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

«Вы знаете старую историю о самолете, летящем из Калифорнии на Гавайи, который в 99% случаев отклоняется от курса, но постоянно корректируется? То же самое и с успешными стартапами, за исключением того, что они могут начать свой путь на Аляску ». — Эван Уильямс

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

Так что не так с этой картинкой?

Почему для такого количества стартапов все идет не так?

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

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

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

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

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

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

В мире проб и ошибок побеждает тот, кто быстрее всех находит ошибки. Некоторые люди называют эту философию «быстро терпеть неудачу». В TripAdvisor назвали это «Speed Wins». Эрик Рис назвал это Lean . Кент Бек и другие программисты назвали это Agile . Как бы вы это ни называли, цель состоит в том, чтобы как можно быстрее выяснить, какие из ваших предположений неверны, путем получения отзывов о вашем продукте от реальных пользователей.

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

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

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

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

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

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

Почему? Что ж, подумайте, сколько предположений вы делаете, которые могут оказаться катастрофически ошибочными:

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

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

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

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

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

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

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

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

• Какое ваше предположение является самым рискованным?

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

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

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

А пока вам нужно повторить процесс MVP еще раз.

• Какое ваше предположение является самым рискованным?

Возможно, на этом этапе ваша маркетинговая стратегия работает. Вы не можете лично посетить каждый ресторан мира. Какой самый маленький эксперимент вы можете провести, чтобы проверить это предположение? Ваш MVP может быть целевой страницей, которая описывает, что будет делать ваш продукт, демонстрирует веб-сайты ресторанов, которые вы создали вручную, и позволяет посетителям указывать свой адрес электронной почты, если они хотят услышать больше при запуске. Затем вы можете купить рекламу на несколько сотен долларов в Google, Facebook, Twitter или LinkedIn, чтобы привлечь трафик на свою целевую страницу и посмотреть, что из этого получится.

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

Вкратце, это и есть процесс MVP. Если вы разрабатываете дизайн продукта, маркетинговый план или пишете код, всегда спрашивайте:

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

- Джим Брикман, перевод с английского "A Minimum Viable Product Is Not a Product, It's a Process".

Если статья показалась Вам полезной, буду рад видеть в своих подписчиках в телеграм-группе.