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

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

Продакт-менеджеры – это ключ к компании, ориентированной на продукт.

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

Часть II

Роль продакт-менеджера

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

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

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

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

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

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

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

Глава 6

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

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

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

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

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

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

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

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

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

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

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

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

Мини-CEO

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

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

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

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

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

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

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

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

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

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

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

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

Официант

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

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

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

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

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

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

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

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

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

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

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