Discovery: находим настоящую проблему, а не выдумываем решение
Разбираемся, почему команды часто решают не те проблемы, и как процесс Discovery, основанный на WHAT-HOW-WHY, помогает приземлить боль в наблюдаемую реальность.
Discovery: находим настоящую проблему, а не выдумываем решение
В продуктовой разработке есть фундаментальный соблазн — как можно скорее перейти к созданию решения. Макеты, планы, задачи в трекере — всё это даёт команде приятное чувство контроля и движения. Но слишком часто это движение в никуда. Команды тратят месяцы на создание элегантных решений для проблем, которых не существует.
Процесс Discovery призван бороться с этим соблазном. Его главная цель — не придумать решение, а поймать реальную поломку и сформулировать её так, чтобы вся команда работала над одной и той же, по-настоящему важной проблемой.
Главный вопрос Discovery
Какую проблему мы решаем на самом деле — и для кого она критична?
Если вы не можете чётко ответить на этот вопрос, любое решение будет лишь гипотезой, построенной на песке.
Фундаментальный принцип
Проблема существует только тогда, когда она мешает пользователю и бизнесу одновременно.
Просто «неудобно» — это ещё не проблема. А вот «неудобно, и из-за этого мы теряем 20% пользователей на этапе активации» — это уже проблема, достойная внимания.
Problem Space vs Solution Space: главное правило Discovery
Весь процесс Discovery можно разделить на две большие части:
- Problem Space (Пространство проблемы): Что именно ломается, у кого, где, почему, и сколько это стоит?
- Solution Space (Пространство решения): Какие варианты вмешательства возможны (кнопки, фичи, редизайн)?
Золотое правило: пока Problem Space не оформлен, обсуждать Solution Space — это как выбирать обои, когда дом горит. Красиво, но бесполезно.
Модель Discovery: WHAT — HOW — WHY
Чтобы структурировать Problem Space, используйте три простые линзы:
1. WHAT — что ломается? (Наблюдаемый симптом)
Это не «пользователям не нравится», а конкретный, измеримый сигнал.
- Примеры:
- Падение конверсии на шаге X с 40% до 25%.
- Рост оттока (churn) в сегменте Y на 15%.
- Всплеск обращений в поддержку с тегом «не могу найти отчёт».
- Пользователи массово экспортируют данные в Excel (обходной путь).
WHAT должен быть описан без интерпретаций — только факты.
2. HOW — как это происходит? (Механизм, сценарий, контекст)
Здесь мы погружаемся в реальность пользователя, чтобы понять причину поломки.
- Что ищем:
- Триггер: Почему пользователь вообще начал этот сценарий?
- Ограничения: В каком контексте он находится (мало времени, мобильное устройство, политика компании)?
- Трение (Friction): Что именно мешает? (Не «плохой UX», а «надо заполнить 8 полей, а я за рулём»).
- Обходные пути: Что он делает вместо «правильного» действия?
Именно здесь рождается настоящая причина проблемы.
3. WHY — зачем это бизнесу? (Ставка и цена)
Проблема становится продуктовой, только когда она имеет цену и для бизнеса.
- Что ищем: Как проблема пользователя транслируется в потери для компании?
- Пример: «Пользователям неудобно» → «они не завершают онбординг (
HOW)» → «падает активация (WHAT)» → «снижается LTV и дорожает маркетинг (WHY)».
WHY — это ответ на вопрос «почему мы вообще должны этим заниматься?».
Итог
Discovery — это не «сбор мнений». Это дисциплина, которая производит ясность. Она заставляет команду сначала глубоко понять, что ломается, как это происходит и почему это важно, и только потом переходить к поиску решения.
Если после фазы Discovery вы не можете сформулировать Problem Statement без слов «кнопка», «фича» или «редизайн» — вы не были в Problem Space. Вы просто искали алиби для решения, которое уже придумали.