{"id":14291,"url":"\/distributions\/14291\/click?bit=1&hash=257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","hash":"257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","title":"\u0420\u0435\u043a\u043b\u0430\u043c\u0430 \u043d\u0430 Ozon \u0434\u043b\u044f \u0442\u0435\u0445, \u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0442\u0430\u043c \u043d\u0435 \u043f\u0440\u043e\u0434\u0430\u0451\u0442","buttonText":"","imageUuid":""}

Зачем нужен MVP?

Бывает так, что нам в голову приходит гениальная идея, и мы тут же начинаем рисовать у себя в голове красивые картинки, как мы станем новым Uber, FB или Airbnb. Мы представляем в голове сайт или приложение с множеством классных функций и креативным дизайном. Потом мы беремся за его создание и реализацию всех наших фантазий. Целыми днями продумываем дизайн, шрифты, подбираем красивый фон и т.д...

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

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

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

Итак, что же такое MVP на самом деле?

MVP (расшифровка) - это то что можно потрогать, чем можно воспользоваться, и главное, чем мы можем удовлетворить потребность клиента. Иногда, это может быть обычный одностраничный лэндинг с одной лишь кнопкой «купить/заказать/оформить...». Главное, чтобы при нажатии этой кнопки, клиент получал то, что по сути закрывает его потребность.

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

И вот тут возникает самый главный вопрос, как же нам показать эту ценность?

Если мы создаем продукт исходя из гипотезы, что это точно будет востребовано на рынке, потому что мы так видим - никак! Этим мы только укрепляем свои фантазии.

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

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

В этом нам поможет CustDev, но это тема для отдельной статьи. Рекомендую к прочтению книги:

Стив Бланк, Боб Дорф — «Стартап: Настольная книга основателя»

Эрик Рис - Бизнес с нуля (Lean Startup)

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

MVP помогает нам, с минимальным вложением средств, протестировать гипотезы, а правильно ли мы определили потребность и ценность?

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

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

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

Foursquare

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

Uber

Единственной функцией было, соединять клиента с водителем.

Airbnb

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

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

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

0
1 комментарий
OTTELIN с любовью к твоей душе

Благодарю за информацию, обязательно прочитаю книги

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда