Что такое MVP и зачем начинать с минимальной версии продукта
MVP (от английского Minimum Viable Product — «минимально жизнеспособный продукт») — самая простая версия продукта, которой уже можно пользоваться. Не «продукт целиком когда-нибудь потом», а маленькая, но работающая часть, которую можно показать людям сейчас.
Ключевое слово здесь — viable, «жизнеспособный». Урезать функции легко; сложнее урезать так, чтобы оставшееся всё ещё решало задачу человека целиком. Половина моста — не MVP моста.
Пример
Вы хотите сделать сервис доставки готовой еды.
- Не MVP: приложение с картами, чатом курьера, программой лояльности и оплатой в рассрочку. Полгода работы до первого клиента.
- MVP: одна страница с меню и формой заказа, а развозите вы сами. Неделя работы.
Второй вариант отвечает на главный вопрос — станут ли люди заказывать — за неделю вместо полугода. Всё остальное имеет смысл строить только после утвердительного ответа.
Чем MVP отличается от похожих вещей
| Что это | Кому показывают | |
|---|---|---|
| Прототип | Кликабельный макет, внутри ничего не работает | Себе и команде — проверить логику экранов |
| Proof of concept | Проверка, что технически это вообще возможно | Себе и инвестору |
| MVP | Работающий продукт с одной ценностью | Настоящим пользователям, за деньги или за контакт |
| Первая версия | Полноценный продукт с набором функций | Рынку |
Главное различие — MVP встречается с реальным человеком, у которого есть реальная задача. Прототип и PoC живут внутри команды.
Почему нельзя строить «всё и сразу»
Самая дорогая ошибка основателя — потратить месяцы и деньги, а потом обнаружить, что продукт никому не нужен. MVP защищает от этого сразу с трёх сторон.
- Быстро. Идея проверяется за дни, а не за месяцы.
- Дёшево. Вы не вкладываетесь в то, что может не пригодиться.
- По-честному. Реакция людей, которые столкнулись с продуктом, важнее любых догадок.
Идея — это гипотеза. MVP — способ проверить её, пока цена ошибки мала.
Как понять, что версия достаточно минимальная
Три вопроса, на которые полезно ответить до начала работы.
- Какую одну задачу человека решает продукт? Если задач больше одной, вы строите не MVP.
- Что произойдёт, если убрать эту функцию? Если ничего критичного — её не должно быть в MVP.
- Какой ответ вы хотите получить от пользователей? Если не можете сформулировать, MVP не нужен — нужны разговоры с людьми.
Что обесценивает MVP
Показывать только знакомым. Они не откажут и не заплатят. Нужны люди, которым вы ничем не обязаны.
Считать успехом лайки и «интересно». Единственный надёжный сигнал — потраченный ресурс: деньги, время, контакт, действие.
Строить MVP из функций, а не из задачи. «Сделаем регистрацию, потом каталог, потом оплату» — это план разработки, а не минимальная версия. Начинать надо с того, за чем человек пришёл.
Не заложить, что делать с ответом. Заранее решите, что означает «гипотеза не подтвердилась» и что вы сделаете в этом случае. Иначе результат просто проигнорируется.
Что дальше
MVP — это шаг, а не весь путь. Дальше идут проверка на людях, экономика, трафик и первые заявки. Полная последовательность с признаками «этап пройден» и типичными ошибками — на странице Путь основателя.
Практика: собрать первый набор артефактов можно за десять минут, регистрация для этого не нужна — Первый MVP за 10 минут.