Как один CPO становился CEO. Продуктовый процесс с нуля
Привет!
Я, Роман Лаврентьев, теперь CEO at Sifox. Мы делаем IT-продукты для телеком операторов и продаем их пока не по всему миру, но бежим туда (в мир) со всех ног. Иногда я пишу о том, как решаю задачи на посту CEO. Надеюсь, что это может быть полезно.
В самом начале в Sifox я был CPO. И отвечал за создание новых бизнес решений и развитие текущих продуктов. На курсе Reforge (американская школа product management) по продуктовой стратегии, я услышал одну очень важную для себя фразу: "Продакт менеджера оценивают по успешности тех фич, которые он запускает, а CPO — по влиянию, которое он оказал на бизнес«. Наверное, интуитивное понимание этой позиции и привело меня к позиции CEO. Несмотря на большое желанию самому залазить »по уши" в продукт, приходилось сдерживаться. Как CPO, я сфокусировался на создании продуктового процесса, поиске подходящих ребят в команду и все больше отрывал себя от участия в исследованиях, управлении беклогом гипотез. В статье хочу рассказать про свой опыт создания продуктового процесса с чистого листа.
"Продакт менеджера оценивают по успешности тех фич, которые он запускает, а CPO — по влиянию, которое он оказал на бизнес"
Предпосылки к созданию процесса.
Стартовый артефакт был наброском процесса в Miro. Предпосылки были следующие:
- в компании есть неформализованное облако идей
- решение о запуске пилота принималось только основателями компаниями
- большенство идей не превращались в гипотезы и не проходили валидацию
- при этом в компании были и есть продукты на поздней стадии развития, в которых тоже появлялись гипотезы.
Исходя из этой диспозиции, у меня получился микс своего опыта и traction методологии ФРИИ.
Основные этапы
- Накопление идей — до сих один из самых сложных этапов, с которым есть проблемы. Часто идеи появляются в чатах, переговорах или просто остаются в головах. На данном этапе для меня важно дать понять команде, что любые идеи приветствуются (правило некритического принятия), и я готов принимать их в любой форме. Из инструментов, на этом этапе, не сработали: спец. почта, и периодические рассылки-напоминалки. Сработал официальный чат, куда все закидывали свои идеи. Сейчас пришли к форме, что после обсуждения идеи, создатель пишет короткий документ в Confluence. Затем самое интересное: превращаем идею в гипотезу, и после этого я забираю ее в беклог.
- Продуктовый комитет — 0 (ПК-0). Как только у кого-то из продактов моей команды освобождалось время для проверки гипотезы, мы собираем ПК-0. Внутри компании я создал эту сущность (звучит так, как будто я играю за бога в какой-нибудь старой стратегии) из ключевых людей команды: фаундеры, СТО, PMO и я. Задача ПК-0 проголосовать за выделение ресурса на проверку этой гипотезы, посмотреть на нее с точки зрения стратегии. Если ПК голосует «За» — значит мы идем дальше в Product Discovery. На этом этапе нельзя допускать холивара на тему: есть ли рынок, проблема или их нет. На все эти вопросы отвечает product manager на следующем этапе.
- Product discovery — этап-квинтэссенция профессии product manager. На этом этапе мы первым делом выкристаллизовываем risk assumptions, которые нужно проверить. Пытаемся декомпозировать задачу и разобраться с подходящей методологией для проверки гипотезы: JTBD, простой CustDev, аналитика данных или маркетинговое исследование. Этот этап делится на три части: само исследование, tech feasibility (проверка на тех. реализацию) и создание артефактов.
- ПК-1.0 — защита нашей гипотезы. Причем защитой мы называем не только факт, что гипотеза подтвердилась, но и если она не подтвердилась. И здесь мы пытаемся с командой относиться к этому, как к победе, даже если гипотеза не подтвердилась. Это важно: команда продактов должна показывать реальность, а не отражать фантазии фаундеров или создателей идей.
- MVP — здесь все понятно. Описываем scope, ищем ресурсы, идем к sales team и просим помощи, чтобы зайти с пилотом к клиенту (в нашем случае — к телеком оператору).
- ПК-2.0 — собираем ПК и смотрим на цифры и метрики. Что мы считали в фин модели до выпуска MVP, и что получили после теста. Собираем learnings: где просчитались и почему.
- Tuning — cюда сразу попали существующие продукты, а также те продукты, которые вышли из MVP и прошли ПК.2.0. На этом этапе три шага. Создание фич, этап допродажи этих фич, если это требуется, и roll out. Причем, если фича требует больших ресурсов, мы пускаем ее на этап ПК-1, и дальше по всем этапам.
- Scaling — это самая желанная наша стадия. Мы продаем наши IT решения телеком операторам по всему миру, а значит, как только мы сделали успешный продукт для оператора в РФ, мы начинаем подготовку и упаковку этого продукта для международного рынка.
Так у нас выглядят этапы в продуктовом процессе.
Продуктовый манифест и Jira flow
Дополню, что в момент создания процесса мы сделали релиз еще одного документа, который описывает этапы, подходы и взаимодействие в команде. Этот документ должен жить и обновляться, дополняться learnings и нести ясность и лаконичность в этот процесс.
Чтобы всем в команде было понятно на какой стадии находятся наши продуктовые гипотезы, мы сделали отдельную доску в Jira, которая отражает весь процесс:
В общем, становление продуктового процесса в команде с нуля — вещь не самая простая. Мы еще многому учимся и меняемся, но есть ощущение, что за это время продуктовый процесс из хаотического состояния перешел в структуру и форму. За это время мы пропустили через процесс более десяти гипотез: три вышли в пилот, остальное пришлось «отстрелить».
Роман Лаврентьев, CEO at Sifox.
Больше про продукты, фреймворки на мой канале в Телеграмм
Роман, спасибо за этот материал. Создаю сейчас подобный процесс в своей команде, разрабатываем мобильное приложения для тренировок дома.
Расскажи пожалуйста в трёх словах о «JTBD, простой CustDev, аналитика данных или маркетинговое исследование». Как вы их проводите?
Роман, спасибо за отличную возможность заглянуть внутрь реального процесса разработки продукта. Какая у вас получается статистика, сколько процентов идей доходит до MVP и сколько в итоге попадает в Scaling ?