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

1. Только разработка:
"Вы нам - бэклог, мы вам - время наших программистов. Что? Документация? Ну хорошо, но только техническая."

2. Работа с требованиями:
"У вас есть только общее понимание бизнес-требований? Хорошо, мы пришлем к вам бизнес-аналитика, попробуем оформить ваши идеи в задачи для наших разработчиков."

3. Проектирование решений (Solution Design):
"Ребята, у заказчика есть ряд проблем и он хочет чтобы мы предложили подходящее решение. Надо будет поизучать контекст отрасли, основных конкурентов и используемые технологии."

И, наконец:

4. Роль Product Owner:
"Да, мы можем взять на себя составление годового роадмапа, но давайте сперва поговорим о ваших бизнес-целях."


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

У описанных стадий достаточно размытые границы, и не всегда сразу очевидно, что у проекта или заказчика есть потребность в каком-то дополнительном сервисе сверх того, что он запросил изначально. Как же определить, что проекту требуется продакт?
До запуска проекта
На стартующие проекты полезно взглянуть через призму горячо любимого продактами и стартаперами Lean Canvas и задать заказчику вопросы:

1) как он определяет целевую аудиторию продукта?
2) какую их проблему будет решать продукт? какое его ценностное предложение?
3) кто его конкуренты? в чем будет состоять преимущество будущего продукта?

Эти вопросы помогут понять, имеется ли бизнес-обоснование у проекта и насколько оно было проработано прежде чем было принято решение вложить деньги в разработку.

Если у заказчика есть это понимание, то также полезным будет взглянуть чуть дальше в будущее:

4) что необходимо будет делать после первого релиза продукта?

С одной стороны, это вопрос технического характера - о том, как заказчик представляет себе поддержку и развитие продукта. С другой стороны, здесь мы хотим услышать мысли заказчика об оценке успешности продукта. Если проект разработки длительный, то ответ на этот вопрос может быть менее детальным, так как в ходе разработки еще будет "время подумать". Тем не менее общее представление должно быть и если при этом вопросе у заказчика на лице появилась смесь удивления и непонимания, то это хороший шанс успеть разобраться в этом вместе с ним до наступления даты релиза.
Текущие проекты
В текущих проектах потребность в продакт-менеджменте чаще будет выражаться через различные "боли" (pain points). Перечислим основные из них:

1) "болит" скоуп:

- непонятно, что делать дальше
- понятно, что делать, но непонятны приоритеты

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


2) отсутствует стабильный поток обратной связи:

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


3) жалобы маркетинга/продаж:

Продакт-менеджер является связующим звеном между маркетингом/продажами и разработкой. Если существует недопонимание между этими подразделениями, то это верный сигнал о том, что имеет место недостаток коммуникации.
Вместо заключения
Несмотря на приведенное описание стадий развития компании/проекта, вопросы и боли, описанные в статье, являются достаточно универсальными и помогают расширить рассматриваемый контекст разработки.
Продакт-менеджмент всегда очень переплетен с функционированием бизнеса и, если вы начнете обращать внимание (свое и заказчика) на перечисленные аспекты, то независимо от стадии, на которой вы находитесь, это поможет вам лучше понять бизнес заказчика и начать разговаривать с ним на одном бизнес-языке. С укреплением взаимоотношений приходит доверие и в какой-то момент вы можете обнаружить, что заказчик сам спросит у вас:
"А как насчет того, чтобы вы взяли на себя product ownership в этом проекте?"

Автор: Andrey Kharchenko
This site was made on Tilda — a website builder that helps to create a website without any code
Create a website