Конфликты продактов и проджектов и пути решения. Мнение из сообщества GoPractice

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

В этом материале CPO стартапа Виктор Дмитриев на основе своего опыта разбирает источники возможных конфликтов проджектов и продактов и предлагает свои рекомендации того, как их минимизировать и сделать совместную работу продуктивной.

В конце материала вы найдете ссылку на наш пост в телеграме, где вы можете проголосовать: согласны ли вы с позицией автора или нет. Также вы можете написать нам на почту dima@gopractice.io, если хотите поделиться развернутым комментарием.

Далее — текст от лица автора.

***

Введение

Меня зовут Виктор Дмитриев. Последние девять лет я работаю в IT, и мой опыт делится на два основных блока:

— Первые четыре года своей карьеры я работал в роли бизнес-аналитика (BA), затем Senior BA и Head of BA Group. Начинал свой путь я в стартапе Inframine, затем перешел в KPMG, где занимался инхаус-разработкой и автоматизацией внутренних процессов.

— А последние пять лет я развивался по пути продакта: продакт-менеджером в одном из крупнейших криптообменников Европы Paybis, а затем в финтех-компании под NDA (не могу разглашать название компании в публичных источниках) как Head of Product, где я занимался развитием white-label криптобиржи. И последний год я занимаюсь развитием стартапа Shokran в роли CPO, где мы пытаемся сделать первый глобальный необанк на базе принципов этических финансов.

За эти девять лет я в каждой из своих ролей так или иначе взаимодействовал с проджект-менеджерами:

• Как начинающий BA я функционально был подчиненным проджекта (хоть линейно им и не был): проджект ставил мне задачи на описание каких-то конкретных требований к функциональности, а я писал определенные куски ТЗ. Сейчас я понимаю, что это работало неидеально, но тогда у меня было слишком мало опыта и знаний, чтобы что-то поменять.
• Когда я стал Senior BA, мы с проджектом были как «два брата». Проджект мог полностью положиться на меня во многих вопросах: в проведении встреч с заказчиком/юзерами, в «челлендже» требований заказчика, в написании всего ТЗ с полным пониманием всех областей разработки. При этом проджект занимался вопросами ресурсного и проектного планирования, не погружаясь в вопросы требований и ТЗ.
• Однако после того как я стал продакт-менеджером, структура взаимодействия с проджектами стала менее понятной, и начали возникать различные конфликты и проблемы.

В этом материале я хочу раскрыть потенциальные конфликты между продактом и проджектом, их корни и возможные пути преодоления.

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

Зоны ответственности

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

На мой взгляд, разметить эту границу можно так:

Таким образом, если коротко, то основное отличие между проджектом и продактом заключается в том, что первый управляет конкретным проектом с упором на его выполнение в рамках определенных параметров (время, бюджет, ресурсы), а второй ответственен за стратегию, развитие и успешное продвижение продукта на рынке.

Возникающие конфликты и их природа

Соответственно, конфликты между продактом и проджектом, как мне кажется, лежат в трех основных плоскостях:

Цели

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

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

Пройти симуляторы от GoPractice можно в группе с опытным ментором.

Что вы получите:

✅ Онлайн-встречи для обсуждения прогресса и разбора вопросов
✅ Общение в закрытом чате для постоянной обратной связи с ментором и одногруппниками
✅ Дополнительные кейсы от ментора

Поддержка ментора доступна при обучении:

→ в «Симуляторе управления продуктом на основе данных»
→ в «Симуляторе управления ростом продукта»
→ в «AI/ML-симуляторе для продакт-менеджеров»

Критерии успеха

Для продакта главным критерием успеха является рост метрик / P&L, при этом для проджекта основной критерий успеха — это довести проект до конца с имеющимися ресурсами.

• Например, продакт решил добавить в финтех приложение подарочные карты магазинов-партнеров, которые пользователи смогут покупать и дарить друзьям. У продакта уже есть подтвержденная уверенность в том, что эта фича позволит улучшить метрики, поэтому вместо обычной проверки гипотезы и выпуска MVP продакт хочет сразу выпустить полноценный продукт или хотя бы MLP-версию.
• Но для этого требуются большие ресурсы, в том числе привлечение людей из других проектов. Продакт уверен, что такое перераспределение поможет улучшить продуктовые метрики. Проджект возражает, поскольку это прямо противоречит его KPI по числу успешно завершенных проектов.

Толерантность к изменениям

Продакт готов реагировать на изменения рынка и при необходимости отложить выпуск продукта, чтобы сделать его более актуальным. Это опять же идет в противоречие KPI проджектa, который закоммитился выпустить проект в срок.

• Например, продакт решил добавить функционал рекуррентных платежей в свое мобильное приложение.
• Когда 30% уже было разработано, продакт понимает, что появился новый провайдер рекуррентных платежей с лучшими UX и функциональностью. Продакт решает, что для продукта выгоднее остановить разработку, начав ее через какое-то время с новым провайдером. Проджект же против остановки проекта, потому что он закоммитился на сроки проекта перед своим менеджментом.

Как их можно решить? 

Важно понимать, что продакт и проджект подчиняются разным линейным руководителям: CPO и Head of PMO соответственно. Поэтому эскалация на вышестоящее руководство часто не помогает.

Будучи продактом, я пробовал разные способы решения конфликтов с проджектом, и здесь я поделюсь с вами наиболее успешными практиками из своего опыта:

Точно определите ваши зоны ответственности и роли

В моей практике помогло такое разделение:

— Продакт берет на себя наполнение бэклога команды.

— Проджект — управление реализацией этого бэклога без простоев внутри команды.

Соответственно, проджект не должен негативно реагировать, когда планы команды меняются. Так же и продакт не должен негативно реагировать, если проджект меняет процессы разработки/оценки внутри команды разработки.

Когда я только начинал работать продактом, мы с проджектом часто пытались перетянуть одеяло на себя. Одна встреча по четкому разделению зон ответственности и критериев успеха каждого из нас помогла решить все проблемы: я начал отвечать за продуктовые метрики, проджект — за delivery-метрики команды разработки.

Продакт транслирует общее видение продукта всей команде разработки

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

— Каждый квартал делиться с командой планами по развитию продукта на ближайший квартал, включая ожидаемые изменения метрик и влияние на бизнес.

— Ежемесячно проводить встречу с командой по прогрессу квартальных планов и подсвечивать ключевые результаты.

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

Регулярная коммуникация продакта и проджекта 

Хоть это и звучит достаточно очевидно, почему-то про нее часто забывают. Мне помогли еженедельные one-on-one встречи с проджектом. На них мы делились изменениями в планах команды, в планах бизнеса, болями и предложениями. Чем больше рассинхрон в целях/планах, тем выше должна быть регулярность у этих встреч.

Стоит привить команде толерантность к неопределенности

В силу специфики роли, продакты более открыты к изменениям и неопределенности, чем, например, команда разработки. Правда в том, что последние годы мы живем в очень динамичном мире. Тем не менее некоторые проджекты и команды до сих пор работают по архаичному waterfall или же по якобы по Agile, но все равно со строгими этапами, сроками, коммитами. Но кому будет польза от выпущенного в срок проекта, если он не принес компании денег?

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

Будьте строже

Наконец, если команда продолжает всячески противиться изменениям, надо стать более строгим продактом.

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

Заключение

Конфликты между продактом и проджектом исходят из разных фокусов этих ролей и лежат в трех основных областях: целеполагание, кретерии успеха, толерантность к изменениям. Чтобы решать или хотя бы минимизировать эффект от этих конфликтов, стоит: 

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

***

Узнайте больше

— FAQ: как продакт-менеджеру наладить взаимодействие с командой разработки?

— Как повысить эффективность продуктовых аналитиков в разы

— Какими навыками продакт-менеджера должны обладать все: дизайнеры, разработчики, аналитики, тестировщики

Поделитесь своим мнением

Проголосуйте в нашем телеграм-канале:

— 👍 если согласны с мнением автора

— 👎 если не согласны

А если у вас есть развернутый комментарий к тексту, то напишите нам на dima@gopractice.io, чтобы мы могли дополнить материал вашей позицией.