PRD на собеседовании продакт-менеджера
Содержание:
Зачем PRD на собесе
PRD (Product Requirements Document) — основной артефакт работы продакта. На собесе проверяют не оформление, а способность держать в голове полную картину фичи: цели, пользовательские сценарии, метрики, edge cases, зависимости.
Что чаще всего просят:
- Написать PRD для абстрактной фичи за 30–40 минут (take-home или live)
- Оценить чужой PRD на полноту и найти пробелы
- Объяснить, как PRD связан с командной разработкой и метриками
Хороший PRD — это документ, который позволяет команде разработки начать без дополнительных уточнений. Плохой — это документ, к которому возвращаются 5 раз в неделю с вопросами.
Структура PRD
Универсального шаблона не существует — каждая компания пишет свой. Но базовый каркас стабилен:
- Title и owner — название фичи, автор, дата, статус
- TL;DR — 3–5 строк: что делаем, для кого, какой эффект ждём
- Background и motivation — почему делаем сейчас, какие данные за этим стоят
- Goals (цели) — что хотим достичь
- Non-goals (что не делаем) — явное ограничение скоупа
- Success metrics — как мерим успех
- User stories — пользовательские сценарии в формате «как X, я хочу Y, чтобы Z»
- Detailed requirements — функциональные и нефункциональные требования
- Acceptance criteria — что значит «фича готова»
- Out of scope — что в этом релизе не делаем
- Dependencies и risks — что нужно от других команд, что может пойти не так
- Open questions — что ещё не решено
Не все разделы обязательны для каждой фичи. Маленькая UX-правка может уместиться в 1 страницу. Большая фича — 5–10 страниц.
Goals и success metrics
Goals
Goals формулируются как изменение состояния, не как процесс. Плохо: «улучшить онбординг». Хорошо: «увеличить activation rate с 45% до 60% за 2 месяца».
Goals должны быть:
- Измеримыми: всегда есть число
- Привязанными к timeline: до какого момента
- Связанными с продуктовой стратегией: не делать ради процесса
На собесе спросят: «А что если goals противоречат друг другу?» Хороший ответ: явно проранжировать (primary > secondary), и в случае конфликта оптимизировать primary.
Success metrics
Это не то же, что goals. Goals — что хотим. Metrics — как поймём, что достигли.
Структура:
- Primary metric — главная, на которую оптимизируем
- Secondary metrics — связанные, движутся в правильную сторону
- Guardrail metrics — не должны ухудшиться (обычно churn, NPS, время загрузки)
Например, для фичи рекомендаций контента:
| Тип | Метрика | Целевое изменение |
|---|---|---|
| Primary | Время на сессию | +10% |
| Secondary | Click-through rate карточек | +20% |
| Secondary | Конверсия в подписку | без падения |
| Guardrail | NPS | без падения |
| Guardrail | App load time | без увеличения |
User stories и сценарии
User stories пишутся в формате «как [роль], я хочу [действие], чтобы [результат]». Это формат, не закон. Главное — понятная связь действия с пользой.
Хорошая story:
Как новый пользователь, я хочу получить рекомендации, основанные на моих первых действиях, чтобы быстро понять ценность продукта.
Плохая story:
Как пользователь, я хочу видеть кнопку «Рекомендации».
В плохой нет результата. Это описание UI-элемента, не пользовательской ценности.
Каждая user story должна иметь acceptance criteria (критерии готовности) и связь с success metric. Если связи нет — это либо не нужная story, либо метрика выбрана неправильно.
Acceptance criteria
Это конкретные проверяемые условия, при которых story считается выполненной. Стандарт «Given–When–Then»:
Given новый пользователь зарегистрировался
When он открывает главный экран в первый раз
Then ему показываются 5 рекомендаций
And рекомендации основаны на ответах онбординга
And если ответов нет — показываются дефолтные рекомендации по популярностиНа собесе оценят:
- Покрытие edge cases (что если данных нет? что если ошибка API?)
- Конкретность (нет «быстрого ответа» — есть «отклик за 200 мс»)
- Тестируемость (QA должен мочь проверить)
Out of scope и зависимости
Out of scope
Список того, что в этом релизе явно не делаем. Это не лень, а защита от scope creep. На собесе обязательно — если в PRD нет out of scope, считается слабым.
Пример для фичи рекомендаций:
- Не делаем персонализацию по социальным графам
- Не поддерживаем offline-сценарии в первой итерации
- Не запускаем для b2b-сегмента
Dependencies и risks
Что нужно от других команд, без чего нельзя стартовать или релизить.
- ML-команда: модель ранжирования к [дата]
- Backend: API эндпоинт
/recommendationsк [дата] - Дизайн: финальный UI к [дата]
Risks — что может пойти не так и как смягчить.
| Risk | Mitigation |
|---|---|
| Модель ML не успеет к релизу | Запасной план — heuristic-based recommendations |
| API нагрузка превысит SLA | Кеширование на 5 мин, rate limit |
| Юзерам не понравится | A/B тест на 10% перед раскатом |
PRD на собесе: что просят
1. Написать PRD за 30 минут
Live или take-home. Условие: «Опиши PRD для фичи X в продукте Y». Формат — обычно текст в google docs или notion.
Что важно показать:
- Структуру (заголовки видны сразу)
- Цели и метрики связаны
- User stories конкретные с acceptance criteria
- Есть out of scope
- Есть dependencies и risks
Не нужно писать роман. 1–2 страницы вполне достаточно.
2. Найти проблемы в чужом PRD
Дают готовый документ, просят прокомментировать. Типичные проблемы для поиска:
- Цели без метрик
- Метрики без guardrails
- User stories без acceptance criteria
- Нет out of scope (значит, scope нечёткий)
- Нет dependencies (значит, скрытые блокеры)
- Нет timeline
3. Защитить PRD перед командой
Дают условие: «У тебя 5 минут. Объясни команде, почему мы делаем эту фичу». Цель — проверить, как PR говорит про продукт. Хороший ответ начинается с пользователя и проблемы, не с фичи.
Частые ошибки
PRD без TL;DR. Команда читает первые 5 строк. Если за 30 секунд не понятно, что делаем и зачем — PRD не работает.
Цели без метрик. «Улучшить опыт» — не цель. Без числа невозможно понять, достигли или нет.
Решения вместо требований. «Используй React Query» — это не требование PRD, это уже архитектура. PRD говорит «нужны быстрые обновления данных», implementation выбирает разработка.
Нет out of scope. Без этого раздела scope расплывается, и фича вырастает в 3 раза. Out of scope — это границы.
Игнорировать non-functional requirements. Скорость загрузки, accessibility, мобильные сценарии. Без них фича может быть «готова», но непригодна.
Open questions = пустота. В каждом нетривиальном PRD есть нерешённые вопросы. Хорошо — фиксировать их явно. Скрывать = создавать риск.
FAQ
Какой длины должен быть PRD?
Достаточный, чтобы команда могла начать без вопросов. Маленькая фича — 1 страница. Большая инициатива — 5–10. Длиннее — обычно лишнее.
Кто пишет PRD — продакт один или с командой?
Драфт — продакт. Финал — после ревью команды (разработчиков, дизайнеров, аналитиков). PRD без ревью — чаще всего сырой.
Чем PRD отличается от brief или spec?
Brief — короткое описание идеи (1 страница, до того как продакт начал работу). PRD — детальный документ для разработки. Spec в традиционном смысле — техническое задание разработчика, обычно идёт после PRD.
Это официальная информация?
Нет. Статья основана на типовых практиках российских IT-компаний и опыте кандидатов. Конкретные шаблоны PRD сильно различаются — на собесе уточняйте, какой формат принят в команде.