TL;DR
- MVP - это минимальная версия проверки, которая дает максимум обучения при минимальных затратах.
- MVP не обязан быть приложением. Это может быть лендинг, ручной сервис, прототип, concierge-подход или предзаказ.
- Главный вопрос MVP: какой самый рискованный допуск мы проверяем?
- Плохой MVP проверяет "понравится ли всем". Хороший MVP проверяет конкретное поведение конкретного сегмента.
- После MVP должно быть решение: продолжать, менять гипотезу, сузить сегмент, поменять оффер или закрыть идею.
Зачем это бизнесу
Команды часто строят продукт так, будто спрос уже доказан. Делают дизайн, кабинет, роли, оплату, интеграции, красивый лендинг, а потом узнают, что клиенту не нужна сама идея. MVP нужен, чтобы не платить полную цену за ошибку.
Для маркетолога MVP важен не меньше, чем для продакта. Через MVP можно проверить оффер, сегмент, цену, канал, возражения и язык клиента до большой закупки трафика. Это снижает риск и ускоряет поиск PMF.
Схема
MVP не начинается с функции. Он начинается с риска: что должно оказаться правдой, чтобы проект имел смысл?
Как это работает
Сначала выпишите допущения. Например: "клиники готовы платить за отчет по пропущенным звонкам", "маркетологам нужен шаблон server-side tracking", "родители будут покупать подписку на подготовку к экзамену". Потом выберите самое опасное. Если оно неверно, проект бессмысленен.
Затем выберите самый дешевый способ проверки. Для B2B это может быть ручной пилот: команда сама собирает отчет, отдает клиенту и смотрит, готов ли он платить. Для consumer-продукта - лендинг с предзаказом или waitlist. Для сложного SaaS - прототип в Figma и звонки, но только если после них есть реальное действие: заявка, оплата, письмо, согласие на пилот.
Метрика должна быть заранее. Не "получить фидбек", а "5 платных пилотов из 20 целевых разговоров", "20% посетителей оставляют заявку", "10 компаний соглашаются дать доступ к данным для теста". Если метрики нет, команда после теста будет спорить эмоциями.
MVP должен быть честным. Нельзя обещать автоматизацию, если все делается вручную, но можно сказать: "на первом пилоте отчет собираем руками, чтобы понять нужный формат". Клиент обычно нормально относится к ручной работе, если получает ценность.
Локальный контекст
В Казахстане MVP часто проще проверять через ручные продажи и пилоты. Рынок компактнее, многие ниши завязаны на доверие, и быстрый разговор с владельцем бизнеса может дать больше, чем месяц абстрактной рекламы.
Например, перед созданием SaaS для салонов можно не писать код. Достаточно взять 10 салонов, руками собрать в таблице пропущенные записи, повторные визиты и источники клиентов, а потом показать владельцу, где теряются деньги. Если за такой отчет не готовы платить или внедрять изменения, приложение тоже не спасет.
Как применять
- Запишите идею продукта одним предложением.
- Выпишите 5-7 допущений, без которых идея не работает.
- Выберите самое рискованное допущение.
- Придумайте самый дешевый тест поведения, а не мнения.
- Заранее поставьте метрику успеха и срок.
- Проведите тест на конкретном сегменте.
- После теста примите решение, а не "еще чуть-чуть понаблюдаем".
Видео
Что почитать
- Lean Startup Co.: What Is an MVP? Eric Ries Explains
- Lean Enterprise Institute: Lean Startup
Главный совет
MVP должен проверять риск, а не демонстрировать амбиции команды. Если после теста вы не можете принять решение, значит, вы проверяли не ту гипотезу или не поставили метрику заранее.