Escaping the Build Trap, глава 6: Плохие архетипы продакт-менеджера

Главная мысль: продакт-менеджер отвечает за «зачем» (why). Плохие PM либо командуют, как мини-CEO, либо принимают заказы, как официант, либо следят только за сроками, как проджект-менеджер.

Часть II: роль продакт-менеджера

Эта глава открывает вторую часть книги. Часть отвечает на вопрос: кто такой продакт-менеджер и как встроить эту роль в компанию.

Что делает PM по версии автора:

• Глубоко понимает и бизнес, и клиента.
• Собирает разные данные: аналитику, отзывы клиентов, исследования рынка, мнения стейкхолдеров.
• Решает, куда двигаться команде.
• Держит фокус на «зачем»: зачем мы это строим и какой outcome получим.

Ещё два тезиса части:

• Product management — это карьера, а не роль в команде.
• Компании нужен понятный карьерный путь для PM. Во главе стоит CPO (chief product officer). Он связывает бизнес-результаты с роадмапом и объясняет их совету директоров.

История автора: спецификация на 21 страницу

• Первая задача автора как PM — страница «сменить пароль».
• Она неделю писала спецификацию: 21 страница, 14 макетов, все ошибки.
• Её учили: чем подробнее спецификация, тем лучше PM. Тогда разработчикам не нужно с ней говорить.
• Позже она поняла: хватило бы пары разговоров с разработчиками и десятой части документов.
• Так учат PM почти везде. Это и есть проблема.

Как обычно учат продакт-менеджеров

• В вузах этому не учат. Обучение на работе слабое.
• Почти только Microsoft и Google имеют путь для начинающих PM.
• Чаще всего в PM переходят из другой роли в компании или из разработки.
• Учат в основном рутине: требования, user stories, планирование, встречи, приёмка, баги.

Это наследие Waterfall:

Шаг	Что происходит
1	PM собирает запросы у внутренних стейкхолдеров
2	Пишет требования
3	Дизайнеры рисуют интерфейс
4	Разработчики месяцами пишут код
5	Клиент видит продукт только в самом конце

Почему Agile не помог

• Многие компании, включая Marquetly, внедрили Agile и разочаровались.
• Agile улучшает совместную работу и ускоряет разработку.
• Но Agile предполагает, что кто-то уже придумал и проверил идеи. Как это делать, он не объясняет.
• Поэтому многие PM в Agile-командах работают с Waterfall-мышлением.
• PM хвалят за подробные спецификации и релизы в срок. Никто не измеряет, думают ли они.

Архетип 1: мини-CEO

• Автор видела, что 90% вакансий называют PM «мини-CEO продукта». Она с этим резко не согласна.
• У CEO есть власть: он увольняет, меняет команды и направление. У PM этой власти нет.
• PM не управляет людьми. Он может только влиять на них.

Пример из Marquetly:

• Ник пришёл после бизнес-школы и хотел быть «новым Стивом Джобсом».
• Он диктовал команде, что строить. Разработчики и дизайнеры его не любили.
• Автор рассказала ему о своей похожей ошибке в OpenSky. Её начальник напомнил: работа PM — создавать ценность, а не продвигать свои идеи.
• Совет Нику: слушать команду, слушать клиентов, любить их проблемы, а не свои решения, искать данные вместо мнений.
• Ник провёл брейншторм с командой и стал отдавать ей заслуги. Через месяц отношение к нему стало лучше.

Архетип 2: официант

• Официант принимает заказы. Он спрашивает стейкхолдеров и клиентов «что вы хотите?» и превращает ответы в список задач.
• Нет цели, нет видения, нет решений.
• По словам автора, так работали 90% product owner в Marquetly.

Что из этого следует:

• Главный вопрос таких PM: «Как приоритизировать?» Без цели это конкурс популярности. Побеждает самый важный человек.
• Клиент просит конкретное решение, и PM его строит без проверки.
• Это product death cycle (термин Дэвида Бланда) — частный случай build trap.
• Придумывать решения — работа PM, а не клиента. Клиенту нужно, чтобы решили его проблему.
• Официанты думают реактивно, а не стратегически. Часто это выученная беспомощность: они не верят, что могут возразить.
• Возражать — часть работы PM.

Архетип 3: бывший проджект-менеджер

Роль	За что отвечает	Вопросы
Проджект-менеджер	when	Когда закончим? Успеваем?
Продакт-менеджер	why	Зачем строим? Какую ценность это даёт клиенту и бизнесу?

• Немного project management в работе PM нужно. Но это не главное.
• Отвечать «зачем» сложнее, чем «когда». Поэтому PM часто уходят в задачи по срокам.
• В Agile кросс-функциональные команды сами берут на себя координацию. Проджект-менеджеров стало нужно меньше.
• Многих из них переименовали в PM или product owner. Опыта продуктовой работы у них часто нет.
• Официант плюс проджект-менеджер — это «официант с календарём»: он не знает зачем, зато следит когда.

Ключевые термины

Термин	Значение
product manager (PM)	Человек, который отвечает за «зачем» и направление команды
internal stakeholders	Люди внутри компании, у которых есть запросы к продукту
mini-CEO	Ложный образ PM как начальника продукта с полной властью
waiter	PM, который принимает заказы без цели и проверки
product death cycle	Цикл, где команда строит то, что просят, без проверки идей
project manager	Человек, который отвечает за сроки и ход проекта
CPO	Chief product officer, главный продуктовый руководитель

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

• Не будьте «официантом» для бизнеса. Когда просят новый дашборд, спросите: какое решение он поможет принять и какую метрику изменит.
• Если заказчик приносит готовое решение («добавьте колонку в витрину»), найдите проблему за ним. Часто её можно решить существующей моделью в dbt.
• Приоритизируйте бэклог данных по цели команды, а не по должности того, кто просит.
• Подробное ТЗ на пайплайн не заменяет разговора. Короткая встреча с аналитиком часто полезнее 20 страниц.
• Работая с PM, спросите его про цель и outcome. Если он отвечает только про сроки, у команды нет ориентира для данных.
• Аргументируйте данными, а не мнением. Это ваше главное влияние без формальной власти.

Вопросы для самопроверки

1. Почему PM не «мини-CEO» продукта?
2. Чем why продакт-менеджера отличается от when проджект-менеджера?
3. Что такое product death cycle и как в него попадают?
4. Почему Agile сам по себе не решает проблему плохого product management?

Предыдущая: 5. Что мы знаем и чего нет. Следующая: 7. Хороший продакт-менеджер.