Что такое MVP, как его создать и протестировать

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

Это и есть MVP — минимально жизнеспособный продукт. В отличие от целого сервиса, его несложно и недорого сделать. Команда смотрит на отклик: если многие делают заказ в телеграм-канале, значит, у полноценного продукта тоже есть потенциал.

В статье подробно рассказываем:

• что такое MVP и зачем он нужен;
• какие виды MVP бывают и как выбрать из всего многообразия;
• как поэтапно создать MVP;
• какие ошибки приведут к сливу бюджета.

Эксперты:

• Ольга Звегинцева — Data PO в Smartbroker+, ex-Sberbank, соавтор и ведущая интенсива «Product Discovery»;
• Валерия Розова — сооснователь WANNABE, автор курсов для продакт-менеджеров, работала СРО в Qlean, BestDoctor, отвечала за Customer Experience в Doc+ и за маркетинг в Gett.

<<guide-create-business-model>>

Что такое MVP

MVP (minimum viable product, минимально жизнеспособный продукт) — это тестовая версия продукта с минимальным набором функций, причём только тех, которые отражают главную ценность продукта. Как такового продукта ещё не существует, но его функции уже можно показать пользователям.

[example]

Spotify. На старте в сервисе была только одна функция — потоковая передача музыки: играло несколько треков, которые выбирала продуктовая команда.

[/example]

[example]

Twitch. Чтобы оценить интерес к стримингу, основатель 24/7 ходил с камерой и снимал собственную жизнь, периодически играя в игры. Трансляция велась на лендинге с чатом, где зрители оставляли комментарии и общались.

[/example]

[example]

Airtable. В MVP можно было только создавать и изменять таблицы. Больше ничего не было — ни связок, ни работы с данными, ни интеграций.

[/example]

Цель создания MVP — быстро проверить гипотезу среди целевой аудитории и получить обратную связь: стоит ли вкладывать ресурсы в разработку полноценного продукта или функции.

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

Можно разложить прямо по словам:

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

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

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

Вот ещё пара примеров MVP от реальных компаний:

[example]

Пример 1 — Uber. Основатели компании были разочарованы высокими расценками в такси Сан-Франциско. В 2010 году они запустили UberCab, простое приложение для iPhone, которое позволяло пассажирам арендовать лимузин для поездки по цене лишь в 1,5 раза выше стоимости городского такси.

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

[/example]

[example]

Пример 2 — Yahoo! Минимальным продуктом здесь была простая страничка со списком ссылок на популярные сайты. Это был вполне достаточный функционал, чтобы удовлетворить пользователей на ранних этапах интернета. А когда сайт приобрёл трафик и популярность, началась его адаптация и развитие.

[/example]

[quote]

Ольга Звегинцева

Data PO в Smartbroker+, ex-Sberbank, соавтор и ведущая интенсива «Product Discovery»

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

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

[/quote]

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

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

MVP Low-fidelity. Такой MVP используют, чтобы с минимальными затратами проверить спрос и собрать первые впечатления с целевой аудитории. Ещё — чтобы найти эту целевую аудиторию. 

MVP Low-fidelity могут быть такими:

1. Видеообъяснение продукта. Это простое видео, в котором вы объясняете, как бы работал ваш продукт, какие у него будут основные функции и почему он обладает ценностью для клиента. 

[example]

Реальный пример — Dropbox. Его основатели, Дрю Хьюстон и Араш Фирдоуси, не хотели сразу разрабатывать сложное ПО. Сначала нужно было проверить, насколько люди заинтересованы в облачном сервисе. Они создали MVP — пятиминутное видео, где Дрю показал, как управляет одними и теми же файлами с разных устройств. ‍‍

За одну ночь число подписчиков в листе ожидания Dropbox выросло с 5000 до 75 000. И только тогда, убедившись в востребованности, основатели начали разрабатывать продукт.
‍

[/example]

2. Лендинг, или посадочная страница. Это веб-страница, на которой вы объясняете суть продукта. Лендинг даёт информацию, сколько пользователей показали, что заинтересованы — например, зарегистрировались в листе ожидания или нажали на кнопку «Хочу такой сервис».

3. Презентация, где вы описываете продукт для потенциальных клиентов.

В совокупности с этими вариантами запускают рекламные кампании — с помощью Facebook, ВК, Google AdWords или иных площадок. Это помогает узнать о представителях потенциальной аудитории — сколько им лет, где они живут и так далее, а также проверить востребованность самой концепции продукта.

MVP High-fidelity. Такой MVP нужен, чтобы продакт-менеджер смог понять, сколько клиент готов заплатить. А ещё чтобы найти первых покупателей и получить обратную связь от реальных юзеров продукта.

MVP High-fidelity могут быть такими:

1. MVP-имитация. При таком виде нет готового продукта и может не быть никакой функциональности совсем. Есть только имитация того, как продукт должен работать. Так можно проверить, нужен ли был бы этот продукт, если бы на самом деле существовал. 

[example]

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

[/example]

2. Консьерж-MVP. Этот метод применяют для услуг. Например, пользователь хочет спланировать поездку. Он рассказывает менеджеру, куда хочет поехать, сколько времени и денег готов потратить, какие активности предпочитает. Затем менеджер лично разрабатывает маршрут, бронирует отели и организует мероприятия.

[example]

Реальный пример — компания Airbnb. В городе, где жили основатели компании, проходила конференция. Отели были дорогими, и Брайан Чески и Джо Геббиа решили сдавать в аренду надувные матрасы в своей квартире. Они предположили, что участники конференции будут платить 80$ за такую ночёвку.

Три человека действительно согласились и арендовали матрасы. Идея оказалась востребованной, и главное — Брайан и Джо не потеряли бы деньги, даже если бы она провалилась. 

[/example]

3. Разрозненный MVP, или метод Франкенштейна. С помощью этого метода идею можно проверить и реализовать без разработки. Команда собирает готовые инструменты, объединяет в одну систему и преподносит в едином интерфейсе. 

[example]

Реальный пример — сервис совместных покупок Groupon. Когда-то он был простеньким сайтом на WordPress. Чтобы купить товар, пользователи должны были писать на электронную почту сервиса. Когда команда убедилась, что продукт приносит деньги, то разработала социальные функции, добавила имейл-рассылку, автоматизацию и мобильное приложение.

[/example]

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

5. «Волшебник страны Оз» (Wizard Of Oz MVP), или MVP Флинстоуна (Flintstone MVP). Похож на консьерж-MVP, но есть отличие: пользователи не знают о том, что за их запросами стоит реальный человек. Они думают, что система полностью автоматизирована. 

[example]

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

[/example]

Какой MVP выбрать, зависит от продукта, ресурсов и желаний вашей команды. Иногда используют оба формата по порядку: с Low-fidelity тестируют, насколько пользователям нужен такой продукт, а потом с High-fidelity — готовы ли они за него платить.

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

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

Идея создать MVP не приходит спонтанно. Всё начинается намного раньше — с исследований. Продуктовая команда периодически проводит исследования: 

• интервью с существующими и потенциальными пользователями;
• интервью с сотрудниками фронт-офиса;
• анализ конкурентов;
• анализ запросов в службу поддержки;
• опросы;
• наблюдение за тем, как люди пользуются продуктом.

Исходя из результатов , команда придумывает идеи, которые могут улучшить показатели бизнеса: «Давайте сделаем вот так, пользователи это оценят». Эти идеи преобразуются в гипотезы: «Если мы сделаем это, то показатель X изменится на Y%». Затем продакт выбирает инструменты, с помощью которых будет проверять гипотезы. 

Как продакту формулировать и тестировать гипотезы

[card]

MVP может быть частью Product Discovery наряду с исследованиями 

1. Иногда MVP заменяет количественное исследование.
2. Вместо некоторых типов MVP мы можем использовать проверку качественными исследованиями.
3. Не стоит воспринимать MVP как что-то отличное и отдельное от исследований. MVP — инструмент, который нужен для определённых случаев: проверки нового продукта или масштабной функции.

[/card]

Допустим, продакт-менеджер решил тестировать идею с помощью MVP. Тогда алгоритм такой: 

1. Формулируем цель продукта — от неё будет зависеть функционал. Определяем, какие гипотезы мы должны проверить в MVP. Формулируем DoD (Definition of Done) — набор критериев, которые должны быть выполнены для того, чтобы задача считалась завершённой.
2. Проводим исследование рынка: определяем целевую аудиторию. Вероятнее всего, ЦА будет более узкой, чем для уже готового продукта, — например, по сегменту. 
3. Строим роадмап запуска MVP: описываем конкретные задачи, сроки, ресурсы, точки контроля. Правильное планирование важно для успешной разработки MVP. 
4. Анализируем конкурентов, чтобы понять, что продукт ничем им не уступает.
5. Определяем user flow и способы, как люди будут использовать продукт.
6. Составляем список функций с градацией по приоритету.
7. Определяем M и V — набор минимального и жизнеспособного функционала, который нам нужен для проверки
8. Выбираем метод MVP среди low-fidelity и high-fidelity.
9. Разрабатываем сам MVP. В некоторых случаях здесь может быть задействована команда разработки.
10. Запускаем MVP и проводим проверку до тех пор, пока наш Definition of Done не будет выполнен. Бывают ситуации, когда DoD невыполним. Тогда мы не можем завершить задачу и, вероятнее всего, закрываем продукт.

Как происходит тестирование MVP

Тестирование MVP — это важный этап, на котором команда проверяет ключевые гипотезы и принимает решения, как развивать продукт. 

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

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

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

1. Гипотезы проверены и подтверждены. Нужно делать первую версию продукта.

2. Гипотезы проверены и частично подтверждены. Нужно понять — готовы ли вы запускать продукт с проверенными гипотезами, достаточно ли этого для выполнения ваших целей. Если нет — нужно вернуться на этап качественных исследований и формулирования новых гипотез.

3. Гипотезы проверены и не подтверждены. Продукт не приносит ценность пользователям. Это отличный результат, вы сэкономили деньги и время. Вернитесь к этапу качественных исследований и формулированию новых гипотез.

4. Гипотезы не проверены. Значит, вы допустили ошибку на одном из этапов — на определении гипотез, DoD, определении M и/или V, на выборе формата. Стоит вернуться в начало и сделать ревью всего процесса, внести в него изменения и попробовать ещё раз.

На основе собранной обратной связи и данных тестирования команда вносит необходимые изменения в MVP и тестирует его заново. Это итеративный процесс, который помогает довести MVP до состояния, когда он будет готов к масштабированию.

[quote]

Валерия Розова

Сооснователь WANNABE, автор курсов для продакт-менеджеров, работала СРО в Qlean, BestDoctor, отвечала за Customer Experience в Doc+ и за маркетинг в Gett

MVP нужен только для проверки гипотезы, дальше он не используется. Его последствия всегда нужно устранять — неважно, оказался он успешным он или нет. В моей практике до 30% проблем возникают из-за того, что никто не «выпиливает» последствия экспериментов. Например, продуктовая команда проверяла гипотезу о том, что если компания отменит лимиты на возвраты товаров, то у бизнеса вырастет выручка. Выручка не выросла, а лимиты обратно не ввели. И всё это засоряет код продукта.

[/quote]

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

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

1. Делают MVP без чёткой гипотезы. Например, если у команды есть только сырые идеи. Она не знает, что именно хочет проверить: спрос на продукт, функционал продукта, сколько люди готовы платить или ещё что-то.
2. Думают, что MVP — это первая версия продукта. В результате в разработку вкладывают много ресурсов, но потом MVP не оправдывает себя. Например, команда разрабатывает красивое функциональное приложение — пока простое, но с планами добавлять новые функции. Делать это с нуля — долго и дорого. Есть риск, что команда потратит много месяцев, а людям в принципе не будет нужен такой продукт.
3. Упускают ценность, или V — viability. Например, полноценный продукт должен попасть в премиум-аудиторию, а для MVP команда выбирает конфигурацию для сегмента эконом.
4. Не выделяют главную ценность MVP. Из-за этой ошибки большинство MVP оказываются неэффективными. Например, команда создаёт интернет-магазин винтажной мебели. В качестве MVP она делает магазин на Shopify и оплачивает подписку на год вперёд вместо того, чтобы создать простой телеграм-канал с объявлениями. 
5. Несут в MVP то, что можно было протестировать на этапе более простых и дешёвых исследований. Например, пользователи приложения для планирования бюджета хотят, чтобы оно автоматически синхронизировалось с приложениями банков. Это можно было выяснить с помощью глубинных интервью и опроса. А в ситуации с MVP процесс стал более долгим и дорогим.
6. Не формулируют Definition of Done до создания MVP. В итоге неясно, до каких пор продолжать тестировать MVP и в какой момент уже можно смотреть на результаты и делать выводы. Процесс затягивается.
7. Делают неверные выводы или не делают выводов вообще. Например, команда влюблена в продукт и даже при плохих результатах оставляет его работать. 

<<zapis-iventa-s-samatom>>

Что такое MVP: частые вопросы

Отвечает Валерия Розова.

В чём разница между прототипом и MVP?

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

Прототипы часто используют для UX-исследований. Продакт или продуктовый дизайнер показывает интерфейс пользователям и просит выполнить какие-то действия, например забронировать билет на нужную дату. А затем наблюдает, насколько поведение пользователей соответствует тому, что предположила команда. 

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

Когда нужно начинать создавать минимальную версию продукта?

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

1. Сформулируете цель продукта и определите функционал.
2. Определите, какие гипотезы нужно проверить в MVP.
3. Сформулируете Definition of Done.
4. Определите целевую аудиторию для MVP — она может быть уже, чем ЦА продукта.
5. Построите роадмап запуска MVP: опишете конкретные задачи, сроки, ресурсы, точки контроля.
6. Проанализируете конкурентов, чтобы понять, что продукт ничем им не уступает.
7. Определите user flow и способы, как люди будут использовать продукт.
8. Составите список функций с градацией по приоритету.
9. Определите набор минимального и жизнеспособного функционала, который нужен для проверки.

И только потом можно выбрать метод MVP, разработать его и выпустить.

Зачем запускают MVP без монетизации?

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

Как сократить бюджет при разработке MVP?

MVP — важная и дорогая часть Product Discovery, поэтому:

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

Что такое минимально жизнеспособный продукт (MVP): конспект

MVP (minimum viable product, минимально жизнеспособный продукт) — это тестовая версия продукта с минимальным набором функций, причём только тех, которые отражают главную ценность продукта. Как такового продукта ещё не существует, но его функции уже можно показать пользователям.

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

MVP может быть частью Product Discovery наряду с исследованиями:

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

Алгоритм создания MVP:

1. Формулируем цель продукта — от неё будет зависеть функционал. Определяем, какие гипотезы мы должны проверить в MVP. Формулируем DoD (Definition of Done) — набор критериев, которые должны быть выполнены для того, чтобы задача считалась завершённой.
2. Проводим исследование рынка: определяем целевую аудиторию. Вероятнее всего, ЦА будет уже, чем для уже готового продукта, — например, по сегменту. 
3. Строим роадмап запуска MVP: описываем конкретные задачи, сроки, ресурсы, точки контроля. Правильное планирование важно для успешной разработки MVP. 
4. Анализируем конкурентов, чтобы понять, что продукт ничем им не уступает.
5. Определяем user flow и способы, как люди будут использовать продукт.
6. Составляем список функций с градацией по приоритету.
7. Определяем M и V — набор минимального и жизнеспособного функционала, который нам нужен для проверки
8. Выбираем метод MVP среди low-fidelity и high-fidelity.
9. Разрабатываем сам MVP. В некоторых случаях здесь может быть задействована команда разработки.
10. Запускаем MVP и проводим проверку до тех пор, пока наш Definition of Done не будет выполнен. 

Основные ошибки при создании MVP:

• Делать MVP без чёткой гипотезы.
• Думать, что MVP — это первая версия продукта.
• Упускать ценность, или V — viability.
• Не выделять главную ценность MVP. 
• Нести в MVP то, что можно было протестировать на этапе более простых и дешёвых исследований.
• Не формулировать Definition of Done до создания MVP. 
• Делать неверные выводы или не делать выводов вообще.

‍