Друзья говорят, что идея отличная. В презентации всё складывается. Кажется, осталось найти разработчика и сделать первую версию. Но одобрение идеи ещё не показывает, что кто-то изменит привычный способ работы ради нового продукта.
До разработки полезно проверить не любовь к концепции, а существование конкретной проблемы: кто сталкивается с ней, как решает сейчас и почему привычный вариант не устраивает.
Сузьте первого пользователя
«Продукт для малого бизнеса» — слишком широкое описание для содержательного разговора. У небольшой студии, магазина и производственной компании разные процессы.
Опишите человека через ситуацию: например, руководитель студии, который каждую неделю собирает статусы задач из нескольких чатов. Пока это гипотеза. Она нужна, чтобы найти похожих собеседников, а не объявить рынок изученным.
Спрашивайте о прошлом поведении
Вопрос «Вы бы пользовались таким сервисом?» приглашает к вежливому ответу. Полезнее попросить рассказать о последнем случае, когда проблема возникла.
Что произошло? Кто участвовал? Как человек вышел из ситуации? Что пришлось отложить? Пробовал ли другие способы? Такие вопросы помогают увидеть реальную последовательность действий.
Не спорьте с собеседником, если его проблема оказалась не такой болезненной, как ожидалось. Цель разговора — уточнить гипотезу, а не защитить презентацию.
Проверьте сценарий простым прототипом
Если проблема повторяется, покажите бумажный макет, последовательность экранов или пример результата. Предложите выполнить конкретную задачу, а не оценить дизайн.
Наблюдайте, где человек останавливается и чего ждёт дальше. Не объясняйте каждый шаг заранее: иначе вы проверяете качество своей презентации, а не понятность сценария.
Часть решения можно временно выполнить вручную, открыто предупредив участников. Такой формат позволяет исследовать процесс, но не доказывает, что автоматизированная версия будет столь же удобной или экономичной.
Различайте сигналы интереса
Похвала, подписка на новости, готовность показать рабочий процесс и согласие на пилот — разные сигналы. Не складывайте их в одну цифру «потенциальных клиентов».
Записывайте, что человек действительно сделал, а не только обещал. При этом отказ тоже требует контекста: возможно, не подходит время, отсутствуют полномочия или задача уже решена другим способом.
Заранее определите решение после проверки
До начала разговоров запишите, какие наблюдения позволят продолжить, изменить аудиторию или остановиться. Не обязательно придумывать универсальный числовой порог: важнее не менять критерии задним числом ради удобного вывода.
Результатом проверки может стать более узкая функция вместо большого продукта. Или понимание, что проблема есть, но находится у другого участника процесса.
Хорошая проверка не гарантирует успех стартапа. Она помогает сделать следующий шаг осмысленно: строить решение для наблюдаемой задачи, а не для одобрительных кивков на встрече.
Как стартапу найти первых 100 платящих клиентов и не потерять год на пустые попытки
Pitch deck, который понимают инвесторы: структура, цифры и типовые ошибки без лишнего шума
Как проверить идею стартапа до инвестиций в разработку: трезвый взгляд, который экономит деньги и время
Product-market fit: почему рост маркетингового бюджета не заменяет ценность продукта
