Мы продолжаем нашу серию статей о ключевых качествах успешного менеджера по продукту. Мы уже успели пообщаться с Антоном Даниловым, Юрием Голиковым, Дмитрием Орловым и Алексеем Коротичем. Сегодня будем говорить с Александром Беляевым. Саша отвечает за один из наиболее масштабных аддонов — Wrike Resource.

— Привет, Саша. Скажи, сколько лет ты работаешь в Wrike и сколько всего лет занимаешься продакт-менеджментом?

— В Wrike я работаю 4,5 года, а насчет общего стажа — это спорный вопрос. Одна из начальных позиций в моей карьере называлась project manager, однако уже тогда я занимался запуском продукта.

Пожалуй, лишь в Wrike я могу точно сказать, что я — продакт: здесь набор полномочий, ресурсов, возможностей и формат работы именно такой, какой я себе представляю соответствующим позиции менеджера по продукту. А до этого, мне иногда кажется, что все было немного не так. Но это, скорее, мой критичный взгляд на начало карьеры: все же, это были разные этапы продактовской карьеры, которая идет с 2010 года.

— Раз уж мы заговорили о project-менеджерах и product-менеджерах, в чем состоит ключевое отличие между ролями и где они, наоборот, пересекаются?

— Скажем так, основная задача управления проектами — обеспечить желаемый результат в срок. Вообще, что такое проект? Это что-то, имеющее начало и конец. А продукт — это не проект.

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

— Я правильно понимаю, что управление проектом можно рассматривать как одну из составляющих управления продуктом?

— Да, я думаю, что это так. Но при этом я считаю, что это одна из самых легко отчуждаемых экспертиз. Функцию непосредственного управления проектом и контроля результатов может осуществлять сама девелопмент-команда, с которой ты работаешь. Этим также могут заниматься scrum-мастер, senior developer или тимлид. То есть просто заботиться о том, что сроки не нарушены и все находится под контролем — это, мне кажется, не великая задача. И я считаю, что менеджеру по продукту эту задачу стоит делегировать членам своей команды, которым он доверяет. А свое время стоит посвятить более высокоуровневым вещам и более широко смотреть на все, что происходит.

— Расскажи, пожалуйста, про опыт разработки и релиза аддона Wrike Resource, которым ты с командой занимался с его зарождения и работаешь над ним до сих пор. Какие главные вызовы стояли перед тобой и командой при работе над данным аддоном на различных стадиях?

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

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

Очень сложно было с “ресурс-менеджментом”, так как это работа над архитектурой нашего приложения, а она у нас достаточно сложная. Само управление проектами — дисциплина непростая, она руководствуется практиками из PMI Guidebook и PMBOK, так что соответствовать этому — задача нетривиальная. Поэтому даже просто понять, как в нашу систему вписывается понятие “task effort” или какие у него должны быть режимы, было очень сложно. Почти целый квартал на это потратили.

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

— То есть, после этого креативного этапа у команды уже есть понимание, каким образом это сделать, каковы примерные сроки и так далее?

— Появляются разные варианты, как поступать. Ты можешь запустить быструю бету. Или начать с определения всего скоупа того, что хочешь сделать за этот год, взять какую-то часть и сделать ее в первую очередь. Например, так мы поступили с datepicker’ом. Тогда мы запустили бету ресурс-менеджмента, в которой был datepicker и effort. То есть, мы просто выбрали что-то маленькое, что проще всего придумать и нарисовать и начали работать над ним.

— Скажи, пожалуйста, насколько, на твой взгляд, работа продакта в Wrike специфична?

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

— А теперь к нашей теме, проходящей через все последние интервью. Я общался с рядом людей, которые хотели к нам устроиться на позицию менеджера по продукту. И от всех я слышал два ключевых вопроса: “Какая требуется экспертиза?” и “Какими качествами необходимо обладать?”. Как я понимаю, вопрос экспертизы очень специфичен, так что давай сразу перейдем к качествам.

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

— На твой взгляд, можно ли стать эффективным продакт менеджером без бэкграунда в разработке и вообще в IT-компаниях? Может ли, допустим, прийти какой-то маркетолог или сейлз и стать продактом?

— Маркетолог и сейлз из IT — да, сможет. Если ты в IT не первый день, то многими навыками ты уже обладаешь. Если смотрел по сторонам, ты понимаешь, как это происходит, какие есть этапы: дизайн, ТЗ и так далее. Маркетолог и сейлз из другой сферы — считаю, что нет.
Если ты маркетолог или сейлз не из IT, то возникает вопрос: “Почему тебе вообще интересна эта сфера, но у тебя в ней нет опыта?”. Приходить в IT, при этом ничего не сделав технического — спорная история. Понимаешь, этот опыт не настолько сложно получить. Специалисту ничего не мешает собрать друзей, нанять фриланесров и, скажем, сделать приложение, руководя всеми процессами. А сделав его, ты уже немножко погрузишься в разработку и поймешь, как все работает. В противном случае возникает вопрос: “А действительно ли тебе интересно создавать продукты в IT?”

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

— Наверное, это доказательство того, что Product management — это не наука, а искусство.

— Наверно, ты прав, да.

— Это такая вечная штука в продуктовом менеджменте: очень сложно все классифицировать, выработать четкие подходы.

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

А в продакт-менеджменте все приходят сразу с совершенно разными подходами. Нет никаких четких инструментов. Есть некий набор фреймворков, но отношение к ним варьируется от любви до ненависти. Вот, в итоге и получается, что никто не может уверенно сказать, кто такой менеджер по продукту и что он умеет. При этом, мнения сходятся примерно на 66%, а оставшаяся треть — это то поле, где все может быть по-разному.

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

— Первое качество — это, своего рода, бизнес-сметливость, то есть понимание того, как работает бизнес, как в нем зарабатываются деньги, какие есть бизнес-модели. Это осознание того, что иногда можно сделать что-то дешевое и кривое, но деньги все равно заработать можно.

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

Это понимание принципа Парето (20% усилий дают 80% результата), как вообще зарабатываются деньги, решаются бизнес-задачи и достигаются результаты.

— Можно ли сказать, что эти качества косвенно являются производным от любознательности?

— Однозначно, да. Ты хочешь узнать, как все работает. И бизнес — это лишь одно из направлений, о котором ты узнаешь детали.

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

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

— Это важный вопрос. Вот, всё же, получают удовольствие или пользу?

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

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

И эти первые два качества должны уравновешивать друг друга. Если ты слишком много думаешь о бизнесе, ты можешь забыть о пользователях и все время останавливаться на уровне “это достаточно полезно, значит, купят”.

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

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

Для того, чтобы проводить эксперименты и формулировать гипотезы, разбивать roadmap, лежащий перед тобой, на итерации и понимать, какой оптимальный путь и какими шажками двигаться — для всего этого требуется системность и аналитичность мышления. И раз за разом тебе нужно задавать себе вопрос: «А правильно ли я мыслю? А верный ли этот вариант?», попытаться его опровергнуть, предложить что-то другое, либо остановиться на нем. Так что сюда же еще добавляем умение критически оценить как свою работу, так и команды.

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

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

— Хочу задать тебе еще один вопрос. Что бы ты посоветовал человеку, который хочет стать продакт-менеджером в Wrike? К чему готовиться и чего ожидать?

— Если опыта нет совсем — я бы посоветовал поработать продактом сначала где-нибудь еще. В Wrike очень высокие требования и быстрый ритм работы, и это не лучшее место для того, чтобы набираться стартового опыта.

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

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

— Понятно. Спасибо тебе огромное, на самом деле, очень интересно пообщаться.

— Не за что. Я рад какие-то вещи сформулировать и проговорить.