Многие продукты умирают не из-за плохой разработки, а из-за того, что команда месяцами строит решение для проблемы, которой нет — или которая недостаточно болезненна, чтобы за неё платить. Discovery за две недели помогает проверить ключевую гипотезу до старта полноценной разработки и принять решение на основе данных, а не энтузиазма.
Зачем нужен короткий discovery
Discovery — это не «исследование ради исследования» и не бесконечный анализ рынка. Это сфокусированный процесс, в котором вы отвечаете на четыре вопроса:
- Какую проблему решаем и для кого?
- Насколько она важна для пользователя?
- Как он решает её сейчас и почему существующие способы не устраивают?
- Готов ли он использовать или платить за новое решение?
Две недели — достаточный срок, чтобы получить первые доказательства. Их не хватит для финального вывода о рынке, но вполне достаточно, чтобы решить: развивать идею, изменить её или остановить до крупных затрат.
Главная ценность discovery — не в красивом отчёте, а в снижении риска. Лучше потратить две недели и понять, что гипотеза не работает, чем шесть месяцев разработки и бюджет на функцию, которой никто не пользуется.
Что нужно подготовить до старта
Чтобы две недели не превратились в хаос, зафиксируйте вводные до первого интервью.
1. Сформулируйте исходную гипотезу
Не «мы хотим сделать приложение для склада», а проверяемое утверждение:
Менеджеры склада тратят более 30 минут в день на поиск расхождений при приёмке товара. Если дать им мобильный инструмент для сканирования и сверки в реальном времени, они сократят время приёмки минимум на 40% и будут готовы платить за экономию времени.
Хорошая гипотеза содержит:
- сегмент пользователя;
- контекст и проблему;
- предполагаемое решение;
- механизм, почему оно должно сработать;
- ожидаемый результат;
- критерий, по которому вы поймёте, что гипотеза подтвердилась или опровергнута.
2. Определите целевой сегмент
«Все, кому нужен учёт» — не сегмент. «Кладовщики в компаниях с 20–200 сотрудниками, которые ежедневно принимают от 50 позиций товара» — уже рабочая гипотеза.
Чем точнее сегмент, тем легче найти респондентов, задавать релевантные вопросы и интерпретировать ответы.
3. Назначьте владельца решения
Discovery должен иметь одного человека, который отвечает за результат: продакт, основатель или продукт-лид. Он собирает сигналы, формулирует выводы и принимает рекомендацию: go, pivot или no-go.
Без владельца исследование легко превращается в набор мнений, а не в инструмент принятия решения.
План discovery на 2 недели
Неделя 1: понять проблему
Дни 1–2. Подготовка
- Сформулируйте гипотезу и критерии успеха.
- Составьте список из 10–15 потенциальных респондентов.
- Подготовьте гайд проблемного интервью.
- Определите, какие данные уже есть: обращения в поддержку, отзывы, аналитика, продажи, отчеты внедрения.
Дни 3–5. Проблемные интервью
Проведите 5–8 интервью с представителями целевого сегмента. Важно: не продавайте идею, а изучайте реальный опыт.
Хорошие вопросы:
- Расскажите, как вы обычно решаете эту задачу?
- Что происходит, когда возникает ошибка или сбой?
- Как часто вы сталкиваетесь с этой проблемой?
- Что вы делали в последний раз, когда она возникла?
- Почему текущий способ вас не устраивает?
- Что вы уже пробовали, чтобы решить её?
- Сколько времени, денег или репутационных рисков это вам стоит?
Плохие вопросы:
- Вам понравилась бы такая функция?
- Купили бы вы такой продукт?
- Как вы относитесь к нашей идее?
Люди охотно говорят «да» на гипотетические вопросы, но это не доказательство спроса. Ценность создают конкретные истории о прошлом опыте, а не обещания о будущем поведении.
Дни 6–7. Анализ сигналов
После каждого интервью фиксируйте:
- кто респондент и в каком контексте работает;
- какую задачу решает;
- как часто возникает проблема;
- какие обходные решения использует;
- что уже пробовал;
- какие слова использует для описания боли;
- есть ли признаки готовности менять текущий процесс или платить.
Ищите не вежливый интерес, а доказательства: повторяющиеся сценарии, конкретные потери, попытки решить проблему своими силами, готовность выделить время или бюджет.
Неделя 2: проверить решение и спрос
Дни 8–9. Сформулируйте решение
На основе интервью уточните гипотезу. Возможно, вы обнаружите не ту проблему, которую ожидали, или другой сегмент с более острой болью.
Соберите краткое ценностное предложение:
Для [сегмента], который сталкивается с [проблемой], мы делаем [решение], которое позволяет [ключевой результат] без [главная боль текущего способа].
Дни 10–11. Сделайте минимальный прототип
Не нужно разрабатывать продукт. Достаточно одного из вариантов:
- кликабельный прототип ключевого сценария в Figma;
- лендинг с описанием ценности и формой заявки;
- презентация решения и демонстрация на 10–15 минут;
- «волшебный MVP», где часть процессов выполняется вручную;
- простой расчет или демо, показывающее экономию времени и денег.
Задача прототипа — проверить не дизайн, а понимание ценности: понимает ли пользователь, для чего это нужно, и верит ли, что это решит его задачу.
Дни 12–13. Тестирование решения
Проведите 5–7 повторных встреч с частью тех же респондентов и несколькими новыми. Покажите прототип и наблюдайте:
- понимает ли человек ценность за 30–60 секунд;
- узнаёт ли он свою проблему в вашем сценарии;
- задаёт ли уточняющие вопросы о цене, внедрении, интеграциях;
- просит ли доступ, пилот или расчёт стоимости;
- готов ли дать контакт лица, принимающего решение.
Полезный вопрос: «Что должно произойти, чтобы вы начали использовать это в работе уже в следующем месяце?»
День 14. Решение и план
Соберите выводы в одностраничник:
- какая гипотеза проверялась;
- какие доказательства получены;
- что подтвердилось, а что нет;
- какие риски и открытые вопросы остались;
- рекомендация: go, pivot или no-go;
- следующий минимальный эксперимент и метрики.
Как понять, что идею стоит развивать
Не существует одного универсального сигнала, но обычно о потенциале говорят сразу несколько признаков:
- проблема возникает регулярно, а не раз в год;
- пользователь уже пытался её решить и тратил на это время или деньги;
- текущие обходные пути неудобны, дороги или рискованны;
- несколько респондентов независимо описывают похожий сценарий;
- человек может объяснить, какой результат для него будет успехом;
- есть готовность к пилоту, оплате или рекомендации внутри компании;
- решение не требует радикального изменения привычного процесса.
Если же пользователи говорят «интересно», «наверное, пригодилось бы» и не могут вспомнить конкретный случай, когда проблема мешала работе — это повод не ускорять разработку, а продолжить поиск.
Чего не делать во время discovery
- Не продавать идею на проблемном интервью. Сначала изучайте опыт, потом показывайте решение.
- Не спрашивать «купили бы вы?» Это даёт социально желаемые ответы, а не доказательство спроса.
- Не собирать только мнения коллег и знакомых. Нужны люди из целевого сегмента, а не «похожие на пользователя».
- Не пытаться проверить всё сразу. Одна итерация — одна ключевая гипотеза.
- Не превращать прототип в MVP. Прототип проверяет понимание ценности; MVP проверяет поведение и готовность использовать решение.
- Не игнорировать негативные сигналы. «Нам не нужно», «у нас уже есть решение», «это не приоритет» — тоже ценные данные.
Как связать discovery с приоритизацией
После discovery у вас появится не просто идея, а оценка её потенциала. Её можно сравнить с другими инициативами через RICE: охват, влияние, уверенность и усилия. Чем больше подтверждённых данных вы получили, тем выше может быть параметр Confidence — и тем осмысленнее будет решение о разработке.wellksm
Например, идея с высоким охватом, но низкой уверенностью и большим effort может проиграть более узкой, но подтверждённой проблеме с быстрым пилотом. Discovery как раз и повышает качество этих оценок.
Итог
Discovery за две недели — это способ купить не «исследование», а уверенность в решении. За 14 дней можно проверить, существует ли проблема, кто её испытывает, насколько она болезненна и есть ли шанс, что пользователи выберут ваше решение.
Правильный результат discovery — не прототип и не презентация, а решение:
- Go: гипотеза подтверждена, есть план MVP и метрики.
- Pivot: проблема есть, но решение или сегмент нужно изменить.
- No-go: гипотеза не подтверждена, бюджет на разработку пока не нужен.
Такой подход экономит не только деньги, но и главное ограничение любого продукта — время команды.
Хотите проверить продуктовую идею до старта разработки?
Напишите на ask@wellksm.ru — поможем провести discovery-спринт: сформулируем гипотезу, подготовим интервью, прототип и критерии решения go / pivot / no-go.
