PRD: как писать документ о целях продукта, который работает

Я видел эту историю много раз. Команда запускает фичу — никто не пользуется. Разработчики сделали всё правильно, точно по ТЗ. Продукт работает. Но пользователи не приходят.

Смотришь на исходное задание — 47-страничный документ с детальным описанием каждого экрана, каждого поля формы, каждого состояния кнопки. Ни слова о том, зачем это нужно пользователю.

Это не ТЗ. Это — инструкция по сборке мебели для квартиры, которую ещё не решили покупать.

Своя версия этой проблемы у меня появилась ещё в 2012-м. Я тогда вёл несколько коммерческих проектов и раз за разом сталкивался с одним и тем же: клиент приходит с требованиями, мы делаем точно по ним — а потом оказывается, что он хотел совсем другого результата. Не другой интерфейс, не другие кнопки — другой результат.

Тогда я придумал для себя документ и назвал его просто "план проекта". Внешне — ничего особенного, несколько страниц. Но в отличие от ТЗ он начинался не с экранов и не с функций. Он начинался с вопроса: зачем мы это делаем? Какую проблему решаем? Что изменится для пользователя после запуска? По каким признакам поймём, что добились результата?

Я внедрил этот документ почти во всех коммерческих проектах, которые вёл в тот период. Это не было PRD — я тогда и термина такого не знал. Но логика была та же: сначала проблема и цель, и только потом — детали реализации.

Прошло больше десяти лет. Термин PRD усвоен, добавлены структура и метрики, изучено как это устроено в Amazon и Google. Но суть осталась той же, что в 2012-м: документ должен отвечать на вопрос зачем, а не описывать что и как.

PRD (Product Requirements Document) — один из самых недопонятых инструментов в индустрии. Его либо не пишут вообще ("мы agile, у нас всё в Jira"), либо пишут так, что документ превращается в артефакт прошлого уже к концу первого спринта. За 15 лет я видел оба крайних случая. И выработал подход, который работает в реальных командах.

TL;DR: для тех, кому некогда

Что такое PRD на самом деле: Документ, который отвечает на вопросы "зачем", "для кого" и "как поймём, что добились цели" — а не "что именно делать".

Почему большинство PRD не работают:

• Написаны как контракт, а не как живой инструмент выравнивания
• Содержат требования ("система должна..."), но не содержат проблемы
• Нет метрик успеха — нельзя понять, достигли цели или нет
• Написаны PM-ом для PM-а, разработчики не понимают контекст

Что должно быть в хорошем PRD:

1. Problem Statement — проблема, которую решаем
2. Why Now — почему сейчас, а не через год
3. Target Users — конкретные люди, не "B2B сегмент"
4. Цели и не-цели — что делаем и, важнее, что не делаем
5. Success Metrics — числа, по которым поймём успех
6. Functional Requirements — что должен уметь продукт
7. Out of Scope — явный список того, чего не будет
8. Risks & Dependencies — что может пойти не так
9. Open Questions — честный список неотвеченных вопросов

Когда PRD нужен: фича крупнее 2 недель разработки, новый продукт, изменение бизнес-логики. Мелкие баги и очевидные улучшения — не нужен.

Что такое PRD и чем он не является

PRD расшифровывается как Product Requirements Document — документ о требованиях к продукту. Но это вводящее в заблуждение название, потому что акцент на "requirements" смещает фокус не туда.

Хороший PRD — это не список требований. Это документ о проблеме и цели.

Разница принципиальная:

Первый тип документа говорит разработчику что делать. Хороший PRD говорит зачем — и даёт команде свободу найти лучшее решение.

Чем PRD отличается от других документов

Я постоянно вижу путаницу между PRD и смежными артефактами:

PRD vs ТЗ (техническое задание): ТЗ — это контракт с деталями реализации, юридический документ. PRD — это внутренний инструмент выравнивания команды. ТЗ отвечает на "как делать", PRD — на "зачем и что считать успехом".

PRD vs Roadmap: Roadmap — это план на будущее, приоритизированный список. PRD — это глубокое описание одной инициативы. Roadmap говорит "что и когда", PRD говорит "почему именно это".

PRD vs User Story: User Story — это минимальная единица работы ("Как пользователь, я хочу..."). PRD — это контекст для целого набора user stories, объясняющий большую картину.

PRD vs Design Brief: Design Brief фокусируется на пользовательском опыте и визуальном языке. PRD шире — включает бизнес-контекст, метрики, технические ограничения.

Где заканчивается PRD и начинается техническое проектирование

В стартапе без выделенного Product Manager границы стираются. PRD часто берёт на себя функции и бэклога, и ТЗ одновременно. Главный критерий: если документ начинает диктовать разработчикам как писать код — выбор стека, конкретные библиотеки, названия классов, схемы БД — вы свернули не туда.

PRD заканчивается там, где начинается технический дизайн. Граница проходит через вопрос:

• PRD: Что должен уметь пользователь? Как поймём успех?
• Technical Design Document / ADR: Как это реализовать технически?

Если ваш PRD содержит строчки вроде «использовать Redis для кэширования» или «таблица user_sessions в PostgreSQL» — это уже TDD, а не PRD. Перенесите в технический документ, иначе смешение форматов запутает обе аудитории.

Почему большинство PRD теряют ценность

«90% PRD превращаются в мусор» — хорошая провокация для заголовка. Но точнее: большинство PRD теряют ценность уже на второй неделе после написания. Не потому что их авторы некомпетентны. А потому что документы пишутся как контракт, а не как инструмент выравнивания. Я сам совершал эти ошибки.

Ошибка 1: PRD как исполнительный документ

Самая частая патология — PRD написан после того, как решение уже принято. Фаундер или PM уже знает, что хочет построить, и пишет PRD как обоснование этого решения задним числом.

В результате проблема не ищется — она конструируется под готовое решение. Это называется "решение в поисках проблемы", и это рецепт провала.

Как выглядит симптом: PRD начинается с "мы хотим сделать..." вместо "пользователи сталкиваются с..."

Ошибка 2: Требования без метрик успеха

"Ускорить загрузку страницы" — это не цель. "Снизить время загрузки главной страницы с 4.2 до 1.5 секунд, что должно увеличить конверсию с 2.1% до 2.8%" — это цель.

Без конкретных метрик невозможно:

• Определить, когда задача выполнена
• Расставить приоритеты между компромиссами
• Оценить успех после запуска

Как выглядит симптом: В разделе "цели" — прилагательные (быстрее, удобнее, лучше) без чисел.

Ошибка 3: Раздел «не-цели» — запоздалая мысль

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

Когда явно написано "интеграция с мобильным приложением — вне рамок v1", у руководителя нет аргументов добавить её "пока вы всё равно там".

Как выглядит симптом: Раздел «не-цели» отсутствует или написан формально ("мы не будем делать всё подряд").

Ошибка 4: PRD без целевого пользователя

"B2B клиенты" — это не пользователь. "Бухгалтер Мария, 42 года, работает в компании 200+ человек, ежемесячно закрывает период в системе 1С, ненавидит, когда данные приходится вводить дважды" — вот это пользователь.

Без конкретики команда строит для абстрактного "среднего пользователя", который не существует.

Как выглядит симптом: Раздел "пользователи" — это сегмент рынка, а не живые люди с конкретными болями.

Ошибка 5: PRD как Waterfall-артефакт

Написали в начале — читать перестали через неделю. Изменилось что-то в процессе — PRD не обновили. Через месяц это исторический документ, но не живой инструмент.

Как выглядит симптом: Последнее изменение PRD — дата его первоначального создания.

Моя методология: PRD как инструмент выравнивания

После многих лет экспериментов я пришёл к следующему принципу: PRD — это не документ о продукте. PRD — это инструмент выравнивания команды.

Цель PRD — убедиться, что все: разработчики, дизайнеры, маркетинг, продажи, руководство — понимают одно и то же. Не одинаково думают (это невозможно), а одинаково понимают проблему и критерии успеха.

Принцип Amazon: начни с пресс-релиза

Amazon использует подход "Working Backwards" — прежде чем писать требования, нужно написать пресс-релиз о запуске продукта, которого ещё не существует. Что написала бы пресса? Чем это важно для пользователей? Какие вопросы они задали бы на пресс-конференции?

Это упражнение заставляет думать о результате, а не о процессе. Если не можешь написать убедительный пресс-релиз — значит, цель ещё не сформулирована.

Я использую упрощённую версию: перед написанием PRD нужно написать один абзац — что изменится в жизни пользователя после того, как мы это запустим. Не "что мы сделаем", а "что станет иначе для них".

Принцип "Проблема важнее решения"

Хороший PRD описывает проблему настолько хорошо, что правильное решение становится очевидным. Плохой PRD описывает решение и оставляет команду гадать о проблеме.

На практике это означает: раздел Problem Statement должен быть написан так, чтобы разработчик, который никогда не видел продукт, понял боль пользователя.

Если разработчик читает PRD и не понимает, кому больно и как именно — PRD не выполняет свою задачу.

Принцип живого документа

PRD должен обновляться при каждом значимом изменении. Не "по итогам спринта", а когда что-то меняется. Это означает:

• Версионирование (v1.0, v1.1, v2.0)
• История изменений в начале документа — кто и что изменил
• Статус документа (Черновик / На проверке / Утверждён / Устарел)
• Ответственный — конкретный человек, который следит за актуальностью

Когда PRD умирает

У каждого документа есть жизненный цикл. PRD умирает, когда последняя задача, созданная на его основе, переходит в статус Done. В этот момент у документа два пути.

Архивирование. Статус меняется на Выпущен, документ сохраняется как исторический артефакт. Полезен при разборе инцидентов ("почему мы так сделали?") и при онбординге новых людей в команду.

Миграция в базу знаний. Если фича стала фундаментальной частью продукта, ключевые разделы (Problem, Goals, Metrics) переносятся в продуктовую документацию как "история принятия решений". Это честнее, чем хранить живой PRD для мёртвой инициативы.

Что точно не нужно — оставлять PRD в статусе Утверждён спустя полгода после запуска. Устаревший документ с актуальным статусом — это активная дезинформация для команды.

Структура идеального PRD

Вот структура, которую я использую в реальных проектах. Не все секции нужны для каждой инициативы — адаптируйте под задачу.

1. Header (шапка)

Документ: PRD — [Название инициативы]
Статус: Черновик / На проверке / Утверждён
Версия: 1.0
Ответственный: Имя Фамилия
Дата создания: ДД.ММ.ГГГГ
Последнее обновление: ДД.ММ.ГГГГ
Заинтересованные стороны: @разработка, @дизайн, @маркетинг

Шапка — это паспорт документа. По ней сразу видно: актуален ли документ, кто за него отвечает, нужно ли его согласование.

2. Executive Summary (резюме)

Три-пять предложений, которые дают полное понимание инициативы. Пишется последним, после того как весь документ готов.

Формат: Мы видим [проблема]. Это влияет на [кто] и стоит [масштаб]. Мы предлагаем [решение], что должно привести к [результат].

Пример:

Пользователи бросают форму онбординга на шаге верификации email — 68% drop-off, что стоит нам ~$120K/мес в недополученной выручке. Мы упрощаем верификацию, добавляя опцию "продолжить без верификации" с доступом к ограниченному функционалу. Цель — снизить drop-off до 35% и увеличить количество активированных аккаунтов на 40%.

3. Problem Statement (формулировка проблемы)

Это сердце PRD. Здесь нужно ответить на три вопроса:

Что происходит сейчас? Описывайте текущую реальность конкретно: с числами, примерами, цитатами пользователей.

Почему это проблема? Какой вред это наносит: пользователям, бизнесу, команде? Квантифицируйте всё, что можно.

Что происходит, если мы ничего не делаем? Это важный вопрос. Иногда ответ "ничего страшного" — и тогда инициативу стоит отложить.

Плохой пример:

Пользователи жалуются на медленную загрузку. Нужно ускорить.

Хороший пример:

Главная страница загружается за 4.2 секунды при медленном 3G (P75). По данным Google, каждые 100ms задержки снижают конверсию на 1%. Наша конверсия с лендинга — 2.1%, что ниже среднего по индустрии (3.8%). Heatmap показывает, что 43% пользователей покидают страницу до полной загрузки. При текущем трафике 50K/мес это ~21K потерянных пользователей, из которых ~420 могли бы конвертироваться.

4. Why Now (почему сейчас)

Этот раздел часто пропускают — и зря. Почему нужно делать именно сейчас, а не через квартал? Что изменилось?

Возможные причины:

• Изменения в рыночной ситуации
• Новый конкурент запустил аналогичную фичу
• Данные показывают нарастающую проблему
• Технический долг блокирует другие инициативы
• Регуляторные изменения

Пример:

Google меняет алгоритм ранжирования с марта 2026, добавляя Core Web Vitals в quality signals. Наш текущий LCP 4.2s грозит потерей 15-20% органического трафика. Конкурент уже провёл оптимизацию (LCP 1.1s). Делать это позже — значит восстанавливать позиции, а не защищать их.

5. Target Users (целевые пользователи)

Конкретные люди, не сегменты. Используйте один из форматов:

Персонажи:

Алексей, 34 года, Head of Marketing в B2B SaaS. Работает с дашбордом каждый день, строит отчёты для совета директоров. Ненавидит, когда данные "не сходятся". Часто открывает продукт с мобильного телефона во время встреч.

Jobs-to-be-done:

Когда я готовлю ежемесячный отчёт [ситуация], я хочу быстро собрать все нужные метрики в один документ [мотивация], чтобы не тратить 3 часа на ручной сбор данных [ожидаемый результат].

Опишите 1-3 основных пользователей для данной инициативы. Не всех пользователей продукта — только тех, на кого направлена эта фича.

6. Цели и не-цели

Цели — конкретные, измеримые результаты, которых хотим достичь.

Формат: [Метрика] изменится с [текущее значение] до [целевое значение] за [период].

Пример:

• Drop-off на шаге верификации: 68% → 35% за 30 дней после запуска
• Количество активированных аккаунтов: +40% относительно исходного уровня
• Время до первого "aha-moment": с 3 дней до 1 дня

Не-цели — явный список того, что НЕ входит в эту инициативу. Это защита от расползания рамок.

Пример:

• Редизайн всего онбординга — только шаг верификации
• Интеграция с социальными сетями — отдельная инициатива Q3
• Изменение структуры тарифов — решение на уровне бизнеса, не продукта

7. Success Metrics (метрики успеха)

Как вы поймёте, что инициатива удалась? Нужен ответ до начала разработки, а не после.

Хорошие метрики: конкретные, измеримые, достижимые за разумный период.

Используйте три уровня:

Основная метрика: Одна метрика, которая важнее всего. Если она не достигнута — инициатива не удалась.

Вторичные метрики: 2-4 метрики, которые дают дополнительный контекст.

Ограничительные метрики: Что не должно ухудшиться. Например: "скорость загрузки не должна вырасти выше текущего уровня".

Пример:

Основная: Конверсия в активированный аккаунт за 7 дней: ≥ 45% (сейчас 27%)

Вторичные:
- Drop-off на шаге верификации: ≤ 35% (сейчас 68%)
- Время до первого касания с ценностью: ≤ 1 день (сейчас 3 дня)
- NPS онбординга: ≥ 40 (сейчас 28)

Ограничительные:
- Уровень spam-регистраций: не выше текущих 3%
- Нагрузка на SMTP: не выше 120% от текущей

8. Functional Requirements (функциональные требования)

Что должен уметь продукт? Описывайте с точки зрения пользователя, не технической реализации.

Используйте приоритизацию MoSCoW:

• Обязательно (Must Have) — без этого продукт не работает
• Желательно (Should Have) — важно, но можно запустить без этого
• По возможности (Could Have) — приятно иметь, добавим если будет время
• Не делаем (Won't Have) — явно исключаем из этой версии

Пример:

Обязательно:
- Пользователь может зарегистрироваться и попасть в продукт без верификации email
- Непроверифицированный пользователь видит ограниченный функционал с явным индикатором
- Напоминание о верификации отправляется через 24 часа и 72 часа

Желательно:
- Верификация доступна в 1 клик из продукта (не нужно искать письмо)
- Индикатор прогресса онбординга помогает понять следующий шаг

По возможности:
- Верификация через SMS вместо email
- Чеклист онбординга в боковой панели

Не делаем (v1):
- SSO через Google/GitHub
- Автоматическое заполнение профиля из соцсетей

9. Non-Functional Requirements (нефункциональные требования)

То, что не видно пользователю, но критично для продукта:

• Производительность: время загрузки, количество запросов, лимиты
• Масштабируемость: на какой объём рассчитываем
• Безопасность: требования к данным, соответствие регуляторике
• Доступность: SLA, uptime, деградация при сбоях
• Совместимость: браузеры, устройства, версии API

Пример:

- Время до первого интерактивного элемента (TTI): ≤ 2 секунды на 3G
- Поддержка браузеров: Chrome 100+, Firefox 100+, Safari 15+, Edge 100+
- GDPR: данные пользователей без верификации не передаются третьим сторонам
- Graceful degradation: если SMTP недоступен, регистрация продолжается

10. User Journey (путь пользователя)

Описание ключевых сценариев использования — не с точки зрения экранов, а с точки зрения пользовательского опыта.

Пример:

Основной сценарий: Регистрация без верификации

1. Пользователь заполняет форму регистрации (email + пароль)
2. Нажимает "Создать аккаунт"
3. Видит экран: "Аккаунт создан. Проверьте email для полного доступа."
4. Кнопка "Начать с ограниченным доступом" → попадает в продукт
5. В интерфейсе — баннер "Верифицируйте email, чтобы разблокировать всё"
6. Через 24 часа — email-напоминание с одним кликом для верификации

11. Dependencies & Risks (зависимости и риски)

Что нужно от других команд, систем, сервисов? Что может пойти не так?

Dependencies:

- Email-сервис (Sendgrid): нужен новый шаблон письма и изменение логики отправки
- Auth-сервис: нужно добавить флаг "email_verified" в JWT-токен
- Дизайн: нужны макеты экрана "ограниченный доступ" до начала разработки

Risks:

12. Вне рамок

Отличается от «не-целей» тем, что это не "отложенные хорошие идеи", а вещи, которые не будут сделаны в рамках этой инициативы никогда (или передаются в другую команду).

Пример:

- Полный редизайн страниц онбординга — в компетенции Growth team
- Изменение бизнес-правил для trial-периода — решение CEO
- Интеграция с CRM для автоматизации follow-up — Q3 roadmap

13. Open Questions (открытые вопросы)

Честный список вещей, которые ещё не решены. Это не слабость документа — это честность. Скрытые вопросы превращаются в неожиданные проблемы в середине разработки.

[ ] Что происходит с аккаунтом если email не верифицирован 30 дней?
    Ответственный: @product, срок: 25.02.2026

[ ] Нужно ли согласование с юридическим отделом для изменения условий регистрации?
    Ответственный: @legal, срок: 01.03.2026

[ ] Как это повлияет на существующих пользователей которые уже в продукте?
    Ответственный: @engineering, срок: в ходе разработки

Готовый шаблон PRD

Вот шаблон, который можно взять и использовать прямо сейчас. Адаптируйте под размер команды и сложность задачи.

# PRD: [Название инициативы]
 
**Статус:** Черновик / На проверке / Утверждён / Устарел
**Версия:** 1.0
**Ответственный:** [Имя]
**Дата создания:** ДД.ММ.ГГГГ
**Последнее обновление:** ДД.ММ.ГГГГ
**Заинтересованные стороны:** @team1, @team2
 
---
 
## История изменений
 
| Версия | Дата       | Автор | Изменения               |
| ------ | ---------- | ----- | ----------------------- |
| 1.0    | ДД.ММ.ГГГГ | [Имя] | Первоначальный черновик |
 
---
 
## Краткое резюме
 
[3-5 предложений: проблема → кто страдает → масштаб → решение → ожидаемый результат]
 
---
 
## Постановка проблемы
 
### Текущая ситуация
 
[Что происходит сейчас? С данными и примерами.]
 
### Почему это проблема
 
[Вред для пользователей и бизнеса. Числа, цитаты, примеры.]
 
### Что будет если не делать
 
[Последствия бездействия. Иногда ответ — "ничего" и это нормально.]
 
---
 
## Почему сейчас
 
[Почему эта инициатива приоритетна именно сейчас? Что изменилось?]
 
---
 
## Целевые пользователи
 
### Основной пользователь
 
**[Имя персонажа]**, [должность], [возраст]
[2-3 предложения о контексте и боли]
 
**Работа, которую нужно выполнить (Jobs-to-be-done):**
Когда [ситуация], я хочу [действие], чтобы [результат].
 
### Вторичный пользователь (если есть)
 
[Аналогично]
 
---
 
## Цели
 
### Что считаем успехом
 
| Метрика               | Сейчас             | Цель   | Период |
| --------------------- | ------------------ | ------ | ------ |
| [Основная метрика]    | [исходный уровень] | [цель] | [срок] |
| [Вторичная метрика 1] |                    |        |        |
| [Вторичная метрика 2] |                    |        |        |
 
### Ограничительные метрики (что не должно ухудшиться)
 
- [Метрика]: не хуже [порог]
 
---
 
## Не-цели
 
- ~~[Что мы явно не делаем]~~ — [краткое объяснение или ссылка]
- ~~[Что мы явно не делаем]~~ — отдельная инициатива / другая команда
 
---
 
## Функциональные требования
 
### Обязательно
 
- [ ] [Требование с точки зрения пользователя]
 
### Желательно
 
- [ ] [Требование]
 
### По возможности
 
- [ ] [Требование]
 
### Не делаем (v1)
 
- [Что явно исключаем из этой версии]
 
---
 
## Нефункциональные требования
 
- **Производительность:** [конкретные требования]
- **Масштабируемость:** [на что рассчитываем]
- **Безопасность:** [требования]
- **Совместимость:** [браузеры, устройства, платформы]
- **Доступность:** [SLA, uptime, деградация]
 
---
 
## Путь пользователя
 
### [Название основного сценария]
 
1. [Шаг]
2. [Шаг]
3. [Шаг]
 
### [Название альтернативного сценария]
 
1. [Шаг]
 
---
 
## Зависимости
 
| Зависимость   | Команда/Сервис  | Что нужно    | Срок       |
| ------------- | --------------- | ------------ | ---------- |
| [Зависимость] | [Ответственный] | [Что именно] | ДД.ММ.ГГГГ |
 
---
 
## Риски
 
Разбивайте риски по категориям — это помогает ничего не пропустить.
 
| Риск                                                       | Вероятность            | Влияние                | Как снижаем                         |
| ---------------------------------------------------------- | ---------------------- | ---------------------- | ----------------------------------- |
| **Технические риски**                                      |                        |                        |                                     |
| [Технический риск]                                         | Высокая/Средняя/Низкая | Высокое/Среднее/Низкое | [Как снижаем]                       |
| **Продуктовые риски**                                      |                        |                        |                                     |
| Неверная гипотеза: [предположение] оказывается ложным      | Средняя                | Высокое                | [Как проверим до разработки]        |
| Каннибализация: новая фича убивает [существующий сценарий] | Низкая                 | Среднее                | [Как отслеживаем]                   |
| **Рыночные риски**                                         |                        |                        |                                     |
| Конкурент запускает аналог до нашего запуска               | Низкая                 | Среднее                | [Ускорение / изменение приоритетов] |
| **Операционные риски**                                     |                        |                        |                                     |
| [Зависимость от внешней команды / сервиса]                 | Средняя                | Высокое                | [Как снижаем]                       |
 
---
 
## Вне рамок
 
- [Что явно вне этой инициативы — передаётся другой команде или не делается]
 
---
 
## Открытые вопросы
 
- [ ] [Вопрос] — Ответственный: [@имя], срок: [дата]
- [ ] [Вопрос] — Ответственный: [@имя], срок: [дата]
 
---
 
## Приложение (опционально)
 
- Ссылки на исследования
- Данные аналитики
- Предыдущие итерации
- Конкурентный анализ

Как PRD вписывается в процесс

PRD — не просто документ, который пишется один раз. Это живой артефакт, который существует на протяжении всего жизненного цикла инициативы.

Когда писать PRD

PRD нужен не для каждой задачи. Мои критерии:

PRD нужен если:

• Фича крупнее 2 недель разработки
• Затрагивает несколько команд
• Меняет бизнес-логику или пользовательский флоу
• Есть неопределённость в требованиях
• Нужно согласование с заинтересованными сторонами

PRD не нужен если:

• Очевидный баг-фикс
• Мелкие UI-улучшения в рамках существующего дизайна
• Задача для одного разработчика на 1-2 дня
• Техническое улучшение без изменения пользовательского опыта

Кто пишет PRD

Классический ответ — Product Manager. Но в реальных компаниях, особенно ранних стартапах, PRD может и должен писать тот, кто лучше всего понимает проблему. Это может быть:

• CEO/Co-founder — для стратегических инициатив
• CTO — для технических продуктов, где пользователи — разработчики
• Tech Lead — для инициатив, исходящих от engineering
• Customer Success — для фич, выявленных в ходе поддержки
• Команда — для крупных инициатив с несколькими ответственными

Важно одно: у каждого PRD должен быть один ответственный — человек, который несёт ответственность за актуальность документа.

Процесс согласования

1. Черновик — ответственный пишет первую версию, намеренно оставляя открытые вопросы
2. На проверке — ключевые участники дают асинхронный фидбек (1-3 дня)
3. Синхронизация — 30-минутный разбор спорных моментов (только если нужен)
4. Утверждён — документ зафиксирован, разработка может начинаться
5. Обновления — документ обновляется при изменениях, с историей изменений

PRD и Agile

Частое возражение: "Мы работаем по Agile, зачем нам тяжеловесные документы?"

PRD не противоречит Agile. Agile — это про итерации в разработке, а не про отсутствие понимания цели. Хорошо написанный PRD позволяет:

• Команде быть автономной в принятии технических решений
• Владельцу продукта не объяснять контекст на каждой планёрке
• Новым участникам быстро понять суть инициативы
• Заинтересованным сторонам видеть прогресс в контексте цели

Agile манифест говорит "работающий продукт важнее исчерпывающей документации" — это не значит "не нужна никакая документация". Это значит: документация должна помогать создавать продукт, а не быть самоцелью.

Анти-паттерны, которых следует избегать

PRD-as-Waterfall

Симптом: PRD написан на 50 страниц и описывает каждый экран, каждое поле, каждое состояние интерфейса.

Проблема: Такой PRD становится устаревшим сразу после первого пользовательского теста. Команда тратит время на обновление документа вместо создания продукта.

Лечение: PRD описывает проблему и цель. Детали реализации — в дизайн-макетах, пользовательских историях, технических спецификациях.

PRD-as-Contract

Симптом: PRD используется как доказательство в спорах "ты обещал вот это".

Проблема: Команда перестаёт думать о пользователе и начинает думать о "соответствии документу". PRD превращается в юридический инструмент, убивающий инновации.

Лечение: Чётко разделить PRD (внутренний инструмент выравнивания) и ТЗ (контрактный документ для внешних подрядчиков).

PRD-as-Wikipedia

Симптом: В PRD собирается вся информация о продукте, конкурентах, исследованиях, истории решений.

Проблема: Документ становится нечитаемым. Ключевые решения теряются в массиве информации.

Лечение: PRD — это сфокусированный документ о конкретной инициативе. Всё остальное — в приложении или отдельных ссылках.

PRD как продающий документ

Симптом: Документ полон маркетинговых формулировок, оптимистичных прогнозов и красивых слайдов, но в нём нет раздела Risks и нет честных Open Questions.

Проблема: Это происходит, когда PRD пишется не для выравнивания команды, а для "продажи" идеи руководству или инвесторам. Стейкхолдеры утверждают красивую картинку, но команда не понимает реальных ограничений и неизвестных. Через месяц начинаются конфликты: "почему вы не сделали то, что было показано на слайдах?"

Это самый политически заряженный анти-паттерн. Я видел его в компаниях, где культура наказывает за "негатив" и поощряет "можем-сделаем". PRD превращается в корпоративный оптимизм, а реальные риски уходят в неформальные разговоры у кофемашины.

Лечение: Начинайте review PRD не с раздела "Решение", а с разделов "Проблема" и "Метрики успеха". Если стейкхолдер не может сформулировать проблему иначе, как через призму своего готового решения — это красный флаг. Проведите встречу, где единственная цель — синхронизировать понимание проблемы, а не утвердить документ.

Раздел Risks с реальными рисками — это не слабость PRD. Это признак зрелости автора.

PRD без owner-а

Симптом: PRD написан коллективно, у него нет конкретного ответственного.

Проблема: Никто не следит за актуальностью. Вопросы остаются без ответа. Документ устаревает незамеченным.

Лечение: У каждого PRD — один ответственный. Не команда, не роль — конкретный человек с именем.

Как внедрить культуру PRD в команду

Написать хороший PRD — это навык. Внедрить культуру написания PRD в команде — это отдельная работа.

Начните с одного документа. Не пытайтесь ретроспективно писать PRD для всех текущих инициатив. Возьмите одну следующую крупную задачу и напишите PRD по этому шаблону.

Сделайте согласование публичным. Когда команда видит, как PRD обсуждается и улучшается, они понимают его ценность. Асинхронные комментарии в Notion/Confluence лучше закрытых совещаний.

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

Признавайте хорошие PRD. Если документ помог команде принять правильное решение или сэкономил время — скажите об этом вслух. Это создаёт правильные стимулы.

Постепенно повышайте планку. В начале принимайте PRD с пустыми разделами. Постепенно добавляйте требования к качеству. Резкий переход убивает мотивацию.

Вместо заключения

PRD — это не бюрократия и не дань корпоративной культуре. Это инструмент, который при правильном использовании экономит месяцы работы и миллионы рублей.

Три проекта из пяти, в которые я входил как CTO, страдали от одной проблемы: умные люди строили не то. Не потому что они плохо работали. А потому что не было общего понимания: зачем, для кого и как измерим успех.

PRD не решает эту проблему магически. Но он создаёт структуру для разговора, который эту проблему решает.

Начните с малого: возьмите шаблон, напишите PRD для следующей значимой инициативы. Это займёт 2-4 часа. Эти часы вернутся неделями сэкономленного времени команды.

Если у вас остались вопросы о построении продуктовых процессов или вы хотите обсудить конкретную ситуацию — напишите мне. Я помогаю командам выстраивать процессы, которые масштабируются.