Предисловие

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

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

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

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

Мэтт Лемей, партнер Sudden Compass и автор книг

«Управление продуктом на практике» и «Agile для всех»

Введение

«Почему менеджер продукта говорит мне, что делать?»

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

Но каждый раз это был новый опыт, отличный от любого другого. Кто тот человек на встрече, что говорил о «продукте» и выступал за UX?

«Это менеджер продукта, тс-с…»

Один из дизайнеров в вашей команде сказал, что вас введут в курс дела позже, но намекнул, что здесь UX подчиняется менеджеру продукта.

Хорошо, но что это значит? Кто что делает? Верно ли, что менеджер по проекту – нет, подождите – по продукту делает макеты, а затем передает их дизайнерам, которые должны «раскрасить их» и «сделать симпатичными»?

Кто принимает окончательные решения по поводу взаимодействия пользователя с продуктом?

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

Наконец, что должны знать UX-специалисты об управлении продуктом?

► ЧТО ТАКОЕ ПРОДУКТ

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

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

Все зависит от обстоятельств.

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

Давайте начнем с того, что отмотаем время на несколько лет назад.

Десять лет назад я участвовал в мастер-классе…

Чуть более десяти лет назад я был штатным UX-дизайнером в Yahoo и куратором легендарной библиотеки дизайнерских паттернов (в моей визитной карточке написано «Детектив шаблонов» (англ. Pattern Detective)). Мой начальник Эрин Мэлоун была старшим директором в команде дизайна платформы отдела UED (user experience design, дизайн пользовательского опыта). Позже мы с ней в соавторстве написали книгу о дизайне социального опыта[2].

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

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

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

Но что более важно, 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, программное обеспечение как услуга). Они размещены в облаке, доступны через браузер и иногда через клиентские приложения, нечувствительны к некоторым материальным ограничениям процесса производства (необратимые затраты, каскадные процессы, ограниченная возможность вносить изменения, когда продукт уже начинают поставлять).

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

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

Менеджером по продуктам середины 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].

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

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

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

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

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

Управление продуктом как творческая работа

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

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

Внезапно креативные основатели начали получать финансирование для своих стартапов. Другие стартапы стали нанимать своих первых дизайнеров на гораздо более ранних стадиях. Дизайн (или «дизайн-мышление») предлагал проверенные методы использования ресурса творчества и изобретения инновационных решений интересных задач.

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

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

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

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

Три черты, общие для всех выдающихся менеджеров продукта

Выдающиеся менеджеры продукта, как правило, обладают следующими чертами личности:

• любопытство;

• способность все объединять;

• смелость.

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

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

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

Чем занимается ПМ?

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

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

Узнать об одном дне из жизни менеджера продукта можно, заглянув в раздел «Типичный день» в главе 2 «Хотите ли вы стать менеджером продукта?».

Ключевые идеи

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

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

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

• Управление продуктом – это бизнес-дисциплина, которая возникла под влиянием маркетинга продуктов, бизнес-анализа, управления программами, а также других практик, изучаемых на курсах MBA.

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

• В Кремниевой долине (по большому счету) управление продуктами приобрело предпринимательские качества экспериментирования и исследования, а также цикл «создавать, измерять, изучать».

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

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

Глава 2

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

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

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

Помимо этого, у вас могла появиться идея полностью перейти от UX к должности менеджера продукта – на полный рабочий день. Возможно, вы начали задаваться вопросом, хотите ли вы стать менеджером продукта или стали уже подумывать, что да, вы на самом деле хотите занять эту должность. Если это одна из причин, по которой вы взяли в руки эту книгу, то у вас сейчас есть хорошая возможность попрактиковаться в старом методе «Пять почему»[17], придуманном не по годам развитыми детьми. Начнем со следующего основного вопроса: почему вы хотите стать менеджером продукта?

Почему именно менеджер продукта?

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

Профессиональная деятельность и карьера

• Профессиональные интересы

• Планирование карьерного роста

Амбиции

• Реалии нынешней организационной структуры

• Жажда власти («темная сторона»)

Меняющиеся интересы

• Угасающий интерес к работе UX-специалиста

• Увлечение бизнес-стороной продукта

Профессиональные и карьерные причины

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

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

Например, в Yahoo, перед тем как компания была включена в Verizon, вице-президент по UX-дизайну в команде по поисковому продукту Ларри Корнетт поднялся на роль вице-президента по продукту для той же самой команды.

Старший директор по UX-дизайну Люк Вроблевски также взял на себя продуктовую роль. Это был подход «Если ты не можешь победить их, присоединяйся к ним» (рис. 2.1).

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

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

Амбиции

Еще одним стимулом для некоторых, несомненно, является возможность высказывать последнее слово по некоторым важным вопросам.

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

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

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

• вы можете прийти к тому, что пролонгируете существование некачественного подхода в управлении продуктом, который контролирует UX и не позволяет использовать его ценность разумно;

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

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

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

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

44 ПРИЗНАКА ТОГО, ЧТО ВЫ СТАНОВИТЕСЬ «НАСТОЯЩИМ» МЕНЕДЖЕРОМ ПРОДУКТА

В своем эссе «44 признака того, что вы становитесь менеджером продукта»[19] (44 Signs You Are Becoming a Product Manager) Джон Катлер, руководитель отдела исследований продуктов и образования в Amplitude[20], рассказывает про «гром и молнии», которые сопровождают ответственность менеджера продукта за принятие решений. Он начинает с вопросов: «Откуда вы знаете, что находитесь на пути к получению лычек ПМ/ВП? Что говорит о прогрессе? Ваш первый релиз? Получение „сертификата“? Составление красивой дорожной карты?» А затем отвечает: «Нет, есть 44 признака» (перепечатано с разрешения автора).

1. Вам будет казаться, что вы бесите свою команду.

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

3. Вы поймете, что оценки бесполезны, но на вас все еще давит «тяжелое чувство из-за временны́х ограничений».

4. Вы будете изо всех сил объяснять, почему ваше интуитивное мнение – верное (и будете правы).

5. Вы будете изо всех сил объяснять, почему ваше интуитивное мнение – верное (и будете не правы).

6. Вас будет напрягать необходимость отправить что-то до того, как оно будет готово.

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

8. Вы будете сталкиваться с суровой реальностью пользовательского тестирования.

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

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

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

12. Вас будут обвинять в том, что вы слишком сосредоточены на решениях проблем.

13. Вас будут обвинять в том, что вы работаете на слишком высоком уровне абстракции.

14. Вы обнаружите, что новый конкурент уничтожает ваш продукт.

15. Вам придется сообщать дурные новости вашей команде (часто признавая, что виноваты в них вы).

16. Вы будете завидовать _______ и тому, как они создают продукт (и все время будете помнить об этом факте, потому что те будут неустанно писать о своей работе в блоге).

17. Вы будете воображать себя технически подкованным, но ежедневно вас будут учить скромности.

18. Вы будете воображать себя подкованным в UX, но ежедневно будете пристыжены.

19. Вы будете воображать себя подкованным в бизнесе, но ежедневно будете пристыжены.

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

21. Вы начнете беспокоиться, что «отвлекаете» свою команду, и обнаружите, что не проявляете открытости. И это вам аукнется.

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

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

24. У вас появится день, заполненный встречами, и вы поймете, что абсолютно никакой ценности в этот день вы не создали.

25. Вы проведете отличную встречу, но никто это не заметит.

26. Вы разработаете полнофункциональный прототип, а затем попытаетесь сказать члену своей UX-команды, что вы не обдумывали дизайн.

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

28. Вы создадите потрясающую функцию, которую никто даже не заметит.

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

30. Вы будете пытаться отследить эффективность выпущенных функций, но потонете в потоке новых.

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

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

33. Вы начинаете говорить клиенту: «Это есть в дорожной карте», – а он в ответ громко смеется.

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

35. Вы говорите «да» клиенту в момент затмения, а затем понимаете, как упрямо пытаетесь защитить функцию, которая никому, кроме этого клиента, не нужна.

36. Вам будут говорить, что у вас недостаточно технический склад ума для этой должности.

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

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

39. Вы будете единственным козлом отпущения.

40. Вы обнаружите, что прикрываете свою команду.

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

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

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

44. Вам будет казаться, что вы учитесь на ошибках, но на самом деле волшебным образом будете их снова совершать (чтобы просто убедиться, что полученные знания укоренились).

Смена интересов

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

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

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

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

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

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

Являются ли эти причины вескими?

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

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

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

Но что именно вы здесь делаете?

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

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

1. Люблю ли я электронные таблицы?

2. Я могу хорошо писать?

3. Глубоко ли меня интересует динамика межличностных отношений?

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

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

Поэтому если вы любите целыми днями сидеть в Figma, Sketch или Swift, то вы, возможно, не обрадуетесь тому, что придется бросить все эти занятия или их большую часть ради задач и обязанностей по управлению продуктом. Вместо того чтобы жить в творческом процессе создания программ, вам придется тратить кучу времени на инструменты управления проектами по гибким методологиям, например Jira (обычно с Confluence), и выполнять, допустим, такие задачи:

• писать техническую документацию;

• разбивать эпики на пользовательские истории;

• приводить в порядок бэклог;

• планировать предстоящие спринты;

• отвечать на вопросы разработчиков по тикетам;

• проверять демоверсии, а потом одобрять их или отправлять на доработку;

• изучать данные автоматического тестирования;

• просматривать график оставшихся работ и другие визуализации прогресса;

• проводить ретроспективы.

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

И это только письменная часть.

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

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

НЕ ВСЕ ПМ ФАНАТЕЮТ ОТ ЦИФР

Клемент Као, директор по продукту в Blend и соучредитель Product HQ[21], отмечает: «В качестве исключения по-настоящему потрясающие менеджеры продукта в B2B обходятся без чисел, поскольку они имеют потрясающие способности к пониманию приоритетов, потребностей и образа мышления каждого отдельного клиента. Тем не менее в B2C определенно невозможно полностью избежать чисел!»

А Мэтт Лемей из Sudden Compass говорит об одном интересном нюансе: «Иногда это так, но не всегда. Я не люблю все эти вещи (числа, математику, анализ, электронные таблицы, базы данных), но при необходимости могу делать вычисления, которые вы описали выше».

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

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

У менеджера по продукту развиваются очень чувствительные антенны (если вы любитель поп-культуры, можете называть это «паучьим чутьем»), которые быстро реагируют, когда утренний отчет по метрике Полярной звезды предвещает[22] неожиданное снижение ежедневной активности пользователей или всплеск продаж. (И это еще до того, как мы приступили к машинному обучению [МО] и другим разновидностям искусственного интеллекта [ИИ].)

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

Типичный день

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

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

Не все дни одинаковы, но в них есть узнаваемые закономерности.

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

И в этом тоже есть узнаваемые закономерности.

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

Дома / до начала официального рабочего дня

4:30. Просыпаетесь посреди ночи и вспоминаете важный момент, который больше никто не отслеживает. Записываете его либо на прикроватной тумбочке, либо встаете с постели, переходите в домашний кабинет, обновляете тикет в Jira или отвечаете на сообщение, а потом пьете воду и засыпаете. (Возможно, вначале ответите на несколько других ночных сообщений от команды, работающей удаленно, пока вы не заснете опять.)

6:30. Встаете с постели, смотрите Slack на телефоне, отвечаете на несколько сообщений. Выполняете утренние ритуалы: кофе, душ, одежда, кофе, завтрак, почта, Slack, Jira, кофе.

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

На работе / реальный рабочий день

9:00. Проводите ежедневные стендапы с командой (разработчиками, иногда с UX-специалистами, но они не всегда приходят, другими участниками), в данном случае действуя де-факто как владелец продукта:

• вы приносите пончики (иногда буквально, но в переносном смысле, который популяризировал[23] эксперт по продуктам Кен Нортон, – постоянно);

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

• продолжаете совещание, обсуждая все, что можно прояснить сразу («Анкит, ты можешь предоставить Элли необходимые учетные данные для Github?»), и фиксируя другие вопросы, которые необходимо обсудить позже.

С 9:30 примерно до 14:30. Мозаика из следующих действий:

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

• общение с настоящими и потенциальными клиентами, другими заинтересованными сторонами;

• написание спецификаций, просмотр дорожной карты, наведение порядка в бэклоге, ответы на сообщения;

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

• обед на рабочем месте.

С 14:30 примерно до 17:30:

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

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

Снова дома / после рабочего дня

С 18:30 до … Наконец-то появилось время сделать следующее:

• почитать объемные отраслевые статьи, обзоры производства продуктов, отчеты коллег, которые вы не успели просмотреть в течение рабочего дня;

• не отвлекаясь, поработать над подробной статьей, анализом, моделированием проекта;

• попытаться уделить внимание своей семье и любимым;

• перед сном проверить данные еще раз.

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

Что, если вы все-таки не хотите быть менеджером продукта?

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

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

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

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

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

Ключевые идеи

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

• Самыми распространенными причинами перехода к управлению продуктом являются стремление к профессиональному и карьерному росту и смена интересов («которые приносят радость») в работе.

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

• Успех в качестве менеджера продукта частично зависит от желания и способности глубоко погружаться в данные. Это сложно, если не кажется вам интересным (или хотя бы «веселым»).

• Типичный рабочий день менеджера продукта сильно отличается от такового UX-специалистов.

Глава 3

Переносимые UX-навыки

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

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

• Какие мои существующие навыки позволяют мне стать менеджером продукта (и продолжат помогать мне на этой работе)?

• Какие мои существующие навыки и экспертные знания станут неактуальными или полностью бесполезными в работе менеджера продукта?

• Какими новыми навыками и практическими знаниями мне нужно овладеть, чтобы дополнить свой «UX-фундамент»?

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

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

Затем, прояснив вопросы и составив карту ландшафта, вы можете отметить конкретные области UX-компетенций, которые можно применять непосредственно в карьере менеджера продукта.

Чем менеджер продукта отличается от UX-специалиста

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

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

Тот, кто принимает решение

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

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

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

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

КТО ПРИНИМАЕТ РЕШЕНИЕ?

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

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

Мэтт Лемей высказывает аналогичную точку зрения: «Хорошие менеджеры продукта привлекают к принятию решений других людей. Но мне доводилось видеть, как многие переходят на должности менеджеров продукта, потому что хотят быть „теми, кто принимает решения“, а потом мгновенно теряют доверие своей команды из-за того, что принимают решения в одиночку и ни с кем ничего не обсуждают. В любом случае я надеюсь, что люди, приходящие из UX, будут лучше понимать, что чувствуешь, когда тебя исключают из числа тех, кто влияет на процесс, и станут более внимательными партнерами в деле принятия решения».

Одна из самых сложных задач – это понять, что невозможно всегда принимать правильные решения. Вам необходимо примириться с тем фактом, что иногда вы будете ошибаться. Вам неизбежно случится принимать решения, которые не оправдаются или покажут, что другой выбор был бы лучше. Как сказал Клемент Као, соучредитель Product HQ: «Когда вы не принимаете решение, то на самом деле вы „решаете его отложить“. Многие начинающие менеджеры продукта полагают, что „если они еще не решили, то это не засчитывается против них“, но такое затягивание само по себе является скрытым решением со своими последствиями».

По разным причинам среди менеджеров продукта существует консенсус: даже если вы справляетесь, то все равно принимаете неправильные решения в 25–30 % случаев. Вам остается просто надеяться, что вы не совершите ошибку, которая погубит компанию. Основатель LinkedIn Рид Хоффман сформулировал одну из веских причин, по которой вам нужно освоиться с этой задачей. Он сказал, что если вас ни капельки не смущает продукт, который вы выпускаете, то вы слишком долго откладывали его выпуск.

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

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

Один уровень абстракции из дизайна

Еще одно значительное различие между менеджером и дизайнером заключается в том, что менеджер – это не дизайнер!

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

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

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

ПРАГМАТИЗМ И СИНТЕЗ или ИДЕАЛИЗМ И ЧИСТОТА

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

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

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

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

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

Но меня шокировал мой ответ.

Правда в том, что UX – это роль для идеалистов, пуристов, искателей и революционеров. Таким людям сложно идти на компромисс.

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

Развивая эту мысль дальше, Мэтт Лемей подчеркивает: «Идея о том, что вам придется отказываться от чистоты одной точки зрения, уметь синтезировать и идти на компромисс, очень важна, но недостаточно обсуждается», – и я думаю, что он прав.

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

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

► СВЕРХСПОСОБНОСТИ UX-ПРАКТИКОВ

СИНТЕЗ

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

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

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

Повседневные задачи отличаются

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

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

Гистограмма навыков UX и ПМ

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

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

• Брендинг

• Создание UI-системы

• Фронтенд-разработка

• Звук и движение

• Визуальный дизайн

• Дизайн диалогов

• Создание прототипов

• Командная критика и итерации

• Дизайн взаимодействия

• Быстрое макетирование (вайрфрейминг)

• Написание UX-текстов

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

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

• Контент-стратегия

• Сервисный дизайн

• Коллективный дизайн

• Рисование эскизов

• Информационная архитектура

• UX-стратегия

• Персонажи и пути пользователей

• Исследование пользователей

• Обобщение результатов исследований

• Управление ожиданиями заказчика

• Концептуальное моделирование

• Юзабилити-тестирование

UX-гистограмма

Теперь оцените себя по каждому навыку или области знаний. Достаточно дать оценку на глаз, а для упрощения задачи используйте 9-балльную шкалу с интервалами: 1 – новичок, 3 – начинающий, 5 – компетентный, 7 – опытный, 9 – эксперт.

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

Навыки в управлении продуктом

Теперь давайте поговорим о навыках, которые относятся к управлению продуктом, но редко относятся к сфере ответственности UX-специалистов.

Рабочий список представлен ниже на рис. 3.4.

• Взаимодействие с клиентами

• Исследование рынка

• Анализ данных

• Планирование спринта

• Работа со списком задач

• Отслеживание ошибок

• Метрики Полярной звезды

• Критерии сдачи-приемки

• Пользовательские сценарии и эпики

• Составление дорожной карты

• Определение минимально жизнеспособного продукта (MVP)

• Определение приоритетов функций

• Моделирование доходов

• Гипотезы и эксперименты

• Управление рисками

• Архитектурная стратегия

• Соответствие продукта рынку

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

Полный список представлен на моей «полной» Product/UX-гистограмме (рис. 3.5).

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

Рис. 3.5. Вот моя самооценка. Другие вправе с ней не согласиться!

Гистограмма по управлению продуктом и UX

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

Рис. 3.6. Это моя гистограмма навыков по управлению продуктом

► ПОЧЕМУ ПОЛНАЯ ГИСТОГРАММА?

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

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

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

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

• Информационная архитектура

• Сильное увлечение клиентами

• Решение проблем с помощью итеративного дизайна

• Лидерство через влияние