Kotik
Kotik

Как создать MVP?

42% стартапов проваливаются потому, что их продукт оказался не нужен рынку.

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

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

Когда вы делаете продукт, у вас изначально много предположений. Вы думаете что вы знаете что хотят пользователи, что они ищут, каким должен быть дизайн, какую маркетинговую стратегию использовать, какая архитектура будет наиболее эффективной, как монетизировать продукт. Неважно насколько вы хороши, всё равно какие-то из ваших гипотез окажутся ошибочными. Только есть одна проблема – вы не знаете какие именно.

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

Например, вы решили сделать продукт, который позволит рестораторам создавать мобильные приложения для их заведений в несколько кликов. У приложения будет простой интерфейс – drag and drop, готовые шаблоны, календарь событий, новостная лента, чек-ины, фотогалерея, чат в реальном времени, интеграция с сайтами-обозревателями, социальными сетями и Google maps.

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

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

Давайте опробуем MVP процесс и прикинем, как можно было бы избежать ошибок. Мы будем делать продукт постепенно, задавая себе два одних и тех же вопроса на каждой стадии:

  • Какая гипотеза в проекте самая сомнительная?
  • Как быстрее всего её проверить?

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

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

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

Одной из идей для следующего MVP может быть создание статических страниц для нескольких заинтересованных рестораторов, чтобы посмотреть, как они реагируют на него. Им нравится? Они впечатлены, тем что сайт делается в пару кликов? Сколько они готовы заплатить, чтобы такой же ресурс был у них уже вчера? Возможно, когда придёт время платить за сайт, вы поймёте, что рестораторы не готовы это делать. Хорошо то, что вы поняли это за несколько дней, а не несколько месяцев разработки.

Или вы поймёте, что они хотят платить. Вы возьмёте плату за несколько месяцев вперёд, запустите их сайты и попросите в случае необходимости обновлений писать прямо на e-mail (то есть все изменения на сайте будете делать вручную на этом этапе)

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

Чем раньше вы обнаружите ошибки, тем меньше времени вы потратите на бесполезные, никому не нужные вещи.

Для того, чтобы определить гипотезы для MVP можно использовать Lean Canvas. 

Lean Canvas — это Business Model Canvas, адаптированный для стартапа, который находится на раннем этапе развития. Это первый кейс документации бизнес-модели будущего стартапа, который потом будет постоянно изменяться. Он полезен для основателей бизнеса, потенциальных инвесторов и партнеров.

Говорят, что если вы сумели качественно заполнить шаблон Lean Canvas для своей идеи за 5-10 минут, тогда вы разбирается в сфере и теме стартапа.

Пример как заполнять Lean Canvas на примитивном примере лин канваса для Санта Клауса, чтобы было понятно на понятных для всех вещах. Проверять гипотезы, которые нам помог прописать шаблон Lean Canvas, можно с помощью HADI циклов.

HADI состоит из: формулирования гипотезы (Hypothesis), ее проверки (Action), получения измеряемого результата (Data) и выводов (Insights), на основании которых мы формулируем дальнейшие гипотезы. 

Рекомендуем посмотреть видео-лекцию Майкл Сибель (основателя Twitch) на тему “Как правильно спланировать создание MVP”

chevron-down