Промты для Product Management: как продуктовые команды в 2026 закрывают research, приоритизацию и roadmap без лишних встреч
Продуктовый менеджер в 2026 году — это уже не «человек, который ходит на встречи». Это человек, который умеет формулировать контекст так, чтобы LLM выдала ему черновик исследования, матрицу приоритизации и структуру PRD за один проход. Разница между PM, который «немного пользуется ChatGPT», и тем, кто выстроил вокруг промтов реальный workflow, — это не скорость печати. Это количество синков, которые не нужно проводить.
Ниже — 12 промтов, которые закрывают полный цикл продуктовой работы: от discovery и customer research до roadmap, релиза и post-mortem. Каждый промт — это не «магическая фраза», а структура запроса с ролью, входными данными, ограничениями и форматом вывода. Я разбил их по этапам жизненного цикла продукта, чтобы вы понимали не только что спросить, но и когда это делать.
Важное замечание по методологии: приоритизационные фреймворки RICE и ICE — это реальные, широко используемые в индустрии модели. RICE расшифровывается как Reach, Impact, Confidence, Effort (охват, влияние, уверенность, затраты), ICE — Impact, Confidence, Ease. Формулы простые и проверяемые, поэтому LLM с ними работает стабильно, если вы даёте ей явные входные числа. А вот если попросить «приоритизируй бэклог» без данных — получите галлюцинацию с красивыми цифрами. Об этом ниже.
Этап 1. Discovery и customer research
1. Синтез интервью в JTBD-структуру
Когда применять: после 5–15 проблемных интервью, когда есть сырые заметки и нужно вытащить Jobs-to-be-Done, а не пересказ цитат.
Промт:
Ты — продуктовый исследователь, работающий в методологии Jobs-to-be-Done (Tony Ulwick).
Ниже — сырые заметки с 8 проблемных интервью с пользователями B2B SaaS.
Задача:
1. Выдели 5-7 ключевых jobs (в формате «когда [ситуация], я хочу [мотивация], чтобы [результат]»).
2. Для каждого job укажи: частоту упоминаний в интервью, текущий workaround пользователя, главный барьер.
3. Отдельно перечисли unmet needs — то, что пользователи не могут закрыть текущими инструментами.
4. НЕ выдумывай данные. Если чего-то нет в заметках — пиши «не упоминалось».
Формат вывода: таблица Markdown + короткий абзац с главным инсайтом.
Заметки:
[вставить заметки]
Пример использования: вы провели 8 звонков с клиентами CRM-системы. Промт вернёт вам таблицу jobs с частотой, и вы увидите: 6 из 8 упоминали проблему ручного переноса сделок между воронками, но никто не жаловался на отчёты — хотя вы шли в интервью с гипотезой про отчёты. Это экономит неделю встреч с командой дизайна.
2. Генерация гипотез из инсайтов
Когда применять: сразу после синтеза research, перед формированием бэклога.
Промт:
Роль: Head of Product в компании [описание продукта, размер, рынок].
Контекст: вот 3 главных инсайта из customer research:
[список инсайтов]
Задача: сформулируй 6 продуктовых гипотез в формате:
«Мы верим, что [изменение] для [сегмент] приведёт к [метрика] — потому что [обоснование из research]».
Требования:
- Каждая гипотеза должна быть фальсифицируемой (можно проверить экспериментом за 2-4 недели).
- Для каждой укажи: метрику успеха, минимальный эксперимент, риск ложноположительного результата.
- Не предлагай фичи, которые требуют переписывания архитектуры, если не указано иное.
Почему работает: формула «мы верим, что… приведёт к… потому что…» — это стандарт из книг по продуктовой аналитике (например, подходы из «Testing Business Ideas» Дэвида Блэнда и Александра Остервальдера). LLM хорошо воспроизводит эту структуру, если задать её явно.
Этап 2. Приоритизация бэклога
3. RICE-приоритизация с защитой от галлюцинаций
Когда применять: перед планированием спринта или квартала, когда есть 15+ кандидатов в бэклог.
Главная ошибка — просить «оцени RICE» без входных данных. LLM выдумает Reach и Impact. Правильный подход: вы даёте числа, модель считает и объясняет.
Промт:
Ты — аналитик продукта. Ниже список фич с моими оценками.
Формула RICE = (Reach × Impact × Confidence) / Effort.
- Reach: сколько пользователей затронет за квартал (число).
- Impact: 0.25 (minimal), 0.5 (low), 1 (medium), 2 (high), 3 (massive).
- Confidence: 0-100%.
- Effort: человеко-месяцы.
Задача:
1. Посчитай RICE для каждой фичи. Покажи расчёт построчно.
2. Отсортируй по убыванию.
3. Отметь фичи, где Confidence < 50% — их нужно сначала валидировать, а не строить.
4. НЕ меняй мои входные числа. Если данных не хватает — задай вопрос, а не подставляй своё.
Данные:
| Фича | Reach | Impact | Confidence | Effort |
|---|---|---|---|---|
| SSO для enterprise | 40 | 2 | 80% | 3 |
| ... |
Пример: таблица на выходе покажет, что «SSO для enterprise» с RICE = (40 × 2 × 0.8) / 3 ≈ 21.3 обгоняет «тёмную тему» с RICE = (500 × 0.5 × 0.9) / 2 = 112.5 — и вы удивитесь, потому что интуитивно ставили SSO выше. Это и есть ценность: модель ломает bias.
4. ICE для быстрых growth-экспериментов
Когда применять: в growth-командах, где решения принимаются за дни, а не недели. ICE проще RICE: Impact, Confidence, Ease — по шкале 1–10.
Промт:
Роль: growth PM.
Контекст: продукт — [описание], цель квартала — [метрика, например, +15% к activation rate].
Список экспериментов:
[список]
Для каждого эксперимента:
1. Оцени Impact, Confidence, Ease по шкале 1-10, обоснуй каждую оценку одной строкой.
2. Посчитай ICE = среднее геометрическое трёх оценок (округли до 1 знака).
3. Предложи порядок запуска с учётом зависимостей между экспериментами.
4. Для топ-3 укажи минимальный размер выборки для статистической значимости при базовой конверсии [X]% и MDE [Y]%.
Среднее геометрическое здесь важно: оно штрафует эксперименты с провальной оценкой по одному критерию. Арифметическое среднее этого не делает.
Этап 3. Документация: PRD и user stories
5. PRD из одной страницы
Когда применять: когда фича одобрена, но писать полный PRD лень, а команда ждёт.
Промт:
Ты — senior PM. Напиши PRD для фичи [название].
Контекст:
- Проблема пользователя: [описание]
- Целевой сегмент: [описание]
- Метрика успеха: [метрика + текущее значение + целевое]
- Ограничения: [технические, юридические, временные]
- Что НЕ входит в скоуп: [список]
Структура PRD:
1. Problem statement (2-3 предложения)
2. Goals & Non-goals
3. User stories (формат: «Как [роль], я хочу [действие], чтобы [ценность]») с acceptance criteria в Gherkin (Given/When/Then)
4. Метрики: leading и lagging
5. Риски и открытые вопросы
6. Зависимости от других команд
Пиши конкретно. Не используй слова «интуитивный», «бесшовный», «мощный» — они ничего не значат.
Совет: Gherkin-синтаксис (Given/When/Then) — это реальный формат из Behavior-Driven Development, используемый в Cucumber и подобных инструментах. LLM воспроизводит его точно, если попросить явно, и QA-команда потом может использовать acceptance criteria почти без правок.
6. Декомпозиция эпика в user stories
Когда применять: сразу после PRD, перед грумингом.
Промт:
Разбей эпик [название] на user stories, каждая из которых:
- Помещается в один спринт (≤ 5 story points по Fibonacci).
- Имеет чёткие acceptance criteria.
- Не зависит от других stories внутри эпика (или зависимость указана явно).
Формат вывода: таблица
| ID | User Story | Acceptance Criteria | Story Points | Зависимости |
После таблицы — список stories, которые можно распараллелить между двумя командами.
Этап 4. Roadmap и коммуникация
7. Roadmap «теперь-далее-потом» без дат
Когда применять: для внешней коммуникации со стейкхолдерами, когда точные даты — это ложь.
Промт:
Ты — VP of Product. Составь roadmap в формате Now / Next / Later.
Входные данные:
- Стратегическая цель: [цель]
- Текущий бэклог с RICE-оценками: [таблица]
- Ресурсы: [команды, их ёмкость]
- Внешние дедлайны (если есть): [список]
Требования:
- Now: что делаем в текущем квартале, с обоснованием привязки к стратегии.
- Next: следующие 1-2 квартала, без точных дат.
- Later: гипотезы, которые ещё не валидированы.
- Для каждого пункта — какой сигнал заставит нас его передвинуть.
Не ставь даты, которых нет во входных данных.
Пример: этот промт удобно прогонять перед квартальным ревью. Вы получаете структуру, которую можно защитить: каждое перемещение между Now и Next обосновано сигналом, а не «мнением самого громкого стейкхолдера».
8. Перевод roadmap на язык разных аудиторий
Когда применять: когда один и тот же roadmap нужно показать инженерам, sales и совету директоров.
Промт:
Возьми roadmap ниже и переформулируй его трижды:
1. Для инженерной команды: акцент на технических зависимостях и архитектурных решениях.
2. Для sales: акцент на том, какие боли клиентов закрываются и когда можно продавать.
3. Для совета директоров: акцент на влиянии на выручку, retention и позиционирование против конкурентов.
Сохраняй факты. Не добавляй обещаний, которых нет в исходнике.
Roadmap:
[вставить]
Этап 5. Аналитика и post-mortem
9. Анализ метрик с поиском аномалий
Когда применять: еженедельно, при разборе продуктовой аналитики.
Промт:
Ты — продуктовый аналитик. Ниже данные по метрикам за 12 недель:
[таблица: неделя, DAU, retention D7, conversion, ARPU]
Задача:
1. Найди аномалии (отклонение > 2 стандартных отклонений от скользящего среднего за 4 недели).
2. Для каждой аномалии предложи 3 гипотезы причины, ранжируй по вероятности.
3. Укажи, какие данные нужны, чтобы подтвердить или опровергнуть каждую гипотезу.
4. НЕ утверждай причинно-следственную связь — только корреляции и гипотезы.
Последний пункт критичен: LLM склонна писать «retention упал из-за релиза X», хотя рядом мог быть сезонный фактор или изменение трекинга. Явный запрет на causal claims снижает этот риск.
10. Post-mortem без обвинений
Когда применять: после инцидента или провалившегося релиза.
Промт:
Проведи blameless post-mortem по следующему инциденту:
[описание: что случилось, timeline, impact, что уже известно]
Структура:
1. Impact: количественно, для пользователей и бизнеса.
2. Timeline: от первого сигнала до восстановления.
3. Root cause: техническая и организационная (не «человек ошибся», а «какой процесс позволил ошибке дойти до прода»).
4. Что сработало: детекция, коммуникация, rollback.
5. Action items: конкретные, с владельцем и сроком, направленные на систему, а не на людей.
Тон: нейтральный. Никаких имён и обвинений.
11. Competitive teardown
Когда применять: при входе в новую нишу или перед стратегической сессией.
Промт:
Проведи конкурентный анализ для [продукт] на рынке [рынок].
Конкуренты: [список]
Для каждого:
- Позиционирование (одно предложение).
- Целевой сегмент.
- Ключевые фичи (только то, что подтверждено публично — сайт, документация, changelog).
- Модель монетизации.
- Слабые места (по публичным отзывам, если доступны).
В конце: таблица сравнения по 5 критериям + 3 незанятых позиционирования, которые мы могли бы занять.
Если данных по конкуренту нет — пиши «нет публичных данных», не выдумывай.
12. Синтез стейкхолдерских запросов в единый приоритет
Когда применять: когда sales, support и CEO приносят противоречащие требования.
Промт:
Ниже — запросы от разных стейкхолдеров.
[список: кто, что просит, аргумент]
Задача:
1. Сгруппируй запросы по underlying need (часто 5 запросов = 1 потребность).
2. Для каждой группы: сколько стейкхолдеров, как часто, какой сегмент затрагивает.
3. Оцени каждую группу по RICE, используя данные, которые я дал. Где данных нет — задай уточняющий вопрос.
4. Предложи формулировку ответа стейкхолдерам, чьи запросы не попали в топ.
Как встроить это в реальный workflow
Три практических правила, которые я вывел из работы с продуктовыми командами:
-
Всегда давайте входные данные. LLM без данных выдумывает. Промт «оцени RICE» без таблицы — это генератор красивых чисел, а не приоритизация. Промт с вашими Reach/Impact/Confidence/Effort — это калькулятор с объяснениями.
-
Задавайте формат вывода явно. Таблица Markdown, Gherkin, формула с построчным расчётом — всё это снижает постобработку. Если не задать формат, получите пять абзацев текста, который придётся переписывать вручную.
-
Запрещайте то, что вам не нужно. «Не выдумывай», «не утверждай причинность», «не ставь даты» — эти короткие запреты экономят часы проверки фактов. LLM по умолчанию склонна заполнять пробелы правдоподобными деталями; явный запрет переключает её в режим «признать пробел».
Отдельно стоит сказать про этап жизненного цикла. На discovery промты 1–2 дают максимальный эффект. На приоритизации — 3–4. На документации — 5–6. На коммуникации — 7–8. На пост-релизе — 9–12. Не пытайтесь применять RICE-промт к сырым интервью — получите структурированную бессмыслицу.
Продуктовая работа в 2026 — это не про то, чтобы заменить встречи промтами. Это про то, чтобы приходить на встречи с уже готовым черновиком: синтезом research, матрицей приоритетов и структурой PRD. Тогда встреча длится 20 минут вместо часа, потому что обсуждается не «что делать», а «правильно ли мы посчитали». А если хотите системно прокачать навык формулирования таких запросов под разные роли в продукте — посмотрите материалы по промт-инжинирингу и AI-инструментам для команд на asibiont.com.
Comments