Opportunity Solution Tree

Opportunity Solution Tree помогает увидеть, где команда перескочила от цели сразу к любимому решению. Дерево полезно как живая карта выбора: outcome должен быть измеримым, opportunities — подтверждёнными потребностями, а эксперименты — снижать конкретную неопределённость до дорогой реализации.

Что такое Opportunity Solution Tree

Определение

Opportunity Solution Tree — это простой визуальный инструмент, который помогает структурировать работу по поиску проблем до фичей и решений. Автор концепции — Тереза Торрес. Дерево делит путь на три части: цели, возможности (opportunities), решения и эксперименты.

Давай на практике

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

Как работает Opportunity Solution Tree в Discovery

Порядок действий

1. Сначала коротко формулируешь продуктовую цель.
2. Разговариваешь с пользователями, наблюдаешь, собираешь обратную связь — ищешь реальные проблемы и ситуации.
3. Фиксируешь найденные opportunities: что мешает, где фрустрация, что бы они хотели.
4. Для каждой возможности придумываешь несколько разных решений, не упираясь в одну идею.
5. Продумываешь быстрые эксперименты или MVP, чтобы проверить главное предположение: сработает ли решение.

В Discovery часто встречается соблазн прыгнуть к идее — но дерево тормозит этот скачок. Ты всегда возвращаешься к реальной проблеме.

Пример из жизни продукта

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

Когда дерево особенно полезно

Моменты роста и неопределенности

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

Антипаттерны

1. Нет цели — непонятно, почему делать дерево.
2. Только одна-две возможности — значит, плохо смотрел на проблемы.
3. Решения дублируют друг друга — креатив на нуле, надо собрать команду и выйти за пределы своего мнения.

Как выжать максимум из Opportunity Solution Tree

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

Брейншторм совместно, приглашай дизайнеров, аналитиков и даже людей из поддержки. Каждый приносит свое видение проблем.

Не бойся менять дерево

Появились новые данные — переделал ветки. Это не бюрократия, а рабочий инструмент.

Держи дерево “живым”

Используй его на еженедельных sync’ах, показывай стейкхолдерам для объяснения приоритетов. Некоторые команды интегрируют ост в Confluence, Miro или FigJam — как живую карту Discovery.

Полезные материалы и ссылки

• Product Talk: Opportunity Solution Trees
• Mind the Product: How to use Opportunity Solution Trees to build better products
• Teresa Torres: Continuous Discovery Habits

FAQ

В чем разница между OST и обычным майндмэпом?
OST всегда связывает решения с четко сформулированными проблемами и бизнес-целями, в отличие от лент идей.

OST работает только для продуктовых команд?
Подходит и для маркетинга, сервисных команд, стартапов любого масштаба.

Как понять, что нашли сильную opportunity?
Есть четкие паттерны в обратной связи пользователей, метрика показывает негативный тренд, команда сама в это верит.

Когда дерево не нужно?
Если задача — просто доработать фичу по баг-репорту или есть четкий рынок и понятные рецепты.

Как работать с деревом, если мало времени?
Используй быстрые User Interview, короткие звонки и материалы поддержки — уже накидка из 3-5 веток сильно помогает выбрать вектор.

Что делать, если идей много, а экспериментов мало?
Приоритизируй через ICE, RICE или другой простой фреймворк — и начинай валидировать не те, что любимы командой, а те, что реально подтянут метрику.