Discovery vs Delivery: дуальная воронка продукта

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

Модель сформулировал Марти Каган из Silicon Valley Product Group и подробно описал в книгах Inspired и Empowered. Принцип лёг в основу того, что Каган называет «современным продуктовым подходом» — отличия зрелых продуктовых команд от классической разработки по требованиям заказчика. Освоение модели требует пересмотра ролей, ритмов работы и метрик успеха.

Что такое продуктовый Discovery

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

Discovery отвечает на четыре риска любого продуктового решения:

• Value risk — будут ли пользователи покупать или использовать это решение
• Usability risk — смогут ли пользователи разобраться, как им пользоваться
• Feasibility risk — сможет ли команда это построить с имеющимися технологиями и ресурсами
• Business viability risk — работает ли решение для бизнеса с учётом юридических, финансовых, маркетинговых и операционных ограничений

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

Что такое продуктовый Delivery

Delivery — работа по качественной реализации выбранных решений. Это разработка production-кода, тестирование, релиз, поддержка. Цель delivery — выпустить функцию надёжно, в срок, с заявленным качеством. Discovery определяет, что строить; delivery — как построить хорошо.

В delivery применяются классические инженерные практики: Agile-итерации, CI/CD, code review, автотестирование, мониторинг в продакшене. Это понятная и хорошо структурированная работа со зрелыми инструментами и методологиями.

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

Двойная воронка как организационная модель

Discovery и delivery идут параллельно, не последовательно. Пока команда строит уже одобренные решения, продакт-менеджер с дизайнером и аналитиком работают над следующими гипотезами. Через несколько недель новые гипотезы пройдут проверку и пополнят список того, что стоит строить.

Кто работает в discovery

Discovery-команда минимально состоит из трёх ролей: продакт-менеджер, продакт-дизайнер, тех-лид (или старший разработчик). Каждый отвечает за свой риск.

• Продакт-менеджер — за value и business viability. Знает рынок, конкурентов, бизнес-модель, говорит с пользователями и стейкхолдерами
• Дизайнер — за usability. Проектирует решение, проводит юзабилити-тесты, итерирует на основе обратной связи
• Тех-лид — за feasibility. Оценивает сложность реализации, риски архитектуры, ограничения существующего стека

В сильных командах все три роли участвуют в discovery с самого начала. Это не последовательность «менеджер придумал → дизайнер нарисовал → разработчик оценил», а совместная работа над одной задачей с разных углов.

Поддерживающие роли

В discovery дополнительно участвуют исследователи пользователей (если они есть в компании), аналитики данных, специалисты по маркетингу, представители саппорта и продаж. Их вклад — данные о текущем поведении пользователей, обратная связь от клиентов, понимание барьеров на пути к покупке.

Continuous Discovery — школа Терезы Торрес

Тереза Торрес развила модель Кагана в концепцию continuous discovery: исследование пользователей становится непрерывным еженедельным процессом, а не разовыми проектами. Книга Continuous Discovery Habits описывает методологию с конкретными практиками.

Опportunity solution tree

Центральный артефакт continuous discovery — дерево возможностей. На вершине — бизнес-цель команды. Под ней — пользовательские возможности (проблемы, потребности, желания). Под каждой возможностью — потенциальные решения. Под каждым решением — эксперименты для его проверки.

Дерево не строится за один присест и не считается завершённым. Команда непрерывно пополняет его новыми возможностями из интервью, расставляет приоритеты, тестирует гипотезы, отсеивает невалидные. Видимая структура помогает выбирать, на чём сфокусироваться в следующем спринте.

Еженедельные интервью с пользователями

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

Эта практика противостоит распространённой ошибке: команда придумывает решения исходя из собственных предположений о пользователях, а не из реальных данных. Регулярные интервью держат команду в контакте с реальностью.

Методы discovery

Концепт concierge MVP

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

Методы delivery

Delivery опирается на классические Agile-практики. Конкретный фреймворк зависит от характера работы:

• Scrum — фиксированные спринты по 1–4 недели с целями спринта и ретро. Подходит для команд с предсказуемым входом задач
• Kanban — непрерывный flow с лимитами WIP. Подходит для поддержки, операций, команд с переменным потоком работы
• Shape Up — методология Basecamp с 6-недельными циклами и предварительной фазой shaping. Подходит для зрелых продуктовых команд
• Гибридные подходы — большинство команд комбинируют практики разных фреймворков под свои нужды

Внутри delivery работают стандартные инженерные практики: code review, автотесты, CI/CD, мониторинг, постмортемы инцидентов. Эти практики не относятся к продуктовой методологии — это базовая инженерная зрелость.

Как соединяются два трека

Discovery и delivery не существуют изолированно. Точки соединения определяют здоровье продуктовой команды.

Backlog как мост

Результат discovery попадает в product backlog: проверенные гипотезы превращаются в задачи для разработки. Delivery-команда берёт задачи из backlog в спринты. Между этими этапами должен быть зрелый процесс grooming, где команда уточняет требования, оценивает сложность, формирует acceptance criteria.

Возврат из delivery в discovery

Не каждая задача из backlog оказывается готовой к разработке. На этапе grooming или в начале спринта команда может обнаружить, что задача недостаточно проработана, есть нерешённые usability-вопросы, спорные технические решения. В этом случае задача возвращается на доработку в discovery.

Влияние delivery на discovery

Реальная обратная связь от выпущенных в продакшен функций — главный источник инсайтов для следующих циклов discovery. Метрики использования, обратная связь от пользователей, обнаруженные проблемы — всё это пополняет дерево возможностей.

Распределение времени продуктовой команды

В зрелой продуктовой команде продакт-менеджер тратит на discovery значительную часть рабочего времени. Распределение различается по фазам продукта.

Распределение для разработчиков и дизайнеров другое: они в основном заняты delivery, а в discovery подключаются точечно для проверки feasibility и проектирования прототипов. Но участвуют регулярно — не как одноразовые консультанты.

Антипаттерны продуктовой работы

Feature factory

Команда выпускает функцию за функцией без проверки их ценности. Метрики измеряют velocity и количество релизов, но не влияние на бизнес. Распознать feature factory легко: команда не помнит, какие из последних 10 функций реально что-то изменили в метриках продукта.

Discovery без delivery

Команда увлекается исследованиями, прототипами, концепциями, но мало что доводит до продакшена. Это характерно для продуктовых команд, где нет инженерной дисциплины или организация перегружена бюрократией. Discovery без delivery не создаёт ценности.

Delivery без discovery

Команда строит то, что заказали стейкхолдеры, без проверки реальной потребности. Это классическая модель «разработка по требованиям», ведущая к низкому проценту используемых функций и провалам.

Watergile

Команды называют свой процесс Agile, но фактически продолжают работать по waterfall: длинные циклы requirements → design → development → testing → release. Discovery либо отсутствует, либо делается раз и не пересматривается.

Передача прототипов «через стену»

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

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

Метрики обоих треков

Метрики delivery

• Cycle time — время от старта работы до релиза
• Lead time — время от появления задачи в backlog до релиза
• Deployment frequency — частота релизов в продакшен
• Change failure rate — доля релизов, потребовавших отката или хотфикса
• Mean time to recovery — среднее время восстановления после инцидента

Метрики discovery

• Количество интервью с пользователями в неделю
• Количество гипотез, проверенных за квартал
• Доля гипотез, подтверждённых экспериментами
• Время от формулировки гипотезы до решения о её судьбе
• Количество отвергнутых функций до старта разработки

Полезный признак зрелой команды — отвергнутые гипотезы. Если все идеи проходят в разработку, значит discovery не выполняет функцию фильтра. В здоровых командах 50–70% идей не доходят до delivery.

Discovery в B2B и enterprise

B2B-команды часто говорят, что discovery в их контексте не работает: пользователей мало, доступ к ним ограничен, решения о покупке принимают одни люди, а пользуются продуктом другие. Это правда, но не означает отказа от discovery — это означает другие методы.

• Глубокие интервью с малым числом ключевых клиентов вместо массовых опросов
• Совместные воркшопы с пользователями для прототипирования
• Анализ обращений в саппорт, тикетов, чатов с клиентами
• Пилотные проекты с одним-двумя клиентами на правах early adopters
• Работа с user research через customer success менеджеров

Базовый принцип остаётся: решения проверяются с реальными пользователями до начала разработки. Меняется только инструментарий.

Часто задаваемые вопросы

Может ли одна команда заниматься и discovery, и delivery

Должна, и это правильная модель. Дуальная воронка не означает две разные команды — это два параллельных трека работы одной кросс-функциональной команды. Разделение discovery и delivery на разные команды (исследователи отдельно, разработчики отдельно) — антипаттерн, ведущий к передаче работы через стену.

Сколько времени должен занимать discovery до старта разработки

Зависит от сложности и риска. Простая функция может пройти discovery за неделю с быстрым прототипом и парой юзабилити-тестов. Принципиально новая возможность требует месяцев исследований. Главный критерий — снижение неопределённости до приемлемого уровня для всех четырёх рисков (value, usability, feasibility, viability).

Что если стейкхолдеры настаивают на конкретной функции

Это нормальная ситуация. Задача продакт-менеджера — превратить «функцию» обратно в «проблему» и провести discovery вокруг проблемы. Часто оказывается, что лучшее решение проблемы — не то, что предлагали стейкхолдеры. Открытый диалог с данными исследований обычно убеждает.

Как разработчики участвуют в discovery без потери времени на код

Точечно, на ключевых решениях. Тех-лид участвует в формулировке гипотез, оценке feasibility, проектировании архитектуры решения. Это 10–20% его времени. Старшие разработчики могут участвовать в технических спайках для оценки сложности. Полное погружение разработчиков в discovery не требуется — нужно их участие в критических точках.

Чем discovery отличается от исследований UX-департамента

UX-исследования — это часть discovery, но не вся. Discovery включает также бизнес-анализ, проверку технической реализуемости, проверку юнит-экономики, конкурентный анализ. UX-исследователи отвечают за пользовательскую часть, продакт-менеджер собирает картину целиком.

Подходит ли модель для команд из 2–3 человек

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

Заключение

Дуальная воронка Discovery–Delivery — это организационная модель, разделяющая продуктовую работу на поиск правильных решений и их качественную реализацию. Discovery отвечает за value, usability, feasibility и business viability; delivery — за надёжный выпуск выбранных решений в продакшен. Оба трека идут параллельно в одной кросс-функциональной команде, а не последовательно или в разных командах.

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