PM без рутины: 12 промтов, которые ведут проект от roadmap до постмортема

PM без рутины: 12 промтов, которые ведут проект от roadmap до постмортема

Продакт-менеджер — это профессия, где 70% времени уходит не на стратегию, а на перевод мыслей в документы. Roadmap, PRD, user stories, RICE-таблицы, повестки ретро, письма стейкхолдерам, постмортемы — всё это нужно, всё это горит, и всё это делается руками. По данным исследования ProductPlan (ежегодный обзор State of Product Management), приоритизация бэклога и коммуникация со стейкхолдерами стабильно входят в топ-3 самых времязатратных задач PM.

Хорошая новость: большая часть этой работы — это структурирование информации по известным фреймворкам. RICE, ICE, MoSCoW, Jobs-to-be-Done, формат Amazon PR/FAQ — это не творчество, а шаблоны рассуждений. А значит, LLM справляется с ними хорошо — при условии, что вы даёте ей правильный контекст и требуете конкретный формат вывода.

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

Как читать эти промты

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

Отдельно про данные: не вставляйте в публичные LLM реальные имена клиентов, суммы контрактов и внутренние метрики, если это запрещено политикой компании. Используйте обезличенные примеры или корпоративный инстанс с изоляцией данных.

1. Декомпозиция roadmap по кварталам

Задача: превратить годовую стратегию в квартальные вехи с эпиками.

Промт:

Ты — Senior Product Manager в B2B SaaS. У меня есть годовая цель.
Разложи её на 4 квартала, в каждом — 2-3 эпика.
Для каждого эпика: гипотеза, ключевая метрика, зависимость от других команд.
Ограничения: команда 6 человек, 1 дизайнер, релизный цикл 2 недели.
Формат: таблица Markdown: Квартал

| Эпик | Гипотеза | Метрика | Зависимости
Цель: снизить отток в первые 90 дней на 15%.

Пример: B2B-сервис аналитики для e-commerce, годовая цель — удержание. Модель выдала 4 квартала: Q1 — онбординг-чеклист, Q2 — интеграция с CRM, Q3 — self-serve отчётность, Q4 — программа лояльности. Каждый эпик с гипотезой и метрикой.

Что экономит: 3-4 часа на первом черновике roadmap. PM не пишет с нуля — редактирует и защищает перед командой.

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

Задача: расставить фичи по RICE без Excel-страданий.

Промт:

Ты — аналитик продукта. Оцени фичи по RICE.
RICE = (Reach × Impact × Confidence) / Effort.
Impact: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal.
Confidence: 100%/80%/50%.
Effort — в человеко-неделях.
Список фич: [вставьте список].
Формат: таблица + топ-5 с обоснованием.
Покажи, какие фичи выпадают из спринта и почему.

Пример: фича «экспорт в PDF» получила RICE 12.5, «тёмная тема» — 2.1. Модель честно показала, что тёмная тема — низкий impact при высоком effort.

Что экономит: вечер в таблицах. RICE-калькулятор в голове у модели, вам остаётся валидировать числа.

3. Написание PRD (Product Requirements Document)

Задача: собрать PRD по стандартной структуре за один прогон.

Промт:

Ты — PM, пишущий PRD для инженерной команды.
Структура: Problem, Goals, Non-goals, User stories, 
Success metrics, Edge cases, Open questions.
Фича: [описание]. Пользователь: [сегмент].
Пиши конкретно, без воды. Каждый пункт — 1-2 предложения.
Non-goals обязательны: что мы НЕ делаем в этой версии.

Пример: фича «массовое приглашение пользователей». PRD на 1.5 страницы с явными non-goals (без SSO, без ролей) — команда не тратит спринт на обсуждение скоупа.

Что экономит: 2-3 часа. Главное — раздел Non-goals, который обычно забывают и который снимает половину споров.

4. Разбиение эпика на user stories

Задача: превратить эпик в набор готовых к оценке историй.

Промт:

Ты — PM. Разбей эпик на user stories в формате:
As a [роль], I want [действие], so that [ценность].
Для каждой: acceptance criteria (Given/When/Then), 
story points (Fibonacci), зависимости.
Эпик: [описание]. Не дроби мельче 1 дня и крупнее 5 дней.

Пример: эпик «онбординг» разбился на 7 историй. Инженеры оценили за 20 минут на планировании вместо часа.

Что экономит: время на груминге бэклога. Истории уже в правильном формате для Jira.

5. Фасилитация ретроспективы

Задача: подготовить сценарий ретро и структурировать выводы.

Промт:

Ты — Agile-коуч. Подготовь сценарий ретро на 60 минут.
Формат: Start/Stop/Continue. Команда: 6 человек, спринт был тяжёлым.
Дай: 3 вопроса для разогрева, тайминг по минутам, 
технику для тихих участников.
Затем: помоги сгруппировать вводные в 3 action items с владельцами.

Пример: после ввода вводных модель сгруппировала 14 стикеров в 3 темы: «размытые требования», «долгие ревью», «флаки-тесты». Каждая — с owner и дедлайном.

Что экономит: час фасилитации и вечер на оформление протокола.

6. Постмортем инцидента

Задача: написать blameless-постмортем без обвинений.

Промт:

Ты — SRE/PM. Напиши blameless postmortem.
Структура: Summary, Impact, Timeline, Root cause (5 Whys), 
What went well, What went wrong, Action items.
Тон: без обвинений, фокус на системах, не на людях.
Инцидент: [описание и таймлайн].

Пример: падение платежей на 40 минут. Модель выстроила таймлайн и через 5 Whys вывела на отсутствие алерта на лаг репликации — action item, который никто не заметил в горячке.

Что экономит: 2 часа на структурирование. Blameless-тон задаётся автоматически.

7. Письмо стейкхолдерам о сдвиге сроков

Задача: сообщить плохие новости без паники.

Промт:

Ты — PM. Напиши письмо стейкхолдерам о переносе релиза.
Факты: [что случилось]. Новая дата: [дата]. Причина: [причина].
Структура: суть в первом абзаце, причина без оправданий, 
план, что нужно от стейкхолдеров.
Тон: спокойный, фактологичный. Максимум 200 слов.

Пример: перенос релиза на 2 недели из-за проблем с интеграцией. Письмо на 150 слов: суть → причина → новый план → просьба. Без воды.

Что экономит: 30 минут на переписывание. Плохие новости доходят быстрее и спокойнее.

8. Синтез пользовательских интервью

Задача: вытащить инсайты из 10 транскриптов.

Промт:

Ты — UX-исследователь. Проанализируй транскрипты интервью.
Найди: повторяющиеся боли, цитаты-подтверждения, 
сегменты пользователей, противоречия.
Формат: таблица Боли

| Частота | Цитата | Сегмент.
В конце — 3 инсайта, которые меняют roadmap.

Пример: из 10 интервью модель выделила боль «не понимаю, откуда цифры в отчёте» — 7 из 10. Это стало фичей Q3.

Что экономит: день ручного кодирования. Инсайты на выходе, а не 40 страниц заметок.

9. Метрики продукта и North Star

Задача: выбрать North Star и декомпозировать её.

Промт:

Ты — продуктовый аналитик. Предложи North Star Metric для [продукт].
Обоснуй: почему она отражает ценность для пользователя.
Декомпозируй на 3-4 input-метрики.
Для каждой: как измерять, где смотреть, целевой тренд.
Избегай vanity-метрик (регистрации, просмотры).

Пример: для B2B-аналитики North Star — «число активных дашбордов на аккаунт в неделю». Input-метрики: time-to-first-dashboard, частота возвратов, число шаренных отчётов.

Что экономит: часы на споры о метриках. Модель отсекает vanity-метрики сразу.

10. Анализ конкурентов

Задача: структурировать конкурентный ландшафт.

Промт:

Ты — продуктовый стратег. Сравни [продукт] с [конкуренты].
Таблица: Функция

| Мы | К1 | К2 | К3 | Вывод.
Затем: 3 наших преимущества и 3 пробела.
Данные: [описание фич]. Не выдумывай фичи, которых нет в данных.

Пример: таблица по 8 функциям показала, что у конкурентов нет self-serve онбординга — это стало дифференциатором.

Что экономит: полдня на сравнительные таблицы. Фокус на пробелах, а не на фичах ради фич.

11. Скоуп MVP

Задача: отрезать лишнее от первой версии.

Промт:

Ты — PM. Помоги определить MVP для [продукт].
Что оставить: только то, без чего пользователь не получит ценность.
Формат: In / Out / Later.
Для каждого пункта в In — обоснование одной строкой.
Для Out — почему это не MVP.

Пример: из 15 фич в MVP осталось 4. Остальные — в Later с обоснованием. Релиз сдвинулся с 3 месяцев на 6 недель.

Что экономит: недели разработки. MVP-дисциплина — главный навык PM, и модель тут помогает быть безжалостным.

12. Синтез обратной связи из поддержки

Задача: найти паттерны в тикетах поддержки.

Промт:

Ты — продуктовый аналитик. Проанализируй тикеты поддержки.
Классифицируй: баги, запросы фич, вопросы, UX-проблемы.
Формат: Категория

| Кол-во | Топ-3 темы | Приоритет.
В конце — 5 фич, которые закроют больше всего тикетов.

Пример: из 500 тикетов 40% — запросы на экспорт. Это стало топ-фичей бэклога без единого интервью.

Что экономит: ручную сортировку сотен тикетов. Паттерны видны сразу.

Что общего у всех промтов

Ещё один приём: просите модель в конце промта задать вам 3 уточняющих вопроса. Часто именно они вскрывают дыры в вашем же брифе — и это ценнее готового ответа.

Заключение

Ни один из этих промтов не заменяет PM. Решения о том, что строить и почему, принимает человек. Но рутина — перевод мыслей в документы, таблицы и письма — отлично делегируется. Начните с двух промтов, которые отнимают у вас больше всего времени: скорее всего, это приоритизация и PRD. Прогоните их на реальной задаче этой недели, сравните с тем, что делали руками, и оставьте в работе то, что сэкономило хотя бы час. Через месяц у вас будет свой набор — точнее любого универсального списка.