Идея в том, чтобы не строить полгода завод, если ещё непонятно, нужен ли людям сам товар. Берёте одну ключевую функцию, выкатываете её на реальных пользователей и смотрите, платят ли они, возвращаются ли, ругаются ли. Дёшево ошибиться сейчас лучше, чем дорого ошибиться после релиза «всего и сразу».
Частая ошибка — путать минимальный продукт с сырым и кривым. MVP должен решать задачу пользователя, пусть и узко, а не вызывать желание закрыть вкладку. Вторая беда — влюбиться в свой MVP и не услышать данные, которые говорят «гипотеза не подтвердилась». Тогда лучше развернуться, чем тащить мёртвую идею дальше.
Версия с одной ключевой фишкой ради быстрой проверки спроса.
За 2 недели понятно, нужен ли продукт рынку вообще.
Ошибку находят на прототипе, а не в готовом релизе.
Вместо полноценного маркетплейса собрали лендинг с формой заказа и табличкой Excel вместо базы. За неделю 30 заявок подтвердили спрос — и только тогда стали проверять product-market fit.
MVP проверяет одну конкретную гипотезу, поэтому до запуска полезно зафиксировать метрику успеха и порог: например, «из 100 визитов на лендинг 5 оставят заявку» или «20% вернутся на второй день». Без числа заранее любой результат можно подогнать под «вроде работает» — это и есть та самая влюблённость в идею, когда данные читают избирательно. Здесь MVP смыкается с проверкой гипотез: вы не доказываете, что продукт хорош, а пытаетесь его опровергнуть и смотрите, выдержит ли он.
Под MVP часто маскируют две разные сущности. «Concierge» — когда заказы вручную обрабатывает основатель, а пользователь думает, что работает система; «Wizard of Oz» — когда интерфейс настоящий, но за ним нет автоматизации. Оба способа дают честный сигнал о спросе без месяцев разработки. Главное — тестировать на реальной целевой аудитории, а не на знакомых: лояльные друзья подтвердят что угодно, и подтверждённый ими product-market fit окажется фантомным.