Если вы создавали свой стартап, занимались маркетингом ИТ продуктов или были частью продуктовой команды, то возможно знакомы с фреймворком планирования RICE для приоритизации продуктовых замыслов, идей и фич. Но сегодня речь не о нём. Будем обсуждать альтернативную версию этого фреймворка – «RIDE».
Преамбула
Для меня планирование очень важный ритуал. На мой взгляд в нём должна участвовать вся команда, ведь все находятся в одной лодке. И эта лодка плывет по алому морю с надеждой достичь берега изобилия. Лодка не вечная, а люди склонны уставать и задавать капитану вопросы. От мастерства капитана и команды зависит доплывете ли и кто будет первым – вы или ваши конкуренты. Экономические шторма, политические бури, технологический солнцепек и атаки со стороны конкурентов способны сломить вашу команду. Поэтому так важно в этом многолетнем путешествии сохранить рассудок и не поддаваться эмоциональным слабостям в трудные периоды. На мой взгляд с этим хорошо справится подход, способный быстро создать прозрачный и последовательный план.
На правах автора этого фреймворка я попытался сделать инструмент для создания таких планов. Я оставил сильные стороны фреймворка прошлого поколения, объединил с другим и заменил интуицию расчетами. Надеюсь, что у меня это получилось если не в полной мере, то хотя бы в значительной. Буду рад, если «RIDE» дополнит ваш арсенал продуктовых инструментов, поможет вам выстоять в бушующем море конкуренции и доплыть до берегов изобилия. Удачи!
Существующие проблемы в RICE
Все, кто работал с RICE в своих продуктах, должны были заметить несовершенство расчетов Impact и Confidence этой модели.
Его авторы признаются, что Impact довольно сложно измерить точно и предлагают нам использовать интуицию. У Confidence похожая проблема. Фактически, он берется с потолка. В более умных вариантах, команда проводит покер и указывает усредненное значение. Что само по себе принципиально ничего не меняет, ведь индивидуальная интуиция лишь становится коллективной. А там где интуиция, там часто рождаются галлюцинации. С таким навигатором можно заплыть далеко и не туда.
Кроме проблемы в объективности подсчета существует еще одна. RICE не позволяет объединить под одной крышей другие виды продуктовых задач. В основном все работы сфокусированы на конструктивных особенностях продукта. В таких командах люди сильно погружены в оптимизацию и улучшения, забыв про маркетинг. Под маркетингом я подразумеваю не только привлечение трафика, но и остальную работу: разработку рыночных предложений, дистрибуция, ценообразование, коммуникации, прокачка бренда. Я хочу сказать, что на моей практике работа над продуктом включает в себя много важных задач: исследования, регулярные внешние процессы со СМИ, партнерами, привлечением трафика в свой продукт, работу с виральностью, создание тарифов, а также проведение маркетинговых активностей.
Всё это говорит о том, что RICE больше подходит для очень ранних стадий продукта – прототипов, где существует высокая степень неопределенности и пока еще уместно делать оценки лишь на основе охвата (Reach) и трудозатрат (Efforts).
Но с каждым последующим месяцем команду будет затягивать в водоворот бесконечных задач. Нужно будет тестировать все блоки бизнес-модели – от ценностных предложений до ценообразования. Это сильно увеличит нагрузку на команду. Ей придется продолжать собирать и обрабатывать обратную связь, устранять выявленные ошибки, закладывать работы на техническую инфраструктуру и обновление ПО, договариваться о коллаборациях с партнерами, работать со СМИ и рекламой, иногда будут приходить входящие обращения на интеграции, внутри команды будут рождаться разные задумки нововведений. Чуть дальше нужно будет начинать выстраивать продажи и соперничать с конкурентами.
Именно здесь возникают большие сложности. Чем сильнее водоворот будет затягивать команду, тем чаще будут возникать в ней конфликты на уровне людей и работ. Это все приведет к тому, что на ваших планированиях будут чаще встречаться соревнования на красноречивость. А победителями в них скорее всего окажутся не люди с инженерным подходом, а люди с наделенной властью, развитыми навыками риторики и софистики.
Именно эти недостатки я постарался убрать при разработке «RIDE».
Анатомия RIDE
Вы можете сразу открыть шаблон и по мере прочтения статьи подсматривать в него для понимания модели расчетов, которая заложена во фреймворке «RIDE». Давайте подробнее посмотрим на колонки 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, а затем делим на наши трудозатраты.
Как пользоваться RIDE
Перейдем к практике. Возьмите за основу этот шаблон, сделайте себе копию с которой будете работать. Итак, приступаем.
Шаг 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
Вы дошли до финала! Осталось совсем немного. Все, что теперь нам осталось, это сделать сортировку по колонке Total от большего к меньшему.
Вот и все. Надеюсь фреймворк позволил вам порефлексировать над продуктовым планом без эмоций, вы смогли сделать наглядный роадмап и получить для себя инсайты. Если вы захотите связаться со мной, форма для связи и контакты есть в шаблоне.
Спасибо, что дочитали до конца. Желаю попутного ветра вам и вашему продукту на пути к берегам изобилия!
