По материалам выступления на конференции Product Sense.

Адаптировал материал из видео в статью Константин Серов.

Считается, что продакт-менеджеры должны помогать компании заниматься тем, что имеет смысл, и не заниматься тем, что бессмысленно. Они фокусируют команду на действиях, которые приносят ценность бизнесу, нравятся пользователям, повышают продажи, средний чек, LTV, ROI и много других умных слов, а всё остальное, ненужное, отсекают. Это похоже на подход Lean, и большинство продакт-менеджеров, которых я знаю, разделяют его.

В то же время рабочий процесс продактов включает в себя занятия, в полезности которых я сомневаюсь. Например, излишние совещания и синхронизация. Я уверен: если бы продакты тратили то же время на общение с пользователями, они бы принесли бизнесу больше пользы.

Как так вышло, что люди, которые отвечают за эффективность всей компании, сами не слишком-то эффективны?

Немного истории

Практически все продуктовые компании понимают, что должен делать продакт-менеджер: тестировать продуктовые гипотезы, приоритизировать разработку, выпускать MVP на рынок как можно раньше, собирать фидбек, считать юнит-экономику, тестировать новые каналы и так далее.

С разработкой ещё проще: она должна делать то, что велит ей продакт-менеджер и/или его помощники: аналитики, тестировщики, маркетологи. Как делать тоже понятно: есть Scrum, Kanban, Agile и много других проверенных подходов и методологий.

Теперь ещё раз посмотрим на работу продакта. Все более менее знают, что он должен делать. Но как организовать процесс так, чтобы это было эффективно? На рынке ещё нет устоявшихся парадигм, поэтому каждая компания придумывает что-то своё.

В этой статье я поделюсь с вами кейсами, которые показывают, как устроены процессы продуктовых компаний на разных этапах развития. Те кейсы, в которых продукт один, мои личные: я сам работал в этих проектах; кейсы с линейкой продуктов принадлежат моим клиентам, которых я консультировал. Материал будет максимально обезличенный, но от этого не менее полезный.

0. Стартап, который ищет свой product/market fit

Или когда продукта ещё нет

Представим себе команду из 3–4 человек, которая решила делать стартап. На данный момент у них есть только идея, которую ещё предстоит проверить. Скорее всего, на старте команда будет выглядеть так:

• Автор идеи. Он, скорее всего, будет продактом,
• Программист. Потому что все знают, что нужны программисты,
• Дизайнер. Куда же без дизайнера,
• Аналитик (опционально).

На данном этапе внедрять что-либо сложнее пробковой доски бессмысленно, потому что если такая маленькая команда не может договориться, как работать, вряд ли у них получится сделать бизнес.

Их главная задача сейчас — тестировать как можно больше гипотез как можно быстрее.

В общем виде процесс выглядит так:

Конечно, у каждой гипотезы есть этап подготовки, на котором определяется что тестировать, на какой аудитории, каким образом, и как интерпретировать результаты.

После непосредственного тестирования продакту нужно собрать данные, проанализировать их, и потом определить, удачная гипотеза или нет. Возможно, сформулировать новые гипотезы.

Процесс прохождения гипотезы от стадии «Идеи» до стадии «Готово» называется Lead Time, и именно над оптимизации этой метрики следует работать стартапу, который в поиске product/market fit.

Некоторые стартапы уже на этом этапе пробуют внедрить Scrum, но вскоре отказываются от этой идеи, потому что митинги и совещания съедают всё время. Как же оптимизировать этот процесс?

Как ни странно, чтобы за одно и то же время проверять больше гипотез, нужно сократить количество одновременно проверяемых гипотез. В Канбане это называется ввести WIP-лимиты — Work in progress, одновременное количество задач в работе.

Дело в том, что когда количество одновременных задач высоко, силы тратятся не на задачи, а на переключение между ними. Поэтому, чтобы экономить время, команды искусственно ограничивают количество задач в работе. Выглядит это примерно так:

Такая организация процессов может работать довольно долго, так как позволяет быстро гонять карточки по системе. Однако, всё хорошее когда-нибудь заканчивается, и это когда-нибудь наступает после…

👉 Статья в тему: «Система целеполагания по Smart»

1. Стартап с product/market fit

Когда гипотеза ценности найдена, и нужно пилить продукт

Стартап нащупал свою нишу и те ценности, за которые пользователи будут платить. Теперь продукт нужно кодить и развивать. В этот момент появляется команда разработки, которая не может работать в старой системе. Если продакт-менеджер может проверить 10 гипотез за неделю, то разработчик может накодить только одну задачу за неделю (цифры условные). Контроль и управляемость теряется.

Более того, у разработчиков свой workflow — этапы разработки отличаются от этапов проверки гипотез.

Возникает вопрос: как подружить между собой продактов и разработчиков?

Первое, что приходит в голову, это общий список задач. Его ещё называет «бэклогом». Продакты накидывают кучу задач в этот список, а разработчики по очереди их выполняют.

Проблема в том, что Scrum не объясняет, какие из этих задач делать первыми. Всё ложится на плечи продакта (в Scrum его называют «product owner») — он же умный, пускай и приоритизирует.

2. В продукте уже есть первые пользователи, и их количество растёт

Когда есть ядро постоянных пользователей, а Retention вышел на плато

Проблемы начинаются после запуска продукта, так как в бэклог начинают попадать задачи ещё из двух источников: баги от пользователей и предложения по рефакторингу кода от разработчиков.

Баги всегда появляются, когда у продукта есть пользователи, а разработчикам действительно нужно переписывать архитектуру, потому что, если этого не сделать, через пару месяцев продукт развалится.

Все это приводит к 200 задачам в бэклоге, и совершенно не понятно, какие из них делать первыми.

Первое, что можно попробовать сделать, разбить бэклог на три части. Это визуально упрощает задачу, однако если суммарно у команды 200 задач, а за неделю они физически успевают сделать 10, то со 100% вероятностью можно сказать, что они никогда их не сделают. Почему? Да потому что каждую неделю что-то меняется, всегда будут новые задачи, инсайты и гипотезы. Через 6 недель продукт может вообще поменяться и пойти в другую сторону.

Снова прибегнем к Канбану: он говорит, что нужно ввести лимиты на максимальное количество задач в списке. Если команда, например, введёт лимит по 10 задач на список, ей каждую неделю нужно будет приоритизировать всего лишь 30 задач, а не 200, как было раньше.

Но как свести приоритизацию к минимуму, или вообще от неё отказаться? Последнее кажется безумным, но только на первый взгляд. Наблюдая за самоорганизовывающимися командами, я увидел достаточно, чтобы сказать: отказ от приоритизации совместим с эффективной работой.

Первый шаг на пути к этому — дать разработчикам самим решать, чем заниматься в первую очередь. Когда я говорю про это на конференциях, мне обычно возражают: «Но как же так? Если разработчикам дать волю, они будут заниматься только архитектурой: будут брать по очереди задачи из списка, пока все 10 не переделают».

Да, такое возможно. Но не потому, что разработчики «мудаки», и не хотят принести пользу продукту. Наоборот, разработчики, как правило, хотят предлагать кучу идей по развитию продукта, и готовы их реализовывать (если у вас не так, значит, у вас проблемы гораздо серьёзнее, чем организация процессов).

Разработчики могут хотеть 100% времени переписывать архитектуру в двух случаях:

1. Скорее всего, настал критический момент, когда без переписывания архитектуры уже никак: продукт просто развалится. Такое было в своё время в Додопицце. Они выросли с 200 до 400 пиццерий за год, и из-за плохой архитектуры система начала лагать уже на 250-й пиццерии (а эта система используется на всех торговых точках). Так как планы были и дальше кратно расти, убытки от сбоев системы росли в геометрической прогрессии.
2. Разработчики не понимают зачем нужна эта задача, какая от неё польза. К сожалению, не все продакт-менеджеры готовы следовать примеру Дмитрия Потапенко, одного из владельцев сети «Пятёрочка»: каждую неделю работать один день за кассой и мыть полы для того, чтобы лично видеть лица клиентов, их настроение, интересы и проблемы.

Вторая проблема, конечно, встречается гораздо чаще. Продакты отдаляются от своих клиентов, в то время как разработчики каждый день отвечают на сложные вопросы второй линии техподдержки и фиксят баги. Это может приводить к тому, что продакты просто ставят задачи, без объяснения зачем. Если хотите, без «продажи» своих задач разработчикам.

Чтобы решить эту проблему, достаточно ввести простое правило:

«Никто не начинает работу до тех пор, пока не поймёт, зачем это нужно»

Ну и начать относиться к своим разработчикам на равных, как к взрослым, самостоятельным и ответственным людям.

Для закрепления этого правила на системном уровне, нужно ввести ещё одну доску для продактов с этапами «Оформление», «Продажа», «Решение». Благодаря тому, что продакты сильно сэкономят на бессмысленной приоритизации, у них освободится время на небольшую работу по продаже своих задач разработчикам. Если разработчики будут понимать, что эта задача принесёт рост в 2 раза, или что все пользователи давно хотят эту фичу и будут ей пользоваться, они сделают её в первую очередь, не смотря на то, что работа может быть сложная и неприятная. Когда человек понимает зачем, ему легче справляться с трудностями.

Конечно, первое время работать по новым правилам будет сложно. Чтобы облегчить груз ответственности разработчиков, Канбан предлагает ввести (да-да, ещё одно ограничение) фиксированное соотношение задач в работе из каждого списка.

Об этом соотношении можно и нужно договариваться, передоговариваться и всегда его обсуждать, потому что на каждом этапе роста продукта соотношение будет разное. Например, на старте продукта на архитектуру должно уделяться 0–5% времени, а на баги 30%. Когда продукт уже зрелый, это соотношение может поменяться, потому что к зрелому продукту высокие требования по качеству.

3. Бизнес с отлаженными процессами и линейкой продуктов

Когда есть несколько продуктовых команд и несколько команд разработки

По большому счёту, продакт-менеджерам не важны конкретные этапы в команде разработки. Их интересует только общий вид: «Очередь», «В работе» и «Готово». И Lead time отдела, конечно. Но как автоматически схлопывать доску разработки до трёх этапов, чтобы не приходилось вести две доски одновременно?

Я не знаю решения этой проблемы в оффлайн мире, когда карточки-стикеры ездят по пробковой доске — в таком случае действительно пришлось бы вести две доски, и постоянно синхронизироваться между ними. В онлайн мире есть Кайтен — наш продукт, который специально создан для работы по Канбану и другим гибким методологиям.

В Кайтене можно создавать пространства с досками для разных отделов, при этом отображая одни и те же доски в разных местах. Например, в пространстве разработчиков не нужна вся кухня продактов — им достаточно видеть только последнюю доску «Оформление», «Продажа», «В корзину» + свою девелоперскую доску с подробными этапами, которые они могут менять, как хотят. Продакты же могут вставить доску разработчиков в своё пространство в упрощенном виде, и при необходимости открывать полную версию.

Пространства в Кайтене позволяют компании работать на разных уровнях, и при этом быть синхронизированными.

Если завтра появится новая команда разработки, она легко встроится в существующий процесс.

Когда компания становится совсем большой, с советом директором и целым оркестром из продуктов, эту модель можно смасштабировать ещё выше, на уровень топ-менеджмента. Опять же, чтобы не перегружать пространство директоров, Кайтен позволяет размещать упрощенные доски продактов.

Резюме. Выгоды от использования Кайтена

Благодаря сквозной системе построения задач, продакты могут экономить время на приоритизации и синхронизации. Это позволяет больше времени уделять основной работе: тестированию новых гипотез, общению с пользователями и так далее.

С помощью отслеживания Lead time можно получить ценную информацию об эффективности разных отделов и компании в целом. Статистика позволяет увидеть распределение выполненных задач по дням с начала их старта. Это полезно при составлении роадмапа или при обещании клиентам сроков выполнения задач.

Взглянув на график, можно сказать: поступившая задача с вероятностью 50% будет выполнена за 4 дня и, с вероятностью 85%, за 12 дней. Больше не нужно гадать о сроках при ответе клиентам. Прогнозы больше не будут базироваться на субъективных оценках разработчиков.

Аналитический модуль в Кайтен позволяет в два клика строить такие графики

Роадмапы можно оформлять, как JetBrains. Все будущие фичи они сортируют по категориям:

• Точно сделаем,
• Скорее всего успеем,
• Если останется лишнее время.

Это даёт понимание, чего ждать от новой версии, и избавляет от привычных, но бесполезных диаграмм Гантта.

Лимиты одновременно выполняемых задач и лимиты на максимальное количество задач в списке позволяют сфокусироваться, быстрее завершать задачи и снизить затраты на приоритизацию.

Канбан — это набор инструментов, который каждая компания адаптирует под свои нужды, а не наоборот. Именно поэтому он подходит для компаний любых размеров: нужно просто внедрять новые правила по мере роста.

Кайтен спроектирован для работы по Канбану. Если вы хотите попробовать Кайтен, заходите на сайт https://kaiten.ru и напишите в поддержку «Хочу жить. Устал приоритизировать», и мы дадим вам дополнительный месяц работы бесплатно при оплате на год.

Автор Дмитрий Абрамов

Интересные статьи

Ключевую роль в управлении компанией должны играть решения, а не данные

Семь преимуществ мышления, при котором на первое место выступает принятие решений

Блог КайтенViacheslav Tsyrulnik

Кейс Сколково: навели порядок в работе с помощью Kaiten

Ренат Батыров — генеральный директор технопарка «Сколково» поделился опытом использования Kaiten

Блог КайтенViacheslav Tsyrulnik

Как делать то, что принесет больше пользы бизнесу

Вам помогут скоринговые модели RICE / ICE и покерное планирование

Блог КайтенViacheslav Tsyrulnik