Как написать PRD: структура, шаблон и пример

Зачем нужен PRD

PRD — Product Requirements Document. Это документ, в котором продакт описывает, что и зачем мы делаем, для кого, как поймём, что получилось, и где границы фичи.

Без PRD происходит классика: на старте все согласны, через месяц команда сделала «как поняли», а оказывается, имели в виду разное. Дизайнер сделал три экрана, разработка реализовала два с половиной, аналитика подключила метрики, которые отвечают на другой вопрос. PRD — не бюрократия, а способ синхронизировать пять-семь человек, которые иначе расползутся в стороны.

Хороший PRD — короткий. 2–4 страницы максимум. Если получается 12 — это уже спецификация, а не PRD.

Структура PRD

Рабочий каркас:

1. Контекст и проблема.
2. Цель и метрика успеха.
3. Гипотеза.
4. Целевая аудитория.
5. Скоуп — что входит, что не входит.
6. Решение (один абзац + ссылка на дизайн).
7. Юзер-стории / сценарии.
8. Требования (функциональные и нефункциональные).
9. Аналитика — какие события, какие отчёты.
10. Риски и зависимости.
11. План запуска.
12. Открытые вопросы.

В минимальной версии можно оставить пункты 1–6, 9, 12. Остальное появляется по мере уточнения.

Шаблон PRD

# PRD: <название фичи>

Owner: <PM>
Status: draft / in review / approved
Last updated: <YYYY-MM-DD>

## 1. Контекст и проблема
Что болит, почему сейчас, какие данные на руках.

## 2. Цель и метрика успеха
Бизнес-цель + 1–2 числовые метрики (с baseline и целью).

## 3. Гипотеза
Если сделаем X, ожидаем Y, потому что Z.

## 4. Целевая аудитория
Сегмент, размер, поведение.

## 5. Скоуп
В скоупе:
- ...
Не в скоупе:
- ...

## 6. Решение
1–2 абзаца + ссылка на макеты.

## 7. Сценарии
- Юзер делает X → видит Y → получает Z.

## 8. Требования
Функциональные:
- ...
Нефункциональные (производительность, доступность, безопасность):
- ...

## 9. Аналитика
События:
- event_name (какие свойства)
Дашборды:
- ...

## 10. Риски и зависимости
- ...

## 11. План запуска
- Бета на 5%.
- A/B на 50/50.
- Полный rollout.

## 12. Открытые вопросы
- ...

Пример PRD: фича шеринга

Реалистичный пример для приложения для подготовки к собесам.

# PRD: шеринг результата квиза в мессенджеры

Owner: Аня Иванова
Status: in review
Last updated: 2026-04-28

## 1. Контекст и проблема
Виральность приложения низкая: <1% пользователей зовут друзей.
Главная точка восторга — финальный экран квиза с результатом.
Сейчас на этом экране есть только кнопка «Ещё квиз», шеринга нет.
Из 1200 опрошенных пользователей 38% хотели бы поделиться результатом.

## 2. Цель и метрика успеха
Цель: вырастить органический поток через шеринг.
Метрики:
- Доля пользователей, нажавших «Поделиться» на финальном экране — с 0% до 8%.
- Conversion из перехода по шер-ссылке в регистрацию — не ниже 20%.
- Анти-метрика: D7 retention не падает более чем на 1 пп.

## 3. Гипотеза
Если на финальном экране квиза дать кнопку «Поделиться результатом» с
красивой картинкой, пользователи будут шерить, и это даст +5% органики
к onboarding-воронке.

## 4. Целевая аудитория
Пользователи, прошедшие квиз до конца. Сейчас это около 60% всех сессий.

## 5. Скоуп
В скоупе:
- Кнопка «Поделиться» на финальном экране квиза.
- Генерация картинки с результатом (имя пользователя, тема, очки).
- Шеринг в Telegram, WhatsApp, копирование ссылки.
- Лендинг по шер-ссылке с CTA «Попробовать тоже».

Не в скоупе:
- Шеринг в соцсети (VK, Twitter).
- Кастомизация картинки.
- Шеринг промежуточных результатов внутри квиза.

## 6. Решение
На финальном экране показываем preview картинки и три кнопки шеринга.
По клику — нативный share sheet или прямая deep link в мессенджер.
Шер-ссылка ведёт на лендинг с тем же квизом и кнопкой «Начать».

Макеты: <ссылка на Figma>.

## 7. Сценарии
- Пользователь дошёл до финала квиза → видит preview картинки и три кнопки →
  нажимает «Telegram» → открывается чат-выбор → отправляет → возвращается
  в приложение.
- Друг открывает шер-ссылку → видит лендинг с тем же квизом → нажимает
  «Начать» → проходит онбординг → попадает в приложение.

## 8. Требования
Функциональные:
- Картинка генерится на бэкенде, кешируется по user_id+quiz_id.
- Шер-ссылка содержит UTM с источником и referrer_id.
- Лендинг открывается за < 2 сек на 4G.

Нефункциональные:
- Картинка: 1200x630, < 200 КБ.
- Конфиденциальность: имя — только если пользователь явно разрешил.

## 9. Аналитика
События:
- share_button_shown (quiz_id, score)
- share_button_clicked (channel)
- share_landing_opened (referrer_id, utm_source)
- share_landing_cta_clicked

Дашборды:
- Воронка share_shown → click → landing_opened → registered.
- Доля шер-ссылок с регистрацией.

## 10. Риски и зависимости
- Зависимость от команды дизайн-системы (новый компонент картинки).
- Риск: медленная генерация картинки убьёт UX. Митигейт — pre-generate
  на финале квиза, не по клику.

## 11. План запуска
- Бета на iOS 5%, неделя.
- A/B 50/50 на 2 недели.
- Если KR1 закрыт — full rollout. Если нет — итерация по тексту/картинке.

## 12. Открытые вопросы
- Как обрабатывать пользователей без имени?
- Нужно ли разрешение на шеринг в Telegram-боте? (с юристами)

Чек-лист перед отправкой

Перед тем как отправить PRD команде, проверьте:

1. Есть конкретная метрика успеха с baseline и целью.
2. Есть scope, и есть out-of-scope.
3. Указаны риски и зависимости.
4. Аналитика прописана до запуска, а не «придумаем потом».
5. План запуска включает бета или A/B.
6. Открытые вопросы видны, а не замаскированы.

Если хоть один пункт пуст — PRD не готов.

Частые ошибки

• Скоуп без out-of-scope. «В скоупе всё интересное» — гарантированный raasползание.
• Метрика успеха в стиле «улучшить UX». Без числа — не метрика.
• Решение раньше проблемы. PRD начинается с «надо сделать кнопку», а проблемы нет.
• Аналитика в самом конце «допилим потом». Потом не допишут.
• 15 страниц. PRD — не диссертация. Длинный PRD никто не читает.
• Нет ответственного. Owner должен быть один.
• Нет confidence по запуску. Команда не понимает, насколько серьёзна гипотеза.

Связанные темы

• Как поставить OKR для продукта
• Roadmap продукта в формате now/next/later
• Приоритизация продуктового бэклога
• User stories: как писать
• Как считать метрику успеха фичи

FAQ

Сколько страниц должен быть PRD?

2–4 страницы. Если получается 10+, это уже техническая спецификация.

Кто пишет PRD — продакт или дизайнер?

Продакт. Дизайн и инженер вкладываются, но владелец — PM.

Когда обновлять PRD?

До старта разработки — каждый раз, как меняется решение. После старта — фиксируем changelog снизу, не переписываем сверху.

Нужен ли PRD на маленькую фичу?

Да, но в минимальной версии: проблема, метрика, решение, аналитика. Полстраницы.

Где хранить PRD?

В одном месте на всю компанию: Notion, Confluence, Google Docs. Главное — единая база и поиск по ней.

---

Готовьтесь к собесу системно — откройте тренажёр с разборами кейсов, метрик и продуктовых задач.