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

Менеджером по продуктам середины 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-х («доткомы»), имели общего предка.