Управление продуктом для UX-специалистов. От дизайна интерфейсов к успешному развитию в мире продуктов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Менеджером по продуктам середины XX века обычно был человеком с бизнес-образованием или даже с ученой степенью в области бизнеса, и самые ранние цифровые эквиваленты унаследовали часть этой ДНК.

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

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

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

Аналогичная роль, появившаяся в Microsoft в то время, называлась руководитель программы (англ. program manager). Сегодня управление программой обычно относится к отдельной дисциплине, посвященной операционному выполнению сложных программ, состоящих из множества взаимосвязанных проектов.

Тогда ПМ почти всегда имели степень MBA[4] и порой конфликтовали с опытными инженерами и дизайнерами, если начинали работать на этой ответственной должности сразу после окончания обучения.

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

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

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

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

СТЕПЕНЬ MBA НЕ ТРЕБУЕТСЯ

Пару лет назад я был частью возглавляемой Мотти Шейнкером команды, которой было поручено поднять планку продуктов в AOL; этот портал недавно отделился от неудачно объединенных компаний Time/Warner и пытался наверстать свое десятилетнее отставание в развитии. Одной из наших задач был пересмотр и обновление кадровой лестницы для менеджеров продукта и UX-дизайнеров. Мы определяли, какой уровень навыков и достижений по ряду критериев требовался для приема на работу или продвижения по службе – от младшего сотрудника до вице-президента (отслеживая индивидуальный вклад, ведущий дизайнера к уровню руководителя).

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

Джофф Редферн, вице-президент по продуктам Atlassian (а ранее LinkedIn и Facebook[5]), предпочитает называть этот аспект роли «мышлением топ-менеджера». Он обладает все теми же ограничениями с точки зрения полномочий, но более точно соответствует концепции человека с ответственностью по согласованному объему работ в бизнесе.

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

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

Еще одним предшественником современных ролей менеджера продукта является должность менеджера по маркетингу, или даже по маркетингу продукта, которая берет свои истоки из бизнес-практики XX века. Интересно, что одержимость потребностями клиента, присущая управлению продуктом, проистекает из этой основополагающей ДНК. Сегодняшняя увлеченность удовлетворением рынка и достижением соответствия ему продукта (термин, также известный как product-market fit[6]) – это еще один элемент преемственности рыночной ориентации в раннем управлении продуктом.

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

В статье «Менеджер по маркетингу продукта против менеджера продукта: где вы проводите черту?» (Product Marketing Manager vs. Product Manager: Where Do You Draw the Line?)[7] авторы проделали хорошую работу по разграничению этих ролей и обоснованию их раздельности, сводя суть к следующему:

• роль управления продуктом – это реализация стратегии;

• роль маркетинга продукта – создание маркетингового сообщения.

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

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

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

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

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

Google славится тем, что заставляет менеджеров продукта «зарабатывать» инженерные ресурсы и покупать их. Нет никакой гарантии, что если вы напишете спецификацию, то кто-то по ней напишет для вас код. Но Google также славится тем, что развивает менеджеров продуктов и дает им больше власти. Программа Associate Product Manager[8] со структурированным обучением и ротацией, которую там впервые внедрила Марисса Майер, широко распространилась в других начинающих технологических гигантах.

Но, опять же, тип менеджера продукта, предпочитаемого в предприятиях с культурой Google или смежными с ней, обычно хорошо технически подкован. Следовательно, такие интервью с заковыристыми задачками в действительности имеют значение для отбора людей, способных программировать, но наивно думать, будто ПМ будет регулярно обсуждать «сложность Большой О[9]» нескольких конкурирующих алгоритмов.

► СОБЕСЕДОВАНИЕ ПМ ПО ТЕХНИЧЕСКИМ ВОПРОСАМ

Я до сих пор с теплотой вспоминаю день, проведенный в кампусе Google, когда я проходил собеседование последовательно у 11 человек разных возрастов, цвета волос и степени атлетизма или чудаковатости, а затем был приглашен на обед. Честно сказать, многие собеседования прошли весело, к тому же мне всегда нравились головоломки, хотя и не под давлением осознания, что на кону большие деньги. Время от времени эти вопросы вновь появляются на собеседованиях, поэтому, немного поискав, вы сможете найти уже использовавшиеся примеры. Например, меня спросили, как может работать эффективный алгоритм генерации пятизначного кода доступа на клавиатуре, учитывая заданные правила или ограничения относительно чисел (набранные с повтором и так далее). Как я уже сказал, это было почти весело.

И, честно говоря, сегодня бóльшая часть приличных организаций, которые предлагают подобного рода задачи, сотрудничает с вами и помогает направить в нужное русло ваши размышления. (Если такая роль – ваша цель, но вы не информатик, то есть книги, которые помогут быстро[10] освоить эти темы. Подробнее о выборе карьеры вы прочитаете в главе 2 «Хотите ли вы стать менеджером продукта?».)

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

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

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

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

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

Марти Каган, консультант в Silicon Valley Product Group[11] и автор книги «Вдохновленные»[12] (Inspired), убедительно обосновал расширение полномочий для команды по продукту, потому что им необходимо изучать проблемные области, управлять исследовательскими процессами, встречаться лицом к лицу с клиентами и планами на будущее, подбираться к глубокому пониманию, что необходимо людям и что им понравится, дабы вывести на рынок ценные продукты.

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

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

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

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

Это та же идея сторонников «бережливости», популяризированная книгой Эрика Райса «Бережливый стартап»[13] (Teh Lean Startup), когда менеджер продукта в уполномоченной команде управляет непрерывным PDCA-циклом, который содержит следующее: изучение того, что в настоящее время «поставляется» и «по-прежнему используется»; включение найденных идей в обновленный исследовательский процесс, организованный в форме качественных исследований[14] и направленный на проверку гипотез и поиск понимания; переопределение проблемной области; выявление дальнейших возможностей или стóящих экспериментов; принятие решений о том, что создавать или исправлять дальше; и выпуск следующей версии продукта, после чего цикл начинается заново.

Этот цикл, показанный на рис. 1.1, можно смоделировать в мельчайших деталях, но чаще всего он сводится к «Созданию, измерению, изучению»[15].

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

Стоит отметить, что несмотря на заголовок и то, что это все является циклом, вы обычно не начинаете с создания продукта. Вы начинаете с изучения или измерения (первоначальной оценки) чего-то, узнаёте то, что относится к предмету вашего исследования, а затем создаете.

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