Как правильно делать PRD
PRD помогает синхронизировать команду, сформулировать гипотезу и убедиться, что все понимают, что делаем и зачем.
Хотите прокачать насмотренность? Приходите в Кейс Клуб от редакции - https://t.me/productcasebar/
1. Цель. Объяснение, зачем вообще нужна эта фича, улучшение или продукт. Это не описание задачи, а бизнес- или продуктовая цель. Повысить / сократить / улучшить что-то у кого-то за счёт чего-то. Цель должна быть измеримой. Если цель слишком абстрактная — уточни метрику и пользователя.
Примеры:
- Повысить retention новых пользователей за счёт улучшения onboarding.
- Снизить процент отмен заказов за счёт показа сроков доставки на карточке товара.
2. Проблема. Какая боль или барьер у пользователя мешает достичь цели? Какие сигналы это подтверждают? Пользователь сталкивается с проблемой X, что приводит к Y. Приводи данные, скриншоты, цитаты. Можно добавить ссылку на исследование, кастдев или аналитику.
Примеры:
- Пользователи теряются на втором шаге регистрации и не понимают, что делать дальше — отток 35%.
- Клиенты не видят информации о сроке доставки, отменяют заказ после оформления (12% отказов).
3. Пользовательский сценарий. Как пользователь будет использовать фичу? Где он находится, чего хочет, как будет действовать? Не пиши "пользователь кликает по кнопке" — важно мышление и мотивация, а не действия.
Когда [контекст], пользователь хочет [мотивация], чтобы [цель].
Пример:
- Когда пользователь выбирает доставку, он хочет понимать дату получения, чтобы спланировать своё время и избежать отказа.
4. Требования к функциональности. Что должна уметь система? Какая логика нужна, какие состояния, действия, обработка ошибок и т.д. Что должно быть реализовано?
Условия показа / действия / скрытия? Описывай поведение при разных состояниях (нет данных, ошибка, успех). Можно добавить "Out of scope" — что не входит в задачу.
Пример:
- Показывать срок доставки под кнопкой "Оформить заказ", если пользователь ввёл адрес.
- Если адрес не введён — показывать плашку-заглушку "Введите адрес для оценки срока".
5. Требования к метрикам. Как поймём, что решение сработало?
Пример:
- Основная: CR оформления доставки с 41% до 46%.
- Вторичная: Кол-во заказов с отменами из-за сроков доставки — ↓ на 15%.
6. Оценка влияния. Зачем это команде? Сколько это повлияет на бизнес? Можно ли без этого?
Если мы реализуем фичу, ожидаем эффект X. Если не реализуем — риск Y. Сравнение с альтернативами.
Пример:
- Если добавим срок доставки — минус 12% отказов, плюс +2.5 млн в GMV за квартал.
- Без реализации — удерживаем существующий отток на прежнем уровне.
7. Технические ограничения. Что нужно учесть при реализации — зависимости, риски, ограничения. Проконсультируйся с разработчиками заранее. Не обещай то, что нельзя сделать в MVP.
Пример:
- Данные о сроках доступны только для регионов с DPD.
- Требуется обновление API → задача на backend.
8. Прототип / мокап. Визуальное представление будущего интерфейса. Figma / Miro / Screenshots. Можно добавить user flow. Укажи, какие экраны критичны, а какие — примерные. Покажи, что будет в случае ошибки, пустого состояния и т.д.
____
Хотите прокачать базу по продакт-менеджменту и продуктовой аналитике? Приходите на наши курсы
- Курс по продакт-менеджменту, базовый
- Курс по аналитике, базовый
- Курс по Продуктовой стратегии и защите инициативы
Следите за нашими курсами тут - https://t.me/koloskoveducation/, а все возможности можно посмотреть тут - https://t.me/FreshProductGo/1471
PRD помогает синхронизировать команду, сформулировать гипотезу и убедиться, что все понимают, что делаем и зачем.
Хотите прокачать насмотренность? Приходите в Кейс Клуб от редакции - https://t.me/productcasebar/
1. Цель. Объяснение, зачем вообще нужна эта фича, улучшение или продукт. Это не описание задачи, а бизнес- или продуктовая цель. Повысить / сократить / улучшить что-то у кого-то за счёт чего-то. Цель должна быть измеримой. Если цель слишком абстрактная — уточни метрику и пользователя.
Примеры:
- Повысить retention новых пользователей за счёт улучшения onboarding.
- Снизить процент отмен заказов за счёт показа сроков доставки на карточке товара.
2. Проблема. Какая боль или барьер у пользователя мешает достичь цели? Какие сигналы это подтверждают? Пользователь сталкивается с проблемой X, что приводит к Y. Приводи данные, скриншоты, цитаты. Можно добавить ссылку на исследование, кастдев или аналитику.
Примеры:
- Пользователи теряются на втором шаге регистрации и не понимают, что делать дальше — отток 35%.
- Клиенты не видят информации о сроке доставки, отменяют заказ после оформления (12% отказов).
3. Пользовательский сценарий. Как пользователь будет использовать фичу? Где он находится, чего хочет, как будет действовать? Не пиши "пользователь кликает по кнопке" — важно мышление и мотивация, а не действия.
Когда [контекст], пользователь хочет [мотивация], чтобы [цель].
Пример:
- Когда пользователь выбирает доставку, он хочет понимать дату получения, чтобы спланировать своё время и избежать отказа.
4. Требования к функциональности. Что должна уметь система? Какая логика нужна, какие состояния, действия, обработка ошибок и т.д. Что должно быть реализовано?
Условия показа / действия / скрытия? Описывай поведение при разных состояниях (нет данных, ошибка, успех). Можно добавить "Out of scope" — что не входит в задачу.
Пример:
- Показывать срок доставки под кнопкой "Оформить заказ", если пользователь ввёл адрес.
- Если адрес не введён — показывать плашку-заглушку "Введите адрес для оценки срока".
5. Требования к метрикам. Как поймём, что решение сработало?
Пример:
- Основная: CR оформления доставки с 41% до 46%.
- Вторичная: Кол-во заказов с отменами из-за сроков доставки — ↓ на 15%.
6. Оценка влияния. Зачем это команде? Сколько это повлияет на бизнес? Можно ли без этого?
Если мы реализуем фичу, ожидаем эффект X. Если не реализуем — риск Y. Сравнение с альтернативами.
Пример:
- Если добавим срок доставки — минус 12% отказов, плюс +2.5 млн в GMV за квартал.
- Без реализации — удерживаем существующий отток на прежнем уровне.
7. Технические ограничения. Что нужно учесть при реализации — зависимости, риски, ограничения. Проконсультируйся с разработчиками заранее. Не обещай то, что нельзя сделать в MVP.
Пример:
- Данные о сроках доступны только для регионов с DPD.
- Требуется обновление API → задача на backend.
8. Прототип / мокап. Визуальное представление будущего интерфейса. Figma / Miro / Screenshots. Можно добавить user flow. Укажи, какие экраны критичны, а какие — примерные. Покажи, что будет в случае ошибки, пустого состояния и т.д.
____
Хотите прокачать базу по продакт-менеджменту и продуктовой аналитике? Приходите на наши курсы
- Курс по продакт-менеджменту, базовый
- Курс по аналитике, базовый
- Курс по Продуктовой стратегии и защите инициативы
Следите за нашими курсами тут - https://t.me/koloskoveducation/, а все возможности можно посмотреть тут - https://t.me/FreshProductGo/1471