Большинство неудачных продуктов проваливаются не на этапе разработки. Они терпят неудачу в тот момент, когда идею принимают без проверки, а разработка лишь делает этот провал дорогим и заметным месяцы спустя.
Три допущения, на которых строится любая идея
Допущение о проблеме: она действительно болезненна?
Не «было бы неплохо это иметь», а «стоит ли это кому-то реального времени, денег или риска сегодня, причём достаточно часто, чтобы человек изменил своё поведение ради решения».
Допущение о решении: закрывает ли проблему именно этот подход?
У реальной проблемы всё равно может быть неверно подобранное решение. Discovery проверяет само решение, а не только боль.
Допущение о жизнеспособности: станет ли кто-то реально это использовать или платить за это?
Интерес — это ещё не внедрение. Люди часто говорят, что воспользовались бы чем-то, а затем никак не меняют своё поведение, когда это становится доступно.
Методы discovery по силе доказательности
| Метод | Сила доказательства | Скорость | Лучше всего подходит для |
|---|---|---|---|
| Опросы мнений | Слабая | Быстро | Только для первичной формулировки проблемы, никогда не сигнал «go/no-go» |
| Интервью с клиентами об их прошлом поведении | Средняя | Быстро | Подтверждения того, что проблема реальна и повторяется |
| Тест кликабельного прототипа | Средняя | Средне | Проверки, имеет ли смысл предложенный flow |
| Консьерж-сервис или ручной пилот | Сильная | Средне | Проверки готовности платить или внедрять до начала разработки |
| Рабочий MVP с реальными данными об использовании | Самая сильная | Медленно | Подтверждения удержания и привычного использования, а не только первого касания |
Лёгкий процесс discovery
Запишите допущение, которое беспокоит вас больше всего
Не всю идею целиком, а одно-единственное допущение, которое, если оно окажется ложным, убивает идею. Проверяйте его первым.
Поговорите с 8–12 людьми, недавно столкнувшимися с проблемой
Спрашивайте о конкретном прошлом поведении, а не о гипотетическом будущем. «Расскажите, как это было в последний раз» работает лучше, чем «стали бы вы пользоваться инструментом, который делает X».
Запустите ручную или консьерж-версию, прежде чем что-то строить
Доставьте результат вручную, пусть даже неэффективно, нескольким реальным пользователям. Если никто не хочет ручную версию, автоматизированная это не исправит.
Заранее определите критерий остановки
Решите, какой результат заставит вас остановиться, ещё до того, как увидите результаты. Без этого неоднозначные данные всегда трактуются как «многообещающие».
Pros
- +Выявляет фатальные несоответствия проблемы или решения до затрат на разработку
- +Даёт реальный язык пользователей и ограничения, которые улучшают скоуп при начале разработки
- +Вынуждает сформулировать конкретное, опровержимое утверждение вместо расплывчатого видения продукта
Cons
- −Может использоваться, чтобы бесконечно тянуть время, если нет критерия остановки или дедлайна
- −Слабые методы (опросы, мнения) могут создавать ложную уверенность, если их принимают за сильные доказательства
- −Некоторые проблемы действительно требуют рабочего продукта для полноценной проверки; у discovery есть пределы
Discovery не доказывает, что идея верна. Это самый дешёвый способ узнать, что она неверна, — раньше, чем это сделает дорогой способ.
Когда идея проходит discovery, следующий вопрос обычно — строить, покупать или собирать из готового, а затем сузить скоуп первой версии настолько, чтобы продолжать проверку уже в процессе разработки.
FAQ
FAQ
Что такое product discovery?+
Product discovery — это процесс проверки того, реальна ли проблема, действительно ли предложенное решение её закрывает и готов ли кто-то платить за это решение или использовать его, прежде чем на него потратят время разработки.
Сколько времени должен занимать product discovery?+
Обычно discovery занимает от нескольких дней до нескольких недель, а не месяцев. Если discovery длится дольше, чем занял бы сам небольшой запуск в разработку, проблемой обычно становится сам процесс.
Нужен ли discovery, если идея кажется очевидной?+
Да. Идеи, которые кажутся очевидными, постоянно проваливают проверку — обычно потому, что предполагаемая проблема оказывается не такой болезненной, частой или нерешённой, как думала команда. Короткий проход discovery — это дешёвая страховка от дорогой разработки.
Похожие материалы
Продуктово-рыночное соответствие: как понять, что оно действительно есть
О продуктово-рыночном соответствии заявляют куда чаще, чем оно реально есть. Конкретное определение, сигналы, которые действительно на него указывают, и сигналы, которые с ним часто путают.
БизнесКогда бизнесу нужно кастомное ПО? Фреймворк для принятия решения
Кастомное ПО дорого строить и дорого пропустить в неподходящий момент. Конкретный фреймворк для решения, действительно ли ваш бизнес перерос готовые инструменты.
БизнесSaaS MVP — фреймворк решения Build vs Buy на 2026 год
Практический фреймворк для решения — строить кастомный SaaS MVP, собирать no-code инструменты или покупать готовое ПО — с учётом стоимости, рисков и скорости.
Newsletter
Продуктовые заметки без шума.
Редкие материалы о порталах, SaaS MVP и автоматизации.