Если вы создавали свой стартап, занимались маркетингом ИТ продуктов или были частью продуктовой команды, то возможно знакомы с фреймворком планирования RICE для приоритизации продуктовых замыслов, идей и фич. Но сегодня речь не о нём. Будем обсуждать альтернативную версию этого фреймворка – «RIDE». Для меня планирование очень важный ритуал. На мой взгляд в нём должна участвовать вся команда, ведь все находятся в одной лодке. И эта лодка плывет по алому морю с надеждой достичь берега изобилия. Лодка не вечная, а люди склонны уставать и задавать капитану вопросы. От мастерства капитана и команды зависит доплывете ли и кто будет первым – вы или ваши конкуренты. Экономические шторма, политические бури, технологический солнцепек и атаки со стороны конкурентов способны сломить вашу команду. Поэтому так важно в этом многолетнем путешествии сохранить рассудок и не поддаваться эмоциональным слабостям в трудные периоды. На мой взгляд с этим хорошо справится подход, способный быстро создать прозрачный и последовательный план.  На правах автора этого фреймворка я попытался сделать инструмент для создания таких планов. Я оставил сильные стороны фреймворка прошлого поколения, объединил с другим и заменил интуицию расчетами. Надеюсь, что у меня это получилось если не в полной мере, то хотя бы в значительной. Буду рад, если «RIDE» дополнит ваш арсенал продуктовых инструментов, поможет вам выстоять в бушующем море конкуренции и доплыть до берегов изобилия. Удачи! Все, кто работал с RICE в своих продуктах, должны были заметить несовершенство расчетов Impact и Confidence этой модели.  Его авторы признаются, что Impact довольно сложно измерить точно и предлагают нам использовать интуицию. У Confidence похожая проблема. Фактически, он берется с потолка. В более умных вариантах, команда проводит покер и указывает усредненное значение. Что само по себе принципиально ничего не меняет, ведь индивидуальная интуиция лишь становится коллективной. А там где интуиция, там часто рождаются галлюцинации. С таким навигатором можно заплыть далеко и не туда.  Кроме проблемы в объективности подсчета существует еще одна. RICE не позволяет объединить под одной крышей другие виды продуктовых задач. В основном все работы сфокусированы на конструктивных особенностях продукта. В таких командах люди сильно погружены в оптимизацию и улучшения, забыв про маркетинг. Под маркетингом я подразумеваю не только привлечение трафика, но и остальную работу: разработку рыночных предложений, дистрибуция, ценообразование, коммуникации, прокачка бренда. Я хочу сказать, что на моей практике работа над продуктом включает в себя много важных задач: исследования, регулярные внешние процессы со СМИ, партнерами, привлечением трафика в свой продукт, работу с виральностью, создание тарифов, а также проведение маркетинговых активностей. Всё это говорит о том, что RICE больше подходит для очень ранних стадий продукта – прототипов, где существует высокая степень неопределенности и пока еще уместно делать оценки лишь на основе охвата (Reach) и трудозатрат (Efforts). Но с каждым последующим месяцем команду будет затягивать в водоворот бесконечных задач. Нужно будет тестировать все блоки бизнес-модели – от ценностных предложений до ценообразования. Это сильно увеличит нагрузку на команду. Ей придется продолжать собирать и обрабатывать обратную связь, устранять выявленные ошибки, закладывать работы на техническую инфраструктуру и обновление ПО, договариваться о коллаборациях с партнерами, работать со СМИ и рекламой, иногда будут приходить входящие обращения на интеграции, внутри команды будут рождаться разные задумки нововведений. Чуть дальше нужно будет начинать выстраивать продажи и соперничать с конкурентами. Именно здесь возникают большие сложности. Чем сильнее водоворот будет затягивать команду, тем чаще будут возникать в ней конфликты на уровне людей и работ. Это все приведет к тому, что на ваших планированиях будут чаще встречаться соревнования на красноречивость. А победителями в них скорее всего окажутся не люди с инженерным подходом, а люди с наделенной властью, развитыми навыками риторики и софистики.  Именно эти недостатки я постарался убрать при разработке «RIDE». Вы можете сразу открыть шаблон и по мере прочтения статьи подсматривать в него для понимания модели расчетов, которая заложена во фреймворке «RIDE». Давайте подробнее посмотрим на колонки Ideas, Reach, Impact, Data, Effort, Total и Real Total. Думаю смысл этого поля интуитивно понятен. В этот список помимо задач конструктивных улучшений, также попадают важные для продукта задачи маркетинга и гигиены. Другими словами теперь команда будет иметь перед глазами более холистическую картину в которой найдется место и дизайну продукта (в широком смысле), и рекламе, и исследованиям и коммуникациям и работе над ошибками.  Всё, что нужно команде – это при добавлении в список новой задачи, указать к чему она относится: Awareness, Acquisition, Activation, Retention, Revenue, Referral и Health. Забегая вперед, скажу, что выбор типа тесно связан с полем Impact и Total. Охват – это ваш прогноз относительно числа уникальных пользователей, которые непосредственно будут взаимодействовать с вашим нововведением.  Хотите запустить рекламную кампанию или объявление? Значит укажите свой прогноз относительно числа уникальных пользователей которых привлечете в продукт. Добавляете кнопку на экран приложения? Значит впишите сколько по вашему мнению нажмут на эту кнопку. У вас интернет-магазин и вы сделали новый тип доставки в корзине? Значит впишите сколько по вашему мнению воспользуются новым типом доставки. У вас SaaS по созданию сайтов и вы сделали новый шаблон? Значит впишите сколько по вашему мнению воспользуются новым шаблоном. У вас PaaS и вы запустили услугу бэкапирования? Значит впишите сколько по вашему мнению воспользуются этой услугой. Важно напомнить еще несколько вещей. Во-первых, убедитесь, что вы считаете Reach за конкретный период одинаково для всех идей в списке. К примеру, выделяете каждой идеи по календарному месяцу или кварталу после запуска и только потом измеряете финальные результаты.  Во-вторых, не перемешивайте фичи для разных продуктов. Поясню, поскольку это не всегда очевидно. К примеру, ВКонтакте моя команда развивала интернет-торговлю. Нам приходилось работать с многоплатформенной бизнес-моделью. В быту про такую модель говорят как о курице и яйце. Получалось, что нам нужно было балансировать между продавцами (B2B) и покупателями (B2C). И если по неосторожности вставить наши доработки в один такой список, все B2B фичи скорее всего окажутся в хвосте. Если у вас похожая ситуация, то делайте отдельный роадмап под каждый продукт. И разрешайте дилемму уже на уровне управления портфеля продуктов. «RIDE» учел недостатки своего предшественника. Теперь этот фактор стал более прозрачный, взвешенный и реалистичный. Учитывается жизненный цикл продукта и привязка к Awareness/Осведомленность, Acquisition/Привлечение, Activation/Активация, Retention/Удержание, Revenue/Выручка, Referral/Рефералы и Health/Гигиена.  Если открыть шаблон, можно увидеть, что в Impact уже вшита формула. Формула берет тип вашей задачи и автоматически выставляет значение для Impact.  Формулу можно и нужно менять в зависимости от зрелости вашего продукта. Как определять зрелость продукта и выбирать стратегию? Об этом можно написать отдельную большую работу. Но если говорить кратко, то к примеру, на этапе MVP значения для Awareness и Acquisition скорее всего будет ниже, чем для Activation и Retention. Ведь привлекать трафик в продукт, который похож на дырявое ведро может оказаться не самой лучшей идеей. Тем не менее, повторюсь, у разных команд разные стратегии. Кто-то может сознательно привлекать трафик в дырявое ведро.  Этот параметр отвечает за трудозатраты. Обсудим несколько важных моментов. В жизни варианты оценки бывают разные. Обычно сроки измеряют в днях, неделях, месяцах. В менее прозрачных случаях могут использовать категориальную оценку. К примеру, S, M, L, XL, XXL. Но таблица «RIDE» работает только с числами. Поэтому если вы используете категориальную оценку, не забудьте привести оценки к числам. Для варианта выше это могли быть значения: S=7, M=14, L=21, XL=35, XXL=56. Также при оценке не забывайте, что работа по каждой задаче в родамапе будет состоять из разных этапов. Не надо забывать про создание документации, подготовку дизайна, контента, техническую разработку, настройку серверов, юридические документы и т.п. Оценка должна учитывать суммарные сроки по всем этим работам. Может быть слишком очевидно, но стоит сказать, что все работы в роадмапе должны быть подсчитаны в одних единицах измерения. Нельзя считать одну задачу в днях, а другую в месяцах. В этом случае месяцы нужно перевести в дни. Итак, у нас есть прогнозы по каждому пункту относительно охвата и трудозатрат с поправкой на жизненный цикл нашего продукта. Но что, если наши прогнозы неверны? Более того, скорее всего это именно так. Поэтому необходимо как-то приблизить эти оценки к реалистичными. Для этого и вычисляется Data.  На самом деле внутри расчета лежит простая идея. Команде необходимо открыть свои предидущие роадмапы и узнать насколько точно тогда удалось вычислить Total для похожей задачи, а затем сравнить его с Real Total. Real Total вычисляется абсолютно также как и Total, но данные для Reach и Effort берутся уже из метрик.  Скорее всего Total и Real Total у вас будут отличаться. Это означает, что в прошлый раз вы переоценили или недооценили свои прогнозы и силы. И теперь этот опыт обязательно нужно учесть при составлении свежего роадмапа. Так вы научитесь избегать серьезных ошибок в своем планировании. Подробный пример расчетов будет ниже.  Как видите, формула простая. Мы берем Reach, корректируем его с помощью Impact и Data, а затем делим на наши трудозатраты.  Перейдем к практике. Возьмите за основу этот шаблон, сделайте себе копию с которой будете работать. Итак, приступаем. Расчехлите свой бэклог. В нём у вас скорее всего уже собраны пожелания клиентов, инвесторов и партнеров. Возможно там же вы храните список будущих продуктовых экспериментов, баги и возможные задачи гигиены. Уверен, что у вас также собраны возможные улучшения после конкурентного анализа. Если у вас всё это есть – вы большие молодцы! Теперь добавим к этому списку возможные маркетинговые активности на предстоящий квартал и внесем всё это в наш будущий roadmap в колонку Ideas.  На этом шаге абсолютно нормально видеть список, который будет вас пугать своим объемом. Не поддавайтесь соблазну преждевременно убирать из него что-то без подсчета Total. Может оказаться так, что задачи которые вы считали минорными, окажутся жизненно необходимые и наоборот. Теперь, для каждой задачи нужно проставить соответствующий тип. Задача так или иначе должна относиться к одному из следующих типов: Awareness, Acquisition, Activation, Retention, Revenue, Referral и Health.  Давайте кратко напомним, что эти задачи подразумевают. Awareness включает маркетинговые активности, которые растят узнаваемость вашего продукта и заставляют вспоминать пользователей в момент передвижения по лестнице Бена Ханта.  Acquisition работа с каналами по привлечению трафика в продукт. Обычно речь про новый трафик.  Activation включает работы по улучшению конверсий из первого контакта с продуктом до прохождения регистрации в нём.  Retention включает работы которые должны побуждать ваших зарегистрированных пользователей чаще пользоваться вашим продуктом, сайтом, приложением.  Revenue отвечает за разовые и регулярные платежи. Referral включает работы, которые побуждают ваших пользователей рассказывать о вашем продукте своим близким. К примеру, приглашать друзей и коллег использовать ваш сервис или приложение.  Health включает задачи по исправлению багов, технические работы по обновлению ПО, рефакторинг кода, автоматизация процессов для сокращения Time To Market. Теперь давайте посчитаем на какое количество пользователей повлияет каждая задача. Не забывайте, что число должно быть привязано к периоду. К примеру, месяц или квартал. Вот несколько примеров: если вы запускаете рекламу на привлечение трафика, это будет число уникальных пользователей пришедших на сайт или установивших ваше приложение; если речь про исправление бага или оптимизацию воронки активации, тогда нужно вписать число людей которые столкнутся с этой ошибкой или сколько людей пройдут на следующий шаг воронки; если речь про Retention задачи впишите число пользователей которые дополнительно будут возвращаться в будущем по сравнению с текущим периодом;  если речь про выручку, напишите свои ожидания о количестве человек совершивших оплату в рамках периода; если вы планируете обновление БД, значит речь про число пользователей  которые работают с этой базой и пострадают в случае ее поломки. Теперь, когда у нас проставлены предположительные охваты по каждой задаче, нам необходимо определиться с приоритетами. Здесь нужно вспомнить о жизненном цикле вашего продукта – от зрелости продукта меняются и приоритеты. Вот несколько примеров как они могут быть расставлены. 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. В данном случае трактовать можно так: команда считает, что продукт не имеем серьезных ошибок и у него все хорошо с возвращаемостью, поэтому надо увеличивать выручку и трафик, а также поддерживать узнаваемость на рынке. На этом шаге команда должна использовать свой предыдущий опыт. Опытные команды наверняка замечали, что их ожидания в прогнозах зачастую расходятся с фактическим результатом. К примеру, рассчитывали, что рекламная кампания приведет в продукт 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, то вспомните про прыжки веры, человеческие факторы, конструктивные поломки, ошибки с оценкой рынка и многие другие напасти, которые встречаются в мире продуктовой разработки. Этот шаг про оценку трудозатрат. В каждой команде свои расчёты. Кто-то измеряет в спринтах, кто-то в человеко-днях, кто-то использует S, M, L, XL, XXL. Вашей команде важно лишь помнить о том, что роадмап составляется на конкретный период. К примеру, если вы работаете двухнедельными спринтами и составляете роадмап на полугодие, то в вашем распоряжении 26 календарных недель или 13 спринтов. И поэтому вам надо быть готовым, что вы что-то не успеете сделать, а значит надо пожертвовать этим. Но к счастью, на финальном шаге объективно определиться с этим вам поможет Total. Вы должны помнить, что оценка включает в себя время на подготовку (спецификацию, исследование рынка), на разработку (дизайн, программирование, подготовка серверов, тестирование), на возможный продуктовый запуск (маркетинг и pr).  Если говорить про частный случай оценки технических работ, то это выходит за рамки этого фреймворка. Но если вашей команде в некоторых случаях добыть оценку будет довольно сложно без мясистой спецификации, с неопытным проджектом или командой которая еще не прошла огонь, воду и медные трубы. Могу рекомендовать известные подходы – посмотрите на похожие готовые задачи в таск трекере, обратитесь к опытным коллегам, проведите покер внутри команды для получения усредненной оценки, помножьте это на человеческие факторы и технические риски.  Вы дошли до финала! Осталось совсем немного. Все, что теперь нам осталось, это сделать сортировку по колонке Total от большего к меньшему.  Вот и все. Надеюсь фреймворк позволил вам порефлексировать над продуктовым планом без эмоций, вы смогли сделать наглядный роадмап и получить для себя инсайты. Если вы захотите связаться со мной, форма для связи и контакты есть в шаблоне. Спасибо, что дочитали до конца. Желаю попутного ветра вам и вашему продукту на пути к берегам изобилия!  Предприниматель, Стартапер, Программист