Продуктовый подход в компании прижился или только объявлен?

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

При этом даже формально модель управления сменили пока немногие компании. По данным глобального опроса McKinsey 89% организаций по-прежнему используют традиционную иерархическую структуру: бизнес-юниты, матрицу или функциональные подразделения. Остальные 11% перешли на одну из трех новых моделей: продуктово-платформенную, гибкую модель всего предприятия или децентрализованную сеть.

Продуктовый подход как модель управления компанией

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

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

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

Марина Иванченко, бывший директор по продуктам и маркетингу MANGO OFFICE

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

Принципы продуктового подхода на уровне компании

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

• Ценность для клиента выше выполнения задачи. Фокус команды смещается с задач на поведение клиентов — работу считают сделанной, когда оно изменилось.
• Постоянная кросс-функциональная команда. Разработчики, аналитики, дизайнеры и представители бизнеса работают вместе все время, пока продукт существует. Временную проектную группу под каждую задачу больше не собирают.
• Решения через гипотезы и эксперименты. Спорную идею сначала проверяют на минимальной версии продукта и на части клиентов. Ресурс всей команды на нее тратят только после подтверждения.
• Короткий цикл обратной связи. Данные о поведении клиентов доходят до команды за дни и недели. Приоритеты пересматривают по ним на каждой итерации.
• Ответственность за результат, а не за объем работ. Команду оценивают по метрике продукта, а количество выпущенных функций отходит на второй план.

По данным исследования ProductSense и X5 2025 года, большинство опрошенных считают, что через пару лет продуктовое мышление выйдет за рамки узкой продуктовой роли. Оно станет либо общим умением любого специалиста в ИТ, либо обязательным навыком для руководителей разных функций. Крупнейшая группа опрошенных по-прежнему работает в корпорациях численностью от 5000 человек, хотя ее доля за год снизилась с 44% до 35%. Доля респондентов из компаний со штатом 10–499 человек суммарно выросла на 4 п.п.

22 октября 16:00 МСК Онлайн Бесплатно Онлайн-конференция: От «да» до первого шага Практика тех, кто каждый день доводит до результата дилеров, клиентов и сотрудников. Зарегистрироваться

Продуктовые команды: что меняется в оргструктуре и бюджете

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

Команды вокруг компонентов и вокруг клиентского пути

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

ИТ-подразделение «Лемана ПРО» объединяет около 1200 специалистов в 130 продуктовых командах. Николай Кныш руководит технологиями в «Лемана Тех», ИТ-компании ритейлера. По его словам, эти команды собраны вокруг компонентов: интернет-портала, мобильного приложения, платежей. Ни одна из них не отвечает ни за весь клиентский путь, ни за выручку компании. В 2025 году ритейлер начал собирать команды вместе с бизнесом вокруг клиентских путей.

Бюджет на команду вместо бюджета на проект

При проектном подходе смету утверждают под конкретную работу и закрывают вместе с ней. Группу исполнителей собирают под задачу и распускают после сдачи. Следующую инициативу снова защищают отдельной заявкой.

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

Финансовый директор начинает спрашивать ИТ о другом: сколько приносит продукт и сколько стоит его команда. В «Лемана ПРО» вопрос об отдаче ИТ встал из-за увеличения расходов: инвестиции в ИТ ежегодно росли в среднем на 30%. Перед ИТ-подразделением поставили задачу перестать быть только статьей затрат и начать приносить прибыль.

Владелец продукта: один ответственный за результат

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

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

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

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

Метрики результата вместо отчета о выполнении

Эффективность продуктовой команды оценивают по результату: по тому, как изменились поведение клиента и выручка. Проектные KPI «в срок и в бюджет» здесь не работают: у продукта нет конечной даты и фиксированного объема работ. На уровне компании метрики продуктовой команды делят на три группы.

Скорость реакции на обратную связь выделяют отдельно. Она показывает, учитывает ли команда мнение клиентов в своих решениях. Быстро это удается немногим: по отчету Planview о глобальном опросе 2024 года, только 15% респондентов могут учесть обратную связь в течение недель.

Меняется и отчетность перед руководством. При проектном подходе команда показывает процент выполнения плана и отклонения по срокам. При продуктовом она объясняет, как за период изменились метрики продукта и какие решения к этому привели.

Как переходят от проектной модели к продуктовой

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

1. Выбрать ограниченный периметр. Один клиентский путь или один продукт, на котором результат измеряется метриками.
2. Объединить бизнес и ИТ в одну команду. У нее одна общая цель, а не два плана от разных руководителей.
3. Назначить владельца продукта. Ему передают право расставлять приоритеты и распределять ресурсы команды.
4. Договориться о метриках. Команда выбирает два-три ключевых показателя: клиентские, денежные или скоростные.
5. Поменять порядок выпуска изменений. Редкие большие релизы заменяют частыми небольшими обновлениями в коротких циклах. Scrum, Kanban и другие гибкие методологии здесь служат инструментами работы самой команды и не заменяют модель управления компанией.
6. Масштабировать удачный опыт. Следующий периметр переводят после успеха первого.

Так, ОТП Банк перестраивался по продуктовой модели с 2020 года. Бизнес- и ИТ-подразделения объединили в команды с общими целями. Параллельно банк разбил монолитные системы на части и перешел от квартальных релизов к выпускам 2–3 раза в неделю. Изменения шли сразу по трем направлениям: оргмодель, архитектура систем и автоматизация тестирования.

По словам зампреда правления ОТП Банка Сергея Симоненко, срок вывода изменений на рынок сократился с более чем 400 дней в конце 2019 года до примерно 90–95 дней. Доля цифровых продаж выросла с 10–15% на старте перестройки до 85%.

Признаки, что продуктовый подход не прижился

До конца перестройку доводят немногие. По данным отчета Planview, к продуктовой операционной модели перешли только 12% опрошенных компаний. Препятствия на этом пути видят 97% респондентов. Главной проблемой исследователи называют отсутствие общего и ясного понимания, что такое продуктовая модель.

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

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

С частью этих признаков перекликаются российские данные о навыках самих менеджеров продуктов. В оценке продуктовых компетенций «Акселератора ФРИИ» участвовали более 800 сотрудников компаний из промышленности, ИТ и банковской сферы. Слабее всего у них оказались навыки исследования клиента. Исследование клиента идет до разработки: на нем проверяют гипотезы о продукте. Последствия этого пробела ФРИИ перечисляет в отчете:

• перегруженные бэклоги и менеджеры продуктов;
• лишние траты ресурсов на разработку;
• невостребованные продукты;
• низкий уровень доверия со стороны бизнеса.

«Изучение и проработка продукта на этапе discovery без необходимых компетенций может обернуться для компаний значительными убытками».

Анна Русакова, директор Центра корпоративных инноваций и продуктового развития «Акселератора ФРИИ»

Как проверить, прижился ли продуктовый подход

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