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

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

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

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

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

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

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

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

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

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

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

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

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

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

Свои проекты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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