MVP: что это простыми словами, примеры и как проверить гипотезу

Коротко

MVP — инструмент проверки, а не этап разработки.

• MVP проверяет одно предположение: будут ли люди этим пользоваться, платить, возвращаться.
• Минимальность меряют не числом функций, а стоимостью ответа: иногда MVP — это лендинг без продукта вообще.
• Гипотезу, метрику и порог успеха записывают до запуска. После запуска любой результат легко объяснить как успех.
• Выборка должна быть достаточной: 300 посетителей лендинга не отличат конверсию 3% от 5%.
• Результат MVP — решение: строить дальше, менять или закрыть.

Что такое MVP простыми словами

Идея проста: у каждого продукта есть предположение, без которого он не имеет смысла. «Малый бизнес будет платить за автоматические отчёты». «Люди станут покупать обувь, не примерив её». MVP — минимальная вещь, которая даёт честный ответ на такое предположение, пока ошибка ещё дешёвая.

Термин популяризировал Эрик Рис в книге The Lean Startup (2011; в русском издании — «Бизнес с нуля»), где MVP описан как версия продукта, дающая максимум проверенного знания о клиентах при минимуме усилий.

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

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

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

MVP — также не прототип. Прототип показывают людям, чтобы проверить, понятен ли интерфейс. MVP дают в работу, чтобы проверить, нужен ли продукт настолько, что его используют или за него платят. Кликабельный макет в Figma отвечает на вопрос «разберутся ли», но не на вопрос «заплатят ли».

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

Форму MVP выбирают по предположению, которое нужно проверить. Если сомнение в спросе, продукт строить рано. Если спрос понятен, а сомнение в том, вернутся ли люди, нужна рабочая функция.

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

Как проверить гипотезу с помощью MVP: работа аналитика

До запуска аналитик превращает смутное «посмотрим, как пойдёт» в проверяемое утверждение. Шаблон: «Мы считаем, что [сегмент] будет [действие], потому что [причина]. Поймём, что правы, если [метрика] за [срок] будет не ниже [порог]».

Метрика — одна главная. Если критериев пять, после запуска какой-нибудь обязательно выполнится, и его объявят главным. Порог выбирают от экономики: при какой доле пользователей функция окупит свою полноценную разработку. Срок — такой, чтобы пользователи успели дойти до действия.

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

Сколько нужно посетителей, чтобы MVP что-то показал

Допустим, лендинг нового тарифа имеет смысл, если в заявку конвертируется 5% посетителей, а при 3% тариф убыточен. Сколько людей надо привести, чтобы различить эти два мира?

Если сравнивать два варианта лендинга между собой (уровень значимости 5%, мощность 80%), нужно по 1506 посетителей на вариант, всего около 3000. Если лендинг один и проверяется, превышает ли конверсия 3%, при тех же условиях и одностороннем тесте хватит примерно 539 посетителей.

А вот 300 посетителей не хватит. При 12 заявках из 300 конверсия 4%, и 95-процентный интервал — от 1,8% до 6,2%. В него попадают и 3%, и 5%: MVP ничего не решил, хотя выглядит как результат. Посчитайте число заранее и заложите бюджет на трафик.

Пример: функция отчётов как MVP на учебных данных

Вернёмся к модулю отчётов. Представим, что вместо трёх месяцев разработки команда выпустила минимальную версию: создать отчёт и выгрузить его в файл. Проверим её на учебной базе SQL-курса — это данные SaaS-продукта «Маяк», тот же DuckDB, что в песочнице.

Гипотеза: пользователи с рабочим пространством будут создавать отчёты и получать от них пользу. До запуска записали критерий. Главная метрика — доля создавших отчёт, которые выгрузили его в течение 14 дней, порог 40%: выгрузка — сигнал пользы, отчёт ушёл из продукта в работу. Входное условие — отчёт за 14 дней создадут не меньше 50% пользователей с рабочим пространством, иначе главную метрику не на ком мерить.

Первое открытие — про логирование. В базе у каждого пользователя не больше одного события report_created: пишется только первый отчёт. Повторное создание отчётов из этих данных не посчитать, поэтому повторное использование пришлось мерить косвенно, через выгрузку и возвраты. Проверьте логирование до запуска, а не после.

Берём регистрации 1 июня – 31 июля, чтобы у всех хватило 14 дней на каждый шаг.

with firsts as (
  select user_id,
         min(event_time) filter (where event_name = 'workspace_created') as ws_at,
         min(event_time) filter (where event_name = 'report_created')    as report_at,
         min(event_time) filter (where event_name = 'export_completed')  as export_at
  from events
  group by user_id
),
eligible as (
  select f.*
  from firsts f
  join users u using (user_id)
  where f.ws_at is not null
    and u.signup_date between date '2026-06-01' and date '2026-07-31'
),
returns as (
  select e.user_id, count(distinct cast(e.event_time as date)) as return_days
  from events e
  join eligible el using (user_id)
  where e.event_name = 'app_open'
    and cast(e.event_time as date) >  cast(el.report_at as date)
    and e.event_time < el.report_at + interval 14 day
  group by e.user_id
)
select
  count(*) as with_workspace,
  count(*) filter (where report_at < ws_at + interval 14 day) as reported_14d,
  round(100.0 * count(*) filter (where report_at < ws_at + interval 14 day) / count(*), 1) as adoption_pct,
  count(*) filter (where report_at < ws_at + interval 14 day
                     and export_at < report_at + interval 14 day) as exported_14d,
  count(*) filter (where report_at < ws_at + interval 14 day
                     and r.return_days >= 1) as returned_14d,
  count(*) filter (where report_at < ws_at + interval 14 day
                     and r.return_days >= 2) as returned_2days
from eligible
left join returns r using (user_id);

Какое решение принять по итогам MVP

Принятие высокое: две трети пользователей с рабочим пространством попробовали отчёт. Но выгрузили его только 38,1% — ниже порога. Возвраты выглядят отлично, 88,6%, пока не сравнишь их с теми, кто отчёт не делал. Из 595 пользователей с рабочим пространством без отчёта 85,4% тоже заходили минимум в 2 разных дня за 14 дней после создания пространства. Разница 3,2 п.п., а это корреляция, не эффект функции: в продукт возвращаются почти все.

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

Чем MVP отличается от MLP, MMP, прототипа и PoC

Аббревиатур много, и их путают. Разница — в вопросе, на который отвечает каждая версия.

Частые ошибки

Почти все ошибки с MVP сводятся к одному: запуск есть, а проверки нет.

• Нет записанной гипотезы и порога. Любой результат потом называют успехом или «нужно больше данных».
• Проверяют не то предположение. Красивый прототип подтверждает, что интерфейс понятен, а спрос остаётся непроверенным.
• Слишком маленькая выборка. 300 визитов на лендинг не различают 3% и 5%, но создают ощущение ответа.
• Событие не логируется. После запуска выясняется, что нужное действие не пишется или пишется только первый раз.
• Главная метрика не различает группы. Возвраты 88,6% выглядят сильно, пока без функции они 85,4%.
• MVP не выключают. Консьерж-процесс или временный костыль живёт годами, потому что никто не принял решения.

Проверьте на учебной базе

Откройте песочницу и посчитайте те же показатели отдельно по каналам users.channel. Проверьте, в каком канале выгрузка отчётов проходит порог 40%, а в каком нет, и решите, для кого стоило бы строить модуль в первую очередь.