Часть 1
В управлении продуктом существуют, на мой взгляд, два полюса - функциональный и продуктовый подходы. В этом материале разберем, в чем разница подходов, как они работают и в чем их коренное отличие.
Привет, меня зовут Алексей Буренин, я работаю Product executive (CPO) и имею большой опыт перестройки компаний на продуктовый подход и опыт работы в функциональном подходе. В данном материале я буду использовать не только свой многолетний опыт, но и опыт западных коллег и маститых авторов по менеджменту. Поехали!
Продуктовый подход как панацея от всех проблем - это довольно распространенное мнение: нам надо перейти на продуктовый подход, и тогда продукт и компания начнут расти. Или другой полюс - в нашей компании очень важно мнение 100500 стейкхолдеров, функции CEO которых надо учесть, и желания клиентов - одним словом, функциональный подход. Давайте посмотрим, в чем же реальная разница этих двух подходов. Первое, что следует заметить: оба подхода имеют право на существование, оба работают при настройке достаточно эффективно и результативно.
Очень распространенное и вредное заблуждение в продуктовой отрасли, о котором часто заявляют многие руководители, - что существует единственный верный способ или фреймворк, лучшая практика и прочее в разработке первоклассных продуктов. Важно понимать, что не существует единой системы, нет абсолютно верного или абсолютно неверного подхода, все зависит от контекста компании, окружения и множества факторов. Выбор продуктового или функционального подхода либо среднего между ними - это стратегический выбор компании.
Функциональный подход
Функциональный подход в управлении продуктом - это классический метод организации, делящий управление продуктом в компании на отделы, группы, направления, функции продукта, по задачам, где работа строится вокруг узких функций или кластеров продукта. Организация работы делится на группы по ролям, каждое направление или часть продукта отвечает за свой узкий участок работы, а главные связи в компании - это команды от старшего менеджера к подчиненному, даже если существуют OKR или подобные инструменты. Обычно продукт поделен на кусочки - онбординг, платежи, программы лояльности, подписки и прочие. Тот самый главный менеджер одной кнопки - это классическая шутка функционального подхода.
Один взгляд на название вакансии сразу даст понять, какой принцип используется в организации: если используется название роли типа "Владелец продукта", Product Owner (роль из скрама), менеджер функции 1 или менеджер по продукту функции 2 - перед вами функциональное управление продуктом.
Важно понимать, что функциональное управление позволяет держать прозрачную структуру управления продуктом, позволяет концентрироваться на конкретных функциях, накапливать компетенции в одной области продукта или домена.
Отдельно следует заметить, что такое управление снижает уровень неопределенности в управлении продуктом и позволяет создать иллюзию прозрачного планирования и контролирования внешней среды управления. Почти в любой момент времени вы можете получить дорожную карту, примерные сроки реализации и знаете, кто отвечает за конкретную функцию. Другими словами, это простая структура управления с множеством плюсов.
Важным отличием функционального подхода является прямое влияние роли стейкхолдеров на управление продуктом. По своей сути эти люди, команды или внешние заказчики являются главными влияющими лицами на управление продуктом. Конечно, существуют целые методики управления и работы со стейкхолдерами, что позволяет направить их влияние в мирное русло продукта, но при этом влияние стейкхолдеров все равно остается.
Часто менеджер по продукту в самой организации будет оцениваться не по достижению продуктовых метрик, результатов - а по отношению между стейкхолдерами и менеджером, по уровню удовлетворенности стейкхолдеров и выстроенным отношениям. Таким образом, функциональное разделение незримо (об этом не принято говорить) ставит отношения выше результатов.
Основные механики функционального подхода
Расстановка приоритетов и график выпуска функций создается совместно со стейкхолдерами. Таким образом учитываются интересы сторон, получаются четкие даты и сроки. При этом планирование работ может осуществляться в коротких итерациях - месяц, или использоваться более длинное планирование, также на моем опыте функциональное управление вполне существует с планированием через OKR.
Сбор требований осуществляется с заинтересованных сторон, особенно для B2B сегмента продуктов.
Планирование релизов и выпуска больше тяготеет к проектному управлению, важны сроки, часто стоимость выпуска, даты релизов. Всегда есть дорожная карта и часто до конца года, иногда даже с дедлайнами и ключевыми датами - обычно диаграмма Ганта.
Стейкхолдеры могут продавливать функции или требовать их реализации. Часто молодые продакт-менеджеры впадают в прострацию от такого поведения.
Команды обычно фулстек и полноценно сформированы - содержат все необходимые роли. Бывает реже, что команды являются платформенными - сгруппированными по типу платформы.
Есть элемент планирования загрузки разработчиков либо контроль загрузки. Если он не формализован, на различных совещаниях в функциональном управлении продуктом вы услышите от CEO или кого-то другого: "А чем занят Вася, наш бекендор?"
Сохраняется управление по целям и метрикам с оглядкой на заинтересованные стороны. При этом не отметается продуктовое исследование, Discovery цикл, глубинные и качественные исследования, A/B тесты. Не следует демонизировать функциональный подход.
Важной особенностью становится управление стейкхолдерами, работа с ними и выстраивание отношений с заинтересованными сторонами. Эти отношения часто значат больше, чем результаты работы, при этом продакт-менеджеру придется балансировать между разными интересами и противоречиями. Управление ожиданиями, как пишет литература по проектному управлению.
Решение конфликтов на уровне заинтересованных сторон из-за ограниченности ресурса (время в первую очередь и очередность выпуска) - это отдельный вызов для менеджера. Думаю, что это отдельный навык и важный опыт для менеджера в функциональном управлении.
Структура управления продуктом иерархична - есть директор по продукту, есть руководители подпродуктов или продуктовых направлений, менеджеры функций. Иногда такое дробление может быть и больше - это зависит от бизнес-целей. По сути, такие продуктовые команды обслуживают через продукт цели бизнеса и формируются исходя из потребностей пользователей и заинтересованных сторон.
Не следует думать, будто функциональный подход не отталкивается от потребностей пользователей или игнорирует их. Это ошибочное мнение. Речь больше про то, что интересы пользователей и интересы заинтересованных сторон приводятся в баланс менеджером по продукту, что достаточно трудно. Как можно заметить, свобода принятия продуктовых решений ограничена не столько влиянием заинтересованных сторон, сколько самой структурой управления (более иерархической), зоной ответственности команды - часть функции либо небольшая функция продукта, и как следствие - областью, на которую может влиять продакт-менеджер так и его команда.
Плюсы функционального подхода
Глубокая экспертиза в конкретном домене или области.
Позволяет накапливать узкую специализацию и высокую компетентность в конкретных функциях продукта (например, платежи, онбординг).
Четкая структура и контроль - удобны для основного бизнеса.
Создает прозрачную иерархию, где понятны зоны ответственности. Это дает иллюзию предсказуемости и облегчает планирование (дорожные карты, диаграммы Ганта).
Эффективность в стабильной среде - позволяет крупным компаниям (и не только) эффективно управлять продуктами.
Хорошо работает в условиях массового производства или крупно серийных продуктов с нечасто меняющейся номенклатурой продукта. Удобно для сложных продуктов со сложной структурой либо технологически сложных продуктов.
Управляемость на уровне ресурсов и сроков.
Упрощает контроль за загрузкой команды и административное управление.
Минусы функционального подхода
Фрагментация продукта, рассинхронизация CX.
Основной риск - превращение продукта в фабрику фич. Команды, сфокусированные на своих OKR, могут создавать разрозненные функции, которые не складываются в целостный пользовательский опыт. Как следствие - потеря целостной стратегии. Требуемые функции от заинтересованных сторон могут навредить основному продукту либо создавать разноплановый CX для пользователей - потеря идентичности.
Сложность координации и потеря связи между командами.
Связи между подразделениями ослабевают, а коммуникация строится преимущественно по вертикали (сверху вниз). Это замедляет принятие решений и реакцию на изменения рынка. Также кратно возрастает время и соответственно стоимость поддержания координации в продукте.
Конфликт интересов на разных уровнях.
Возникает конкуренция между отделами за ресурсы и влияние, а также потенциальные конфликты между функциональными менеджерами. Команды не понимают ценности выпускаемых функций и теряют мотивацию. Я часто видел, как командная энергия просто угасает в этой ситуации - особенно среди разработчиков.
Потеря фокуса на пользователе.
Цели могут смещаться с удовлетворения потребностей клиентов на внутренние отчеты и выполнение планов перед руководством. Успех менеджера оценивается не по рыночным результатам, а по удовлетворенности стейкхолдеров, что приводит к потере фокуса на решаемых проблемах пользователей.
Больше интрестного тут - https://t.me/dao_producta
Часть 2 тут (скоро будет)