Technical Product Manager (технический менеджер продуктов) — это менеджер продуктов с хорошей технической подготовкой техническим, опытом в разработке, который больше работает с командой разработки и инженерами, а не бизнесом, продажами или маркетингом. Например, они могут заниматься развитием API продукта, оценивать разные технологии, на которых можно строить продукт, проводить конкурентный анализ с точки зрения технологий и внутреннего устройства продуктов.
Расскажу об этой роли подробнее на примере Riot Games. Когда компания только появилась, в ней была плоская, одномерная структура (это общая черта стартапов), а командам давали на откуп разные участки продукта. Наша команда занималась магазином в игре. Задачу нам поставили очень просто: «Сделайте так, чтобы в магазине все было хорошо».
У нас была вертикальная интеграция с frontend, middleware и backend, и мы все сделали сами. Но в какой-то момент поняли: если все команды будут бежать вперед независимо друг от друга, то возникнет диссонанс и проблемы с масштабированием. Одна команда не сможет на высоком уровне одновременно создавать UX/UI и бэкенд на 100 млн игроков.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Это привело нас к мысли, что должен быть какой-то общий технический фундамент, единый инструментарий для всех команд и отдельная команда технических менеджеров продуктов, которая его создает. Причем пользователями продуктов этой команды будут уже не игроки, а сотрудники Riot Games — например, инженеры, которые на базе единого программного интерфейса, API начнут создавать продукты и фичи.
Когда в Riot Games стали планомерно выстраивать эту единую техническую платформу (сейчас она называется Riot Platform), появилась целая группа Technical Product Manager. И отбирая людей в эту группу, надо выяснять, способен ли менеджер продуктов, который до этого создавал фичи, например, для магазина, так же эффективно работать в пространстве, где конечным пользователем будет технический специалист? Потому что технический менеджер продуктов должен уметь разговаривать с инженерами на одном языке и даже немного кодить.
Как выстраивать отношения с техническими специалистами
Главное в роли технического менеджера продуктов — не столько технологии, сколько умение правильно задавать вопросы команде и своему пользователю, вытаскивать наружу те вещи, о которых инженеры обычно не говорят, потому что «могут решить любую проблему». Нередко интервью с ними становится похоже на коучинг-сессию.
Почти у каждого инженера есть особый тип мышления, который мне очень нравится. На английском это звучит как «Don’t worry about it we’ll figure it out» («Не парьтесь, мы всё решим»). И вот это «мы всё решим» нам нередко вредит, потому что наша задача технических менеджеров продуктов как раз в том, чтобы облегчить жизнь инженерам и чтобы им не приходилось постоянно «всё решать». Мы понимаем: даже если инженерам неудобно, они что-нибудь придумают — однако нам важно, чтобы наш продукт действительно приносил им пользу и был удобным.
Как единая технологическая платформа связана с бизнесом
Основная причина появления технических менеджеров продуктов и внутреннего продукта в Riot Games — вера в то, что это принесет нам заветные 10x (отсылка к The 10X Rule: The Only Difference Between Success and Failure Book by Grant Cardone — прим.ред.). Мы стремимся сократить время разработки настолько, чтобы программист выпускал продукт в 10 раз быстрее.
У нас есть гипотеза: если мы запустим платформенные решения, которые смогут автоматически масштабироваться, инженеры будут быстрее выпускать новые игры и фичи. А значит, мы целимся в такую метрику, как время. При этом мы смотрим на него со стратегической точки зрения — для нас это в первую очередь time to market, время выхода на рынок.
Но одного времени мало: если мы сделали 10х, но потратили $10 млрд — это не очень хорошо. Поэтому появляется еще одна метрика — dimension cost или ограничение по стоимости продукта. Ограничения всегда полезны — с их помощью удобно определять, каким должно быть конечное решение. Кроме того, мы постоянно следим за метриками качества (счастья) — например, стандартным Net Promoter Score: «Эй, инженер, тебе понравилось работать с нашим API? Оцени от 0 до 10, пожалуйста».
Такие метрики хорошо работают, если замерять их регулярно, а стейкхолдеры понимают, как их интерпретировать. Например, если они показатели NPS низкие, это не означает, что надо всех уволить прямо сейчас. Такие показатели просто говорят о наличии проблемы — а вот если она не уходит через год, тогда, думаю, уже можно всех уволить.
Особенность технического менеджмента продуктов в том, что когда мы смотрим на пользователя-инженера, у нас появляется необходимость работать с особыми характеристиками, которых нет у других категорий пользователей. Часть из них можно описать одним словом — developer experience (DX), и мы хотим, чтобы DX у наших разработчиков был хорошим.
Только после этого идут бизнес-метрики, которые говорят нам: если инженеры проектируют определенную фичу, то мы можем предположить, что время разработки сократится на полтора года — и мы должны обосновать свои предположения, доказать, что это не просто наше предположение в стиле «вроде как-то так работает». Сейчас нашему продукту уже почти 2,5 года — он доказал свою полезность в боях. Слева от моего рабочего места стоит инфомонитор, и он показывает что к нашему продукту приходит 300 тысяч запросов в минуту.
Почему технические менеджеры продуктов часто остаются незамеченными и как это исправить
Особенность технических менеджеров продуктов в том, что на этой роли твои заслуги не всегда могут оценить по достоинству. Стейкхолдерам — президентам, вице-президентам — проще соотносить себя с конечной аудиторией (в нашем случае — игроками), а не с инженерами и их нуждами.
Мы участвовали в создании многих крупных фич в игре «League of Legends» — например, «Hextech crafting». И помню, я переживал, что нашу команду могут даже не упомянуть, хотя мы запилили практически весь монетизационный «фундамент» этой фичи. Переживал я зря — в Riot всегда умели поблагодарить и отметить весь стек, всех участников процесса. Тем не менее, во многих компаниях это на самом деле большая проблема. Технический менеджер продуктов, особенно если он не упрощает свою работу до такого объяснения, которое способны переварить руководители уровня CEO, может попасть в ситуацию, когда и он сам, и команда делают очень много, но рассказать об этом как будто и нечего: «Ну да, была там какая-то технология. Окей».
Поэтому еще одна важная черта работы технического менеджера продуктов — умение постоянно доносить свою пользу для компании через обобщение и упрощение, умение создать понятную для простых людей коммуникацию: «Ребята, мы сделали такую-то платформу, чтобы вы могли запустить „Hextech crafting” и у игрока при этом ничего не упало». Как только вы наводите такие мосты, стейкхолдеры— а они все-таки люди совсем не глупые — начинают понимать: «Подождите, так вот же та самая понятная ассоциативная цепочка, которая помогает мне понять, что именно эти люди делают».
И именно у нас в Riot я наблюдаю эволюцию стейкхолдеров — они уже давно начали переходить от обычной признательности техническим менеджерам продуктов к пониманию нашего deliver player value (вклада в ценность продуктов для игроков). Конечно, в определенной степени нам необходимо признание, но ведь важнее устойчивая ценность для игроков или даже ее увеличение.
Вспомним инфомонитор. Если с показателями на нем что-то не так, все сразу это видят — о, проблемы. А когда все отлично, мониторы показывают нам зеленые дашборды, никто этого даже не замечает. И с этим, с одной стороны, придется смириться, а с другой — бороться. Я регулярно прилагаю усилия, чтобы по окончании спринта можно было свои результаты соединить с результатами других команд, выпускать апдейты, рассказывать о них, появляться во внутренних новостных лентах и т.д.
Также я стремлюсь сделать более простой и наглядной визуализацию состояния нашей платформы — чтобы любой сотрудник, проходя мимо инфомонитора, мог понять, что происходит. Например, есть монитор, который показывает метрику доступности платформы. Мы могли бы вывести на него непонятные цифры — 99% или 999 — но их значения никто не знает, а мы хотим, чтобы нас понимали и ценили. Поэтому для стейкхолдеров мы сделали «обобщенный» монитор, на котором написано «стабильность», и договорились, что нормальный показатель стабильности — 99,95%. Вторая метрика, которую мы выводим на монитор — performance. Она показывает, как быстро проходят транзакции виртуальной покупки — по стандарту это должно занимать не больше секунды. И такие наглядные метрики на самом деле помогают найти общий язык с топ-менеджерами и показать им важность нашей работы.
Как взаимодействовать с топ-менеджерами
Технический менеджер продуктов должен понимать своих потребителей. Правда, есть нюанс: потребители для него — это те самые стейкхолдеры, которые дают ресурсы и «покупают» созданный им сервис. И надо сразу свыкнуться с мыслью, что придется постоянно разжевывать все сложные технические объяснения, переводить их на язык, понятный стейкхолдерам. Иначе, если у руководства нет технического бэкграунда, коммуникации окажутся сломанными и будут возникать не очень приятные ситуации.
Эту способность выстраивать правильную коммуникацию мы называем attribution to success (атрибуция успеха). С одной стороны, компания стремится жить так, чтобы мотивировать людей работать хорошо. Это вызывает необходимость выделять успехи и работать над слабыми сторонами или неудачами, если они есть — поэтому нельзя похвалить всех и сразу. Должна быть дифференциация.
В реальной работе моя команда и другие подобные структуры часто оказываются частью чего-то более крупного, что мы называем Scrum-of-Scrums, то есть команда команд. Такая сверхкоманда реализует какое-то сложное большое решение и без объединения в команду команд такое решение не сделать. Усилий отдельных команд не хватит, потому что надо сразу учесть все возможные межкомандные зависимости. Только так можно сделать «startup spirit» — то есть в кратчайшие сроки выкатить новый проект. И у нас в Riot технические менеджеры продуктов обязательно участвуют Scrum-of-Scrums. В этой команде команд обычно существуют некие рабочие соглашения – как часто мы встречаемся, как координируемся, как отмечаем успех, что будет происходить.
И очень приятно, когда после завершения работы над межкомандными проектами лидеры компании, выходя на сцену, не просто формально говорят: «Спасибо всем, включая этих ребят», — а обозначают, за что именно спасибо, в чем заслуга нашей группы и как она влияет на весь продукт и пользователей. Например, Джей Капур, который отвечает за Riot Player Platform, вышел на сцену и сказал: «Ребята, в этой игре очень много разных классных фич, но подумайте вот о чем. Когда пользователь логинится, он может воспользоваться или не воспользоваться какой-то фичей, тем же магазином. Но каждый игрок логинится — а это заслуга команды технических менеджеров продуктов. Они создали эту систем». Это было мощно!
На мой взгляд, стейкхолдеры должны отмечать такие вещи. Особенно это касается роли технических менеджеров продуктов — топ-менеджеры должны всегда задавать себе вопрос: «А есть ли у нас сейчас unsung heroes (невоспетые герои), которых надо упомянуть?». Ведь если они будут признавать их заслуги, это создаст более привлекательную среду, в которую потянутся люди.
