Давайте будем честными, в 95 % случаев нормальная работа продакта в компании требует строительства огромных детальных CJM или проведения глубинных исследований сотнями в месяц. MVP? Тоже единичные случаи: проще сразу в бой и на малую группу. Да и базовый расчёт рынка необходим лишь при защите продукта на различных комитетах.

А что же важно? Важно уметь придумывать гипотезы, которые будут прогнозируемо наращивать целевую метрику. Для этого требуются не столько знания, сколько значительные усилия.

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

Но для того, чтобы продакты научились применять эти навыки в работе, необходимо:

1. Отдать ответственность за результат (тут хорошо работает вопросительная коммуникация) и напомнить: запустить то, что не летит, в 1 000 раз хуже, чем НЕ запустить.
   
   
2. Сформировать насмотренность в продукте и понимание всех связей и зависимостей.

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

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

✅ Артефакты после внедрения инструмента:

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

Сработаю на опережение: вот мини-видео об основных возможных ошибках:

Небольшое видео о том, в чём принципиальная разница между аналитикой и общением с пользователем. И то, и то – про данные от пользователя, оба инструмента важно и нужно применять. Вопрос, когда и что лучше.

✅ Артефакты после внедрения инструмента

• ТЗ на аналитику
• Профиль пользователя, с которым надо поговорить

Сбор данных обычно не вызывает больших сложностей. Почти все умеют формировать ТЗ для аналитиков или доставать информацию другими способами.

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

Так же мини-видео про основные ошибки в построении CJM:

✅ Артефакты после внедрения инструмента

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

Ну и напоследок. У нас есть места, где влияние на основную метрику будет максимальным. У нас есть данные от пользователя, на основе которых рождаются гипотезы об изменении метрик. Теперь мы должны понять, что делать в первую очередь, а что – после. Для этого есть очень гибкая модель приоритизации, которую можно адаптировать под любую задачу.

✅ Артефакты после внедрения инструмента

• Принятая всей командой модель приоритизации
• Понятный приоритизированный бэклог с оценкой эффекта, основанный на данных от пользователя