Растущая продуктовая компания: штат растет, а outcome снижается. Что с этим делать?

Дано: компания, которая всего за 2 года, начав с небольшой команды из шести человек, выросла во внушительный коллектив, насчитывающий уже 120 сотрудников. time-to-market на старте, то есть время, которое в среднем эта компания тратила на реализацию небольших продуктовых проектов, составляло один месяц. Как вы думаете, чему стал равен time-to-market, когда компания выросла в 20 раз? Стала ли она делать быстрее, больше и эффективнее? 

Правильный ответ: нет, time-to-market теперь стал равен 4 месяцам. 

Закономерный вопрос: почему это произошло? Мы хотели сделать ситуацию лучше, по численности выросли в 20 раз, а реальная картина получилась совсем иной.

Когда структура больше не соответствует продукту

Коренная причина этой проблемы в следующем — в процессе роста структура компании стала расходиться с продуктом. Что это значит? 

Представьте, у вас небольшая компания и некоторая продуктовая задача, например, реализовать подписку на ваш сервис. Эта задача в случае небольшой компании целиком локализуется в рамках этой компании = небольшой команды, например, 6 человек. Вместе они работают над этой задачей, сфокусированы на результате и понимают, в какую сторону им двигаться.

А теперь давайте посмотрим, что происходит, когда мы растём. Новые команды теперь локализуются вокруг функций (мобильная разработка, тестирование, продакт-менеджмент, маркетинг и т.д.), у нас больше нет подразделения, которое может выполнить эту задачу от начала и до конца (end-to-end). Поэтому задача «распиливается» (обычно кем-то сверху, силами вышестоящего менеджмента) на кусочки и каждому отделу достается определенный фронт работ, который он должен выполнить. 

Согласитесь, уже на этом этапе есть ощущение, что что-то пошло не так: кто-то задачу должен распилить, но в итоге кто-то должен этот пазл собрать. ?
И в нашем примере речь идет только об одной задаче, но в реальной жизни таких задач много. И эти многочисленные кусочки попадают в отделы, где начинается война миров борьба приоритетов.

В одном подразделении этот кусочек задачи будет иметь высокий приоритет, в другом — низкий, и это понятно, но это и убивает time-to-market.

Но это еще не всё ?

Менеджмент ведь всегда борется за эффективность, а как можно повысить эффективность наших команд — конечно же, ввести KPI. К чему приводит такая практика, вы, наверное, уже догадываетесь: мы получаем команду из серии лебедь, рак и щука. Одни топят за одно, другие хотят сначала достичь своих целей, в итоге приоритеты еще сильнее начинают разъезжаться, работая на KPI, а не на синхронизацию по продуктовым задачам. А тем временем наш time-to-market продолжает расти, и в итоге мы получаем 4 месяца или даже больше. 

Хотите убить time-to-market в вашей компании? Здесь я делюсь пошаговой инструкцией для любителей острых ощущений 🙂

Не только структура. Оргдизайн в растущей продуктовой компании

На самом деле относительно продукта разъезжается не только структура, за ней следуют и остальные элементы. На изображении выше одна из простейших моделей оргдизайна — звездная модель Гэлбрейта. Кстати, в этом цикле статей я подробно рассказываю про 9 основных моделей оргдизайна, их преимущества и главные отличия.

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

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

Что такое продукт?

Продукт занимает центральное место в модели оргдизайна, относительно него формируется стратегия, структура и остальные, связанные с ней процессы, такие как система вознаграждений, HR-политики. И наша задача — понять и определить, что такое продукт. 

Чтобы было проще ответить на этот вопрос, в качестве примера давайте рассмотрим банковские продукты. 

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

Именно вокруг таких сущностей (CRM, кредитный конвейер, маркетинг …) собирается структура, у каждой сущности есть владелец, который управляет приоритетами. Поступающие задачи не локализуются ни в одном из подразделений. Это означает, что они будут распилены на кусочки, переданы в команды, у которых уже есть свои очереди задач, приоритеты, KPI и прочие крайне важные моменты. И как вы уже понимаете, time-to-market в такой ситуации будет $#*@%!!!, то есть не поддающийся никакой критике. 

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

Мы точно хотим двигаться быстрее относительно целей CRM/кредитного конвейера/ маркетинга? И как же все-таки правильно определить продукт? Ответ очень простой. Встаньте на место клиента, подумайте, зачем он к вам приходит и что покупает. Ответом и будет ваш продукт. 

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

Собираем структуру вокруг продукта

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

Подведем небольшой итог. Что мы понимаем под продуктом? 

• Продукт – это то, зачем к вам приходит клиент. Как правило, это то, что он у вас покупает. 

• Продукт имеет бизнес-модель. То есть, представляет собой систему генерирующую доход компании, за счет удовлетворения потребности клиента.

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

Пошаговый алгоритм, как выстроить оргструктуру в компании

Шаг 1. Определить продукт/продукты

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

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

Шаг 2. Собрать структуру и оргдизайн вокруг продукта

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

Решением может стать тепловая карта. На изображении выше в первой колонке зафиксирован наш бэклог задач на ближайший квартал или 6 месяцев. Чтобы реализовать эти задачи, мы отмечаем необходимые компетенции в соответствующих колонках таблицы, используя систему оценки от 0 до 3. Например, для реализации подписки на сервис нам потребуется продуктовый аналитик, дизайнер, тестировщик, маркетолог для продвижения и юристы для решения различных правовых вопросов. 

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

Таким образом, мы определяем состав продуктовой группы в целом и состав продуктовых команд так, чтобы задачи могли быть выполнены внутри организационных единиц end-to-end. Такой подход обеспечивает необходимый фокус и устраняет барьеры для быстрой реализации задач.

Внутреннее устройство продуктовой группы может быть организовано по 3-м возможным вариантам:

1) Неспециализированные продуктовые команды.

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

2) Специализированные продуктовые команды.

Второй вариант — специализированные продуктовые команды. Мы разделяем наш список задач на несколько классов. Например, задачи по активации пользователей, привлечению клиентов, общие продуктовые задачи и монетизации. Затем собираем команды для каждого из этих классов. Каждая команда специализируется на определенной области продукта и выполняет эти задачи end-to-end. У каждой команды есть свой локальный Владелец продукта, который управляет задачами и следит за соответствующими метриками.

3) Компонентные команды.

Третий тип — это компонентные команды. В этом случае мы не меняем основную структуру организации, такую как отделы маркетинга, продаж, разработки и так далее. Вместо этого мы используем специальные координирующие процессы, чтобы перефокусировать наши команды с их функциональных обязанностей на продуктовые цели и задачи. В этом могут помочь различные методы, такие как ОКР или Spotify Rhythm, а также специальные подходы, как на примере выше Nexus. С помощью специальных процессов мы обеспечиваем работу этих команд над задачами end-to-end, пытаясь реализовать их максимально быстро, несмотря на возможные ограничения основной структуры организации. 

Подробнее о каждом типе команд вы можете прочитать в моей бесплатной PDF-книге «Оргдизайн продуктовой компании».

Итак, мы уже прошли 2 шага: определили продукт в компании и собрали структуру вокруг него. Можно ли сделать еще лучше? Да, для этого есть третий шаг.

Шаг 3. Выровнять оргдизайн относительно продукта.

Структура — это только один из элементов оргдизайна, поэтому в рамках третьего шага мы можем поработать и с остальными элементами, сделать их комплементарными друг другу.

Частая ситуация: компания внедрила продуктовую структуру, но при этом оставила неизменной систему мотивации и вознаграждения. Какая здесь может возникнуть проблема? 

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

Подведем важный итог: если вы хотите роста продукта — оргдизайн должен соответствовать этому продукту. Решить эту задачу можно в 3 шага, они будут непростыми, вы столкнетесь с мощным сопротивлением внутри компании, но сможете, наконец, справиться с дилеммой «команда растет, а outcome уменьшается»: 

1. Определите продукт и его задачи.
2. Соберите структуру вокруг продукта.
3. Выровняйте оргдизайн относительно продукта.