Product discovery: как проверять продуктовые гипотезы до разработки
Product discovery — это работа по выяснению, стоит ли вообще строить то, что вы собираетесь строить. Цель discovery — снизить риск до того, как команда потратит недели на разработку: убедиться, что задача ценна, решение применимо, реализуемо и жизнеспособно для бизнеса.
Что такое product discovery
Discovery отвечает на вопрос «что и почему стоит делать», тогда как delivery отвечает на «как это построить и поставить». Это не отдельная фаза в начале проекта, а непрерывный поток работы, идущий параллельно с разработкой: команда постоянно проверяет следующие по важности предположения.
Принято выделять четыре риска, которые discovery снижает: ценность (захотят ли это использовать и платить), удобство (смогут ли разобраться), реализуемость (сможем ли построить) и жизнеспособность (подходит ли это бизнесу, юристам, поддержке). Школа continuous discovery добавляет к этому идею непрерывного, а не разового контакта с пользователями.
Discovery против delivery
Частая ошибка — считать, что discovery «замедляет». На практике он экономит самый дорогой ресурс: время инженеров, потраченное на ненужное. Дешёвый эксперимент на неделю окупается, если предотвращает квартал разработки фичи, которую никто не использует.
- Delivery оптимизирует выпуск: спринты, релизы, качество.
- Discovery оптимизирует выбор: какие гипотезы проверять и в каком порядке.
Как формулировать продуктовые гипотезы
Сильная гипотеза проверяема и фальсифицируема. Удобный шаблон: «Мы верим, что [изменение] для [сегмента] приведёт к [измеримому результату]. Мы поймём, что правы, если увидим [метрика и порог]».
Ключевое — заранее назвать метрику и порог. Без них любой результат можно объявить успехом задним числом, и эксперимент теряет смысл.
Чем дешевле проверить гипотезу
- Интервью и наблюдение — для риска ценности и удобства.
- Прототип / фейк-дор — кнопка или лендинг, измеряющие реальный спрос до постройки.
- Concierge / Wizard-of-Oz — руками отдать ценность нескольким клиентам, прежде чем автоматизировать.
- A/B-тест — когда трафика достаточно для статистической значимости.
Правило: выбирайте самый дешёвый эксперимент, который способен опровергнуть гипотезу. Подтвердить гипотезу легко и обманчиво; ценны попытки её сломать.
Как встроить discovery в процесс
Сделайте discovery еженедельной привычкой, а не разовым проектом: регулярный контакт с пользователями, общая карта предположений, видимый список текущих экспериментов. Тогда продуктовая стратегия перестаёт быть документом раз в год и становится потоком проверенных решений.
Разберите свою задачу по этой логике — бесплатно
ProductHub Deep Dive за ~7 минут превращает вашу продуктовую задачу в план с обоснованием, опираясь на методологию и 200+ реальных проектов агентства. Без воды и коммерческих звонков.
Пройти разбор бесплатноЧастые вопросы
Discovery — это отдельная фаза перед разработкой?
Нет. В зрелых командах discovery идёт непрерывно и параллельно с delivery: пока разрабатывается одна вещь, проверяются предположения для следующих.
С чего начать, если discovery нет вообще?
С еженедельного контакта с пользователями и одной явной, измеримой гипотезы. Даже один разговор и один дешёвый эксперимент в неделю радикально меняют качество решений.
