Готовый шаблон для создания дорожной карты с помощью фреймворка RIDE

Если вы создавали свой стартап, занимались маркетингом ИТ продуктов или были частью продуктовой команды, то возможно знакомы с фреймворком RICE. Но сегодня речь не о нём, а его альтернативной версии – «RIDE».

Чтобы понять, чем RIDE отличается от RICE, давайте откроем шаблон и пройдемся по каждой колонке: Ideas, Reach, Impact, Data, Effort, Total и Real Total.

Ideas

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

Всё, что нужно команде – это при добавлении в список новой задачи, указать к чему она относится: Awareness, Acquisition, Activation, Retention, Revenue, Referral и Health. Забегая вперед, скажу, что выбор типа тесно связан с полем Impact и Total.

Reach

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

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

– Добавляете кнопку на экран приложения? Значит впишите сколько по вашему мнению нажмут на эту кнопку.

– У вас интернет-магазин и вы сделали новый тип доставки в корзине? Значит впишите сколько по вашему мнению воспользуются новым типом доставки.

– У вас SaaS по созданию сайтов и вы сделали новый шаблон? Значит впишите сколько по вашему мнению воспользуются новым шаблоном.

– У вас PaaS и вы запустили услугу бэкапирования? Значит впишите сколько по вашему мнению воспользуются этой услугой.

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

Во-вторых, не перемешивайте фичи для разных продуктов. Поясню, поскольку это не всегда очевидно. К примеру, ВКонтакте моя команда развивала интернет-торговлю. Нам приходилось работать с многоплатформенной бизнес-моделью. В быту про такую модель говорят как о курице и яйце. Получалось, что нам нужно было балансировать между продавцами (B2B) и покупателями (B2C). И если по неосторожности вставить наши доработки в один такой список, все B2B фичи скорее всего окажутся в хвосте. Если у вас похожая ситуация, то делайте отдельный роадмап под каждый продукт. И разрешайте дилемму уже на уровне управления портфеля продуктов.

Impact

«RIDE» учел недостатки своего предшественника. Теперь этот фактор стал более прозрачный, взвешенный и реалистичный. Учитывается жизненный цикл продукта и привязка к Awareness/Осведомленность, Acquisition/Привлечение, Activation/Активация, Retention/Удержание, Revenue/Выручка, Referral/Рефералы и Health/Гигиена.

Если открыть шаблон, можно увидеть, что в Impact уже вшита формула. Формула берет тип вашей задачи и автоматически выставляет значение для Impact.

Формулу можно и нужно менять в зависимости от зрелости вашего продукта. Как определять зрелость продукта и выбирать стратегию? Об этом можно написать отдельную большую работу. Но если говорить кратко, то к примеру, на этапе MVP значения для Awareness и Acquisition скорее всего будет ниже, чем для Activation и Retention. Ведь привлекать трафик в продукт, который похож на дырявое ведро может оказаться не самой лучшей идеей. Тем не менее, повторюсь, у разных команд разные стратегии. Кто-то может сознательно привлекать трафик в дырявое ведро.

Effort

Этот параметр отвечает за трудозатраты. Обсудим несколько важных моментов.

В жизни варианты оценки бывают разные. Обычно сроки измеряют в днях, неделях, месяцах. В менее прозрачных случаях могут использовать категориальную оценку. К примеру, S, M, L, XL, XXL. Но таблица «RIDE» работает только с числами. Поэтому если вы используете категориальную оценку, не забудьте привести оценки к числам. Для варианта выше это могли быть значения: S=7, M=14, L=21, XL=35, XXL=56.

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

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

Data

Итак, у нас есть прогнозы по каждому пункту относительно охвата и трудозатрат с поправкой на жизненный цикл нашего продукта. Но что, если наши прогнозы неверны? Более того, скорее всего это именно так. Поэтому необходимо как-то приблизить эти оценки к реалистичными. Для этого и вычисляется Data.

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

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

Подробный пример расчетов будет ниже.

Total

Вычисляется без труда. Мы берем Reach, корректируем его с помощью Impact и Data, а затем делим на наши трудозатраты.

Для начала сделайте себе копию шаблона. Уже сделали? Тогда вперёд!

Шаг 1

Расчехлите свой бэклог. В нём у вас скорее всего уже собраны пожелания клиентов, инвесторов и партнеров. Возможно там же вы храните список будущих продуктовых экспериментов, баги и возможные задачи гигиены. Уверен, что у вас также собраны возможные улучшения после конкурентного анализа. Если у вас всё это есть – вы большие молодцы! Теперь добавим к этому списку возможные маркетинговые активности на предстоящий квартал и внесем всё это в наш будущий roadmap в колонку Ideas.

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

Шаг 2

Теперь, для каждой задачи нужно проставить соответствующий тип. Задача так или иначе должна относиться к одному из следующих типов: Awareness, Acquisition, Activation, Retention, Revenue, Referral и Health.

Давайте кратко напомним, что эти задачи подразумевают.

• Awareness включает маркетинговые активности, которые растят узнаваемость вашего продукта и заставляют вспоминать пользователей в момент передвижения по лестнице Бена Ханта.
• Acquisition работа с каналами по привлечению трафика в продукт. Обычно речь про новый трафик.
• Activation включает работы по улучшению конверсий из первого контакта с продуктом до прохождения регистрации в нём.
• Retention включает работы которые должны побуждать ваших зарегистрированных пользователей чаще пользоваться вашим продуктом, сайтом, приложением.
• Revenue отвечает за разовые и регулярные платежи.
• Referral включает работы, которые побуждают ваших пользователей рассказывать о вашем продукте своим близким. К примеру, приглашать друзей и коллег использовать ваш сервис или приложение.
• Health включает задачи по исправлению багов, технические работы по обновлению ПО, рефакторинг кода, автоматизация процессов для сокращения Time To Market.
  

Шаг 3

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

Вот несколько примеров:

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

Шаг 4

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

Этап «Внедрение»

Activation = 4, Retention = 2, Health = 1, Referral = 0.5, Revenue = 0.25, Acquisition = 0.12, Awareness = 0.06 Здесь можно трактовать так: команде нужно залатать дыры в продукте и сформировать понятные ценностные предложения чтобы люди регулярно использовали их продукт, поэтому растить узнаваемость и привлекать трафик на этом этапе менее важно.

Этап «Рост»

Revenue = 4, Acquisition = 2, Referral = 1, Awareness = 0.5, Activation = 0.25, Retention = 0.12, Health = 0.06. В данном случае трактовать можно так: команда считает, что продукт не имеем серьезных ошибок и у него все хорошо с возвращаемостью, поэтому надо увеличивать выручку и трафик, а также поддерживать узнаваемость на рынке.

Шаг 5

На этом шаге команда должна использовать свой предыдущий опыт. Опытные команды наверняка замечали, что их ожидания в прогнозах зачастую расходятся с фактическим результатом. К примеру, рассчитывали, что рекламная кампания приведет в продукт 10000 пользователей, а на деле получили 7000. Или мы планировали сделать прирост к конверсии на шаге активации на +7%, а получили + 3%. А может у вас были истории, когда вы планировали обновить ПО или исправить баги за календарную неделю, а в действительности потратили 1 календарный месяц? Все это досадно и со временем подрывает веру и мотивацию команды, поэтому так важно стараться увеличить точность своих прогнозов относительно плана.

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

Команде надо открыть свои предыдущие роадмапы. Найти в них похожие по смыслу и объему задачи. Посмотреть на их Total и посчитать Real Total. Он вычисляется просто – необходимо получить реальный Reach и Efforts. Эта информация без труда найдется в системе аналитики и таск трекере. А далее надо просто вычислить отношение Real Total к Total, а затем вписать это в ячейку таблицы. К примеру, в прошлый раз вы вычислили Total=10000, а Real Total оказался равным 8540. Значит поделив 8540/10000 мы получим 0.85. Его и надо вписать в колонку Data напротив задачи.

Что делать, если похожих задач не было или у вас еще незрелая команда? Все это говорит о высоких рисках сделать что-то неликвидное или затянуть сроки. Поэтому для таких случаев моя рекомендация ставить значение в интервале от 0.05 до 0.20. Если вас будет тянуть поставить что-то стремящееся к 1, то вспомните про прыжки веры, человеческие факторы, конструктивные поломки, ошибки с оценкой рынка и многие другие напасти, которые встречаются в мире продуктовой разработки.

Шаг 6

Этот шаг про оценку трудозатрат. В каждой команде свои расчёты. Кто-то измеряет в спринтах, кто-то в человеко-днях, кто-то использует S, M, L, XL, XXL. Вашей команде важно лишь помнить о том, что роадмап составляется на конкретный период. К примеру, если вы работаете двухнедельными спринтами и составляете роадмап на полугодие, то в вашем распоряжении 26 календарных недель или 13 спринтов. И поэтому вам надо быть готовым, что вы что-то не успеете сделать, а значит надо пожертвовать этим. Но к счастью, на финальном шаге объективно определиться с этим вам поможет Total.

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

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

Финальный шаг – подсчитываем Total

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

Спасибо, что дочитали до конца. Желаю попутного ветра вам и вашему продукту на пути к берегам изобилия!