Opportunity Solution Tree (дерево возможностей): от фич к результату

Opportunity Solution Tree (дерево возможностей) — это схема, которая связывает цель команды с потребностями клиентов, решениями и проверками этих решений. Наверху — желаемый результат, под ним — возможности (боли, нужды и желания клиентов), ещё ниже — решения и тесты допущений. Руководителю дерево показывает, почему команда делает именно эту фичу и что она узнала о клиенте за последний месяц.

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

Типичная ситуация: квартальный роадмап из двадцати фич, все в работе, а метрика, ради которой их делали, не сдвинулась. Никто не может объяснить, какую проблему клиента решала каждая строка. Дерево возможностей лечит именно это: оно не даёт команде начать с решения.

Ниже — откуда метод, как задать команде цель, на которую она реально влияет, пример дерева для AI-агента в поддержке и чек-лист, по которому вы прочитаете дерево своей команды за 10 минут.

Что такое Opportunity Solution Tree и откуда он взялся

Дерево придумала Тереза Торрес, коуч продуктовых команд и автор блога Product Talk. Она описывает его с 2016 года, а в мае 2021-го выпустила книгу «Continuous Discovery Habits», где дерево — один из главных инструментов непрерывного исследования клиентов наряду с интервью и тестами допущений.

Сама Торрес определяет дерево как простой способ визуально показать пути, которыми можно прийти к желаемому результату. В нём четыре уровня:

Желаемый результат (desired outcome). Корень дерева. Он задаёт рамки исследования: какие возможности вообще относятся к делу.
Возможности (opportunities). По Торрес, это неудовлетворённая потребность, боль или желание клиента. Возможности ветвятся: крупная распадается на более конкретные.
Решения (solutions). Варианты, как закрыть выбранную возможность.
Тесты допущений (assumption tests). Быстрые проверки того, на чём держится каждое решение.

Метод — одна из ступеней цикла продуктового решения: сначала понять задачу, потом выбрать, что делать, потом дёшево проверить и только затем запускать. Дерево отвечает за шаг «выбрать». Весь цикл и восемь методов для него собраны в обзоре продуктовых решений при неопределённости.

Почему дерево возможностей важно руководителю

Роадмап фич отвечает на вопрос «что мы сделаем». Дерево отвечает на вопрос «зачем» — и показывает, где команда пропустила шаг.

Метод предотвращает три дорогие ошибки:

Сразу к решению. Клиент попросил интеграцию — команда её строит. Просьба клиента — это его вариант решения, а не его проблема. Подробно эту ловушку разбирает статья «Боль vs просьба».
Одно решение на проблему. Если вариант один, сравнивать не с чем, и команда влюбляется в первую идею. Торрес советует выбрать три решения для целевой возможности и сравнивать их между собой.
Цель, на которую команда не влияет. «Вырастить выручку на 20%» — цель компании. Команде с такой целью остаётся только выпускать фичи и надеяться.

Цена любой из них — обычно квартал работы команды (оценка статьи, а не Торрес). Посчитайте фонд оплаты продуктовой тройки и разработчиков за три месяца: столько стоит фича, которую никто не использует.

Продуктовый или бизнес-результат: какую цель поставить команде

Торрес прямо пишет: как правило, она хочет видеть наверху дерева продуктовый результат (product outcome). Бизнес-результат (business outcome) команде трудно сдвинуть: непонятно, как на него влиять, а продуктовый результат находится в её зоне контроля.

Тип цели	Что измеряет	Пример	Кто влияет
Бизнес-результат	Здоровье компании	Выручка, доля рынка, стоимость поддержки	Вся компания
Продуктовый результат	Поведение клиента в продукте	Доля клиентов, решивших вопрос без обращения в поддержку	Одна продуктовая команда
Метрика использования (traction metric)	Использование одной функции	Доля пользователей, открывших отчёт	Команда, но поле слишком узкое
Поставка (output)	Выпуск фичи	«Запустить чат-бота к 1 декабря»	Команда, но это не результат

В статье о восьми ошибках при выборе продуктового результата Торрес и Хоуп Гурион перечисляют самые частые. Три из них руководитель видит сразу:

Поставка вместо результата. «Запустить AI-агента» записали в OKR — это всё ещё фича.
Цель вне зоны контроля. Выручку и долю рынка напрямую двигают очень немногие продуктовые команды.
Слишком узкая метрика использования. Цель «больше открытий отчёта» оставляет команде одно решение и не говорит, получил ли клиент ценность.

Рабочая формула для руководителя — связка из двух уровней:

Бизнес-результат (ваша зона):      снизить стоимость поддержки на клиента
            ↓ почему поможет
Продуктовый результат (зона команды): доля вопросов, которые клиент
                                      решил сам, без создания тикета

Торрес разводит уровни так: «Business outcomes measure the health of the business. Product outcomes measure a change in customer behavior» — бизнес-результат измеряет здоровье компании, продуктовый — изменение поведения клиента. И связывает их одной фразой: «My product outcomes help me drive my business outcome» — продуктовые результаты помогают двигать бизнесовый.

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

Как выстроить такие связи для всего продукта, показано в материале про дерево продуктовых метрик.

Как построить дерево возможностей: пошагово

Дерево собирает продуктовая тройка — так Торрес называет связку продакт-менеджера, дизайнера и инженера. Мы советуем руководителю не участвовать в построении: его дело — задать цель и регулярно читать результат.

Договоритесь об одном результате. Одна команда — одна цель в работе. Торрес предупреждает: несколько целей сразу не дают глубоко разобраться в пространстве возможностей. Общее дерево на всю компанию она тоже не рекомендует.
Наберите возможности из интервью. Не выдумывайте их на встрече. Торрес пишет, что без хороших входных данных дерево построить почти невозможно. Входные данные — истории клиентов о конкретных случаях в прошлом. Как получить их без вежливого вранья, разобрано в статье про Mom Test.
Сформулируйте возможность голосом клиента. «Я не понимаю, почему не загрузился файл» — это возможность. «Нужна подсказка в форме импорта» — уже решение. Проверка от Торрес: есть ли больше одного способа закрыть эту возможность? Если нет — перед вами решение.
Разложите крупные возможности на дочерние. Наверху — общая боль, ниже — конкретные моменты, где она случается. Работать удобнее с нижним уровнем: там решения обозримы.
Выберите одну целевую возможность. Сравнивайте возможности между собой, а не реагируйте на последнее громкое интервью или тикет. И не отбрасывайте возможность только потому, что она выглядит сложной.
Придумайте три решения для этой возможности. Только для неё, а не мозговой штурм по всему дереву.
Выпишите допущения каждого решения и проверьте самые рискованные. Что должно быть правдой, чтобы решение сработало? Как выбрать допущения для проверки, описано в материале про карту допущений.
Обновляйте дерево по ходу. Первый черновик не стоит доводить до идеала: он изменится после следующих интервью. Как часто пересматривать дерево, сказано в частых вопросах ниже.

Если хочется собрать первый черновик с ИИ, есть готовый промт-консультант по OST. Он ведёт команду по методу Торрес от желаемого результата до экспериментов. Но возможности он не заменит: их всё равно приносят интервью.

Пример дерева возможностей: AI-агент в поддержке B2B SaaS

Пример условный: B2B SaaS для учёта складских остатков, где в роадмапе уже стоит «AI-агент в чате». Клиенты загружают файлы с товарами, а руководство хочет снизить нагрузку на поддержку. Вот как та же задача выглядит деревом.

РЕЗУЛЬТАТ: доля вопросов, которые клиент решил сам, без тикета
│
├── ВОЗМОЖНОСТЬ: «Я не понимаю, почему не загрузился файл»
│   ├── «Ошибка говорит "invalid format", а что не так — неясно»   ← целевая
│   │   ├── РЕШЕНИЕ A: AI-агент в чате отвечает по базе знаний и логу импорта
│   │   │   ├── тест: прогнать агента на 50 прошлых тикетах об импорте,
│   │   │   │         эксперт поддержки оценивает правильность ответов
│   │   │   └── тест: кнопка «Спросить ассистента» на экране ошибки —
│   │   │             сколько клиентов нажмут до создания тикета
│   │   ├── РЕШЕНИЕ B: ошибка с указанием строки и столбца + ссылка на исправление
│   │   │   └── тест: показать 5 клиентам макет ошибки на их же сломанном файле
│   │   └── РЕШЕНИЕ C: проверка файла до загрузки по шаблону
│   │       └── тест: дать шаблон 10 клиентам с частыми ошибками импорта
│   └── «Файл загрузился, но часть товаров пропала»
│
├── ВОЗМОЖНОСТЬ: «Хочу знать статус своего обращения, не переписываясь»
│
└── ВОЗМОЖНОСТЬ: «Не могу найти, как настроить права сотрудников»

Что здесь произошло. Строка роадмапа «AI-агент» превратилась в одно из трёх решений для конкретной боли. И у команды появился честный вопрос: может, сообщение об ошибке с номером строки закроет большую часть таких тикетов за неделю работы, без модели и затрат на её запуск?

Таблица сравнения решений для целевой возможности:

Решение	Ключевое допущение	Самый дешёвый тест	Риск, если допущение ложно
A. AI-агент в чате	Агент правильно объясняет ошибку по логу	Прогон на прошлых тикетах	Неверные ответы, клиент всё равно пишет в поддержку, доверие падает
B. Понятная ошибка	Клиент сам исправит файл, если знает строку	Макет на сломанном файле клиента	Клиенту нужна не подсказка, а исправление за него
C. Проверка до загрузки	Клиенты станут пользоваться шаблоном	Шаблон для 10 клиентов	Шаблон игнорируют, ошибки остаются

AI-агент может выиграть сравнение — например, если ошибки разнородные и зависят от настроек аккаунта. Но теперь это вывод из тестов, а не стартовая точка. Сколько денег разумно потратить на каждый тест, помогает решить ценность информации по Хаббарду.

Как прочитать дерево своей команды за 10 минут

Дерево, которое никто не читает, через месяц превращается в картинку для отчёта. Попросите команду показать текущую версию и пройдитесь по ней сверху вниз.

Минуты	Что смотреть	Красный флаг
0–2	Корень	Наверху фича, проект или выручка компании. Или целей несколько
2–5	Возможности	Сформулированы как фичи: «нужен AI-чат», «добавить фильтр». Нет ссылки на интервью
5–7	Решения	Висят прямо под результатом, без возможности над ними. Одно решение на возможность
7–9	Тесты	Тестов нет, или тест — это «запустим и посмотрим метрику»
9–10	Динамика	Дерево не менялось месяц. Целевая возможность та же, новых веток нет

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

Вопросы, которые стоит задать после просмотра:

Почему выбрана именно эта целевая возможность, а не соседняя?
Какие три решения вы сравнивали и почему отбросили два?
Какое допущение вы проверили на этой неделе и что узнали?
Что в дереве изменилось после последних интервью?
Если мы сдвинем этот продуктовый результат, почему двинется бизнес-цель?

Ответы «так решили на планировании» или «это попросил крупный клиент» — повод разобрать дерево вместе, а не повод для разноса.

Еженедельные контакты с клиентами: привычка, без которой дерево мертво

Дерево — это не разовый воркшоп. Торрес пишет прямо: интервьюировать клиентов нужно непрерывно, неделя за неделей. Без свежих интервью возможности берутся из головы, и дерево подтверждает то, что команда и так собиралась сделать.

Как поддержать привычку на уровне руководителя:

Уберите барьер рекрутинга. Договоритесь с продажами и поддержкой, что команда может каждую неделю получать один-два контакта клиентов без согласований.
Выделите время в календаре. Один слот в неделю у тройки закреплён под интервью, как планирование спринта.
Спрашивайте про выводы, а не про количество. «Что вы узнали на интервью во вторник?» работает лучше, чем KPI по числу звонков.
Следите за искажением. Команда, которая ищет в интервью подтверждение уже выбранной фичи, найдёт его. Как это выглядит на практике, описано в статье про предвзятость подтверждения в данных.

Когда дерево возможностей не нужно

Метод требует времени на интервью и сравнение. Торрес сама признаёт, что у команд не всегда есть время сравнивать несколько решений. Сравнение особенно окупается, когда риск высок, возможность важна для отличия от конкурентов или нужно нестандартное решение.

Дерево можно не строить, если:

Работа обязательная. Требование регулятора, безопасность, миграция с отключаемой платформы. Решение уже задано извне.
Решение дешёвое и обратимое. Поправить текст кнопки быстрее, чем обсуждать три альтернативы.
Нет доступа к клиентам. Без интервью дерево превращается в мозговой штурм в красивой рамке. Сначала решите вопрос доступа.
Цели нет. Если руководство не может назвать продуктовый результат для команды, дерево построить не из чего. Это задача руководителя, а не команды.

Как внедрить за неделю: чек-лист руководителя

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

Роадмап при этом не обязательно выбрасывать. Строки, которые уже в работе, можно повесить на дерево и посмотреть, какой возможности они служат. Строки, для которых возможность не нашлась, — первые кандидаты на паузу.

Частые вопросы

Чем Opportunity Solution Tree отличается от дерева метрик?

Дерево метрик раскладывает бизнес-показатель на измеримые составляющие. Дерево возможностей раскладывает одну продуктовую цель на потребности клиентов и способы их закрыть. Их удобно использовать вместе: дерево метрик подсказывает, какой продуктовый результат поставить команде, дерево возможностей — как его сдвинуть.

Можно ли поставить наверх дерева выручку?

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

Сколько решений нужно на одну возможность?

Торрес советует выбирать три решения для целевой возможности и сравнивать их. Смысл не в числе, а в сравнении: при одном варианте команде не с чем его сопоставить. Для дешёвых и обратимых изменений хватит одного.

Кто строит дерево — продакт или вся команда?

По Торрес, исследование ведёт продуктовая тройка: продакт-менеджер, дизайнер и инженер. Дерево — их общий артефакт. Если его рисует один продакт, остальные видят готовый вывод без истории, и решения снова спускаются сверху.

Как часто обновлять дерево возможностей?

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

Источники

Teresa Torres. Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes. Product Talk, 6 декабря 2023; метод описывается с 2016 года.
Teresa Torres, Hope Gurion. Defining Product Outcomes: The 8 Most Common Mistakes You Should Avoid. Product Talk, 21 декабря 2022.
Teresa Torres. Continuous Discovery Habits. Product Talk, анонс книги от 19 мая 2021.
Teresa Torres. Product Trio. Product Talk, 5 мая 2021.
Teresa Torres. Ask Teresa: What’s the Difference Between OKRs and Outcomes? Product Talk, 8 марта 2023.