Как быстро проверить бизнес-гипотезу с помощью ИИ: MVP на реальных пользователях

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

В посте в канале в мае 2025 года я писал, что с ИИ-платформами прототип можно собрать за день вместо месяцев разработки. Но быстрая сборка закрывает только часть задачи: прототип полезен, когда отвечает на вопрос, заданный заранее. Ниже - порядок такой проверки и то, где на каждом шаге помогает ИИ. Сведения о законах и сервисах проверены 12 октября 2026 года.

Что такое MVP и что он должен доказать

В посте я определял MVP как рабочую мини-версию продукта, которая покажет, нужен ли он рынку. Эрик Рис, для которого MVP - одна из главных техник подхода lean startup («бережливый стартап»), в 2009 году сформулировал строже: это версия нового продукта, которая позволяет собрать максимум проверенного знания о клиентах при минимальных усилиях. Там же он оговаривается, что MVP, вопреки названию, не про создание минимальных продуктов.

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

Критерий успеха на схеме стоит раньше прототипа. Почему так - в шаге 2.

Шаг 1. Запишите гипотезу так, чтобы её можно было опровергнуть

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

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

Условный пример с сервисом бронирования, который я упоминал в посте: «Мы считаем, что владельцы небольших салонов красоты в нашем городе оставят заявку на подключение онлайн-записи, потому что сейчас теряют клиентов, которые не дозвонились. Мы поймём, что правы, если из 300 посетителей страницы хотя бы 15 оставят заявку за две недели». Числа здесь условные: свои пороги задайте сами.

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

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

Шаг 2. До запуска решите, что будет успехом, а что провалом

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

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

В условном примере с салонами из шага 1 это может выглядеть так: из 300 посетителей страницы 15 заявок и больше - дальше, от 5 до 14 - менять, меньше 5 - закрыть.

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

Шаг 3. Соберите самый дешёвый прототип, который проверяет гипотезу

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

«Волшебник страны Оз» - метод, который исследователи интерфейсов из Nielsen Norman Group описывают так: человек работает с интерфейсом, который выглядит автономным, но полностью или частично управляется человеком. Это дешёвый способ проверить решение, которое потом потребует сложных технологий. Если участника при этом вводят в заблуждение, в Nielsen Norman Group советуют в конце сессии рассказать ему, как всё было устроено. С реальными клиентами действуйте так же честно: не обещайте автоматизацию, которой нет. А заявки и контакты, которые человек обрабатывает вручную, - те же персональные данные, что и в форме (раздел ниже).

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

Рабочий прототип в посте я предлагал собирать так: вы описываете идею, ИИ пишет код, помогает с дизайном и интеграциями. По моей оценке из поста, прототип сайта с формой бронирования получается за пару часов, затем к нему добавляется чат-бот для клиентов. Речь о простом прототипе; у сложной задачи срок будет другим. Среди инструментов тогда я называл Cursor; с сентября 2026 года Cursor официально в России не работает. Остальные платформы из поста, которые собирают приложение по описанию, здесь не названы: на 12 октября 2026 года надёжного источника об их работе в России найти не удалось. Как собрать прототип самому и какие помощники для кода есть в России, разобрано в статье про вайб-кодинг.

Что поручить ИИ. Тексты страницы в двух-трёх вариантах, вопросы анкеты, структуру макета. Перечитайте готовый текст: модель может приписать продукту функции, которых у вас пока нет.

Если форма собирает контакты: минимум по 152-ФЗ

Имя и телефон из формы заявки - персональные данные: закон относит к ним любую информацию, относящуюся к определённому или определяемому человеку, а обработкой считает действия с ними как с помощью программ, так и вручную (статья 3). Минимум, который стоит проверить до запуска:

• Согласие отдельным документом. Согласие на обработку оформляется отдельно от других документов, которые подписывает или подтверждает человек (статья 9, часть 1). Поэтому не прячьте его в тексте оферты или пользовательского соглашения.
• Политика на странице. Если данные собираются через сайт, на страницах, где идёт сбор, нужно опубликовать документ о политике обработки персональных данных (статья 18.1, часть 2).
• Уведомление. До начала обработки оператор обязан уведомить уполномоченный орган по защите прав субъектов персональных данных, кроме случаев, перечисленных в законе (статья 22, часть 1).
• Где хранятся данные. При сборе данных граждан России запись и хранение с использованием баз данных за пределами России не допускаются, за исключениями из закона (статья 18, часть 5). Проверьте в условиях сервиса форм, где он хранит ответы.
• Передача в зарубежный ИИ-сервис. Передача персональных данных на территорию другого государства иностранной компании - трансграничная передача (статья 3, пункт 11), и о ней тоже нужно заранее уведомить уполномоченный орган (статья 12, часть 3). Проще не передавать: загружайте в модель только обезличенные ответы.

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

Шаг 4. Покажите прототип людям из целевой группы

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

Где их найти: среди нынешних клиентов, в отраслевых сообществах, через партнёров или небольшую рекламу. Если приводите людей рекламой, помните: интернет-реклама в России должна быть помечена словом «реклама» и содержать указание на рекламодателя, а распространять её можно только с присвоенным идентификатором рекламы (статья 18.1 закона «О рекламе», части 16 и 17). Посмотрите в справке рекламной площадки, как она выполняет эти требования.

Сколько людей нужно, зависит от вопроса:

• Понятно ли и удобно ли. Для такого качественного теста Nielsen Norman Group советует 5 человек и несколько небольших раундов: по их расчёту, первые пятеро находят около 85% проблем удобства. Если у продукта несколько сильно разных групп пользователей, в тест нужны люди из каждой группы.
• Удобство в цифрах (время, доля успешных попыток). Для количественных метрик там же рекомендуют 20 человек.
• Есть ли спрос. Здесь считается поток. Если вы ждёте, что заявку оставит 5% посетителей, то для 15 заявок нужно около 300 посетителей. Это условный расчёт без запаса: если ожидаемая доля совпадает с порогом, из-за случайного разброса результат легко окажется чуть ниже даже при верной гипотезе. Подставьте свои ожидания из критерия и закладывайте больше посетителей.

Посетителей и заявки удобно считать в веб-аналитике с целями, например в Яндекс Метрике, а форму заявки - собрать в конструкторе форм, например в Яндекс Формах.

Шаг 5. Собирайте поведение, а не комплименты

Отзыв «классная идея, я бы пользовался» о спросе почти ничего не сообщает. Якоб Нильсен из Nielsen Norman Group много раз повторял: слова и поступки людей расходятся. Спрашивать «стали бы вы пользоваться такой функцией?» бессмысленно: человек не может предсказать, как поведёт себя с тем, чего ещё не видел.

Сильные сигналы - те, за которые человек чем-то платит: контактом, временем или деньгами.

• оставил заявку с телефоном или почтой;
• внёс предоплату или забронировал время;
• вернулся и воспользовался ещё раз;
• позвал коллегу или прислал знакомого.

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

В разговорах спрашивайте о прошлом опыте вместо планов на будущее: «Как вы решали эту задачу в последний раз? Где было неудобно? Сколько стоило?» Рассказ о случившемся надёжнее обещаний.

Что поручить ИИ. Свести ответы анкет и заметки из разговоров, сгруппировать повторяющиеся проблемы, найти противоречия. Перед загрузкой уберите имена, телефоны и почту: это персональные данные (подробнее - в шаге 3). Выводы модели сверяйте с исходными ответами: при пересказе она может сгладить или усилить формулировки.

И не заменяйте людей нейросетью. Сервисы «синтетических пользователей» обещают ответы ИИ-персонажей вместо интервью. Nielsen Norman Group разобрала такой подход в 2024 году: синтетические пользователи часто дают поверхностные или слишком благожелательные отзывы, годятся для кабинетного исследования и придумывания гипотез, но не для итоговых решений. Вывод разбора: исследованию нужны реальные люди.

Шаг 6. Примите решение: дальше, менять или закрыть

Когда срок вышел, вернитесь к критерию из шага 2 и сравните с ним фактические цифры. Исход уже определён заранее, остаётся записать его и следующее действие.

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

Прежде чем масштабировать прототип

Прототип, собранный за день, создан для проверки, а не для потока клиентов. В посте я писал об этом прямо:

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

• опору для аудита уязвимостей - OWASP Top 10, документ о самых критичных рисках безопасности веб-приложений (актуальная версия - OWASP Top 10 2025). Сам аудит - работа разработчика или специалиста по безопасности: код, написанный ИИ, должен проверять человек. Разобрать пункты списка с ИИ-помощником можно заранее, для подготовки, но аудит это не заменяет;
• ключи и пароли - не в тексте программы, а в отдельных настройках с ограниченным доступом;
• резервные копии заявок и данных клиентов и проверку, что из копии можно восстановиться;
• персональные данные - всё из раздела про 152-ФЗ, теперь уже для настоящих клиентов;
• ответственного, который понимает, как устроен продукт, и чинит его, когда что-то ломается.

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

Частые вопросы