Как найти владельца продукта внутри компании
Чем грозит неправильное определение владельца продукта, как найти людей, между которыми распределены его функции сейчас, и понять, кто из сотрудников сможет взять все обязанности на себя.
Когда компания внедряет Agile-подходы, как правило, появляется роль владельца продукта, особенно если команда переходит на Scrum.
Как показывает наш опыт, сознательно определяют владельца продукта в двух случаях:
- Когда организация готовится к Agile-трансформации и нужно понять, кто из текущих сотрудников внутри компании будет выполнять эту роль.
- Когда Agile-трансформация уже стартовала и кого-то назначили владельцем продукта, но позитивных изменений в развитии продукта не замечают.
Содержание статьи
Почему важно определить владельца продукта
Когда компании самостоятельно реализуют Agile-трансформацию, чаще всего роль владельца продукта отдают тому, кто находится близко к команде, разбирается в метриках и общается с клиентами/пользователями. Туда, как правило, попадают аналитики, проектные менеджеры, руководители разработки, техлиды и другие специалисты.
Проблема такого подхода в том, что зачастую этим людям не хватает полномочий в принятии решений относительно управления продуктом: видения, стратегии, целей, монетизации, экономики, маркетинга и т.д. А раз нет полномочий, то и ответственность за это продолжает находиться там же, где была до Agile-трансформации.
И когда команда живет в новых процессах реализуя задачи, которые не приводят к целям и успеху, то это только демотивирует сотрудников, и люди начинают винить во всём Agile-трансформацию, или говорить, что Scrum не работает.
Чтобы не попадать в ситуацию, когда вы перешли на Scrum, а ценность продукта для бизнеса и клиентов не меняется, важно найти в компании человека, который будет единолично сфокусирован на этой задаче, то есть исполнять роль владельца продукта. Для начала хорошо бы понять, какие полномочия нужны владельцу продукта для успешного исполнения своей роли.
Определить зоны ответственности владельца продукта
Как правило, основные функции владельца продукта — это формирование видения продукта, определение стратегии, выбор целей и задач. Обычно до Agile-трансформации их выполняет топ-менеджмент, который определяет, зачем мы создаем продукт, каким будет продукт, на каком рынке будем работать, как будем зарабатывать, с кем и как будем конкурировать и т.д.
Кроме того, владелец продукта занимается:
- вопросами бюджетирования;
- выстраиванием маркетинга и продаж;
- экономикой продукта, монетизацией и тарифами;
- составлением, приоритизацией бэклога продукта;
Также в его задачи входит исследование рынка, проектирование экспериментов, поиск точек роста, исследование клиентов и технологий. До Agile-трансформации перечисленные зоны ответственности, как правило, распределены между несколькими сотрудниками внутри компании. Теперь нам нужно передать эти полномочия одному человеку и понять, а есть ли такой сотрудник в компании.
Определить, кто выполняет роль владельца продукта сейчас
Поиски владельца продукта внутри компании начинаются с ответов на четыре вопроса, которые помогут определить, между какими людьми внутри компании сейчас распределены ключевые функции владельца продукта — потенциально эти люди могут взять роль на себя:
- Кто принимает управленческие решения? То есть определяет, куда и зачем бежит команда.
- Кто определяет и выделяет бюджет? То есть выделяет ресурсы, чтобы команда двигалась в нужном направлении.
- Кто отвечает за бизнес-эффект? Если команда не достигла бизнес-целей, — размера выручки или объема клиентской базы — кто будет за это отвечать перед CEO?
- Кто драйвит этот процесс внутри организации? То есть кто является носителем идеи продукта, заряжает идеей компанию и команду?
Одна компания запустила Scrum-команду, пожила в новом процессе пару месяцев и поняла, что продукт с точки зрения ценности для бизнеса никуда не двигается, хотя задачи выполняются. Это была система для автоматизации процессов логистики внутри группы компаний.
Мы ответили на четыре вышестоящих вопроса и за 20 минут определили, что:
- СЕО холдинга драйвит историю с цифровизацией.
- Директор одного из предприятий холдинга отвечает за бизнес-эффект от реализации данной инициативы.
- Директор проектного офиса выделяет бюджет на реализацию (причем деньги она берет у директора предприятия).
- Руководитель отдела логистики принимает управленческие решения касательно приоритетов, т.е. какие бизнес-процессы автоматизировать в первую очередь, а какие нет.
При этом владельцем продукта был назначен аналитик, который подчиняется руководителю отдела логистики. Понятно, что аналитик не мог принимать решения касательно развития продукта, а занимался только расшифровкой требований к продукту от руководителя и других заинтересованных лиц. После данной сессии клиент собрал вышеупомянутых людей вместе, чтобы решить, кому из них стоит передать все эти функции, чтобы начать видеть рост ценности продукта для холдинга.
Когда ответите на четыре вопроса, вам предстоит понять: есть ли в компании человек, который сможет стать владельцем продукта, или нужно нанимать нового сотрудника.
Определить, кто будет выполнять роль владельца продукта
Итак, мы определили людей, которые сейчас выполняют разные функции владельца продукта. Теперь нужно узнать, готов ли кто-то из них расширить свою зону ответственности в работе над продуктом.
Например, директор проектного офиса отвечает за бюджет, и вот ей предлагают взять ответственность еще и за бизнес-показатели, бэклог, исследования, эксперименты в одном продукте. Она сказала: «Нет, я не готова, у меня много других дел, поэтому я не хочу заниматься этими вопросами». Подобные ответы, скорее всего, мы получим и от других топ-менеджеров компании.
Мы идем чуть ниже, к линейным менеджерам или руководителям, и начинаем задавать те же вопросы. Даже если кто-то согласится взять на себя новую роль, руководство может не согласиться с кандидатурой, потому что человек не обладает достаточной экспертизой и опытом. Если же менеджмент одобрит самовыдвиженца, то окажите ему всяческую поддержку на этом пути, особенно в первые месяцы. Как правило, первое время менеджмент будет передавать свежеиспеченному владельцу продукта свою бизнес-экспертизу.
В этот период мы будем сепарировать владельца продукта от топ-менеджера в каких-то зонах ответственности. И в первую очередь нужно понять, с чего начнется процесс роста полномочий владельца продукта. Например, сначала будем передавать ему целеполагание и ответственность за бизнес-показатели, бюджет пока оставим в зоне ответственности директора проектного офиса, а видение и стратегию — у СЕО. После того, как менеджмент убедится в адекватности владельца продукта, начинайте ему/ей передавать остальные полномочия.
Если же мы понимаем, что никто в компании не готов примерить на себя роль владельца продукта, или топ-менеджмент не готов передавать полномочия по управлению продуктом никому из сотрудников компании, тогда начинаем поиск стороннего человека. В этом случае для начала определитесь: а какие вышеперечисленные зоны ответственности менеджмент готов отдать в единоличное управление этому человеку? Это поможет избежать в будущем неловких ситуаций, когда нашли владельца продукта, а на самом деле хотели хорошего проектного менеджера.
Подключайтесь к Telegram-каналу, где мы делимся практиками осознанного Product Ownership.
Хочу рассказать вам о методе Бережливого планирования продуктов и месте, которое он занимает в современной деятельности по созданию технически сложных и комплексных продуктов, таких как беспилотный автомобиль, аэротакси или современные космические ракеты. А заодно порассуждать, почему некоторые технологические стартапы превращаются в глобальные корпорации, как например Tesla, а некоторые входят в анналы истории как имена нарицательные для обозначения кринжовых концепций и безумных проектов, например как ё-Мобиль.
Что такое минимально жизнеспособный продукт (MVP)? Почему MVP так важен в процессе разработки и как его эффективно использовать? В этой статье ответим на все эти вопросы и посмотрим примеры самых узнаваемых брендов, история которых начиналась с MVP.
Обсудим, как написать хорошую User Story, какие существуют паттерны декомпозиции пользовательских историй, как их использовать и главное — зачем на самом деле декомпозиция нужна команде.