Чтобы ответить на вопрос, что делать с продуктом прямо сейчас, сколько ресурсов на него тратить и как приоритизировать бэклог, важно понимать, на какой стадии зрелости продукт находится. Более того, от этого зависит и правильное соотношение проектной и операционной работы.
Жанна Шебаршова, CPO в Контуре, рассказала, какие этапы жизненного цикла продукта бывают и как это использовать на практике для развития продукта и правильного планирования.
Примечание: это не застывшая система. Понимание жизненного цикла постоянно уточняется, пересматривается и корректируется, исходя из опыта собственной продуктовой работы и опыта других продуктов.
Для чего нужно понимать жизненный цикл продукта
Понимание, на каком этапе жизненного цикла находится продукт, дает доступ к накопленным знаниям сообщества: какие мероприятия, ресурсы и компетенции нужны на том или ином этапе, какие риски и типовые ошибки существуют, какова примерная длительность каждого этапа и какие ожидания есть на выходе. Мы расписали четыре этапа, хотя на самом деле их шесть:
- Инициация
- Формирование и проверка гипотезы проблемы
- Формирование и проверка гипотезы ценности
- Формирование и проверка гипотезы решения
- Масштабирование
- Поддержка
Первые три этапа: инициация, формирование и проверка гипотез проблемы и ценности — мы объединили в один. С точки зрения организации процесса, методов исследования и выделения ресурсов они работают по похожим принципам, меняется только количество ресурсов.
0. Инициация — прото-конвейер
По классике инициация — это отдельный этап, но мы в Контуре завернули его в процесс, который включен в исследование проблемы.
Цель этапа: отобрать гипотезы для более полной проверки, потратив на сбор информации по каждой гипотезе не более 4 человеко-часов.
На входе: идея, которая появилась у любого участника команды, в том числе входящие предложения или реакция на резкое изменение внешней среды.
Внутри этапа: собираем доступную информацию (кабинетный мини-ресерч, сбор имеющихся данных, встречи).
На выходе: понимание, интересна нам гипотеза или нет, уточнение гипотезы.
Длительность: не более 4 человеко-часов.
Проект: нет, работа ведется в рамках операционной деятельности менеджеров, ответственных за развитие продукта.
Команда: менеджерские роли, отвечающие за развитие продукта в целом (продакты, продуктовые маркетологи, менеджеры проектов развития).
Типичные ошибки на этом этапе:
- Не закладывать время менеджеров на этот этап в надежде, что оно как-то само найдется и все произойдет (спойлер: не произойдет).
- Копаться в теме более 4 часов (более глубокие запросы на данные, подробное исследование конкурентов и так далее).
- Не писать заранее «командным» мозгом на какие вопросы мы хотим получить ответ в рамках первичной проверки.
1. Исследование гипотез проблемы и ценности / Research
На этом этапе у нас есть только гипотеза, и мы ее относительно дешево проверяем.
Цель этапа: подтвердить гипотезу проблемы и обсчитать «на глазок» рынок (общий, доступный и достижимый — TAM, SAM, SOM).
На входе: гипотеза.
Внутри этапа: кабинетные (метрики, конкурентный анализ, продукты-заменители) и качественные исследования, реже количественные (они дороже). У нас еще нет пользователей, есть только потенциальные клиенты.
На выходе:
- Подтвержденная проблема.
- Гипотеза рынка с объемами.
- Гипотеза ценности.
Длительность: от нескольких часов до квартала.
Проект: как правило, на этом этапе еще нет инвестпроекта.
Команда: обычно какая-то команда продукта/направления делает все на энтузиазме или внутри существующего процесса.
NB. Далеко не каждая гипотеза проходит на этап проверки гипотезы решения (MVP, рассматривается ниже) — и это нормально. Нормальное соотношение в зависимости от компетенций команды в предметной области, имеющихся данных или возможности доступа к ЦА от 10 до 100 гипотез на входе и одна подтвержденная гипотеза на выходе.
Ошибки на этом этапе:
- Низкое качество гипотез. Например, они не содержат в себе одного из параметров: описание проблемы, сегмента и ценности при решении этой проблемы.
- Низкое качество подтверждения гипотезы проблемы, когда мы не понимаем, почему это является проблемой для пользователя, в чем она заключается, зачем пользователю ее решать? Показатель низкого качества: в описании этих параметров мы начинаем использовать слово «кажется».
- Разворачивание бурной деятельности в продажах и разработке.
- Дорогие исследования. Например, запускать количественные исследования с помощью обзвона.
- Исследование гипотез, по которым у команды уже достаточно вводных для совершения прыжка веры — но при этом либо конкретный менеджер об этом не знал, либо знал, но у него слишком высокий порог для совершения прыжка веры. Решения по гипотезам, которые проходят на следующий этап, мы принимаем коллегиально, но при этом не требуется единогласного решения. Если большинство из участников команды, принимающей решение, голосуют «за», то гипотеза проходит дальше — а значит, прыжок веры совершен.
2. Исследование гипотезы решения и MVP
На этом этапе мы продолжаем исследования, начинаем применять более дорогие методы исследований, можем создавать продукт из пластилина и веточек. Мы все еще до конца не уверены в гипотезе и должны быть готовы к тому, чтобы все выкинуть.
Цель этапа: подтвердить гипотезы ценности и рынка. Нет задачи обязательно ввязываться в разработку — любые no code-инструменты тут вполне уместны.
На входе: то, что на выходе из предыдущего этапа.
Внутри этапа: проектируем концепцию ценностного предложения. Могут появляться концептуальные прототипы, тестируем гипотезу продажами, запускаем лендинги и рекламные кампании, проводим качественные исследования ценности. Можем делать (или не делать) продукт из пластилина и веточек, чтобы понять — да, это оно, то, что решает проблему, то, что покупают, то, у чего есть достаточные конверсии.
На выходе — уже подтвержденные артефакты:
- Прототип продукта, в котором пользователи достигают ожидаемую ценность (Product/Market-Fit).
- Уточненные ценностное предложение, объем рынка, конверсии, средний чек.
- Концепция тарификации.
- Работающие масштабируемые каналы продаж.
- Приблизительно подсчитанные «на салфетке» расходы на реализацию проекта.
- Снятые технологические риски.
- Рабочая методология продаж.
- Сформированное предложение по стратегии и тактике развития продукта.
Длится: от месяца до года.
Проект: может оформляться в виде малого инвестпроекта.
Команда: начинает формироваться. На этом этапе команда еще небольшая — до 10-15 человек всех ролей в зависимости от сложности продукта. Функции разделяются, появляются свои люди хотя бы на часть ставки по каждой роли. В зависимости от продукта на этом этапе могут возникать новые роли, подразделения, отделы, функциональные зоны.
Ошибки на этом этапе:
- Слишком быстро переходить на этап разработки.
- Упускать подтверждение или валидацию одной из составляющих бизнес-модели. (Это критически важно понять — внутри этапа может быть несколько итераций поиска концепции решения).
- Переходить к масштабированию.
- Не закрывать продукт, если не сходится экономика, оказаться внутри ловушки потраченных ресурсов — когда жалко все выбрасывать, потому что потрачено много сил и времени.
- Не начинать готовить заранее кого-то из команды на роль менеджера проекта.
- Переходить к масштабированию, не удостоверившись, что каналы продаж можно масштабировать.
3. Масштабирование / Scale
На этом этапе мы масштабируем то, что исследовали ранее.
Цель этапа: сделать хороший продукт и раскатать его на все продажные мощности, настроить процессы внутри команды, снизить затраты на ТП, выйти на финансовую схему.
На входе: то, что на выходе из этапа MVP.
Внутри этапа: убираем костыли, если продукт был создан на прошлом этапе с костылями (самое время для рефакторинга), масштабируем продажи, набираем команду, выстраиваем процессы и т.д.
На выходе:
- Продукт без крупного техдолга.
- Масштабированная методология продаж.
- Сформированная команда проекта.
- Выстроенный биллинг.
- Выстроенный процесс работы команды.
- Маркетинговая стратегия, увязанная с верхнеуровневыми стратегиями материнского продукта.
- Стратегия в своей нише/сегменте. Окончательно определен статус: сателлит/самостоятельный продукт, предназначение продукта.
- Должна начать формироваться модель юнит-экономики, произошло определение подсегментов клиентов продукта.
- Появилась механика выделения и анализа экономики продукта из материнского продукта (если он есть).
Длится: от пары кварталов до пары лет.
Проект: 100% должен быть инвестпроект — их может быть даже два.
Команда: сформирована, растет.
Ошибки на этом этапе:
- Слишком рано заканчивать и отдавать в поддержку продукт в плохом состоянии (не выстроены процессы, не поделены зоны ответственности, продукт не допилен — не все сценарии ценностного предложения реализованы).
- Не отделять новые структурные подразделения/отделы для выполнения каких-то задач (внедрения, логистика, активация и т.п структуры, возникшие в процессе создания продукта).
- Работать с клиентами как с единой когортой, не начать уточнение и сегментацию.
- Не передавать продукт из команд развития в команды или структуры поддержки (касается всех функций: продаж, разработки, маркетинга, продуктовой работы).
- Не воспринимать организацию передачи продукта в команды поддержки как отдельную важную задачу.
- Не выделять выручку или расходы из материнского продукта (если он есть).
- Не считать синергетическую выручку от продуктов компании или направления, ассоциированную с продажами нового продукта.
4. Поддержка / Support
Поддерживаем существующий продукт. Как правило на этом этапе уже не происходит серьезных изменений: принципиально новых сценариев или выходов на другую ЦА. Если есть необходимость это делать, то надо выделить это в самостоятельную деятельность, не обманывать себя и не пытаться сделать вид, что это развитие существующего продукта.
Цель этапа: окупить расходы и заработать на существующем продукте.
На входе: уже созданный продукт с подтвержденными каналами, ценностью, понятной экономикой. Крайне желательно, чтобы была модель юнит-экономики и уже произошло выделение подсегментов клиентов продукта.
Внутри этапа: оптимизация каналов, техподдержки, сценариев работы в продукте, актуализация продукта под меняющиеся требования внутри существующей ценности для существующей ЦА (например под требования законодательства или под новый фирстиль).
На выходе:
- С каждым годом — все более оптимизированная бизнес-модель. При «хорошей» ценности такой продукт может существовать приносить прибыль десятилетиями.
Длится: от 3 лет до условной бесконечности.
Проект: в операционном фонде, т.е. уже внутри финансовой схемы.
Команда: сформирована, может уменьшаться в размерах.
Ошибки на этом этапе:
- Не выделять новую инвестиционную деятельность в отдельное направление работы, вести ее неосознанно. Это сбивает команду с толку, привносит хаос во все подразделения, и даже может поставить под вопрос существование основного продукта.
- Не расширять кругозор команды, показывая им возможности развития и за рамками существующего периметра продукта — даже если доля ресурсов на развитие выделяется значимая, эффективность расходования этих ресурсов, будучи ограничена скоупом одного продукта, будет не максимальной.
- Не ротировать команду, особенно команду разработки — люди «засиживаются» в границах продукта, а потому не видят перспектив. Это снижает потенциал роста новых поколений профессионалов (передавать свои задачи кому-то не станешь, если опасаешься, что для тебя не найдется новой работы). И в целом снижает потенциал команды к росту и развитию, снижает их ценность для компании. В результате люди выгорают и компания рискует когда-то в будущем оставить продукт без команды.
Что важно учитывать при переходе на более зрелые этапы жизненного цикла
- Потенциальная выручка как правило «подсушивается» — у нас появляются более «твердые» факты для финмодели, они надежнее, но как правило ниже первоначальных ожиданий.
- Ресурсов с каждым этапом требуется больше, то есть расходная часть растет. Это может создавать иллюзию, что все плохо и надо срочно запускать новые идеи.
Однако это ловушка: надо прекратить сравнивать продукты (точнее их обещания) этапа исследования с продуктами этапа масштабирования. Это несравнимые деньги и, соответственно, несравнимые ресурсы.
