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

Приятного чтения!

Надеемся, что эта книга вам понравится. Мы понимаем, что она немаленькая, поэтому некоторые неактуальные для вас разделы можно пропустить. Вы всегда сможете вернуться к ним позже.

Не стесняйтесь, пишите нам по адресу gayleandjackie@careercup.com и следите за нами в интернете:

• twitter.com/jackiebo

• facebook.com/jackie.bavaro

• https://medium.com/@jackiebo

• twitter.com/gayle

• facebook.com/gayle

• https://medium.com/@gayle

Глава 2
Роль продакт-менеджера

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

Одни полагают, что это мини-версия гендиректора. Другие – что это специалист по работе с клиентами. Кто-то считает его неким звеном, объединяющим команду в единое целое. А кто-то видит в нем сходство с дирижером оркестра. Некоторым кажется, что это человек, отвечающий за стратегию, а кому-то – что он занят исследованием пользовательской аудитории и реализацией проектов.

Почему же ответов так много? Во-первых, роль PM сложна и многогранна. Во-вторых, он действительно имеет разные функции в зависимости от компании. Управление продуктом представляет собой некое заполнение пробелов – PM отвечает за то, что не закрывается функционалом других сотрудников. Некоторые PM работают с целой командой специально нанятых исследователей, аналитиков данных, маркетологов и копирайтеров, в то время как у других нет такой возможности (либо они имеют ограниченный доступ лишь к одному из этих ресурсов).

Вот наш ответ на вопрос, кто такой продакт-менеджер:

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

Он несет ответственность за итоговый результат всей работы над продуктом. Это чрезвычайно влиятельная позиция, потому что именно PM определяет, над чем конкретно будет работать команда разработчиков продукта.

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

Продуктовая триада

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

Обычно людей, которые составляют ядро продуктовой команды, в большинстве современных технологических компаний называют триадой. В нее входят инженер (или техлид^[9]), дизайнер и PM.

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

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

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

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

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

Жизненный цикл продукта

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

В реальной жизни эти этапы накладываются друг на друга, происходят не по порядку или повторяются снова и снова. У каждой компании своя версия порядка действий, но общая схема такова:^[10]

PM часто работают сразу в двух направлениях: над исследованием одного продукта и над запуском другого^[11]. За счет этого по завершении работы над текущим проектом инженеры могут сразу переходить к следующему, не дожидаясь, пока PM придумает, чем им заняться.

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

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

ИССЛЕДОВАНИЕ ПРОДУКТА

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

Что же пошло не так?

Вы пропустили этап исследования продукта (product discovery) и восприняли распоряжение вашего VP слишком буквально. Нужно было копнуть глубже и разобраться, какая проблема его заботила изначально.

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

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

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

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

Отличным примером такого провала стала война форматов видеозаписи VHS и Betamax в 1970-х годах. Качество изображения у Betamax было явно лучше, но оказалось, что клиентов больше заботила доступность и возможность записать на носитель двухчасовой фильм. Время записи у кассет Betamax ограничивалось всего одним часом. Более тщательная проработка исследования продукта могла бы направить Betamax в нужное русло.

Видеокассеты Betamax и VHS

К стандартным задачам на этапе исследования продукта относятся:

• Изучение запросов на добавление новых функций.

• Анализ показателей воронки продаж.

• Опрос клиентов.

• Тестирование идей.

• Обсуждение долгосрочной стратегии.

• Изучение конкурентов.

• Анализ рынка.

• Проведение мозговых штурмов.

• Запуск дизайн-спринтов (пятидневных сессий, во время которых прорабатываются идеи и тестируются прототипы продукта. – Примеч. ред.)^[12].

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

ОПРЕДЕЛЕНИЕ ПРОДУКТА

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

Что пошло не так?

А дело в том, что вы внесли недостаточно ясности на этапе определения (define phase). Вы не сопоставили масштабы проблемы и то, как должен выглядеть желаемый результат работы. Возможно, вы предположили, что в первом релизе вы решите только небольшую часть задач, но не объяснили это вашему дизайнеру.

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

К стандартным задачам на этапе определения продукта относятся:

• Приоритизация задач, поставленных на этапе исследования продукта.

• Выбор целевого клиента.

• Составление пути клиента (customer journey).

• Определение показателей успеха.

• Создание ви́дения продукта.

• Составление предварительной дорожной карты (roadmap).

• Определение первоначальных сроков.

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

ДИЗАЙН ПРОДУКТА

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

В данном сценарии вы не рассмотрели разные варианты решений и не протестировали бумажные прототипы на этапе дизайна (design phase).

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

К стандартным задачам на этапе дизайна относятся:

• Написание спецификации.

• Определение функционала.

• Согласование зависимостей с другими командами.

• Вайтбординг^[13] с дизайнерами и инженерами.

• Предоставление обратной связи по дизайну.

• Исследование юзабилити продукта.

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

РАЗРАБОТКА ПРОДУКТА

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

К стандартным задачам на этапе разработки относятся:

• Составление тикетов (запросов) на разработку.

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

• Расстановка приоритетов по исправлению багов.

• Регулярная помощь коллегам по команде в затруднительных ситуациях.

• Практическая проверка функций по мере их создания и предоставление обратной связи.

• Предоставление актуальной информации стейкхолдерам и руководству.

Чем внимательнее вы будете к своей команде, тем быстрее она сможет создать продукт.

ЗАПУСК ПРОДУКТА

Создание продукта завершается этапом запуска (delivery), на котором решение представляют пользователям. При этом в него могут вноситься изменения: некоторые незаметно, без лишней шумихи, из других делают целую рекламную кампанию для продвижения продукта.

Многое на этапе запуска может пойти не так. И именно PM должен проследить за тем, чтобы все прошло хорошо. Ведь вы не хотите в день запуска обнаружить, что продукт полон багов и выводит из строя серверы один за другим. Вряд ли службы продаж и поддержки будут рады изменениям, которые они не смогут объяснить клиентам. И маловероятно, что вам понравится перспектива отправки тысячам клиентов писем с просьбой загрузить приложение, которое еще не доступно в AppStore (Как? Оно же там было!).

К стандартным задачам на этапе запуска относятся:

• Выполнение этапа валидации: догфудинг^[14], бета-тестирование, A/B-тесты и тесты на устойчивость.

• Организация процесса обеспечения качества (quality assurance, QA).

• Работа с партнерами и проверка их готовности к запуску продукта (в том числе наличия всех разрешений).

• Сотрудничество с маркетологами по вопросам вывода продукта на рынок.

• Обучение менеджеров по продажам и сотрудников службы поддержки.

• Вечеринка с командой в честь успешного запуска.

Запуск продукта требует особой слаженности действий и снижения рисков до минимума. В основе любого успешного запуска лежит взаимодействие продуктового, инфраструктурного, маркетингового, производственного и множества других отделов.

АНАЛИЗ ПРОДУКТА

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

К стандартным задачам на этапе анализа (debrief) относятся:

• Ретроспективная оценка того, что было сделано правильно, а что нет.

• Анализ метрик запуска.

• Изучение отзывов клиентов о запуске.

• Определение очередности «мер быстрого реагирования» на основе обратной связи от клиентов.

• Оценка успешности запуска.

• Информирование всех сотрудников компании о результатах запуска.

• Составление плана дальнейших действий (следующей итерации).

Время и энергия, которые вы потратите на «разбор полетов», помогут вам вырасти как PM и укрепить свой авторитет.

ДРУГИЕ ВИДЫ ДЕЯТЕЛЬНОСТИ

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

С этой точки зрения перед PM встают следующие задачи:

• Подбор кандидатов на вакансии и проведение собеседований.

• Менторство других PM.

• Написание подробных отзывов о работе коллег.

• Участие в таких корпоративных процессах, как постановка целей и подготовка текущих отчетов.

• Обзор спецификаций других PM.

• Ответы на вопросы других команд.

• Презентация продуктов важным клиентам.

• Регулярные встречи с клиентами.

• Обмен полученным опытом.

• Участие в процессах в масштабах всей компании.

• Выступления на общих собраниях.

• Участие в обсуждениях стратегии.

• Участие в отраслевых конференциях.

• Отслеживание передового опыта в области продакт-менеджмента.

Как стать хорошим продакт-менеджером

Хорошие PM – это те, кто создает классные продукты. В начале карьеры вас могут хвалить за развитие навыков и проявление потенциала, но в конечном итоге ваш уровень будет измеряться эффективностью продуктов, которые вы создаете^[15].

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

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

На то, чтобы стать хорошим PM, могут уйти годы практики и опыта.

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

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

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

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

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

Вам придется взять на себя больше стратегических обязанностей. Это похоже на выбор между яблоками и апельсинами^[16] при прогнозировании развития фруктового рынка. Вы будете браться за несколько проектов одновременно, что вынудит вас идти на серьезные компромиссы (при этом угодить всем заинтересованным сторонам абсолютно невозможно). Все будут требовать от вас roadmap и стратегии. А когда вашу команду попросят взяться за какую-нибудь абсурдно амбициозную задачу, вы зададитесь единственным вопросом: «Где найти для всего этого время?»

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

Примерно тогда вы и почувствуете себя хорошим PM.

Вы сможете расслабиться и наслаждаться успехом или сделать еще один рывок к руководящей должности. Удачи!

Глава 3
Первые 90 дней

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

В первую неделю работы Клэр попросила инженеров из своей команды предоставить ей для ознакомления все, над чем они в тот момент работали. Она знала, что CEO^[17] беспокоится о качестве продукции, поэтому тщательно протестировала продукты, выявила десятки багов и внесла несколько предложений по улучшению юзабилити. «Отлично! – подумала она. – Я уже приношу пользу».

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

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

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

Упс. В своем рвении к успеху Клэр поддалась импульсивности, и все усилия первых 30 дней пошли насмарку. Но, к счастью, у нее осталось еще 60 дней, чтобы выправить ситуацию.

Она подошла к каждому из коллег и извинилась за то, что торопила события: «Приятно познакомиться. Мы можем начать заново? Расскажите мне немного о себе». Она поговорила со своей командой и узнала, чего от нее ждут. Она встретилась со своим руководителем и составила подробный список того, что нужно сделать, когда и с каким результатом. Затем она забила свой график встречами с клиентами, а в свободное время изучала документы по стратегии и панели мониторинга работы над проектом (дашборды).

Переключившись с режима «делай, делай, делай!» на режим обучения, Клэр смогла разобраться, что действительно нужно ее команде и как ей помочь. Коллеги перестали выражать недовольство – извинения всегда помогают, – и Клэр смогла вернуть доверие, которое потеряла.

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

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

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

Выделите время на то, чтобы заложить крепкий фундамент для дальнейшей работы в команде:

• Узнайте все о компании, вашей команде и принятых культурных нормах.

• Изучите информацию о продукте и о заказчиках.

• Выясните, чего от вас ожидают.

• Согласуйте свои планы и сроки онбординга (введения в должность) с руководителем и товарищами по команде.

• Сформируйте прочные отношения с коллегами.

• Заслужите доверие.

• Одержите несколько «быстрых побед».

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

ПРЕИМУЩЕСТВА НОВИЧКА

У новичка в команде есть огромные преимущества.

Во-первых, можно задавать много вопросов. Максимально используйте вопросы и фразы типа «Извините, я здесь новенький, не могли бы вы объяснить, что это значит?» или «Возможно, я не до конца понимаю ситуацию. Расскажите, пожалуйста, подробнее, почему мы делаем это именно так». Мы имеем в виду настоящие вопросы для получения конкретной информации. Но эта же техника отлично работает, чтобы выдвигать свои предложения уже в первые дни.

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

Конечно, у положения новичка есть и свои недостатки; у вас пока нет никакой репутации, и это серьезно осложняет вашу работу. Но не волнуйтесь – вы еще заслужите доверие коллег!

ПЛАН ОНБОРДИНГА НА 30/60/90 ДНЕЙ

В первую неделю или две целесообразно составить план онбординга на 90 дней и обсудить его со своим руководителем.

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

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

• Непосредственная команда: дизайнер, инженеры, специалисты по обработке данных и по исследованию пользовательской аудитории.

• Другие PM внутри команды.

• Менеджеры на уровне вашего руководителя.

• Ключевые стейкхолдеры.

• Коллеги из кросс-функциональных подразделений: продажи, маркетинг, производство, инфраструктура, контроль качества, развитие бизнеса, копирайтеры, юристы и т. д.

• Все, с кем полезно познакомиться.

Ниже представлен примерный план онбординга.

Первые 30 дней

HR и знакомство с компанией

• Заполнить документы по трудоустройству, пройти обязательное обучение и т. д.

• Изучить материалы о стратегии и ценностях компании.

PM и команда разработчиков

• Разобраться в процессах.

• Получить доступ к инструментам.

• Узнать о текущих планах и потребностях команды.

• Наблюдать за работой действующего PM.

Наблюдение за действиями своего ментора

• Сидеть с ним рядом.

• Присутствовать на его встречах.

• Следить за тем, как он ведет общение.

Знакомство с коллегами

• Разослать приветственное сообщение.

• Провести вводные встречи один на один.

• Проходить ежедневные пятиминутки с ментором.

• Еженедельно встречаться один на один с руководителем.

Повышение экспертности по продукту и работе с клиентами

• Участвовать в созвонах отдела продаж, выездных встречах и исследовательских сессиях.

• Читать или отвечать на обращения пользователей в службу поддержки.

• Использовать продукт, фиксировать первые впечатления, просмотреть руководство пользователя.

Планируемый результат

• Выполнить стартовый проект: запустить A/B-тест к третьей неделе.

Первые 60 дней

Команда разработчиков

• Взять на себя роль основного PM под контролем предыдущего.

Знакомство с коллегами

• Продолжать встречаться с коллегами.

Повышение экспертности по продукту и работе с клиентами

• Продолжать встречаться с клиентами.

Планируемый результат

• Проследить за намеченным на 10 сентября запуском.

• Создать новый квартальный roadmap для команды к 12 сентября.

Первые 90 дней

Команда разработчиков

• Осуществлять руководство командой без контроля со стороны предыдущего PM.

Повышение экспертности по продукту и работе с клиентами

• Продолжать встречаться с клиентами.

Планируемый результат

• Достичь поставленных перед командой OKR.

ВВОДНЫЕ СОВЕЩАНИЯ

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

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

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

Непосредственный руководитель

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

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

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

Примерный список вопросов руководителю:

• Каков ваш стиль работы?

• Какой вы видите нашу совместную работу?

• Как вы предпочитаете общаться: лично или письменно?

• Что вас больше всего раздражает? Что вы любите?

• Каковы ваши главные цели на этот год?

• Как я могу помочь в достижении этих целей?