Библия product-менеджеров: краткий пересказ

Без Марти Кагана не обходится ни один список рекомендованной литературы для продактов. В "Inspired" коротко обозревается всё, с чем ежедневно сталкивается продакт: концепции, методологии, роли в продуктовых командах, принципы создания продукта, методики исследований и тд. Сама книга хорошо структурирована, автор не повторяет одну и ту же мысль десятки раз (чем обычно грешит нон-фикшн), а материал будет полезен не только джунам, но и чувакам с опытом.

Продуктовые компании могут находиться на трех стадиях развития:

1. стартап (основная задача - достичь product-market-fit)

2. компания на стадии роста (задача - эффективно расти)

3. корпорация (задача - выдавать непрерывные инновации).

Стиль управления продуктами в компаниях на разных стадиях разный (что логично).

Сердечко продуктовой компании - разработка. Есть две основные модели управления разработкой: каскадная (читай - рудиментарная) и agile.

Каскадная (водопадная) модель управления - это когда все функции и этапы разработки сменяют друг друга последовательно. Ошибки выясняются только на предпоследнем этапе - если что-то не так, вся предыдущая работа идет насмарку (ну, грубо говоря).

Методологии lean и agile работают иначе. Их основные принципы:

Учитывай риски в самом начале;
Разрабатывай продукты совместно;
Главное - решить проблему, а не имплементировать новые функции.

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

Менеджер продукта может выбрать три подхода к работе:

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

В обязанности продакт-менеджера входит понимание 4 сфер:

Потребители (их надежды, чаяния и боли)
Аналитика (циферки, метрики и вот это все)
Бизнес и заинтересованные стороны ("сколько денежек нам надо заработать в этом месяце")
Рынка и отрасли (что сейчас на хайпе, а что уже зашквар).

Два курса, которые стоит пройти продакту:

Введение в программирование (видимо, так проще коммуницировать с разработчиками и понимать их боль)
Введение в финансы (а кто будет юнит-экономику считать, кроме тебя, умник?)

Кто вообще входит в продуктовую команду?

Продуктовый дизайнер - твой бро, с которым тебе придется работать рука об руку. В работе над продуктом существует три основных типа дизайна: дизайн взаимодействия, графический и промышленный. Продуктовый дизайнер в IT должен особенно хорошо шарить в двух вещах: UI и UX. Понятие UX (user experience) шире, чем UI (interface), и включает в себя не только интерфейсы, но и все взаимодействие с продуктом (например, емейл, маркетинг, поддержка и тд).
Разработчики. Казалось бы, тут все просто (но только на словах) - надо уважать их и налаживать с ними хорошие отношения. Не слишком много указывать, но при этом быть вовлеченным в работу. Предоставлять свободу для самовыражения, но постараться не слишком факапить сроки. В общем, удачи, ребята.
Продуктовый маркетолог - тут начинается интересное. Вообще-то маркетологи редко на 100% принадлежат продуктовой команде - обычно они подключаются on demand. Функции продуктового маркетолога и менеджера по продукту довольно сложно разграничить - стандартное разделение выглядит примерно так: менеджер больше думает про продукт, а маркетолог про рынок. Но все опционально.
Исследователи пользователей - если в команде нет таких сотрудников, их функции берет на себя дизайнер продукта.
Аналитики данных - если в команде таких нет, то их задачки переходят к продакт-менеджерам.
Тестировщики - их задачками могут, конечно, заниматься и программисты, но лучше бы не жопиться и выделить доп.ресурсы, чтобы не залажать.
Директор по технологиям. Очень важный человек, который отвечает за воплощение всего задуманного. Выполняет шесть основных обязанностей: организация, руководство, поставка на рынок, архитектура, исследование продукта, евангелизм.
Операционный менеджер с техническими навыками - попросту проджект (обычно выполняет функцию скрам-мастера).

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

Есть еще промежуточная роль GPM (group product manager) - отчасти он все еще работает ручками, а отчасти уже является менеджером по персоналу: обучает, коучит и управляет несколькими продактами из смежного профиля.

Масштабирование самоуправления

Иногда команды говорят, что не чувствуют свободы в принятии решений. Почему такое может быть?

Менеджмент не хочет ослаблять поводок
Команды хотят делать что-то, что противоречит устоям компании.

Насколько вообще надо давать команде полномочия в выборе технологий, методик и тд? Зависит от трех аспектов:

Уровень командного мастерства
Значение скорости (можем позволить себе чуть притормозить?)
Размер и расположение компании
Культура компании
Зрелость технологии
Значение для бизнеса
Уровень ответственности

Продукт должен отвечать следующим требованиям:

ценность
юзабилити
реализуемость
бизнес-жизнеспособность
нормальное соотношение «время-деньги».

В компаниях очень любят дорожные карты по двум причинам:

Они дают менеджменту уверенность, что идет работа над самыми приоритетными для бизнеса штуками
Они помогают контролировать сроки

Но вообще-то лучше работать на результат, а не на процесс. Альтернатива обычным дорожным картам - дорожные карты по методике OKR.

! Разница между SMART и OKR в том, что OKR дает большую свободу в плане методики достижения цели. По OKR ты выбираешь 3-5 целей и прописываешь к ним по 3 требования - способ достижения остается на усмотрение исполнителя.

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

Видение продукта описывает будущее, стратегия развития - путь к реализации будущего, а принципы продукта определяют природу продуктов, которые вы хотите создать.

Как работать над продуктом:

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

Продвижение продукта = продуктовый евангелизм (Гай Кавасаки). Как продавать мечту?

Используйте прототип
Щедро делитесь успехом
Проводите демонстрации продукта
Искренне любите продукт
Проводите время с командой

Продукт несет следующие риски:

Риск ценности
Риск юзабилити
Риск технической реализуемости
Риск бизнес жизнеспособности

Чтобы устранить риски, нужно исследовать продукт – собрать доказательства.

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

Методики исследования продукта (все методики неплохо гуглятся, не буду подробно описывать каждую):

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

Для прототипирования (прототипы для тестирования реализуемости - как правило, код, который показывает, получится или не получится реализовать данный проект; пользовательские прототипы - симуляции; прототипы для сбора данных об использовании - тут генерим ограниченный трафик и смотрим на поведение пользователей; смешанные прототипы - интерфейсы, за которыми член команды руками выполняет все действия).
Для тестирования спроса - тест с поддельными дверями; тест на спрос с использованием посадочной страницы; АВ-тесты.

Для тестирования бизнес-жизнеспособности - пользовательский тест, демонстрация продукта (продажа через мероприятие)

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

Основная мысль проста и незаурядна: продуктовая культура - это важно, а обмениваться новыми знаниями просто необходимо.

Черты хорошей продуктовой культуры в компаниях:

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

Summary/финальное напутствие/CTA: читайте про компании с сильной продуктовой культурой, шерьте полученные знания со своей командой, пытайтесь внедрить бест практис у себя, будьте открыты ко всему новому - и будет вам счастье и сильная продуктовая культура.

Библия product-менеджеров: краткий пересказ

Часть 1. Продуктовые компании

Часть 2. Продуктовые команды

Часть 3. Правильный продукт

Часть 4. Правильный процесс

Часть 5. Продуктовая культура