Всем привет! Сегодня я продолжаю свой рассказ о важнейшей литературе для любого менеджера, начатый в моей первой статье про литературу для тимлидов, и представляю вам книгу Марти Кагана «Transformed — Moving to the Product Operating Model».

Каган — один из наиболее ярких IT-менеджеров в Кремниевой долине. В своих статьях и книгах он разбирает менеджмент таких гигантов, как Amazon и Spotify, описывает свой взгляд на ведение бизнеса, а в этой книге объединил весь этот опыт и представил самостоятельную «инструкцию» по трансформации работы над продуктом.

Причина № 1. Возможность узнать, что такое Product Operating Model и почему это важно

POM — это основа, скелет, который показывает весь процесс организации работы над продуктом. Если конкретнее, то эту модель можно описать формулой:

Product Model = product team + product strategy + product discovery + product delivery + product culture

Каждое слагаемое — это фактически набор принципов, которые отличают успешные компании от остальных. Предположу, что с остальными тезисами понятно, но что такое Discovery и Delivery?

Согласно Кагану, стандартная разработка разбивается на две большие фазы: Discovery и Delivery. Discovery — это процесс поиска важной проблемы и способа ее решения. Delivery — это процесс реализации решения проблемы. Давайте разберем принципы Product Discovery и Product Delivery в деталях.

Принципы Product Discovery

• Минимизировать «пустые траты»:
  
  • До старта разработки получать доказательство, что проблема реальна и предлагаемое решение будет востребовано (например, в нашей практике мы оцениваем потенциал будущего продукта или фичи в деньгах на основе открытых данных и нашего опыта).
  • Анализировать не только прямые издержки (Direct Cost; например, зарплаты), но и издержки упущенной выгоды (Opportunity Cost). Иногда оказывается, что, условно, разрабатывая какую-то фичу, способную заработать миллион, команда использует ресурсы, которые при реализации другой задачи позволили бы заработать 10 миллионов.
• Оценивать продуктовые риски, такие как:
  • Value Risk — удостоверяться, что мы планируем делать решение лучшее, чем есть на рынке, и фиксировать готовность потенциального пользователя платить за него;
  • Usability Risk — проверять наличие «алаймента»: узнавать как пользователи воспринимают проблему и попадаем ли мы со своим решением в их паттерны поведения;
  • Viability Risk — учитывать юридические ограничения, стоимость поддержки, маркетинга;
  • Feasibility Risk — просчитывать насколько дорого может обойтись разработка и насколько критичной будет затрата таких ресурсов для бизнеса.
• Регулярно проводить быстрые эксперименты. Прежде чем тратить много, стоит поискать дешевый способ проверить гипотезу.
• Проверять все идеи ответственно: то есть, обкатывая концепт, оберегать существующий доход, репутацию коллег, клиентов. Заслужить доверие сложно, а потерять легко.

Принципы Product Delivery

• Помнить, что ключевая ценность — надежность.
• Отдавать предпочтение небольшим, но частым релизам. Это позволяет лучше планировать работу и быстро исправлять возникающие инциденты.
• Не давать оценки сроков без повода. Процесс таких рассчетов может отнимать много ресурсов, а соблюдать наобум озвученные сроки получается далеко не всегда. Каган предлагает делать оценку только в критичных ситуациях, например в рамках High-Integrity Commitments. И для того чтобы ее дать, команда сначала создает прототип и только после этого оценивает сроки.
• Не пренебрегать мониторингом и телеметрией (например, у нас есть система уведомлений на случай, если фон ошибок в продукте отклонился от нормального).
• Использовать зрелую инфраструктуру для деплоя продуктов и проведения экспериментов. Инфраструктура должна:
  
  • Иметь низкий технический долг;
  • Поддерживать возможность A/B-тестирования.

Принципы Product Discovery были для меня полезны и в настоящих кейсах. Так, когда к нашей команде пришел заказчик с задачей рассчитать бюджет для конкретного кейса, знания из книги помогли мне учесть не только прямые издержки (те самые затраты на проект), но и альтернативные, что сделало анализ более конкретным и приземленным. Проще говоря, книга подсветила для меня все аспекты разработки продукта, которые потенциально могут пострадать из-за акцента на новой задаче. Например, работа с Opportunity Cost позволяет распределять время и ресурсы на разные проекты более равномерно, не перегружая команду.

Причина № 2. Возможность изучить конкретные кейсы компаний по всему миру — и реализовать их лучшие практики

Для подтверждения многогранности Product Operating Model в книге анализируются компании из различных направлений бизнеса:

1. Almosafer — Travel-бренд, который смог во время ковида перестроиться и в конечном счете забрать 70% рынка.
2. CarMax — крупнейший продавец б/у автомобилей, который вынужден был из-за ковида оцифровать свою бизнес-модель и сохранить лидерскую позицию.
3. Trainline — Uber of rail в Великобритании. После приватизации железных дорог смогла организовать крутой сервис по продаже билетов.
4. Gympass — бразильская компания, которая во время ковида вышла на международный рынок поддержания здоровья сотрудников.
5. Adobe — не нуждается в представлении. :)
6. Datasite — компания из области анализа финансовых транзакций.

Не открою Америки, если напомню, как важно обогащать свой опыт разными кейсами. Как вы видите, Каган представляет примеры самых разных компаний из самых разных индустрий и сфер. Однако, по Кагану, «база» продуктового менеджмента актуальна и для глобального финтеха, и для локальных транспортных сервисов, поэтому уважаемые читатели могут мотать на ус, вне зависимости от конкретной специфики их бизнеса. :)

Причина № 3. Желание понять, что такое трансформация и как ее проводить

Мы часто слышим слово «трансформация», но, на мой взгляд, Марти Каган дал отличное определение. Трансформация — это изменение трех аспектов, которые он называет «измерениями»:

• Изменение того, как мы разрабатываем и доставляем до пользователей (переход к частым регулярным релизам, внедрение мониторинга);
• Измнениние того, как мы решаем бизнесовые проблемы (изменение подхода к работе над фичами и проблемами; внедрение метрик Time To Money — времени к появлению выручки и Time To Market — времени к выходу на рынок);
• Изменение того, как мы приоритизируем проблемы (планирование, общение с пользователями).

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

Причина № 4. Необходимость подобрать компетенции для продуктовой команды

Давайте представим, что вам предстоит собрать команду с нуля. Какие ключевые компетенции вам понадобятся? Согласно Марти Кагану, существует 3(+1) обязательных набора компетенций.

• Designer
  
  • Постоянно участвует в Discovery-процессах.
  • Проектирует, «как работает продукт» и «как пользователи его воспринимают».
• Product Manager
  
  • Понимает пользователей, изучает данные, проводит исследования, понимает рынки, ограничения рынков и compliance и самостоятельно принимает решения.
• Engineer (+tech lead)
  
  • Определяет наилучшее возможное решение проблем. Привлекается на ранних этапах их проработки.
• Product Leader
  
  • Management: управляет самой командой.
  • Leadership: лидирует с помощью контекста, а не контроля: формулирует Product Vision, определяет топологию команд, описывает продуктовую стратегию, управляет через цели.

Что касается пользы книги в понимании компетенций, то лично мне стало проще понимать, как работает компания ЗА РАМКАМИ моих задач и кейсов. Более широкое понимание задач спецов позволяет выстраивать более прочные взаимоотношения со стейкхолдерами и устанавливать устойчивые переговорные позиции в дискуссиях с ними (а менеджеру без этого порой никуда!).

Итоговый вердикт в баллах

10 эффективных менеджеров из 10 (!!!).
Особенно книга подойдет тем, у кого в IT опыт более трех-пяти лет. Причем опыт в IT не конкретно менеджерский, а любой, начиная с джуна.

Любимая цитата

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

Если же на вас сильно повлияла какая-то другая менеджерская литература, смело пишите в комментарии своих любимых авторов по менеджменту! (первому написавшему про Макиавелли — мгновенный респект от автора!)