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

Одна и та же история снова и снова.

 

Сначала команда придумывает идею.

 

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

 

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

 

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

Представление о работе MVP

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

 

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

 

Рассмотрев «жизненный» цикл более чем 100 неудавшихся стартапов, в организации CB Insights выявили, что главная причина провала стартапов (в 42 % случаев) – их продукция не нужна на рынке. Около половины таких стартапов тратят месяцы, а то и годы, чтобы осознать свою главную ошибку: кто-то уже разрабатывал то же, что и они.

 

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

 

Реальная работа над MVP

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

 

В мире «проб и ошибок» тот, кто сможет найти свои ошибки быстрее других, побеждает. Некоторые люди называют этот принцип «Fail Fast». В компании TripAdvasor мы называем его по-другому – «Скорость решает». Эрик Райс (Eric Ries) придумал название «Бережливый стартап». А Кент Бэк (Kent Beck) и другие программисты называют это «Гибкой методологией разработки». Не важно, как вы называете этот принцип, смысл в том, чтобы понять, где вы ошиблись, с помощью отзывов от пользователей. И понять максимально быстро.

 

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

 

  • Какая моя самая опасная ошибка?
  • Что я могу сделать, чтобы проверить эту ошибку?

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

 

Давайте рассмотрим пример.

 

Вы разрабатываете продукт, который позволит владельцам ресторанов создавать мобильное приложение для своих заведений в несколько кликов. В нем будет простой интерфейс «Drag and drop», множество готовых шаблонов, календарь событий, новостная рассылка, регистрация, фотогалерея, чат, интеграция с сайтами рецензий, социальными сетями и Google Maps. А самое главное, оно позволит посетителю забронировать столик, делать заказы, а также поддерживать купоны, с которых небольшая часть прибыли будет идти вам. Это будет превосходный продукт!

 

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

 

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

 

Почему? Рассмотрим, где вы можете ошибиться:

 

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

 

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

 

По словам Питера Дракера (Peter Drucker), «нет ничего более бесполезного, чем делать то, что вообще не нужно делать».

 

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

 

  • Какая моя самая опасная ошибка?
  • Что я могу сделать, чтобы проверить эту ошибку?

 

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

 

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

 

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

 

Но это еще не все. Теперь вы должны повторить процесс создания вашего нового MVP:

 

  • Какая моя самая опасная ошибка?

 

Тут главная ошибка может заключаться в том, что владельцы ресторанов не захотят платить за такой сайт. Как же это проверить? Можно попробовать вручную создать несколько веб-сайтов и показать их владельцам, изъявившим интерес к этому вопросу. И посмотреть, как они отреагируют. Нравятся ли они им? Удивлены ли они, что сайт уже готов? Сколько они готовы заплатить за то, чтобы и у них был подобный сайт?

 

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

 

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

 

Но теперь вам снова нужно повторить процесс создания MVP:

 

  • Какая моя самая опасная ошибка?

 

Рассмотрим вариант, когда это ваша маркетинговая стратегия. Вы не можете лично обратиться к каждому владельцу ресторана в мире. Что же вам делать? Вашим MVP тогда будет сайт, объясняющий, для чего ваш проект. На нем будут примеры сайтов, сделанных вами ранее, а также возможность для посетителей оставить свой электронный адрес, чтобы они могли узнать больше, если, конечно, они заинтересовались вашим проектом. Вы также можете потратить несколько сотен долларов на рекламу на сайтах Google, Facebook, Twitter, Linkedln.

 

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

 

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

 

  • Какая моя самая опасная ошибка?
  • Что я могу сделать, чтобы проверить эту ошибку?

 

Джим Брикмен (Jim Brikman) – создатель стартапа Hello и основатель компании Atomic Squirrel, компании, специализирующейся на оказании помощи новым стартапам. До этого он больше десяти лет работал в таких компаниях, как Linkedln, TripAdvisor, Cisco Systems, Thomson Financial. Он имеет степени бакалавра и магистра компьютерных наук Корнелльского университета.

 

Перевод: Вячеслав Гладков

 

Оригинал фото: themacro, twitter