Менеджмент Ольга Ленская, «Про бизнес» 7 сентября 2021

«Продакт» и «проджект» — в чем разница и кто на самом деле нужен бизнесу

Юрий Бранковский. Фото предоставлено автором

В интернете часто обсуждают, в чем разница между менеджером по продукту (Product Manager) и проектным менеджером (Project Manager). «Бизнес не всегда четко понимает, кто ему нужен: берет „продакта“, потому что он вроде бы круче, в то время как ему нужен „проджект“, или наоборот. В итоге специалист заваливает задачи и сроки, выгорает или быстро уходит, потому что занимается не своей работой», — делится опытом Юрий Бранковский, продакт-менеджер, ментор и член жюри хакатонов Emerge и Epam engineering jam. О роли «проджекта» и «продакта» в компании читайте в нашем интервью.

— Юра, расскажи, чем ты занимаешься, проектами или продуктами? И в чем разница? Нужен ли Project Manager в проекте, если есть Product Manager?

— Я занимаюсь и тем, и другим. Есть проекты, которые важны для развития продукта. Отсюда следует краткий ответ на последний вопрос: нужен. А более подробный зависит от контекста. Для начала давайте разберемся, кто есть кто.

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

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

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

Product Manager — это человек, управляющий продуктом, отвечающий за создание новых продуктов, анализ рынка, ассортиментную политику, ценообразование, продвижение продукта, планирование KPI, формирование требований к продукту, определение назначения продукта.

Такой человек активно взаимодействует с продажами, маркетингом, технической поддержкой, производством, R&D и т.д. Функциональность менеджера по продукту напрямую зависит от типа компании (производитель, дистрибьютор, дилер, системный интегратор, стартап) — то есть это не обязательно будет сфера ИТ.

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

Следующим шагом после разработки идеи является выстраивание рабочей стратегии. В большинстве случаев менеджер по продукту делает это вместе с проектным менеджером, чтобы создать осуществимый план.

«Продакт» в любом случае должен уметь настраивать процессы и осуществлять менеджмент. Но по мере расширения количества команд и людей в командах он вполне может делегировать управление процессами «проджекту», освобождая время на более важные задачи. Например, может сконцентрироваться на метриках, выручке, growth hacking (рост и продвижение компании) и так далее.

Но важно понимать, что «проджект» не отвечает за бизнес-показатели, метрики продукта. Только за time to market (время от начала разработки идеи до ее конечной реализации) — наряду с тимлидом.

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

— То есть менеджер по продукту не обязательно должен управлять процессами?

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

— А насколько «продакт» должен быть погружен в процессы, как понять, что надо уже что-то делегировать?

— Это зависит от стадии продукта. Например, в стартапе «продакт» максимально погружен в процессы, потому что там процессы быстро меняются в зависимости от того, как развивается продукт. Как-то мы делали сервис видеоинтервью для платформы автоматизации отбора кандидатов. Но пришел крупный заказчик и сказал, что готов заплатить еще и за доработку цифровой анкеты для кандидатов. И мы сделали эту анкету, хотя в бэклоге этого не было. Стартапу важна выручка. Поэтому «продакт» вел параллельно этот проект с заказчиком.

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

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

— Что значит «в ущерб развитию продукта»?

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

— А почему бы не нанять еще одного «продакта»?

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

— Ты про шеринг разработчиков?

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

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

— Насколько глубоко у «продакта» должны быть проработаны навыки менеджмента?

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

Тайм-менджемент
Планирование
Управление и контроль.

Суть менеджмента в том, чтобы добиваться результата; прогнозировать его с максимальной точностью, чтобы добиваться максимальных бизнес-показателей за меньшие деньги. Наверное, идеальный менеджер — тот, который на 100% выполнил план так, как задумывал, и принес компании столько денег, сколько планировал. И делает все это регулярно.

— Ты таких встречал?

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

Но ведь менеджеру платят деньги за менеджмент (простите за тавтологию)! Соответственно, задача «продакта» — сделать максимально точный роадмэп, или дорожную карту продукта. Это наглядный документ, в котором описываются шаги, которые вы планируете предпринять, чтобы продукт соответствовал вашему видению. Составление роадмэпа помогает понять, на какой стадии продукт находится сегодня, направление, в котором он движется, и каким образом будут достигнуты поставленные цели.

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

Вот представьте, что вы — менеджер крупного продукта, отвечаете за бизнес-результаты. Для усложнения пусть продукт еще будет операционный. Соответственно, для успеха должны классно сработать команды привлечения, онбординга, сопровождения, продукта, поддержки и так далее. Без высокого уровня владения навыками менеджмента все просто развалится.

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

— А если речь о небольшой команде?

— А в чем принципиальная разница? Меньше команда — хорошо. Это не отменяет того, что «продакт» должен принести планы топ-менеджменту, а затем выполнить их и показать результат. Представьте, что он будет планировать одно, а результаты показывать совершенно другие. Это говорит о том, что «продакт» не представляет, что делает, и действует по наитию. Для стартапа это еще может сработать, а на этапе роста или превращения стартапа в компанию все просто начнет валиться из-за неотстроенных процессов. Например, если нет четкого процесса обработки запросов клиентов, то когда этих запросов станет в разы больше, команда поддержки не справится и не успеет масштабироваться, потому что при отсутствии процессов масштабируется хаос.

— То есть «проджект» — это часть «продакта»?

— Я бы сказал по-другому. Вот в команде есть «продакт», который больше специализируется на дизайне, — это продуктовый дизайнер. Есть «продакт», который лучше разбирается в коде, — это разработчик. А есть «продакт», который является гуру в управлении процессами, — это «проджект». То есть продуктовое мышление есть у каждого, просто в чем-то коллеги сильнее, и это очень круто. Невозможно быть одинаково сильным во всем.

— Получается, что выбор между наймом «продакта» или «проджекта» зависит от стадии продукта, размера компании, специфики бизнеса?

— Я считаю, что выбор не должен стоять «или — или». Это разные профессии, и каждая необходима для выполнения определенных задач. Просто «продакт» может в себя включать «проджекта» (но не обязательно), а «проджект» не включает «продакта» (иначе он сам становится «продактом»).

И если в продукте есть отдельные проекты — то продуктолог реализует навыки «проджекта». Поэтому при четком понимании, нужно развивать продукт или реализовывать проекты, вопрос о выборе отпадает сам собой.