Недавно я написал статью об антипаттернах Product Ops, но читатели указали мне на то, что в этой статье я упустил главную мысль, и что ее самая важная часть лежит далеко за пределами второстепенной темы Product Ops.
Поэтому в этой статье я хотел бы сосредоточиться на более фундаментальной теме, которая касается самой природы продукта и основы того, что значит быть сильной продуктовой командой.
Сильная продуктовая команда существует для того, чтобы решать важные проблемы клиентов или компании, способами, которые нравятся пользователям и клиентам, с помощью технологий, которые сейчас стали возможными, и способами, которые работают на бизнес.
Обратите внимание, что это совсем другая цель, чем у feature-команды или delivery-команды, поэтому данная статья посвящена именно продуктовым командам с расширенными возможностями.
Продуктовая команда заинтересована в том, чтобы предлагать эффективные решения. А чтобы повысить шансы на успех, нужно иметь свободный доступ к трем группам заинтересованных лиц:
1. Прямой доступ к пользователям и клиентам
Это должно быть очевидно, что без прямого и свободного доступа к реальным пользователям и клиентам у команды разработки мало шансов на успех в решении вопросов ценности и удобства использования продукта.
Пользователи и клиенты не только вдохновляют на поиск нерешенных проблем, но и дают возможность быстро протестировать предлагаемые решения. Немного менее очевидной является необходимость прямого доступа к данным об этих пользователях, например, о том, как они взаимодействуют с продуктом, и об отзывах, которые эти люди оставляют об опыте использования продукта.
Интуитивно должно быть понятно, почему прямой доступ к пользователям необходим менеджеру продукта и дизайнеру продукта, но важность предоставления такого доступа инженерам менее очевидна.
Вам не нужно, чтобы все инженеры сопровождали каждого пользователя, но когда инженер наблюдает за неудачными попытками взаимодействия пользователя с продуктом, происходит «магия», поэтому будет полезно поощрять такую инициативу.
Главное здесь — не позволять никому пытаться помешать вам получить прямой доступ к клиентам — ни специалистам по продажам или маркетингу, ни специалистам по работе с клиентами, ни UX-исследователям, ни Agile-коучам, ни менеджерам — никому.
2. Прямой доступ к стейкхолдерам
Решение проблемы жизнеспособности продукта связано с решением различных бизнес-ограничений: маркетинг, продажи, саппорт, финансы, закон, контроль соблюдения требований, производство, эксперты предметной области и многое другое. Очень важно, чтобы по крайней мере менеджер продукта имел прямой доступ к лидерам бизнеса, которые отвечают за эти ограничения.
Менеджер продукта должен установить отношения с этими людьми, потратить время и усилия на изучение проблем и потребностей стейкхолдеров. Стейкхолдеры должны поверить, что менеджер продукта понимает ограничения и будет учитывать их в любом предлагаемом решении. В случае если вопрос находится в серой зоне, когда менеджер продукта не уверен, является ли что-то жизнеспособным или нет, он обсуждает это со стейкхолдером.
Такое доверие между продуктовой командой и стейкхолдерами имеет решающее значение для здорового сотрудничества, необходимого для поиска эффективных решений, которые удовлетворят и клиентов, и бизнес. Именно поэтому продуктовые команды должны понимать, когда и как периодически брать на себя высоконадежные обязательства.
3. Прямой доступ к инженерам
Наконец, менеджеру и дизайнеру продукта необходимо обеспечить постоянный доступ к инженерам. Для кого-то это совершенно очевидно.
Но для других это часто не так. Например, в ситуациях, где инженеры являются аутсорсерами; или где инженеры находятся в разных часовых поясах, что влияет на взаимодействие, или где считается, что инженеров нужно ото всех спрятать, чтобы их не прерывали во время написания кода; или где продуктовая команда разделена так, что менеджер продукта взаимодействует с клиентами и стейкхолдерами, а кто-то еще, например, владелец продукта или менеджер проекта, взаимодействует с инженерами.
Поймите, что инженеры ежедневно работают с технологиями, поэтому они находятся в идеальном положении, чтобы понять, что именно сейчас возможно. Но осознайте, что это становится возможным тогда, когда инженеры ежедневно взаимодействуют с менеджером и дизайнером продукта.
Вдохновение для инноваций
Все это означает, что необходимо защищать потребность прямого доступа продуктовой команды к этим трем составляющим и бороться с попытками поместить дополнительное звено в виде человека или громоздкий процесс между продуктовой командой и этими людьми.
Именно прямой, постоянный доступ к этим трем составляющим позволяет продуктовой команде находить инновационные решения и принимать правильные решения.
Я все чаще подчеркиваю важность «выбора битв, в которых стоит принимать участие».
Если мне нужно было бы выбрать единственную вещь, которая увеличивает шансы на успех, то это был бы постоянный доступ к этим трем группам. Поэтому я искренне надеюсь, что вы об этом задумаетесь.
По моему мнению, продуктовая команда, которой не дают доступа ни к одной из этих трех аудиторий, с большой долей вероятности может потерпеть неудачу. Поэтому исправление этой ситуации — это битва, которую стоит вести. Если ваша компания не понимает, почему это так важно, и вы исчерпали все силы, чтобы донести эту идею, но все равно хотите заниматься продуктом в сильной продуктовой компании, — вам, возможно, стоит начать рассматривать компании, где у вас будет больше шансов на успех. Настолько это важно.
Приглашаем всех желающих на открытое занятие «MVP и другие типы прототипов, HADI циклы». На вебинаре рассмотрим:
в каких ситуациях какие прототипы актуальны,
от MVP к MLP и далее,
HADI циклы.
Записаться на занятие можно на странице онлайн-курса "Senior Product Manager".
