Escaping the Build Trap, глава 1: Система обмена ценностью

Главная мысль: компания попадает в build trap, когда считает успехом количество выпущенных фич, а не пользу для клиента и бизнеса. Ценность появляется только тогда, когда продукт решает проблему клиента.

Часть I: что такое build trap

Build trap — ловушка, в которой компания меряет успех через output, а не через outcome.

• Output — то, что сделали: фичи, релизы.
• Outcome — что изменилось для клиента и бизнеса.
• Компания думает о выпуске фич. Она не думает о пользе этих фич.
• Клиенты не получают ценности. Компания теряет рынок. Её могут обогнать конкуренты.
• Выход — сильный и осознанный product management. Тогда продакт-менеджеры ищут возможности, которые дают ценность и бизнесу, и клиенту.

История Marquetly

Marquetly — онлайн-школа для маркетологов. Эксперты делают курсы. Студенты платят месячную подписку.

Что было в компании:

• Выручка росла примерно на 30% в год. Компания быстро наняла сотни людей.
• Перешли на Scrum. Понадобились продакт-менеджеры.
• На эту роль поставили маркетологов без опыта в продукте.
• VP of product Карен руководила 20 людьми. На стратегию у неё не было времени.
• Отдел продаж обещал enterprise-клиентам фичи, которых ещё не было.
• В работе было 20 крупных проектов. На каждый — один джуниор-продакт и одна команда.
• Бонусы зависели от того, выпустил человек фичи или нет.

Что случилось:

1. Автор учила продактов новым методам. Сначала были успехи.
2. Через три месяца команды ничего не выпустили. Руководство разозлилось.
3. Продакты бросили исследования пользователей. Они стали просто писать user stories.
4. За месяц выпустили около 10 фич. Руководство радовалось.
5. Фичи плохо протестировали. Сайт ломался.
6. Новые функции мешали преподавателям создавать курсы и отвечать студентам. Часть преподавателей убрала свои курсы.
7. Студенты новыми фичами не пользовались. Выручка продолжала падать.

Почему это не вина продактов

Автор называет проблемы всей организации:

Проблема	Как это выглядело
Нет общей цели	CEO хотел рост выручки. CTO говорил про мобильную стратегию. Карен — про новых преподавателей. Продажи — про enterprise-клиентов
Слишком много приоритетов	Всё «номер один». Много стратегических задач на мало людей (peanut-buttering)
Нет обратной связи	Люди боятся спорить с руководством
Неверные стимулы	Бонусы за выпуск софта, а не за решение проблем
Не те люди в роли	Маркетологи, а не продакт-менеджеры

Вывод автора: компании нужно стать product-led. Нужно менять структуру, стратегию, процессы, политики и награды.

Build trap — это про всю компанию

• Kodak не ответила на цифровую фотографию. Она продолжала работать по-старому. Когда попробовала меняться, было поздно.
• Microsoft долго полагалась на Windows. Сатья Наделла перестроил компанию под новую стратегию.
• Build trap — это путаница между мерами прогресса (output) и мерами ценности.
• Смотреть нужно на всю компанию, а не только на команду разработки.

Обмен ценностью

Компании работают на обмене ценностью:

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

Ценность для бизнеса — это то, что питает бизнес: деньги, данные, знания, продвижение. Каждая фича должна давать результат, который связан с этой ценностью.

Ценность для клиента измерить сложнее. Продукт сам по себе не ценен. Ценно то, что он делает для клиента.

Фичи как ложная метрика

Если компания плохо знает проблемы клиентов, она подменяет ценность тем, что легко посчитать. Это proxy-метрика: число выпущенных фич.

Та же подмена идёт в оценке людей:

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

Пример с дата-платформой. У компании было 30 фич и ещё 40 в бэклоге. Клиенты постоянно пользовались только 2% фич. Но команда продолжала строить новые.

Почему так вышло:

• Компания копировала конкурентов фича за фичей. Она не знала, работают ли эти фичи у конкурентов. Так же ошибся Google+, когда копировал Facebook.
• Продажи обещали клиентам всё ради контракта. Получилось много фич для одного клиента.
• Компания жила в реактивном режиме. Она строила без намерения.

Value Exchange System

Чтобы понять, какие продукты нужны, надо глубоко знать клиентов. Для этого сотрудники должны быть ближе к клиентам. Политики компании должны это поддерживать.

Политики — пример ограничения в этой системе. Об ограничениях — следующая глава.

Ключевые термины

Термин	Значение
Build trap	Ловушка, где успех меряют числом фич, а не пользой
Output	То, что команда выпустила: фичи, релизы
Outcome	Результат для клиента и бизнеса
Value exchange	Обмен: компания решает проблему клиента, клиент даёт ценность бизнесу
Value Exchange System	Вся система обмена ценностью вместе с её ограничениями
Product-led	Компания, где рост идёт от успеха продуктов
Peanut-buttering	Много стратегических задач на мало людей

Что это значит на практике

• Перед новой витриной или дашбордом спросите: какую проблему бизнеса он решает? Кто им будет пользоваться и какое решение примет?
• Считайте не число dbt-моделей и дашбордов, а их использование. Посмотрите логи BI-инструмента: часто реально смотрят малую часть дашбордов, как с 2% фич в примере.
• Не делайте отдельную модель под каждый запрос одного заказчика. Ищите общие сущности и метрики, которые нужны многим.
• Помогите продакту измерять outcome. Постройте события и модели, которые показывают использование фич после релиза, а не только факт релиза.
• Если в команде всё «приоритет номер один», попросите связать каждую задачу с одной целью компании.

Вопросы для самопроверки

1. Чем output отличается от outcome? Приведите пример из своей работы.
2. Какие ошибки организации привели Marquetly в build trap?
3. Когда клиент отдаёт ценность бизнесу в системе обмена ценностью?
4. Почему число фич — плохая метрика успеха?

Предыдущая: Обзор книги. Следующая: 2. Ограничения обмена ценностью.