MVP, минимально жизнеспособный продукт, это самая простая версия продукта или системы, на которой можно проверить главную гипотезу на настоящих пользователях. По определению Эрика Риса, которое приводит Agile Alliance, MVP даёт максимум подтверждённых знаний о клиентах при минимуме усилий. Виды: лендинг, консьерж, «волшебник страны Оз», сборка из готовых сервисов, одна функция. За месяц можно проверить одну гипотезу: 3 дня на гипотезу и порог успеха, 5 на разговоры, 10 на сборку, 10 на запуск и 2 на решение. Подход работает и для внутренних систем: проверяют, будут ли ими пользоваться сотрудники.
MVP что это простыми словами: минимально жизнеспособный продукт, от английского minimum viable product. Это самая простая версия продукта, сервиса или системы, на которой можно проверить главное предположение на настоящих пользователях. MVP нужен не для того, чтобы быстро выпустить продукт, а для того, чтобы быстро узнать, стоит ли его делать дальше. Часто такую проверку можно уложить в месяц, если заранее решить, что проверяем и какая цифра будет считаться успехом.
Ниже разберём, откуда взялся термин, чем MVP отличается от прототипа и пилота, какие бывают виды, как сделать MVP внутренней системы или новой услуги и как пройти проверку идеи за 30 дней.
Откуда термин и что в нём главное
Главное в MVP это обучение, а не продукт. Термин стал популярным после книги Эрика Риса «Бережливый стартап». Agile Alliance приводит его определение: MVP это та версия нового продукта, которая позволяет команде собрать максимум подтверждённых знаний о клиентах при минимуме усилий.
Работает это циклом «создать, измерить, научиться». Вы делаете минимальную версию, смотрите, что делают люди, и решаете: продолжать или менять курс. Отсюда два слова в названии:
- Минимальный. В нём только то, без чего не проверить главную гипотезу. Всё остальное потом.
- Жизнеспособный. Им реально можно пользоваться и получить пользу. Кнопка «Купить», за которой ничего нет, это не MVP, а обман пользователя.
MVP, прототип, PoC, пилот и первая версия: в чём разница
Все пять слов про раннюю стадию, но отвечают на разные вопросы. Если их путать, можно сделать дорогой прототип и решить, что проверили спрос.
| Что это | На какой вопрос отвечает | Кто видит | Пример |
|---|---|---|---|
| Прототип | Понятно ли и удобно ли | Команда и несколько тестовых пользователей | Кликабельные экраны кабинета без работающей логики |
| PoC, доказательство концепции | Технически это вообще возможно | Команда | Проверка, что данные из учётной системы можно забирать автоматически |
| MVP | Нужно ли это людям и будут ли они пользоваться или платить | Настоящие клиенты или сотрудники | Запись на новую услугу через форму и бота, расписание ведётся вручную |
| Пилот | Работает ли решение в реальных условиях на части компании | Один отдел, филиал или группа клиентов | Новая система заявок в одном офисе на месяц |
| Первая версия | Можно ли этим пользоваться всем каждый день | Все пользователи | Система после MVP с доработками по итогам проверки |
Виды MVP: какой выбрать
Выбор вида зависит от того, что именно вы проверяете: интерес, готовность платить или удобство. Чем меньше кода нужно для проверки, тем лучше.
| Вид | Как устроен | Что проверяет | Пример для малого бизнеса |
|---|---|---|---|
| Лендинг с формой | Одна страница с описанием и заявкой или предзаказом | Интерес к предложению | Страница новой услуги выездного обслуживания, реклама на небольшой бюджет |
| Консьерж | Услугу вручную оказывает человек, клиент об этом знает | Ценность и готовность платить | Менеджер сам подбирает поставщика клиенту и присылает подборку в мессенджер |
| «Волшебник страны Оз» | Для клиента всё выглядит автоматическим, но за экраном работает человек | Удобство сценария | Форма расчёта на сайте, расчёт делает инженер и отправляет за 15 минут |
| Из готовых сервисов | Форма, таблица, бот, оплата связаны между собой без своей разработки | Сценарий и экономику | Запись через бота, данные в таблице, напоминания по расписанию |
| Одна функция | Своя разработка, но только главного сценария | Регулярное использование | Кабинет, где клиент видит только статус своего заказа |
Про честность. «Волшебник страны Оз» допустим, пока клиент получает обещанный результат. Если в MVP есть форма с именем и телефоном, вы собираете персональные данные: часть 2 статьи 18.1 закона 152-ФЗ требует опубликовать на сайте политику их обработки. Это касается и одностраничного лендинга.
MVP не только для стартапов: внутренняя система и новая услуга
Подход MVP хорошо работает внутри компании. Большинство статей про MVP рассказывают о стартапах, но собственнику малого бизнеса чаще нужно проверить другое: будут ли сотрудники пользоваться новой системой и купят ли клиенты новую услугу.
Пример: внутренняя система заявок. Компания хочет свою систему учёта заявок вместо таблицы и чатов. Вместо полной системы на полгода делается MVP на месяц: форма заявки, список со статусами и уведомление ответственному. Без отчётов, ролей и интеграций. Проверяем одно: перестали ли заявки теряться и ведут ли их менеджеры в системе, а не в чате.
Пример: кабинет клиента. Клиенты постоянно звонят узнать статус заказа. MVP: страница, где по номеру заказа виден статус, статусы менеджер обновляет вручную. Проверяем, станет ли меньше звонков.
Пример: новая услуга. Сервисная компания думает о подписке на обслуживание. MVP: лендинг, консьерж-режим для первых клиентов, договор и счета вручную. Проверяем, сколько людей подпишутся за месяц и сколько продлят.
| Что проверяем | Метрика | Откуда цифра |
|---|---|---|
| Интерес к новой услуге | Доля посетителей, оставивших заявку | Цели в Яндекс Метрике |
| Готовность платить | Число оплат или подписанных договоров | Бухгалтерия, CRM |
| Использование внутренней системы | Доля заявок, заведённых в систему, а не в чат | Сверка системы с чатом за неделю |
| Польза кабинета | Число звонков «где мой заказ» до и после | Журнал звонков или телефония |
| Удержание | Сколько вернулись или продлили | Данные MVP через 2–4 недели |
Если сотрудники обходят новую систему стороной, это тоже результат MVP. Как измерять использование и что делать с теневыми каналами, разобрано в статье про приёмку системы по метрикам.
Как проверить идею за месяц: план на 30 дней
Месяца хватает, если проверять одну гипотезу и собирать MVP из простых частей. Пример плана для новой услуги или небольшой системы:
- Дни 1–3. Гипотеза и порог. Запишите одно предложение и одну цифру, которая будет считаться успехом.
- Дни 4–8. Разговоры. 5–10 разговоров с клиентами или сотрудниками: как они решают задачу сейчас, что их раздражает, сколько это стоит.
- Дни 9–18. Сборка. Минимальная версия: лендинг, форма, бот, таблица, одна функция. Сразу настройте измерение, например цели в Метрике.
- Дни 19–28. Запуск. Пускаете первых пользователей: рекламу на небольшой бюджет, рассылку своим клиентам или один отдел.
- Дни 29–30. Решение. Сравниваете цифры с порогом и решаете, что дальше.
Как читать: больше половины месяца уходит не на сборку, а на подготовку и на работу с пользователями. Если сборка не помещается в 10 дней, MVP слишком большой: уберите всё, что не нужно для проверки главной гипотезы, или замените разработку ручной работой.
Кто делает MVP и из чего его собирают
MVP не обязательно заказывать у разработчиков. Чем проще гипотеза, тем меньше нужно кода. Своя разработка нужна там, где проверяется именно работа программы: расчёт, кабинет, обмен с вашей учётной системой.
| Из чего собрать | Кто может сделать | Ограничение |
|---|---|---|
| Лендинг на конструкторе и форма | Маркетолог или сам владелец | Проверяет интерес, но не удобство продукта |
| Таблица, форма и уведомления | Сотрудник, который ведёт процесс | Ломается при росте объёма и числа людей |
| Бот в мессенджере | Разработчик за несколько дней | Сложные экраны и отчёты в боте неудобны |
| Небольшое веб-приложение | Разработчик или команда | Дольше и дороже, поэтому только для главного сценария |
Хорошее правило: всё, что можно на время проверки сделать руками, делайте руками. Автоматизируют то, что подтвердилось.
Где взять первых пользователей
MVP без пользователей ничего не проверяет. План, откуда они придут, нужен до сборки, а не после.
- Свои клиенты. Рассылка или звонок тем, кто уже покупал. Быстро, но такие люди лояльнее новых, учитывайте это в выводах.
- Небольшая реклама. Поисковая или в соцсетях на одну страницу. Даёт новых людей и понятную цифру: сколько стоил один интерес.
- Один отдел. Для внутренней системы. Выберите отдел, где боль сильнее всего, и человека, который отвечает за переход.
- Партнёры. Компании, у которых те же клиенты: можно предложить им попробовать новую услугу для своих клиентов.
Гипотеза и критерий успеха: как записать
Хорошая гипотеза содержит кого, какое действие, срок и цифру. Без цифры любой результат можно назвать успехом. Шаблон:
Шаблон гипотезы. Мы считаем, что [кто] будет [что делать], потому что [какая боль]. Гипотеза подтверждена, если за [срок] [метрика] будет не меньше [порог].
Пример: «Мы считаем, что владельцы загородных домов будут оформлять подписку на сезонное обслуживание, потому что им неудобно каждый раз искать мастера. Гипотеза подтверждена, если за 3 недели рекламы 10 человек оставят заявку и 3 оплатят первый месяц». Цифры здесь условные: порог вы считаете сами, исходя из того, при каком числе клиентов услуга окупится.
Порог считают от экономики, а не от желаемого. Подставьте свои цифры: калькулятор покажет, окупится ли продукт, если MVP подтвердит спрос в таком объёме.
Как считается: заявки = посетители × доля заявок; продажи = заявки × доля покупок; прибыль = продажи × средний чек × маржа − расходы в месяц. Разгон учитывает, что поток клиентов набирается не сразу. Строка «заявок, чтобы окупиться за год» подскажет порог успеха для MVP.
Готов ли ваш план MVP
Перед тем как что-то собирать, пройдите короткую проверку. Чаще всего MVP проваливается не из-за разработки, а из-за того, что не решили, что и как измерять.
Что делать после MVP
После проверки у вас три пути: развивать, менять или остановиться. Все три это нормальный результат: MVP для того и делали, чтобы не потратить полгода на ненужное.
- Развивать. Порог достигнут. Сначала автоматизируйте то, что делали вручную, потом добавляйте функции, о которых просили пользователи. Здесь уже нужно ТЗ на первую версию.
- Менять. Результат близко к порогу. Поменяйте одну вещь: аудиторию, предложение или канал, и проверьте ещё раз.
- Остановиться. Результат далеко от порога. Запишите, что узнали. Это сэкономленный бюджет, а не провал.
Сохраните всё, что узнали за месяц: записи разговоров, цифры, жалобы пользователей, ручные операции, которые делали за систему. Это готовая основа для ТЗ на первую версию. В ней уже понятно, какие функции нужны людям, а какие никто не попросил.
Если идея подтвердилась и нужна своя система, переход от MVP к рабочему продукту описан в статье про этапы разработки веб-приложения. А если вы сомневаетесь, писать код или собрать продукт на конструкторе, посмотрите обзор конструкторов приложений и когда нужен код.
Частые ошибки MVP
- MVP на полгода. В него добавляют «ещё одну функцию», и проверка превращается в полноценную разработку.
- Нет порога. После запуска любые цифры объясняют как успех.
- Нет измерения. Запустили, но не настроили цели и не ведёте учёт, поэтому через месяц нечего сравнивать.
- Слишком сыро. Продукт не решает задачу даже минимально, и люди уходят не из-за идеи, а из-за неудобства.
- Нет пользователей. MVP собрали, а привести на него людей не запланировали.
- Проверяют на своих. Мнение друзей и коллег не заменяет поведение настоящих клиентов.
- Внутренняя система без хозяина. Нет человека, который следит, что сотрудники работают в MVP, а не по-старому.
С чего начать на этой неделе
- Запишите гипотезу по шаблону и порог успеха с цифрой.
- Договоритесь о 5 разговорах с клиентами или сотрудниками.
- Выберите вид MVP, для которого нужно меньше всего разработки.
- Решите, где будете считать цифры, и настройте это до запуска.
Если MVP нужна своя разработка, например кабинет, бот с логикой или небольшая система, её можно собрать по этапам с понятным результатом каждого. Так устроена разработка веб-приложений и MVP: сначала главный сценарий, потом всё остальное.
Частые вопросы
Что такое MVP простыми словами?
Это самая простая версия продукта, которой уже можно пользоваться и на которой можно проверить главное предположение. Цель MVP не выпустить продукт, а понять, стоит ли его развивать.
Чем MVP отличается от прототипа?
Прототип показывает, как будет выглядеть продукт, и проверяет удобство, им пользуются в тесте. MVP работает по-настоящему и проверяет, нужен ли продукт людям: будут ли они им пользоваться или платить.
Сколько времени занимает MVP?
Зависит от вида. Лендинг, консьерж или сборку из готовых сервисов часто можно уложить в месяц вместе с проверкой. Если сборка не помещается в две недели, MVP обычно слишком большой.
Можно ли сделать MVP без программиста?
Часто да: лендинг на конструкторе, форма, таблица, бот, ручная работа вместо автоматизации. Своя разработка нужна, когда главная гипотеза касается именно работы программы.
Нужен ли MVP для внутренней системы компании?
Да, это хороший способ не потратить месяцы на систему, которой не будут пользоваться. Делают минимальную версию для одного процесса или отдела и смотрят, ведут ли сотрудники работу в ней, а не по-старому.
Как понять, что MVP удался?
Сравнить результат с порогом, который записали до запуска: например, число заявок и оплат за три недели. Если порога нет, понять нельзя, поэтому его задают заранее.
Что делать, если MVP не подтвердил гипотезу?
Если результат близко к порогу, поменять одну вещь: аудиторию, предложение или канал, и проверить снова. Если далеко, остановиться и записать выводы. Это сэкономленный бюджет.
Нужно ли ТЗ для MVP?
Короткое описание нужно всегда: гипотеза, главный сценарий, что не входит в MVP, как измеряем. Подробное ТЗ пишут на первую версию после того, как MVP подтвердил идею.
