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

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

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

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

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

Итак, начнем. Нашего первого гостя зовут Антон Данилов. Антон — Group Product Manager в Wrike, руководит направлением Enterprise. В прошлом Антон отвечал за инфраструктуру онлайн-продаж в Лаборатории Касперского, а до этого работал в Microsoft и Sun Microsystems. Общий стаж в продакт менеджменте – больше 10 лет.

– Привет, Антон.

– Привет, Артем. Спасибо, что позвал пообщаться.

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

– Ну, во-первых стоит сказать, что судя по вопросам, человек только начинает свой путь в управлении продуктом.

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

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

– Давай не будем привязываться к количеству, а в конце разговора посчитаем?

– Хорошо. Первое, наверное, самое важное – я бы его назвал “чувство продукта”. Я сейчас объясню.
Что такое чувство продукта? Это, можно сказать, профессиональное искажение, когда все вокруг воспринимается как продукт. Вообще всё. Даже если это продукт природы, это результат какой-то деятельности, каких-то процессов.

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

Тут мы подкрадываемся к глобальным вещам – в частности, к умению отличать хорошее от плохого. По большому счету, это называется чувством вкуса.
Когда я говорил про то, что ты смотришь на все как на продукты, то видишь их различия. Что, в свою очередь, означает, что какие-то из них по некоторым шкалам лучше, какие-то хуже. Менеджер по продукту понимает, что продукты сделаны для чего-то, у них есть какой-то смысл, какая-то цель.

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

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

– Совершенно верно.

– Соответственно, если ты ему предлагаешь любое решение для появления дырки в земле, ты решаешь его проблему?

– Более того, в размышлении Питера Друкера можно было бы сделать еще один шаг вперед. Хороший менеджер по продукту спросил бы: «Зачем вам дырка в земле? Вам нефть нужна? А, на самом деле, в конечном итоге, вам нужна не нефть. Вам нужна прибыль, которую вы получите, когда продадите ее.” Вот это пример того, как можно мыслить. Этот пример очень хороший. Человек в своем рассуждении сделал один шаг. Можно сделать еще два.

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

Когда к тебе человек приходит и говорит: «Мне нужно бурильную установку», вот это сразу означает, что пользователь пришел к тебе с решением. А ты ему говоришь: «Так, так, подожди секунду. А что мы хотим сделать?». И правильный разговор должен дойти до того, что менеджер по продукту скажет: «А! Я понял, вы хотите заработать денег вот в этом конкретном месте на добыче нефти. ОК». И мы, может быть, в итоге придем и к бурильной установке (а может быть, и нет), но уже очень много будем знать про эту бурильную установку, мы дадим именно ту самую правильную бурильную установку, нужную по мощности, по надежности, по еще каким-то параметрам, а, возможно, решение будет заключаться не в покупке установки, а в чем-то другом, но проблема пользователя будет решена. Я не специалист в добыче нефти, но это довольно очевидно.

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

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

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

– Я правильно понимаю, что менеджер по продукту, прежде чем команда примется за работу, должен “продать” ей идею продукта?

– Это упрощение, но да. Он должен уметь работать с командой таким образом, чтобы команде захотелось это делать. Он должен уметь работать так, чтобы замотивировать команду на самое лучшее, что коллектив может сделать.

– Понятно

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

– Еще раз уточняю: ты сказал, что менеджер по продукту – это не тот человек, который сидит и пишет код.

– Абсолютно не тот.

– А значит ли это, что теоретически менеджер по продукту может не иметь технического бэкграунда? И прийти, к примеру, из продаж?

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

Бывают случаи, когда в скоуп менеджера по продукту входят глубокие интеграции или какие-то другие сложные штуки. Когда проектируется технически сложное решение, конечно, будет трудно без понимания, на каком языке разговаривают девелоперы. В таких случаях технический бэкграунд желателен, но я бы не сказал, что он является одним из ключевых. Я абсолютно уверен, что можно быть продакт-менеджером, не понимая ничего в технической составляющей. Очень часто, несмотря на то, что у меня образование в области прикладной математики, я говорю своей команде: «Слушайте, я в этом не разбираюсь. Расскажите мне, как работает». Команда отвечает: «Тут надо компонент написать». Я спрашиваю: «Что это значит?». И так далее.

– То есть это нормальные вопросы? Задавая их, ты не выглядишь глупо?

– Подобные вопросы во многом даже могут сблизить PM’a с командой, потому что ты строишь коммуникацию таким образом: «Я специалист в своей области, а вы специалисты в своих областях. Давайте объединим наши профессиональные навыки, чтобы достичь общей цели». Разработчики остаются экспертами в своей сфере, пиэм — в своей. Это то, что касается именно лидерского компонента. Но это не все.

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

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

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

Наверное, третьим навыком я бы выделил то, что называется execution. Когда продукт запланирован совместно с командой, менеджер продукта должен приложить организационные усилия, чтобы релиз состоялся. Важный фактор – понимание того, как декомпозировать продукт на фрагменты. Его можно разбить так, что он будет в разработке два года, а, в конце концов, окажется никому не нужен. А можно разбить так, чтобы он сразу начал приносить ценность. PM должен понимать, где и каким образом продукт будет выпускаться, для каких клиентов, где и какие риски у этой системы, каким образом эту разработку побить на фрагменты. И, наконец, как декомпозиция будет выглядеть на уровне scrum/agile. Здесь, как ты понимаешь, мы говорим о реалиях продуктовой организации.

Это тактическая вещь, но, по сути, умение сделать так, чтобы ты дошел от идеи до реализации и измерения результатов, умение пронести с собой огонь целиком через весь этот путь, не потеряв его. Это не спринт, это марафон, и продакт должен уметь пробегать этот марафон.
С другой стороны, у начинающих продакт-менеджеров часто встречается стремление сделать решение идеальным и не выпускать его “раньше времени”. Есть опасение, что результат будет “не очень”, и, не имея большого авторитета, продакт получит невысокую оценку своей деятельности. А на самом деле, это взгляд скорее с уровня команды. На уровне стейкходеров быстро доставленная ценность, проверенная и подтвержденная или опровергнутая гипотеза и продуманные последующие итерации гораздо ценнее, чем идеально выпущенный продукт, в котором много-много-много фич, но который делался очень долго.

– Например, готовится аддон, и потенциально у этого аддона для клиентов будет очень большая ценность. При этом он еще сыроват, но кто-то готов купить уже и в текущей итерации. На твой взгляд, лучше скорее выпустить и потом разбираться с последствиями или определить какой-то, так сказать, good is good enough уровень и не торопиться?

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

У нас в Wrike существует целый цикл релиза крупной функциональности. Есть внутренняя бета – это когда мы готовы открывать функциональность только для внутренних пользователей. У нас есть закрытая бета, когда мы приглашаем некоторых выбранных клиентов и включаем им новые возможности. Клиенты дают нам первый фидбэк, и ценность уже начинает предоставляться.

Затем мы выпускаем разработку в Labs, когда мы включаем функциональность лояльным клиентам, которые согласны дать свою оценку и фидбек. Потом – публичный релиз. Дальше — стадия улучшений и итерирования. Не все релизы проходят через каждый из этапов пути, но полный цикл выглядит так. Он предназначен именно для того, чтобы мы приносили ценность клиентам как можно быстрее, но при этом постепенно наращивали эту ценность, и собирали по дороге фидбек, делая продукт все лучше и лучше. В этом заключается итеративный подход к разработке с быстро доставленной ценностью.

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