Георгий Овсянников

Product Manager, Glovo

20 апреля 2023

Как не провалить свой первый запуск в новой компании

image

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

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

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

Давайте начнём!

1. Определите ожидания от вашей роли

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

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

Пример из моего опыта: в одной из команд, к которой я присоединился несколько лет назад, постановкой проблем исторически занимались бизнес-стейкхолдеры, и от продакта в первую очередь ожидался проджект-менеджмент. Это несоответствие ожиданий систематически приводило к недостатку контекста и дублированию работы: стейкхолдеры формулировали свой запрос как «успеем ли мы сделать фичу X к дате Y?», и большой кусок продуктовой и бизнес-работы оставался для меня за кадром — это существенно замедлило мой онбординг и привело к нескольким продуктовым ошибкам, об одной из которых я расскажу в следующем пункте.

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

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

Пример из личного опыта: перед командой, к которой я присоединился, стояла задача — реализовать возможность со-финансирования нашей программы лояльности вместе с 3rd-party-спонсорами. Одним из важных решений на ранних этапах было использовать для со-финансирования пользовательские промокоды, т.к. этот формат подходил всем спонсорам вне зависимости от их сферы деятельности.

imageМеханизм действия: любая компания-спонсор может заплатить нам за промокоды, которые они потом распространят среди своей пользовательской базы.

Позже, более подробно изучив рынок, мы выяснили, что наиболее крупные внешние спонсоры в таких коллаборациях — платёжные системы (mastercard, visa), и для них формат промокодов не подходит, т.к. их бизнес-показатели завязаны на количество транзакций сделанных картой, выпущенной той или иной платёжной системой. Для этих компаний принципиально, чтобы их пользователи получали скидку только при оплате их картой.

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

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

3. Изучите North star метрики вашей и соседних продуктовых команд

Вне зависимости от того, какой фреймворк управления целями использует компания (OKRs, MBOs, и т. д.), важно получить представление об основных приоритетах продуктовых команд с которыми вы будете работать. В особенности нужно уделить внимание метрикам, между которыми возможны конфликты — так вы будете лучше понимать мотивацию разных команд и находить оптимальные пути разрешения этих конфликтов. Например, если вы занимаетесь монетизацией продукта через рекламу, ваши цели могут противоречить целям команды, занимающейся engagement. В этом случае, знания о том, как сравнивать метрики обеих команд между собой поможет эффективным эффективному принятию решений о trade-offs.

4. Определите состояние технической платформы

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

  • Сколько проектов (и какого размера) ваша команда способна закончить за месяц/квартал/семестр?
    Несмотря на то что любая оценка здесь будет приблизительной, крайне важно понимать, с учётом размера вашей команды, специфики продукта и состояния кодовой базы, насколько быстро вы можете двигаться. Выводы об этом можно частично сделать на основании проектов, которые ваша команда уже запустила, но также важно с самого начала тесно работать с командой над приблизительной временной оценкой проектов из бэклога.
  • Как распределена техническая ответственность между командами?
    В зависимости от того, как исторически был построен процесс разработки, в компании может существовать чёткое разделение кодовой базы между командами, либо каждая команда может быть способна разрабатывать продукт независимо. Это существенно влияет на работу продакт-менеджера, т.к. в первом случае вам и вашему тимлиду потребуется больше времени для устранения внешних зависимостей и приоритизации изменений в доменах других команд.
  • Насколько гибкие в компании процессы разрешения зависимостей?
    В предыдущем пункте вы узнали, насколько автономно ваша продуктовая команда может двигаться вперёд. В случае любых внешних зависимостей, продакт-менеджеру требуется знать, что от него требуется для устранения этих зависимостей и как много времени это займёт. Другими словами, что нужно сделать, чтобы другая продуктовая команда что-то сделала для вашей команды, и как часто есть возможность это осуществить. Это знание позитивно скажется на вашей способности управлять ожиданиями стейкхолдеров и приоритизировать проекты.
  • Функциональность и гибкость back-office инструментов
    Какие инструменты используются для A/B-тестирования? Можно ли запускать несколько A/B-тестов независимо? Как много времени требуется для анализа результатов A/B-теста? Можно ли запустить A/B-тест без привлечения разработки бэкенда?Ответы на эти вопросы могут драматически различаться в зависимости от состояния технической платформы (в некоторых компаниях результаты A/B-тестов считаются автоматически, в то время как в других это может занимать несколько недель времени аналитика).

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

Также из опыта: на ранних этапах моей работы в роли продакта, платформа для A/B-тестирования одной из компаний не позволяла запускать более одного A/B-теста в одном городе. Поскольку длительность некоторых тестов достигала 2-3 недель, бронировать запуск теста в крупном городе приходилось за месяц, и это существенно влияло на сроки запуска проектов.

Заключение

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

Присоединяйся к чату комьюнити

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

Заходи в чат