Product Requirements Document

Что такое PRD

PRD, или Product Requirements Document, — это документ, в котором подробно описана вся функциональность и требования к продукту, который планируется создать. Простыми словами, это инструкция для разработчиков, дизайнеров и тестировщиков, которая отвечает на вопрос: «Что именно мы создаем и зачем?»

Обычно PRD состоит из цели, метрик успеха, целевой аудитории, сценариев, требований, допущений и зависимостей, а также раздела «Что не делаем».

PRD подойдет:

• продакт-менеджерам, которые передают фичу в разработку и хотят, чтобы все участники понимали задачу одинаково;

• тимлидам инженерных команд для оценки сложности и планирования спринтов;

• дизайнерам и аналитикам, чтобы понять контекст до проектирования;

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

PRD поможет:

• обозначить цель, аудиторию и метрики продукта в одном документе;

• развести «что делаем» и «что не делаем», чтобы снизить число споров на код-ревью;

• показать инженерам и дизайнерам ограничения и зависимости до старта работы;

• собрать вопросы и решения в одном пространстве.

Как работать с шаблоном

1. Откройте шаблон PRD в Unidraw. Начните с проблемы и цели. Не описывайте решение — сначала зафиксируйте, какую боль закрываете и какую бизнес- или пользовательскую цель преследуете.

2. Зафиксируйте метрики успеха: конверсию, удержание, выручку, NPS. Важно записать их с текущим и целевым значениями.

3. Опишите целевую аудиторию и сценарии. Кто пользуется фичей, в какой момент, для какой задачи? Выберите один-два конкретных сценария, старайтесь избегать абстракций.

4. Перейдите к требованиям и UX. Что фича делает, какие у нее правила работы и edge cases? Если есть макеты, приложите ссылки.

5. Запишите допущения, зависимости и Out of Scope — список задач, функций или требований, которые команда осознанно решает не делать в текущей версии продукта.

6. Запишите вопросы в открытой форме — они должны начинаться со слов «что», «как» и так далее. Например, кто должен ответить, к какому сроку. Эти вопросы закрывают по ходу работы.

Пример на практике

Руководитель фитнес-приложения составляет план по созданию новой функции — напоминаний о тренировках.

Проблема и цель. Пользователи бросают занятия через две недели, потому что забывают о них. Задача — сделать так, чтобы к концу первого месяца в приложении оставалось 25% пользователей вместо нынешних 18%.

Показатели успеха. Рост числа вернувшихся в приложение через месяц и высокая открываемость уведомлений: на них должны нажимать чаще, чем в 12% случаев.

Целевая аудитория. Новички, которые заполнили анкету при старте, но уже пропустили тренировки.

Пример использования. Марина выбрала график занятий по понедельникам и средам. В среду в 18:30 она получила уведомление на телефон и сразу перешла к тренировке.

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

Что не делаем пока. Систему автоматического подбора времени на основе искусственного интеллекта, интеграцию с личным календарем телефона и СМС-рассылки.

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

Чем отличается от похожих форматов: PRD против технического задания

ТЗ отвечает на вопрос «Как сделать технически?»: какой код написать, какую базу данных настроить. PRD отвечает на вопрос «Что и зачем мы делаем для пользователя?». PRD понятен даже маркетологам, а ТЗ — это скорее документ для инженеров.

Когда не стоит использовать PRD

• Если изменение незначительное: правка текста или баг. Для этого хватит задачи в трекере.

• Если часто меняются требования. На стадии раннего прототипа или продуктового поиска PRD устаревает быстрее, чем его согласуют. Используйте короткий формат: проблема, гипотеза, эксперимент.

Советы по работе с шаблоном в Unidraw

• Начинайте с проблемы, а не с решения. Если первым в PRD появилось «Нужна кнопка «Поделиться»», вернитесь на шаг назад и опишите, зачем она пользователю и бизнесу.

• Заполняйте Out of Scope так же подробно, как требования: «Не делаем веб-версию», «Не поддерживаем iOS 14».

• Ведите историю версий документа. После первой встречи всплывают новые вопросы и меняются требования. Чтобы команда не запуталась, вынесите в шапку дату последнего обновления и коротко записывайте, какие именно правки вы внесли.

Часто задаваемые вопросы

Какого размера должен быть PRD?

PRD должен быть минимально возможного размера, достаточного для запуска разработки. В современной практике Agile идеальный объем — от 1 до 3 страниц текста или экран, который можно проскроллить за 2–3 минуты.

Кто пишет PRD — продакт-менеджер или вся команда?

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