Что значит быть продукт-менеджером?

ПОДРОБНЕЕ О КНИГЕ

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

Тем не менее между продукт-менеджером и директором существует одно принципиальное различие: продукт-менеджеры не имеют прямой власти над участниками команды.

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

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

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

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

Задачи продукт-менеджера

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

Хотя жизненный цикл продукта зависит от компании (а иногда и от команды), он, как правило, имеет четыре основных этапа: «Исследования и планирование — Разработка дизайна — Реализация и тестирование — Выпуск». Разумеется, эти этапы часто пересекаются друг с другом.

В некоторых компаниях/командах обязанности продукт-менеджера распределяются между двумя людьми, один из которых в большей степени сконцентрирован на бизнесе, другой — на технических вопросах. В этом случае технического сотрудника называют техническим руководителем программ, или техническим продукт-менеджером (Technical Product Manager, TPM), а сотрудника, ориентированного на бизнес, — просто продукт-менеджером (Product Manager, PM).

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

Исследования и планирование

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

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

После того как продукт-менеджер подготовил предварительный план, ему необходимо привлечь к работе других людей. В таких компаниях, как Microsoft, Apple и Amazon, одобрение происходит «сверху вниз» и высшее руководство задействуется на самых ранних этапах разработки проектов. В компаниях Google и Facebook, а также во многих стартапах преобладает подход «снизу вверх», в котором основная задача продукт-менеджера — выстроить отношения с инженерами.

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

На этом этапе продукт-менеджер начинает определять критерии успеха. Он представляет себе, как выглядит мир, если команда работает успешно. Чтобы объяснить команде основные цели работ, во многих компаниях используется модель целей и ключевых результатов (Objectives and Key Results, OKR). В этой модели продукт-менеджер вместе с командой определяет измеримые результаты, к которым они будут стремиться.

Дизайн

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

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

В некоторых командах, особенно в тех командах Microsoft, которые занимаются разработкой поставляемого (в противоположность онлайновому) ПО, продукт-менеджер составляет подробную функциональную спецификацию, включающую в себя следующие пункты:

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

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

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

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

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

Реализация и тестирование

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

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

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

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

В процессе реализации продукт-менеджер также приступает к сбору обратной связи и отправке отчетов об ошибках в начальных версиях продукта. Иногда функциональная возможность, которая выглядела привлекательно на этапе разработки дизайна, в реальной жизни оказывается не столь хорошей. Для выявления подобных проблем команды исследуют практичность продукта, экспериментируют с ним и проводят его внутреннее тестирование (dogfooding) по принципу «сам ешь свою стряпню», означающему просто, что вы сами должны использовать собственный продукт. Например, сотрудники Microsoft ежедневно работают на компьютерах, на которых установлены ранние версии будущих релизов Windows. Сотрудники Facebook общаются между собой при помощи Facebook Groups.

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

Еще один способ проверить работоспособность продукта до его выпуска — провести исследование его практичности. При исследовании практичности участники опробуют первые прототипы нового продукта или новой функциональной возможности.

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

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

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

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

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

Выпуск

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

• Просмотр перечня выпуска. Для выпуска может понадобиться окончательное утверждение ключевых участников проекта (например, юридического отдела) или координация с определенными командами (например, командой маркетинга и эксплуатационной группой).

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

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

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

Как тип продукта влияет на работу продукт-менеджера

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

Поставляемое ПО

К поставляемому ПО относятся мобильные приложения, доступные в магазинах приложений Apple, и программы, распространяемые на DVD. Уникальность поставляемого ПО состоит в том, что его сложно обновлять после запуска. Для веб-приложения всегда можно реализовать новую функциональную возможность, а если с ней возникнут проблемы, быстро удалить ее. При разработке поставляемого ПО важно «попасть в цель с первого выстрела».

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

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

Онлайновое ПО

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

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

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

Продукты широкого потребления

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

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

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

Продукты корпоративного назначения

Пользователями продуктов корпоративного назначения (business-to-business, В2В), таких как онлайновая реклама и узкоспециальные программы, являются сотрудники других компаний. Инженеры, разрабатывающие эти продукты, не являются их целевой аудиторией, поэтому в своей работе они опираются на понимание клиентов продукт-менеджером.

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

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

Новые продукты

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

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

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

Зрелые продукты

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

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

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

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