PRD
Также: product requirements document, ПРД, документ требований к продукту, продуктовые требования
PRD (product requirements document) — документ требований к продукту или фиче: какую проблему решаем, для кого, как измерим успех и что входит в объём. Отвечает на «что и зачем», а не «как сделать».
PRD (product requirements document, документ требований к продукту) — короткий документ, в котором продакт-менеджер описывает, какую проблему решает фича, для кого, как измерить успех и что в неё входит. PRD отвечает на вопросы «что» и «зачем». Вопрос «как» — архитектуру, интерфейс, код — решают дизайнеры и разработчики, и в PRD его не диктуют.
Что входит в PRD?
- Проблема — чья боль и какие есть доказательства: интервью, данные, обращения в поддержку;
- Цель и метрика успеха — какое число и на сколько должно измениться;
- Пользователи и сценарии — кто и в какой ситуации столкнётся с фичей;
- Объём — что входит и, что важнее, что не входит (non-goals);
- Требования — функциональные и нефункциональные, с приоритетом;
- Критерии готовности — по каким признакам фичу выпускают;
- Открытые вопросы и риски — что ещё не решено и кто решает.
Чем PRD отличается от ТЗ?
| PRD | Техническое задание | |
|---|---|---|
| Отвечает на вопрос | Что и зачем | Как именно сделать |
| Автор | Продакт-менеджер | Аналитик, архитектор, заказчик |
| Меняется | По мере новых данных | Обычно фиксируется договором |
| Главный раздел | Проблема и метрика успеха | Требования к реализации |
Пример
Онлайн-школа «Букварь» теряет учеников после первой недели. Фрагмент PRD:
- Проблема: 38% учеников не возвращаются после первого урока; в 12 интервью из 15 причина — «не понял, что делать дальше»;
- Метрика: доля вернувшихся на второй урок в течение 7 дней — с 62% до 70%;
- Объём: экран «Ваш следующий шаг» после урока и письмо через 24 часа;
- Не входит: переделка программы курса и геймификация — отдельные решения;
- Готовность: экран показан 100% новых учеников, A/B-тест на две недели.
Где чаще всего ошибаются?
- Начинать с решения. «Сделать экран X» вместо «ученики не понимают, что делать дальше» — команда теряет шанс предложить решение лучше.
- Не писать non-goals. Без них объём разрастается в процессе разработки.
- Метрика без числа. «Улучшить удержание» нельзя проверить; «с 62% до 70% за квартал» — можно.
- Писать 30 страниц. Хороший PRD читается за 10 минут; детали живут в макетах и задачах.
- Не обновлять. PRD, который разошёлся с тем, что делают, хуже, чем отсутствие PRD.
Связанные термины
- Jobs to be Done — как сформулировать проблему пользователя;
- Приоритизация — какие требования делать первыми;
- MVP — минимальный объём первой версии;
- Метрики продукта — чем измерять успех.
Продуктовая аналитика 2.0
Углубленный курс продуктовой аналитики с Python, ML и продвинутыми техниками анализа
Посмотреть курс