Визуальная шпаргалка

Продуктовый менеджмент без тумана

Продакт помогает команде выбрать ценную проблему, проверить решение и доказать результат данными. CJM, User Story, сценарий, BRD и PRD — инструменты для разных решений, а не обязательная пачка документов.

Увидеть общую логику ↓ Открыть шаблоны

01 · Ментальная модель

Сначала причина, потом решение

Документы появляются там, где нужно сохранить вывод, согласовать решение или передать контекст. Начинать с PRD на непроверенную идею обычно рано.

01Цель бизнеса

Какой результат компании должен измениться?

02Сегмент и контекст

Кому, когда и в какой ситуации помогаем?

03Исследование

Интервью, наблюдение, аналитика, обращения.

04Проблема

Что мешает получить ценность и насколько это важно?

05Гипотеза

Какое изменение должно улучшить поведение или результат?

06Решение

Прототип, требования, разработка и запуск.

07Эффект

Метрика изменилась? Что узнали и что делаем дальше?

Главный тест

Каждая функция должна связываться цепочкой: цель → наблюдаемая проблема → доказательство → гипотеза → изменение поведения → метрика.

02 · Основные артефакты

Пять инструментов, пять вопросов

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

ПодсказкаНажмите на вопрос. Откроется подходящий инструмент.

CJM · Customer Journey Map

Карта пути и опыта конкретного сегмента во времени: до, во время и после взаимодействия с продуктом. Она объединяет факты о действиях, мыслях, эмоциях, барьерах и точках контакта.

Отвечает«Где на пути теряется ценность и какую возможность исследовать?»

Из чего состоит

01Рамка: начало, конец и цель пути.
02Сегмент и контекст: кто проходит путь и в какой ситуации.
03Этапы: естественные фазы пути глазами человека.
04Действия: что человек реально делает на каждом этапе.
05Мысли и вопросы: чего не понимает, что сравнивает.
06Эмоции: уверенность, тревога, разочарование, облегчение.
07Барьеры: усилия, ожидание, ошибки, сомнения и риски.
08Точки контакта: приложение, поддержка, письмо, офлайн и другие каналы.
09Доказательства: цитаты, события аналитики, конверсия, обращения.
10Возможности: не готовые функции, а зоны для улучшения результата.

Как составить

1Ограничьте один сегмент, одну задачу и один путь.
2Соберите факты: интервью, наблюдение, аналитику, отзывы, поддержку.
3Разложите путь на этапы языком пользователя, а не структурой экранов.
4Заполните строки и пометьте неизвестное как гипотезу.
5Выберите критические моменты по частоте, тяжести и связи с целью.
6Проверьте карту с пользователями и командами, которые видят путь.

Хороший сигналУ каждой важной боли есть доказательство и понятный следующий вопрос.

Частая ошибкаНарисовать идеальный путь из головы и сразу вписать любимые функции.

CJM: [название пути]
Сегмент: [кто]
Контекст / задача: [когда и зачем]
Рамка: от [начало] до [конец]

Этапы:             1. […] | 2. […] | 3. […]
Действия:          […]    | […]    | […]
Мысли / вопросы:   […]    | […]    | […]
Эмоции:            […]    | […]    | […]
Барьеры:           […]    | […]    | […]
Точки контакта:    […]    | […]    | […]
Доказательства:    […]    | […]    | […]
Возможности:       […]    | […]    | […]

User Story · пользовательская история

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

Отвечает«Кому нужна эта возможность, чего человек хочет и зачем?»

Из чего состоит

01Роль или сегмент: конкретный пользователь в значимом контексте.
02Намерение: результат, которого человек хочет достичь.
03Ценность: зачем этот результат нужен.
04Критерии приёмки: наблюдаемые условия корректной работы.
05Контекст: ссылка на проблему, макет, сценарии, данные и ограничения.

Как составить и проверить

1Начните с исследованной потребности, не с названия функции.
2Назовите роль настолько точно, чтобы контекст влиял на решение.
3Опишите намерение без деталей интерфейса, если они ещё не обязательны.
4Проверьте ценность вопросом «и что это даёт человеку?».
5Добавьте критерии Given / When / Then и обсудите историю с командой.

INVEST-проверкаНезависима, обсуждаема, ценна, оцениваема, мала и проверяема.

Частая ошибка«Как пользователь, я хочу кнопку» описывает решение, но не намерение и ценность.

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

Критерии приёмки:
— Дано: [контекст / начальное состояние]
— Когда: [действие или событие]
— Тогда: [наблюдаемый результат]

Ссылки: [проблема] · [макет] · [сценарии] · [аналитика]

Сценарий · конкретный ход взаимодействия

Последовательность событий для одной ситуации. Сценарий показывает основной путь, альтернативы и сбои. Он помогает дизайну, разработке, аналитике и тестированию увидеть одинаковую картину.

Отвечает«Что происходит от триггера до результата, включая отклонения?»

Из чего состоит

01Название и цель: какой результат хочет получить пользователь.
02Актор и контекст: кто, где, на каком устройстве и почему сейчас.
03Предусловия: что уже должно быть истинно.
04Триггер: событие, запускающее сценарий.
05Основной поток: шаги пользователя и ответы системы.
06Альтернативы: допустимые развилки.
07Краевые случаи: ошибка, пустое состояние, тайм-аут, повтор, нет прав.
08Постусловие: новое состояние и подтверждение результата.

Как составить

1Возьмите одну User Story или одну задачу пользователя.
2Опишите самый короткий успешный путь без деталей реализации.
3На каждом шаге спросите: «Что может быть иначе или сломаться?».
4Добавьте важные состояния: загрузка, пусто, ошибка, успех, ограничение.
5Свяжите события аналитики и критерии приёмки с наблюдаемыми шагами.

Хороший сигналДизайнер, разработчик и тестировщик одинаково перескажут ход и результат.

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

Сценарий: [результат пользователя]
Актор и контекст: [кто, где, почему сейчас]
Предусловия: [что уже истинно]
Триггер: [что запускает поток]

Основной поток:
1. Пользователь […]
2. Система […]
3. Пользователь […]
4. Система подтверждает […]

Альтернативы: [развилки]
Ошибки и края: [пусто / нет прав / тайм-аут / повтор]
Постусловие: [новое состояние]
События аналитики: [что фиксируем]

BRD · Business Requirements Document

Документ о бизнес-потребности и ожидаемом результате. BRD объясняет, какое изменение нужно организации, зачем оно нужно, какие процессы и правила затрагивает, кто заинтересован и по каким бизнес-показателям принимать результат.

Отвечает«Какую потребность бизнеса закрываем, какой эффект ожидаем и какие рамки обязательны?»

Минимальный состав

01Резюме и решение: что нужно одобрить или согласовать.
02Бизнес-контекст: возможность, проблема, причина и доказательства.
03Цели и показатели: база, целевой эффект, срок и вклад в стратегию.
04Стейкхолдеры: спонсор, владельцы процессов, затронутые команды и клиенты.
05Текущий и целевой процесс: что меняется в работе организации.
06Границы: подразделения, рынки, каналы, входит, не входит и этапы.
07Бизнес-требования: нужные возможности и результаты без проектирования экранов.
08Правила и контроль: политика, закон, безопасность, аудит, уровни сервиса.
09Экономика: ожидаемая выгода, издержки, бюджетные рамки и окупаемость.
10Ограничения и зависимости: системы, данные, поставщики, сроки и ресурсы.
11Риски и приёмка: условия бизнес-готовности, владельцы и управление решениями.

Как составить

1Назовите спонсора и конкретное решение, ради которого нужен BRD.
2Зафиксируйте текущий процесс, исходные показатели и цену бездействия.
3Сформулируйте измеримые бизнес-цели и нецели.
4Картируйте заинтересованные стороны, процессы, правила и обязательные ограничения.
5Опишите требования как нужные способности бизнеса, не как экраны и архитектуру.
6Проверьте экономику, зависимости и риски с владельцами функций.
7Согласуйте приоритеты, условия приёмки и журнал решений.

Хороший сигналНесколько команд могут спроектировать свои изменения, сохранив одну бизнес-цель и обязательные правила.

Частая ошибкаДублировать PRD и заранее предписывать интерфейс вместо бизнес-способности и результата.

Важно

Единого стандарта BRD нет. В современной продуктовой команде его часто объединяют с business case, one-pager или PRD. Отдельный BRD особенно полезен для межфункциональной трансформации, регулирования, закупки, корпоративного клиента или нескольких продуктов.

# [Название бизнес-инициативы]

## 1. Резюме и требуемое решение
## 2. Бизнес-контекст и доказательства
Текущий процесс · исходные показатели · цена бездействия

## 3. Бизнес-цели / нецели
Показатель · база · цель · срок · связь со стратегией

## 4. Стейкхолдеры и владельцы
## 5. Текущий / целевой процесс
## 6. Границы и этапы

## 7. Бизнес-требования
BR-01: [бизнес должен уметь / обеспечить…]
Приоритет · обоснование · критерий бизнес-приёмки

## 8. Правила, закон, безопасность, SLA
## 9. Экономика и бюджетные рамки
## 10. Ограничения и зависимости
## 11. Риски, открытые вопросы и журнал решений

PRD · Product Requirements Document

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

Отвечает«Почему решаем это сейчас, что входит, как выглядит успех и что может помешать?»

Минимальный состав

01Резюме: решение в трёх-пяти предложениях.
02Контекст и проблема: факты, масштаб, причины, текущий путь и ссылка на BRD, если он есть.
03Пользователь: сегмент, контекст, Job to be Done.
04Цели и нецели: что меняем и что сознательно не решаем.
05Метрики: база, цель, срок, сегмент и защитные показатели.
06Границы: что входит в первую версию, что позже.
07Требования: возможности, истории, сценарии, состояния, правила.
08Опыт: поток, макеты, контент, доступность.
09Измерение: события, свойства, дашборд и план анализа.
10Ограничения: технические, правовые, операционные, коммерческие.
11Запуск: этапы, аудитория, поддержка, откат.
12Риски и решения: неизвестное, зависимости, открытые вопросы, владельцы.

Как составить

1Сначала напишите проблему, доказательства и целевую метрику.
2Согласуйте цели и нецели до детализации решения.
3Пройдите решение вместе с дизайном, разработкой, аналитикой и операциями.
4Разделите обязательное, желательное и отложенное.
5Опишите сценарии и ограничения, а не каждый пиксель реализации.
6До разработки зафиксируйте аналитику, запуск, защитные метрики и откат.
7Обновляйте решения и причины изменений. Удаляйте устаревшее.

Хороший сигналКоманда понимает проблему и может предложить более простое решение с тем же эффектом.

Частая ошибкаPRD превращается в неизменный заказ на функции без метрики, нецелей и плана проверки.

# [Название инициативы]

## 1. Резюме
## 2. Контекст и проблема
Доказательства · масштаб · текущий путь · причины

## 3. Пользователь и Job to be Done
## 4. Цели / нецели
## 5. Метрики успеха
База · цель · срок · сегмент · guardrails

## 6. Границы версии
Входит · не входит · позже

## 7. Требования
User Stories · сценарии · состояния · бизнес-правила

## 8. UX и контент
## 9. Аналитика
## 10. Ограничения и зависимости
## 11. План запуска и отката
## 12. Риски, открытые вопросы, решения и владельцы

03 · Не путать

Один продукт, разный масштаб

Артефакты не конкурируют. Каждый меняет уровень детализации и служит своему решению.

Артефакт	Масштаб	Что фиксирует	Когда нужен	Не заменяет
CJM	Путь во времени, много этапов и каналов	Фактический опыт, боли, доказательства, возможности	Ищем, где проблема и почему она возникает	Дизайн потока и спецификацию
User Story	Одна порция пользовательской ценности	Роль, намерение, ценность	Формируем элемент бэклога и разговор команды	Сценарии и критерии приёмки
Сценарий	Одна ситуация от триггера до результата	Шаги, ответы системы, альтернативы, ошибки	Проектируем и проверяем поведение	Причину и приоритет инициативы
BRD	Бизнес-инициатива, процесс или трансформация	Бизнес-потребность, эффект, правила, границы и заинтересованные стороны	Нужно согласовать изменение между функциями или продуктами	Пользовательский опыт и детали продукта
PRD	Инициатива или значимое изменение	Почему, что, границы, успех, риски и запуск	Нужно согласовать и передать контекст	Исследование и совместное принятие решений

НаправлениеСтратегия / business case

Почему эта ставка важна и почему сейчас.

Бизнес-уровеньBRD

Какой эффект, процесс, способность и обязательные правила нужны.

Продуктовый уровеньОдин или несколько PRD

Какое изменение для пользователя и продукта даст нужный эффект.

ИсполнениеStories + сценарии

Какие порции ценности и потоки реализует команда.

BRD · взгляд бизнеса

Главный вопрос: что должна получить или уметь организация?

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

PRD · взгляд продукта

Главный вопрос: какое изменение продукта даст ценность пользователю и нужный эффект?

Фокус: сегмент, проблема, опыт, поведение продукта, границы и метрики.
Читатели: продукт, дизайн, разработка, аналитика, тестирование и go-to-market.
Детализация: сценарии, состояния, требования, аналитика, запуск и откат.
PRD может существовать без отдельного BRD, если бизнес-контекст уже ясен.

Правило

BRD не «старше» и не «подробнее» PRD. Это другой ракурс. Если два документа повторяют один текст и обслуживают одну команду, объедините их. Разделяйте, когда разные решения, владельцы или уровни согласования требуют разных деталей.

04 · Сквозной пример

Как одна боль проходит до релиза

Пример: доставка продуктов. Пользователи узнают об отсутствии удобного интервала слишком поздно и бросают корзину.

CJM + данныеНаблюдение

На этапе оформления 18% корзин закрываются после показа доступных интервалов. В интервью люди говорят: «Я зря собирал корзину».

ПроблемаФормулировка

Занятые покупатели не знают заранее, успеет ли доставка к нужному времени, поэтому откладывают или отменяют заказ.

BRDБизнес-потребность

Бизнес должен сообщать актуальное обещание доставки до оформления. Цель — сократить потерянные заказы без роста опозданий.

ГипотезаОжидаемый эффект

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

User StoryЦенность

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

СценарииПоведение

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

PRD + запускПродукт и метрика

Показать ближайший слот на главной и обновлять после смены адреса. Снизить отказ с 18% до 13% за шесть недель.

05 · Базовая система знаний

Что ещё нужно продакту

Удобно мыслить четырьмя слоями: направление, понимание, поставка и измерение. Инструмент важен лишь тогда, когда улучшает решение.

01 / DIRECTION

Куда и почему

Выбор рынка, пользователя, ценности и компромиссов.

Видение продукта

Желаемое будущее для пользователя и бизнеса. Даёт направление, но не список функций.

Стратегия

Диагноз ситуации, ставка и согласованные действия. Сильная стратегия говорит и о том, чего мы не делаем.

Сегментация

Группы с разными задачами, поведением или ценностью. «Все пользователи» редко помогают выбрать решение.

Ценностное предложение

Для кого продукт, какую работу помогает выполнить, какую выгоду даёт и почему лучше альтернатив.

Бизнес-модель

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

Позиционирование и рынок

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

02 / DISCOVERY

Что истинно

Понимание задач, проблем и самых рискованных допущений.

JTBD

Job to be Done описывает прогресс в контексте: «Когда…, я хочу…, чтобы…». Фокус на задаче, не на демографии.

Триангуляция

Качественные данные объясняют «почему», количественные показывают «сколько». Надёжнее использовать оба типа.

Формулировка проблемы

[кто] не может [прогресс] в [контексте], потому что [барьер]; это ведёт к [эффекту].

Карта допущений

Что должно быть правдой о ценности, удобстве, реализуемости и жизнеспособности? Сначала тестируют важное и неизвестное.

Гипотеза и эксперимент

Изменение → аудитория → ожидаемое поведение → метрика → критерий решения. Эксперимент нужен ради выбора, не ради отчёта.

Opportunity Solution Tree

Связывает outcome, пользовательские возможности, решения и эксперименты. Помогает не прыгать от цели к первой идее.

03 / DELIVERY

Что и как поставить

Границы решения, последовательность, качество и выход на рынок.

Outcome и output

Output — выпущенная функция. Outcome — изменившееся поведение или результат. Команда управляет output, но учится по outcome.

MVP

Самый дешёвый способ проверить ключевой риск и дать минимальную ценность. Это не синоним некачественной первой версии.

Приоритизация

Стратегическое соответствие, эффект, охват, уверенность, усилия и риск. RICE = Reach × Impact × Confidence / Effort.

Roadmap

Последовательность outcomes, проблем или ставок. Формат Now / Next / Later честнее точных дат при высокой неопределённости.

Backlog и Agile

Бэклог хранит упорядоченную работу. Scrum и Kanban помогают поставке, но не заменяют стратегию и discovery.

Go-to-market

Кому и как сообщаем ценность, каналы, цена, продажи, поддержка, обучение, этапы запуска и обратная связь.

04 / LEARNING

Что изменилось

Метрики, экономика, причинность и следующее решение.

North Star Metric

Показатель повторяемой ценности, которую пользователи получают, а бизнес может наращивать. Не обязательно выручка.

Дерево метрик

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

Воронка

Acquisition → Activation → Retention → Revenue → Referral. Этапы подстраивают под реальный путь продукта.

Retention и когорты

Возвращаются ли пользователи к ценности? Когорты отделяют изменения поведения от смешения разных периодов и сегментов.

Юнит-экономика

CAC, LTV, маржа, стоимость обслуживания и срок окупаемости. Рост без здоровой экономики может увеличивать убыток.

Причинность

Рост после релиза ещё не доказывает эффект. Нужны эксперимент, контроль, квазиэксперимент или осторожная интерпретация.

06 · Метрики

Метрика без рамки почти бесполезна

«Увеличить конверсию» не задаёт решения. Нужны исходная точка, цель, срок, сегмент и ограничители.

показатель+ сегмент+ база+ цель+ срок+ guardrails

VALUE

Главная метрика

Отражает полученную пользователем ценность: завершённые поездки, решённые задачи, успешные заказы.

LEADING

Входные метрики

Меняются раньше результата и подконтрольны команде: активация, время до ценности, доля успеха.

LAGGING

Итоговые метрики

Показывают конечный эффект: удержание, выручка, маржа, повторное использование.

GUARDRAIL

Защитные метрики

Не дают улучшить одно ценой другого: возвраты, ошибки, жалобы, задержки, риск, нагрузка.

07 · Команда

Продакт не работает один

Границы различаются между компаниями. Главное — явно договориться, кто принимает решение, кто даёт данные и кто отвечает за исполнение.

Product Manager

Проблема, outcome, приоритет, компромиссы, согласование и обучение после запуска.

Product Designer / Researcher

Исследование поведения, структура опыта, прототипы, удобство и доступность.

Tech Lead / Engineers

Архитектура, реализуемость, оценка, качество, эксплуатация и технические риски.

Product Analyst

Определение метрик, дизайн измерения, события, эксперименты, анализ и интерпретация.

GTM / Operations

Цена, продажи, маркетинг, поддержка, процессы, обучение, правовые и операционные условия.

08 · Рабочий цикл

Повторяйте не документы, а обучение

Масштаб цикла может быть от одного дня до квартала. Чем выше неопределённость, тем меньше должен быть следующий проверяемый шаг.

01Выбрать outcome

Связать работу с целью бизнеса и пользователя.

02Наблюдать

Данные, интервью, путь, рынок и поддержка.

03Сформулировать

Сегмент, контекст, проблема, масштаб и причина.

04Проверить риск

Прототип, интервью, технический spike или эксперимент.

05Определить

Границы, истории, сценарии, PRD и аналитика.

06Поставить

Разработка, качество, коммуникация, запуск и откат.

07Научиться

Эффект, причины, решение: масштабировать, изменить или остановить.

Feature factory

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

Solution first

Команда защищает идею до понимания пользователя, контекста, причины и масштаба проблемы.

Vanity metrics

Метрика растёт и красиво выглядит, но не связана с полученной ценностью или экономикой.

Research theatre

Исследование проводят, но не фиксируют, какое решение изменится от каждого результата.

RICE как истина

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

MVP без качества

Критический путь ненадёжен, поэтому тест измеряет раздражение от ошибок, а не ценность идеи.

Минимум перед стартом разработки

Если на пять вопросов есть короткие доказательные ответы, команда готова обсуждать решение. Если нет, следующий шаг — уменьшить неизвестность.

Для кого и в каком контексте? Какая проблема и какие доказательства? Почему сейчас и что не делаем? Что должно измениться в поведении? Как измерим успех и вред?