Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта - читать онлайн книгу. Автор: Мелисса Перри cтр.№ 8

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

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

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

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

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

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

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

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

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

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

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

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

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