MVP, то есть minimum viable product (минимально жизнеспособный продукт), — это минимальная версия продукта, которая позволяет проверить самое важное предположение на реальных пользователях. Это не «дешёвая версия приложения», а кратчайший путь к ответу на вопрос: действительно ли это кому-то нужно и сделают ли люди то, чего вы ожидаете.
Если вы попали сюда из мира игр или спорта: там MVP означает «most valuable player», то есть лучший игрок. В этой статье речь о продукте.
Откуда взялся термин
Термин появился в начале 2000-х, а популярными его сделали Стив Бланк и Эрик Рис. В «The Lean Startup» Рис описывает MVP как версию продукта, которая позволяет собрать максимум проверенных знаний о клиентах при минимуме усилий. Здесь важны два слова: знания и усилия. MVP нужен, чтобы вы чему-то научились, а не просто чтобы он существовал.
Что значат три буквы
- Minimum — только то, что нужно, чтобы проверить одно предположение. Каждая лишняя функция удлиняет путь до первого ответа.
- Viable — продукт должен реально работать и давать ценность. Разваливающийся макет не скажет вам, хотят ли люди такое решение, он скажет лишь, что они не хотят сломанного.
- Product — то, чем люди пользуются или за что платят. Опрос «купили бы вы это?» — исследование, а не продукт.
Самая частая ошибка — держаться только за первую букву. «Minimum» без «viable» даёт продукт, который ничего не доказывает.
Виды MVP
Не каждое MVP — приложение. Начинайте с самого дешёвого способа, который даст достоверный ответ.
Страница с записью (smoke test). Вы описываете продукт так, будто он уже существует, и считаете, сколько людей оставляют e-mail или нажимают «купить». Спрос проверяется ещё до того, как написана хоть одна строка кода продукта.
Concierge MVP. Услугу вы выполняете вручную для первых нескольких клиентов. Вы сразу узнаёте, за что они платят и что для них важно, и только потом автоматизируете.
MVP «Волшебник страны Оз» (Wizard of Oz). Клиент видит готовый продукт, но за кулисами часть работы делает человек. Вы проверяете, пользуются ли люди решением, прежде чем строить дорогую автоматизацию.
Продукт с одной функцией. Работающее приложение, которое хорошо делает одну вещь: например, только бронирование, без программы лояльности, чата и отчётов. Это самая частая форма, когда предположение касается того, будут ли люди пользоваться продуктом регулярно.
MVP из готовых блоков. Форма, таблица, платёжный сервис и автоматизация вместо собственной системы. Быстро и дёшево, но у такого решения есть пределы, когда трафик растёт.
Известные примеры
- Dropbox до создания полного продукта показал короткое видео о том, как будет работать синхронизация файлов. Список желающих вырос с нескольких тысяч до десятков тысяч человек за одну ночь. Это был тест спроса, а не приложение.
- Zappos в начале не имел склада. Основатель фотографировал обувь в местных магазинах, а после заказа покупал пару и отправлял клиенту. Он проверял, будут ли люди покупать обувь через интернет.
- Airbnb начал со сдачи надувных матрасов в квартире основателей во время конференции в Сан-Франциско, когда в отелях не было мест. Простой сайт, несколько гостей, настоящие деньги.
Во всех трёх случаях первая версия проверяла одно предположение, от которого зависела вся идея.
Чем MVP не является
Это не прототип для показа инвесторам. Прототип проверяет, можно ли понять решение и пользоваться им. MVP проверяет, пользуются ли им люди и платят ли за него. Обе вещи полезны, но отвечают на разные вопросы.
Это не первая версия с половиной функций. Если список функций MVP выглядит как годовой план, разрезанный на две части, это не MVP. Это полный продукт, который просто делается медленнее.
Это не небрежность. Узкий объём не оправдывает ошибки, медленную работу и небезопасное хранение данных. Функций мало, но сделаны они добротно.
Это не конец работы. MVP — начало цикла обучения. После него идут данные, решения и следующие версии.
Как выбрать объём MVP
- Запишите предположения. У кого есть проблема, как он решает её сегодня, сколько это ему стоит, почему он выберет вас.
- Выберите самые рискованные. То, которое, если окажется ложным, перечёркивает остальные. Обычно оно касается того, достаточно ли болезненна проблема, а не того, можно ли решить её технически.
- Определите, что будет успехом. Конкретно и до старта: например, «10 из 50 человек из списка платят за первый месяц». Без этого любой результат можно истолковать в свою пользу.
- Уберите всё остальное. Вход через пять сервисов, панель с отчётами, приложение под две системы: если это не помогает проверить то единственное предположение, это подождёт.
Подробнее о том, как вести такой цикл шаг за шагом, я пишу в теме о методологии lean startup, а об упорядочивании предположений на одной странице — в теме о lean canvas.
Сколько стоит MVP и сколько времени занимает
Зависит от вида. Страница с записью или concierge MVP может появиться за несколько дней и стоить немного. Работающее веб-приложение с одной главной функцией, входом и платежами — это обычно несколько недель работы.
У меня MVP веб-приложения с узким объёмом стоит 1 900–9 300 € по фиксированной цене и занимает 2–6 недель. Откуда берётся такой разброс и какие бывают скрытые расходы, я подробно разбираю в статье Стоимость MVP в 2026 году. Если хотите начать, посмотрите, как я делаю MVP.
Частые вопросы
Обязательно ли MVP должно быть приложением? Нет. Если главный вопрос — «хочет ли это кто-нибудь», часто хватает страницы, разговоров и услуги, выполненной вручную. Приложение стоит строить, когда вы хотите проверить, будут ли люди пользоваться им регулярно.
Можно ли показывать клиентам MVP, если оно «недоделано»? Да, при условии что то, что оно делает, оно делает хорошо. Первые пользователи прощают нехватку функций, но не прощают, когда не работает базовое.
Что после MVP? Вы измеряете, что сделали люди, и решаете: развивать, сменить направление или закончить. О том, как понять, что продукт попал в потребность, я пишу в теме о product-market fit.