MVP продукта: как проверить идею сервиса до полной разработки

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

Что такое MVP продукта

MVP расшифровывается как minimum viable product — минимально жизнеспособный продукт. Автор подхода Эрик Рис определяет его как версию нового продукта, которая позволяет команде собрать максимум проверенной информации о клиентах с наименьшими усилиями. Ключевые слова здесь — «проверенная информация»: число функций вторично.

MVP отвечает на вопрос, который нельзя закрыть обсуждением на планёрке. Будут ли владельцы кафе заказывать продукты через приложение? Заплатят ли родители за онлайн-запись к логопеду? Дойдут ли клиенты до оплаты, если доставка платная? Ответ даёт поведение людей, а не их слова в опросе.

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

MVP — это эксперимент в форме продукта. Его результат — решение «строим дальше или меняем идею».

Зачем делать MVP вместо полной разработки

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

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

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

Чем MVP отличается от макета, пилота и первой версии

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

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

Факт. Atlassian в руководстве по MVP советует ограничивать его лишь несколькими функциями и считать испытательным полигоном для бизнес-концепции.

Какие бывают MVP?

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

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

Метод «волшебника страны Оз» Nielsen Norman Group описывает как приём исследований, который часто используют при разработке MVP. Классический пример — Zappos: до складов и автоматизации основатель проверял ценностное предложение, выполняя заказы сам — покупал обувь в обычном магазине и отправлял клиенту.

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

Для тестов с пользователями не нужны большие выборки. Якоб Нильсен из NN/g пишет, что лучшие результаты дают тесты не более чем с 5 пользователями и как можно больше таких небольших тестов. Для MVP это значит: несколько разговоров после каждой правки полезнее одного большого исследования в конце.

Мнение. Если вы не можете заранее написать, какой результат заставит вас отказаться от идеи, эксперимент не готов. Сначала порог провала, потом запуск.

Какие метрики смотреть у MVP?

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

Хорошая метрика для MVP привязана к действию, которое стоит человеку усилий или денег. Оставил заявку с телефоном. Внёс предоплату. Вернулся и воспользовался сервисом второй раз. Пригласил коллегу. Чем дороже действие для пользователя, тем честнее сигнал.

Условный пример: сервис онлайн-записи к частным мастерам. Плохая метрика — сколько людей открыли лендинг. Хорошая — сколько мастеров после бесплатной недели сами попросили продлить доступ. Порог задаётся до запуска и зависит от экономики: сколько стоит привлечь мастера и сколько он принесёт.

Технически большинство таких метрик собирается целями в Яндекс Метрике и CRM. Как связать сайт, заявки и продажи, разобрано в статье про аналитику сайта и расчёт ROI.

Что делать, когда MVP запущен?

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

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

Менять курс — если интерес есть, но не там, где вы ждали. Клиенты не пользуются записью, зато просят напоминания. Платят не мастера, а салоны. Это новая гипотеза для следующего MVP.

Закрыть идею — если люди не совершают действий даже при простом и бесплатном входе. Это самый дешёвый провал из возможных, ради него эксперимент и делают.

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

Когда MVP не подходит?

Подход MVP хорош там, где ошибка дешёвая, а неопределённость высокая. Есть случаи, где он работает плохо или требует других форм.

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

Второй — когда спрос очевиден и проверен. Если вы делаете внутренний портал для собственных сотрудников или сайт-каталог для действующего бизнеса с понятными клиентами, проверять «нужно ли это» незачем. Здесь работает обычная разработка по техническому заданию.

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

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

С чего начать

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

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

Мы помогаем пройти оба этапа: собрать лендинг для проверки спроса, а после подтверждения гипотезы — спроектировать и разработать портал или сервис под реальные сценарии клиентов.

Источники

• Что такое продукт с минимальной функциональностью (MVP)? — Atlassian
• The Wizard of Oz Method in UX — Nielsen Norman Group
• Why You Only Need to Test with 5 Users — Nielsen Norman Group