ProductHub

Product discovery: как проверять продуктовые гипотезы до разработки

Product discovery — это работа по выяснению, стоит ли вообще строить то, что вы собираетесь строить. Цель discovery — снизить риск до того, как команда потратит недели на разработку: убедиться, что задача ценна, решение применимо, реализуемо и жизнеспособно для бизнеса.

Что такое product discovery

Discovery отвечает на вопрос «что и почему стоит делать», тогда как delivery отвечает на «как это построить и поставить». Это не отдельная фаза в начале проекта, а непрерывный поток работы, идущий параллельно с разработкой: команда постоянно проверяет следующие по важности предположения.

Принято выделять четыре риска, которые discovery снижает: ценность (захотят ли это использовать и платить), удобство (смогут ли разобраться), реализуемость (сможем ли построить) и жизнеспособность (подходит ли это бизнесу, юристам, поддержке). Школа continuous discovery добавляет к этому идею непрерывного, а не разового контакта с пользователями.

Discovery против delivery

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

  • Delivery оптимизирует выпуск: спринты, релизы, качество.
  • Discovery оптимизирует выбор: какие гипотезы проверять и в каком порядке.

Как формулировать продуктовые гипотезы

Сильная гипотеза проверяема и фальсифицируема. Удобный шаблон: «Мы верим, что [изменение] для [сегмента] приведёт к [измеримому результату]. Мы поймём, что правы, если увидим [метрика и порог]».

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

Чем дешевле проверить гипотезу

  1. Интервью и наблюдение — для риска ценности и удобства.
  2. Прототип / фейк-дор — кнопка или лендинг, измеряющие реальный спрос до постройки.
  3. Concierge / Wizard-of-Oz — руками отдать ценность нескольким клиентам, прежде чем автоматизировать.
  4. A/B-тест — когда трафика достаточно для статистической значимости.

Правило: выбирайте самый дешёвый эксперимент, который способен опровергнуть гипотезу. Подтвердить гипотезу легко и обманчиво; ценны попытки её сломать.

Как встроить discovery в процесс

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

Разберите свою задачу по этой логике — бесплатно

ProductHub Deep Dive за ~7 минут превращает вашу продуктовую задачу в план с обоснованием, опираясь на методологию и 200+ реальных проектов агентства. Без воды и коммерческих звонков.

Пройти разбор бесплатно

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

Discovery — это отдельная фаза перед разработкой?

Нет. В зрелых командах discovery идёт непрерывно и параллельно с delivery: пока разрабатывается одна вещь, проверяются предположения для следующих.

С чего начать, если discovery нет вообще?

С еженедельного контакта с пользователями и одной явной, измеримой гипотезы. Даже один разговор и один дешёвый эксперимент в неделю радикально меняют качество решений.