MVP: что это и как разработать минимально жизнеспособный продукт
Если коротко: MVP (minimum viable product, минимально жизнеспособный продукт) — это самая простая версия продукта, которая уже решает главную задачу пользователя и которую можно дать реальным людям, чтобы проверить спрос до вложений в полную разработку. Ключевых слов здесь два, и они одинаково важны: минимальный — значит без всего лишнего, жизнеспособный — значит работающий, а не огрызок. Половина бед с MVP начинается там, где помнят про первое слово и забывают про второе.
Code Pilots с 2014 года запускает цифровые продукты, в том числе с нуля — от стартап-идеи до платформы с реальной нагрузкой, как GigAnt. И первое, что мы проговариваем с основателем: MVP — это не «дешёвый и сырой», а «маленький, но настоящий». Этот материал — про то, что такое MVP на самом деле, чем он отличается от прототипа, PoC и пилота (их постоянно путают), как урезать продукт до сути и не отрезать жизненно важное, какие бывают типы MVP и как понять, что он сработал. Общие этапы разработки, выбор платформы и стоимость — это отдельные темы, они в статьях про жизненный цикл разработки, в зонтичном гайде и в материале о цене.
Что такое MVP на самом деле: «минимальный» и «жизнеспособный» одинаково важны
Термин ввёл Фрэнк Робинсон в 2001 году, а в обиход его вывел Эрик Рис в книге «Бережливый стартап»: MVP он определил как версию продукта, которая позволяет команде получить максимум проверенных знаний о клиентах при наименьших усилиях. Смысл не в том, чтобы сделать подешевле, а в том, чтобы быстрее всего узнать главное: нужен ли продукт людям и будут ли им пользоваться, — пока на это потрачено мало денег.
Лучше всего суть объяснил Хенрик Книберг своей известной картинкой. Неправильный путь: сначала делаем колесо, потом раму, потом кузов и только в самом конце — готовый автомобиль. Проблема в том, что до последнего шага у пользователя на руках бесполезные детали — на колесе никуда не доедешь. Правильный путь: сначала скейтборд, потом самокат, велосипед, мотоцикл и в финале автомобиль. На каждом шаге у человека есть то, на чём можно ехать прямо сейчас, — и с каждой итерацией становится удобнее. MVP — это скейтборд, а не колесо от будущей машины.
Отсюда главная ошибка, на которой спотыкаются чаще всего: «минимальный» понимают как «обрезанный», и выкатывают нерабочий огрызок без половины нужных функций. Скейтборд — простой, но он едет; обрезанный автомобиль без двигателя не едет никак. Жизнеспособность означает, что MVP полноценно закрывает одну главную задачу, а не плохо делает десять. Это и есть граница между «маленьким настоящим продуктом» и «недоделкой, которую стыдно показать».
MVP, PoC, прототип и пилот: что чем проверяют
Эти четыре слова в разговорах смешивают, а они про разные вопросы и разные стадии. Путаница дорого обходится: можно заказать «MVP», а получить технический эксперимент, который нельзя показать пользователю, — или наоборот.
| Что это | На какой вопрос отвечает | Кому показывают | |
|---|---|---|---|
| PoC (proof of concept) | Технический эксперимент осуществимости | «Это вообще можно построить?» | Внутри команды, не пользователям |
| Прототип | Кликабельная имитация интерфейса | «Удобно ли, та ли логика?» | Тестовым пользователям, без реального кода |
| MVP | Минимальный работающий продукт | «Нужно ли это людям, будут ли пользоваться?» | Реальным пользователям, в бою |
| Пилот | Ограниченный запуск полного продукта | «Работает ли в реальных условиях?» | Узкой группе в контролируемой среде |
Логика такая: PoC снимает технический риск («потянем ли мы распознавание лиц на этом объёме»), он живёт внутри команды и пользователю не показывается. Прототип проверяет, удобен ли интерфейс и верна ли логика, — на нём кликают, но за ним нет настоящего кода и данных (подробно — в отдельной статье про прототипирование). MVP — это уже работающий продукт в руках реальных пользователей, его задача — проверить спрос и ценность. Пилот — это запуск полного продукта на ограниченной группе, типичный для регулируемых отраслей вроде медицины или финтеха, где «выкатить сырое всем» нельзя. Часто они идут по очереди: PoC → прототип → MVP → пилот → полный продукт, но не каждому проекту нужны все четыре.
Как урезать продукт до MVP и не отрезать лишнее
Самое трудное в MVP — не построить, а решить, что в него НЕ войдёт. Основатель обычно видит продукт целиком, со всеми функциями сразу, и каждая кажется обязательной. Работа здесь — найти ту единственную ценность, ради которой продукт вообще существует, и оставить только то, что её обеспечивает.
Практический способ — задать по каждой функции три вопроса. Какое главное действие, ради которого пользователь придёт? Без чего это действие физически невозможно совершить? И что из остального — приятно, но подождёт? Первые две группы — это и есть MVP, третья откладывается. Для сервиса доставки еды ядро — выбрать блюдо, оформить и оплатить заказ, получить его; программа лояльности, рейтинги курьеров, сторис ресторанов — всё это потом. Если выкинуть оплату, продукт перестанет быть жизнеспособным; если выкинуть сторис — никто не заметит.
Полезно сразу разделить функции на две корзины и держать дисциплину:
- Must-have — без этого продукт не решает свою главную задачу. Это и есть MVP.
- Nice-to-have — улучшает опыт, но не критично для проверки гипотезы. Это бэклог на потом.
Соблазн «добавим ещё вот это, это же быстро» — главный враг MVP: из десяти таких «быстро» собирается тот самый долгий и дорогой полный продукт, который мы как раз и не хотели делать раньше времени. Чем честнее команда режет до ядра, тем быстрее и дешевле проверит идею.
Типы MVP: от лендинга до «консьержа»
MVP — это не обязательно урезанное приложение. Иногда проверить гипотезу можно вообще без разработки продукта. Тип подбирают под то, что именно нужно узнать:
| Тип MVP | Как устроен | Что проверяет | Пример |
|---|---|---|---|
| Лендинг / видео | Страница или ролик про продукт и кнопка | Есть ли спрос в принципе | Dropbox — видео-демо до разработки, сбор листа ожидания |
| «Консьерж» | Услугу оказывают вручную, пользователь это знает | Готовы ли платить за ценность | Ручной подбор до автоматизации |
| «Волшебник из страны Оз» | Снаружи автоматика, внутри запросы обрабатывают руками | Работает ли механика для пользователя | Имитация «умного» сервиса людьми за ширмой |
| Однофункциональный | Реальный продукт, но одна ключевая функция | Заработает ли ядро на людях | Spotify — только стриминг; Uber — вызов машины в одном городе |
Выбор типа зависит от вопроса. Если непонятно, есть ли спрос вообще, — хватит лендинга или видео; если спрос ясен, а вопрос в том, заработает ли механика, — нужен работающий однофункциональный продукт. «Консьерж» и «Волшебник из страны Оз» хороши, когда автоматизация дорогая, а проверить ценность хочется до вложений в неё.
Как понять, что MVP сработал: build — measure — learn
MVP без заранее определённой метрики успеха — это не эксперимент, а просто маленький продукт, выпущенный наугад. Смысл MVP — в цикле, который Эрик Рис назвал build — measure — learn: построили минимальную версию, измерили поведение реальных пользователей, сделали вывод — и решили, что дальше.
Поэтому метрику успеха задают ДО запуска, а не подгоняют после. Что мы хотим увидеть, чтобы считать гипотезу подтверждённой: какую долю дошедших до оплаты, какой процент вернувшихся на второй день, сколько заявок с лендинга? Без этого числа любой результат можно объявить успехом, а это самообман. Когда данные собраны, развилок две: persevere (продолжать — гипотеза подтвердилась, наращиваем продукт по бэклогу) или pivot (развернуться — пользователи ведут себя не так, как ждали, меняем подход, пока не вложились в полную версию). Именно ради этой развилки MVP и затевается: дешево узнать, что идея не работает в задуманном виде, — это не провал проекта, а сэкономленный бюджет на полной разработке не того продукта.
Частые ошибки с MVP
Урезать до нерабочего. «Минимальный» поняли как «лишь бы что-то», и продукт не закрывает даже одну задачу. Жизнеспособность не опциональна.
Золочение (gold-plating). Обратная крайность: в MVP тащат всё «чтобы сразу красиво». Получается долгий дорогой полный продукт под вывеской MVP — и весь смысл быстрой проверки теряется.
Не задать метрику. Запустили, «вроде пользуются» — и непонятно, успех это или нет. Без числа успеха MVP не отвечает ни на один вопрос.
«MVP» как оправдание сырого. MVP — это про узкий объём, а не про низкое качество. То, что входит в MVP, должно работать нормально: «это же MVP» не оправдывает падающие функции и сломанную оплату.
Делать MVP для инвестора, а не для пользователя. Продукт, заточенный произвести впечатление на питче, проверяет не спрос, а красоту слайда. Учиться надо у пользователей.
MVP там, где нужен пилот. В медицине, финтехе, на регулируемых рынках «выкатить минимальное всем» нельзя — там сначала пилот в контролируемой среде. Тип проверки выбирают под отрасль.
С чего начать
Порядок такой:
- Сформулировать одну главную гипотезу (какую ценность и какому пользователю проверяем) и метрику, по которой поймёте, что она подтвердилась
- Вычленить ядро — то единственное действие, без которого продукта нет, — и честно отложить остальное в бэклог
- Выбрать тип MVP под вопрос (иногда хватит лендинга, иногда нужен работающий однофункциональный продукт)
- Запустить на реальных пользователях, собрать данные и принять решение — наращивать или разворачиваться
- И не путать MVP с прототипом, PoC или сырой версией полного продукта
Самое дорогое в продукте — построить целиком то, что никому не нужно, и понять это после релиза. MVP переносит этот вывод в начало, где цена ошибки минимальна. Code Pilots помогает довести идею до жизнеспособного MVP — с аналитикой, которая отделит ядро от бэклога, и разработкой, которая сделает это ядро по-настоящему работающим, а не сырым. Расскажите о задаче — подскажем, что проверять в первую очередь и каким способом это сделать дешевле всего.
Частые вопросы (FAQ)
Они проверяют разное. PoC (proof of concept) отвечает на вопрос «это технически возможно построить» и живёт внутри команды. Прототип — кликабельная имитация интерфейса, проверяет удобство и логику на тестовых пользователях, но за ним нет реального кода. MVP — это уже работающий продукт в руках реальных пользователей, его задача — проверить спрос и ценность в бою. Часто они идут по очереди: PoC → прототип → MVP.
Нет. «Минимально жизнеспособный» означает узкий по объёму, но работающий: он полноценно закрывает одну главную задачу, а не плохо делает десять. То, что входит в MVP, должно работать нормально. «Это же MVP» — не оправдание для падающих функций и сломанной оплаты; это оправдание только для отсутствия второстепенных возможностей.
Столько, сколько нужно для одного ключевого сценария ценности, — и ни одной сверх. Практический фильтр: оставляем то, без чего главное действие пользователя физически невозможно (must-have), и откладываем всё, что просто улучшает опыт (nice-to-have). Обычно это заметно меньше, чем кажется основателю на старте.
Можно, но это ставка на то, что вы заранее знаете, что нужно пользователю. Если гипотеза не подтвердится, вы это узнаете уже на готовом продукте — самый дорогой момент для такого открытия. MVP переносит проверку в начало. Исключение — регулируемые отрасли (медицина, финтех), где вместо публичного MVP запускают пилот в контролируемой среде.
По заранее заданной метрике. До запуска решают, что считать успехом — например, доля дошедших до оплаты или процент вернувшихся пользователей, — и после запуска сверяются с этим числом. Если гипотеза подтвердилась — продукт наращивают по бэклогу (persevere); если пользователи ведут себя не так, как ждали, — меняют подход (pivot), пока не вложились в полную версию.
