Как организованы продуктовые команды в Lamoda, Skyeng, «Авито» и других компаниях

В RealtimeBoard есть две группы продуктовых команд — Core Product и Product Growth.

В Core-продукте разделение по опыту пользователя, компонентам — Core features, Integrations, Platform, Mobile, Enterprise. В Product Growth — по Customer journey: Activation, Engagement & Retention, Monetization.

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

Cхема работы между командами такая: Core product исследует потребности и workflow пользователей и занимается глубокой проработкой ценности и UX-фичей, а Product Growth уже встраивает их в «каналы доставки» (онбординг, нотификации и так далее) и монетизацию.

Чтобы все это не тащилось в разные стороны, есть три важные вещи:

1. OKRs, которые декомпозированы на инициативы, и каждая команда понимает, на что влияет

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

3. Встреча по продуктовому фидбэку, где мы обсуждаем решения.

Анна Бояркина, head of product в RealtimeBoard

Основной продукт «Авито» разделен на два ключевых сегмента — частники и бизнес. Далее продуктовые команды делятся по направлениям, которые приносят пользователям конкретную ценность.

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

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

Евгений Емельянов, директор по продукту в «Авито»

Мы в Qlean организуем продуктовые команды по принципу «Цепочки ценностей» Майкла Портера. Инструмент цепочки ценностей в классическом варианте используется для стратегического анализа компании. Этот подход применяют, когда нужно очень сложный процесс декомпозировать на части и определить, где «узкое место». Мы подумали, что это можно адаптировать под нужды нашего бизнеса и продуктовой команды.

Почему мы выбрали такой подход?

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

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

3. У каждой продуктовой команды есть понятные бизнес-заказчики. Там, где их нет, процесс максимально автоматизирован. Не возникает путаницы и беспощадных Google Docs, куда тысяча бизнес-заказчиков ставят кучу своих «требований» к продукту.

4. Очень легко считать, за какую часть P&L отвечает команда: каждое звено цепочки ценности представлено в отдельной строке, блоке строк в отчетности. Это помогает лучше ставить цели, планировать эффект работы продукта на бизнес.

5. У продакт-менеджеров развивается большая экспертиза и глубокое понимание бизнеса. Им нужно мыслить в рамках отдельного звена бизнеса и контролировать коммуникации с соседними звеньями — они чувствуют себя полноценными «генеральными директорами» небольшой части компании.

Названия команд для примера — Customers Acquisition, Customers Retention, Cleaners Acqusition, Cleaners Retention, Customer Service.

Валерия Коваленко, head of product в Qlean

Как мы работали раньше?

Над продуктом работали команды, которые поделены по типу создаваемой ценности. В старой структуре у нас было пять команд: веб-разработка, десктоп-разработка, маркетинг, развитие бизнеса и команда product ownership (по сути — PM, PO, PMM и стейкхолдеры). Все жили в квартальном цикле планирования с одной метрикой. И с этим были проблемы:

1. Долгий цикл планирования.

2. Огромное количество зависимостей между командами.

3. Сложные коммуникации между командами.

4. Принятие даже самых мелких решений превращается в боль.

5. Декомпозиция метрик.

Основа бизнеса Setapp — customer acquisition funnel. Также у нас есть несколько стратегических feature-направлений, в которые мы верим. Поэтому мы решили выстроить новую структуру вокруг того, что считаем важным. Так появился драфт нашей организационной структуры 2.0.

Funnel:

1. Growth team (закупка трафика, оптимацизация воронки, все, что происходит с юзером до начала триального периода).

2. Membership team (фокус на retention).

3. Revenue team (продажа базового плана, апселы, прайсинг).

4. Recovery (работа с churn, у нас он 2,5%, поэтому пока даже не начали ее формировать).

Features:

1. Setapp for Teams (задача — валидировать и запустить спин-офф потребительского продукта на b2b-рынке.

2. SEO and Editorial (нам дешевле и выгоднее содержать свое медиа, чем платить за трафик из Google или Facebook, поэтому выделяем отдельную команду, которая заточена на создание контента вокруг проекта).

Core:

1. Core dev team (фокус на фичах, которые пока что не имеют отдельного PM).

2. Core marketing (общая координация всего брендинга и закупки).

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

1. Идеальной структуры не будет, нужно итерировать. Мы потратили большое количество времени, чтобы все продумать, но все равно в реальности в процессе реализации меняется все.

2. У команд должны быть PM. Мы попробовали запустить эксперимент с Growth командой без PM — затея не удалась.

3. При планировании новой структуры — фокусируйтесь на минимизации зависимостей между центрами создания ценности.

Павел Педенко, продакт-менеджер в Setapp (продукт компании MacPaw)

У нас нет сильного дробления, мы работаем продуктовыми командами, в которых продукт — отдельный сервис. У нас есть команда «Ленты», команда «Чемпионата» и так далее. Единственный бренд, в котором у нас есть дробление, — портал «Рамблер».

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

Екатерина Текунова,, директор по продуктам Rambler&Co

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

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

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

Стандартный набор команд:

1. Команда DAU или MAU: привлечение и удержание пользователей бесплатной части сервиса

2. Команда активации: привлечение неплатящих пользователей в платную версию и оформления триального периода на Pro

3. Команда подписок: конверсия пользователей из триального периода в подписку и снижение оттока из подписки.

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

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

Михаил Трутнев, главный операционный директор Ultimate Guitar

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

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

— Сокращается время до запуска продуктов.

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

— При таком подходе получается хорошо фокусироваться на платформенных фичах (таких, как поиск по фото в приложениях) и развивать продукт на отдельной платформе в целом (например, мы серьезно изменили мобильный сайт).

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

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

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

Например, у нас есть команда Sizes, которая решает одну из важных задач для онлайн fashion-ecommerce: делает так, чтобы люди не ошибались в выборе размера одежды и обуви. Особенность Lamoda в том, что онлайн и офлайн у нас тесно пересекаются.

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

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

Кира Матвеева, head of product в Lamoda

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

От разделения по платформам (iOS, Android) мы отказались, так как нам важно сохранить консистентность между приложениями — и кажется логичным, что одну и ту же фичу под Android и под iOS будет продумывать и контролировать один и тот же человек. Делить продукт по экранам тоже не хочется, так как существенную долю фичей нужно протаскивать через все приложение.

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

Елизавета Гончарова, руководитель продукта в Joom

У нас есть и горизонтальное (по платформам) и вертикальное (по частям customer journey) разделение. В целом, даже 3D-кубик получается.

Есть команда Product Core:

— Web.

— Mobile.

— CRM.

— Billing&Auth.

Это платформы, к ним приходят остальные заказчики — своеобразный baseline продукта.

Отдельно есть команды на разных этапах customer journey — своеобразный усиливающий спецназ:

— команда C1 (первой оплаты);

— команда C2 (второй оплаты);

— команда Teachers (у нас двусторонний рынок).

У них максимальный фокус на конкретные жизненно важные метрики.

И еще есть команды на новые направления:

— b2b;

— kids;

— international;

— экспериментальные продукты.

Они выступают заказчиками к платформам или пилят какие-то вещи сами, если это нужно только им.

Для синхронизации команд — есть квартальные OKR, сквозные проекты и правила, чтобы они не буксовали, есть еженедельные встречи продактов (для обучения и иногда синхронизации).

Михаил Карпов, директор по продукту в Skyeng