VJOURNAL

Бизнес • Глобальная редакция •

Что такое MVP простыми словами: минимально жизнеспособный продукт, примеры и границы метода

Минимально жизнеспособный продукт — не сырая первая версия, а эксперимент: он должен с наименьшими усилиями показать, нужен ли продукт людям. Откуда взялся термин, какие бывают MVP, как урезать объём и что измерять.

Обложка VJOURNAL к материалу «Что такое MVP простыми словами: минимально жизнеспособный продукт, примеры и границы метода»

Короткий ответ

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

6 источников
По формулировке Эрика Риса, MVP — версия продукта, которая даёт максимум знаний о клиентах при наименьших усилиях.
Википедия относит термин к 2001 году и Фрэнку Робинсону; широко известным его сделали Стив Бланк и Эрик Рис.
MVP проверяет не технологию, а бизнес-гипотезу: стоит ли делать продукт и станет ли кто-то за него платить.

Минимально жизнеспособный продукт — эксперимент, а не маленький продукт

Когда спрашивают, что такое MVP, обычно ждут названия типа продукта: небольшое приложение, сырая первая версия. Точнее — эксперимент, к которому приложен продукт. Английская Википедия определяет минимально жизнеспособный продукт как версию, где функций ровно столько, чтобы ею пользовались первые клиенты и давали обратную связь для дальнейшей разработки. Кофейня, которая до заказа приложения проверяет предзаказ простой формой для постоянных гостей, уже сделала свой MVP.

По той же статье, термин придумал и определил в 2001 году Фрэнк Робинсон, а известным сделали Стив Бланк и Эрик Рис. Формулировку, которую цитируют основатели, дал Рис: в августе 2009 года в блоге Startup Lessons Learned он назвал MVP версией нового продукта, которая позволяет команде собрать максимум подтверждённых знаний о клиентах при наименьших усилиях. Знания здесь — результат, усилия — цена.

Чем MVP не является: черновик, прототип, демонстрация для инвестора

Название сбивает с толку, и Рис сам это признаёт: MVP, вопреки названию, не про создание минимальных продуктов. В отрывке из книги The Lean Startup, который TechCrunch опубликовал в 2011 году, он добавляет: это не обязательно самый маленький продукт, и, в отличие от прототипа, его цель — проверить основные бизнес-гипотезы, а не только вопросы дизайна и техники. Прототип показывает, что нечто может работать. MVP показывает, нужно ли это настоящим клиентам.

И это не разрешение выпускать сломанное. В статье Википедии собрана критика: продукт ниже ожидаемого минимума качества проигрывает конкурентам, которые выходят на рынок с планкой выше, а плохие отзывы о раннем выпуске могут ударить по репутации компании. Демонстрация для инвестора — третья вещь: она показывает, что могло бы существовать, тем, кто этим пользоваться не будет. То единственное, что делает MVP, обязано работать как следует.

Вопрос, на который отвечает MVP, и гипотеза до первой строки кода

Сайт The Lean Startup формулирует цель одной строкой. Вопрос не в том, можно ли сделать этот продукт; вопросы в том, стоит ли его делать и можно ли построить вокруг него устойчивый бизнес. Толковая команда со временем сделает почти что угодно. А изменят ли незнакомые люди привычку и заплатят ли за результат, неизвестно, пока кто-нибудь не попробует.

Википедия приводит пример. В 2015 году специалисты Сиднейского университета создали робота Rippa для автоматизации фермерских работ и борьбы с сорняками. Техническая гипотеза (робот отличает сорняк от культуры) уже была доказана, бизнес-гипотеза (он окажется жизнеспособным инструментом на действующей ферме) ещё нет. Небольшая компания записывает то же одной фразой до всякого кода: кто клиент, как он решает задачу сегодня, что сделает с продуктом и какая цифра к какой дате значит «да».

Три вида MVP и задокументированный пример каждого

В самом лёгком виде продукта нет вовсе. Историю Dropbox Рис рассказывает в отрывке на TechCrunch: работающую программу нельзя было показать как прототип, и глава компании Дрю Хьюстон снял простое трёхминутное видео для первых пользователей новых технологий. По словам Хьюстона, очередь на бета-версию выросла с 5000 до 75 000 человек буквально за ночь. Здесь, заключает Рис, видео и было минимально жизнеспособным продуктом. Страница, которая собирает заявки, работает так же.

Второй вид — лендинг, который просит чуть больше, чем адрес почты. Основатель Buffer Джоэл Гаскойн описал свой в блоге компании в феврале 2011 года. Первая версия из двух страниц проверяла, станут ли люди рассматривать такое приложение. Затем он вставил между ними страницу с тарифами, чтобы видеть, какой план выбирают, и небольшая часть посетителей нажимала на платные. Лишь после этого он собрал продукт, и первый платящий клиент появился в первые четыре дня после запуска.

Третий вид — услуга, которую выполняют вручную за простой витриной. Статья Википедии о бережливом стартапе со ссылкой на Риса описывает, как основатель Zappos Ник Суинмерн проверял, станут ли люди покупать обувь в интернете. Он фотографировал товар в местных обувных магазинах, выкладывал снимки в сеть, после продажи покупал пару по полной цене и отправлял покупателю. Самый простой вид — одна функция, сделанная как следует: Гаскойн хотел взять одну функцию приложений для Twitter, отложенную публикацию, и довести её до блеска.

Как урезают объём: один пользователь, один сценарий, один результат

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

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

Что измерять после запуска и что считать ответом

День запуска приносит цифры, и большинство из них льстит. Статья Википедии о бережливом стартапе делит метрики на два сорта. Метрики тщеславия рисуют самую радужную картину и не отражают того, что движет бизнесом; типичный пример — число новых пользователей в день. Если привлечение каждого дорогой рекламой обходится заметно дороже, чем выручка с него, рост числа пользователей может быстро довести до банкротства. Действенные метрики ведут к обоснованному деловому решению.

У первой версии действенных цифр немного. Сколько из увидевших предложение попробовали продукт, сколько вернулись без напоминания, сколько заплатили. Гаскойн отчитался так: примерно через два с половиной месяца после запуска — больше 500 пользователей и около 4% перешедших на платные планы. Ответу нужен ещё и порог, заданный заранее, иначе любой результат читается как ободрение. Сайт The Lean Startup называет следующее решение: если то, на чём держится бизнес-модель, не сдвигается, пора разворачиваться, то есть структурно менять курс.

Три ошибки: год разработки, запуск без цифр и вежливый интерес

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

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

Что подготовить, прежде чем заказывать MVP в студии

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

Поэтому принесите один лист. На нём один пользователь, один сценарий, результат, который он должен получить, цифра и дата, которые значат «да», и то, чему уже научили дешёвые проверки. VITON13 Studio делает MVP веб-приложений по таким брифам; объём и стоимость расписаны в гайде и на странице услуги ниже. С этим листом вопрос «что такое MVP» сменяется практическим: какая самая маленькая версия способна доказать, что вы ошибаетесь.

Практический чеклист

  • Запишите гипотезу одной фразой: кто пользователь, что он сделает, какая цифра к какой дате значит «да».
  • Выберите самую дешёвую проверку, которая даст ответ: страница с формой, видео, услуга вручную или одна функция.
  • Урежьте первую версию до одного пользователя, одного сценария и одного видимого результата; остальное — в список «потом».
  • Настройте подсчёт попыток, возвратов и оплат до прихода первого посетителя, а не после него.
  • Назначьте день, когда посмотрите цифры, и заранее решите, какой результат значит продолжать, менять курс или остановиться.

Вопросы и ответы

Чем MVP отличается от прототипа?

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

Обязательно ли MVP должен быть программой?

Нет. Dropbox проверил спрос трёхминутным видео, а Zappos начинался с фотографий обуви из местных магазинов и заказов, которые выполняли вручную. Программа нужна только тогда, когда на вопрос нельзя ответить без работающего продукта.

Сколько времени должна занимать разработка MVP?

Общей нормы нет, и источники её не называют. Основатель Buffer рассчитывал на неделю, а потратил семь, работая по вечерам и выходным. Полезнее обратный вопрос: в какой самый ранний день настоящие пользователи смогут дать вам ответ.

Подходит ли MVP действующему малому бизнесу или это только для стартапов?

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

Когда MVP — неподходящий способ проверить идею?

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