Оргдизайн продуктовой компании. Как выстроить структуру, которая помогает расти

История одного стартапа, или к каким проблемам приводит рост продуктовой компании

Наша история начинается с небольшого стартапа XScale (название выдумано, все совпадения случайны), который создает массовый digital-продукт. В нем работают несколько человек — маркетолог, продукт-менеджер, разработчик мобильного приложения, разработчик бэкенда, аналитик данных и веб-разработчик. Это небольшая компания, в которой все сотрудники замкнуты на клиента, то есть напрямую связаны с его задачами и между ними и клиентом или продуктовыми метриками нет промежуточных звеньев. Все они достаточно хорошо осознают, как их работа влияет на пользователя.

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

Как это происходит? Маркетологу в помощь нанимают еще одного маркетолога, и вот у нас появляются зачатки отдела маркетинга. Задач по разработке становится все больше, и команду значительно расширяют. Затем компания нанимает еще двух мобильных разработчиков и одного веб-разработчика — появляется группа фронтенд-разработки. За этим нанимают еще двух бэкендеров, и вот у нас уже отдел бэкенд-разработки. В завершении появляется команда Data Science.

Сначала дела идут хорошо, пока через полгода CEO компании не начинает жаловаться на то, что все происходит очень медленно. Реализация того функционала, который полгода назад, до расширения штата, они делали за месяц, сейчас затянулась на несколько месяцев, и конечный срок постоянно откладывается. 

Получается, компания выросла в несколько раз по численности, а outcome, возможно, даже уменьшился. Кажется странным? Но в такую ловушку попадают многие продуктовые компании. Почему же так происходит?

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

• кросс-командные зависимости, 
• целеполагание, 
• координация, 
• мотивация, 
• передача и искажение информации, 
• разные приоритеты, 
• расфокус и др.

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

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

Как решить проблему роста структуры?

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

Ну что же, пора в этом разобраться.

Вариант №1. Как обычно born-digital компании решают проблему роста структуры, и почему не всегда получается

Давайте посмотрим на то, что происходит в нашем примере дальше. Итак, в процессе роста компания нанимает множество людей, которых, как правило, затем структурирует на подразделения вокруг функций или компонентов архитектуры. При этом CEO тоже уже не справляется с задачами, поэтому у него появляется множество помощников в виде различного рода директоров (CTO (Chief Technology Officer или Технический директор), COO (Chief Operating Officer или Операционный директор) и т.д.) и продукт-менеджеров, отвечающих за разные аспекты продукта (например, монетизацию, активацию и др.).

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

Что же делать? В этот момент рождается гениальная идея — что, если каждому из этих продукт-менеджеров или директоров выделить по команде: сделать команду монетизации, активации, системы лояльности и т.д. Нарезка таких команд может быть абсолютно разная, например по этапам продуктовой воронки AARRR (Acquisition Activation Retention Referral Revenue). Я даже встречал нарезку команд по областям управления компанией: одна группа команд под COO, другая под CFO (Chief Financial Officer или Финансовый директор), третья под CTO и т.д. 

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

Что такое специализированная фиче-команда?

Многие digital продуктовые компании приходят к такому формату структуры естественным образом. Этот тип структуры называется специализированные фиче-команды (от англ. feature). Компания разделена на команды, каждая из которых фокусируется на определенной области продукта. У каждой команды есть руководитель — продуктовый менеджер, который отвечает за рост конкретного направления продукта. У него свои продуктовые метрики, с их учетом он формирует для команды поток задач (бэклог). Его команда кросс-функциональна в рамках данных метрик, то есть может end-to-end (от идеи до доставки пользователю) реализовывать задачи в этой области продукта.

ВАЖНО! Может возникнуть ощущение, что фиче-команда — это команда, которая предназначена для реализации конкретной фичи, а потом ее нужно пересобирать для другой задачи. Но на самом деле они предназначены для реализации задач в определенной области, являются стабильными на протяжении долгого времени и не пересобираются от фичи к фиче.

По такому варианту развития событий когда-то давно пошла компания Spotify, поэтому часто такую структуру называют Spotify-like структурой. По этому же пути, как упоминалось ранее, естественным образом идут многие digital продуктовые компании, и собирают все те же «грабли», как в свое время Spotify.

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

Что нужно для того, чтобы эта схема работала?

Одно из ключевых условий для работоспособности данной структуры — это независимость поставки результата разными командами (мини-продуктами). 

Почему — спросите вы. 

Во-первых, представьте ситуацию, когда вы руководитель команды монетизации (в Spotify их называют Product Owner, PO или Владелец Продукта), и вам понадобилось в целях повышения конверсии в покупку произвести определенные изменения в процессе активации клиентов, за который отвечает другая команда. Что вы сделаете? Очевидный ответ — пойдете к этой команде и попросите их включить вашу задачу в их бэклог. Но в большинстве случаев это не сработает, так как далеко не факт, что ваша задача хоть как-то влияет на метрики команды активации, а возможно, даже ухудшает их. Вполне логично, что PO команды активации вам откажет в исполнении этой задачи или включит ее в бэклог с низким приоритетом. В результате вы либо не сможете сделать эту задачу вообще, либо ее реализация затянется на долгий период времени.

Таким образом, в нормальной ситуации, когда вам необходимы изменения в другой части продукта, вы делаете их сами по определенным правилам. Такая схема работы называется inner source (общее владение кодом, open source подход в периметре компании).

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

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

1. Inner source — команды имеют возможность вносить изменения в большинство компонентов сервиса Spotify. 

2. На уровне большой группы команд ведется Бэклог Зависимостей (Dependency Backlog), куда они помещают системные зависимости, обнаруженные в попытке независимо поставить результат. Команды регулярно берут задачи из этого бэклога для разрешения зависимостей на системном уровне. 

3. На уровне больших групп команд (трайбов) есть специальные команды, которые занимаются проблемами независимости поставки. Их задача — на системном уровне устранять зависимости.

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

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