Продакт vs. Проджект: чем отличаются профессии, которые часто путают
Ольга Стратанович, Program Director в ProductSense и Chief Product Officer в «Киноплан», рассказала о ключевых отличиях в мышлении и навыках менеджера продукта и менеджера проекта.
Профессия «менеджер продуктов» пока еще молодая в СНГ, но уже востребована на рынке. Компании с собственной разработкой ищут человека, который сможет выпустить и сопровождать продукт. Заказная разработка тоже нуждается в продуктовом подходе. Но хороших менеджеров продуктов на всех не хватает, поэтому возникает необходимость брать джуниоров из других областей.
Самой близкой областью считается менеджмент проектов. Я часто встречаю бывших менеджеров из заказной разработки, которые перешли в менеджмент продуктов. Они не понимают, какие изменения должны произойти на новой работе. Обычно они думают, что это всего лишь следующая ступень проектного менеджмента.
Давайте разберем, чем отличается менеджер продукта от менеджера проекта.
Зона ответственности
Главные метрики успешности проекта — срок, бюджет и объем задач. Менеджер проекта должен получить требования от стейкхолдеров, согласовать бюджет и проследить, чтобы проект сдали в срок. Его не интересует, что произойдет дальше:
— как конечный пользователь получит проект и будет его использовать,
— как проект будет или не будет развиваться.
Для менеджера продукта главное — донести пользу до клиента. Создание продукта — только небольшая часть ответственности менеджера продукта. Ему нужно думать о необходимости и эффективности функционала, «упаковке», доставке, сопровождении и развитии продукта.
Генерация и валидация гипотез
Менеджер проекта не генерирует идеи: к нему поступает задача, которую он обязан выполнить эффективно. Хороший менеджер уточнит у заказчика цель проекта, вместе с ним подумает над оптимальным решением и может быть предложит свое. Но он не выдвигает и не проверяет гипотезы — этим обычно занимаются владелец бизнеса, заказчик и другие стейкхолдеры.
Основная задача менеджера продукта — выявлять потребности и предлагать идеи для улучшения продукта. Менеджер продукта много общается с пользователями, проводит глубинные интервью, выдвигает, проверяет и отвергает гипотезы. Все это он может выполнять даже без команды разработки. Он не знает, что ему делать, но ищет свой путь.
Условия неопределенности
Менеджер проекта действует в заранее обозначенных условиях: объем задач известен (его можно уменьшить, но не намного), сроки и бюджет согласованы. Обязанности менеджера обычно четко прописаны в гайдах, внутренних регламентах и правилах компании.
Менеджеру продукта повезло меньше: он никогда точно не знает, что должен сделать. Какая гипотеза окажется провальной, а какая принесет прибыль? Здесь появляются MVP, экономические расчеты, метрики, A/B тесты, валидация прототипов — всё, что помогает оценить идею.
Менеджеру продукта надо признавать провал экспериментов и безжалостно удалять функционал, который не приносит ожидаемой пользы. Ему приходится отказываться от собственных идей и пожеланий клиентов.
Метрики
На собеседовании я всегда прошу кандидата рассказать, какие метрики были у его последнего продукта или какие метрики он бы выбрал, если бы был владельцем продукта. Бывшие менеджеры проектов отвечают: «Количество пользователей» или «Мы прикручивали аналитику, но я туда не заглядывал».
Менеджер продукта всегда смотрит глубже: метрик много, и каждый продукт требует своего подхода. Умение выбрать метрики, проанализировать и принять на основе анализа решение — один из важнейших навыков в этой профессии.
Экономика
Менеджер проекта не думает об окупаемости, его задача — уложиться в согласованный бюджет.
Для менеджера продукта окупаемость стоит на первом месте. Сколько мы потратим? Какую модель монетизации выбрать? Как привлекать пользователей и увеличивать Lifetime Value? Как получить дополнительную прибыль? Это вопросы, на которые мы ищем ответы постоянно.
Продажи, внедрение и сопровождение
С этим менеджер проекта обычно не сталкивается. Проект принят, документы подписаны — на этом его зона ответственности заканчивается. Если проект нужно сопровождать или что-то в нем дорабатывать, компания заключит новый контракт или запустит внутренний проект с новым бюджетом, объемом задач и сроками.
Для менеджера продукта готовый функционал — это только начало. Нужно договориться со смежными отделами, «упаковать» продукт, доставить клиенту, объяснить ценность отделу продаж. Важно убедиться, что продукт сопровождают качественно: например, в b2b сопровождение не менее важно, чем функционал продукта.
Взаимодействие между командами и построение эффективных процессов — еще один вызов для менеджера продукта.
Коммуникации
Менеджер проекта принимает требования от стейкхолдеров и передает команде разработки.
У менеджера продукта коммуникаций гораздо больше. Он — точка входа в команду для всех смежных отделов. К нему стекается весь поток вопросов от отделов продаж, маркетинга и сопровождения. Он постоянно общается с клиентами. Топ-менеджеры транслируют ему свое видение.
Эффективные коммуникации и фильтрация входящего потока — это первое, чему должен научиться менеджер продукта.
Стратегия и видение
Менеджер проекта действует в рамках срока проекта — обычно он длится не более года. Цели чаще всего ставят владелец бизнеса или заказчики. Менеджер проекта управляет только контрольными точками в рамках этого срока.
Менеджер продукта формирует собственное видение, куда движется его продукт и каким он станет через 1−3−5 лет. Он должен четко понимать, как та или иная задача приближает продукт к цели, и иногда жертвовать краткосрочными результатами.
Риск-менеджмент
Хороший менеджер проектов всегда думает о рисках и минимизирует их негативное влияние.
Менеджер продукта думает о возможностях. Любая неопределенность или проблема — это потенциальная возможность улучшить продукт. Менеджер продукта думает, как извлечь дополнительную выгоду и сделать то, чего еще никто не делал.
Вдохновление
Менеджер проекта должен принести в команду хорошо описанную понятную задачу: Что делать? Как делать? В какие сроки делать?
Менеджеру продукта надо «продать» боль пользователя и вместе с командой выработать оптимальное решение этой боли. Команде с продуктовым мышлением нельзя просто принести задачу — они начинают задавать сложные вопросы. Это очень хорошо для продукта, но требует от менеджера навыков продвижения своих идей, вдохновления команды, объяснения проблем.
В бизнесе много говорят о продуктовом мышлении команд. Появляется определение продуктового инженера — разработчика, который не просто берет и делает задачу, но думает о пользователе, предлагает свои решения.
Карта компетенций
Профессия менеджера проектов давно сформировалась. Набор его навыков определен и понятен.
Профессия менеджера продуктов еще молодая. В разных компаниях у него могут быть разные обязанности, поэтому навыки должны быть шире. Это не только управление, но и маркетинг, основы экономики, аналитика, умение вести переговоры, лидерство, основы дизайна и многое другое.
Менеджер продукта «болеет» за продукт. Продукт плохо продается — это его проблема. Нужно идти в отдел продаж и выяснять причины, помогать построить процесс, подготовить маркетинговые материалы. Нет ресурсов на разработку — идти к HR (это не обязанность менеджера, но что если важные задачи тормозит нехватка разработчиков?). Нет дизайнера — рисовать макеты самостоятельно. Пусть это будет непрофессионально, но целью должен быть не идеальный макет, а польза для клиента.
Важно, чтобы менеджер продукта мог сделать что-то самостоятельно, если делать некому, или найти человека, которому это можно делегировать. Менеджеру продукта нельзя говорить: «Это не моя обязанность, я не буду за это отвечать». Ему надо делать все возможное, чтобы продукт был успешен.
Подведем итог
У меня нет цели показать, что менеджеры продукта круче, чем менеджеры проекта. Я видела прекрасных продуктологов, которые никогда не смогли бы вести сложные проекты и писать подробные ТЗ. Я хотела показать разницу в мышлении и сфере ответственности. Если вы решите перейти из проектной разработки в продуктовую, вам придется:
- Мыслить за пределами разработки: что делать и как доставить пользу, а не как сделать
- Генерировать, проверять и отсекать гипотезы.
- Смириться с неопределенностью и уменьшать ее.
- Ставить и анализировать метрики.
- Думать об окупаемости.
- Искать новые возможности.
- Научиться жить с возросшим числом коммуникаций.
- Формулировать и «продавать» свои идеи.
- Быть готовым разбираться с любыми проблемами в продукте.
- Брать на себя ответственность за успех или провал продукта.
