Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта

Scaled Agile Framework (SAFe) (масштабированный гибкий фреймворк) учит этому по-другому, и я думаю, что это одно из самых слабых мест во всей системе. В SAFe менеджеры по продукту являются руководителями владельцев продукта и отвечают за взаимодействие и работу с внешним миром. Они разговаривают с клиентами, определяют требования и объем создаваемых продуктов и передают их владельцам продуктов. Владельцы продуктов работают внутри компании, определяя компоненты решения и работая с разработчиками над его внедрением.

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

Я выслушала массу аргументов в пользу того, что у владельцев продукта нет времени на выполнение обеих ролей. В нынешних условиях это действительно так. Владельцы продуктов, с которыми я общаюсь, тратят 40 часов в неделю на написание тонны пользовательских историй. В этот момент вам нужно спросить, а ценны ли вообще эти истории? Чему они отдают предпочтение? Откуда они знают, что они решат проблему? Если у вас один человек тратит столько времени на написание пользовательских историй каждую неделю, вы наверняка попали в ловушку.

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

Я учу своих клиентов, что менеджеры по продукту, находящиеся на руководящих должностях (вице-президенты, руководители или менеджеры среднего звена), концентрируются на определении концепций и стратегии для команд, основываясь на исследованиях рынка, понимании целей, а также изучении текущего состояния успеха продуктов. Менеджеры без Scrum-команд или с небольшими командами (например, UX-дизайнер и один разработчик) помогают утвердить и внести свой вклад в эту стратегию для будущих продуктов. После утверждения направления мы создаем вокруг этих людей более крупные Scrum-команды и выстраиваем решения.

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

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

Глава 8

Карьерный путь менеджера по продукту

Когда организации маленькие, их команды тоже маленькие, а это значит, что сотрудники делают буквально все. Они выполняют множество функций – и им приходится это делать, чтобы обеспечить успех компании. Как только компании начинают масштабироваться, их продуктовые команды тоже должны расширяться, поэтому обязанности становятся более определенными. Когда одному человеку не хватает часов в сутках, чтобы выполнить всю работу, это приводит к появлению новых уровней в организации, а обязанности этих людей меняются в зависимости от объема тактической, стратегической и оперативной работы.

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

Стратегическая работа заключается в позиционировании продукта и компании с целью победы на рынке и достижения целей. Она рассматривает будущее состояние продукта и организации и то, что потребуется для достижения цели.