Составляем Roadmap продукта: типичные ловушки и как их избежать
В быстро меняющемся цифровом мире создание инноваций немыслимо без применения гибких подходов. Это позволяет находить пути создания новых источников ценности, которые удовлетворяют растущие потребности клиентов. Грамотно составленный roadmap продукта ложится в основу плана по доставке ценности пользователям. В то же время, неверно составленный roadmap приводит к ряду неожиданных последствий, которые мы рассмотрим в этой статье. Но, для начала, определимся, что же такое roadmap продукта.
Что такое Roadmap продукта?
Если говорить просто, то Roadmap продукта описывает то, каким образом компания планирует реализовать vision (концепцию) продукта.
Нет верного и не верного способа составить Roadmap, но как правило, при составление roadmap’a используют один из двух форматов:
- Outcome Roadmap — состоит из результатов и/или целей;
- Feature Roadmap — состоит из фич (функционала) продукта.
Ниже приведен пример показывающий, различия между двумя форматами, а также демонстрирующий, как составление продуктовых roadmap’ов встраивается в процесс планирования продукта.
Ловушка №1: Формат не соответствует контексту
Продуктовые команды часто негативно относятся к составлению Roadmap’a продукта. Во многом это связано с выбором формата, который не соответствует контексту: зрелости продукта и динамике рынка.
Давайте рассмотрим, как эти факторы влияют на решение о формате roadmap’a.
Формат Feature Roadmap рекомендуется использовать, если продукт считается зрелым и компания конкурирует на стабильном рынке.
Неопределенность, связанная с созданием продуктов в динамической среде, затрудняет планирование. Оценка фичи (ценность vs. ресурсы) после каждой итерации, как правило, меняется по мере обнаружения новых рисков и/или зависимостей.
Это приводит к частым изменениям Roadmap’a, которые подрывают доверие к продуктовой команде.
Поэтому, если продукт не зрелый или организация конкурирует на быстро развивающемся рынке, рекомендуется использовать формат Outcome Roadmap, потому что главные цели и возможности меняются не так быстро и с меньшей вероятностью.
Best Practice: Руководство устанавливает цель бизнеса и дает возможность команде продукта определить направления развития и проекты. Так можно продемонстрировать доверие к команде и увеличить её вовлеченность.
Ловушка №2: Стратегия продукта определена не четко
Марти Каган определяет стратегию продукта, как «последовательность фичей или релизов, которые команда планирует реализовать на пути к осуществлению концепции продукта».
В стремлении уложиться в сроки, продуктовые команды не выделяют необходимое количество времени и ресурсов для проверки продуктовой стратегии. Это приводит к созданию продуктов, которые не влекут за собой предполагаемых изменений в поведении клиентов, что в конечном итоге ограничивает способность команды решать бизнес-задачи.
Используйте Product Vision Canvas для понимания стратегии продукта и формирования общего понимания на уровне всей компании. Все сформированные гипотез нуждаются в проверке. Самым простой способ проверки это общение с клиентами и наблюдение их взаимодействия с продуктом. После этого стоит оценить осуществимость, сотрудничая с разработкой, чтобы понять технические ограничения.
Самым простой способ проверки это общение с клиентами и наблюдение их взаимодействия с продуктом. После этого стоит оценить осуществимость, сотрудничая с разработкой, чтобы понять технические ограничения.
Best Practice: Снижение рисков — один из ключевых факторов успешного выполнения стратегии продукта, поэтому каждая команда продукта должна четко сформулировать четыре риска продукта, прежде чем писать код.
- Риск ценности — готовы ли клиенты купить продукт;
- Риск восприятия — поймут ли пользователи, как использовать продукт;
- Риск осуществимости — есть ли у команды соответствующие навыки;
- Риск жизнеспособности бизнеса — подходит ли предложенное решение бизнесу.
Ловушка №3: Линейные roadmap’ы и итеративная разработка
«Мы признаем, что не знаем, какие именно фичи собираемся создать, и даем командам возможность понять это» — Элли Рего, менеджер по продукту @ Wodify.
Движение итерациями — ключевое преимущество при создание цифровых продуктов: запуск фичей, измерение реакции клиентов и, затем, улучшение. Выделить время на улучшение текущего функционала, при этом сохраняя текущий темп доставки ценности — непростая задача для продуктовой команды. Нехватка времени и необходимость перехода к следующей фиче затрудняет улучшение элементов существующего продукта, таких как закрытие технического долга, рефакторинг или усовершенствования дизайна.
Рекомендуется, чтобы член команды по продукту, обычно Scrum Master или владелец продукта, периодически отслеживал график сгорания (Scrum) или кумулятивную диаграмму рабочего процесса (Kanban), чтобы определить, идет ли доставка по графику.
На этом пока всё. Продолжение в следующей части.
