Escaping the Build Trap, глава 7: Хороший продакт-менеджер
Главная мысль: хороший PM соединяет цели бизнеса и проблемы пользователей. Он отвечает за «зачем», а за «что» отвечает вся команда.
Настоящая роль PM
Заголовок раздела «Настоящая роль PM»- PM вместе с командой создаёт продукт, который решает проблемы пользователей и закрывает цели бизнеса.
- Он понимает рынок, бизнес-модель, видение компании и потребности пользователей.
- Название «менеджер» обманывает. У PM почти нет прямой власти. Он работает через влияние.
- PM владеет «зачем» (
why). Команда вместе владеет «что» (what). - PM ведёт эксперименты и снижает неизвестность. Сначала неясна проблема. Потом неясно, какое решение подойдёт.
- PM собирает данные из многих источников: исследования клиентов, рынок, эксперименты, аналитику.
- Цель PM — снижать риск через обучение. Не все хорошие идеи — его собственные.
Эксперт по технологиям или по рынку
Заголовок раздела «Эксперт по технологиям или по рынку»- Плохая черта PM — «одинокий волк»: он думает, что один отвечает за успех.
- PM работает с UX-дизайнером над сценариями пользователя. С разработчиками решает, как быстро выпустить продукт.
- UX — только одна часть продукта. PM смотрит на всю систему: требования, ценность, бизнес-модель, цены, интеграции.
- Ошибка при найме: искать технического эксперта или эксперта по рынку. PM — эксперт по product management.
- PM должен быть tech literate, а не tech fluent. Он понимает технологию достаточно, чтобы задавать правильные вопросы и делать компромиссы. Код писать не обязан, если продукт не очень технический.
- Рынок можно изучить. Если в команде есть сильные аналитики рынка, PM учится у них.
Пример: Marquetly наняла бывших маркетологов в PM. Им было трудно строить продукт. Их перевели в контент, и это подошло и им, и компании.
Кейс: Меган и ипотека
Заголовок раздела «Кейс: Меган и ипотека»Меган — PM в крупном розничном банке. Она отвечала за опыт людей, которые впервые берут ипотеку.
| Шаг | Что сделала Меган |
|---|---|
| Видение | Начала с видения подразделения: подавать заявку на ипотеку легко и откуда угодно |
| Цель | С VP продукта выбрала цель: больше завершённых заявок. 60% новых заявителей бросали процесс |
| Данные | Нашла тех, кто не закончил заявку, и поговорила с ними |
| Исследование | Брала разработчиков и дизайнера на интервью с пользователями |
| Проблема | Документы проверяли только в офисе. Ждать встречу долго, люди уходили в другой банк |
| Проверка | Опрос шире показал: из людей с этой проблемой заявку закончили только 25% |
| Эксперимент | Документы присылали по почте, их проверял сотрудник вручную. Заявки завершали на 90% чаще |
| Первая версия | Удобная отправка документов, но проверка всё ещё человеком. Визитов стало на 50% меньше |
| Дальше | План: AI-компоненты и онлайн-нотариусы, цель — ноль визитов |
Меган: если держаться за «зачем», больше шансов построить правильную вещь.
Начинать с «зачем»
Заголовок раздела «Начинать с «зачем»»Меган задавала вопросы до того, как строить:
- Зачем вообще этот проект?
- Какой результат мы хотим?
- Как выглядит успех?
- Что если всё станет цифровым, а заявок не будет? Как снизить этот риск?
Каждый вопрос — риск, который может убить проект.
- Часто PM не дают спросить «зачем». Им спускают готовые решения, иногда ещё на годовом бюджетировании.
- Любое решение несёт предвзятость. Бороться с ней можно только через пользователей и эксперименты.
- Когда решение спускают сверху, обычно не задают метрики успеха. Тогда нельзя исправить курс.
- Меган помогло, что начальник вместе с ней задал цель, дал свободу и разрешил говорить с пользователями.
Product owner и product manager
Заголовок раздела «Product owner и product manager»По Scrum у product owner три обязанности:
- вести бэклог и писать user stories;
- приоритизировать бэклог;
- принимать готовые stories.
Scrum не отвечает на важные вопросы:
- Как определить ценность?
- Как измерить успех на рынке?
- Как понять, что мы строим правильное?
- Как назначить цену и вывести продукт на рынок?
- Строить самим или покупать? Как интегрироваться с другими системами?
Вывод автора: product owner — это роль в Scrum-команде, а product manager — это карьера. Уберите Scrum, и вы всё ещё PM.
Ещё один вывод: компании без PM («всё придумывает CEO») редко создают ценность надолго. Их обгоняют, или они медленно угасают.
Одна роль, много обязанностей
Заголовок раздела «Одна роль, много обязанностей»Работа PM зависит от контекста:
| Контекст | Фокус |
|---|---|
| Без Scrum-команды или с маленькой командой | Стратегия и проверка идей для нового продукта |
| Со Scrum-командой | Выполнение решений |
| Руководитель PM | Стратегия для большей части продукта, коучинг команд |
Критика SAFe:
- В SAFe product manager говорит с клиентами и спускает требования. Product owner внутри команды пишет stories.
- Автор не видела, чтобы это работало. Product owner оторваны от пользователей. По сути это Waterfall, и никто не проверяет идеи.
- Если product owner 40 часов в неделю пишет user stories, компания в build trap.
Как надо:
- С хорошей стратегией и жёсткой приоритизацией один человек успевает и говорить с клиентами, и работать с командой.
- Старшие PM задают видение и стратегию.
- PM с маленькой командой (дизайнер и один разработчик) проверяют направление.
- После проверки вокруг них строят большие Scrum-команды.
- Если дать PM большой бэклог на этапе поиска, он будет его заполнять. Ни поиск, ни поставка не будут сделаны хорошо.
Ключевые термины
Заголовок раздела «Ключевые термины»| Термин | Значение |
|---|---|
why / what | PM отвечает за «зачем», команда — за «что» строить |
known unknowns | То, что мы знаем, что не знаем. PM выявляет и проверяет их |
tech literate | Понимает технологию на уровне вопросов и компромиссов |
product owner | Роль в Scrum: бэклог, приоритизация, приёмка |
| SAFe | Scaled Agile Framework, фреймворк для масштабирования Agile |
lone wolf | PM, который считает себя единственным ответственным за успех |
Что это значит на практике
Заголовок раздела «Что это значит на практике»- Будьте как Меган с данными: прежде чем строить решение, найдите в хранилище, где теряются пользователи. Воронка заявок покажет проблему лучше мнений.
- Дайте PM быстрый доступ к данным: витрина воронки, сегменты тех, кто бросил процесс. Это его источник для интервью.
- Для эксперимента вроде ручной проверки документов не нужен большой пайплайн. Хватит простой таблицы и запроса. Строгий
dbt-проект делайте после проверки. - Задайте метрику успеха до старта (у Меган — доля завершённых заявок). Без неё нельзя понять, работает ли решение.
- Вы тоже можете быть tech literate для бизнеса и business literate для PM. Объясняйте компромиссы данных простыми словами.
- Если вы целый день только закрываете тикеты, спросите: против какой цели они приоритизированы?
Вопросы для самопроверки
Заголовок раздела «Вопросы для самопроверки»- За что отвечает PM, а за что команда?
- Что значит «tech literate, а не tech fluent»?
- Какие шаги сделала Меган от проблемы до первой версии?
- Чем product owner отличается от product manager по версии автора?
Предыдущая: 6. Плохие архетипы PM. Следующая: 8. Карьера продакт-менеджера.