Что такое MVP и как его сделать: виды, объём, сроки и метрики

MVP (Minimum Viable Product, минимально жизнеспособный продукт) — это самая маленькая версия продукта, на которой можно проверить главную гипотезу о спросе: есть ли проблема, решает ли её продукт и готовы ли люди за это платить. Хороший MVP даёт максимум знаний о рынке при минимуме затрат. Иногда это работающее приложение с одной функцией, а иногда лендинг или ручной сервис без строчки кода.

Статья для основателей, продакт-менеджеров и руководителей IT-компаний в Казахстане, которые запускают новый продукт или направление. Разбираем, чем MVP является и чем нет, шесть видов MVP с примерами, как определить объём, этапы и сроки, метрики проверки, особенности рынка Казахстана и ошибки, которые съедают бюджет.

Что такое MVP на самом деле

Термин популяризировал Эрик Рис в книге «Бережливый стартап». Главная идея: продукт строится циклом «создать — измерить — сделать выводы», и MVP — это самый короткий путь пройти этот цикл первый раз.

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

Если гипотезу нельзя сформулировать одной фразой, MVP строить рано. Сначала стоит поговорить с потенциальными клиентами и понять, какую проблему вы решаете.

Чем MVP не является

Вокруг MVP много путаницы, и она обходится дорого.

MVP — не кривая первая версия. Продукт с багами и неудобным интерфейсом проверяет не спрос, а готовность терпеть баги. Объём можно урезать, качество ключевого сценария нельзя.

MVP — не урезанная версия всего задуманного. Если взять план на десять функций и сделать каждую наполовину, получится десять полуфункций, а не MVP. Правильно сделать одну функцию полностью.

MVP — не прототип для инвестора. Презентация и красивые макеты не показывают, как ведут себя реальные пользователи.

MVP — не финальный продукт. Часть кода и решений после проверки гипотезы выбросят или переделают. Это нормально и закладывается заранее.

MVP — не обязательно программа. Если гипотезу можно проверить без разработки, её нужно проверить без разработки.

Виды MVP и примеры

Вид MVP выбирают по гипотезе, а не по привычке команды писать код.

Вид MVP	Как работает	Что проверяет	Когда подходит
Лендинг	Страница с описанием продукта и формой заявки или предзаказа	Интерес к предложению и готовность оставить контакт	Нужно быстро проверить ценностное предложение и каналы
Консьерж-MVP	Команда вручную оказывает услугу, клиент знает об этом	Ценность результата и готовность платить	Сервисы, B2B, сложные процессы
Wizard of Oz	Клиент видит интерфейс, работу за ним вручную делает команда	Готовность пользоваться продуктом в привычном виде	Автоматизация и AI-сервисы до сложной разработки
No-code	Продукт собран на готовых платформах без программирования	Использование и удержание на реальном потоке	Простая логика, небольшое число пользователей
Кликабельный прототип	Интерактивные экраны без бэкенда	Понятность сценария и интерес на интервью	Сложный интерфейс, B2B-демо
Одна ключевая функция	Настоящий продукт, который делает одно дело хорошо	Удержание и оплату	Гипотеза подтверждена, нужна проверка в реальном использовании

Известные примеры. Dropbox до полноценной разработки показал видео о том, как будет работать синхронизация файлов, и проверил интерес по реакции аудитории. Основатель Zappos начинал с того, что выкладывал на сайт фотографии обуви из местных магазинов и при заказе покупал пару сам. Оба случая проверяли спрос до того, как строить дорогую инфраструктуру.

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

О no-code отдельно. Конструкторы позволяют собрать работающий продукт за дни, и для проверки гипотезы это часто лучший выбор. Но у них есть потолок: сложная логика, нагрузка, интеграции и хранение данных зависят от возможностей платформы. Если MVP на no-code подтвердил спрос, продукт обычно переписывают, и это нужно заранее заложить в план, а не считать неудачей.

Как проверить спрос ещё до MVP за две недели, мы разбирали в статье «Как проверить спрос на IT-продукт до разработки».

Как определить объём MVP

Объём MVP определяется одним ключевым сценарием. Порядок работы такой.

1. Сформулируйте гипотезу. Кто клиент, какая у него проблема, какой результат он получит и за что заплатит.
2. Опишите ключевой сценарий. Путь пользователя от входа до результата, ради которого он пришёл. Обычно это пять-десять шагов.
3. Вычеркните всё, что не входит в сценарий. Настройки, роли, отчёты, уведомления, интеграции — каждая функция должна доказать, что без неё сценарий не работает.
4. Замените автоматизацию ручной работой. Админку заменяет таблица, модерацию — сотрудник, сложную интеграцию — выгрузка раз в день.
5. Оставьте аналитику. События ключевого сценария должны записываться с первого дня, иначе MVP ничего не измерит.

Чтобы спор о функциях не длился неделями, полезно сразу разложить список на две колонки.

Обычно входит в MVP	Обычно подождёт
Ключевой сценарий от входа до результата	Второстепенные сценарии и редкие случаи
Простой вход по почте или телефону	Сложные роли и права доступа
Хранение данных и резервное копирование	Полноценная админка: её заменяет таблица или ручная работа
События аналитики по ключевому сценарию	Подробные дашборды и отчёты
Способ получить оплату или подтверждение готовности платить	Автоматический биллинг со скидками и тарифами
Канал связи с пользователем	Центр уведомлений, рассылки, чат внутри продукта

Сильнее всего объём двигают число ролей пользователей, платежи, интеграции с внешними системами и выбор между вебом и мобильным приложением. Как каждый из этих факторов влияет на трудоёмкость и бюджет, разобрано в статье «Сколько стоит MVP в Казахстане в 2026 году».

Этапы и сроки создания MVP

Сроки зависят от вида MVP и объёма, поэтому ниже ориентиры по этапам, а не обещания.

Этап	Что происходит	Ориентир по сроку
Исследование	Интервью с клиентами, формулировка гипотезы и порогов решения	Одна-две недели
Проверка без кода	Лендинг, прототип или консьерж-формат	От нескольких дней до нескольких недель
Аналитика и дизайн	Ключевой сценарий, экраны, события для аналитики	Одна-три недели
Разработка	Одна ключевая функция, вход, хранение данных, базовая админка	От нескольких недель до нескольких месяцев
Тестирование и запуск	Проверка ключевого сценария, публикация, первые пользователи	Одна-две недели, для мобильных приложений дольше из-за ревью в сторах
Измерение	Сбор данных, интервью с пользователями, решение	Несколько недель реального использования

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

Последний этап часто забывают. Запуск MVP — это начало проверки, а не её конец. Решение о продолжении принимают по данным за несколько недель, а не по первым отзывам.

Метрики: как понять, что MVP сработал

Главное правило: пороги задаются до запуска. Если сначала собрать данные, а потом решать, что считать успехом, любые цифры покажутся обнадёживающими.

Метрика	Что показывает	Вопрос, на который отвечает
Конверсия в ключевое действие	Сколько пришедших прошли основной сценарий	Понятен ли продукт и нужен ли он с первого раза
Активация	Сколько новых пользователей получили первый результат	Доходят ли люди до ценности
Удержание	Сколько возвращаются через неделю и месяц	Решает ли продукт регулярную задачу
Готовность платить	Предзаказы, оплаты, подписанные пилоты	Есть ли бизнес, а не только интерес
Качественные сигналы	Что пользователи говорят на интервью, о чём просят	Почему цифры такие и что менять

Сколько пользователей нужно. Для B2B-продукта на старте достаточно нескольких компаний, которые реально используют продукт в работе, плюс подробные интервью с ними. Для массового продукта нужен поток, на котором видна разница между каналами и когортами, и здесь важнее не число, а то, что пользователи пришли не только из круга знакомых основателя. Друзья и коллеги дают завышенные оценки и искажают проверку.

Регистрации, лайки и комплименты на демо — слабые сигналы. Сильные сигналы — повторное использование, оплата и ситуация, когда пользователь расстраивается, если продукт пропадает. Когда сильные сигналы становятся устойчивыми и растут без ручных усилий команды, это уже разговор о соответствии продукта рынку, подробнее в статье «Product-market fit: что это и как понять, что он у вас есть».

MVP в Казахстане: рынок и каналы

Рынок Казахстана меньше и плотнее, чем рынки, на которые ориентируются англоязычные гайды. Это и ограничение, и преимущество. Ограничение: в узкой B2B-нише может быть несколько сотен потенциальных клиентов, и каждый неудачный контакт заметен. Преимущество: до этих клиентов можно дотянуться лично, через рекомендации и отраслевые сообщества, и получить обратную связь быстро.

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

Контекст Казахстана. Если MVP собирает персональные данные пользователей и вам или вашим клиентам важно хранить их в Казахстане, это влияет на выбор хостинга и no-code-платформ с первого дня: многие зарубежные конструкторы хранят данные за пределами страны. Переезд после запуска дороже, чем правильный выбор на старте. Двуязычие тоже стоит учесть заранее: если аудитория говорит на казахском и русском, проверьте, нужен ли интерфейс на обоих языках уже в MVP.

Какие каналы работают для первых клиентов SaaS-продукта, мы описали в статье «GTM для SaaS в Казахстане», а особенности запуска мобильного продукта — в статье о выводе мобильного приложения на рынок Казахстана.

Ошибки при создании MVP

Начать с разработки. Самая дорогая ошибка. Если гипотезу можно проверить лендингом или ручным сервисом, код подождёт.

Нет гипотезы и порогов. Команда запускает продукт «посмотреть, что будет», и любой результат трактуется как успех.

Слишком много функций. Каждая лишняя функция удлиняет срок и размывает вывод: непонятно, что сработало, а что нет.

Экономия на качестве ключевого сценария. Пользователь, который упёрся в ошибку на третьем шаге, не вернётся, и вы решите, что спроса нет.

Нет аналитики. Без событий в ключевом сценарии MVP превращается в мнение команды о том, как всё прошло.

Мобильное приложение там, где хватит веба. Две платформы и ревью в сторах удлиняют путь до первых данных.

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

Нет плана после MVP. Что делать, если гипотеза подтвердилась, и что делать, если нет, нужно решить заранее, чтобы данные превратились в действие.

Как мы это делаем

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

Как устроена работа, этапы и что входит в результат, описано на странице услуги разработки MVP и запуска IT-продуктов.

Термины простыми словами

MVP (Minimum Viable Product)

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

Гипотеза

Проверяемое предположение о клиентах и продукте, например «руководители IT-студий будут платить за автоматические отчёты клиентам». MVP строится вокруг одной главной гипотезы.

Консьерж-MVP

Формат, при котором команда вручную оказывает услугу, которую потом будет выполнять продукт. Клиент знает, что работают люди. Проверяет ценность до разработки.

Wizard of Oz MVP

Формат, при котором клиент видит интерфейс продукта, а работу за ним вручную делает команда. Проверяет, готовы ли пользоваться продуктом, без дорогой автоматизации.

No-code

Платформы, на которых приложение собирают из готовых блоков без программирования. Подходят для быстрой проверки идеи, но ограничены в масштабировании и доработках.

Кликабельный прототип

Интерактивный макет продукта, по экранам которого можно пройти как по настоящему приложению. Проверяет понятность и интерес, но не реальное использование.

Удержание (retention)

Доля пользователей, которые возвращаются к продукту через день, неделю или месяц. Главный сигнал того, что продукт решает реальную задачу.

Конверсия

Доля людей, которые перешли с одного шага на следующий: из посетителя в заявку, из заявки в оплату. Показывает, где продукт теряет клиентов.