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

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

Если вы не сможете победить их…

Еще на меня произвел огромное впечатление тот день, когда Ларри Корнетт перешел с должности вице-президента по UX-дизайну Yahoo Search на позицию вице-президента по продукту для той же самой команды.

А что, так можно было?! Для меня это стало откровением.

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

Стал ли я одним из угнетателей? Нужно ли вам поменять команду, чтобы продвигаться вперед или повлиять на стратегию продукта? Или продукт и UX могут объединить усилия как «лучшие друзья»? Это лишь некоторые вопросы, которые я рассмотрю в этой книге.

Глава 1
Что именно делает менеджер продукта?

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

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

Управление продуктом отвечает за ценность

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

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

Можно представить себе это так: устойчивая ценность для организации обеспечивается путем получения справедливой доли ценности, созданной для клиента (или конечного пользователя, субъекта, действующего лица, главного героя).

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

ИСТОРИИ ИЗ ЖИЗНИ

ЧТО МЫ ИМЕЕМ В ВИДУ, КОГДА ГОВОРИМ ПРО ЦЕННОСТЬ

Первым человеком, научившим меня фокусироваться на ценности как путеводной звезде управления продуктом, стал Джей Завери, который в то время был директором по продуктам в стартапе CloudOn, а сейчас руководит инкубатором продуктов в Social Capital, венчурной инвестиционной компании из Пало-Альто.

Я цитировал его, когда люди спрашивали меня, что означает ценность, и сложно было избежать шаблонных ответов вроде «Вы поймете это, когда увидите всё ее многообразие». Некоторые люди подчеркивают ценность системы в целом – в отличие от только денежной ценности или от той, которая достается лишь владельцу организации. Однако Джей сформулировал это так: «Ценность – это нечто особенное, что испытывает человек или клиент и чего раньше не было. Ценный продукт является полезным, удобным и желанным. Ценность удовлетворяет глубокую потребность, желания или стремления клиентов, о существовании которых они даже не подозревали. Очевидно, что продукт должен выделяться среди других технологически („дешевле, быстрее, лучше“), быть широкодоступным (доступен там, где раньше им могли пользоваться лишь немногие) и менять поведение людей (таким способом, который выгоден пользователю или клиенту)».

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

Менеджер продукта – это не руководитель проекта

Менеджеров продукта часто путают с менеджерами проектов. Даже те люди, которые понимают разницу, случайно путают их в разговоре. Аббревиатуры не помогают, поскольку для обоих названий используется ПМ, и только контекст помогает их отличить. (Иногда встречается контекст «в этой компании нет менеджеров проектов» или наоборот; в другой раз все зависит от говорящего, команды и самой беседы.)

► В ЭТОЙ КНИГЕ ПМ ОЗНАЧАЕТ «МЕНЕДЖЕР ПРОДУКТА»

Забудьте также о потенциальных аббревиатурах ПрМ или ПроМ^[3], поскольку тут все равно нет букв, проясняющих разницу. И я еще не встречал ни одного человека, который хотел бы, чтобы его называли ПроджМ и ПродМ, или PjMs и PdMs, уж если на то пошло. В этой книге ПМ означает «менеджер продукта».

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

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

Некоторые руководители проектов действительно становятся менеджерами продукта, и тогда, как и в случае с UX-дизайнерами, они должны овладеть целым рядом смежных навыков, помимо «отправления поездов по графику».

Консультант по продуктам и автор книг Мэтт Лемей, соучредитель Sudden Compass, сказал так: «У менеджеров продукта есть как возможность, так и обязанность задавать вопрос „почему?“».

Менеджер продукта – это не владелец продукта

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

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

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

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

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

Откуда появились менеджеры продукта?

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

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

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

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

• В отличие от физических продуктов, под которыми раньше понимали «упакованную штуковину в коробке на полке», большинство программных систем сегодня являются SaaS (Software as a Service, программное обеспечение как услуга). Они размещены в облаке, доступны через браузер и иногда через клиентские приложения, нечувствительны к некоторым материальным ограничениям процесса производства (необратимые затраты, каскадные процессы, ограниченная возможность вносить изменения, когда продукт уже начинают поставлять).

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