Всем привет! С вами снова Александр Бондаренко, CPO Garage Eight, и мы продолжаем цикл материалов про создание успешного продукта. В прошлых статьях (часть 1; часть 2; часть 3) я рассказал более чем о 12 рабочих моделях построения продуктовых команд. Сегодня обсудим, как выбрать наиболее подходящую для себя, и разберем ошибки, которые мешают компаниям развиваться.
Итак, вы изучили несколько способов, как построить команду и отобрали, допустим, 5 подходящих для вашего бизнеса. Что делать дальше? Как понять, какая из них лучше?
Отталкиваться от этапа жизненного цикла продукта
На этапе старта продукта лучше всего подходят плоские структуры, поскольку они позволяют быстро принимать решения и адаптироваться к изменениям.
Когда компания переходит в фазу роста и масштабирования, эффективными становятся функциональная иерархия и модель трех отделов, которые обеспечивают четкое распределение обязанностей.
Если продукт уже достиг зрелости или компания управляет несколькими продуктами, стоит рассмотреть структуры с разными продуктовыми направлениями или модели на основе групп, например, Squads.
Отсеять часть вариантов по характеристикам
Чтобы сузить круг выбора, стоит задать несколько вопросов:
Какого размера ваша компания?
Какой этап жизненного цикла у вашего продукта?
Какие основные цели и приоритеты бизнеса?
Насколько важна скорость принятия решений?
Какой уровень кросс-функционального взаимодействия требуется?
Планируете ли вы построить экосистему из небольших сервисов?
Ответы на эти вопросы исключат структуры, которые не соответствуют текущим реалиям.
Чтобы учесть размер компании при выборе модели, можно ориентироваться на лучшие практики:
Обратить внимание на триггеры для перехода между структурами
Когда точно стоит менять структуру команды:
Компания растет, и текущая структура не масштабируется.
Продукт усложнился, и коммуникация стала хаотичной.
Внутренние конфликты между командами мешают работе.
Бизнес требует большей гибкости и быстрого вывода новых решений.
Иногда изменения требуют не кардинальной перестройки, а адаптации существующей модели.
Анализ сильных и слабых сторон поможет понять, какие элементы стоит сохранить, а какие — трансформировать.
✅ Для этого используйте чек-лист:
Структура команд помогает компании достигать целей.
Роли и обязанности понятны всем сотрудникам.
Команды слушают и слышат друг друга, вместе решают проблемы, делятся опытом.
У компании есть ресурсы для перехода на новую модель.
Как менять модель при росте компании:
✅ Структура будет работоспособной только в том случае, если она соответствует корпоративной культуре, размеру компании, типу продукта и долгосрочной стратегии и целям бизнеса.
Выбирать «рандомный» способ организовать команду вне зависимости от этих факторов не стоит.
Согласно отчету McKinsey, организационная структура поддерживает инновации. Сильные компетенции в управлении инновационными процессами и гибкие модели способствуют созданию благоприятной среды для развития новых идей и их успешной реализации.
Как не надо строить продуктовую команду: антипаттерны
Даже самые перспективные команды могут столкнуться с проблемами, если структура организации выбрана неверно.
Я выделил распространенные ошибки, которые только навредят бизнесу:
Отсутствие четкого распределения ролей и обязанностей
В стартапах часто наблюдается ситуация, когда все сотрудники выполняют все задачи. Это приводит к хаосу и снижению ответственности за ошибки, задержки и финансовые потери. Важно, когда один человек курирует несколько направлений, он рискует не уделить должного внимания каждой задаче. Что негативно сказывается на эффективности работы.
Что происходит:
Никто не понимает, кто за что отвечает.
Продакт делает работу аналитика, маркетолога и даже тестировщика.
Разработчики спорят, какие задачи важнее, так как нет четкого владельца.
Реальный пример: Российский финтех-стартап пытался строить продуктовую команду без ролей. В итоге все делали все, но никто не нес ответственность.
Решение: Ввести разделение Product Owner / Product Manager / Analyst / Designer / Developer.
Еще пример: полная зависимость от одного человека — Hero Syndrome
IT-стартап в сфере HR-технологий строил весь продукт вокруг одного гениального продакт-менеджера. Но когда он ушел в другой проект, вся работа встала, потому что никто не понимал, как двигаться дальше. Остальные члены команды не чувствовали ответственности.
Решение: Создать систему, где ключевые знания распределены среди команды, внедрить принципы автономности.
Изолированные команды без кросс-функционального взаимодействия
Когда продуктологи, дизайнеры и разработчики работают «в своих коробках», продукт теряет целостность. Изменения вносятся медленно, общий фокус теряется. Конфликтующие приоритеты и узкий взгляд на продукт размывают связь между задачами и целями продукта.
Что происходит:
Дизайнеры рисуют интерфейсы, не консультируясь с разработчиками.
Маркетинг запускает акции, которые невозможно технически реализовать.
Аналитика и UX-исследования не интегрированы в процессы.
Реальный пример: Ozon раньше строил процессы по жесткой функциональной иерархии. Это приводило к тому, что разработчики узнавали о новых фичах уже после запуска маркетинговой кампании.
Решение: Внедрение Squads-модели с кросс-функциональными командами, где разработчики, маркетологи и аналитики работают вместе.
Еще пример: компания потеряла контроль, внедряя Squads
В одном российском банке решил ускорить разработку новых продуктов через Squads. Команды получили полную автономию. Но что-то пошло не так: команды разрабатывали похожие решения, не зная, что другие делают то же самое. Один Squad фокусировался на кредитных продуктах, другой на UX-улучшениях, но никто не думал о совместимости. У каждой команды был свой план, но бэкенд-разработчики работали на все Squads сразу.
Решение: Через 6 месяцев команда поняла, что структура создает хаос, и ввела новую роль Tribe Lead — ответственного за координацию между Squads.
Сложная иерархия замедляет процессы
Избыточные встречи для согласования каждой мелочи приводят к потере гибкости. Отсутствие адаптации структуры при увеличении масштабов компании препятствует росту. Стартап, работая по плоской модели, рискует столкнуться с трудностями при расширении команды до 50+ человек, если не адаптирует свою структуру.
Что происходит:
Чтобы принять простое решение, нужно согласование у 3-х менеджеров.
Встреч больше, чем реальной работы.
Из-за перегруженной структуры команды работают медленно.
Реальный пример: Крупный российский банк пытался внедрить Agile, но сохранил старую иерархию. Руководство создало Squads и назначило Agile-коучей. Бюрократия убила все. Решения требовали одобрения на трех уровнях — даже если Squad мог быстро запустить MVP, его нужно было согласовать с юристами, риск-менеджерами и compliance. Формально продакт-менеджеры стали автономными, но фактически каждую фичу утверждали топ-менеджеры.
Старая культура сопротивлялась: сотрудники не понимали, зачем менять процессы, и просто продолжали работать по Waterfall. Через год поняли, что Agile-система в банке не работает, и процессы остались прежними.
Решение: Убрать лишние уровни управления, передать ответственность командам, сократить количество митингов.
Еще пример: отсутствие гибкости в структуре команды
Бывает, что структура продуктовых команд не меняется годами, даже если меняется рынок. А при масштабировании компании старая модель начинает «трещать по швам». Яндекс.Дзен (теперь проект VK) начинался как продукт с классической функциональной структурой, но со временем это стало тормозить развитие. Когда появились новые направления — рекомендации, видео, платформа для блогеров, компания не смогла проигнорировать сигналы, что нужно пересмотреть процесс работы.
Решение: Структура изменилась в сторону Tribes & Squads. Рекомендуется оценивать эффективность модели раз в 6–12 месяцев и адаптировать ее под текущие бизнес-задачи.
Команда теряет связь с реальностью
Когда игнорируются мнения участников, что снижает мотивацию и приводит к текучке кадров. Если же команда не слушает пользователей, она быстро теряет связь с рынком и тратит ресурсы на невостребованные функции. Фокус на числовых результатах может привести к игнорированию качества и долгосрочных целей.
Что происходит:
Внедряются фичи, улучшающие только цифры (например, рост MAU), но не реальную ценность для пользователей.
Команда не собирает качественную обратную связь.
Впереди метрики, а не логика.
Реальный пример: Российская e-commerce компания начала активно улучшать Retention Rate. Они добавили навязчивые пуш-уведомления, бонусные механики и email-рассылки. Это увеличило цифры, но клиенты начали массово отключать уведомления и удалять аккаунты.
Решение: Важно сочетать количественные и качественные метрики, учитывать влияние на UX.
Подчинение продуктовой группы COO
Если все продукты подчиняются операционному директору, можно потерять стратегический фокус. Например, продуктовая команда может быть перегружена операционными задачами — управлением ресурсами и оптимизацией процессов — что тормозит развитие новых инициатив. Продуктовая группа должна сохранять баланс между стратегией и операционными целями.
Что происходит:
Весь фокус идет на операционные задачи, а не на развитие продукта.
Продакт-менеджеры перегружены KPI по внутренней эффективности вместо работы с клиентами.
Внедряются инициативы, которые помогают бизнесу, но вредят пользователям.
Реальный пример: В одном российском брокере продуктовую команду поставили в подчинение COO. В результате продакты больше занимались внутренними процессами такими, как оптимизация отчетности и CRM, а не улучшением клиентского опыта.
Решение: Продуктовая команда должна подчиняться CPO или CEO, чтобы держать фокус на развитии продукта.
Еще пример: команда потеряла влияние, оказавшись под управлением COO
В одном крупном ритейле продуктовую команду поставили под управление директора по операциям (COO). Продакт-менеджеры стали решать операционные задачи, а не развивать продукт. Все приоритеты формировались исходя из операционной эффективности, например, команды увеличивали скорость сборки заказов, но забывали про UX мобильного приложения. Новые фичи откладывались, потому что COO считал, что их сложно внедрить с точки зрения логистики. Через год продуктовая команда фактически перестала заниматься стратегическим развитием и сосредоточилась только на внутренних процессах.
Решение: После реструктуризации продуктовую команду вернули в подчинение CPO.
А как все-таки надо строить продуктовую команду?
Какие сигналы указывают, что пора менять модель?
Коммуникация между командами замедлилась.
Приоритеты постоянно пересматриваются.
Команды жалуются на хаос и дублирование.
Новые задачи не вписываются в текущую систему.
Что попробовать, если нет уверенности?
Начать с пилотного запуска: перевести одну команду на новую модель.
Определить «болевые точки» текущей системы.
Провести опрос среди сотрудников о том, какие есть проблемы.
Как избежать сопротивления?
Сотрудники боятся изменений из-за неопределенности, возможной потери контроля и просто из-за привычек работать «как было».
Поэтому нужно:
Объяснить логику изменений: «мы внедряем Squads, чтобы ускорить разработку».
Подключить команды к выбору: не навязывать сверху, а дать влиять на процесс.
Запустить тестовый период: «попробуем новую модель 3 месяца и посмотрим результаты».
На какие технические метрики эффективности команд смотреть?
Добавлю еще пару пунктов к решениям-рекомендациям:
🚀 Если команды не понимают, кто за что отвечает → Нужна четкая иерархия ролей.
🚀 Если все задачи идут через одного человека → Нужна децентрализация.
🚀 Если разные отделы работают порознь → Нужны кросс-функциональные команды.
Заключение
Нет универсального решения для выбора структуры продуктовой команды — каждая компания уникальна.
При формировании команды важно учитывать стратегические цели бизнеса, культуру организации и текущие вызовы.
Какую модель вы используете в своей компании?
🔘 Squads
🔘 Двухпоточная модель
🔘 Плоская структура
🔘 Или опишите свой вариант в комментариях
На этом я завершаю большой раздел моего цикла про то, как строить продуктовую команду в компании. Но мы на этом не заканчиваем! В следующих статьях расскажу о жизненном цикле продукта и о том, когда нужно остановиться в его развитии. Подписывайтесь!