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