В первой части я рассказывала о том, почему перешла из техлида в продакт-менеджеры, чем мышление продакта отличается от образа мыслей разработчика. И какие у продакта с техническим бекграундом есть сильные стороны.
Сегодня, как и обещала, расскажу про сложности, с которыми я столкнулась за год работы продактом и которые совсем не предвидела, соглашаясь на новую роль.
Смена окружения
Я люблю тусовки разработчиков, мне нравятся code review, локальные мемы. Я привыкла работать с программистами и перестала замечать, насколько это прекрасная среда.
У продакта окружение меняется. Вы, конечно, много общаетесь с разработкой, но ещё вам нужно выявлять инсайты с пользователями, кооперироваться с отделом маркетинга, синхронизироваться с другими менеджерами. Обстановка меняется, и дистиллированный за много лет гик-программист немного разбавляется. К этому нужно быть готовым.
Признание. Мне тяжело давались конфликтные переговоры. До этого я общалась лишь с дружелюбными коллегами-разработчиками, а потом мне пришлось доказывать свою точку зрения руководителям соседних отделов, у которых в подчинении по 200 человек, что для меня большой стресс.
Но ничего — начинаешь копать, спрашивать советы у людей, читать книги. Мне помогли классные книги Игоря Рызова: «Переговоры с монстрами» и «Кремлевская школа переговоров».
Работа с хейтом и недоверием
Когда вы пишете код, вы проходите code review, получаете оценку от начальника и коллег — то есть, получаете конструктивную критику. Все оценивающие разбираются в том, что вы делаете — сложно представить, что вас будет критиковать некомпетентный человек.
Продакта может обидеть каждый. Особенно, когда он делает продукт для всех — не b2b со своими законами, а всем понятный b2c. Любой человек в компании может прийти к вам и сказать, что вы всё испортили.
Предупрежу: от этого никуда не деться. Всегда найдутся люди, которым понравится ваша работа, и те, кто вас осудит. И чем масштабнее изменения, тем больше хейта и недоверия вы будете вызывать. С этим придётся жить.
Сложно понять сильные стороны коллег
Со специалистами, дизайнерами и разработчиками легко понять, кто на что способен. Вы сразу видите, какого качества код пишет человек вашего уровня, выделяете плюсы и минусы. Ваш начальник обычно компетентнее вас. Вы знаете, что к нему можно прийти со сложной задачей и получить толковый совет.
Но когда вы начинаете работать продакт-менеджером, ситуация меняется. Вы часто обсуждаете с другими менеджерами потенциал той или иной идеи. И в этот момент сложно понять, к чьему мнению нужно прислушаться, а какое можно просто принять к сведению. Потому что никто зачастую не знает, какая именно идея выстрелит — надо просто пробовать. И так уж устроены продакт-менеджеры, что даже если у них нет опыта и конкретного ответа на твой вопрос, они все равно будут стараться изобрести ответ — считайте это профессиональной деформацией. Со временем вы начинаете понимать, кто из коллег в каких вопросах дает наиболее ценные советы, но на первых порах приходится работать с очень противоречивыми рекомендациями.
Известный американский предприниматель и миллиардер Рей Далио в своей книге «Принципы» пишет, что завел в компании систему бейсбольных карточек. На каждого сотрудника заполнена форма, в которой расписаны его сильные и слабые стороны. Кто-то хорош в коммуникации, но плох в тайм-менеджменте, кто-то ас в запуске новых гипотез, но плох в их реализации.
И когда ты идешь к человеку за советом, ты можешь изучить, в чем он компетентен, а с чем к нему идти не стоит. Отличная система, но у нас её нет. Приходится самому методом проб и ошибок калиброваться — чьи советы слушать, а чьи — слушать и делать наоборот.
Сложно наслаждаться процессом
Каждый день ты проверяешь гипотезы, и только одна из десяти выстреливает. До этого момента твоё копание в неизвестных механизмах приносит только боль. Как если бы ты был главным в походе и вдруг потерял карту. Время идёт, команда стоит, все ждут, когда же ты укажешь направления, а ты не имеешь ни малейшего понятия, куда идти.
Тут стоит перестроить свою жизнь и находить радость где-то помимо работы. В плохие дни я шла в кафе и брала свое любимое пирожное. Это была простая дофаминовая плюшка за все страдания на рабочем месте.
Чтобы справляться со стрессом, придётся изменить свою призму восприятия. Иначе будет больно. Особенно людям с синдромом отличника, которые не привыкли ошибаться.
Ошибки не страшны — они двигают человечество вперед. Это описано во многих книгах. Об этом пишет Нассим Талеб в «Антихрупкости», канадский психолог Джордан Питерсон тоже часто об этом говорит. Вы знаете достаточно биографий художников, музыкантов, предпринимателей — рисковых ребят, без которых не было бы Netflix, Boring Company, пиксаровской «Души». Нужно найти людей, которые живут похожей жизнью, и увидеть, что ошибаться — нормально.
Результат важнее приложенных сил
Это справедливо для всех, но для программиста — в меньшей степени. Главная проблема разработчика — дедлайн. Когда трубы горят, разработчик может погасить пожар временем: где-то не поспать и поработать ночью, где-то взять сверхурочный. Но чем больше вы пишете, тем сильнее становитесь, как специалист, и тем дальше продвигаетесь.
У продакта проблема встаёт гораздо острее. Вы полгода потратили на разработку фичи, вовлекли и свою команду, и смежные отделы, и все работали на износ, чтобы выдать всё в срок — а результат пшик. Это ничем не исправишь — это провал.
Другое дело, когда вы продумали небольшое изменение, которое можно быстро реализовать с минимумом ресурсов, но оно ключевым образом повлияет на ваши бизнес-показатели. Тут вы молодец.
Продакт-менеджеров оценивают именно по результату. Совершенно неважно, сколько усилий вы вложили. Скорее, наоборот: чем больше, тем хуже. Больше всего в колхозе пахала лошадь, но председателем так и не стала — это иллюстрирует жизнь продакта.
Данные решают не всё
Я люблю анализировать данные, выстраивать закономерности, искать причинно-следственные связи. Поэтому, когда я начала работать продактом, я обещала себе, что не буду тем продактом, который заставляет команду что-то делать без аргументов на руках. Я обложусь метрикой, аргументирую десятое “зачем”, всё будет доказано.
На деле всё выходит иначе. Иногда просто ковыряешь продукт в поиске нужных метрик и понимаешь, что нет ничего, достойного твоего внимания — все слишком шумно или непонятно. Но двигаться куда-то надо. В таком случае приходится принимать хоть какое-то решение, даже если не можешь его доказать и придется разбираться на ходу. Наберитесь мужества — если пойдете не по тому пути, придется брать ответственность за провал.
Теперь вопрос: если все так сложно, зачем туда идти? Можно оставаться техлидом, руководить разработкой и жить счастливо. Мой ответ: работа продакта — это самая творческая работа, которую мне доводилось делать. Ты создаешь что-то из ничего, из непонятных источников данных собираешь реально применимую гипотезу, постоянно ищешь нестандартные решения. С одной стороны — ты почти всегда вне зоны комфорта, а с другой — это чистое творчество.
Еще у меня поменялся масштаб видения. Как-то я расписывала задачи на полгода и вдруг представила, сколько разработчиков будут заняты воплощением моих идей, если мне удастся их защитить. С одной стороны — я влияю на множество людей. С другой стороны — имею ли я право завалить их работой? Но, в целом, это скорее вдохновляет, нежели пугает.
Как совершить переход — для тех, кто заинтересовался
Когда меня спрашивают, как перейти из разработки в продакт-менеджмент, я обычно предлагаю вот такие шаги:
1. Будьте ближе к продукту. Если вы работаете в команде, занятой техническими задачами наподобие налаживания инфраструктуры, вы не пересекаетесь с продакт-менеджерами и бизнес-аналитикой и не совсем понимаете, что происходит по ту сторону баррикад. Поэтому, если вы серьезно хотите стать продактом, смените команду. Лучше возьмите команду поменьше, которая очень тесно общается с продакт-менеджером. У вас появится возможность общаться с ним и напитываться новыми знаниями.
2. Начните интересоваться бизнесом и аналитикой. До этого вы думали только про технические решения, теперь попробуйте освоить новую область. Почитайте отчеты вашей компании, сходите на встречи по продукту (они, как правило, открытые). Просто спрашивайте у людей, принимающих бизнес-решения, что происходит. Начинайте быть в курсе.
3. Найдите в вашей компании крутого продакта и учитесь. Анализируйте его поступки: что он делает, почему он принимает те или иные решения. Если есть возможность, посмотрите, к чему привели его решения, от чего он отталкивался и к чему он пришел. Постарайтесь не учиться у плохих продактов, потому что переучиваться будет тяжело.
Если в вашей компании мало продакт-менеджеров или так исторически сложилось, что вы не можете у них учиться, можно поискать ментора в другом месте, например в открытом сообществе IT-наставников GetMentor.dev. Многие крутые наставники готовы консультировать, много людей готовы делать это бесплатно, на голом энтузиазме. Для поиска "своего" ментора можно почитать описания участников на сайте или подписаться на телеграм-канал сообщества — ребята публикуют полезные материалы от менторов и короткие интервью.
4. Качайте работу с данными — математическую статистику, запросы в базу данных. Встряхните эти знания в себе, ибо они непосредственно нужны для работы продакта.
5. Если вы работаете в близкой к продукту команде, вы можете поучаствовать в продуктовой рутине. Ходите на UX-исследования, попроситесь на парочку CustDev’ов. Необязательно ходить на каждое — сходите на несколько. Вы уже будете потихоньку вовлекаться — наблюдать, как люди общаются с пользователями, как спрашивают про их боли. В будущем вам это пригодится.
6. Поищите внутри компании или за её пределами проекты, требующие продакта-технаря. Я уже приводила в пример менеджеров для ML-продуктов — на вакансии, связанные с машинными обучением, обычно ищут продакта, который хорошо разбирается именно в этом. Потому что другой не разберётся с техническими нюансами. Вас могут рассмотреть на эту роль, даже если у вас мало опыта в менеджменте, но вы разбираетесь в технологиях. А вот на роль продакта-визионера, который должен считывать эмоции пользователя и представлять вау-дизайны, будет сложнее пробиться, просто потому что у вас нет релевантного опыта, а технические знания здесь отходят на второй план.
7. Попросите не очень рисковую задачу «на пробу». Например, моим первым чисто продуктовым проектом был Viber-бот для Яндекс.Карт. Мы на тот момент понимали, что этот продукт вряд ли будет очень массовым, и если бы я даже с треском провалила эту задачу, компания от этого ничего не потеряла бы. У меня была возможность потренироваться на котиках: сделать этого бота, посмотреть на процесс, а у моего руководства — возможность оценить меня в новой роли.
Заключение
Переход в продакты — не билет в один конец. У вас всегда есть возможность снова вернуться в разработку. За год или полтора ваши скиллы никуда не денутся. К примеру, у меня есть знакомый СTO, который периодически меняет роли. Когда настроит разработку, начинает заниматься продакт-менеджментом, когда разлаживаются процессы — возвращается.
Вы можете побыть продактом год или два, а не понравится — вернуться. Это не проблема. Как минимум, у вас появится другая грань профессиональных умений и другая точка зрения на процессы.
16 и 17 сентября в Санкт-Петербурге пройдёт конференция Saint TeamLead Conf 2021. Я там тоже буду — приходите пообщаться.
