Что делает продакт в Фейсбуке? Часть 1, Часть 2 Из пяти осн | No Flame No Game

Что делает продакт в Фейсбуке?
Часть 1, Часть 2

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

Начну с главного: тот факт, что продакт не заводит таски, совершенно не значит, что он не отвечает за результат. Отвечает на 100%. Но, как я говорила в предыдущей заметке, пути достижения этого результата не сводятся к постановке задач. Так, а что же там есть еще?

Execution, по сути, складывается из двух больших категорий: 1) Приоритизация (как наилучшим образом воплотить в жизнь стратегию - про стратегию еще отдельно поговорим); и 2) Процесс (как нам продвигаться вперед наиболее эффективно).

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

Процесс - это коммуникация, проджект-менеджмент, получение сигнала по гипотезе через эксперименты/исследования, и так далее. По сути: как мы доходим от гипотезы до успешно запущенной фичи с максимальным ROI.

Безусловно, продакт может заниматься всем вышеперечисленным - и обычно именно так и начинают карьеру в продакт-менеджменте. Но чем сеньорнее становится продакт, тем меньше ценности команда будет получать от его фокуса на execution, в особенности, на процессе. Чтобы написать one pager или поставить задачу, не требуется никакого тайного знания; любой опытный разработчик или дизайнер может с этим справиться. С другой стороны, поиск новых возможностей для команды, коммуникация со стейкхолдерами или проработка стратегии - более редкие навыки, ради которых и нанимают продактов; здесь они могут добавить уникальную ценность.

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

1) Для некоторых профессий в этих областях находятся точки роста: например, разработчикам для перехода на позиции Senior или Engineering Manager нужны навыки управления проектами. Хорошие продакты делегируют, помогают ребятам в команде расти и освобождают себе время для более стратегических задач.

2) Команда отвечает (и оценивается) по конечному результату, а не по формальным обязанностям. Если, например, разработчик написал великолепного качества код или выкатил фичу, но это все никак не повлияло на счастье пользователей или ценность для бизнеса, то его работа не будет иметь особого значения. Такой подход ведет к тому, что команда пытается максимизировать результат, а не выполнение своих обязанностей, например:

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


Что все это значит на практике?

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