Всем привет. Как и обещал, публикую вторую часть статьи на тему того, кто приносит больше пользы, Business Product Manager или Technical Product Manager.
Напомню, что первую часть статьи, где я рассказываю, какая ситуация сложилась у меня в бизнесе и какой управленческий эксперимент мы запустили в результате разногласий СРО (меня) и СЕО, вы можете найти по ссылке.
В первую очередь хочу поблагодарить за комментарии к предыдущей статье. Рад, что поднятая мной тема вызвала какой-то интерес и возникла дискуссия. Как раз с ответов на комментарии к предыдущей статье я и хотел бы начать, так как именно в русле проблемы, поднятой в комментариях, и я хотел написать вторую часть этой статьи.
Итак, уважаемые комментаторы предыдущей статьи вполне справедливо заметили, что я как будто бы ставлю перед читателем безальтернативный выбор — либо набираете бизнес-продактов и страдаете от неэффективного деливери, либо берёте технических продактов и развиваете продукт непонятно как, зато фичи выпускаете быстро и качественно.
Конечно же, это не так. Безальтернативный выбор — это крайность, необходимость в которой может возникнуть исключительно в ситуации серьёзного кризиса. Если бизнес находится в ситуации, когда необходимо выжить и нет возможности нанять нескольких специалистов, каждый из которых покрывает свою зону ответственности, согласно своих сильных сторон и навыков. Либо если вы можете позволить себе нанять только одного человека, либо вам нужно решить, кого из нескольких продакт-менеджеров нужно оставить в ситуации кризиса — воспользуйтесь моими рекомендациями из предыдущей статьи. Во всех остальных случаях я рекомендую применять более гибкий подход и выстраивать организационную структуру и процессы исходя из наличия нескольких продактов по специализациям.
Собственно, это именно то решение, к которому я пришёл в своей компании, в результате анализа того, каким образом продуктовый департамент работал на протяжении шести месяцев.
Передо мной возникло две фундаментальные проблемы, без решения которых вся работа департамента и его эффективность была под вопросом:
Бизнес продакт менеджеры работают «в стол», так как большая часть их проработанных проектов, экспериментов и проверенных гипотез разбиваются об уже существующие приоритеты и роадмапы команд разработки. При том, что выстраивались эти роадмапы, а также в целом управление командами разработки осуществлялось проджект-менеджерами, которые находятся в другой организационной и управленческой вертикали.
Само выстраивание этих роадмапов и определение приоритетов для команд разработки выстраивалось практически вслепую, без сбора каких либо цифр, без анализа данных, без оценки потенциальной прибыльности и рисков для каждого отдельного проекта. То есть фактически управление продуктовым роадмапом компании осуществлялось в ручном режиме лично СЕО с вовлечением проджект-менеджеров команд разработки. Как следствие, сам процесс разработки превратился в полный хаос со всеми вытекающими последствиями: остановка проектов на полпути из-за того, что вдруг выяснилось, что они не нужны бизнесу; изменение основных требований по ходу проекта, когда становилось понятно, что клиентам нужно несколько другое; дорогие ошибки в архитектуре системы из-за невыявленных с самого начала продуктовых требованиях и так далее.
В результате бизнес растрачивал огромное количество ресурсов (денег и времени людей) на разработку фичей, которые в результате либо совсем не приносили прибыль, либо были разработаны с ошибками и нуждались в доработках для обеспечения максимизации прибыли.
Возникшая ситуация требовала фундаментального решения, без которого я чувствовал, что бизнес остановится в развитии. И мы приняли решение сделать следующее:
Мы перевели все команды разработки в продуктовую организационную и управленческую вертикаль. При этом менеджером каждой из команд разработки стал выделенный Technical Product Manager. Никаких -проджект-менеджеров, скрам-мастеров и т.д. в командах разработки не осталось. За всю работу команды (начиная от отпусков, наймов и увольнений и заканчивая определением приоритетов для команды) отвечает Technical Product Manager. Также в команде остаётся роль бизнес-аналитика, который помогает техническому продакт-менеджеру декомпозировать задачи и описывать требования для команды. Кроме этого, в команде выделяется роль лид разработчика, который также находится в прямом подчинении технического продакта и помогает ему настраивать процессы в команде, занимается проектированием и архитектурой, выбирает технологический стек и инструментарий, а также помогает техническому продакту оценивать перформанс других членов команды.
Мы выделили отдельный юнит бизнес продакт-менеджеров внутри продуктовой организационной вертикали, который работает параллельно с командами разработки. В задачу этого юнита входит обеспечение технических продакт менеджеров качественной продуктовой аналитикой и проработанными (с точки зрения бизнеса) проектами, которые можно брать в проектирование и приоритезацию для команд разработки на основании представленной информации по потенциальной прибыльности.
При этом, поскольку оба юнита (бизнес-продакты и команды разработки во главе с техническими продактами) находятся в одной продуктовой вертикали, практически не возникает проблем, связанных с конкуренцией за ресурсы команд разработки. В отдельных исключительных случаях этот вопрос поднимается ко мне и я принимаю окончательное решение о том, какой из двух проектов более приоритетный. Но как правило, этого не происходит, бизнес-продакты прекрасно находят общий язык с техническими, так как все они гребут в общей лодке с едиными и прозрачными целями на весь продуктовый департамент.
Организационная структура такой системы выглядит примерно следующим образом:
Как видите, в бизнес-юнит, помимо собственно бизнес-продактов входят также UI/UX дизайнеры и пользовательские исследователи. То есть это полноценный продуктовый и аналитический юнит, который способен самостоятельно на качественном уровне проводить продуктовую аналитику, собирать обратную связь от пользователей, проверять продуктовые гипотезы и т.д.
При этом технический юнит занят построением роадмапов и реализацией конкретных проектов, пришедших от бизнес-юнита. В такой системе технические продакты могут позволить себе сосредоточиться на построении эффективного процесса деливери, не отвлекаясь на продуктовую аналитику. При этом, технический продакт отличается от проджект-менеджера тем, что он всё-таки продакт. То есть он также вовлекается в процесс продуктовой аналитики и принимает участие в работе бизнес-юнита, но не погружаясь туда слишком глубоко. Ну и как я писал в предыдущей статье, у нас есть достаточно строгие требования к технологическому бекграунду технического продакт-менеджера: знание архитектуры системы и API продукта, по которым он взаимодействует с внешним миром — это must требование.
Надеюсь, статья была вам полезна. Готов ответить на вопросы в комментариях.
Автор статьи — Александр Лобов, преподаватель курсов в OTUS.
Давно хотели понять, почему Facebook, Amazon или Booking стали успешными продуктами? Спойлер: они правильно определили метрику роста и работали над улучшением unit-экономики. Приглашаем всех желающих на demo-занятие «Как продакт-менеджеру найти метрику роста и свести Unit-экономику?».
За полтора часа на примерах с реальных продуктов вы узнаете: почему успех продакт-менеджера — это рост главной метрики продукта; как определить метрику роста; как построить аналитику и продукт вокруг метрики роста; научитесь расчету unit-экономики, как это делают продакт-менеджеры; а также узнаете, что может сделать продакт-менеджер для улучшения unit-экономики. Регистрация — по ссылке.