Continuous Discovery и дерево возможностей: как находить, что строить

В русскоязычной среде про Continuous Discovery и Opportunity Solution Tree пишут мало, хотя в продуктовом мире это давно рабочая классика. Подход описала Тереза Торрес, и суть его проста: чтобы делать нужный продукт, надо регулярно разговаривать с теми, для кого ты его делаешь, и честно связывать свои решения с их реальными болями. Звучит очевидно, но большинство команд так не работает: фичи придумывают на совещаниях, спорят на основе мнений и узнают, что промахнулись, только после запуска. В этой статье разберу по-человечески: что такое непрерывное исследование, зачем нужно дерево возможностей и решений, как внедрить это у себя и каких ошибок избегать.

Что это простыми словами

Continuous Discovery дословно — «непрерывное исследование». Это привычка команды постоянно, а не от случая к случаю, узнавать новое о своих пользователях. Противоположность — discovery как разовый проект: раз в год заказали большое исследование, получили толстый отчёт, положили на полку и дальше пилим по плану. Проблема в том, что мир меняется быстрее, чем устаревает такой отчёт, и команда снова работает вслепую.

Тереза Торрес формулирует это так: discovery — не этап перед разработкой, а то, что идёт параллельно ей всё время. Пока вы что-то строите, вы одновременно проверяете, туда ли движетесь. Discovery (исследование, что строить) и delivery (собственно разработка) — две ноги, на которых команда идёт: если одна не работает, вы либо строите быстро, но не то, либо понимаете, что нужно, но ничего не выпускаете.

Сердце подхода — правило еженедельных касаний с пользователями. Команда, которая принимает продуктовые решения (обычно связка из продакт-менеджера, дизайнера и инженера), каждую неделю проводит хотя бы один короткий разговор с реальным клиентом. Не масштабное интервью на сто человек раз в квартал, а маленькая, но регулярная порция понимания. Постоянство важнее объёма: лучше говорить с одним пользователем каждую неделю, чем с пятьюдесятью раз в год.

Вторая опора — Opportunity Solution Tree, дерево возможностей и решений. Это визуальная схема, держащая всю логику команды в одном месте. На вершине — желаемый результат, измеримая цель (например, чтобы больше новичков доходили до первой покупки). Ниже ветвятся возможности — боли и потребности пользователей из интервью. Под каждой — идеи решений, как боль закрыть, а под решениями — эксперименты для проверки. Дерево не даёт перескочить сразу к «давайте сделаем кнопку»: каждое решение привязано к конкретной боли, а каждая боль работает на результат.

Зачем это нужно

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

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

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

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

Как применить у себя

Хорошая новость: чтобы начать, не нужны большой бюджет и отдел исследований — нужны привычка и дисциплина. Вот пошаговый план, с которого можно стартовать даже маленькой командой или в одиночку.

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

Второе — спрашивайте про прошлое, а не про будущее. Не «хотели бы вы такую функцию», а «расскажите, как вы в последний раз решали эту задачу». Конкретные истории дают правду, а гипотетические «хотел бы» — вежливые догадки. Слушайте, где было трудно, что раздражало, что человек делал в обход. Это и есть будущие возможности для вашего дерева.

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

Четвёртое — генерируйте решения под выбранную боль. Набросайте несколько идей, а не цепляйтесь за первую же: чем больше вариантов, тем выше шанс найти удачный. И пятое — проверяйте гипотезы экспериментами, прежде чем строить. Спросите: во что мы верим, чтобы это сработало, и как проверить это быстро и дёшево? Маленький прототип, фейковая кнопка, опрос, ручная имитация сервиса — всё это проверяет идею за дни, а не за месяцы. Только прошедшее проверку идёт в разработку.

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

Частые ошибки

Самая частая и коварная ошибка — спрашивать пользователей про решения вместо их проблем. «Нужна ли вам тёмная тема? А уведомления? А интеграция?» Люди из вежливости почти на всё отвечают «да, было бы неплохо», и команда тонет в списке фич, которые на самом деле никому не важны. Задача интервью — понять боль и контекст человека, а придумывать решения — это уже ваша работа, не его. Спрашивайте про то, что человек делал, а не про то, что он хотел бы.

Вторая ошибка — вести discovery «для галочки». Команда честно проводит интервью, рисует красивое дерево, а потом всё равно строит то, что заранее решили на совещании. Исследование превращается в ритуал, который ни на что не влияет. Признак беды — если результаты разговоров никогда не меняют планы. Если discovery не способно остановить или развернуть проект, значит, его нет — есть лишь имитация.

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

Четвёртая ошибка — отдавать discovery одному человеку. Когда интервью проводит только исследователь или продакт, а остальные читают пересказ, инсайты теряются и не вызывают доверия. Дизайнер и инженер, сами слышавшие боль пользователя, принимают совсем другие решения, чем те, кому её пересказали в двух строчках. И пятая ошибка — построить дерево один раз и забыть. Это живой инструмент: новые интервью добавляют ветки, проверенные гипотезы закрывают их, цель меняется. Дерево, которое не обновлялось месяцами, — просто картинка на стене.

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

Чем Continuous Discovery отличается от обычного исследования пользователей? Главное отличие — в ритме. Обычное исследование делают разово: большой проект, отчёт, пауза на год. Непрерывное встроено в работу постоянно, через еженедельные короткие разговоры. Инсайты не успевают устареть, и команда остаётся на связи с реальностью, а не работает по данным годичной давности.

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

Зачем нужно дерево, если можно просто записывать идеи списком? Список идей ничем не связан и растёт бесконечно: непонятно, зачем нужна каждая фича и работает ли она на цель. Дерево показывает логику целиком: от результата к болям, от болей к идеям, от идей к проверкам. Оно заставляет привязывать каждую фичу к реальной потребности пользователя.

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

Continuous Discovery заменяет аналитику и цифры? Нет, они дополняют друг друга. Цифры показывают, что происходит: где люди отваливаются. Разговоры объясняют почему: что человек чувствовал и думал. Аналитика без интервью оставляет с догадками о причинах, а интервью без цифр — без понимания масштаба. Сильные решения опираются и на то, и на другое.

Коротко о главном

Continuous Discovery и Opportunity Solution Tree — про одну простую идею: чтобы строить нужное, надо постоянно слушать тех, для кого строишь, и связывать свои решения с их реальными болями. Непрерывное исследование заменяет редкий разовый ресёрч привычкой еженедельных коротких разговоров. Дерево держит всю логику в одном месте: результат наверху, под ним боли пользователей, под ними идеи решений, а внизу — дешёвые эксперименты для проверки. Главная польза — строить на основе наблюдений, а не интуиции самого громкого в комнате, и ошибаться рано и дёшево. Чтобы начать, достаточно задать ритм интервью, спрашивать про прошлое, построить дерево и проверять гипотезы перед разработкой. Главное — не превращать это в ритуал «для галочки» и не спрашивать пользователей про решения вместо их проблем. Тогда подход перестаёт быть модной теорией и начинает реально подсказывать, что строить.