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

> Opportunity Solution Tree, или дерево возможностей Терезы Торрес: как задать команде продуктовый результат, сравнить решения и за 10 минут найти красные флаги в дереве.

Статья · Алексей Ишманов · 18 октября 2026 · https://aleksishmanov.ru/blog/opportunity-solution-tree/

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

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

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

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

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

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

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

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

Метод — одна из ступеней цикла продуктового решения: сначала понять задачу, потом выбрать, что делать, потом дёшево проверить и только затем запускать. Дерево отвечает за шаг «выбрать». Весь цикл и восемь методов для него собраны в обзоре [продуктовых решений при неопределённости](/blog/produktovye-resheniya-pri-neopredelennosti/).

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

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

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

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

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

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

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

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

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

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

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

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

Торрес разводит уровни так: «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» — продуктовые результаты помогают двигать бизнесовый.

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

Как выстроить такие связи для всего продукта, показано в материале про [дерево продуктовых метрик](/blog/products-metrics-tree/).

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

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

1. **Договоритесь об одном результате.** Одна команда — одна цель в работе. Торрес предупреждает: несколько целей сразу не дают глубоко разобраться в пространстве возможностей. Общее дерево на всю компанию она тоже не рекомендует.
2. **Наберите возможности из интервью.** Не выдумывайте их на встрече. Торрес пишет, что без хороших входных данных дерево построить почти невозможно. Входные данные — истории клиентов о конкретных случаях в прошлом. Как получить их без вежливого вранья, разобрано в статье про [Mom Test](/blog/mom-test-intervyu-s-klientami/).
3. **Сформулируйте возможность голосом клиента.** «Я не понимаю, почему не загрузился файл» — это возможность. «Нужна подсказка в форме импорта» — уже решение. Проверка от Торрес: есть ли больше одного способа закрыть эту возможность? Если нет — перед вами решение.
4. **Разложите крупные возможности на дочерние.** Наверху — общая боль, ниже — конкретные моменты, где она случается. Работать удобнее с нижним уровнем: там решения обозримы.
5. **Выберите одну целевую возможность.** Сравнивайте возможности между собой, а не реагируйте на последнее громкое интервью или тикет. И не отбрасывайте возможность только потому, что она выглядит сложной.
6. **Придумайте три решения для этой возможности.** Только для неё, а не мозговой штурм по всему дереву.
7. **Выпишите допущения каждого решения и проверьте самые рискованные.** Что должно быть правдой, чтобы решение сработало? Как выбрать допущения для проверки, описано в материале про [карту допущений](/blog/assumption-mapping-karta-dopushcheniy/).
8. **Обновляйте дерево по ходу.** Первый черновик не стоит доводить до идеала: он изменится после следующих интервью. Как часто пересматривать дерево, сказано в частых вопросах ниже.

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

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

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

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

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

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

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

AI-агент может выиграть сравнение — например, если ошибки разнородные и зависят от настроек аккаунта. Но теперь это вывод из тестов, а не стартовая точка. Сколько денег разумно потратить на каждый тест, помогает решить [ценность информации по Хаббарду](/blog/value-of-information-hubbard/).

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

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

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

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

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

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

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

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

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

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

- **Уберите барьер рекрутинга.** Договоритесь с продажами и поддержкой, что команда может каждую неделю получать один-два контакта клиентов без согласований.
- **Выделите время в календаре.** Один слот в неделю у тройки закреплён под интервью, как планирование спринта.
- **Спрашивайте про выводы, а не про количество.** «Что вы узнали на интервью во вторник?» работает лучше, чем KPI по числу звонков.
- **Следите за искажением.** Команда, которая ищет в интервью подтверждение уже выбранной фичи, найдёт его. Как это выглядит на практике, описано в статье про [предвзятость подтверждения в данных](/blog/confirmation-bias-v-dannyh-komanda-6-mesyatsev-validiruet-to-vo/).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Источники

- Teresa Torres. [Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes](https://www.producttalk.org/opportunity-solution-trees/). Product Talk, 6 декабря 2023; метод описывается с 2016 года.
- Teresa Torres, Hope Gurion. [Defining Product Outcomes: The 8 Most Common Mistakes You Should Avoid](https://www.producttalk.org/defining-product-outcomes/). Product Talk, 21 декабря 2022.
- Teresa Torres. [Continuous Discovery Habits](https://www.producttalk.org/continuous-discovery-habits/). Product Talk, анонс книги от 19 мая 2021.
- Teresa Torres. [Product Trio](https://www.producttalk.org/product-trio/). Product Talk, 5 мая 2021.
- Teresa Torres. [Ask Teresa: What’s the Difference Between OKRs and Outcomes?](https://www.producttalk.org/2023/03/okrs-vs-outcomes/) Product Talk, 8 марта 2023.