Как составить roadmap продукта

Как создать идеальную дорожную карту продукта и что для этого нужно?

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

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

Зачем нужна дорожная карта?

Цель дорожной карты, как основного документа менеджера продукта, – донести главные идеи и прогресс в задачах до членов команды и внешних заинтересованных сторон (акционеров, заказчиков, партнеров).

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

Дорожные карты не ограничиваются продуктами: их цели аналогичны для разных видов (например, маркетинговые и IT-роадмапы).

Любая дорожная карта, ориентированная на свою аудиторию, имеет свои особенности.

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

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

Отличия дорожные карты в Agile и Waterfall

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

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

• Стратегические инициативы глобального уровня
• Релизы по периодам (кварталам)
• Детализированные функции
• Информация о баг фиксинге

Как создать идеальную дорожную карту?

Электронные таблицы

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

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

Презентации

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

Почему специальные сервисы лучше простых способов создания дорожной карты?

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

• Представить визуально дорожную карту продукта
• Связать глобальную стратегию с процессами дорожной карты
• Определить и оценить идеи
• Сотрудничать со всеми заинтересованными сторонами (включая клиентов и нетехнических коллег)
• Интегрироваться со сторонними системами

Какой сервис выбрать? Вот ТОП-7 платформ для менеджеров продуктов, которые заботятся о качественной визуализации дорожной карты:

Roadmunk

Hygger

Taskworld

Proofhub

GanttPRO

Wizeline

Roadmap planner

Если сервис для управления продуктом определен, можно приступать к созданию дорожной карты. С чего начать? Как создать понятную всем дорожную карту?

Основные этапы создания дорожной карты

Вероятно, нет необходимости напоминать лишний раз о ключевых бизнес-целях, которые напрямую связаны с созданием дорожных карт. Четко понимая их, а также ваши инициативы, в которые вы собираетесь инвестировать, вы можете определить, какие функции добавить в свою дорожную карту (подумав о том, что будет иметь наибольшее влияние на ваш бизнес). Вот 4-шаговая стратегия, которая будет полезна всем:

1. Определение стратегии

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

2. Кастомизация релизов

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

3. Приоритизация фич

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

4. Совместное использование дорожной карты

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

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

В качестве заключение

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

Хорошо разработанное программное обеспечение с опцией 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

Идеи

Достойная альтернатива Excel ?

Поделиться

СВЕЖИЕ СТАТЬИ

Другие материалы из этой рубрики

Не пропускайте новые статьи

Подписывайтесь на соцсети

Делимся новостями и свежими статьями, рассказываем о новинках сервиса

«Честно» — авторская рассылка от редакции Unisender

Искренние письма о работе и жизни. Свежие статьи из блога. Эксклюзивные кейсы
и интервью с экспертами диджитала.

Дорожные карты продуктов – это стратегические и тактические инструменты коммуникации, которые описывают шаги на пути к видению продукта.

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

Они служат способом объединения команд и заинтересованных сторон вокруг общего видения и направления развития продукта, учитывая отзывы и потребности клиентов.

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

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

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

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

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

Шаги к созданию дорожной карты продукта:
– Согласование видения, стратегии и целей продукта
– Создайте бэклог функций
– Определите план выпуска релизов
– Регулярно пересматривайте и обновляйте дорожную карту.