Читать книгу: «Управление продуктом для UX-специалистов. От дизайна интерфейсов к успешному развитию в мире продуктов», страница 2

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

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

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

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

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

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

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

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

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

Менеджер продукта как бизнес-менеджер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Менеджер продукта как менеджер по маркетингу

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

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

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

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

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

Менеджер продукта и технический менеджер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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