Промты для Product Management: как ИИ берёт на себя RICE, user stories и разговоры со стейкхолдерами

Product-менеджер живёт в трёх параллельных реальностях: бэклог, который никогда не заканчивается, стейкхолдеры, у которых «всё срочно», и команда, которой нужно понятное ТЗ вчера. По данным исследования Product Management Festival и отчётов продуктовых сообществ, значительная часть рабочего времени PM уходит не на стратегию, а на рутину: переписывание требований, сведение оценок, подготовку вопросов к интервью. Именно эту рутину LLM забирают лучше всего — если дать ей правильную рамку.

Ниже — подборка промтов, которые можно копировать и адаптировать под свой продукт. Каждый промт решает конкретную задачу, имеет пример входа и выхода и опирается на реальные фреймворки: RICE (Intercom), ICE (Sean Ellis), Jobs-to-be-Done (Clayton Christensen), MoSCoW (DSDM Consortium), Kano-модель (Noriaki Kano). Промты не заменяют мышление PM — они убирают механическую часть и оставляют место для решений.

1. Гипотеза в формате, который можно проверить

Плохая гипотеза — «улучшим онбординг, станет лучше». Хорошая — проверяемая и с метрикой. Промт заставляет модель собрать гипотезу по структуре «Если… то… потому что…» и сразу привязать к метрике.

Ты — senior PM в B2B SaaS. Преврати мою сырую идею в проверяемую гипотезу.
Структура: "Если мы [изменение], то [метрика] изменится на [X] у [сегмент], потому что [причина]."
Добавь: метрику успеха, метрику-контрбаланс (что не должно ухудшиться), минимально достаточное доказательство и способ проверки.
Идея: {idea}
Контекст продукта: {context}

Пример. Вход: «Пользователи бросают настройку интеграции на 3-м шаге». Выход: «Если мы объединим шаги 2–3 в один экран с прогресс-баром, то completion rate онбординга вырастет у новых аккаунтов, потому что снизится когнитивная нагрузка». Контрбаланс — количество обращений в поддержку по настройке не растёт.

2. RICE без Excel-мучений

RICE = Reach × Impact × Confidence / Effort. Intercom популяризовал формулу именно для честного сравнения фич, а не для того, чтобы «победила самая громкая». Промт считает и — что важнее — заставляет модель объяснить допущения.

Рассчитай RICE для списка фич. Для каждой дай:
- Reach: сколько пользователей затронет за квартал, с обоснованием
- Impact: 3 (massive), 2 (high), 1 (medium), 0.5 (low), 0.25 (minimal)
- Confidence: 100% / 80% / 50% — и почему именно столько
- Effort: человеко-недели команды
Покажи таблицу и отсортируй по RICE. Отдельно перечисли, где Confidence ниже 80% и какие данные нужны, чтобы его поднять.
Фичи: {features}
Данные о продукте: {metrics}

Обратите внимание: тёмная тема и экспорт обгоняют SSO по RICE — классический пример, почему «очевидные» enterprise-фичи не всегда выигрывают. Промт помогает это увидеть и аргументировать перед стейкхолдером.

3. ICE для быстрых решений и экспериментов

Когда данных мало и RICE нечестен (нечего считать в Reach), работает ICE: Impact × Confidence × Ease, каждая по шкале 1–10. Sean Ellis описывал ICE именно для growth-экспериментов, где скорость важнее точности.

Оцени идеи по ICE (1-10 по каждой оси). Дай оценку и одну строку обоснования на каждую ось.
Затем раздели идеи на три корзины: "делать сейчас", "тестировать малым усилием", "отложить".
Идеи: {ideas}

Этот промт удобно прогонять раз в спринт по накопившемуся списку «а давайте попробуем».

4. User story + критерии приёмки в Gherkin

Формат user story: «Как [роль], я хочу [действие], чтобы [ценность]». Критерии приёмки в Gherkin (Given/When/Then) — де-факто стандарт в BDD, изначально описанный Дэном Нортом в Cucumber. Промт генерирует и то, и другое сразу.

Разбей фичу на user stories. Для каждой:
- Заголовок в формате "Как <роль>, я хочу <действие>, чтобы <ценность>"
- 3–5 критериев приёмки в формате Gherkin (Given / When / Then)
- Edge cases: пустые состояния, ошибки сети, права доступа, лимиты
- Definition of Done для этой истории
Фича: {feature}
Роли в продукте: {roles}

Пример выхода: «Как администратор, я хочу приглашать коллег по email, чтобы не заводить аккаунты вручную». Given у меня есть права admin, When я ввожу email и нажимаю «Пригласить», Then создаётся pending-аккаунт и уходит письмо. Edge case: email уже занят — показать предложение отправить напоминание вместо ошибки.

5. Декомпозиция эпика с оценкой

Большие эпики страшны, пока не разбиты. Промт режет эпик на вертикальные срезы (то, что можно показать пользователю), а не на слои «бэкенд / фронтенд» — это важно для инкрементальной поставки.

Разбей эпик на вертикальные срезы, каждый из которых можно зарелизить отдельно и показать пользователю.
Для каждого: цель, объём, зависимости, rough estimate в story points (Fibonacci), риски.
Отсортируй от самого маленького ценного к самому большому.
Эпик: {epic}

6. Приоритизация по MoSCoW и Kano

MoSCoW (Must / Should / Could / Won't) из методологии DSDM хорош для фиксированного дедлайна. Kano-модель Нориаки Кано — для понимания, что радует, а что просто ожидается.

Разложи список требований по MoSCoW и отдельно проведи Kano-классификацию:
Must-be, Performance, Attractive, Indifferent, Reverse.
Пометь конфликты: что попало в Must по MoSCoW, но по Kano — Indifferent.
Требования: {requirements}

Конфликты — самое ценное здесь: они показывают, где команда делает то, что пользователю всё равно, только потому что «так исторически сложилось».

7. Jobs-to-be-Done вместо фич

Клейтон Кристенсен сформулировал JTBD так: люди «нанимают» продукт на работу. Промт переводит список фич в работы, которые пользователь пытается выполнить.

Переформулируй список фич в Jobs-to-be-Done.
Формат работы: "Когда <ситуация>, я хочу <мотивация>, чтобы <результат>".
Для каждой работы укажи: текущее решение пользователя, боль, метрику успеха.
Фичи: {features}

Это спасает от классической ловушки «фича ради фичи»: половина списка превращается в одну и ту же работу.

8. Вопросы для интервью со стейкхолдером

Самая недооценённая часть работы PM — подготовка к разговору. Промт генерирует вопросы, которые вытаскивают реальную потребность, а не подтверждают уже принятое решение.

Составь набор вопросов для интервью со стейкхолдером по теме {topic}.
Раздели на блоки: контекст и цели, ограничения, критерии успеха, риски, кто принимает решение.
Избегай наводящих вопросов. Добавь 3 вопроса, которые вскроют скрытые конфликты интересов между отделами.

9. Синтез заметок из 10 интервью

После десятка интервью заметки превращаются в кашу. Промт вытаскивает паттерны и цитаты.

Вот заметки с {N} интервью. Выдели:
- топ-5 повторяющихся болей с частотой упоминания
- противоречия между респондентами
- цитаты-иллюстрации (по одной на боль)
- что НЕ подтвердилось из наших гипотез
Не выдумывай то, чего нет в заметках.
Заметки: {notes}

Фраза «не выдумывай» критична: без неё модель любит достраивать красивые выводы, которых в данных нет.

10. Анализ конкурентов по публичным данным

Промт не заменяет исследование, но структурирует то, что уже есть в открытых источниках: цены, позиционирование, changelog.

Собери сравнительную таблицу конкурентов: {competitors}.
Критерии: целевой сегмент, ключевая ценность, модель монетизации, заметные фичи, слабые места по отзывам.
Источник — только публичные данные (сайт, pricing, changelog, отзывы). Помечай, где данных нет.

11. Release notes, которые читают

Release notes — это тоже продукт. Промт переводит внутренний changelog на язык пользователя.

Преврати технический changelog в release notes для пользователей.
Формат: короткий заголовок-выгода, одно предложение пояснения, что делать пользователю.
Тон: дружелюбный, без маркетингового шума. Сгруппируй по темам: новое, улучшения, исправления.
Changelog: {changelog}

12. Ответ на «срочный» запрос стейкхолдера

Самый частый конфликт: «это нужно вчера». Промт помогает ответить без конфликта, но с данными.

Стейкхолдер просит добавить {request} в текущий спринт.
Напиши ответ, который:
- признаёт ценность запроса
- показывает, что выйдет из спринта при добавлении (конкретные фичи)
- предлагает 2 альтернативы: сдвиг сроков или урезанный объём
- заканчивается вопросом о приоритете, а не отказом
Текущий состав спринта: {sprint}

Это превращает разговор из «нет» в «выберите, что важнее» — и перекладывает решение туда, где оно и должно быть.

13. Метрики продукта: дерево и контрбалансы

Промт строит дерево метрик с North Star и защитой от «оптимизации в одну сторону».

Построй дерево метрик продукта: North Star, 3-4 входные метрики, 2 контрбаланса.
Для каждой метрики: определение, как считать, частота, кто владелец.
Покажи, какую метрику легко испортить в погоне за North Star.
Продукт: {product}

14. PRD в один экран

Полноценный PRD на 20 страниц никто не читает. Промт сжимает суть в одностраничник.

Собери one-pager PRD: проблема, доказательства, целевой сегмент, предлагаемое решение, метрики успеха, вне scope, открытые вопросы, зависимости.
Максимум 400 слов. Без воды и маркетинга.
Контекст: {context}

15. Разбор причин падения метрики

Когда метрика просела, важно не угадывать. Промт задаёт структуру диагностики.

Метрика {metric} упала на {X%} за {период}. Помоги построить диагностику:
- 5 наиболее вероятных причин с проверяемым сигналом на каждую
- какие данные запросить в первую очередь
- как отличить сезонность от регрессии
- что проверить в первую очередь, если регрессия в коде
Данные: {data}

16. Стейкхолдер-карта и план коммуникации

Промт помогает не забыть, кому и что рассказывать.

Составь карту стейкхолдеров по влиянию и интересу (матрица power/interest).
Для каждой группы: что важно, как часто общаться, какой формат, главный риск недокоммуникации.
Стейкхолдеры: {stakeholders}

17. Ретро-вопросы, которые не звучат как ритуал

Промт генерирует вопросы для ретро, которые вытаскивают реальные проблемы процесса, а не «что прошло хорошо».

Составь 7 вопросов для ретро спринта, которые вскрывают процессные проблемы.
Избегай общих формулировок. Каждый вопрос должен быть таким, чтобы на него нельзя было ответить "всё нормально".
Контекст спринта: {context}

18. Метрики-антипаттерны: чему не верить

Финальный промт — для самопроверки. Модель ищет в плане признаки плохих метрик (vanity metrics) и ловушки.

Проверь мой план по метрикам на антипаттерны: vanity metrics, метрики без владельца, метрики, которые нельзя изменить действиями команды, конфликтующие метрики.
Для каждого антипаттерна предложи замену.
План: {plan}

Как этим пользоваться на практике

Три правила, которые сэкономят время. Первое: всегда давайте модели контекст продукта — без него она выдаёт generic-ответы. Второе: просите обоснования, а не только результат — «почему такая оценка» ценнее самой оценки. Третье: не доверяйте цифрам без источника — LLM может уверенно выдать выдуманный процент, поэтому любую статистику проверяйте по первоисточникам (документация фреймворков, отчёты компаний, академические статьи).

Промты — это не замена PM, а снятие рутины. Они освобождают время на то, что действительно требует человека: разговор со стейкхолдером, спор о приоритетах, решение о том, что НЕ делать. Начните с двух-трёх промтов из этой подборки, адаптируйте под свой продукт — и через неделю заметите, что бэклог перестал быть бесконечным.