Как проверить идею сервиса до того, как писать код

Почему «все скажут, что идея классная» - это не проверка

Когда вы рассказываете идею друзьям и коллегам, они обычно поддерживают. Это не злой умысел - просто люди не хотят обидеть. Но «звучит интересно» и «я бы заплатил» - разные вещи.

Настоящая проверка начинается тогда, когда вы просите человека что-то сделать: оставить email, предоплатить, подписаться на лист ожидания. Готовность совершить действие - первый реальный сигнал.

Поэтому не спрашивайте «тебе нравится идея?». Спрашивайте «ты бы воспользовался этим прямо сейчас и за какую цену?»

Шаг первый: сформулируйте проблему, не решение

Большинство основателей приходят к разработчику с решением: «нужно приложение с такими-то функциями». Но до этого нужно убедиться, что проблема, которую вы решаете, реально болезненная и достаточно частая.

Напишите одно предложение: «[Аудитория] сталкивается с [проблемой] и сейчас решает её через [неудобный способ]». Если не можете заполнить все три части - идея ещё не оформилась.

Например: «Небольшие кафе тратят по часу в день на ручное занесение заказов в таблицы, потому что нормальная CRM стоит как крыло самолёта». Здесь есть аудитория, боль и текущий костыль.

Как проверить идею стартапа без единой строчки кода

Самый быстрый инструмент - лендинг с описанием ценности и кнопкой «Хочу попробовать». Не нужен дизайнер и не нужна разработка: Tilda или Notion-страница справятся. Главная задача - узнать, кликают ли люди и оставляют ли контакт.

Запустите на этот лендинг небольшой трафик: пост в тематическом Telegram-канале, таргет на нужную аудиторию или просто прямые сообщения потенциальным клиентам. Десять-двадцать живых разговоров дадут больше, чем сто анкет.

Если за неделю никто не оставил контакт - это не провал, это данные. Либо аудитория не та, либо ценность не очевидна из текста, либо проблема не такая острая, как казалось.

Custdev: пять разговоров, которые меняют продукт

Custdev - это не фокус-группа и не опрос. Это живой разговор, где вы слушаете, а не продаёте. Задача - понять, как человек сейчас решает проблему, сколько времени и денег это стоит, что его бесит.

Попросите рассказать о последнем случае, когда столкнулись с этой ситуацией. Не гипотетически, а конкретно: «Что вы сделали? Куда пошли? Что не устроило?» Детали важнее общих оценок.

После пяти-семи таких разговоров обычно начинает повторяться одно и то же. Это и есть настоящая боль, вокруг которой стоит строить продукт.

• Не предлагайте своё решение в ходе разговора - сначала дослушайте
• Записывайте дословные цитаты, не пересказывайте своими словами
• Если человек сам спрашивает «а где можно купить?» - это сильный сигнал

Когда результаты говорят «продолжай», а когда - «стоп»

Хороший знак: люди сами спрашивают, когда можно попробовать, готовы дать предоплату или хотя бы публично рекомендуют знакомым. Плохой знак: все говорят «интересно», но никто не оставляет контакт и не возвращается.

Ещё один стоп-сигнал - когда у каждого собеседника оказывается своя версия проблемы и своё желаемое решение. Это означает, что рынок слишком разрозненный или проблема недостаточно универсальная.

Если проверка показала спрос - берите результаты на первый разговор с разработчиком. Это сократит время на бриф и поможет точнее сформулировать MVP.

Что заказывать после проверки

Когда гипотеза подтверждена, задача - сделать минимально работающий продукт, который закрывает одну ключевую боль. Не всё сразу, а именно то, за что люди готовы платить уже сейчас.

В EFIMOV DEV мы начинаем с брифа: обсуждаем задачу напрямую с тем, кто будет вести проект. После этого появляется смета с разбивкой по блокам - не одна строка с числом, а список того, за что именно вы платите. Ориентировочные вилки по услугам опубликованы на сайте, точная цифра - после разговора.

Если проверка показала, что идею нужно доработать - это тоже хороший результат. Лучше потратить две недели на custdev, чем три месяца на разработку продукта, который не купят.