Личный опыт: из разработки в менеджмент продукта

Хочется сразу отметить, что это не инструкция по применению или неоспоримая истина, а лишь моя личная история карьерного поворота. Идея статьи появилась после общения с друзьями, которые хотят переходить в менеджеры продукта, и ребятами, с которых побеседовал в ivi. Конечно, есть полноценные образовательные программы в ВУЗах (например, программа в МАИ, где регулярно преподают сотрудники ivi). Но довольно часто в менеджеры продукта приходят не сразу после ВУЗа, а уже с опытом работы в какой-то другой профессии — именно так произошло со мной, и хочется поделиться этим опытом в надежде, что кому-нибудь он окажется полезен.

PS: это моя первая статья, прошу не судить строго за литературность повествования :D

Учился в НИУ ВШЭ на программе «Программная инженерия», закончил бакалавриат в 2015. Еще через 2 года закончил магистратуру там же, по направлению «Проектирование и разработка мобильных приложений». Ещё на третьем курсе бакалавриата, я устроился на стажера в Лабораторию Касперского и начал развиваться как разработчик. Здесь я отвечал за написание внутренних систем для работы с вредоносными файлами: допустим, есть вредоносные файлы – они могут лежать в архиве с паролем, который еще и подписан ключом шифрования — система должна все распаковать и выложить файлы в открытом виде для дальнейшего разбора вирусными аналитиками.

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

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

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

1. Внешние пользователи. То, что мы делали, использовалось лишь внутри компании. Удобно, что ты всегда мог подойти и узнать мнение коллег, которые пользуются твоим сервисом, все ли им удобно, но хотелось иметь существенно бóльшую аудиторию сервиса. Для меня было (и остается) важным делать вещи, которые помогают сотням тысяч и миллионам людей, а не десяткам.
2. Более широкое применение. Проекты, которыми я занимался в Касперском, были довольно ограничены в функционале: это либо утилиты для автоматизации (и тут чем менее заметно работает система — тем лучше), либо UI инструмент для аналитиков с выводом нужной информации о файле. Последнее — это очень ограниченный в своем функционале продукт, т.к. требований к нему было крайне мало, да и сложно было придумать что-то действительно полезное и нужное для него.
   
3. Возможность улучшать продукт на основе метрик. Здорово получать обратную связь от пользователей, но мне было интересно, насколько я делаю лучше или хуже для пользователей, внедряя какой-то функционал? А как это изменение сказывается на бизнесе и метриках? Да и сама возможность формулировать продуктовые метрики и следить за ними, иметь возможность улучшать их на основе данных (а не только заявок внутренних пользователей) тоже всегда выглядела привлекательно.
   
4. Дизайн. Мне всегда хотелось делать красивые и функциональные вещи, такие, которым было бы приятно пользоваться людям. Я пытался вносить изменения в UI инструмента для аналитиков, но на первое место всегда выходит функциональность и сроки, а не красота и изящество.
   

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

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

Первая мысль: Лаборатория Касперского — большая компания со множеством продуктов, да и есть открытые позиции, можно попробовать просто перейти в другой отдел. Следил за вакансиями, когда появилось что-то примерно подходящее моим интересам — сразу написал нанимающему менеджеру. Мои мечты остаться в Касперском в новой роли довольно быстро разбились о реальность: на тот момент в ЛК не готовы были выращивать менеджеров продукта, а искали сотрудников лишь с 6+ лет опыта в этой сфере.

Дальше ничего необычного — искал на HeadHunter подходящие вакансии, отправлял резюме, ждал, не получал приглашения. Пробовал и другой вариант — искал по конкретным компаниям, продукты которых мне нравились, и направлял резюме напрямую. Я пробовал искать и что-то около продукта, например — откликался на продуктового аналитика.

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

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

Свои проекты

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

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

Если у вас уже есть идея какого-то проекта – замечательно! Если нет – попробуйте подумать над какой-нибудь проблемой, которую сами хотели бы решить. Например, у меня была идея заменить бумажные карточки «10-я чашка кофе – в подарок» на электронную (карта для Apple Wallet). И я начал просто исследовать вопрос того, как это можно сделать и какие уже есть решения. Что в итоге я делал:

1. Исследования рынка и конкурентов. Не нужно специфичных знаний, чтобы найти какую-нибудь аналитику по объему рынка, найти конкурентов (то есть аналоги придуманного приложения/сервиса — в большинстве случаев, придуманное решение уже кем-то в каком-то виде реализовано), установить их приложения, потыкать и составить табличку с плюсами и минусами. Можно делать и более подробный анализ: например, составить список «фичей» и проверить как они реализованы у конкурентов, изучить ценообразование, посмотреть статистику использования. Тут вам помогут такие инструменты, как SimilarWeb для сайтов и App Annie для мобильных приложений.
2. Метрики и бизнес-план. Составить описание всех ключевых метрик проекта, модели монетизации, прогноза роста метрик — тоже не так уж сложно, с учетом того, сколько примеров и статей уже есть в интернете. Пускай придуманные показатели будут недостижимы, основаны на неточностях, но такое упражнение поможет на собеседованиях и при выполнении тестовых заданий. Вопрос про метрики весьма популярный, ведь менеджер продукта должен оперировать ими свободно и прекрасно понимать, зачем они нужны, как применять и как считать. Примеры продуктовых метрик можно посмотреть, например, здесь.
   
3. Интервью и опросы. Абсолютно никто не мешает сделать опрос в Google Forms по теме вашего проекта. Подумайте над тем, как можно выявить проблему, которую решает ваш продукт, как найти проблемные зоны («боли») пользователей, понять, что не нравится в текущих решениях конкурентов. Разошлите опрос коллегам, друзьям, попросите друзей разослать коллегам и друзьям — ответов 100-200 можно набрать без особого труда. А дальше — анализируйте ответы, находите подтверждения своих гипотез, находите новые идеи и проблемы пользователей, которые можете удовлетворить. А ещё возьмите друзей, коллег, знакомых — проведите интервью. Поспрашивайте о том, как они решают свои проблемы сейчас, об их опыте — в общем обо всем, о чем стоит спрашивать на глубинных интервью.
   
4. Прототипы. Необязательно уметь программировать, даже рисовать уметь необязательно. Сейчас можно создавать прототипы мобильных приложений уже из готовых компонентов, просто перетаскивая их мышкой на экране, а потом скачивать их на смартфон и смотреть, как они работают без единой строки кода. Пример такого инструмента — Proto.io.
   
5. Сбор и контроль метрик. Без технического бэкграунда, наверное, это будет сделать непросто, но поскольку я сам придумывал, что разработать и сам же разрабатывал, то решил попробовать и это. Любой продукт имеет аналитику — то есть сохраняет информацию о том, что видит и куда нажимает в приложении или на сайте пользователь. Первая задача для разработки — настроить отправку всех нужных событий в систему аналитики. Дальше уже менеджер продукта может сам разобраться с тем, какие метрики и воронки он может построить на основе собираемых данных. Для большинства несложных проектов достаточно использовать готовые решение типа Яндекс.Метрики или Firebase/Google Analytics — разработчикам их легко внедрить в приложение или сайт, а менеджеру — легко собрать нужные графики и таблицы для контроля метрик.
   

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

Курсы и тренинги

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

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

Пара слов про собеседования

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

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

Ещё пообщались про ivi – что я про знаю про сервис, пользовался ли, как пользовался. Здесь важно отметить: приходя на собеседование, ознакомьтесь с продуктом, над которым, возможно, предстоит работать! Сразу можете подумать над тем, что вам кажется неудобным и что можно было бы улучшить, зачем, и на что это повлияет. Подумайте над метриками, за которыми вы следили бы на месте менеджера продукта этого сервиса и которые вы считаете ключевыми именно для этого продукта. Это с одной стороны подготовит вас к потенциальным вопросам в стиле «а что бы вы изменили?», а с другой – покажет вашу заинтересованность в продукте и вакансии. Собственно, у меня тоже был как раз такой вопрос: какую бы фичу я предложил для ivi, зачем, и как бы я замерил успешность её внедрения. К сожалению, я пользовался на тот момент ivi всего раз, но не задумался обо всех вопросах, написанных выше, и пришлось импровизировать. И про метрики вопросы тоже были: какие продуктовые метрики я знаю и какие метрики применимы к ivi – за чем, по-моему, стоит следить?

Хочется добавить, что зачастую не бывает правильных ответов на вопросы (если это не из серии «как считать конверсию в покупку» или что такое LTV) и интервьюер смотрит на то, как ты рассуждаешь. Ко многим вопросам нет единственно верного ответа и важно продемонстрировать свой подход к решению вопроса. Так, например, на том же первом собеседовании мне рассказали, что ivi есть на Smart TV (а я на тот момент, в общем-то, не сталкивался со Smart TV, не говоря уже об ivi на этой платформе). Мы вышли из комнаты, в которой было собеседование, нашли в офисе ближайший телевизор Smart TV и включили ivi. В нем перешли в раздел «поиск» и меня спросили: что тут можно сделать лучше? На такой вопрос существует много правильных ответов, и можно придумать много гипотез по улучшениям. Здесь важно не впасть в ступор и не отвечать «не знаю, вроде бы тут и так все хорошо», а предложить хотя бы одну гипотезу и объяснить, как вы будете замерять успех реализации этой фичи – а именно на какую метрику вы повлияете.

Небольшое напутствие

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

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