PM без рутины: 11 промтов, которые закрывают бэклог, roadmap и метрики до того, как вы успеете открыть Jira

PM без рутины: 11 промтов, которые закрывают бэклог, roadmap и метрики до того, как вы успеете открыть Jira

Продакт-менеджер — это человек, который половину недели пишет тексты. User stories, acceptance criteria, PRD, релизные заметки, ответы стейкхолдерам, повестки синков, саммари ретро. По моим ощущениям, на генерацию и переписывание формулировок уходит больше времени, чем на собственно принятие решений. Решения занимают минуты, а их оформление — часы.

LLM не заменит продуктовое чутьё: она не знает вашего рынка, не поговорит с пользователями и не возьмёт на себя ответственность за приоритеты. Но она отлично снимает рутину вокруг решений. Ниже — 11 промтов, которые я использую в реальной работе: от бэклога и roadmap до метрик и релиза. Каждый — с примером запроса и пояснением, под какую задачу он заточен.

1. Приоритизация бэклога по RICE

RICE (Reach, Impact, Confidence, Effort) — фреймворк приоритизации, популяризированный командой Intercom: ценность фичи оценивается как произведение охвата, влияния и уверенности, делённое на затраты. Главная проблема RICE — не математика, а то, что PM каждый раз заново объясняет, что имеется в виду под Reach и Impact. Промт фиксирует определения один раз.

Промт: Ты помогаешь продакт-менеджеру приоритизировать бэклог по RICE. Reach — сколько пользователей затронет фича в месяц. Impact — насколько она повлияет на целевую метрику (3 — massive, 2 — high, 1 — medium, 0.5 — low, 0.25 — minimal). Confidence — уверенность в оценках (1.0 — высокая, 0.8 — средняя, 0.5 — низкая). Effort — человеко-месяцы. Вот список фич: [список с оценками]. Посчитай RICE, отсортируй и объясни, почему топ-3 идут первыми. Отдельно отметь фичи, где Confidence ниже 0.8, и предложи, какой самый дешёвый эксперимент поднимет уверенность.

Пример: для фичи «Экспорт отчётов в CSV» с Reach 1200, Impact 1, Confidence 0.8 и Effort 0.5 получаем RICE = (1200 × 1 × 0.8) / 0.5 = 1920. Модель не только считает, но и подсказывает, что при Confidence 0.5 дешевле сначала провести интервью с пятью пользователями, чем строить фичу на догадке.

2. User stories и acceptance criteria

Формат «Как <роль>, я хочу <действие>, чтобы <ценность>» знают все, но качественные acceptance criteria в стиле Given-When-Then пишут единицы. Промт превращает сырое требование в готовую к оценке историю.

Промт: Преобразуй требование в user story и acceptance criteria. Формат story: «Как <роль>, я хочу <действие>, чтобы <ценность>». Acceptance criteria — в формате Given-When-Then, только проверяемые условия, без общих слов вроде «удобно» и «быстро». Отдельно перечисли edge cases и негативные сценарии. Требование: пользователь может восстановить пароль по email.

На выходе вы получите не только happy path («Given пользователь запросил сброс, When перешёл по ссылке в течение 24 часов, Then видит форму нового пароля»), но и сценарии с истёкшим токеном, повторным запросом и уже использованной ссылкой — то, что обычно всплывает на код-ревью и тормозит спринт.

3. PRD из черновика

PRD (Product Requirements Document) — документ, который описывает проблему, цели, scope и метрики успеха. Писать его с нуля мучительно; переписать структурированный черновик — быстро. Ключ в том, чтобы дать модели факты, а не просить их придумать.

Промт: Составь PRD на основе моих заметок. Структура: проблема и контекст, цели и метрики успеха, целевые пользователи, scope (in/out), функциональные требования, зависимости, риски, открытые вопросы. Не выдумывай данные: если факта нет в заметках — вставь [НУЖНО УТОЧНИТЬ]. Пиши короткими абзацами. Заметки: [сырой текст]

Плейсхолдер [НУЖНО УТОЧНИТЬ] — самая полезная часть промта. Он не даёт модели «дорисовать» рынок и цифры, а сразу показывает, где у вас пробелы в собственном понимании задачи.

4. Roadmap на квартал

Roadmap — это не список фич, а история о том, куда движется продукт. Модель хорошо помогает переупаковать бэклог в нарратив по горизонтам Now / Next / Later.

Промт: Собери roadmap на квартал из списка инициатив. Сгруппируй по Now / Next / Later. Для каждой инициативы укажи: проблему пользователя, ожидаемый эффект, метрику успеха и ключевой риск. Не обещай дат, если они не указаны. В конце — три предложения о том, какую историю этот roadmap рассказывает совету директоров. Инициативы: [список]

Ограничение «не обещай дат» критично: roadmap с датами превращается в контракт, а roadmap без дат — в направление. Модель по умолчанию любит добавлять конкретику, поэтому запрет нужно прописывать явно.

5. Анализ retention и churn

Когортный анализ — это таблица, где строки — когорты пользователей по дате первого действия, а столбцы — периоды их жизни. Считать его в SQL умеют аналитики, но интерпретировать и формулировать гипотезы часто приходится PM.

Промт: Вот таблица retention по недельным когортам: [данные]. Проанализируй: где самый резкий обрыв, отличается ли поведение когорт между собой, есть ли признаки «выгорания» продукта. Предложи три гипотезы падения и для каждой — метрику, по которой её можно проверить. Не делай выводов о причинах, которых нет в данных.

Последняя фраза экономит вам репутацию: без неё модель уверенно объяснит падение «сезонностью» или «конкуренцией», хотя в данных этого нет.

6. Разбор NPS и обратной связи

Открытые ответы в NPS-опросах — это сотни строк текста, которые никто не читает целиком. LLM отлично работает как тематический классификатор.

Промт: Вот 200 ответов на вопрос «Почему вы поставили такую оценку?»: [текст]. Сгруппируй их в темы, для каждой темы укажи: название, количество упоминаний, 2–3 цитаты-примера, тональность. Отдельно выдели темы, характерные для оценок 0–6 (детракторы) и 9–10 (промоутеры). В конце — топ-3 темы, которые стоит вынести в бэклог.

Важно помнить про ограничение: NPS — это не метрика продукта, а индикатор лояльности, и по одной цифре нельзя судить о качестве продукта. Промт помогает увидеть, что стоит за цифрой.

7. Release notes для пользователей

Релизные заметки пишутся в двух версиях: сухая для внутреннего changelog и человеческая для пользователей. Оба варианта легко генерируются из списка задач.

Промт: Напиши release notes по списку изменений. Две версии: 1) для пользователей — дружелюбно, без технического жаргона, акцент на выгоде, 5–7 пунктов; 2) для внутреннего changelog — сухо и точно, с номерами задач. Не преувеличивай значимость мелких правок. Изменения: [список]

Отдельно попросите модель помечать breaking changes — это то, что пользователи должны увидеть в первую очередь.

8. Ретроспектива: саммари и действия

Ретро без действий — это разговор ради разговора. Промт превращает сырые заметки в структурированный документ с конкретными задачами.

Промт: Вот сырые заметки с ретро [текст]. Оформи в структуру: что сработало, что не сработало, идеи. Преобразуй идеи в 3–5 action items в формате «действие — владелец — срок». Если владелец или срок не указаны в заметках, пометь их как [нужно назначить]. Не придумывай новые проблемы, которых не было в заметках.

Формат «действие — владелец — срок» — это то, что отличает ретро, после которого что-то меняется, от ретро, после которого остаётся красивый документ.

9. Синк со стейкхолдерами: повестка и follow-up

Половина конфликтов в проектах — из-за неясных ожиданий, а не из-за плохой работы. Промт помогает подготовить встречу и зафиксировать договорённости.

Промт: Подготовь повестку встречи со стейкхолдерами на 30 минут. Цель встречи: [цель]. Участники: [список]. Контекст: [краткое описание]. Формат: цель, 3–4 пункта повестки с таймингом, вопросы, требующие решения, ожидаемый результат. После встречи я пришлю тебе заметки — на их основе сделай follow-up письмо с решениями, владельцами и сроками.

Второй промт — для follow-up — часто важнее первого: именно письмо с зафиксированными решениями защищает вас от «мы же договорились иначе».

10. Метрики продукта: дерево и North Star

Дерево метрик связывает North Star (главную метрику продукта) с метриками более низкого уровня. Строить его вручную долго, а модель отлично справляется с черновиком.

Промт: Построй дерево метрик для [продукт] с North Star [метрика]. Разложи на 3 ветки: acquisition, engagement, monetization. Для каждого узла укажи метрику, формулу и то, на какой узел выше он влияет. Отметь метрики-«водители» (leading) и метрики-«результаты» (lagging). Не выдумывай данные о текущих значениях.

Полезная проверка после генерации: если изменение метрики на нижнем уровне не объясняет изменение метрики выше, ветка построена неправильно.

11. Коммуникация со стейкхолдерами: сложные сообщения

Отказ от фичи, перенос сроков, плохие новости — самые неприятные тексты в работе PM. Модель здесь не принимает решение, но помогает сформулировать его без лишней эмоциональности.

Промт: Помоги написать сообщение стейкхолдеру. Ситуация: [описание]. Нужно: честно сообщить о [проблема], объяснить причину без обвинений, предложить варианты решения и запросить конкретное решение. Тон: профессиональный, прямой, без корпоративного жаргона. Длина: до 150 слов. Не оправдывайся и не используй фразы вроде «как вы знаете».

Правило «без обвинений» здесь принципиально: цель сообщения — не найти виноватого, а получить решение.

Сводная таблица: какой промт под какую задачу

Что важно помнить

LLM не знает ваших пользователей, рынка и ограничений команды. Любой сгенерированный артефакт — это черновик, который вы проверяете и присваиваете. Самые опасные места — цифры и причинно-следственные связи: модель уверенно напишет «падение retention вызвано релизом», даже если в данных этого нет. Поэтому в промтах выше так часто встречаются запреты вроде «не выдумывай данные» и «не делай выводов, которых нет в данных» — это не паранойя, а рабочий приём.

Начните с двух-трёх промтов из тех, что закрывают вашу самую рутинную задачу. Скорее всего, это будет приоритизация бэклога или release notes. Через неделю вы заметите, что время уходит на решения, а не на формулировки, — и это, пожалуй, лучший показатель того, что AI встроился в процесс правильно.