Чем менеджер продукта отличается от тяжелоатлета

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

Так вот, менеджеры продуктов отличаются от тяжелоатлетов тем, что редко делают базу, часто отрицают её наличие или путают базовые дисциплины с узкоспециализированными. Какие дисциплины и области знаний являются для менеджера продукта базовыми — вопрос сложный. Я предпочитаю отталкиваться от существующих реалий самой роли, практической применимости в «боевых» условиях и максимальной пользы на единицу затраченного на изучение времени.

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

Что скрывает в себе роль менеджера продукта

Стивен Хейнс в книге «The Product Manager’s Desk Reference» даёт определение:

The product manager plays a central role in Product Management. As the “mini-CEO” for the product, he or she leads a cross-functional team to achieve the product’s strategic intent.

Мини-CEO — хорошая и точная характеристика продакт менеджера в идеальном мире, в котором PM руководит мини-бизнесом внутри другого бизнеса и у PMа есть ресурсы и полномочия «вести кросс-функциональную команду к достижению стратегических целей». В этом случае Хейнс прав и PM должен обладать знаниями в области стратегии, маркетинга, финансов, рыночного анализа, лидерскими качествами и так далее. То есть, набором качеств хорошего, полноценного CEO.

Об идеальном мире чуть дальше, но в реальном мире получается несколько иначе и задачи у PMа слегка приземлённее. Чаще продакт менеджер выполняет роль координатора кросс-функциональной команды или «матрицы» из разных департаментов. Прямой власти и полномочий принимать решения у него нет, а уровень влияния сильно ограничен. Всё усложняется тем, что ни сам менеджер продукта, ни вышестоящий менеджмент толком не понимают границы роли, а бывает и расходятся в понятиях в противоположные стороны. Что приводит к когнитивному диссонансу и фрустрации участников с обеих сторон, проще говоря — к несоответствию реальности ожиданиям и представлениям.

Идеальная роль менеджера продукта предполагает множество внешних условий и допущений, что-то вроде «команды мотивированных профессионалов» в Agile манифесте. Стивен Хейнс учёл сложности реального мира, поэтому написал целую главу на 22 страницы, которая называется «Organizing for Product Management» и содержит интересный подраздел «Transforming organization». Хорошо, когда есть возможность совершить трансформацию, но чаще всего её нет.

Так вот ты какой, реальный мир

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

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

 — Роли, всё же, разделятся (и мы наблюдаем это в некоторых компаниях, вроде Яндекса) .
 — Роли останутся консолидированными, но в более эффективной конфигурации и со смещённым фокусом на продукт.

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

Чем меньше звеньев в цепочке, тем лучше. И если организация сможет выстроить гибкий и масштабируемый процесс, то получит важное конкурентное преимущество. Конкуренты либо перестроятся в ту же сторону, либо будут страдать (см. Agile трансформации крупных банков). Трансформация, если она случится, позволит PMу всё сильнее смещаться в сторону управления продуктом, но функция организатора и оптимизатора полностью не уйдёт.

Похожим образом эволюционировала роль разработчика и дизайнера — с развитием «средств производства» разработчики смогли заняться решением всё более сложных инженерных задач вместо преодоления ограничений среды. А роли проектировщика, аналитика и дизайнера консолидировались в одном человеке и значительно повысили эффективность работы над пользовательскими интерфейсами.

Футурология менеджерских ролей — отдельная большая тема и как-нибудь я её раскрою подробнее и с рассмотрением альтернатив.

Пока мы идём к светлому будущему, суровость текущей реальности может дополняться разными ограничениями среды обитания менеджера:

  • Менеджер не принимает никаких окончательных решений, все решения нужно «продавать» стейкхолдерам или исполнять уже принятые решения.
  • Как следствие, кто-то из вышестоящего руководства или влиятельных стейкхолдеров может значительно перекроить продукт в любое время.
  • Менеджер тратит много времени на координацию команды и процесса разработки, занимается построением и улучшением процессов.
  • Команда разработки постоянно задаёт вопросы по требованиям к системе, потому что менеджер является первоисточником требований и носителем знаний о продукте. А из-за нехватки времени, требования обычно не сформулированы и не зафиксированы.
  • Стейкхолдеры противоречат сами себе и друг-другу, часто меняют мнение и склонны к бесконечному генерированию новых идей.
  • Так как роль и полномочия расплывчаты, то возникают постоянные проблемы с кросс-функциональностью команды и вовлечением в процесс. Есть соблазн сконцентрироваться на том департаменте, внутри которого находится сам менеджер продукта (маркетинг, разработка и т.д.).
  • И так далее, добавьте ингредиентов из своего опыта по вкусу.

То, чем в реальности занимается менеджер продукта — это консолидация продуктового видения из разных источников и формулирование непротиворечивой картины продукта, которая затем «продаётся» стейкхолдерам и исполняется под руководством всё того же менеджера продукта. А фокус его направлен скорее не вовне (к пользователям продукта), а внутрь (к проектной команде и стейкхолдерам). В этом случае, основной задачей становится выстраивание процесса таким образом, чтобы оставалось хоть какое-то время на управление продуктом.

И что же поможет менеджеру справляться со всем этим безобразием эффективно и результативно? Подсказка — это не customer development, не A/B тестирование и даже не data-informed decision-making. На помощь приходит «база», которая была актуальна вчера, актуальна сегодня и будет актуальна завтра.

О проектном менеджменте и системном анализе

Проектный менеджмент в целом и PMBoK в частности учит нас нескольким важным вещам:

  • Менеджер отвечает за всё, что происходит на проекте, даже если на многое он не имеет прямого влияния.
  • Менеджер должен тщательно обдумывать и планировать всё, что происходит на проекте. В том числе сам процесс планирования.
  • Менеджер осознанно и целенаправленно управляет всеми областями знаний, не ограничиваясь одной только разработкой или «продуктовыми метриками»
  • Даже если что-то пошло не так, у вас всегда есть план “Б”, о котором вы заранее подумали.

Последний пункт особенно важен, так как напрямую связан с не идеальным миром и даёт нам инструменты для работы в любой ситуации.

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

Немного статистики почему проваливаются проекты (причины пересекаются, сумма не равна 100%, источник):

  • 37% из-за плохо собранных требований
  • 31% из-за плохой работы с рисками
  • 30% из-за проблем с коммуникацией
  • 29% из-за плохой работы с изменениями

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

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

И пару слов о системном анализе в целом и бизнес-анализе в частности. Даже как-то неудобно говорить о системном анализе, как о чём-то действительно важном, потому что это вроде бы очевидно. Но как показывает практика — очевидно далеко не всем.

По моей статистике, только 1 из 10 менеджеров проектов/продуктов с опытом работы больше 3х лет способен «от бедра» (на собеседовании) поставить качественную задачу на разработку небольшой фичи. Примерно та же ситуация с формулированием требований к системе/продукту. Если специалист не может сформулировать и зафиксировать свои мысли на бумаге, то правильно ли он их вообще «думает»?

Есть мнение, что PM сообщество слишком рьяно клеймит «бюрократию» и превозносит гибкие подходы в менеджменте. Не стоит путать холодное с мягким, а любую документацию приравнивать к техническим заданиям по ГОСТу. Это приводит к перегибам в обратную сторону, когда менеджеры ставят всё на soft skills, зачитывают до дыр книги Стива Бланка, Эрика Риса и статьи о лидерских качествах великих предпринимателей, но игнорируют ту самую базу и часто не способны справиться с тривиальными ситуациями. Управление продуктом — это огромная ответственность и часто приземлённый тяжелый труд, далёкий от роли визионера, которую представляют себе ребята, мечтающие о роли менеджера продукта.

Кризиса идей нет, есть кризис «производства»

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

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

Рассылка новых постов и статей