Product Discovery: как построить эффективную рабочую карту и избежать основных ошибок

Дорожная карта (Roadmap) — документ, в котором отображены основные этапы реализации проекта, указаны их исполнители и сроки завершения. Об особенностях процесса расскажет Кирилл Хусаинов, Senior Product Manager в Lamoda Tech.

Чаще всего дорожная карта представлена в графическом виде, а процесс ее создания состоит из трех шагов.

1. Проблема
2. Дизайн и техника
3. Планирование

Идея продукта на пути к релизу проходит через два основных этапа: Product Discovery и Product Delivery. На первом этапе происходят первичные исследования для выявление проблем, целей, гипотез, требований и метода реализации (этот этап также можно назвать продуктовой проработкой).

На втором происходит разработка описанных требований. Важно помнить, что некоторые пункты можно учитывать и как Discovery-, и как Delivery-часть, а какие-то пункты могут идти параллельно или вперемешку (в зависимости от сложности продукта).

Сегодня мы рассмотрим усредненное понимание для Product Discovery и его завершения в виде готовой дорожной карты.

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

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

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

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

Привести эффект от решения проблем к одному виду

Часто необходимо сравнивать между собой проблемы из разных отделов. Например, между реализацией автоматизации внутренних процессов и упрощением пользовательского опыта на клиенте.

Решение: использовать общую метрику для приоритезации (обычно это денежная метрика формата GMV или NMV за определенный период времени, после релиза функционала).

Дать точное определение проблемы

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

Решение: оповестить все отделы о наличии данной проблемы и собрать от них обратную связь.

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

В зависимости от детализации дорожной карты и долгосрочности планов, исследование проблемы также вносится и располагается на первых позициях в графике. Средняя продолжительность этапа начинается от одной недели и может доходить до месяцев.

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

1. Формируются продуктовые требования для дизайна и разработки. Рекомендуется использовать описанные User Stories и уточнения частных кейсов при использовании продукта.
2. На основе требований создается базовый дизайн без детальной проработки, основанный на гипотезах.
3. С дизайном идет обсуждение на стороне разработки (для выбора оптимального решения).
4. Собирается обратная связь от заинтересованных менеджеров, разработки и дизайнеров.
5. Вносятся правки. При необходимости происходит возврат к первому пункту и повторение процесса.

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

После утверждения дизайна производится оценка со стороны разработки и нарезка на первые «эпики». Важно делить разработку на конечные задачи, которые приносят определенный результат в процессе достижения основной цели.

Данный этап относится к Product Discovery, но также частично и к Product Delivery. Это происходит из-за вовлеченной работы дизайнеров, чей готовый дизайн уже является началом фактических работ.

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

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

Остановимся на частых проблемах при планировании дорожной карты.

1. Отсутствие изначально запланированных ресурсов (bus factor) по ходу проекта.

2. Задержки других проектов. Узнайте статусы предшествующих проектов и скорректируйте даты начала этапов в собственном.

3. Отсутствие аналитики. Заранее заложите все необходимые события для функционала, чтобы получать свежие данные и корректировать дорожную карту.

4. Время на тестирование и исправление багов.

5.Время на A/B-тестирование и расчет результатов. Добавьте всех заказчиков и заинтересованных по проекту в тестовую группу.

Фактор автобуса (англ. bus factor) проекта — статистика, которая показывает количество участников проекта, после потери которых (увольнения, заболевания и других форс-мажорных обстоятельств) проект не сможет быть завершен оставшимися участниками.

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

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

Спасибо, что остаетесь с нами! А для тех, кто хочет войти в продукт или прокачать свои навыки, у ProductStar есть обучение профессиям Продакт-менеджер, Менеджер проектов и даже CPO.