20 промптов для продакт-менеджера, которые показывают компромиссы

01. Написать PRD из сумбурного брифа и перечислить открытые вопросы

У вас есть тред в Slack, заметки со звонка и дедлайн, но нет спецификации.

Преврати этот сумбурный бриф в документ с продуктовыми требованиями.

[вставьте бриф, тред, заметки со звонка или всё, что есть]

Разделы в таком порядке: проблема и у кого она есть, подтверждения, которые у нас есть, цель с измеримым результатом, что входит в объём, что не входит в объём, пользовательский сценарий по пронумерованным шагам, требования с пометкой MUST или SHOULD и зависимости от других команд.

Используй только то, что сказано в брифе. Там, где он молчит, пиши [OPEN: вопрос] вместо того, чтобы додумывать.

В конце перечисли все открытые вопросы, сгруппировав их по тому, кто может ответить (я, дизайн, разработка, юристы, клиент), и вынеси первыми три вопроса, которые блокируют разработку.

02. Разбить фичу на пользовательские истории с критериями приёмки

Рефайнмент завтра, а фича всё ещё один большой тикет.

Разбей эту фичу на пользовательские истории, которые команда может делать и выпускать по одной.

Фича: [что она делает]
Пользователи: [кто ею пользуется и чего хочет добиться]
Ограничения: [платформы, сроки, то, что уже сделано]

Для каждой истории:
1. Как [пользователь], я хочу [действие], чтобы [результат].
2. Критерии приёмки в формате Given / When / Then, от трёх до шести на историю, каждый можно проверить без участия автора.
3. Оценку размера S, M или L и одну вещь, которая делает её неопределённой.

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

03. Найти граничные случаи, которые пропустил ваш PRD

Спецификация выглядит готовой, а разработка стартует на следующей неделе.

Прочитай этот PRD глазами инженера, которому после запуска придут баг-репорты.

[вставьте PRD или спецификацию]

Перечисли граничные случаи, которые он не покрывает, по группам: пустые состояния и первый запуск, ошибки и таймауты, права и роли, пределы (очень длинное, очень много, ноль, дубликат), конкурентность (два человека редактируют, двойные клики, повторные запросы), данные, появившиеся до этой фичи, и доступность.

Для каждого случая: сценарий одной строкой, что, судя по спецификации, произойдёт сейчас, и вопрос, на который мне нужно ответить. Выбери пять главных по вероятности, что реальный пользователь столкнётся с ними в первый месяц. Не придумывай требования, задавай вопросы.

Откройте остальные промпты (17) бесплатно

Подпишитесь на рассылку Whizi, чтобы прочитать остальную часть набора.

4. Оценить бэклог по RICE и показать расчёт
5. Превратить заметки интервью в задачи, боли и цитаты
6. Составить гайд для discovery-интервью о том, что люди делали, а не чего хотят
7. Сгруппировать тикеты поддержки в продуктовые проблемы, которые стоит чинить
8. Написать спецификацию на одну страницу, по которой инженеры смогут строить
9. Выбрать метрику успеха и контрметрику, которая не даёт себя обманывать
10. Спроектировать эксперимент и сначала ответить на вопросы о размере выборки
11. Составить чек-лист запуска с ответственным в каждой команде
12. Написать заметки о релизе, которые пользователи действительно читают
13. Написать апдейт для стейкхолдеров, начав с того, что изменилось
14. Написать историю роадмапа, где сказано, чем вы не занимаетесь
15. Отказать в запросе фичи, объяснив причину и следующий шаг
16. Провести пре-мортем до выхода запуска
17. Разобрать страницу продукта конкурента по утверждениям
18. Написать одну цель спринта из длинного списка тикетов
19. Превратить запрошенное решение в проблему, которая за ним стоит
20. Попросить вторую модель проверить PRD первой