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

• Как мы можем снизить этот риск?

Слишком часто менеджеры по продукту погружаются в создание решений, не продумав сопутствующие риски. Каждый из вышеупомянутых вопросов представляет для Меган риск, который потенциально может погубить ее проект. Здесь назревает вопрос: почему мы так поступаем? Во многих розничных банках и других организациях менеджерам по продукту не дают возможности задать вопрос «почему». Они получают функции и решения от заинтересованных сторон или менеджеров. Иногда эти функции определяются и утверждаются во время ежегодного периода бюджетирования. В других случаях их рассматривают как работу менеджера – диктовать решения, которые необходимо создать. Поступая таким образом, вы создаете риск неудачи, связанный с предвзятостью этих решений, организационной или личной. Единственный способ борьбы с этой предвзятостью – учиться у пользователей и экспериментировать.

Во многих случаях, когда организации предлагают решения, они не устанавливают метрики успеха и цели. Проект Меган мог бы пойти совсем по-другому, если бы это было так, и если бы ей просто сказали: «Сделайте процесс подачи заявки цифровым, чтобы никому не пришлось лично обращаться в банк». А что, если бы она обнаружила, что ее клиенты не хотят подавать заявки онлайн и им удобнее делать это в офисе? Что, если бы цифровизация процесса привела к резкому снижению процента оформления заявок? Как она могла принять решение и исправить ситуацию, если у нее не было для этого никакого пространства?

Самая большая проблема, которую я слышу от руководителей, приходя в их организации, заключается в том, что продакт-менеджеры не хотят делать шаг вперед и «владеть продуктом». Однако это обоюдоострый меч. Во многих случаях менеджер может сделать больше. Например, он может поставить под сомнение определенные решения. Работа, необходимая для сбора данных и доказательства эффективности решения, требует времени. И вот именно здесь люди обычно путаются между тем, что в Agile называется владельцем продукта и менеджером по продукту.

Если посмотреть на роль владельца продукта в большинстве литературы по Scrum (методология управления проектами), то в обязанности этой должности входит следующее:

• Определение бэклогов и создание действенных пользовательских историй для команд разработчиков.

• Выявление и расставление приоритетов работы в бэклоге.

• Приемка завершенных пользовательских историй и проверка работы на соответствие критериям.

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

• Как мы определяем ценность?

• Как мы измеряем успех продуктов на рынке?

• Как убедиться, что мы создаем нужный продукт?

• Как устанавливать цену и упаковывать продукт?

• Как вывести продукт на рынок?

• Что имеет смысл создавать, а не покупать?

• Как выйти на новые рынки, используя стороннее программное обеспечение?

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

Без такого опыта человек может эффективно выполнять роль владельца продукта, но он никогда не сможет быть уверенным в том, что он создает правильную вещь. Другими словами, владелец продукта – это роль, которую вы играете в команде Scrum. Менеджер продукта – это карьера.

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

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

Меган добилась успеха в немалой степени потому, что ее руководитель и организация настроили ее на успех. Они вместе работали над определением цели, а ее начальник предоставил ей пространство для достижения цели. Более того, команда тоже ее поддержала. Но что самое важное, у нее было самое главное преимущество: ей разрешили общаться с пользователями.

Поговорив с людьми, которые не закончили подачу заявки на ипотеку, она узнала о проблеме проверки документов. Именно тогда она смогла сказать: «Ага! Если я найду эффективный способ проверки документов, тогда люди будут завершать оформление ипотеки». Она нашла проблему, которую нужно решить, вместо того чтобы гадать, что должно произойти, а затем бросать все свои силы на решение проблемы, которые могут существовать, а могут и не существовать.

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

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

Слишком часто компании даже не знают, в чем состоит работа продакт-менеджеров. Они не понимают их значимости в компании. Я нередко слышу, что руководители не хотят нанимать продакт-менеджеров, потому что не понимают, зачем они нужны. «Всем занимается генеральный директор, – вот что они говорят. – У нас не такая большая организация – несколько сотен человек. Команда справится». Отговорки только накапливаются, и в итоге организации не удается сохранить долгосрочную ценность для пользователей. Они быстро разваливаются или, в случае с крупными компаниями, медленно угасают. Если вы хотите выбраться из ловушки и начать фокусироваться на правильных решениях и продуктах, которые нужны и востребованы клиентами, вы должны внедрить в свою компанию управление продуктом.

Одна роль, много обязанностей

Крис начал понимать. «Похоже, мне и правда нужны продакт-менеджеры. Но как мне удержать их в процессе работы? У них есть возможность карьерного роста?» Мы обсудили их обязанности и карьерную лестницу.

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

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

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

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

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

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

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

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

Глава 8

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

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

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

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

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

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

График 8.1. Стратегическое, оперативное и тактическое процентное соотношение ролей (для команд численностью более 10 человек)

Давайте рассмотрим типичный карьерный путь менеджера по продукту:

• младший продакт-менеджер;

• менеджер по продукту;

• старший менеджер по продукту;

• директор по продукту;

• вице-президент по продукту;

• главный директор по продукту (CPO).

Младший продакт-менеджер

Роль младшего продакт-менеджера является начальным уровнем. Однако, как я уже упоминала в начале этой части, в компаниях, кроме Microsoft и Google, таких должностей не так много. Именно это нам и требуется изменить в отрасли. Если компании хотят иметь грамотных менеджеров, им нужно начать их выращивать.

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

Разработчики учатся своему ремеслу, работая в паре со старшими IT-архитекторами и очень опытными разработчиками. Сотрудники отдела продаж учатся у опытного руководителя в своем подразделении. В продакт-менеджменте должна существовать такая же система, и именно поэтому компании важно иметь опытных людей, которые смогут работать в паре с младшими сотрудниками. Однако, как знает любой человек, кто когда-либо пытался нанять старших специалистов по продуктам, на рынке их не так много. А тех, кто есть, быстро расхватывают. Так почему у нас так мало людей с опытом работы в этой роли?

Создание программы ассоциированного управления или младшего управления продуктом – ключевой момент. Если вы руководите компанией или занимаетесь разработкой организации производства, я призываю вас создать такую программу. Откройте должность младшего продакт-менеджера для людей, переходящих в управление продуктом сразу после окончания школы или из другой сферы деятельности. Поставьте их в пару со старшим менеджером, чтобы он научил их работе. Предоставьте им все необходимые консультации. Мы создаем старших специалистов, дав шанс младшим.

Менеджер по продукту

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

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

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

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

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

Старший менеджер по продукту

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

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

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

Директор по продукту

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

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

Вице-президент по продукту

Следующая должность – вице-президент по продукту. Человек в этой роли контролирует стратегию и операции для всей линейки продуктов.

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

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

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

Главный директор по продукту (CPO)

Главный директор по продукту – это довольно новая, но очень важная роль для организаций. CPO курирует весь портфель продуктов компании. Это самая высокая должность менеджера по продукту, и она означает место за исполнительным столом компании.

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

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

CPO должен уметь взаимодействовать и на уровне совета директоров. Шелли Перри, венчурный партнер компании Insight Venture Partners и эксперт по роли CPO, объясняет это следующим образом: «Члены совета директоров заботятся о финансовых последствиях решений, касающихся технологий и продуктов. Успешный директор должен уметь переводить свои действия в понятные для совета директоров термины».

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

Если предположить, что они уже обладают навыками во всех аспектах управления продуктом, технологиями и финансами, то те, кто становятся лучшими директорами по продукту, обладают тремя ключевыми чертами, которые отличают их от других: они внушают доверие, сопереживают, а также неутомимы и выносливы.

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

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

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

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

Наличие сильного лидера в руководстве – это критически важный шаг к тому, чтобы стать компанией, ориентированной на продукт. К сожалению, в настоящее время на рынке не так много CPO, поскольку эта область еще только формируется. Моя компания, Produx Labs, в партнерстве с Insight Venture Partners создала акселератор CPO, в котором вице-президенты по продукту превращаются в CPO своих компаний. Мы рады развивать будущих лидеров, находящихся на стадии роста, которые могут помочь создать успешные, нацеленные на продукт организации.

Глава 9

Организация команды

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

Marquetly была структурирована вокруг технических компонентов. «Наш тренер по Agile предложил создать Scrum-команды для каждой области продукта», – сказал технический директор. Хотя в теории это имеет смысл, на практике это способствовало плохому управлению продуктом.

Во время семинара, посвященного хорошим навыкам управления продуктом, я подчеркивала важность прочных основ, когда один из владельцев продукта вдруг вставил свое слово:

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

– Это новый API? – поинтересовалась я. – Есть ли с ним сейчас какие-то серьезные проблемы, которые вы пытаетесь исправить?

Оказалось, никаких серьезных проблем не было. Интерфейс прекрасно работал.