В предыдущей статье были тезисно расписаны основные идеи правильного масштабирования продукт-менеджмента в компаниях энтерпрайз уровня. Настало время рассмотреть каждую из идей в отдельности. Сегодня мы поговорим про то, что является продуктом в сложном решении, состоящем из множества подсистем.
Для того, чтобы понять проблему определения продукта проще всего описать ее на примере. Ниже вы можете видеть набор систем, представляющий из себя некое решение по предоставлению абстрактной услуги.
Это очень упрощенное и в чем-то типичное решение для предоставления услуг. В реальности список систем значительно шире и исчисляется десятками, при этом часть из них может быть устаревшей и должна быть заменена новыми.
В разных компаниях по разному организуют разработку таких систем. В одних компаниях можно увидеть команды разработки, которые ответственны за несколько компонент, в других — наоборот, одну компоненту может разрабатывать несколько команд. Однако чаще всего на одну систему приходится одна команда разработки. Это классический и наиболее распространенный подход компонентных команд (component teams).
Проблема определения продукта заключается в том, что продукт — это не компонента, а некоторый их набор, дополненный процессами и людьми, которые доставляют ценность определенной группе пользователей.
Представим, что на каждую из описанных выше систем приходится по одной команде разработки. Все команды работают по скраму, имеют скрам-мастера и владельца продукта. На этом месте и проявляется проблема определения продукта: владелец продукта на самом деле является владельцем компоненты.
Чем это грозит?
Основная функция владельца продукта — повышать ценность продукта для пользователей, приоритизировать требования и принимать готовую работу. Но ценность продукта зачастую создается совместной работой нескольких систем. В такой ситуации владельцу продукта сложно или вовсе невозможно определить ценность тех или иных изменений в системе и получить обратную связь пользователей.
Как же тогда определить, что такое продукт?
Чтобы ответить на этот вопрос, рассмотрим первое взаимодействие пользователя с решением. В данном случае ценностью для пользователя будет получение доступа к услуге в обмен на деньги.
Ценность — понятие субъективное. В процессе взаимодействия с решением у покупателя возникнет некоторое собственное ощущение того, насколько простым, приятным, удобным и полезным это взаимодействие. Именно за это покупатель и платит.
Оплата в свою очередь — это самый просто маркер для выделения продукта. То, за что пользователь готов платить, и называется продуктом. В данном случае это некоторый набор из систем, людей и процессов, обеспечивающий поток ценности пользователю (operational value stream).
В таком случае владельцу продукта с методологической точки зрения более правильно было бы реализовать разработку сразу нескольких систем, участвующих в потоке ценности. Такие команды разработки называются продуктовыми или функциональными (feature teams или cross-component teams).
Проблемы трансформации компонентных команд в функциональные довольно интересны и заслуживают отдельной статьи. Напишите в комментариях, если вам интересен этот опыт.
Выделение продуктов по покупкам не является единственным вариантом. Дело в том, что потоков ценности, как правило, больше, чем потоков, образованных платежами покупателей. Существуют потоки ценности направленные не на внешних пользователей, а на внутренних.
Таким потоком, например, может быть ценность, принесенная компании маркетологами, которые создают новые конфигурации для услуг и тарифов с целью привлечения новых пользователей или увеличения частоты использования услуг. Такие продукты тоже не сложно выделить на карте:
Внутренние продукты имеют свои особенности. Их критерии успеха менее понятны, а метрики сложнее выделить. Тем не менее, управлять ими можно и нужно точно также, как и продуктами для внешних пользователей.
И еще раз о том, зачем выделять продукт.
В случае, когда продукт выделен правильно, владелец продукта имеет возможность:
Влиять на все компоненты, составляющие поток ценности;
Видеть реальные метрики продукта, а не косвенные, отраженные в компоненте;
Опрашивать пользователей напрямую, понимая их проблемы, а не получать интерпретацию от продакт менеджера / главного владельца продукта
В ворохе заявок в поддержку выявлять наиболее критические, а не только те, которые относятся к его компоненте;
Фокусировать усилия команды на наиболее проблемных местах, "расшивая" одно "бутылочное горлышко" за другим.
Спасибо за внимание, в следующей статье поговорим про метрики.
antirek
Нальешь кружечку чая, откусишь печеньку — и оп, статья закончилась ))
Думаю, очевидно, что на разном уровне у вас просто разный продукт, не так ли? Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг. Если биллинг использует компоненту, то он по сути выступает заказчиком на некоторые фичи компоненты, и соответственно получает ценность компоненты.
Команда, реализующая продвижение какой-то услуги вашей компании, для которой продукт — продажа услуги, будет по сути заказчиком для биллинга, чтобы были нужные опции расчетов.
Но вы в статье говорите, что продукт — это не биллинг, и не система подбора услуг, где есть скрам-мастер и продукт-owner. А есть некий «мега-продукт», который несет «ценность». Т.е. вы просто перешли на уровень абстракции выше, когда соединение нескольких систем дает удобство для клиента? И продукт есть feature, который как раз дает добавленную стоимость (как денежное выражение ценности для клиентов)?
Отсюда следующий вопрос. Т.е. как происходит организация команд для реализации мега-продуктов? Т.е. остается ли команда, которая, например, занимается тем же биллингом.
voodoo113 Автор
Я пока сфокусировался на том, чтобы писать понятно и не сложно. Как только у меня начнет это получаться — буду писать длиннее, может даже на несколько печенек хватит.
Вот именно это и побудило меня написать первую статью. Никто не понимает точно, что нужно считать продуктом, а что просто промежуточная компонента. В итоге некоторые владельцы продуктов по сути являются аналитиками, просто расписывающими юзер стори для команд.
Сейчас я склонен считать, что продукт определяется только тем, что он решает какую-то конечную задачу для определенной группы пользователей. Подробнее я планировал раскрыть эту мысль в часте про пользователей. Там, с помощью подхода JTBD можно будет наглядно увидеть как формируется ценность того или иного продукта.
Биллинг, конечно тоже имеет ценность в контексте оказания услуги, но его роль в сценарии использования в большинстве известных мне случаев будет на уровне подфункции. Про уровни целей пользователя очень хорошо писал Алистер Коберн. Постараюсь это подробно объяснить в четвертой части этого цикла.
Чуть-чуть терпения. Про организацию команд, координацию работы продактов и наиболее популярные фреймворки я еще расскажу.