Как проверить спрос на IT-продукт до разработки: шесть способов за две недели

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

Статья для основателей, продактов и руководителей IT-компаний в Казахстане, которые придумали новый продукт или функцию и хотят понять, стоит ли тратить на неё бюджет разработки. Разберём каждый способ с критериями, дадим план на 14 дней, таблицу для чтения сигналов и типичные ошибки.

Зачем проверять спрос до разработки

Разработка — самый дорогой способ узнать, что продукт никому не нужен. Даже небольшой MVP требует нескольких человеко-месяцев работы команды, а проверка спроса — две недели времени основателя и небольшой рекламный бюджет. Из чего складывается цена разработки, мы подробно разобрали в статье о стоимости MVP в Казахстане.

Проверка спроса отвечает на три вопроса:

1. Есть ли у конкретного сегмента проблема, которую он осознаёт и уже как-то решает?
2. Достаточно ли ваш оффер отличается от текущего решения, чтобы на него переключились?
3. Готовы ли платить, и сколько?

Перед стартом: гипотеза и пороги решения

Главная ошибка — начать проверку без критериев, а потом трактовать любой результат как успех. Поэтому до первого интервью запишите гипотезу в одну строку:

«[Сегмент] испытывает [проблему], сейчас решает её [способом], и готов платить [сумму] за [результат]».

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

Шесть способов проверки

1. Проблемные интервью

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

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

2. Анализ поискового спроса и конкурентов

Посмотрите, ищут ли решение проблемы: статистику запросов в Вордстате Яндекса и планировщике ключевых слов Google, подсказки поиска, вопросы на форумах и в профильных Telegram-чатах. Отдельно соберите конкурентов и прямые заменители, включая Excel, WhatsApp-группы и подрядчиков, и прочитайте отзывы на них.

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

3. Лендинг с оффером и формой заявки

Одна страница: для кого продукт, какую проблему решает, чем отличается, сколько примерно стоит, кнопка «Оставить заявку» или «Записаться на ранний доступ». Трафик ведите из одного-двух каналов, где есть ваш сегмент. Если сомневаетесь в формулировке, сделайте два варианта оффера и сравните их на одном источнике трафика.

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

4. Кликабельный прототип

Прототип ключевого сценария в Figma или аналогичном инструменте. Дайте его пяти-восьми представителям сегмента с задачей: «Вам нужно сделать вот это». Смотрите, где они спотыкаются, и слушайте, что говорят вслух.

Критерий: большинство проходит сценарий без подсказок и спрашивает, когда можно попробовать на своих данных. Этот способ проверяет понятность решения, а не готовность платить, поэтому не заменяет пятый и шестой.

5. Ручной сервис вместо продукта

Оказывайте услугу, которую обещает продукт, вручную: через таблицы, мессенджеры и собственное время. Если продукт подбирает подрядчиков — подбирайте их сами. Если формирует отчёты — собирайте их руками.

Критерий: клиенты пользуются сервисом повторно и готовы платить хотя бы символическую сумму. Бонус: вы увидите реальный процесс клиента и поймёте, какие шаги действительно стоит автоматизировать.

6. Предпродажа

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

Критерий: заранее заданное число платежей, подписанных писем или договоров. Это самый сильный сигнал из шести: слова ничего не стоят, деньги и подписи стоят.

Итог по способам:

Способ	Что проверяет	Сила сигнала	Время
Проблемные интервью	Наличие и острота проблемы	Средняя	5–7 дней
Анализ поиска и конкурентов	Осознанность проблемы, размер рынка	Средняя	1–2 дня
Лендинг с оффером	Интерес к конкретному предложению	Средняя	5–7 дней трафика
Кликабельный прототип	Понятность решения	Низкая для спроса	2–3 дня
Ручной сервис	Ценность результата	Высокая	5–10 дней
Предпродажа	Готовность платить	Самая высокая	Параллельно с остальными

План проверки на 14 дней

Дни	Что делаем	Результат
1	Формулируем гипотезу, сегмент и пороги решения	Одна страница с критериями
2	Анализ поискового спроса, конкурентов и отзывов	Список заменителей и жалоб
2–3	Набираем собеседников, готовим сценарий интервью	15–20 договорённостей о звонках
3–7	Проводим интервью, после каждого записываем выводы	Карта проблем и цитаты клиентов
6–7	Собираем лендинг на языке клиентов из интервью	Лендинг с формой и аналитикой
8–13	Ведём трафик на лендинг, созваниваемся с оставившими заявки	Конверсия и квалифицированные лиды
8–10	Делаем прототип и тестируем его на 5–8 людях	Список проблем понятности
9–13	Запускаем ручной сервис и предпродажу для самых заинтересованных	Платежи, письма, повторные обращения
14	Сверяем результаты с порогами и принимаем решение	«Строим», «меняем гипотезу» или «останавливаемся»

Числа в плане — ориентир для одного сегмента и одного человека, который ведёт проверку. Если сегмент B2B и решения принимаются долго, предпродажу растяните на следующий цикл, но первые разговоры о деньгах проведите в эти же две недели.

Контекст Казахстана. Рынок небольшой, и в B2B решения часто принимаются через знакомых и рекомендации. Поэтому до интервью проще дойти через личные связи и отраслевые сообщества, чем через холодные письма, а вот смещение выборки в сторону «своих» людей нужно отслеживать отдельно. Многие собеседники предпочтут переписку и голосовые сообщения в WhatsApp видеозвонку, и это нормально. Для массовой аудитории проверьте лендинг на русском и казахском: язык оффера влияет на отклик. Форма заявки собирает персональные данные. Если важно хранить базу с заявками в Казахстане, учтите это при выборе конструктора лендингов и CRM.

Как читать сигналы

Сигнал	Что означает	Решение
Проблему называют сами, есть обходной путь и потраченные деньги	Проблема реальная и осознанная	Переходить к офферу и предпродаже
Проблему признают только после подсказки	Проблема не приоритетная	Искать другой сегмент или другую проблему
Много кликов на лендинге, мало заявок с контактами	Интересен заголовок, но не предложение	Переписать оффер, проверить цену
Заявки есть, на звонок не соглашаются	Слабая мотивация или не тот сегмент	Уточнить сегмент и канал трафика
Прототип проходят, но платить не готовы	Решение понятно, но ценность мала	Пересмотреть результат, который обещает продукт
Ручным сервисом пользуются повторно	Ценность подтверждена	Автоматизировать самые трудоёмкие шаги
Есть предоплаты или подписанные письма	Подтверждена готовность платить	Планировать MVP под этот сегмент
Сигналы разных сегментов противоречат друг другу	Смешаны аудитории	Выбрать один сегмент и повторить цикл

Как принять решение на четырнадцатый день

Решение принимается на одной встрече, по таблице с порогами, которую вы записали в первый день. Вариантов три.

Строим. Пороги пройдены хотя бы по одному сильному сигналу: есть предоплаты, подписанные письма или повторное использование ручного сервиса, и это подкреплено интервью. Следующий шаг — описать MVP только под тот сценарий, за который уже заплатили, и запустить его на людях из списка заявок. Всё, что не проверялось, уходит в бэклог.

Меняем гипотезу. Проблема подтвердилась, но оффер, цена или сегмент не сработали. Это нормальный и частый исход. Переформулируйте одну переменную, а не все сразу: другой сегмент при том же оффере или другой оффер для того же сегмента. Затем проведите ещё один короткий цикл, уже без повторного анализа рынка.

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

Чтобы решение не превратилось в спор о вкусах, договоритесь заранее, кто принимает его окончательно, и зафиксируйте итог письменно вместе с цифрами, на которых он основан.

Типичные ошибки

• Проверять на друзьях и коллегах. Они хотят вас поддержать и отвечают соответственно.
• Спрашивать «купили бы вы». Гипотетические ответы почти всегда положительные и почти ничего не значат.
• Задавать пороги после результатов. Тогда любой результат можно назвать успехом.
• Смешивать сегменты. Ответы малого бизнеса и корпораций в одной выборке дают средний результат, который не описывает никого.
• Останавливаться на интересе. Лайки, подписки и клики не равны деньгам. Без предпродажи или ручного сервиса готовность платить не проверена.
• Строить лендинг на своём языке, а не на языке клиента. Формулировки для оффера лучше брать из интервью дословно.
• Не фиксировать данные. Заявки и договорённости должны жить в CRM или хотя бы в таблице, а не в личных переписках.

Если проверка прошла и спрос подтверждён, следующий шаг — выбрать каналы, через которые продукт будет получать клиентов. Об этом наша статья о GTM для SaaS в Казахстане.

Как мы это делаем

Мы начинаем с диагностики гипотезы: вместе с командой формулируем сегмент, оффер и пороги решения, затем проводим двухнедельный цикл проверки на одном сегменте. Если сигналы сильные, собираем MVP только под подтверждённый сценарий и запускаем его на тех, кто уже оставил заявку или внёс предоплату. Масштабируем то, что подтвердили данные, а не то, что хотелось построить изначально.

Если хотите пройти проверку спроса и запуск продукта вместе с нами, начните со страницы разработки MVP и запуска продуктов: там описан процесс и что вы получите на каждом этапе.

---

Источники. Сроки и пороги в статье — рабочая модель Gotomarket, а не рыночная статистика.

Термины простыми словами

MVP (Minimum Viable Product)

Минимальная рабочая версия продукта для проверки идеи на реальных пользователях. Проверка спроса нужна, чтобы не тратить бюджет на MVP, который никому не нужен.

Лендинг

Одностраничный сайт с описанием предложения и формой заявки. На этапе проверки показывает, оставляют ли люди контакты, хотя продукта ещё нет.

Оффер

Формулировка предложения: для кого продукт, какую проблему решает, чем отличается и сколько примерно стоит. Его лучше писать словами клиентов из интервью.

Сегмент

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

Конверсия

Доля посетителей, которые сделали нужное действие, например оставили заявку на лендинге. Порог конверсии задают заранее, исходя из своей экономики.

Кликабельный прототип

Макет интерфейса, по которому можно «пройти» сценарий, нажимая кнопки, хотя за ним нет работающего кода. Проверяет понятность, а не готовность платить.

Консьерж-сервис (ручной MVP)

Вы вручную оказываете клиенту ту услугу, которую обещает продукт: через таблицы и мессенджеры. Так проверяется ценность результата до разработки.

Письмо о намерениях

Документ, в котором компания-клиент подтверждает намерение купить продукт после запуска. Для B2B это сильный сигнал спроса, почти как предоплата.