Как писать PRD: структура, примеры и шаблон документа
Содержание:
- В чем разница между PRD, BRD и что писать продакту
- Когда писать короткий PRD, а когда полный
- Что должно быть в каждом разделе PRD
- Как написать PRD с помощью ИИ и поддерживать его производительность актуальным
Команды, которые начинают разработку без документа с требованиями, платят за это дважды. Сначала временем на переделки, когда разработчик и дизайнер поняли задачу по-разному. Потом деньгами, когда фича готова, но решает не ту проблему. PRD — это документ, который закрывает оба риска до того, как команда написала первую строчку кода.
Product Requirements Document — это документ с требованиями к продукту или отдельной фиче, который объясняет что нужно построить, для кого и зачем. Это важный инструмент синхронизации: продакт, разработка, дизайн и заинтересованные стороны смотрят на один документ и понимают проект одинаково. Без него каждый участник работает со своей версией реальности.
PRD должен дать команде ответы на три вопроса. Какую проблему пользователя решаем и почему это приоритет. Что именно строим и каковы границы scope. Как поймем, что справились — через конкретные показатели успеха и критерии успеха.
Большинство проблем с PRD не в том, что его не пишут. Проблема в том, как пишут. Документ на 15 страниц, который никто не читает до конца. Требования без метрик. Решение, описанное вместо проблемы. Документ, написанный для себя, а не для вашей команды. Результат одинаковый: scope creep, переделки, недопонимание между разработчиками и дизайнерами.
Короткий гайд по статье
- PRD это документ с требованиями к продукту который синхронизирует понимание задачи между продактом, разработкой и дизайном
- Выбирайте формат под задачу: 1-pager для небольших доработок, полный PRD для новых продуктов и крупных фич
- Самый важный раздел — problem statement с конкретной метрикой, без нее документ теряет смысл
- Edge cases и acceptance criteria пропускают чаще всего — и именно они всплывают как проблемы в середине разработки
- ИИ сокращает время написания PRD с 8-16 часов до 2-3 часов — но только если давать реальные данные а не общие формулировки
- Делайте структуру модульной чтобы обновлять секции независимо и держать документ актуальный в процессе разработки продукта
- Хороший PRD это тот который команда открывает в процессе работы а не после запуска
В чем разница между PRD, BRD и что писать продакту
PRD документ продакта
Хороший PRD читается за 10-15 минут и после этого у любого участника команды не остается открытых вопросов о том, что и зачем строим.
BRD документ бизнеса
В стартапах и продуктовых компаниях BRD почти не используют — его функцию берет на себя PRD с расширенным разделом про бизнес-контекст.
Документ разработки
Граница простая: PRD отвечает на вопрос что и зачем, техническая спецификация — на вопрос как.
User Story как минимальная единица требований
«Как [роль] я хочу [действие], чтобы [результат]».
Пользовательские истории живут внутри PRD или в Jira как задачи для разработки. Они не заменяют PRD, а конкретизируют его на уровне отдельных сценариев.
PRD — это контекст и стратегия. User story — тактика и конкретное действие пользователя внутри продукта.
PR/FAQ — формат для новых продуктов
PR/FAQ особенно полезен при запуске MVP или совершенно нового направления, когда нужно определять ценность продукта до написания требований.
Продакту не нужно знать все форматы наизусть. Нужно понимать один принцип: выбирайте формат под аудиторию и задачу, а не потому что так принято в компании.
Когда писать короткий PRD, а когда полный
Lenny Rachitsky, автор Lenny's Newsletter: «Лучший PRD — тот который команда реально читает. Это означает короткий, конкретный и написанный для людей а не для процесса.»
Когда достаточно одной страницы
Типичный 1-pager включает четыре блока: проблема в одном абзаце, предлагаемое решение, основными функциями и метрики успеха. Все это на одной странице. Такой формат читают за три минуты и сразу идут делать. Именно поэтому его используют Intercom и Notion для большинства продуктовых задач внутри зрелых продуктов.
«Полное погружение в продакт-менеджмент»
Полный PRD: когда нужна детализация
Полный документ на 5-15 страниц с подробным описанием всех секций. Figma и Product Hunt используют именно такой формат для крупных проектов с несколькими командами.
← прокрутите таблицу →
| Формат 1-pager Быстро, чётко, по делу | Формат Полный PRD Подробно, со всеми деталями | |
|---|---|---|
| Размер команды | 2–5 человек | 5+ человек, несколько команд |
| Тип задачи | Доработка существующей фичи | Новый продукт или крупная фича |
| Время на написание | 1–2 часа | 8–16 часов (2–3 ч с ИИ) |
| Детализация | Проблема, решение, метрики | Все секции, включая edge cases |
| Примеры компаний | Intercom Notion | Figma Product Hunt Amazon |
| Agile-контекст | Уровень задачи в спринте | Уровень эпика или нового направления |
| Инструмент | Google Docs Notion | Confluence Coda Notion |
| Согласование | Асинхронно в комментариях | Синхронная встреча + асинхронный review |
Как контекст меняет формат
В корпорации контекст распределен между командами, часть участников процессе разработки продукта вообще не знает деталей смежных проектов. Здесь полный PRD — это не бюрократия, а инструмент масштабируемости и согласования между командами. Atlassian и крупные продуктовые компании используют Confluence именно для хранения и обновления таких документов.
Agile и PRD: как совместить
Хороший PRD в agile — это не фиксация всех решений заранее. Это фиксация проблемы, контекста и метрик, внутри которых команда может итерировать свободно.
Выбор формата — это продуктовое решение, как и любое другое. Начните с минимального формата и добавляйте детализацию только там, где ее отсутствие создает реальный риск для команды.
Что должно быть в каждом разделе PRD
Разбираем каждую секцию PRD с конкретным примером. Продукт — мобильное приложение для управления задачами, задача — переработать онбординг.
Это самый критичный раздел всего документа. Большинство продактов пишут здесь решение, замаскированное под проблему. «Нам нужно добавить push-уведомления» — это не проблема, это решение.
«62% новых пользователей уходят на экране регистрации, не завершив онбординг. Day 1 retention составляет 21% при среднем по рынку 35%. Пользователь не видит ценность продукта до того, как его попросили заполнить восемь полей профиля.»
Хороший problem statement включает три элемента: контекст и цели пользователя, конкретную метрику которая показывает масштаб проблемы, и объяснение почему это важно решить именно сейчас. Без цифр любые обоснования выглядят как догадки.
Проверочный вопрос: если прочитать только problem statement, понятно ли какие проблемы решаем и насколько они серьёзны?
Этот раздел нужно определять максимально конкретно. Не «молодые люди 18–35 лет», а портрет реального человека с реальной задачей.
«Менеджер проектов в компании от 20 человек, который впервые устанавливает приложение после рекомендации коллеги. Его задача: за три минуты понять, может ли продукт заменить текущий инструмент. Если за это время он не увидел ценность — удаляет приложение.»
Jobs-to-be-Done описывает пользовательскую потребность, а не функцию продукта: «быстро оценить инструмент без лишних шагов», «сохранить прогресс и вернуться позже». Это помогает команде понимать пользователей на уровне мотивации, а не только поведения.
Здесь продакт описывает решение на уровне пользовательского опыта, не вдаваясь в технические детали реализации.
«Переработать онбординг по принципу "ценность до регистрации": пользователь сразу попадает в интерактивное демо с тестовыми задачами. Регистрация запрашивается только после первого целевого действия — создания задачи с назначенным исполнителем. Ключевые функции: интерактивное демо из трёх шагов, отложенная регистрация, автозаполнение профиля через Google OAuth.»
Подробное описание решения всегда включает явное указание Out of Scope — это не список отказов, а защита команды от scope creep.
Пользовательские истории структурируют требования в формате: «Как [роль] я хочу [действие] чтобы [результат]». Это стандарт для agile-команд который помогает держать фокус на пользователе.
«Как новый пользователь я хочу попробовать продукт до регистрации, чтобы понять подходит ли он мне.»
«Дано что пользователь открыл приложение впервые — когда он нажимает "Попробовать" — тогда он видит интерактивное демо без запроса email или пароля. Дано что пользователь завершил демо и зарегистрировался — тогда тестовые задачи из демо сохранены в его аккаунте.»
Без acceptance criteria каждая задача превращается в источник разногласий на review. Именно здесь продакт и разработчик договариваются о том, что значит «готово».
Этот раздел пишется совместно с разработкой. Продакт обозначает известные технические ограничения и зависимости от других команд.
«Новый онбординг должен бесшовно интегрироваться с существующей системой аутентификации. Зависимость от команды платформы: нужно API для временной сессии без регистрации. Ограничения: время загрузки первого экрана не более 2 секунд на 4G. Fallback на email-регистрацию если Google OAuth недоступен.»
Зависимости нужно фиксировать до начала разработки. Блокер, обнаруженный в середине спринта, стоит дороже, чем час на заполнение этого раздела.
Это раздел, который систематически пропускают даже опытные продакты — и именно он потом всплывает как недоделка на этапе тестирования.
Пользователь закрыл приложение в середине демо → при повторном открытии видит предложение продолжить с того места.
Пользователь уже зарегистрирован и попал на онбординг по старой ссылке → редирект в основное приложение без повторного прохождения.
Google OAuth недоступен → показываем форму регистрации с email.
Простой способ не пропускать: пройти флоу продукта и задать вопрос «что может пойти не так на каждом шаге».
Раздел без которого PRD теряет смысл. Целевые показатели должны быть конкретными — без порогов команда не сможет измерять успех.
Activation rate: с 38% до 60% за 60 дней после запуска.
Day 1 retention: с 21% до 30%.
Время до первого целевого действия: с 4 минут до 90 секунд.
Day 7 retention не ниже текущих 14%.
Оценка в сторах не ниже 4.2.
Именно здесь появляется связь с бизнес-целями: как показатели успеха фичи влияют на конверсии и retention продукта в целом.
Как написать PRD с помощью ИИ и поддерживать его производительность актуальным
ИИ не заменяет продуктовое мышление. Но он кратно сокращает механическую работу и помогает избежать типичных ошибок которые продакты допускают при написании требований.
Что ИИ делает хорошо
- Структурирование информации — ИИ быстро превращает разрозненные заметки со встречи в связный problem statement.
- Формулировка acceptance criteria — один из самых трудоемких разделов пишется за минуты если дать правильный контекст.
- Генерация edge cases — ИИ системно перебирает нетипичные сценарии шаблонов, которые продакт пропускает из-за когнитивной нагрузки.
- Описание error states — то что обычно остается за пределами документа теперь можно прописать за один промпт.
Что ИИ делает плохо
- Если написать в промпте «высокий churn», ИИ сгенерирует generic текст без конкретных пороговых значений.
- Если написать «23% churn по данным exit survey за Q3», получите качественный output с конкретными целевыми показателями. Правило простое: давайте реальные данные, получаете реальный документ
- Потребности пользователей, инсайты из интервью, стратегическое соответствие бизнес-целям — все это должен принести продакт.
Промпты для каждой секции PRD
Acceptance Criteria: «Напиши acceptance criteria в формате "дано — когда — тогда" для следующей user story: [вставить story]. Включи три сценария: happy path, edge case и error state.»
Edge Cases: «Перечислить все edge cases для следующего флоу: [описание флоу]. Максимум 3 слова на каждый сценарий, затем подробное описание что происходит и как продукт должен реагировать.»
Success Metrics: «Напиши раздел success metrics для PRD. Первичная цель: [метрика и текущее значение]. Бизнес-контекст: [как связано с целями продукта]. Формат: первичные метрики с конкретными целевыми показателями, guardrail-метрики, операционные метрики.»
Как поддерживать ваш PRD актуальным
В процессе разработки продукта PRD должен оставаться актуальный инструмент а не исторический артефакт. Для этого достаточно трех правил. Первое: любое решение принятое на встрече фиксируется в документе в тот же день. Второе: при появления новой информации — данных из тестирования, обратной связи от разработки, изменения приоритетов — обновляется конкретная секция а не весь документ. Третье: PRD считается живым до момента запуска фичи, после — архивируется со статусом и ссылкой на результаты.
Хороший PRD это документ который команда открывает в процессе разработки продукта а не после. ИИ помогает создавать такие документы быстрее — но только если продакт приносит реальный контекст, данные и понимание пользователей.
Ваш PRD
Заключение
- Возьмите ближайшую задачу и напишите к ней хотя бы 1-pager. Не идеальный, не по всем правилам — просто problem statement с метрикой, решение и acceptance criteria. Это уже лучше чем задача в Jira без контекста.
- Добавьте в свой следующий PRD раздел Edge Cases. Пройдите флоу продукта и задайте вопрос «что может пойти не так на каждом шаге». Этот раздел занимает 20 минут но экономит несколько итераций на тестировании.
- Попробуйте написать один раздел с помощью ИИ. Возьмите реальные данные из аналитики или пользовательских интервью, вставьте в промпт из этой статьи и посмотрите на результат. Первый раз будет непривычно, второй раз — быстро.
«Полное погружение в продакт-менеджмент»
Часто задаваемые вопросы
Больше статей по теме
на все вопросы.