Продуктовые роли не появились из воздуха. Их не придумали с нуля бородатые дядьки в Долине или выглаженные воротнички из Купертино. Профессии Product/Project Owner/Manager выстраивались на протяжении почти столетия — и всё ради того, чтобы сейчас мы с вами плевались, читая вакансии на хедхантере. Кто главнее: PM или PO? Что должен делать проджект? И что ещё за AI PM и Data PM?
Давайте разбираться. И копнём аж до начала прошлого века.
1. Исторический контекст
1.1. Gantt, 1910-1918
Когда ещё не было даже намёков на современный проджект-менеджмент, инженер Генри Гантт впервые рисует «Gantt charts» для Baltimore & Ohio RR и корабельных верфей. Простейшие полоски-задачи + календарная шкала оказываются чудом наглядности. Минобороны США нанимает Гантта, чтобы распланировать переброску корпуса во Францию. Так больше века назад рождаются первые серьёзные инструменты для управления проектами.
1.2. Brand Man, 1931
Спустя больше десяти лет Нил Макэлрой в Procter & Gamble требует выделить отдельную позицию «brand men», отвечающую за прибыль конкретного мыла, которым торговала компания. Именно этот шаг принято считать зарождением продакт-менеджмента (хотя в тот момент это была история больше про бренд, чем про продукт в его современном смысле).
1.3. Lean, 1940+
В 1940х Тайити Оно и инженеры Toyota собрали конвейер, который тянет детали «под заказ» вместо того, чтобы гнать их на склад: принцип Just-in-Time стал ядром Toyota Production System (TPS). Философия свелась к борьбе с любым «мусором» — лишними операциями, запасами, дефектами и простоями — и к непрерывному улучшению (кайдзен).
К 1978ому TPS оформилась в книгу Оно, а западный менеджмент получил словарь Lean и идею, что скорость достигается не сокращением сроков, а плавным потоком ценности.
1.4. CPM, 1957
Инженер Морган Уокер (DuPont) и математик Джеймс Келли (Remington Rand Univac) за два с небольшим года собирают алгоритм Critical Path Method: вычисляем цепочку задач с нулевым запасом, накладываем на неё график — и видим, где сгорают деньги. Первый пилот прошёл в DuPont летом 1957го, технология мгновенно улетела в строительство и оборонку.
1.5. PERT, 1958+
ВМС США (да-да, снова оборонка), разрабатывая ракету Polaris, создаёт PERT — предка большинства инструментов проектного управления. Program Evaluation and Review Technique (метод оценки и анализа программ) помогал определить последовательность задач, оценить время выполнения каждой и построить критический путь проекта. Родившееся как решение для военпрома, очень скоро PERT (как и CPM) перекочевали в строительные компании, где также требовалась чёткая и единая методология планирования.
1.6. PMI, 1969+
Пятеро энтузиастов регистрируют Project Management Institute в Пенсильвании. Спустя некоторое время им ещё предстоит формализовать профессию Project Manager (PjM), но тогда PMI только зарождается. Активную работу над стандартами они начнут позже, в 80ых. А уже в 1996ом выпустят первое издание PMBOK Guide и формально кристаллизуют те самые 9 (на тот момент) областей знаний.
1.7. Program Manager, 1984
В команде MS Excel появляется первая должность Program Manager (Джейб Блументаль): человек пишет 300-страничную спеку, общается с юзерами, торгуется с девелоперами и по сути владеет «что и зачем» продукта, оставляя «как» инженерам. Такой PM сидит в «триаде» вместе с Dev & Test и гонит фичи короткими релизами.
Почти оновременно Microsoft выпускает Microsoft Project 1.0 — дешёвый Gantt-конкурент для PC, который быстро приучает менеджеров к сетевому плану и критическому пути. Шаблон «Program Manager + внутренняя тулза для графиков» разлетится по всей индустрии и станет базой для современных Product/Program Management.
1.8. CMM, 1988+
Уортс Хамфри, ветеран IBM (в которой гигантские мэйнфрейм-проекты требовали железной дисциплины) оформляет свои наработки в идею Capability Maturity Model — пятиступенчатую «лестницу зрелости» процессов, родившую моду на метрики, peer-review и PM-офисы. Параллельно корпорация активно внедряет Integrated Product Development и к середине 1990-х уже учит тысячи инженеров единому языку рисков, и базовых KPI проекта.
Итог: если Microsoft сделал PM «хозяином продукта», то IBM закрепила за PM роль «сторожа процесса и качества», а их сочетание и сформировало то самое гибридное понимание Project/Product/Program Management, которым мы с вами пользуемся сегодня.
1.9. Scrum, 1993+
В 1995ом на конференции OOPSLA Джефф Сазерленд и Кен Швабер презентуют Scrum. В нём закрепляются роли Scrum Master и Product Owner.
Это не «дата рождения» скрама, скорее дата его первой формализации. До этого он уже жил в коридорах Easel Corporation: Сазерленд, Скумниоталес и МакКенна за несколько лет до этого докрутили идеи Такаути и Нонаки, собрали первую скрам-команду и начали итеративно выпускать программные тулзы.
Стоит отметить, что роль Product Owner в оригинальном Scrum была скорее про ответственность за ценность продукта, чем за детальный бэклог, как это часто понимают сегодня.
1.10. Agile, 2001
Cемнадцать практиков (Кент Бек, Мартин Фаулер, Джим Хайсмит и другие), устав от тяжеловесных процессов в их компаниях, заперлись в лыжном домике в Юте. В результате такого заточения родился Agile Manifesto: четыре коротких ценности (люди и взаимодействия, работающий софт, сотрудничество с заказчиком, готовность к изменениям) и двенадцать принципов. Ключевая мысль: лучше непрерывно доставлять маленькие порции ценности и общаться вживую, чем тонуть в документах, планах и контрактах.
Манифест мгновенно поколебал иерархию «Project Manager — процесс — документация». Команды получили моральное право ставить ценность продукта выше сроков, а менеджеры — экспериментировать с ролями PM, PO, PjM.
Именно после Agile Manifesto взлетели Scrum-гайды, Kanban-доски и подходы Discovery/Delivery: теперь задача менеджера была в том, чтобы убрать препятствия и помочь команде быстро учиться на фидбэке, а не просто «выполнить план по Гантту».
1.11. Kanban, 2004-2007
Картонные канбан-карточки, которыми Toyota в 1950х синхронизировала поставки, в 2004ом перенёс в софт-разработку Дэвид Андерсон. Канбан-доска с колонками «To Do — Doing — Done» и жёстким лимитом параллельных задач дала командам прозрачный поток без ломки оргструктуры.
С 2007го метод разлетелся по Agile-сообществу: сроки и риски теперь выводят из статистики цикла, а роль проджекта смещается к Flow/Delivery Manager, который охраняет WIP-лимиты и lead-time. В итоге Kanban стал легковесной альтернативой спринтам и вписался даже в ML-пайплайны, где важнее стабильный поток, чем фиксированные итерации.
1.12. Inspired, 2008-2018
Но на этом история не заканчивается. В конце десятых Марти Каган публикует культовую книгу «Inspired». В ней Product Manager сравнивается с «мини-CEO» продукта и ставится выше Product Owner’а. Тысячи пятых точек мгновенно воспламеняются — и этого огня хватает, чтобы осветить путь нового подхода в Долине. Да так мощно, что переиздание выходит аж через 10 лет после первой версии книги.
1.13. SAFe, 2011
Организация Scaled Agile формализует фреймворк SAFe, где Product Manager управляет общим бэклогом, а PO — бэклогом команды. SAFe создаётся как альтернатива классическому скраму с его гиперсамостоятельностью отдельных команд и призван выстраивать и поддерживать зависимости в кросс-командных или кросс-платформенных продуктах.
1.14. AI & Data PM, 2020+
Появляются специализации AI Product Manager и Data Product Manager, акцентирующие владение данными, ML-моделями и этичной эксплуатацией искусственного интеллекта. Потихоньку они начинают вносить коррективы в устоявшиеся роли — и об этом мы тоже поговорим позже.
Окей, а дальше что? Понятней не стало.
А дальше давайте разложим это всё на пять самых популярных школ менеджмента и попробуем разобраться, почему в одних вакансиях оунеры ниже продактов, а в других рулят проджекты безо всяких PM и PO.
2. Пять школ управленческого Дао
Разумеется, отнюдь не все компании придерживаются какой-то конкретной школы. Вы легко можете встретить самые странные миксы. Но изложенная ниже структура поможет вам хотя бы понять, из каких ингредиентов собраны эти должностные коктейли.
2.1. Silicon Valley
В стартапах Кремниевой Долины PM задаёт стратегию, а PO её реализуют. Тут во всей красе расцветают идеи Кагана. Логика проста: рынок быстрый, а для быстрого рынка нужна единая визия (чтобы внутренние и связанные продукты не разорвало, как того хомячка от капли никотина).
PM: Формирует продуктовую стратегию и roadmap, основываясь на рынке и данных пользователей. Проводит discovery, определяет метрики и координирует нескольких PO. Решает, какие фичи войдут в продукт, а какие на помойку. Влияет на бюджет (но не управляет им).
PO: Детализирует бэклог, переводит стратегию в задачи. Впахивает с разработчиками, аналитикам и дизайнерами, обеспечивает выполнение спринтов. Приоритизирует задачи команды, решает, что готово для релиза.
PjM: Редко встречается, может координировать ресурсы или зависимости. Полномочия PjM здесь ограничены логистикой, в продукт он не лезет.
2.2. Чистый Scrum
Здесь PO — единственный владелец ценности внутри команды, мать, отец и мотивационная морковка. PM (если он вообще есть) остаётся вне проектных процессов. В скраме основная ставка на автономность и скорость.
PM: Если есть, собирает инсайты о рынке, проводит исследования, изредка — формирует стратегию. Влияет на приоритеты через рекомендации, но не вмешивается в дела команды и продукта.
PO: Управляет бэклогом, определяет цели спринта, работает с разработчиками. Обеспечивает максимальную ценность продукта. Полностью контролирует приоритеты — именно он решает, что именно пойдёт в разработку, а что нахрен.
PjM: Отсутствует, его функции выполняет Scrum Master.
2.3. SAFe
PM ведёт Agile Release Train (ART, огроменный поезд всех спринтов и зависимостей), а PO управляет одним небольшим вагончиком своей команды. Такая двухэтажная модель нужна, когда Agile раскатан на десятки людей и нужно общее PI-планирование (за которое тоже кто-то должен отвечать).
PM: Управляет program backlog (приоритизированный список фич для ART), задаёт стратегию, согласовывает её с бизнесом. Участвует в PI-планировании. Решает, какие фичи войдут в Program Increment, влияет на ресурсы.
PO: Детализирует бэклог команды, работает с разработчиками, обеспечивает выполнение задач в рамках ART. Приоритизирует задачи команды, определяет степень готовности фич.
PjM: Координирует зависимости между командами, следит за сроками PI. Контролирует риски и сроки, но не продуктовые решения.
2.4. PMI/Waterfall
В PMI роль Project Manager (PjM) старше всех: он отвечает за «срок-бюджет-скоуп» и регулярно докладывает заинтересованным сторонам. Продуктовые роли тут, по большей части, консультирующие.
PM: Определяет границы продукта, консультирует по требованиям, проводит исследования рынка. Влияет на требования, но подчиняется PjM.
PO: Обычно отсутствует или уточняет требования как аналитик.
PjM: Планирует этапы, распределяет ресурсы, контролирует риски, отчитывается перед steering committee.
2.5. FMCG
Компании типа Fast Moving Consumer Goods исторически больше про офлайн, поэтому PM здесь — владелец P&L (бабла, по факту) и бренда. PO часто отсутствует или входит в digital-подразделения как Digital PM, ведь основное IT-направление в таких компаниях — маркетинговое.
PM: Отвечает за стратегию бренда, маркетинг, ценообразование. В digital управляет цифровыми продуктами (например, loyalty apps или e-commerce). Шарит за стратегию, бюджеты и приоритеты digital-продуктов.
PO: Детализирует бэклог для цифровых продуктов, работает с командами разработки. Приоритизирует задачи digital-продукта в рамках стратегии PM.
PjM: Управляет проектами (например, запуск кампаний), координирует ресурсы. Контролирует сроки, но не стратегию.
Ну что, стало попонятнее? Дайте мне минуту, уже исправляю.
3. Не всё так просто
Как я уже писал, роли миксуются. Где-то это осознанное решение, продиктованное продуктовыми, рыночными и бизнес-реалиями. А где-то PO и PM перепутаны просто по тупости и незнанию. Вот вам парочка примеров, когда классические подходы работают не совсем так, как были задуманы:
- Когда у вас двойной трек discovery & delivery, то даже при связке «PM выше PO» стратегия и тактика бегут параллельно. PM генерит гипотезы, PO быстро проверяет их с командой и говорят PM, куда генерить дальше.
- Матричные компании типа SAP или Siemens часто держат PM и PjM на одном уровне, решая спорные вопросы коллегиально. Это заложено в саму суть их оргструктуры.
- В банках, фарме и подобных направлениях регуляция и специфика отрасли толкает PjM наверх даже при Agile: сроки релизов настолько жёстко привязаны к аудиту и сертификации, что визионерство тихонечко курит в сторонке.
4. Как меняют рынок AI PM & Data PM
В наше время, если в твоём продукте нет ИИ, он рано или поздно сдохнет. Что бы там не говорили современные луддиты, но даже приложение для учёта расходов лучше справляется со своей задачей, если в нём ИИ-помощник. Как ответ на это рынок разрождается новыми ролями. И эти роли потихоньку изменяют уже привычных нам продактов.
Общее проникновении AI заставляет менеджеров организовывать чёткую петлю обратной связи модели: без доменной экспертизы продукта ИИ-агенты учатся крайне неффективно и не приносят столько прибыли, сколько могли бы. McKinsey в своём недавнем отчёте указали, что AI PM должны развивать навыки работы с low-code платформами и агентскими фреймворками. Без этого не получится координировать сложные AI-системы и ускорять продуктовые циклы.
Но работа с готовыми моделями ещё не всё. Нужно, чтобы кто-то курировал сквозной жизненный цикл датасета и культуру «data-as-a-product»: качество схем, метаданные, соблюдение privacy-ограничений и прочее. Так потихоньку рождается роль Data Product Manager: человека, без которого консистентность данных (и, как следствие, всего остального) фактически недостижима.
Так что если вы снова запутались, расслабьтесь: дальше будет только хуже.
5. Пара слов в защиту здравого смысла
Но давайте вернёмся к знакомым PO с PM и PjM. Как быть-то? Кому верить, какой школе? А никакой. Верьте реалиям бизнеса/продукта и здравому смыслу.
Считайте команды. Если у вас одна кросс-функциональная — один человек легко совместит роли PM и PO. Три-семь команд? PM ставьте на стратегию, PO — в каждую команду. Контракт с фиксированным объёмом и датой? Вам не нужны визионеры, вам нужен сильный PjM.
Давайте власть тому, кто держит метрику. Если PO отвечает за NPS, он должен иметь право отменить любой фич-реквест. Если квартальная премия PM зависит от LTV клиента, странно не давать ему на это влиять.
Забейте на регалии. Сначала обязанности и метрики, и только потом титулы. То, что должен делать человек — намного важнее того, как называется его роль в оргструктуре.
Но а если уж прям сильно хочется, то вот вам мой субъективный маркер-лист. Он немного противоречит каждой из перечисленных школ, но мне плевать:
- PM: Шарит за экономику, стратегию, продуктовые границы и визионирует как не в себя.
- PO: Меняет приоритет без бюрократии, раскатывает релизы, выстраивает коммуникации.
- PjM: Парится о сроках и процессах, подсвечивает риски и организует всё, что ещё не организованно.
6. Итого
Я не рассказал про тьму аспектов. Про культурные различия (США, Европа, СНГ, Азия), про всякие LeSS, Prince2 и прочее. Но от этого суть статьи не меняется.
Роли появились по историческим причинам, школы выстроили разные пирамиды, но всё всегда сводится к одному: если у вас мутные зоны ответственности, полномочия не связаны с обязанностями, проверка ценности происходит интуитивно, а не на цифрах — вас не спасут никакие роли и термины.
