Escaping the Build Trap, глава 20: Коммуникация через результат
Главная мысль: руководители должны регулярно видеть прогресс к outcome. Если они его не видят, они возвращаются к старому: считают выпущенные фичи.

Часть V: урок Kodak
Заголовок раздела «Часть V: урок Kodak»Пятая часть книги — про организацию. Хорошие процессы не работают, если компания устроена против них.
История Kodak:
- 2007 год. Автор работает в инновационной команде Cornell вместе с Kodak Research Laboratories.
- Команда интервьюирует людей 18-25 лет. Сначала изучает проблемы, потом думает о продукте.
- Что хотят пользователи:
- контролировать, кто видит их фото;
- редактировать фото перед публикацией;
- иметь хорошую камеру в телефоне.
- Совет для Kodak: встроить свою камеру в телефоны. Сделать редактирование фото прямо на телефоне.
- Kodak ответила один раз: всё ещё ищет команду и бюджет. В 2012 году Kodak обанкротилась.
- Эти функции потом сделали Instagram, Apple, Android и Facebook.
Почему Kodak не смогла:
| Причина | Что произошло |
|---|---|
| Реакция вместо стратегии | Компания поздно ответила на угрозу |
| Изолированная лаборатория | Мало людей думали о будущем бизнеса |
| Нет ресурсов | Команда нашла идеи, но не могла их выполнить |
| Годовой бюджет | Новые деньги — только на годовом пересмотре, через полгода |
Вывод: исследование клиентов само по себе не спасает. Нужна организация, которая его поддерживает. Дальше книга говорит о коммуникации, культуре, политиках и наградах.
Marquetly через год
Заголовок раздела «Marquetly через год»- На квартальном обзоре Karen рассказывает о результатах. После запуска новых курсов acquisition rate вырос с 15% до 25%.
Retentionвырос до 60%. - Год назад Marquetly была в build trap: проекты от CEO, нет продакт-менеджеров, команды не говорят с клиентами.
- CEO Chris видит прогресс. Но между встречами он нервничает: ему не хватает видимости.
Главная причина провала таких перемен — руководство не готово судить по outcome. Ставить галочки за готовую работу приятно. Поэтому нужны другие способы показать прогресс.
Ритм встреч
Заголовок раздела «Ритм встреч»Прозрачность даёт командам свободу. Чем лучше лидеры видят прогресс, тем меньше они вмешиваются. Если прятать прогресс, растёт knowledge gap из главы 11.
Ритм встреч совпадает с уровнями стратегии: vision, strategic intent, product initiatives, options.
| Встреча | Кто | Как часто | О чём |
|---|---|---|---|
| Quarterly business review | Высшее руководство, CPO, VP of product | Раз в квартал | Прогресс к strategic intents, выручка, churn, затраты. Можно добавить новые intents |
| Product initiative review | CPO, CTO, лидеры дизайна, VP of product, PM | Раз в квартал, в другие месяцы | Прогресс options против initiatives. Результаты экспериментов. Запрос денег |
| Release review | Команды, часто руководители | Раз в месяц | Что точно выйдет. Метрики успеха. Roadmap для маркетинга и продаж |
- На quarterly business review не приоритизируют initiatives. Для этого есть product initiative review.
- На release review показывают только то, что точно выйдет. Не эксперименты.
- Решения обычно принимают после встречи. Встреча показывает прогресс и красные флаги.
Roadmap: не диаграмма Гантта
Заголовок раздела «Roadmap: не диаграмма Гантта»Проблема: roadmap часто — это Гантт с датами фич. Его обещают клиентам. Потом его нельзя изменить.
Лучше: roadmap объясняет стратегию и текущую стадию продукта. Его часто обновляют. В Produx Labs его называют Living Roadmap.
Что входит в roadmap:
- тема;
- гипотеза;
- цели и метрики успеха;
- стадия разработки;
- важные вехи.
Автор советует книгу Product Roadmaps Relaunched (C. Todd Lombardo, Bruce McCarthy).
Четыре стадии разработки
Заголовок раздела «Четыре стадии разработки»Договоритесь о словах для стадий. Тогда все понимают, что сейчас происходит.
| Стадия | Что проверяем | Кто видит |
|---|---|---|
| Experiment | Стоит ли решать проблему. Problem и solution exploration | Production-кода нет |
| Alpha | Нужно ли решение клиентам | Малая группа. Фичу могут изменить или убрать |
| Beta | Масштабируется ли решение технически | Больше клиентов, но не все |
| Generally Available (GA) | — | Все клиенты. Продажи продают открыто |
Договорённость с продажами: в sales roadmap попадает только GA и поздняя Beta. Это снижает напряжение между продуктом и продажами.
Product operations
Заголовок раздела «Product operations»Когда команд много, следить за целями и процессами трудно. Нужна команда product operations.
- В Marquetly её ведёт chief of staff под CPO. В команде два человека.
- В большой компании её ведёт лидер уровня VP. Команда тоже подчиняется CPO.
Что делает product operations:
- автоматически собирает данные о прогрессе к целям;
- готовит отчёты: цели,
outcome, roadmap, ёмкость, затраты, их финансовый смысл; - ведёт платформу продуктовой аналитики;
- стандартизирует общие процессы: ритм стратегии, учёт экспериментов, roadmap, цели;
- проводит ключевые встречи;
- обучает команды.
Важно: эта команда задаёт шаблоны и системы. Она не пишет roadmap за команды. Состав: проджект-менеджеры, продуктовые люди и несколько разработчиков.
Пример: компания с более чем 350 Scrum-командами. Автор сказала новому VP of product operations: успех — автоматизировать свою команду. Команда не должна расти без нужды.
Но отчёты не меняют поведение сами по себе. Многие компании меняют процессы, но награждают людей за старое.
Ключевые термины
Заголовок раздела «Ключевые термины»| Термин | Значение |
|---|---|
| Quarterly business review | Квартальная встреча руководства о strategic intents и финансах |
| Product initiative review | Квартальная встреча о прогрессе инициатив и финансировании |
| Release review | Ежемесячный показ того, что точно выйдет |
| Living Roadmap | Roadmap, который объясняет стратегию и часто обновляется |
| Alpha / Beta / GA | Стадии: нужно ли клиентам, масштабируется ли, доступно всем |
| Product operations | Команда, которая автоматизирует отчёты и стандартизирует процессы |
Что это значит на практике
Заголовок раздела «Что это значит на практике»- Product operations строит отчёты о прогрессе к целям. Это работа для data-команды. Предложите витрину в warehouse: initiative, цель, метрика, текущее значение.
- Сделайте три уровня дашбордов под три встречи. Руководству — выручка, churn, затраты. Продукту — метрики initiatives. Командам — метрики релиза.
- Добавьте стадию (Experiment, Alpha, Beta, GA) как атрибут фичи в dbt-модели. Так можно сравнить метрики Alpha-группы и всех клиентов.
- Для Alpha и Beta нужен флаг сегмента пользователя в событиях. Договоритесь с PM об этом заранее, до запуска.
- Автоматизируйте сбор данных для отчётов. Ручные таблицы в презентациях не масштабируются на десятки команд.
- Ваш собственный roadmap тоже может быть «живым»: тема, гипотеза, метрика успеха, стадия. Не обещайте бизнесу даты для идей, которые ещё в стадии Experiment.
Вопросы для самопроверки
Заголовок раздела «Вопросы для самопроверки»- Почему исследование клиентов не спасло Kodak?
- Чем отличаются quarterly business review и product initiative review?
- Что проверяют на стадиях Alpha и Beta?
- Что делает product operations и чего она не делает?
Предыдущая: 19. Разработка и оптимизация. Следующая: 21. Награды и стимулы.