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

Глава 6
Архетипы плохого менеджера

На сегодняшний день существует немного путей изучения продакт-менеджмента. Этому не учат в колледже. Программы обучения на рабочем месте обычно отсутствуют. Microsoft и Google – две единственные крупные компании, которые действительно имеют карьерный путь для менеджеров по продукту. Стажировки тоже немногочисленны, поэтому большинство менеджеров либо переместились с должности на должность внутри компании, либо были «повышены» из отдела разработки программного обеспечения.

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

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

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

Если вы слушаете и разводите руками, говоря: «Так не должно быть!», я с вами соглашусь. С ростом популярности методологии Agile все больше и больше людей видят недостатки этой системы, которая может годами определять ценность этих требований.

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

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

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

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

Когда я прошу людей дать определение продакт-менеджеру, я получаю множество разных ответов – даже от самих менеджеров. «Менеджер по продукту – это тот, кто придумывает идеи!» Или: «Они – голос клиента!» И всегда: «Менеджер по продукту – это генеральный директор продукта!»

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

Мини-CEO

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

Из этого замечательного мифа о генеральном директоре возник архетип очень высокомерного менеджера по продукту, который думает, что он правит миром. Одного из таких типов я нашла в Marquetly. Его звали Ник. Ник только что окончил бизнес-школу и был принят в компанию на должность менеджера по продукту. Все разработчики его ненавидели. UX-дизайнеры тоже. Почему?

Честно говоря, Ник ужасно себя вел с дизайнерами и разработчиками. Он изначально хотел стать менеджером по продукту, потому что воображал себя следующим Стивом Джобсом, провидцем, который будет сидеть наверху и диктовать своей команде все, что они должны создать. Излишне говорить, что остальным членам команды это очень не нравилось. Он был расстроен: «Команда меня не слушает и ничего не делает». Бедный Ник. Он просто не понимал своей роли.

Тогда я отвела его в сторону и сказала:

– Слушай, я когда-то была в твоей роли, и позволь заметить, что такой образ мышления работает не в твою пользу. Я пришла в OpenSky, ухватилась за эту должность и не хотела ее отпускать. Я никогда не хотела слышать критику в адрес своих идей. В конце концов, я же визионер! Это была моя работа. Если кто-то приходил ко мне с идеей, я сразу же ее отвергала. Пойми, так друзей не завоюешь. И, честно говоря, я была несчастна, потому что моя команда не хотела со мной работать.

Я заметила, что привлекла его внимание. Тогда я продолжила:

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

Ник сидел и вникал в происходящее.

– Я хочу добиться успеха. Скажите, что нужно сделать, чтобы стать лучше и создавать крутые продукты.

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

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

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

Официант

«Официант» – это менеджер по продукту, который в душе является исполнителем. Такие люди приходят к заинтересованным сторонам, клиентам или менеджерам, спрашивают, чего те хотят, и превращают желания в список вещей, которые необходимо разработать. Здесь нет цели. Нет концепции. Нет принятия решений. Такой архетип встречался у 90 % владельцев продукта в Marquetly.

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

Схема 6.1. Цикл смерти продукта, автор Дэвид Дж. Блэнд

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

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

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

Бывший продакт-менеджер

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

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

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

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

Глава 7
Успешный продакт-менеджер

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

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

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

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

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

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

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

Технический эксперт и рыночный эксперт

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

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

Мне часто задают вопрос: «В чем разница между UX-дизайном и управлением продуктом?» Эти две дисциплины во многом пересекаются, но пользовательский опыт – это только одна часть создания хорошего продукта. Дизайн – его важнейший компонент. Но опять же это тоже только одна его часть. Управление продуктом – это изучение всей системы: требований, компонентов функций, ценности, пользовательского опыта, базовой бизнес-модели, ценообразования и интеграции. Это выяснение, как конкретный продукт может принести доход компании. Речь идет о понимании всей картины организации и выяснении того, как продукт – а не только опыт – в нее вписывается.

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

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

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

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

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

Грамотный продакт-менеджер

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

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

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

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

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

Ее цель состояла в том, чтобы увеличить этот процент. Поэтому, оценив потребности клиентов и проблемные точки в предложении ипотечных услуг, Меган спросила себя: «Поможет ли мой подход увеличить вероятность того, что эти люди останутся в нашем банке?»

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

Меган периодически приглашала членов своей команды – разработчиков и UX-дизайнера – на сеансы исследования пользователей, чтобы все могли четко понять проблемы. Вскоре они обнаружили закономерность: многих потенциальных клиентов просили прийти в офис для проверки документов (поскольку это нельзя было сделать онлайн). Большинство людей предпочитали обратиться в другой банк, потому что в этом банке не было свободных мест на ближайшее время. Проведя опрос среди более широкого круга людей, Меган выяснила, что это была самая распространенная проблема. Только 25 % людей заполнили заявки в ее банке.

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

Меган рассказала нашей команде о первом тестировании. Чтобы понять, как создать онлайн-систему для загрузки и проверки необходимых документов для ипотеки, они сразу перешли к практике и попросили заявителей прислать документы по электронной почте. На время тестирования банк назначил человека для проверки документов и их одобрения. За это время новые заявители заполняли свои заявки на 90 % чаще, чем те, кто приходил в офис.

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

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

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

Начните с «почему»

Теперь давайте поговорим о том, что помогло Меган и ее команде добиться успеха. Она начала с вопроса «почему?».

• Почему мы переходим на цифровое обслуживание в сфере ипотеки?

• Зачем вообще делать этот проект?

• Каков желаемый результат?

• Как выглядит успех?

• Что произойдет, если мы перейдем на цифровое обслуживание, но никто не будет брать кредит?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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