Границы ответственности продакт-менеджеров и проджект-менеджеров могут размываться, что потенциально приводит к конфликтам. Проджекту важно завершить проект в срок и в рамках бюджета, тогда как продакт может жертвовать этим ради достижения бизнес-целей.
В этом материале CPO стартапа Виктор Дмитриев на основе своего опыта разбирает источники возможных конфликтов проджектов и продактов и предлагает свои рекомендации того, как их минимизировать и сделать совместную работу продуктивной.
В конце материала вы найдете ссылку на наш пост в телеграме, где вы можете проголосовать: согласны ли вы с позицией автора или нет. Также вы можете написать нам на почту dima@gopractice.io, если хотите поделиться развернутым комментарием.
Далее — текст от лица автора.
***
Введение
Меня зовут
— Первые четыре года своей карьеры я работал в роли бизнес-аналитика (BA), затем Senior BA и Head of BA Group. Начинал свой путь я в стартапе Inframine, затем перешел в KPMG, где занимался инхаус-разработкой и автоматизацией внутренних процессов.
— А последние пять лет я развивался по пути продакта: продакт-менеджером в одном из крупнейших криптообменников Европы Paybis, а затем в финтех-компании под NDA (не могу разглашать название компании в публичных источниках) как Head of Product, где я занимался развитием white-label криптобиржи. И последний год я занимаюсь развитием стартапа Shokran в роли CPO, где мы пытаемся сделать первый глобальный необанк на базе принципов этических финансов.
За эти девять лет я в каждой из своих ролей так или иначе взаимодействовал с проджект-менеджерами:
- Как начинающий BA я функционально был подчиненным проджекта (хоть линейно им и не был): проджект ставил мне задачи на описание каких-то конкретных требований к функциональности, а я писал определенные куски ТЗ. Сейчас я понимаю, что это работало неидеально, но тогда у меня было слишком мало опыта и знаний, чтобы что-то поменять.
- Когда я стал Senior BA, мы с проджектом были как «два брата». Проджект мог полностью положиться на меня во многих вопросах: в проведении встреч с заказчиком/юзерами, в «челлендже» требований заказчика, в написании всего ТЗ с полным пониманием всех областей разработки. При этом проджект занимался вопросами ресурсного и проектного планирования, не погружаясь в вопросы требований и ТЗ.
- Однако после того как я стал продакт-менеджером, структура взаимодействия с проджектами стала менее понятной, и начали возникать различные конфликты и проблемы.
В этом материале я хочу раскрыть потенциальные конфликты между продактом и проджектом, их корни и возможные пути преодоления.
Я пишу это на основе личного опыта, поэтому часть тезисов могут звучать субъективно. В некоторые компаниях продакт и проджект в принципе не работают вместе. Или могут работать и избегать конфликтов. Однако если сложности в работе возникают, надеюсь, мои рассуждения могут быть полезными.
Зоны ответственности
Продакт-менеджер и проджект-менеджер — это две разные роли, но слишком часто границы ответственности обоих размывается.
На мой взгляд, разметить эту границу можно так:
Роль | Фокус | Задачи |
Продакт-менеджер | Достижение бизнес-целей продукта и удовлетворение потребностей пользователей | — Определение стратегии продукта и его позиционирование на рынке — Разработка роадмапа продукта — Анализ конкурентов, рынка, пользовательских потребностей — Поиск и развитие уникальной продуктовой ценности |
Проджект-менеджер | Выпуск проекта в рамках бюджета и сроков | — Планирование и организация работы команды — Управление ресурсами и бюджетом проекта — Мониторинг прогресса и контроль выполнения задач — Работа с рисками и проблемами проекта |
Таким образом, если коротко, то основное отличие между проджектом и продактом заключается в том, что первый управляет конкретным проектом с упором на его выполнение в рамках определенных параметров (время, бюджет, ресурсы), а второй ответственен за стратегию, развитие и успешное продвижение продукта на рынке.
Возникающие конфликты и их природа
Соответственно, конфликты между продактом и проджектом, как мне кажется, лежат в трех основных плоскостях:
Цели
Продакт стремится создать долгосрочную ценность, а проджект ориентирован на плановое выполнение конкретных, поставленных перед командой задач в определенные сроки. Часто, когда проджект и продакт работают на одном продукте/проекте, эти два измерения начинают конфликтовать.
- Например, в середине спринта продакт-менеджер решает отправить команду проработать интеграцию с другим KYC-провайдером, потому что в долгосроке этот партнер потенциально принесет больше пользы за счет более высокой конверсии в автоматическое прохождение KYC.
- При этом проджект-менеджер уже закоммитился на выполнение определенного скоупа задач, от которых могут зависеть другие команды. Нарушение коммитов перед другими командами негативно отразится на перформанс-ревью проджекта.
Критерии успеха
Для продакта главным критерием успеха является рост метрик / P&L, при этом для проджекта основной критерий успеха — это довести проект до конца с имеющимися ресурсами.
- Например, продакт решил добавить в финтех приложение подарочные карты магазинов-партнеров, которые пользователи смогут покупать и дарить друзьям. У продакта уже есть подтвержденная уверенность в том, что эта фича позволит улучшить метрики, поэтому вместо обычной проверки гипотезы и выпуска MVP продакт хочет сразу выпустить полноценный продукт или хотя бы MLP-версию.
- Но для этого требуются большие ресурсы, в том числе привлечение людей из других проектов. Продакт уверен, что такое перераспределение поможет улучшить продуктовые метрики. Проджект возражает, поскольку это прямо противоречит его KPI по числу успешно завершенных проектов.
Толерантность к изменениям
Продакт готов реагировать на изменения рынка и при необходимости отложить выпуск продукта, чтобы сделать его более актуальным. Это опять же идет в противоречие KPI проджектa, который закоммитился выпустить проект в срок.
- Например, продакт решил добавить функционал рекуррентных платежей в свое мобильное приложение.
- Когда 30% уже было разработано, продакт понимает, что появился новый провайдер рекуррентных платежей с лучшими UX и функциональностью. Продакт решает, что для продукта выгоднее остановить разработку, начав ее через какое-то время с новым провайдером. Проджект же против остановки проекта, потому что он закоммитился на сроки проекта перед своим менеджментом.
Как их можно решить?
Важно понимать, что продакт и проджект подчиняются разным линейным руководителям: CPO и Head of PMO соответственно. Поэтому эскалация на вышестоящее руководство часто не помогает.
Будучи продактом, я пробовал разные способы решения конфликтов с проджектом, и здесь я поделюсь с вами наиболее успешными практиками из своего опыта:
Точно определите ваши зоны ответственности и роли
В моей практике помогло такое разделение:
— Продакт берет на себя наполнение бэклога команды.
— Проджект — управление реализацией этого бэклога без простоев внутри команды.
Соответственно, проджект не должен негативно реагировать, когда планы команды меняются. Так же и продакт не должен негативно реагировать, если проджект меняет процессы разработки/оценки внутри команды разработки.
Когда я только начинал работать продактом, мы с проджектом часто пытались перетянуть одеяло на себя. Одна встреча по четкому разделению зон ответственности и критериев успеха каждого из нас помогла решить все проблемы: я начал отвечать за продуктовые метрики, проджект — за delivery-метрики команды разработки.
Продакт транслирует общее видение продукта всей команде разработки
Продакт должен транслировать общее видение продукта, ценности, ключевые метрики не только проджекту, но и всей команде разработки. Желательно делать это на регулярной основе. Если команда будет понимать, что планы разработки часто меняются из-за ситуации на рынке и в бизнесе и что новые планы должны улучшить метрики продукта, команда охотнее будет включаться в новые задачи. Любая команда, которая видит ценность своего труда, гораздо сильнее мотивирована, чем команда, работающая в вакууме. Мне помогли такие ритуалы:
— Каждый квартал делиться с командой планами по развитию продукта на ближайший квартал, включая ожидаемые изменения метрик и влияние на бизнес.
— Ежемесячно проводить встречу с командой по прогрессу квартальных планов и подсвечивать ключевые результаты.
— Каждый раз, когда что-то в планах меняется, сразу сообщать команде об этих изменениях, четко объясняя мотивацию этих изменений.
Регулярная коммуникация продакта и проджекта
Хоть это и звучит достаточно очевидно, почему-то про нее часто забывают. Мне помогли еженедельные one-on-one встречи с проджектом. На них мы делились изменениями в планах команды, в планах бизнеса, болями и предложениями. Чем больше рассинхрон в целях/планах, тем выше должна быть регулярность у этих встреч.
Стоит привить команде толерантность к неопределенности
В силу специфики роли, продакты более открыты к изменениям и неопределенности, чем, например, команда разработки. Правда в том, что последние годы мы живем в очень динамичном мире. Тем не менее некоторые проджекты и команды до сих пор работают по архаичному waterfall или же по якобы по Agile, но все равно со строгими этапами, сроками, коммитами. Но кому будет польза от выпущенного в срок проекта, если он не принес компании денег?
Это, наверное, один из самых сложных советов, поскольку толерантность к неопределенности прививать очень сложно, но мне помогла работа с психологией команды: следует рассказать про новые практики в разработке, новые тенденции, новые технологии. Все это поможет команде быть более готовой к изменениям, когда они придут. А они приходят всегда.
Будьте строже
Наконец, если команда продолжает всячески противиться изменениям, надо стать более строгим продактом.
Я себя считаю достаточно демократичным менеджером, но и у меня возникали кейсы, когда было необходимо надавить на команду: следует прямо объяснить команде разработки, что спрашивать за рост вашего сегмента бизнеса топ-менеджмент будет с вас, и именно поэтому финальное решение по развитию продукта остается за вами. Даже если команда инвестировала много времени в реализацию текущей задачи, следует ее остановить, если новая задача принесет больше пользы бизнесу.
Заключение
Конфликты между продактом и проджектом исходят из разных фокусов этих ролей и лежат в трех основных областях: целеполагание, кретерии успеха, толерантность к изменениям. Чтобы решать или хотя бы минимизировать эффект от этих конфликтов, стоит:
- четко определить и разграничить ваши зоны ответственности;
- транслировать общее видение продукта, ценности, ключевые метрики команде;
- регулярно коммуницировать с проджектом по изменениям;
- прививать команде толерантность к неопределенности;
- наконец, в ряде случае быть более строгим продактом, если это необходимо.
***
Узнайте больше
— FAQ: как продакт-менеджеру наладить взаимодействие с командой разработки?
— Как повысить эффективность продуктовых аналитиков в разы
Поделитесь своим мнением
Проголосуйте в
— 👍 если согласны с мнением автора
— 👎 если не согласны
А если у вас есть развернутый комментарий к тексту, то напишите нам на dima@gopractice.io, чтобы мы могли дополнить материал вашей позицией.