Из техлида в менеджеры продукта: чем поможет бэкграунд разработки и стоит ли переходить именно вам

Меня зовут Марина Перескокова. Я проработала в Яндексе 10 лет, и из стажёра-разработчика выросла до руководителя службы разработки фронтенда. За это время получилось поработать над JS API Яндекс.Карт, поруководить фронтендом сервиса yandex.ru/maps и покодить движок для векторной карты на WebGL. По итогам моего тимлидства я написала книгу.

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

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

Эту статью мы писали совместно с проектом GetMentor. Это сообщество IT-наставников, готовых делиться знаниями и опытом. На сайте можно подобрать себе ментора, а в группе в Телеграме — почитать материалы от наставников. Мои там тоже есть.

Откуда переходят в продакт менеджеры и зачем

Согласно исследованию, с 2017 по 2019 год потребность рынка в продакт-менеджерах выросла на 32%, а в США работу продакта признали четвёртой среди наилучших — число вакансий за пять лет увеличилось вдвое. Индустрия всё больше и больше нуждается в тех, кто управляет продуктом.

Для продакт-менеджера важны такие качества, как предпринимательский дух, умение анализировать данные и понимание процессов и устройства IT-индустрии. Егор Данилов, Chief Product Officer Юлы, в одном из своих интервью говорил, что любит брать продактами бывших аналитиков. Они уже умеют в анализ, а значит, осталось найти аналитика с предпринимательским духом и вырастить из него продакта.

Кто идёт в управление продуктом? В 2019 году 427 продакт-менеджеров опросили, из какой сферы они перешли. Разброс большой, но лидеры есть. Чаще всего в продукт-менеджмент переходят из проджект-менеджмента, аналитики, маркетинга и, на четвёртом месте с 7% опрошенных, идёт разработка.

Действительно, почему бы программисту не стать продактом. Он точно знает про процессы внутри IT. У него, как и у аналитика, одно и то же фундаментальное техническое образование. Предпринимательский дух тоже есть — плох тот разработчик, который не хочет основать свой Facebook. Так что же его отделяет от продакта? Я составила список отличий в образе мыслей разработчика и продакта, которые у меня получилось заметить за время работы.

Чем отличаются образ мышления разработчика и продакта?

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

Всего таких отличий я насчитала семь.

Отличие первое

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

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

Отличие второе

Инженер думает, как решить задачу. Продакт в первую очередь задумывается, а нужна ли она вообще. Важное умение продакта — уметь отказываться от идеи.

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

Задача была нетривиальной, она потребовала много времени и рефакторинга. Спустя полгода разработки оказалось, что оба решения хороши. Одно в результате взяли в продакшн, а второе — заморозили.

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

Отличие третье

Инженер работает в привычных ему инструментах. Да, в современном мире мы постоянно переучиваемся, но когда вам прилетает очередная задача, вы идёте проторенным путём.

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

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

Отличие четвёртое

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

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

Отличие пятое

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

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

Отличие шестое

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

На одном собеседовании мне задали вопрос: у нас есть интернет-магазин, есть аналитика, как вы составите портрет пользователя? Если бы я была классическим программистом, я бы взяла логи аналитики, посидела несколько недель и постаралась бы выделить, какие есть пользовательские кластеры и что они покупают.

Человек, который работает продактом, думает так: “Если у меня обычный интернет-магазин и от других не отличается, то и портрет пользователя у нас с ними одинаковый. Поищу-ка я лучше открытую статистику с других площадок.”

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

Отличие седьмое

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

Продакт постоянно что-то придумывает и изучает, но почти ничего не делает сам. По завершении проекта роль продакта сильно размывается. Он сгенерировал идею, команда блестяще воплотила её в жизнь — и кто в итоге молодец?

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

В чем сильные стороны программиста, ставшего продактом

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

Суперсила №1

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

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

Считалось, что по статистике на такие объекты приходится большое количество кликов и логично было попробовать прокачать эту фичу дальше. Как зануда-программист по натуре, я начала проверять все статистические данные. Выяснилось, что в результате недопонимания количество кликов в реальности было на несколько порядков меньше, чем обозначено в задаче.

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

Суперсила №2

У вас строгое аналитическое мышление. Я не встречала рассеянных хороших программистов. Разработчики в целом довольно четкие ребята, и это сильно помогает.

Хороший продакт должен для каждого своего решения выстроить цепочку ответов на вопрос “зачем?”. Он знает, как его работа влияет на бизнес, и как каждая конкретная фича помогает бизнесу держаться на плаву, привлечь больше пользователей или заработать больше денег — в зависимости от модели развития.

Кажется что это просто и очевидно. Но когда вы работаете в большом долгосрочном проекте с участием сотни человек, смысловая связь между задачами сильно размывается. Где-то вы можете сделать неправильный вывод, а ваш мозг запомнит его как правильный и вы начнете с ним жить. Умение трезво оценить то, что вы делаете, заново отстроить цепочку “зачем?” и объяснить её команде очень ценно для продакта.

Суперсила №3

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

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

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

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

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

IT-наставники Онтико тоже участвуют в проекте GetMentor.

А 16 и 17 сентября в Санкт-Петербурге пройдёт конференция Saint TeamLead Conf 2021. Я там тоже буду — приходите пообщаться.