Чтобы проверить идею стартапа, сначала опишите конкретную проблему и людей, которые с ней сталкиваются, затем выясните, как они решают её сейчас. После интервью покажите минимальный способ решения и наблюдайте за действиями, а не за комплиментами. Фраза «я бы купил» сама по себе не подтверждает спрос: она ничего не стоит собеседнику и не показывает, что продукт впишется в его жизнь.
Переведите идею в проверяемую гипотезу
«Сделаем приложение для продуктивности» — описание замысла, но не проверка. Более полезная формулировка: «самостоятельные мастера теряют заявки, когда отвечают клиентам в нескольких мессенджерах; им нужен простой способ видеть следующий шаг по каждому заказу». Теперь можно искать этих людей, спрашивать про недавние случаи и сравнивать существующие решения. Если проблема не встречается или уже решается без заметных затруднений, красивый интерфейс не делает гипотезу сильнее.
Разделите предположения. Первое — у определённой группы действительно бывает затруднение. Второе — оно достаточно важно, чтобы человек менял привычный порядок работы. Третье — ваше решение подходит лучше доступной альтернативы. Отдельно проверяется экономическая сторона: расходы на создание и обслуживание не исчезают от того, что прототип кому-то понравился. Не пытайтесь доказать всё одним вопросом «вам интересно?».
Учебный пример: журнал заказов для мастерской
Представим вымышленную команду, которая хочет сделать сервис для небольших мастерских. Её гипотеза: владельцы вручную переписывают заказы из переписок, из-за чего забывают сроки и уточнения. Вместо презентации будущего сервиса команда просит нескольких владельцев показать, как они обработали последние два заказа. Один хранит записи в блокноте, другой пользуется готовой таблицей, третий не видит проблемы. Это три разных сигнала; не следует записывать всех троих в «заинтересованные клиенты».
Команда делает бумажный экран с полями «клиент», «следующее действие», «срок» и просит первого собеседника перенести реальный, но обезличенный заказ. Важно наблюдать, какие сведения он ищет, какие поля игнорирует и возвращается ли к листу при следующем разговоре. Если для заполнения требуется больше времени, чем для привычной записи, проблема может быть в прототипе или в исходной гипотезе. Нужно выяснить причину, а не объявлять тест успешным из вежливости.
Порядок проверки без большой разработки
- Запишите предположение. Укажите группу, ситуацию, существующий способ решения и неудобство. Фраза должна допускать опровержение: иначе любой ответ можно объявить подтверждением.
- Найдите подходящих собеседников. Ищите людей, которые недавно решали эту задачу, а не знакомых, готовых вас поддержать. Не раскрывайте желаемый ответ в приглашении.
- Расспросите о прошлом действии. «Расскажите, как вы обработали последний заказ» полезнее, чем «вы бы пользовались нашим сервисом?». Попросите показать шаги и инструменты, но уважайте конфиденциальность данных.
- Сделайте минимальный тест решения. Это может быть бумажный экран, ручное выполнение услуги или простая форма. Его задача — проверить ключевой переход, а не изображать законченный продукт.
- Запишите критерий решения заранее. Какие действия будут поводом продолжать, изменить предложение или остановиться? Например, человек без подсказки возвращается к прототипу для той же задачи. Формулировка после теста снижает соблазн подогнать вывод.
Как читать результаты без самообмана
Небольшое число бесед помогает найти язык проблемы и неожиданные препятствия, но не даёт оценки размера рынка. Интервью не заменяет проверку оплаты, договорённостей, ограничений площадки и стоимости обслуживания. Одинаково опасно считать одно «нет» приговором и одно «да» доказательством бизнеса. Ищите повторяющееся поведение в конкретной ситуации, уточняйте различия между группами и сохраняйте неудобные наблюдения в протоколе.
Если люди уже используют таблицы, не спешите объявлять это подтверждением спроса на приложение. Спросите, что именно не работает в таблице и меняли ли они инструмент раньше. В некоторых случаях улучшенный шаблон решит задачу без нового продукта. Когда будет понятен процесс, пригодится подход из статьи о том, как бизнес-аналитик переводит наблюдения в требования. Здесь важнее честная проверка проблемы, чем технический масштаб идеи.
Частые вопросы
Можно ли проверять идею без готового продукта?
Да. Разговор о прошлом опыте, бумажный прототип или ручной процесс часто позволяют обнаружить неверные предположения до разработки. Но для проверки реального спроса на конкретное платное предложение позже понадобится более сильный сигнал, чем положительный отзыв.
Стоит ли задавать вопрос «сколько вы заплатите»?
Его можно использовать для разговора об ограничениях, но заявленная сумма не равна будущей покупке. Лучше понять, за что человек уже платит временем или деньгами и какое действие готов совершить сейчас.
Когда остановить проверку?
Когда вы можете объяснить, что узнали о проблеме, какой риск остался и какое следующее наблюдение способно изменить решение. Бесконечные интервью не заменяют решения, а преждевременная разработка не исправляет отсутствие проблемы.
В практикуме по запуску стартапа этот цикл продолжается экономикой, MVP и защитой проекта. Но первый шаг самостоятельный: запишите одну опровержимую гипотезу и проверьте недавний опыт человека, для которого хотите работать.
