Чем продакт отличается от проджект-менеджера

Рассмотрим отличия product-подхода от project-подхода на конкретных ситуациях.

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

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

Путать эти две профессии — обычное дело даже в компаниях с зрелым продуктовым менеджментом: часто под проджект-менеджерами подразумевают продактов и наоборот, а в вакансиях на управление проектами и управление продуктом встречаются почти одинаковые формулировки. Разбираться в разнице между этими профессиями стоит на конкретном примере, а не через сухие определения. Если вы хотите подробнее разобрать, чем занимается каждый специалист по отдельности — обязанности, зарплаты, курсы по управлению проектами и продуктами, карьерный путь до head of product — у нас есть отдельные материалы: «Кто такой проджект-менеджер и чем он занимается» и «Чем занимается product manager в компании». Здесь же разберем именно точку расхождения: продакт-менеджер и проджект-менеджер решают разные задачи, даже когда работают над одним проектом. Менеджер проектов и менеджер продукта — по сути, два разных человека в одной компании, и разница между этими профессиями определяет, кто в итоге принимает решения.

Эксперт по продуктовому и проектному управлению Андрей Бадин, основатель и CEO компании Product Lab, автор методологии Product Focus, более 20 лет опыта в стратегическом, продуктовом и проектном управлении, среди клиентов — Т-Банк, Яндекс, Газпромбанк, СберБанк: «Проект-менеджера всегда интересуют три вопроса — как уложиться в срок, в бюджет и сделать то, что написано в ТЗ. Продакт задает себе совершенно другие вопросы, потому что для него продукт — это не факт того, что вещь сделана, а то, сколько ее купили и какую выручку она принесла».

В этой статье вы узнаете:

• почему один и тот же проект выглядит по-разному в глазах продакта и проджекта;
• где проходит граница ответственности между product и project manager;
• почему продакт-менеджер может закрыть готовую фичу, а проджект-менеджер — нет;
• как модель четырех фокусов Product Focus объясняет разницу в мышлении;
• какие ошибки чаще всего совершают компании, путая эти роли;
• как продакт и проджект взаимодействуют в одной команде.

Возьмем пример, на котором Андрей Бадин объясняет разницу между ролями на курсах Product Lab: компания делает газонокосилку.

Проджект-менеджер смотрит на это как на проект. У любого проекта есть проектный треугольник — три жесткие координаты: срок, бюджет и объем работ, зафиксированный в техническом задании. Все мышление проджект-менеджера выстроено вокруг трех вопросов: успеваем ли мы в срок, укладываемся ли в бюджет, делаем ли именно то, что прописано в ТЗ. Если ответ на все три «да» — с точки зрения проджекта, работа сделана хорошо. Вопрос, нужна ли газонокосилка вообще, для него не стоит — это решение принято до него.

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

1. Какие у клиента вообще потребности, ради которых он купит газонокосилку?
2. Что будет пользоваться спросом?
3. Как зарабатывать больше на постоянной основе?

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

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

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

На практике эта граница чаще всего проявляется в трех типичных ситуациях.

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

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

Меняются приоритеты в разгар спринта. Продакт может перестроить бэклог, если появились новые данные о рынке или поведении пользователя. Для проджекта это означает пересчет сроков и ресурсов — конфликт возникает не потому, что кто-то не прав, а потому что зоны ответственности у product и project manager разные с самого начала.

Разница между профессиями хорошо объясняется через модель четырех фокусов методологии Product Focus, которую Андрей Бадин выстроил на основе практики работы с продуктовыми и проектными командами.

Продакт-менеджер обязан держать в голове четыре области одновременно:

• продукт — технологии, функции, дизайн;
• клиент — сегменты аудитории, задачи и каналы;
• бизнес — объем рынка, конкуренты, бизнес-модель, цена;
• тренды — рыночные, технологические и поведенческие сдвиги, которые пронизывают три предыдущих фокуса.

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

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

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

Даже если роль совмещена в одном человеке, стоит разносить решения по времени — отдельно встреча «что и зачем делаем» (продуктовое мышление), отдельно «как и в какие сроки» (проектное). Это дисциплинирует и не дает стратегии подменяться операционкой.

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

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

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

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

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

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

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

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

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

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

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

Дальше в игру вступает проджект. Он собирает кросс-функциональную команду — двух разработчиков, дизайнера и аналитика, — оценивает объем работ в две недели и договаривается с банком-партнером о сроках интеграции API. Когда выясняется, что интеграция займет на неделю дольше из-за требований безопасности банка, именно проджект решает, что делать: расширить срок, урезать скоуп до одного способа оплаты или подключить второго разработчика. Это его зона — продакт в эту развилку не вмешивается, если общий срок эксперимента остается приемлемым.

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

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

Такое разделение особенно заметно в разработке программного обеспечения: у крупных компаний ИТ-продукты имеют свои бюджеты и отдельные команды на каждый проект, а рынок и поведение пользователей меняются быстрее, чем успевает обновиться план. Без продакта команда рискует точно в срок сделать то, что никому не нужно — как если бы проджект просто не узнал вовремя, что рассрочка не сработала. А без проджекта хорошая гипотеза продакта так и останется гипотезой — потому что никто не переведет ее в конкретные сроки, ресурсы и ответственных.

Ключевое отличие продакт-менеджера от проджект-менеджера — не в наборе задач, а в том, какие вопросы каждый из них имеет право задавать и на что имеет право влиять. Проджект-менеджер отвечает за то, чтобы согласованная задача была выполнена вовремя, в бюджете и по ТЗ. Продакт-менеджер отвечает за то, была ли сама задача правильной — и вправе ее пересмотреть, если рынок, клиент или данные говорят об обратном.

Понимание этой границы помогает компании правильно распределять полномочия, а специалистам — понимать, за что именно они отвечают на своем месте в команде, и в какую сторону расти, если цель — стать продакт-менеджером или дорасти до head of product.

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