будет работать.
И вот это и требует реального сотрудничества.
Не забывайте, что наша роль в продуктовом бизнесе состоит в решении проблем, которые нас просят решить, теми способами, которые одновременно нравятся нашим клиентам и работают на благо нашего бизнеса. В этом и заключается наша работа как кросс-функциональной команды, наделенной расширенными полномочиями, где каждый участник привносит в общее дело свой вклад с помощью необходимых навыков.
И начинается это с подлинного и тесного сотрудничества между продуктовым менеджментом, дизайнерами по продукту и инжиниринговой группой.
Я предпочитаю такой способ взаимодействия: члены команды собираются вместе, имея на руках прототип (как правило, созданный дизайнером), чтобы сообща рассмотреть и обсудить предложенное решение. Дизайнеры могут обдумывать разные подходы к пользовательскому опыту, инженеры — рассматривать последствия, связанные с разными подходами, и потенциальные возможности прорывных технологий, а менеджеры по продукту — взвешивать эффекты и последствия каждого потенциального направления (например, не будет ли нарушен принцип конфиденциальности, подойдет ли это для реализации по нашему каналу продаж).
Обратите внимание, что на этапе продуктового исследования некоторые инструменты и методы служат как для облегчения совместной работы, так и для создания артефакта в качестве промежуточного результата этого сотрудничества. Два весьма популярных примера — создание прототипа и карты пользовательских историй.
Сам процесс создания и обсуждения прототипов и карт пользовательских историй способствует взаимодействию на основе сотрудничества. Если вы стараетесь актуализировать ваши прототип или карту пользовательских историй, они могут также служить артефактом, который отражает данные, полученные в результате продуктового исследования, и решения, принятые на его основе.
Реальная польза и сама цель использования инструментов в данном случае — укрепление сотрудничества. А получение артефакта в финале можно рассматривать как приятный бонус.
На самом деле главное здесь — не прототип, а само сотрудничество, развитию которого способствует создание прототипа.
Заметьте, что менеджер по продукту и инженеры не пытаются диктовать дизайнеру, как делать свою работу. Также менеджер по продукту и дизайнеры не указывают инженерам, как им делать свою. А дизайнеры и инженеры не указывают менеджеру по продукту, как работать должен он.
Напротив, в здоровой и компетентной команде каждый ее участник рассчитывает, что другие выполнили «домашнее задание» и использовали свои навыки в качестве вклада в общее дело.
Впрочем, не стоит превратно истолковывать все вышеизложенное и полагать, что дизайнеры отвечают исключительно за удобство в использовании, а инженеры — только за осуществимость, поскольку в этом случае вы упускаете истинный смысл сотрудничества.
Часто у дизайнеров бывают озарения, основанные на глубоком понимании потребностей пользователей и их потребительского поведения, которые указывают другой путь решения стоящей перед нами проблемы или меняют сам подход к проблеме. Такие озарения порой оказывают прямое влияние на ценность продукта и косвенное — на такие вещи, как производительность.
Аналогичным образом сильные инженеры обладают глубоким пониманием прорывных технологий, что порой открывает перед нами возможность совершенно другого решения поставленных проблем — и часто гораздо более эффективного, чем могли представить менеджер по продукту, дизайнер и особенно клиент. Если бы мне пришлось выбирать, что мне больше всего нравится в ощущении истинного сотрудничества в продуктовой команде, наделенной широкими полномочиями, я бы выбрал ту магию, которая происходит, когда ваши сотрудники: а) мотивированны и б) грамотны и опытны в своей области — продуктовом менеджменте, дизайне и инжиниринге, — а также способны совместно обсуждать прототип или наблюдать за взаимодействием с ним пользователя. Инженер показывает новые возможности, дизайнер — разные варианты потенциальных пользовательских впечатлений, а менеджер по продукту взвешивает возможные последствия, связанные с продажей, или финансами, или условиями конфиденциальности. И после изучения целого ряда подходов они создают вариант, который действительно работает. Он получается ценным, удобным в использовании, осуществимым и жизнеспособным.
Исходя из опыта, могу отметить, что есть две ситуации, когда чаще всего это не срабатывает.
Первая связана с тем, что менеджер по продукту не выполнил свою «домашнюю работу» и не имеет понятия о разных аспектах и ограничениях бизнеса, таких как продажи, маркетинг, финансы, правовые нормы, конфиденциальность и т. п. Поэтому у продуктовой команды нет информации, необходимой для решения порученных ей проблем (что обычно означает возврат к внедрению функций, прописанных в дорожной карте).
Вот почему ранее в этой части, посвященной коучингу, шла речь о том, что ваша первоочередная задача как руководителя — оценить знания и навыки менеджера по продукту и составить план, который позволит довести его компетентность до надлежащего уровня.
Вторая ситуация связана с самонадеянностью. Если менеджер по продукту убежден, что решение, которое уже сложилось в его голове, является оптимальным, и даже если он прав — это будет сдерживающим фактором для сотрудничества. В результате он, скорее всего, получит команду из наемников, а не из миссионеров.
Еще одной важной формой сотрудничества, особенно в компаниях, где существует отдел прямых продаж, является взаимодействие с потенциальными клиентами — чтобы определять, сможет ли ваш продукт удовлетворить их потребности.
Вполне естественно, что потенциальные клиенты склонны диктовать свои требования насчет функций продукта, а ваша задача — постараться понять их основные проблемы и ограничения и затем совместно с ними выработать общее решение, которое отвечает их потребностям. Эта форма сотрудничества лежит в основе методики «программа поиска клиентов»[15].
Сотрудничество означает совместную работу менеджеров по продукту, дизайнеров и инженеров с клиентами, стейкхолдерами и топ-менеджментом, с тем чтобы выработать решение, которое учитывает все ограничения и риски. Именно об этом идет речь, когда мы говорим о решениях, которые нравятся нашим клиентам и при этом выгодны для бизнеса.
Умение выстраивать истинные отношения сотрудничества — основа работы сильных продуктовых команд. Это — сочетание необходимых навыков и особого склада мышления. Для развития такого умения со стороны руководителя часто требуется организация активного коучинга для новых специалистов по продукту.
Глава 17. Сотрудничество со стейкхолдерами
Члены функциональных команд с опаской относятся к теме взаимодействия со стейкхолдерами, в особенности это касается менеджеров по продукту и продуктовых дизайнеров. Они считают, что если стейкхолдеры не диктуют условия, то точно мешают работе, создают препятствия, которые приходится преодолевать.
Это еще один явный пример различия между функциональными и продуктовыми командами, наделенными широкими полномочиями. В компаниях, использующих первую модель, функции, которыми занимаются команды, исходят от стейкхолдеров, так что именно они считают себя клиентом, а продуктовые команды рассматриваются как наемный IT-персонал.
По сути, это просто еще один способ сказать, что задача функциональной команды — обслуживать бизнес.
А вот задача продуктовой команды, наделенной широкими полномочиями, — обслуживать клиентов теми способами, которые им нравятся и при этом работают на благо бизнеса.
Таким образом, хотя в продуктовой команде
