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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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