Что такое этап Discovery?

Этап Discovery (Исследование) в разработке IT продуктов

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

Цели этапа Discovery

1. Валидация проблемы Убедиться, что проблема действительно существует и является болезненной для пользователей. Много раз PM предполагает проблему, которой нет на самом деле, или которая не так важна для пользователей.

2. Понимание контекста Понять, как пользователи сейчас решают проблему. Какие workarounds используют, какие инструменты, сколько времени тратят. Это раскрывает суть проблемы.

3. Сегментация пользователей Не все пользователи одинаковые. У SMB одна проблема, у Enterprise другая. Discovery помогает понять, кому нужно решение в первую очередь.

4. Выработка гипотез На основе исследования выработать несколько гипотез по решению. Не одно "правильное" решение, а несколько вариантов, чтобы выбрать лучший.

5. Минимизация рисков Ошибка на этапе Discovery стоит в 100 раз дешевле, чем ошибка на этапе разработки.

Как проводится Discovery

User Research (Исследование пользователей)

• Интервью с 5-15 пользователей (не нужно сотни)
• Наблюдение того, как они используют продукт или решают проблему
• Запись сессий (с согласия)
• Вопросы открытого типа: "Как вы обычно...", "Расскажите о последний раз когда..."

Цель: не подтвердить мою гипотезу, а услышать правду из уст пользователя.

Анализ данных

• Посмотреть на аналитику текущих пользователей
• Какие фичи используются, какие игнорируются
• Где пользователи падают в воронке (drop-off)
• Где закрываются сделки (conversion)

Анализ конкурентов

• Как конкуренты решают эту проблему
• Что работает, что нет
• Какие скрытые возможности есть в их подходе

Анализ рынка

• Размер рынка (TAM — Total Addressable Market)
• Есть ли спрос на это решение
• Какая готовность платить

Прототипирование и тестирование

• Создать низкофиделити прототип (sketch, wireframe)
• Показать 3-5 пользователям
• Получить фидбэк: "Это вам нужно? Как бы вы это использовали?"
• Итерировать протокол на основе фидбэка
• Когда направление понятно, создать high-fi прототип

Метрики и KPI

• Какой метрик будет улучшаться если решение сработает
• Например: "Уменьшим время обработки заказа с 30мин до 5мин"
• Как измерим успех

Результаты Discovery

Problem Statement Специфичное описание проблемы в одно-два предложения. Пример: "Enterprise клиенты теряют 15 часов в неделю на ручное согласование счётов, потому что нет автоматической проверки расхождений с берегом."

User Personas и Jobs to be Done Какие типы пользователей есть, что они хотят достичь.

Solution Hypothesis 2-3 варианта решения с оценкой сложности и потенциала. Пример:

• Option A: Автоматическая проверка с AI (сложно, высокий потенциал)
• Option B: Встроенная форма отчёта об ошибках (просто, средний потенциал)
• Option C: Интеграция с accounting software (средне, высокий потенциал)

Design Brief для дизайнеров и разработчиков Требования, constraints, success criteria.

Roadmap Impact Какие другие фичи это пересекает, какие зависимости.

Типичные ошибки на этапе Discovery

Недостаточный research "Я сам знаю, что нужно пользователям" — это самая частая ошибка. Я остаюсь слепым к реальным проблемам.

Интервьюирование только superfans Если разговариваю только с теми, кто любит продукт, услышу только позитив. Нужно найти критиков и потенциальных уходящих.

Игнорирование красных флагов Если пользователи говорят, что это не решит их проблему — слушать, не защищать своё мнение.

Слишком длинный Discovery Discovery должен длиться 1-4 недели для фичи. Если дольше — это пауза в разработке без оправдания.

Пропуск прототипирования Без прототипирования сложно получить реальный фидбэк. Описание всегда выглядит лучше, чем реальность.

Timeline Discovery

Для типичной фичи в SaaS:

• День 1-2: Определение проблемы и целей
• День 3-7: User research (интервью)
• День 8-10: Анализ, выработка гипотез
• День 11-14: Прототипирование и тестирование с пользователями
• День 15: Выводы и Design Brief

Все — 2-3 недели.

Практический пример

Наш CRM приложение имело функцию экспорта в Excel. Часто пользователи просили улучшить её.

До Discovery я думал: "Нужно добавить больше форматов (CSV, JSON)."

Но на Discovery я интервьюировал 10 пользователей и узнал:

• Только 2 из 10 используют экспорт
• Они экспортируют не в Excel, а в Power BI для аналитики
• Реальная проблема: в CRM недостаточно встроенной аналитики

Мы сделали правильное решение: встроили Tableau вместо экспорта. Пользователь стал счастлив.

Bez Discovery я бы потратил недели на улучшение экспорта, который 80% пользователей не используют.

Discovery — это страховка от траты ресурсов на неправильное решение.