Треугольник управления продуктом
--
Недавно я наткнулась на абсолютно потрясающую серию статей Daniela Schmidta, которая начинался со статьи “The Product Management Triangle”. Излюбленная тема: “Кто же такой менеджер продукта и что он делает?”. Но внутри настолько структурированные и близкие к моему восприятию поднятой темы мысли, что не могла не поделиться. С разрешения самого Daniela — ловите ее перевод на русский.
Введение
Роль менеджера продукта стала критически необходимой практически во всех IT компаниях. Тем не менее, точного определения термину “менеджмент продукта” до сих пор не существует. Перечень задач, которые выполняют люди, называющие себя “Менеджерами продукта” варьируется от компании к компании. Они работают над разными продуктами, с разными типами команд, в компаниях с различной структурой организации. Набор задач, над которыми работают менеджеры продукта в разных компаниях, часто настолько отличается, что может казаться ошибкой вообще называть двух этих людей одинаковым названием. А попытки выцепить что-то общее из этих двух списков приводит к такому уровню обобщения, что понимание реальных ценностей и задач роли теряются. Вот пример таких точных, но расплывчатых описаний: “определяет слепые зоны” или “играет связующую функцию между кросс-функциональными командами”.
Роль менеджера продукта действительно неоднозначна. Даже в пределах одной компании его обязанности могут быстро и радикально измениться. Менеджеры продукта работают в постоянно изменяющихся условиях. Технологии меняются, изменяется командная динамика, общество, неожиданно появляются новые возможности для бизнеса. И это особый навык — определять, какие из этих изменений имеют значение для продукта и для самой роли. С этой точки зрения, менеджеры продукта вынуждены постоянно пересматривать пул своих задач на регулярной основе.
Но что это за особый навык, позволяющий определять, что именно приведет к росту и развития продукта под влиянием изменений среды, и реализовывать это? По сути менеджеры продукта простраивают мостики от очень общих вещей (трендов изменения мира) к очень конкретным вещам (функциональные требования к одной конкретной кнопке). Но, как бы это иронично ни звучало, сама дисциплина менеджмента продукта где-то потеряла этот мостик. У нас до сих пор нету четкого понимания верхнеуровневых и ежедневных задач менеджера продукта. Я разработал графическую модель треугольника менеджмента продукта, чтобы он стал этим мостиком и обеспечил более глубокое понимание темы управления продуктом.
Продуктовая среда
Чтобы подготовить почву, я хочу сначала описать среду, в которой существует менеджер продукта. Диаграмма продуктовой среды приведена на рисунке ниже. На мой взгляд, она отображает ключевые элементы контекста среды разработки цифрового продукта. Многие аспекты продукта и создающих его людей являются переменными, но эти элементы всегда будут присутствовать.
В сердце фреймворка лежит сам продукт. Продукт в IT-компании по факту представляет собой программный код, размещенный в среде, где пользователи могут получить доступ к его функциональности. Все продукты соединены с тремя элементами: разработчики, пользователи и бизнес.
Разработчики (инженеры) — люди, которые пишут и разворачивают код. В компании могут быть люди, которые работают над продуктом, но не программируют (а может не быть). Но люди которые пишут код — обязательное условие. Разработчики в принципе могут выполнять любые задачи, возникающие в компании (хотя и не всегда самым эффективным способом).
Пользователи (клиенты) — люди, уже использующие продукт или потенциально имеющие возможность его использования. У каждого продукта есть цель — быть используемым на каком-либо уровне людьми.
Бизнес — это сущность, вкладывающая деньги в продукт и надеющаяся получить прибыль. Независимо от того, является ли организация коммерческой или некоммерческой, существует ограниченный в своем размере бюджет.
Среда, в которой существует продукт, может состоять только из этих элементов. Например, компания может быть основана разработчиками, иметь достаточный бюджет для старта и большую мечту о росте клиентской базы. Но это приводит к появлению белых пятен. “Белые пятна” — это недостающие связи в среде. Если есть роли, восстанавливающие их, это приводит к повышению эффективности всей среды, и, как следствие, повышению успешности продукта. Если быть более точным, есть три области “белых пятен”, которые обозначены на Рис.2 как A, B и C.
Белое пятно A
Область А — белое пятно между разработчиками, продуктом и пользователями. У разработчиков и пользователей в голове разные ментальные модели продукта. Не смотря на то, что разработчики могут сами использовать свой продукт, их ментальная модель наполнена знаниями о том, как продукт работает. Поэтому сталкиваясь с потребностью изменений, трудолюбивые и талантливые инженеры, как правило, выбирают решения, которые не требуют от них больших усилий, не портят и не усложняют уже написанный код. Пользователи же знают продукт только из своего опыта взаимодействия с ним. Возможно, они и смогут рассказать, как работает ваш продукт под капотом, основываясь на каких-то своих базовых знаниях. Но будем честны: обычно они не знают (а на самом деле, им вообще все равно). Пользователи используют продукты потому, что они решают какие-то их проблемы и задачи. Их не очень волнует то, насколько дорога был разработка, и красив ли получился код.
И хотя встречаются инженеры, которые могут посмотреть на продукт с точки зрения пользователя и простроить недостающие связи в этом белом пятне, растущему бизнесу, как правило, требуется отдельный человек, который бы соединил миры разработки и клиентов. Роль дизайнера в данном случае хорошее решение. Задача дизайнера — понимать ментальные модели пользователей и создавать пользовательские интерфейсы, которые могут быть переданы в разработку. Есть еще много ролей, кроме дизайнеров, которые заполняют это белое пятно: web-аналитики, маркетинг, редакция, UX исследователи, информационная архитектура, техническая поддержка, community management, контроль качества, — и это только некоторые из немногих. Одни из этих ролей сфокусированы на том, чтобы разработка лучше понимала клиентов, другие — на улучшение коммуникации по вопросам продукта с клиентами и привлечение новых клиентов.
Белое пятно B
Область B — белое пятно, существующее между клиентами, продуктом и бизнесом. Это та самая область, где ценность, которую продукт приносит своим пользователям конвертируется (надеюсь, что у вас это так) в выручку (или другие преимущества) для бизнеса. В значительно степени сложность этой области определяется тем, что:
- пользователи платят за продукт напрямую
- вы зарабатываете на рекламе
Пример 1. eCommerce или продукты, с подписочной моделью. В этом случае, задачи в рамках белого пятна состоят в том, чтобы эффективно использовать инвестиции компании в привлечение потенциальных пользователей (например, с помощью использования традиционной рекламы, SEO или продаж), извлекать из этого как можно больше доходов с каждого пользователя и направлять масштабирование и рост продукта на самые маржинальные рынки.
Пример 2. Привлечение через социальные сети и медиа компании. Этот случай сложнее, потому что нам необходимо разделять пользователей на две категории: а) предполагаемые пользователи продукта (например, человек, пользующийся Facebook или читающий New York Times и b) рекламодатели, которые платят, чтобы охватить этих пользователей. В этом случае основная задача области В — максимизировать ценность для рекламодателей с помощью нашего продукта, чтобы извлечь информацию о пользовательских предпочтениях, демографии, поведении и интересах. Мы также должны таргетировать и продавать продукт потенциальным рекламодателям и разрабатывать модели монетизации и ценообразования для оптимизации прибыли.
Наверное, можно рассмотреть еще третий случай — венчурные стартапы, которые в начале стремятся нарастить базу, а позже начать ее монетизировать. В этом сценарии все еще требуется человек, которые простроит недостающие связи в области B. Обязанности этого человека включают вовлечение инвесторов и удовлетворение их ожиданий, выращивание метрик “тщеславия” (уникальные пользователи, страницы просмотров), которые сигнализируют о возможности монетизации продукта в будущем.
Белое пятно С
Область С — белое пятно, существующее между бизнесом, продуктом и разработкой. Это область, где компания решает, на что будут сфокусированы инвестиции и усилия разработки. На верхнем уровне управления это влечет за собой формулирование и распространения внутри компании бизнес-видения, которое определяет направление проектов (иногда, эта задача находится в компетенции CEO). На нижнем уровне, это влечет за собой приоритезацию конкретных инженерных и рутинных задач, багов (иногда эта задача менеджера проекта). Все эти обсуждения также включают в себя сложные вопросы: “купить или построить самим”, — когда дело доходит до обсуждения конкретных технических решений. Область С — это область, где компания превращает идеи в реализацию.
На рисунке 3 приведены примеры ролей, которые могут заполнять каждое из белых пятен. Это ни в коем случае не исчерпывающий список — его задача быстро передать суть каждой из областей.
Итак, мы обсудили значения областей A,B, и C с точки зрения белых пятен между основополагающими элементами продуктовой среды. По мере взросления компании, это регионы заполняются связями, соединяющими элементы друг с другом. Дизайнер может быть нанят для того, чтобы сформировать связь между пользователями и разработкой, или руководитель по развитию бизнеса, чтобы простроить связь между пользователями и бизнесом.
По мере добавления новых ролей, элементы продуктовой среды простраиваются в различных направлениях. Области AB, BC и AC на рисунке 4 — те области, где различные, иногда кажущиеся несовместимым друг с другом, данные, объединяются, образуя каждый из продуктовых элементов среды. Я называю их областями синтеза.
Область синтеза AB
Область синтеза AB — место, где входные данные из белого пятна A должны соединиться с входными данными из белого пятна B, и сформировать целостную историю для пользователей. Люди, сфокусированные на создании ценного продукта для пользователей, должны понимать потребности бизнеса. Также как и люди, задачей которых является монетизация продукта, должны понимать пользовательский опыт и то, как он отражается в продукте. Я объяснял выше, что сложность белого пятна B определена тем:
- зарабатываете ли вы напрямую с пользоватлей
- зарабатываете через рекламу
Понимание того, какой из случаев ваш, сильно влияет на набор трудностей, с которыми вы столкнетесь в области синтеза AB. В первом случае трудности не высоки, потому что, как правило, та функциональность, за которую пользователи и любят ваш продукт, будет генерировать большую прибыль компании. Чем больше значимых для пользователей изменений вы будете привносить в ваш продукт, тем больше людей будут узнавать о них и платить за него. Во втором случае всегда будет существовать внутренний конфликт между созданием ценного продукта для пользователей и функциональности, которая позволит продвигать его через рекламные каналы и акции. Реклама может ухудшить пользовательский опыт, а связь продукта с постоянной рекламой может подорвать доверие пользователей. И наоборот, улучшение пользовательского опыта может привести к снижению количества показов рекламы и ухудшению ее рекламных показателей. Поэтому критически важно, чтобы в компании был человек, который бы синтезировал потребности бизнеса и пользователей, взвешивал все “за” и “против” и разрабатывал продуктовые решения отвечающие потребностям компании в целом.
Задача синтеза не ограничивается только обработкой входных данных из соседних белых пятен. Иногда различные входные данные могут находиться в пределах одной области, и необходимо выровнять их. Даже если мы проигнорируем противоречивость входных данных из области B, может существовать конфликт данных внутри области A. Например, два человека, каждый из которых отвечает за определение потребностей пользователей, могут расходиться во мнении о том, как создать удобный сценарий для пользователя. И здесь необходим кто-то, кто бы понимал потребности пользователя и приводил к общему знаменателю противоречивые мнения внутри области A.
Область синтеза BC
Область синтеза BC — место, в котором связи из области B сталкиваются со связями из области C и формируют единую бизнес-стратегию. Это та область, где бизнес инициативы отфильтровываются и превращаются в конкретные действия, на которые выделяются ресурсы, осуществляется приоритезация и интеграцию в vision. Люди, находящиеся в области B формируют гипотезы о том, как продукт может помогать развивать бизнес в целом. И здесь важно, чтобы кто-то обладал пониманием миссии, целей и возможностей компании. Поскольку новые бизнес-идеи в компаниях всегда бьют ключом, основная задача области синтеза BC — определять, какие из них соответствуют целям и задачам компании, а какие нет. Строгий фильтр, основанный на понимании рынка и ключевых компетенциях команды, позволит компании сфокусировать разработку на тех задачах, которые позволят добиться максимального успеха.
Область синтеза BC — место, где знания о рынке превращаются в код. Поскольку какие-то продуктовые гипотезы выстреливают, какие-то проваливаются, крайне важно, чтобы полученные знания постоянно транслировались в компанию. В то время как многие стартапы погибают по независящим от них причинам, стартапы с сильным менеджментом в области синтеза BC могут со временем улучшить свою способность выбирать успешные продуктовые идеи.
Область синтеза AC
Область синтеза AC — место, в котором связи из белого пятна A должны встретиться со связями из области C, и сформировать четкий, выполнимый план разработки. Входные данные из области A дают понять, как продукт должен себя вести в идеальном сценарии, чтобы приносить ценность пользователям. Входные данные из области C дают понимание, что из этого является достижимым в условиях доступных нам ресурсов и конкурирующих бизнес-приоритетов. Когда эти две силы сталкиваются в области синтеза AC, часто требуется идти на компромиссы. Зачастую идеальное решение оказывается слишком дорогим или требующим большого количества времени для его реализации. Но область синтеза AC не про разрушение мечтаний дизайнеров-идеалистов — она о разработке решений, отвечающих потребностям пользователей наилучшим образом, в рамках заданных бизнес-параметров.
Область синтеза AC — это место, где появилось понятие минимального жизнеспособного продукта (MVP). Идея MVP заключается в том, чтобы приложить минимальные усилия с точки зрения разработки, которые были бы достаточными, чтобы подтвердить или опровергнуть нашу гипотезу при взаимодействии пользователя с получившимся функционалам продукта. Способность компании эффективно создавать MVP определяет их способность быстро двигаться от итерации к итерации, учиться, и, в конечном итоге, находить успешные решения. Определение фич, которые должны быть включены в MVP, — это искусство. Оно требует понимания, что действительно важно для пользователей и как продукт может развиваться в будущем.
Зоны ответственности Менеджера Продукта
Теперь, когда мы рассмотрели продуктовую среду и отдельные ее области, у нас есть необходимый контекст для описания того, как управление продуктом вписывается в этот паззл. В первую очередь следует отметить, кем не является менеджер продукта. Не смотря на то, что некоторые менеджеры продукта часто надевают шляпу разработчика, сама роль менеджера продукта не предполагает касания самого кода продукта. Обновление кода — это задача разработчиков. Тот факт, что человек, несущий наибольшую ответственности за продукт (менеджер продукта) не отвечает за разработку, является характерной особенностью продуктового менеджмента.
Так что же делает менеджер продукта? Теперь у нас достаточно почвы под ногами, чтобы этот загадочный ответ обрел конкретное значение:
Менеджер продукта отвечает за здоровое взаимодействие и функционирование всех областей среды продукта.
Эта ответственность может быть разделена на две большие категории, которые относятся или непосредственно к белому пятну, либо к области синтеза, про которые мы говорили:
- Менеджер продукта должен определять и наполнять связями белые пятна между элементами продуктовой среды. То есть фактически управлять областями A, B, C. Если какая-то из связей пропущена, менеджер продукта либо сам формирует эту связь, либо находит способ ее восстановить. С этой точки зрения, менеджер продукта должен хотя бы на базовом уровне самостоятельно формировать связи вокруг элементов продукта, т.е. обладать широким спектром знаний, начиная от web-аналитики, заканчивая сопровождением клиентов и проектным управлением.
- Менеджер продукта должен синтезировать различные входные данные, влияющие на каждый элемент продуктовой среды, т.е. управлять областями синтеза AB, BC, AC. Менеджер продукта должен обладать необходимым бизнес-контекстом для каждого элемента: разработчикам нужно четкое понимание задач, пользователям нужны понятные сценарии использования продукта, бизнесу нужно четкое понимание ценности продукта для рынка. Синтезируя входные данные из различных областей, менеджер продукта создает и доносит до всех сотрудников компании эти сценарии и истории.
Эти две функции — по сути Инь и Ян продуктового менеджмента. Заполнение белых пятен наполняет систему: простраивая недостающие связи между элементам продуктовой среды, менеджер продукта добавляет системе недостающей ее сложности. Задача же в области синтеза — убирать лишнее. Менеджер продукта должен понимать все запутанные входные данные в продуктовой среде и оставлять от них только те, которые станут ключевыми и будут удовлетворять требованиям пользователей, бизнеса и разработки одновременно.
Я уверен, что приведенное выше определение менеджера продукта, будет верно всегда, независимо от компании и сценариев в продукте. Если вы не выполняете эти две функции, вы не являетесь менеджером продукта. Тем не менее, определение носит довольно общий характер. В рамках этих двух категорий находится огромное количество активностей, которые могут оказываться в зоне ответственности менеджера продукта в зависимости от ситуации. Как я и обещал в начале статьи, я постараюсь создать мостик между общими и конкретным обязанностями менеджера продукта. В оставшейся части статьи мы рассмотрим, как сценарии компании преобразуются в конкретный перечень обязанностей менеджера продукта, которые соотносятся с двумя категориями выше.
Примеры сценариев Менеджера Продукта
Когда мы вводили понятие продуктовой среды, я говорил, что разработчики — это единственная необходимая роль для создания IT продуктов. Кто-то должен поставлять код. Затем, в ходе обсуждения белых пятен, я объяснял, что в компании должно существовать множество ролей, необходимых для простраивания связей в белых пятнах областей A, B и C продуктовой среды. И когда стартап получает инвестиции, он начинает заполнять эти роли, не связанные с разработкой. Если бизнес продолжает расти, организация тоже растет и появляются все больше и больше специализированных позиций. Тем не менее, существует большое количество способов заполнения ролей, не связанных с разработкой, внутри компаний. Некоторые могут сразу добавить в среду менеджера продукта. Другие начинают с добавления компетенций по дизайну или продажам, прежде чем первый менеджер продукта будет нанят. Порядок, в котором компания добавляет роли зависит от бизнес-домена и набора скиллов текущей команды.
B2C стартапы часто начинают с выделения на ранней стадии роли дизайнера (простраивая связи в области A), так как создание сильного визуального впечатления в первые мгновения критически важно для привлечения пользователей, у которых есть всего несколько секунд для формирования решения о вашем продукте. В противовес этому — B2B стартапы, скорее всего, будут вводит роли business development (простраивая связи в области B). В этом случае валидация продуктовых гипотез больше зависит от подтверждения того, что сервис может быть продан организации с тем набором функциональности, который в нем есть сейчас. Сильный визуальный дизайн, не смотря на то, что он важен, может быть не так критичен на ранней стадии.
Следует также отметить, что на ранних этапах жизни стартапа, разработчики, помимо написания кода, могут играть роли, не связанные с разработкой. Часто можно увидеть разработчика, выполняющего роль дизайнера, менеджера проекта или CEO. Возможности эффективного выполнения ролей, не связанных с разработкой, командой разработки очень сильно зависят от того, в какой из областей требуется сейчас фокусировка усилий. Например, некоторые компании стали бы нанимать отдельного дизайнера, хотя необходимость в этом может быть существенно ниже, если в команде разработки есть минимальная экспертиза в этой области.
Следующие примеры, которые мы рассмотрим, отличаются ролями, не связанными с разработкой, которые формируют связи в областях продуктовой среды. Не смотря на огромное количество факторов, влияющих на конкретные задачи менеджера продукта, структура команды, работающей над продуктом, оказывает наибольшее влияние на его ежедневные задачи.
Пример 1. Разработчики + Дизайнер + Менеджер продукта
Давайте начнем со сценария, в котором компания нанимает дизайнера, заполняя первую роль, не связанную с разработкой. Я обозначу эту роль в виде желтой полосы с надписью “Дизайнер” в белом пятне области A, изображенной на рисунке 8. Это распространенный кейс, так как часто первую связь, которую компании хотят улучшить — это та, которая соединяет пользователей и разработку. Прежде чем фокусироваться на монетизации, многие компании стараются сформировать ценностное предложение для пользователя. Как я уже упоминал, особенно для B2C стартапов, продукт не найдет свое место на рынке, если он не будет ясным, понятным и бросаться в глаза новым пользователям, у которых есть только несколько секунд, чтобы составить общее впечатление о вашем продукте.
Затем, компания нанимает менеджера продукта, заполняя вторую роль, не связанную с разработкой. Что должен делать менеджер продукта в этом сценарии? Напомним две основные верхнеуровневые задачи менеджера продукта
- Определять и простраивать недостающие связи в белых пятнах областей продуктовой среды.
- Синтезировать различные входные данные, которые пересекаются в областях синтеза треугольника управления продуктом.
Для этого и других примеров, я расскажу, что это означает для областей A, B, C и областей синтеза AB, BC, AC.
Зоны ответственности управления продуктом
Определяйте и заполняйте важные белые пятна в областях между элементами продуктовой среды.
A
С одной стороны наличие выделенного дизайнера в компании снимает нагрузку с менеджера продукта. С другой стороны — наличие выделенного человека, ответственного за дизайн, не достаточное условие для появления здоровых отношений между разработчиками, продуктом и клиентами. Чтобы дизайн-процесс давал результат, он должен поддерживаться другими ролями, такими как Исследователи поведения пользователей и web-аналитика. Менеджер продукта должен сам определить кем заполнить и как простроить эти связи: собой или кем-то еще. Также набор навыков дизайнера может не покрывать полный стек навыков и технологий, который требуется вам сейчас. Например, менеджер продукта может выполнять роль информационного архитектора, предоставляющего дизайнеру данные для последующей визуализации. Также в области А есть белые пятна, требующие простроения, находящиеся за рамками определения традиционного дизайн-процесса. Например, менеджер продукта может видеть необходимость в улучшении SEO, технической поддержки или работы с сообществом.
B
Если модель компании требует быстрого роста выручки на старте, область B может потребовать менеджера продукта сфокусироваться на сценариях, лежащих внутри нее. Если в этой области нет выделенных сотрудников, менеджер продукта должен сам определить и простроить связи между элементами. Именно наличие в области B критических, непонятных белых пятен заставляет многие компании искать управленцев со степенью MBA. Менеджер продукта будет отвечать за оценку потенциального рынка, прогнозов и выстраиванию бизнес-модели. Но многие стартапы на ранних фазах не сконцентрированы на монетизации — они сфокусированы на подтверждении потребности пользователей и наращиванию клиентской базы. Тем не менее, это не значит, что менеджер продукта может игнорировать область B. Не зависимо от того, сфокусирована ли компания сейчас на монетизацию или нет, инвесторы должны понимать траекторию движения компании. Для этого менеджер продукта должен простроить связь между пользователями, продуктом и бизнесом. А для этого необходимо понимать, как метрики, показывающие вовлеченность пользователей, влияют на бизнес ценность. В терминологии подхода бережливого производства это означает, что цифры должны отражать эффективность используемой стратегии роста и показывать динамику роста. Или, если продуктовая гипотеза не подтвердилась, помогать обосновывать менеджеру продукта переход к новой концепции продукта.
C
В этом, и во многих других сценариях, область С является важной и сложной зоной ответственности менеджера продукта. Он играет здесь критически важную роль — фокусируя команду разработки на задачи и проекты, которые максимально эффективно будут продвигать бизнес вперед. Менеджеру продукта придется здесь поработать в роли менеджера проекта. Здесь требуется координировать и конкретизировать каждую инженерную задачу. И хотя продакт менеджер здесь решает конкретную тактическую задачу, затрагивающую малое изменение в продукте, он также должен простраивать связь между текущими задачами инженерной команды и четким видением продукта, фокусирующим и вдохновляющим команду. Менеджер продукта также должен создавать промежуточный слой: продуктовый роадмап. И инвесторам, и разработчикам необходимо иметь долгосрочное представление о том, какие проекты будут следующими в разработке, даже если роадмап будет изменен.
Синтез входных данных, влияющих на элементы продуктовой среды
AB
Присутствие в команде выделенного дизайнера увеличивает потребность в синтезе входных данных в области АВ. C дизайнером у компании появляется сильный голос внутри, отстаивающий интересы пользователей. Конечно, в этом есть много позитивных моментов, но зачастую этот голос требует противовеса. Огромное количество изменений продукта могут быть инициированы дизайнерами, но по факту они не приведут к значительному продвижению бизнеса вперед. Например, дизайнер может захотеть изменить интерфейс пользовательского поиска, но менеджер продукта может принять решение о том, что недостатки в текущей реализации поиска, не препятствуют нужному темпу роста бизнеса. В области синтеза АВ задача менеджера продукта — фокусировать дизайнера на улучшение продукта в тех направлениях, которые принесут максимальный бизнес результат. И да, иногда энергия дизайнеров должна быть потрачена на вещи, которые будут ухудшать пользовательский опыт. Например, пользователям не понравится добавление рекламы или платного доступа, но они необходимы с точки зрения бизнеса. Менеджер продукта может также выполнять роль SEO. Например, дизайнер как адвокат пользователей может исключить оптимизированные для SEO тексты со страницы. Разрешение этого конфликта требует взвешивания всех за и против и понимания важности привлечения новой аудитории через поисковые системы в противовес упрощения пользовательского опыта для существующих пользователей. Фокусировка бизнеса на балансе между ростом и удержанием текущей базы пользователей будет оказывать влияние на результат. Хочется верить, что общение между членами команды по этим вопросам не превращается в состязание. Одна из зон ответственности этой области — передавать дизайнерам бизнес-контекст компании и понимание направления развития. Гибкий и прагматичный дизайнер будет работать вместе с менеджером продукта для разрешения этих конфликтов бизнеса и опыта пользователей.
BC
Задача синтеза в менеджменте продукта требует хороших дипломатических и коммуникативных навыков. Требуется привести к единому решению команду, члены которой по-разному смотрят на продукт. Но именно в этом сценарии, задача синтеза — ментальная задача самого менеджера продукта. Так как в областях B и C нет выделенных ролей и нет отдельных людей под них, то и задачи выравнивать их понимание и видение нет. Не смотря на это, все еще могут существовать конфликты, которые менеджер продукта должен разрешать самостоятельно. Если бизнес страдает от нехватки денег, решить, какая из следующих бизнес идей должна быть реализована становится очень тяжело. Принятие решения о том, на что делать ставку в следующий раз, может привести менеджера продукта к бессоннице. Постоянный выбор неуспешных идей в этой ситуации может привести компанию к краху. В этом случае менеджеру продукта важно следовать выбранному направлению бизнеса и выделять ресурсы только на те проекты, которые соответствуют этому направлению.
AC
Вместе с выделенной ролью дизайнера задача менеджера продукта в области АС состит в том, чтобы
а) фокусировать энергию дизайнеров на проектах, которые приведут к реализации кода, оказывающего максимальный результат на бизнес
б) балансировать задачи, имеющие ценность для пользователя, с другими инженерными задачами по разработке
Оптимизация ценности энергии дизайнеров включает в себя управление входными и выходными данными из дизайн-процесса. Менеджер продукта должен определять какие из следующих проектов роадмапа продукта требуют внимания дизайнеров. Для таких проектов, менеджер продукта должен задать параметры для разработки дизайна и давать обратную связь, основываясь на собственном понимании пользовательского опыта, бизнес целей, и текущего состояния продукта (что влияет на количество усилий, приложенных для внедрения). Тем не менее, здесь важно не слишком ограничивать процесс проектирования. У дизайнера могут появляться идеи, которые не приходят в голову менеджеру продукта. Дизайнерам нужна свобода, чтобы создавать новые креативные идеи.
Так как результатом работы дизайнеров являются прототипы интерфейса продукта, они неизбежно будут на шаг впереди задач, над которыми работает команда разработки. Не стоит, конечно, создавать водопадный процесс, когда команда разработки неделями реализует дизайн, который до этого недели создавали дизайнеры. Более здоровый процесс: продакт менеджер определяет критически важные элементы дизайна, которые потом будут реализованы итерационно-инкерементально. Задача менеджера продукта — получить максимальное количество развивающей обратной связи от пользователей. Это позволит быстро обнаруживать проблемы в дизайне и определять фичи, с низким уровнем ценности, которые не стоит отдавать в разработку. Менеджер продукта также определяет, насколько фокус команды нацелен сейчас именно на работу над новыми фичами для пользователей. На этапе исследования, может быть целесообразно быстро спрототипировать несколько вариантов дизайна, чтобы подтвердить или опровергнуть продуктовые гипотезы, что приведет к появлению значительного количества технического долга. Тем не менее, по мере взросления продукта, фокус продуктовой команды может смещаться от реализации новых дизайн-решений в сторону решения проблем производительности, безопасности, поддержки кросс-браузерности, рефакторингу и документации.
Пример 2. Разработчики + Дизайнер + Business Development + Менеджер продукта
В отличие от примера 1, в примере 2 появляется отдельная роль Развития Бизнеса. В этом примере, некоторые из внутренних конфликтов, которые менеджер продукта может испытывать, балансируя между потребностями пользователя и бизнеса, становятся конфликтами области синтеза AB. Теперь у нас есть два сильных голоса: дизайнер, выступающий адвокатом пользователей, и руководитель Развития Бизнеса, который преследует свою цель — получить максимальный объем денег с пользователей. Как уже обсуждали ранее, иногда эти две точки зрения легко уживаются вместе, иногда нет. Управление взаимоотношениями между дизайнерами и руководителем Развития Бизнеса будет в центре внимания менеджера продукта. Сама область синтеза AB будет горячей точкой продуктовой среды.
Напряжение в области синтеза AB во многом зависит от влияния сил с противоположных сторон треугольника. Очевидно, что область С тоже будет горячим местом. Правильное бизнес-видение создаст синергию между пользователями и ценностью для бизнеса. Менеджер продукта должен отфильтровать бизнес идеи руководителя Развития Бизнеса (в области BC), чтобы поддержать единый бизнес нарратив, который выровняет бизнес цели и потребности клиента вокруг общих целей компании. Вот почему маркетплейсы, например, имеют такой потенциал. С ростом числа участников в нем, ценность для пользователя и выручка возрастают. Такой сетевой эффект и формирует IT продукты. Менеджер продукта должен постоянно охотиться за этой магической формулой, которая помогает дизайнеру и руководителю по развитию бизнеса держаться вместе, а не сражаться друг с другом.
Пример 3: Разработчики + Дизайнер + Business Development + Business Vision + Менеджер продукта
В примере 3 включается еще одна неразработческая роль — человек, который отвечает за business vision. Как правило эту роль выполняет CEO. Визионирующий CEO будет главным человеком, который транслирует миссию и стратегию компании командам разработки. Тем не менее, это не освобождает менеджера продукта от его задач в области С. А в некотором смысле, даже усложняет их. Менеджер продукта должен интегрировать vision CEO в продуктовый роадмап, который будет ориентирован на ключевую метрику бизнеса. Если какой-то из элементов vision-a в процессе валидации с точки зрения ценности для пользователя или бизнеса, не подтвердился, менеджер продукта должен управлять ожиданиями CEO и помочь скорректировать vision, в соответствии с полученной обратной связи. Такого рода заполнение белых пятен можно рассматривать как управление.
Теперь, когда у нас есть три неразработческие роли, которые простраивают связи продуктовой среды (дизайнер, biz dev и business vision), мы видим, что общий фокус задач менеджера продукта больше смещается в сторону синтеза, чем непосредственного простраивания связей в белых пятнах. Успешный менеджер продукта в этом сценарии должен обладать хорошими дипломатическими навыками, уметь доносить свою точку зрения и способствовать коллективному решению проблем.
Пример #4: Выстроенная продуктовая организация
Пример 4 рассматривает выстроенную продуктовую организацию. Сейчас мы уходим от фазы раннего стартапа и перемещаемся на уровень зрелых стартапов и больших корпораций. Компания в этом сценарии нанимает сотрудников для заполнения нескольких связей в областях A, B, C. Представьте организацию с дизайнерами, исследователями пользователей, поддержкой, community менеджерами, SEO специалистами, продажами, специалистами по стратегическим партнерствам, специалистами по рекламе, управлению проектами, финансами и менеджментом C-уровня. В этой среде задачи менеджера продукта больше ориентированы на синтез, а не на простраивание связей в слепых областях. Самый большой вызов для менеджера продукта здесь связан с большим количеством данных, влияющих на дальнейшее развитие продукта. Каждая из ролей в продуктовой компании двигает продукт в своем направлении. И это задача менеджера продукта — понять весь спектр возможностей и повернуть в единое направление каждый из элементов продуктовой среды: разработчиков, пользователей и бизнес.
В этом сценарии потенциал возникновения конфликтов очень высок. В любой области может возникнуть конфликт (например, в области А он может возникнуть между дизайнерами и SEO). Но когда сталкиваются несколько соседних областей, возникают целые политические войны. Чтобы продукт развивался, менеджер продукта должен играть на опережение: в зародыше определять эти конфликты и устранять их раньше, чем они начнутся. Это требует от менеджера продукта реакции на возникающие изменения и проактивной коммуникации всем участникам продуктовой среды направления развития продукта, в котором синтезированы все точки зрения, и отфильтрованы те, которые не соответствуют этому направлению.
Момент сознательного отказа от точки зрения одного из членов команды является одним из самых сложных аспектов межличностных отношений, с которыми сталкивается менеджер продукта. И если у него есть команда, то четкое объяснение: “Почему?” — имеет очень важное значение. Уважение к менеджеру продукта пропадает, когда его решения кажутся беспринципными и необоснованными. Когда же всем будут понятны принципы выбора продуктовых инициатив, даже люди, чьи идеи были отвергнуты, почувствуют уверенность в том, что продукт находится в надежных руках.
Применение треугольника управления продуктом
В приведенных выше примерах я постарался проиллюстрировать как визуальный словарь треугольника управления продуктом может стать полезным инструментом в описании паттернов менеджера продукта. Не смотря на то, что общие зоны ответственности менеджера продукта фиксированы (простраивание связей в белых пятнах и синтез), конкретные обязанности менеджера продукта зависят от каждой компании и того, как она формирует работу с продуктом.
Рассматривая треугольник управления продуктом мы можем сделать обсуждения об обязанностях менеджера продукта более предметными. Мы можем его использовать конкретных вопросов, например, почему люди, которые каждый день выполняют абсолютно разные задачи, называются общим термином “менеджер продукта”. Его также можно использовать, чтобы понять, почему хорошие менеджеры продукта преуспевают в каких-то конкретных (зачастую разных) направлениях. С одной стороны, успешные менеджеры продукта в стартапах должны быть ориентированы на развитие продукта в условиях, когда их деятельность определяется потребностью заполнения белых пятен. С другой стороны, отличные менеджеры продукта в крупных организациях могут быть менее подготовленными к простраиванию связей в белых пятнах, но быть великолепными в синтезе данных и объединении политической структуры. Каждый менеджер продукта должен понимать свою роль в организации, согласно треугольнику и связям, которые объединяют элементы продуктовой среды. Проделав это упражнение, менеджер продукта может понять, на что ему стоит сосредоточить свои усилия — простраивание белых пятен областей A, B, C или синтез областей AB, BC, AC.
Можно включать треугольник управления продуктом в описание вакансий для менеджеров продукта, для более точного описания роли и понимания задач, для решения которых компания ищет сотрудника. В этом случае, менеджеры продукта с MBA могли бы точно понимать, когда компания ищет человека, для выстраивания связей между пользователями, продуктом и бизнесом. А менеджеры продукта, более ориентированные на пользовательский опыт, смогли бы выбрать опции, которые предполагают простраивание связей между пользователями и разработчиками.
Треугольник управления продуктом может быть также использован и самими менеджерами продукта, чтобы лучше описывать свою роль, а также лучше понимать свои сильные и слабые стороны. Например, простроив треугольник для своей компании, как я это сделал в примере 1, менеджер продукта может осознать, что требует внимания какая-то конкретная область. Например, дизайн сталкивается с продажами (область AB), и это та область, где стоит больше внимания уделить синтезу. Или менеджеры продукта могут использовать треугольник для того, чтобы определить свои слабые места. Например, может им стоит пересмотреть свои подходы у правлению разработкой, чтобы повысить уровень здоровья и гибкости в области C.
В заключении, я надеюсь, что это эссе послужит стартовой площадкой для многих конкретных обсуждений в области управления продуктом. В будущем, я бы хотел написать “how to” для каждой из областей треугольника.
