Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании
- -
- 100%
- +
Обычно людей, которые составляют ядро продуктовой команды, в большинстве современных технологических компаний называют триадой. В нее входят инженер (или техлид[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 дней и обсудить его со своим руководителем.
План не обязательно должен быть сложным – просто любому новичку полезно иметь перед глазами зафиксированный на бумаге список задач. Именно на начальном этапе, как правило, возникает недопонимание и рассогласованность действий. Без письменного плана вы будете чувствовать себя неуверенно, пытаясь нарастить темп, а руководителю при этом может показаться, что вы вливаетесь слишком медленно.
Создавая план, выясните, с кем из сотрудников вам необходимо пообщаться. Уточните, есть ли какие-то конкретные темы для обсуждения с ними, и обязательно спросите о наличии напряженности в отношениях, конфликтов и наболевших вопросов, о которых вам следует знать. Рекомендуем начать со следующего списка людей:
• Непосредственная команда: дизайнер, инженеры, специалисты по обработке данных и по исследованию пользовательской аудитории.