Команда генерит 50 идей в квартал. Реализует 12. Работают 2. Что не так с discovery?

200 задач в бэклоге, и ни одна не двигает метрику

Дима, Head of Product в EdTech-стартапе на 40 человек. Команда из 3 продактов и 12 разработчиков. Бэклог — 200+ задач. Каждый квартал генерят 50 идей, реализуют 12, из которых двигают метрики — максимум 2.

Приоритизация — по RICE. Или по крику. Или по тому, что CEO увидел у конкурента. Discovery-процесс = еженедельная встреча на час, где продакты питчат идеи, а разработчики считают story points.

Результат: 83% engineering-ресурсов тратится на фичи, которые не влияют ни на retention, ни на revenue. Через 9 месяцев — Дима получает обратную связь от борда: «У вас product-market fit или нет?». Он не знает.

Проблема Димы — не в команде и не в идеях. Проблема в отсутствии структуры между бизнес-результатом и конкретным экспериментом. Между «нужно вырастить retention» и «давайте сделаем push-уведомления» — пропасть из предположений, которые никто не проверял.

Что такое Opportunity Solution Tree

Opportunity Solution Tree (OST) — это визуальная структура, которая связывает бизнес-результат (Outcome) с конкретными экспериментами через два промежуточных слоя: Opportunities и Solutions.

Тереза Торрес описала OST в книге «Continuous Discovery Habits» (2021). Идея проста, но контринтуитивна для большинства продуктовых команд: не начинайте с решений. Начните с результата, найдите возможности, сгенерируйте решения, проверьте через эксперименты.

graph TD
    O["🎯 Outcome
Увеличить 30-day retention
с 35% до 50%"]
    O --> OP1["Opportunity 1
Новые пользователи не находят
ценность в первые 3 дня"]
    O --> OP2["Opportunity 2
Пользователи забывают
вернуться после 1-й сессии"]
    O --> OP3["Opportunity 3
Контент заканчивается
через 2 недели"]
    OP1 --> S1["Solution A
Guided onboarding
с прогресс-баром"]
    OP1 --> S2["Solution B
Персональная подборка
контента при входе"]
    OP2 --> S3["Solution C
Email-цепочка на 7 дней
с highlights"]
    OP2 --> S4["Solution D
Push-уведомления
с новым контентом"]
    OP3 --> S5["Solution E
UGC: пользователи
создают контент"]
    S1 --> E1["Эксперимент
Прототип onboarding
10 пользователей"]
    S3 --> E2["Эксперимент
A/B email vs без
500 пользователей"]
    S5 --> E3["Эксперимент
Concierge: ручной
сбор UGC от 5 авторов"]
    

4 уровня. Одно дерево. Каждый уровень отвечает на свой вопрос:

Уровень	Вопрос	Источник данных	Типичная ошибка
Outcome	Какой результат нужен бизнесу?	Стратегия, OKR, unit economics	Слишком абстрактный: «улучшить продукт»
Opportunity	Какие потребности/боли клиентов связаны с этим результатом?	Интервью, данные продукта, поддержка	Путать с решением: «нужен чат-бот» — это Solution, не Opportunity
Solution	Как мы можем закрыть эту возможность?	Мозговой штурм, аналоги, прототипы	Генерировать одно решение вместо 3+
Experiment	Как проверить, что решение работает?	A/B-тесты, прототипы, concierge	Строить MVP вместо эксперимента

Уровень 1: Outcome — начните с метрики, а не с идеи

Outcome — это измеримый бизнес-результат, на который команда может повлиять в горизонте квартала.

Торрес выделяет три критерия хорошего Outcome:

1. Измеримый: есть число и дата. «Увеличить 30-day retention с 35% до 50% к Q3» — хорошо. «Улучшить retention» — плохо
2. Контролируемый: команда может на него повлиять. «Увеличить revenue» — слишком далеко. «Увеличить конверсию триал→платный» — в зоне влияния
3. Клиентский: связан с поведением пользователя, а не с внутренней метрикой. «Выпустить 5 фичей» — output, не outcome

И вот что интересно:

Большинство команд путают Outcome и Output. «Выпустить мобильное приложение» — это Output. «Увеличить DAU/MAU с 0.3 до 0.5» — это Outcome. Разница колоссальная: Output можно выполнить и провалить цель. Outcome нельзя «выполнить» — его можно только достичь или нет.

Уровень 2: Opportunity — не «что делать», а «что болит»

Opportunity — это потребность, боль или желание клиента, которое связано с целевым Outcome. Не решение.

Торрес подчёркивает: самая частая ошибка — формулировать Opportunity как Solution. «Нужен чат-бот» — это Solution. «Пользователи не получают ответ на вопрос в первые 5 минут» — это Opportunity.

Как отличить:

Opportunity (правильно)	Solution (неправильно)
«Пользователи не понимают, с чего начать»	«Нужен onboarding-визард»
«Клиенты забывают вернуться»	«Нужны push-уведомления»
«Контент заканчивается быстрее, чем ожидают»	«Нужен UGC-модуль»
«Руководители не видят прогресс подчинённых»	«Нужен дашборд для менеджеров»

Источники Opportunities: custdev-интервью (еженедельные, по Торрес — минимум 1 интервью в неделю), данные продукта (воронки, drop-off), обращения в поддержку, NPS-комментарии, сессии Hotjar/FullStory.

Звучит просто? Не совсем.

На практике 80% команд никогда не формулируют Opportunities отдельно. Они прыгают от Outcome к Solution напрямую: «retention падает → давайте сделаем email-цепочку». Без слоя Opportunities вы не знаете, почему retention падает — и ваше решение с высокой вероятностью мимо.

Уровень 3: Solution — минимум три варианта

Торрес настаивает: для каждой Opportunity генерируйте минимум 3 Solution. Одно решение = нет выбора = нет оптимизации.

Почему три, а не одно? Потому что первая идея — обычно самая очевидная. А самая очевидная — редко самая эффективная. Когда команда генерирует 3+ решений, происходит «creative collision» — идеи комбинируются, рождаются неочевидные варианты.

Правила генерации Solutions:

• Каждое решение должно закрывать конкретную Opportunity
• Решения могут быть разного масштаба: от «изменить текст кнопки» до «новая система рекомендаций»
• Не оценивать решения на этапе генерации — оценка = эксперименты
• Допустимы решения, которые кажутся «глупыми» — именно они часто оказываются лучшими

Уровень 4: Experiment — не MVP, а тест предположения

Эксперимент ≠ MVP. Эксперимент — это минимальное действие, которое проверяет одно конкретное предположение.

Торрес выделяет три типа экспериментов по «тяжести»:

Тип	Что проверяет	Пример	Стоимость
Assumption test	Верно ли наше предположение?	«Пользователи не находят ценность в первые 3 дня» — проверяем через анализ time-to-value в аналитике	0 — часы
Prototype test	Понятно ли решение пользователю?	Кликабельный прототип onboarding → 10 usability-тестов	Дни
Concierge test	Решает ли решение проблему?	Вручную собираем персональную подборку контента для 20 пользователей, замеряем возвращение	Дни — неделя

А теперь самое важное:

Порядок имеет значение. Сначала Assumption test (бесплатно). Если предположение подтверждается — Prototype test (дёшево). Если прототип работает — Concierge test (дороже, но ещё без кода). И только потом — разработка.

Дима из нашего кейса раньше тратил 2-4 недели разработки на каждую гипотезу. С OST — первые два уровня тестирования занимают 1-3 дня. 70% гипотез отсеиваются до написания кода.

OST vs другие фреймворки приоритизации

OST — не замена RICE или ICE. Это другой слой: OST определяет «что тестировать», а RICE — «в каком порядке строить подтверждённое».

Фреймворк	Отвечает на вопрос	Слабость
RICE	«Какую фичу строить первой?»	Не проверяет, нужна ли фича вообще
ICE	«Что протестировать первым?»	Субъективные оценки Impact/Confidence/Ease
Story Mapping	«Как разбить фичу на релизы?»	Не связывает фичу с бизнес-результатом
OST	«Какую гипотезу проверить, чтобы двигать метрику?»	Требует еженедельных интервью (дисциплина)

В идеальном мире: OST определяет, какие решения стоит строить. RICE приоритизирует подтверждённые решения в бэклоге разработки. Они не конкурируют — они работают последовательно.

Еженедельные интервью: двигатель OST

Торрес настаивает на минимуме 1 интервью в неделю. Не «когда есть время». Не «раз в квартал». Каждую неделю.

Это кажется невозможным. Где брать респондентов? Как тратить время? Торрес предлагает «continuous discovery» — короткие 20-минутные интервью, встроенные в повседневный workflow:

• Добавить вопрос в onboarding: «Что вы пытались сделать до того, как нашли нас?»
• Звонить каждому, кто отменил подписку (5 минут)
• Проводить 15-минутное интервью после demo-звонка
• Встроить feedback-виджет с открытым вопросом в продукт

Каждое интервью = потенциальная новая Opportunity на дереве. Дерево растёт еженедельно. Это живой документ, не квартальный артефакт.

5 ошибок при внедрении OST

OST выглядит просто. Внедрить его правильно — сложнее, чем кажется.

1. Outcome = output

«Выпустить мобильное приложение» — это не Outcome, это Output. Outcome — что изменится для пользователя, когда приложение выпущено. «Увеличить DAU/MAU с 0.3 до 0.5» — вот Outcome.

2. Opportunity = Solution

«Нужен чат-бот» — Solution. «Пользователи не получают ответ на вопрос в первые 5 минут» — Opportunity. Если ваше дерево состоит из «нужно X, нужно Y, нужно Z» — вы пропустили слой Opportunities.

3. Одно Solution на Opportunity

Одно решение = нет выбора. Вы не «выбрали лучшее» — вы просто пошли с первым, что пришло в голову. Минимум 3 Solutions на Opportunity. Всегда.

4. Строить вместо тестировать

«Давайте сделаем MVP» на каждую гипотезу — это 2-4 недели кода. Assumption test — 2 часа. Prototype test — 2 дня. 70% гипотез отсеиваются до кода. Экономия — месяцы разработки.

5. Статичное дерево

OST — живой документ. Если дерево не менялось 3 недели — вы не проводите интервью. Или не обновляете дерево по результатам экспериментов. И то, и другое — антипаттерн.

OST и Product DNA: как они связаны

OST — инструмент discovery-процесса. Product DNA — фреймворк продуктового интеллекта. OST организует процесс, Product DNA наполняет его данными.

Связь через слои Product DNA:

Уровень OST	Product DNA Strand	Что даёт
Outcome	Strand 6: Growth Mechanics	5 типов петель роста определяют, какие метрики — leading indicators
Opportunity	Strand 3: Demand Architecture	L5 (Friction Points) — готовый список Opportunities из структурированных данных
Solution	Strand 7: Execution Protocol	Demand-Weighted Priority Score ранжирует Solutions по влиянию на спрос
Experiment	Strand 5: Evidence Engine	26 Evidence Points показывают, какие предположения уже подтверждены, а какие — нет

Торрес говорит: «проводите интервью каждую неделю». Product DNA уточняет: проводите интервью, собирая 26 Evidence Points, и считайте Bayesian Confidence для каждого предположения. Это не противоречие — это углубление.

Как начать с OST за 1 неделю

Не нужно перестраивать весь процесс. Начните с одного дерева для одной метрики.

1. День 1: Выберите один Outcome. Конкретная метрика, конкретный срок. «Retention 35%→45% за Q3»
2. День 2-3: Проведите 3 интервью с пользователями, которые ушли (или не конвертировались). Запишите Opportunities — потребности и боли, связанные с Outcome
3. День 4: Мозговой штурм: 3 Solutions на каждую из топ-3 Opportunities. 15 минут, таймер, без критики
4. День 5: Выберите 2-3 самых рискованных предположения. Спланируйте Assumption tests на следующую неделю
5. Неделя 2+: 1 интервью в неделю + обновление дерева + 1-2 эксперимента в спринт

Через месяц у вас будет живое дерево с 5-10 проверенными предположениями. Это больше validated learning, чем у большинства команд за квартал.

AI CPO автоматически строит Demand Architecture из ваших разговоров с клиентами — готовый фундамент для слоя Opportunities в OST.

Начните строить Opportunity Solution Tree для вашего продукта → aicpo.ru