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