Библия 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 довольно хорошо масштабируется при росте компании. В больших компаниях, как правило, создаются команды, которые не взаимодействуют напрямую с потребителем - их задача заклбчается в обслуживании других, более компетентных команд (это бэкофис).

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

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

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

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

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

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

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

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

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

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

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

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

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