MVP это не просто продукт с половиной урезанных фич. По факту, MVP не является продуктом вообще. И это, конечно, не то что вы сделали один раз и считаете что работа уже окончена. Скорее всего, вы вообще не понимаете, что это такое.




MVP – это не продукт, а процесс. Думаете, что это не так?



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



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

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

В последнем исследовании сотни стартапов, CB Insights определило, что самая главная причина провала (42% всех случаев) – это отсутствие рыночного спроса. Почти половина этих стартапов потратили месяцы, или даже годы, делая продукт до момента, пока не осознали, что их гипотеза была неправильной – что кто-то вообще заинтересован в их продукте.

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



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



В этом мире, кто быстрее находит ошибки и исправляет их, тот и становится победителем. Некоторые люди называют эту философию «Fail fast» (проваливайся быстро). В TripAdviser мы называем это «Speed wins» (Скорость — это преимущество). Эрик Райз называет эту методику “Lean” (бережливый), Кент Бэк (один из создателей Agile Manifesto) и другие программисты называют это Agile.

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

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

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


Советую почитать — А вы знаете, что такое Growth Hacking? [11 кейсов внутри]

MVP как процесс в действии.



Давайте разберём пример, шаг за шагом. После него вы точно поймёте, что такое MVP.

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

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

Вы найдете несколько друзей, которые станут вашими ко-фаундерами. В идеальной ситуации (которая не произойдёт в 99.9% случаев) “поднимите” немного денег у зажиточного бизнес-ангела, запрётесь в комнате на 12 месяцев и будете пилить все эти фичи.

Если вы более прокачаны, то урежете половину фич, которые вам кажутся не первостепенными. И сможете запустить свой MVP за 8 месяцев, а не за 12.

В обоих случаях вы скорее всего провалитесь.

Почему? Окей, учитывая сколько предположений вы сделали, все может оказаться катастрофически неправильным.

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

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

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

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

По словам Питера Друкера «Нет ничего настолько бессмысленного, как создание бесполезного продукта, никому не нужного продукта».

Советую почитать — Growth Hacking: 36 реальных кейсов – Часть 1

Делаем приложение по MPV-процессу



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


В самом начале, самое смелое предположение: Рестораторам нужно такое мобильное приложение

Поэтому первое MVP должно быть наброском мобильного приложения – может быть даже таким, которое будет сделано на обороте ресторанной салфетки (как в тему, да?).

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

Покажите им мок-ап (набросок), и подумайте будет ли это хорошим решением их проблем.

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

С другой стороны, возможно вы узнаете, что рестораторы заинтересованы не в мобильном приложении, а в простом адаптивном сайте. И это прогресс!

Советую почитать — Стартап Plotguru поднял конверсию лендинга с 9 % до 52 %. А вам слабо?

Но вы еще не закончили. Сейчас вы должны повторить процесс, что бы выстроить следующий MVP.

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

«Захотят ли рестораторы платить за адаптивный сайт?»

И как можно это проверить?

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

Им нравится? Они впечатлены, тем что сайт делается в пару кликов? Сколько они готовы заплатить, чтобы такой же ресурс был у них уже вчера?

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

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

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

Советую почитать — Кейс: Увеличение регистраций на 11.6 % в сервисе Piktochart

Продолжаем дальше наш MVP-процесс.



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

В этот раз, возможно ваша маркетинговая стратегия по привлечению клиентов сработала. Но вы не сможете обойти все рестораны в мире.

Тогда возникает вопрос как проверить эту гипотезу на большем количестве людей с минимальными затратами?

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

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

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

Советую почитать — 6 кейсов увеличения конверсии от компании Fiverr

Чувак, это MVP





Когда вы разрабатываете дизайн продукта, создаёте маркетинговый план или пишите код, всегда спрашивайте себя:

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


Всего два простых вопроса, которые могут сэкономить вам очень много времени и денег. Запишите и повесьте их прямо перед вашим рабочим местом.

Оригинал статьи: A Minimum Viable Product Is Not a Product, It’s a Process

Читайте также наши другие популярные статьи:

1. Как увеличить конверсию — 30 коротких советов для [интернет-маркетологов] (3000+ просмотров)
2. Они помогут найти всех «убийц» конверсии — 10 отчётов в Google Analytics (5000+ просмотров)
3. 100 идей для A/B тестирования. Часть первая (2000+ просмотров)
4. 100 идей для A/B тестирования: Часть вторая (1000+ просмотров)
5. Как найти идею для A/B теста: тепловые карты и опросы (1000+ просмотров)

Комментарии (14)


  1. EndUser
    06.04.2016 10:08

    Хороший подход, созвучный с Теорией ограничения систем.
    Спасибо!


    1. andreibaklinau
      06.04.2016 22:13

      Спасибо за комментарий. К сожалению, я не в курсе теории ограничения систем, поэтому ничего на тот счет сказать не могу)


  1. lexnekr
    06.04.2016 14:41

    Пытался один раз объяснить это коллегам по проекту. В ответ получил железобетонное «нет» и уведомление, что мы оказывается совершили ошибку и неправильно выбрали ЦА. Аргумент, что ЦА мы выбрали «от балды» и по большому счёту для изучения оной и нужен был MVP было отметено.


    1. andreibaklinau
      06.04.2016 22:15

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


      1. lexnekr
        07.04.2016 09:25

        Это был проект для которого собралась независимая команда (т.е. не в рамках работы). Я счёт нерациональным работать дальше с людьми, которые не хотят слушать.


        1. andreibaklinau
          08.04.2016 09:16

          Наверно, это было самое рациональное решение.


  1. enabokov
    06.04.2016 22:15

    Только дочитав до конца, из названия оригинальной статьи понял что скрывается за тремя буквами MVP — A Minimum Viable Product (продукт, обладающий минимальной ценностью). А не Model-View-Presenter и не Most Valuable Person или что-то ещё.


    1. andreibaklinau
      06.04.2016 22:16

      Сорри, забыл добавить пояснение в начале статьи. Обычно стараюсь это делать для новых слов, которые чаще всего незнакомы читателям)
      А как впечатление от статьи в целом? Полезно или нет?


      1. EndUser
        06.04.2016 22:38

        Очень верна смена парадигмы, что MVP не веха, а этап поиска. Я не совсем так думал — ваша позиция яснее и, вроде, вернее.

        Теория ограничения систем имеет всего три пункта:
        0) понять метрику целого бизнес процесса без учёта метрик его частей. оптимизировать надо именно весь процесс, а не этапы.
        1) понять что мешает течению процесса — «бутылочное горлышко» именно в общей метрике, а не проблемы частных этапов
        2) принять меры по устранению узкого места. перейти к пункту 1.

        Это как помню. Точная формулировка, конечно, точнее другая.

        Подробнее и романтичнее написал Элияху Голдрат в виде ряда производственных романов «Цель: ...» — там в художественной форме решаются проблемы типичные менеджмента. В каждом романе по две-четыре проблемы, но досконально на множестве доступных примеров.


        1. andreibaklinau
          08.04.2016 09:15

          О, как раз сегодня на глаза меня попалась эта книга. Наверно. знак прочесть её.

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


      1. enabokov
        07.04.2016 12:09

        Интересная статья. Почитаю что-нибудь ещё на эту тему.


        1. andreibaklinau
          08.04.2016 09:16

          Спасибо!
          Очень советую. Тема MVP(rocess) очень крутая и полезная. И материалов по ней очень много, в принципе. Точно помню, что на LPgenerator была огромная статья об этом — целая книга, можно сказать


  1. tomzarubin
    15.04.2016 00:44

    MVP— это всё же продукт, который уже решает в каком-либо виде проблему/делает лучше пользователя/клиента. Никто и никогда не говорил, что у MVP урезанный функционал.
    Другое дело, что MVP, как и любой продукт совершенно, даже взрослый на взрослом рынке взрослой компании, разрабатывается итерационно. С разной степенью скорости итераций и количеством изменений. И это тоже всем известно.
    Для кого такой громкий заголовок, если вы плаваете в теме, прочитав 5-7 статей?


    1. andreibaklinau
      15.04.2016 00:45

      Громкий заголовок для того, чтобы вы оставили коммент и подсказали, что «MVP, как и любой продукт совершенно, даже взрослый на взрослом рынке взрослой компании, разрабатывается итерационно»

      Спасибо, активный читатель)

      А я, пожалуй, отправлюсь и дальше плавать в этой теме)