Roadmap продукта

Roadmap продукта. Что это такое? Как составить roadmap?

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

То есть грубо говоря мы сначала делаем фичу (функционал)№1, затем мы одновременно делаем фичу №2 и №3, потому что их можно делать одновременно, но обязательно после фичи №1 и потом мы всё это заканчиваем фичей №4.

Это грубое описание того, что из себя представляет Roadmap.

Для того чтобы понять, как сделать Roadmap который будет давать результат, для начала нужно понять для чего команды вообще делают Roadmap.

Зачем нужен Roadmap.

Обычно в продукте есть какие-то спонсоры. Скорее всего это кто-то от бизнеса вашей компании, либо это какие-то инвесторы. И соответственно Roadmap нужен этим бизнесменам или инвесторам, чтобы показывать, что ваша команда делает самый критичный функционал из списка задач.

Roadmap нужен для того, чтобы бизнес или стейкхолдеры (лица заинтересованные в реализации проекта) могли понимать сроки: какое время вы реализуете тот или иной функционал. Это необходимо потому, что часто вместе с релизом определенного функционала необходимо планировать какие-то параллельные дополнительные действия: маркетинговые активности, планировать бюджет расширения команды, расширение штатов (например продавцов). Поэтому Roadmap нужен для каких-то верхнеуровневых срооков, под которыми команда подписалась (закоммитилась (от англ. to commit) – означает подписаться на выполнение сделки на определенных условиях, в определенный срок).

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

Проблемы классических Roadmap.

К сожалению, очень часто бывает так, что команда вместе с продакт менеджером построили Roadmap, показали его бизнесу, подписались под сроки и в принципе уже реализовали этот функционал. Но он не работает. Он не решает проблемы пользователей.

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

Во-первых, для пользователя может просто не быть ценности в той фиче, которую вы сделали. Во-вторых, фича может быть слишком сложной в использовании для пользователя. И они могут просто не разобраться как ей пользоваться. В-третьих, фича может быть технически очень сложной в реализации или недостижимой: например, необходим сложный алгоритм с использованием VR технологий, artificial Intelligence, в машинном обучении, а ваш инженер программист не в состоянии осуществить это на вашем маленьком проекте. В-четвёртых, у вашей фичи могут быть какие-то юридические ограничения: например, вы, реализовав эту фичу, можете нарушать закон и так далее.

Что же нужно включать в Roadmap, который даст результат?

В него нужно включать последовательность проблем бизнеса. Соответственно, когда вы даете какой-то коммит бизнесу, вы говорите: «Сначала мы будем решать вот такую критичную проблему, потом такую, а потом вот эту». Таким образом, у вас выстраивается картина, какие проблемы пользователей вы собираетесь своим функционалом решать.

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

Инсайт.

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

Так как же построить Roadmap?

Практически все дорожные карты продуктов относятся к одной из трех основных структур:

- карты без указания временных ограничений (no-dates product roadmap);

- гибридные карты (hybrid product roadmap);

- карты с указанием четких временных ограничений (timeline product roadmap).

Для многих компаний, особенно тех, которые разрабатывают продукты на ранней стадии по методологии Agile, временные дорожные карты не являются полезными или необходимыми.

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

2. Гибридная дорожная карта. По мере того как продукт становится более зрелым, дорожная карта должна будет отражать более полное представление о продукте. Вот тут-то и появляется гибридная дорожная карта продуктов.

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

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

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

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

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

В рамках акселерации в Product University