Продуктовый бэклог в 2023 году? Вы серьезно?
Алексей Пименов в продолжние своего доклада https://platform.productland.ru/library/ispolzovanie-kanban-method-i-f4p-framework-dlya-upravleniya-produktovoi-strategiei
Процесс управления продуктом - это сложная комплексная деятельность, в ходе которой необходимо рассмотреть огромное количество возможностей, которые существуют на рынке, для развития нашего продукта и из них выбрать только те, которые принесут максимум пользы, будут в рамках продуктовой стратегии и их количество будет равно возможностям вашего сервиса поставки (читай ваших команд разработки).
Сейчас во многих компаниях этим зачастую не заморачиваются и предпочитают хранить все клиентские запросы в одной помойке с названием Бэклог. Почему я употребил слово «помойка» относительно бэклога. Дело в том, что в нем хранится и то, что надо сделать обязательно и то, что непонятно и то, до чего не дойдут руки, но жалко выкинуть и это все лежит в одной куче, размер которой может быть огромен, гниет и пахнет. А продакт менеджеры изобретают механизмы скоринга и приоритезации, чтобы из глубин этой помойки на поверхность всплыло (желательно автоматически) что-то полезное.
Наверное этим абзацем я достаточно сильно вас уже разозлил, но где-то краем мозга вы все же понимаете, что в чем-то я прав, ведь для скоринга бэклога вам нужно собрать какие-то данные. А везде в бэклоге эти данные собраны? А как вы управляете процессом сбора этих данных?
Когда-то на ProductCamp я делал доклад на тему процесса управления продуктом и того, как можно его описать в виде канбан-доски: https://platform.productland.ru/library/ispolzovanie-kanban-method-i-f4p-framework-dlya-upravleniya-produktovoi-strategiei
Давайте сейчас рассмотрим то, как можно это все сделать себе на практике и как этим пользоваться.
Наш процесс лучше всего рассмотреть с точки зрения реальных опционов - термин из финансовой среды. Реальным опционом можно рассматривать приобретение компанией, путем осуществления некоторых затрат, права принятия определенного управленческого решения в будущем, которое сопровождается снижением неопределенности будущего в период между приобретением опциона и решением по исполнению опциона.
Переводя на язык продуктового управления, вы берете с рынка какую-то функциональность, которую можно реализовать в продукте (вы может называете ее продуктовой гипотезой). Будучи реализованной она может принести пользу клиенту и деньги вам, а может и нет - у вас есть риски. И есть некоторый момент времени в который вам необходимо принять решение - надо эту идею реализовать или не надо. И есть инвестиция - проведение исследований, расчетов, выяснения деталей и т.п. которые вы можете сделать, для того, чтобы более правильно принять решение о том, надо эту функциональность реализовать или нет.
Вам повезло, если у вашего продукта всего один менеджер продукта (а может и не повезло, ибо в это одно лицо попытались запихнуть кучи компетенции, или про какие-то компетенции забыли и продакт менеджер упускает какие-то активности), но если он не один, то у вас может появиться целая команда.
Члены которой могут быть:
- разными по специализации (продукт менеджеры, продуктовые исследователи, маркетологи, клиентские менеджеры и т.п.)
- разными по воронке (менеджер по привлечению, менеджер по конверсии, менеджер по возврату и т.п.)
- разными по каналам
- и т.д.
Это все к чему? Это все к тому, что у вас в процессе управления продуктом завязано множество людей и их бы стоило собрать в одну кучу и устроить им воркшоп. И основной вопрос этого воркшопа будет:
Что нужно сделать и какие данные нужно получить, чтобы однозначно ответить на вопрос: «Это нужно сделать в нашем продукте или нет?»
Воркшоп по построению процесса
Итак, начнем…
Шаг 1: Знания для принятия решения
Задайте группе вопрос: “Какие знания вам необходимо получить (обычно) для того? чтобы принять решение о том? что какой-то из опционов надо обязательно сделать”
Попросите их записать результат на стикеры.
В результате вы можете увидеть следующие вещи:
- Знание о том, что экономика сходится
- Знание о том, что у клиента есть такая потребность
- Знание о том, что это реализуемо
- Знание о технологических рисках реализации
- Знание того, что у нас есть и выделен бюджет на доработку
- Знание о том, сколько времени займет реализация
может быть много других вариантов, все зависит от вашего контекста и от опыта вашей команды
Шаг 2: Активности по накоплению знаний
Дайте группе задание: “Описанные вами знания получаются в виде каких-то активностей. Напишите к каждому из знаний на стикер по одной или более активностей, которые вы делаете/знаете что надо делать”
В результате мы можем понаблюдать как люди будут записывать достаточно хайповые фразы и аббревиатуры или же просто опишут собрания и комитеты:
- CJM
- JTBD
- Глубинные интервью
- Бюджетный комитет
- Обсуждение с командой разработки
- Подсчет юнит экономики
и многое другое
Шаг 3: Определение последовательности
Дайте группе задание: “Зафиксированные вами на стикерах активности, возможно имеют последовательность. Без одной активности не стоит или невозможно сделать другую активность. Расположите их последовательно и обсудите, почему последовательность именно такая. Возможно какие-то активности надо делать параллельно, расположите стикеры с ними в параллель, но не злоупотребляйте этим (не надо бездумно среду строить так, что все надо делать параллельно и одновременно)”
В результате у вас появится какая-то последовательность, возможно в ней будут параллельно идущие активности. Пора определиться с критериями завершения данных активностей.
Шаг 4: Критерии завершения активностей
Здесь мы даем задание: “Для каждой активности напишите критерии, по которым вы сможете точно понять, что данная активность для данного опциона завершена. Критерии должны быть формальные и измеримыми”
По сути ваша команда будет готовить чеклист, пройдя по которому можно будет понять, закончена ли данная активность или нет.
На данном этапе ваша доска со стикерами может начать выглядеть уже так:
Шаг 5: Вспоминаем текущую стратегию
На данном этапе нам надо освежить в памяти команды вашу продуктовую стратегию, если выработка стратегии и ознакомление с ней команды было недавно, то данный шаг можно опустить.
Дайте команде задание: “Напишите на стикерах то, что вы знаете о текущей продуктовой стратегии, какие поставлены KPI или выработаны OKR вокруг нее, на чем делается фокус, что считается менее важным?”
В результате у нас получится рисунок стратегии, который мы сможем использовать в следующем шаге.
Шаг 6: Критерии отбрасывания
Если активность завершена, то у нас для опциона есть два пути:
- Перевести его в следующий этап
- Выбросить его как непригодный для дальнейшего рассмотрения
Отбрасывание опциона может идти по разным причинам:
- Опцион не подходит под стратегию компании (например у нас стратегия на привлечение клиентов, а опцион слабо на него влияет, но сильно влияет на удержание)
- Опцион не влияет на показатели успешности (например у нас есть несколько OKR выбранных на квартал и опцион никак не влияет на их достижение)
- Не сходится экономика - опцион не приносит прибыли или приносит прибыль в таком размере, что лучше его не делать (слишком мало)
- Не соблюдается баланс между усилиями по реализации опциона и выгодой от его реализации (делать долго, заработаем мало)
и многое другое.
Напомните эти причины вашей команде и дайте им задание: “Напишите на стикерах критерии, по которым с каких-то активностей опционы должны оказаться выброшенными. Смотрите на стратегию компании, поищите там эти критерии”.
В результате мы получим набор формальных признаков для каждой из активностей, в которой происходит накопление информации для принятия правильного решения по опциону.
Порой это может выглядеть как полный хаос, но поверьте, та команда, которая это сгенерила - понимает что делает:
Шаг 7: Визуализация дискавери процесса
Дайте команде задание нарисовать доску с этапами, каждый этап которой - это активность. Напомните, что между этапами могут быть буферы, где работа ожидает освобождения ресурсов или назначенного собрания. Разместите на доске критерии завершения для активностей и критерии отбрасывания. В результате вы можете получить что-то типа такого:
А что дальше…
А дальше вам надо начать пользоваться данной визуализацией и процессом. Первым делом неплохо было бы сделать статусные собрания.
Статусное собрание
Статусное собрание не обязательно должно быть ежедневным, собирайте свою команду у доски согласно частоте обновления информации. Выбирая частоту собраний пользуйтесь следующим правилом: Если вы собрались, а обсуждать нечего - вы собираетесь слишком часто. Если вы собрались и обсуждений слишком много и даже что-то упускается и забывается - вы собираетесь слишком редко.
Формат данного собрания должен быть следующим
Вы идете по доске справа налево по всем опционам и задаете следующие вопросы:
- Что надо сделать, чтобы завершить активность по данному опциону?
- Когда эта активность будет завершена?
- Возможно стоит этот опцион отбросить?
- Есть ли какие-то проблемы?
- Нужна ли какая-то помощь?
Такое собрание легко поможет вам сфокусироваться на продвижении по доске самого ценного, отбрасывании лишнего. Также может дать вам понять, что вы берете на себя слишком много работы или рассматриваете одновременно слишком много опционов.
Вообще, шаг в построении такой доски ведении статусных собраний - это только начало. Существует еще куча инструментов оптимизации данного процесса, выравнивания его с продуктовой стратегией, улучшения охвата опционов и конечно же выстраивания баланса с Product Delivery, но это уже темы для других статей и докладов. Берите на вооружение данный воркшоп, выстраивайте свой процесс управления продуктом, выбрасывайте бэклог и механизмы его приоритезации, наступила эра Product Discovery процессов!
Присоединяйся к чату комьюнити
Будь в курсе всех новостей, обращайся за помощью к коллегам и находи единомышленников!
