Что такое MVP на самом деле и чем он не является

MVP (minimum viable product, минимально жизнеспособный продукт) — это самая маленькая вещь, которая проверяет самое рискованное предположение о продукте на настоящих людях. Не урезанная версия мечты, а эксперимент, после которого ты знаешь больше, чем до него.

Вокруг вопроса «что такое MVP» накопилось столько толкований, что слово почти ничего не значит. Одни называют так первую версию с половиной фич, другие — красивый макет в Figma, третьи — всё, что собрано за выходные. Разберёмся, что в этом определении действительно важно.

Главное слово — «предположение»

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

Обычно одно из допущений рискованнее остальных: если оно неверно, остальное уже не имеет значения. MVP строится вокруг него. Если главный риск — «будут ли платить», то MVP — это страница с ценой и кнопкой оплаты, а не приложение с личным кабинетом. Если главный риск — «сможет ли модель надёжно разбирать эти документы», то MVP — скрипт, который прогоняет сотню реальных документов, а не лендинг.

Отсюда простой тест: если ты не можешь одним предложением сказать, какую гипотезу проверяет твой MVP и какой результат её опровергнет, — это не MVP, а просто ранняя версия.

Что такое MVP по сравнению с прототипом и v1

Эти три слова часто смешивают, хотя отвечают они на разные вопросы.

Прототип отвечает на вопрос «как это может выглядеть и работать?». По нему кликают, его показывают, но реальной ценности он не создаёт. Кликабельный макет, демо на выдуманных данных.
MVP отвечает на вопрос «нужно ли это людям так, как мы думаем?». Им пользуются по-настоящему, даже если внутри всё держится на ручной работе и таблицах.
v1 отвечает на вопрос «можем ли мы поставлять это стабильно?». Это уже продукт, который выдерживает рост, платежи, поддержку и требования безопасности.

Вайбкодинг размыл границы: за вечер в Lovable или Cursor получается то, что выглядит как v1. Но внешний вид ничего не говорит о том, какой вопрос ты проверил. Работающее приложение без единого пользователя — это просто дорогой прототип.

Насколько маленьким должен быть MVP

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

Вход через пять соцсетей, тёмная тема, настройки уведомлений, админка — почти никогда не проверяют гипотезу. Иногда MVP вообще не требует кода: форма, таблица и ты, отвечающий руками. Это называется консьерж-подходом, и он честнее многих приложений.

Но у слова «viable» есть смысл. MVP должен решать проблему достаточно хорошо, чтобы человек захотел вернуться. Если продуктом невозможно пользоваться, отказ ничего не скажет о гипотезе — только о том, что продукт сырой.

Частые ошибки с MVP

Строить то, что легко, а не то, что рискованно. Интерфейс собирать приятно, поэтому его и собирают. А главный риск — например, продажи — так и остаётся непроверенным.
Не решить заранее, что считать успехом. Без порога любой результат можно истолковать как «в целом неплохо». Запиши до запуска: сколько человек, что они должны сделать и за какой срок.
Показывать только друзьям. Друзья вежливые. Им нравится всё.
Считать MVP фундаментом. Код, написанный ради проверки гипотезы, часто не годится для роста. Это нормально: у него была другая задача. Плохо, когда об этом забывают и строят v1 поверх, ничего не пересматривая.
Затягивать. MVP, который делается полгода, проверяет уже другой рынок и другое терпение.

Что делать после MVP

Если гипотеза подтвердилась, переходи к следующей по степени риска и параллельно решай, что из сделанного можно оставить. Если опровергнута — это тоже результат, причём купленный дёшево. Меняй гипотезу, а не цвет кнопки.

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

Коротко

MVP — самая маленькая вещь, которая проверяет самое рискованное предположение на реальных людях.
Прототип показывает, как может выглядеть продукт, MVP проверяет, нужен ли он, v1 поставляет его стабильно.
До запуска запиши гипотезу и порог, по которому поймёшь, подтвердилась она или нет.
MVP часто можно сделать без кода или почти без него.
Код MVP не обязан быть фундаментом для v1, и это нормально.

SUBXCAT помогает довести проверенный MVP до продукта, который выдерживает настоящих пользователей.