что такое минимально жизнеспособный продукт
Минимально жизнеспособный продукт – это не продукт, а процесс
Одна и та же история повторяется снова и снова. Сначала команду людей озаряет идея.
Затем они создают минимально жизнеспособный продукт в качестве доказательства концепта, тратя много времени в спорах о том, какими особенностями стоит его наделить, а какими – нет. И в конце концов, если минимально жизнеспособный продукт оказывается удачным, то они планируют создания полноценного развитого стабильного продукта.
Но что же здесь не так? Почему для многих стартапов это оборачивается проблемами?
Проблема в том, что в этих командах не понимают суть минимально жизнеспособного продукта. Это не просто продукт с урезанным функционалом или возможность раньше выбросить продукт на рынок. На самом деле минимально жизнеспособный продукт вообще не должен быть продуктом. И это не тот продукт, который вы создаете один лишь раз, а далее считаете, что на этом работа закончена.
«Знаете старую поговорку о том, что самолеты из Калифорнии на Гавайи 99% времени уходят с курса, но его постоянно корректируют? То же самое и с успешными стартапами — за исключением того, что их новый маршрут может вести даже на Аляску», — Эван Уильямс (Evan Williams)
Как по мнению основателей будет работать минимально жизнеспособный продукт.
Минимально жизнеспособный продукт – это процесс, который вы повторяете снова и снова: найдите наиболее рисковое для вас предположение, протестируйте его с наименьшими возможными затратами и используйте результаты эксперимента для внесения поправок.
Когда вы создаете продукт, вы делаете множество допущений. Вы предполагаете, что знаете, чего хотят пользователи, как должен работать дизайн, какую использовать маркетинговую стратегию, какая архитектура будет наиболее эффективной, какая стратегия монетизации будет наиболее рациональной в долгосрочной перспективе, каким законам правилам вы должны следовать. Не важно, насколько вы хороши в своем бизнесе – некоторые ваши предположения будут неверны. Проблема в том, что вы не знаете, какие именно (см. примечание 1 в конце статьи).
Анализируя причины неудачи более 100 стартапов, CB Insights обнаружил, что основной причиной гибели стартапов является то, что их продукт «не соответствовал потребностям рынка». Около половины этих стартапов проводили месяцы, а то и годы, развивая продукт, до того, как они поняли, что их самое основное предположение было неверным: то, что этот проект кому-то вообще интересен.
Есть только одна возможность это проверить, лишь один способ протестировать ваши предположения – предложить ваш продукт реальным пользователям так быстро, как это только возможно. И когда вы это сделаете, то зачастую оказывается, что нужно возвращаться к наброскам. На самом деле вам придется возвращаться к ним не раз, а снова и снова.
Как на самом деле работает минимально жизнеспособный продукт.
Это не уникальное развитие продукта. Когда вы пишите книгу или статью, то вам приходится делать множество набросков и проводить много времени, корректируя написанный текст. И когда вы пишите код, вам часто нужно реорганизовать или даже переписать код (см. примечание 2 в конце статьи). Каждой творческой деятельности человека сопутствует множество попыток и ошибок.
В мире попыток и ошибок побеждает тот, кто смог быстрее выявить свои ошибки. Некоторые люди называют эту философию «терпите неудачи быстро». В TripAdvisor мы называем ее «скорость побеждает». Кент Бек (Kent Beck) и другие программисты называют это Agile. Как бы вы это ни называли, суть остается та же: как можно быстрее понять, какие из ваших предположений неверны благодаря фидбеку реальных пользователей о вашем продукте.
Независимо от того, создаете ли вы продукт, пишете код или разрабатываете маркетинговый план, вам нужно всегда задавать себе два вопроса:
Минимально жизнеспособный продукт как процесс в действии
Давайте рассмотрим один пример.
Вы решили разработать продукт, который позволяет владельцам ресторанов создать мобильное приложение для их ресторанов всего лишь в несколько кликов мыши. У вас есть простой drag-and-drop интерфейс, набор предустановленных шаблонов, календарь событий, новостная рассылка, регистрация, фотогалерея, онлайн-чат, интеграция с сайтами обзоров, соцсетями и Google Maps. И самое важное – вы предлагаете возможность осуществлять резервации, делать заказы обедов на дом и использовать купоны, что и станет источником вашей монетизации. Это должно быть великолепно!
Вы находите несколько друзей, которые с становятся вашими соучредителями, если вы типичная команда стартапов, вы собираете деньги, закрываетесь в четырех стенах на 12 месяцев и пытаетесь внедрить все эти функции. Если вы мыслите более здраво, то вы откажитесь от функций, которые не важны для первого запуска продукта, тогда вы сможете запустить свой «минимально жизнеспособный продукт» через 8 месяцев, а не 12.
И в обоих случаях, скорее всего, вы потерпите поражение.
Почему? Ну, подумайте, сколько ваших предположений могут быть неверными, что позднее обернется катастрофой:
Таким образом, самым первым минимально жизнеспособным продуктом может быть макет такого мобильного приложения – может быть, даже тот, который вы набросали на бумажной салфетке в ресторане (как кстати!) Обойдите владельцев ресторанов в ваших окрестностях и расспросите их, какие проблемы они испытывают с современными IT-технологиями. Может быть у них уже есть мобильные приложения? Если нет, то почему? Хотят ли они мобильное приложение? Насколько они технически подкованные? Понимают ли они преимущества? Покажите им свой макет. Выясните, будет ли это хорошим решением их проблем.
Вы можете узнать, что владельцы ресторанов не проявляют достаточно интереса для того, чтобы ваш бизнес стал жизнеспособным. Это печально, но хорошей новостью является то, что вы потратили всего лишь несколько часов на понимание этого, а не несколько месяцев разработки продукта. С другой стороны, вы можете обнаружить, что владельцам ресторанов интересны не мобильные приложения, но веб-сайты, которые было бы легко создавать. Это прогресс!
Но это еще не конец. Сейчас вы обязаны снова повторить процесс для создания вашего следующего минимально жизнеспособного продукта:
Какое из ваших предположений связано с наибольшим риском?
На данном этапе, это скорее всего то, что владельцы ресторанов захотят платить за такой веб-сайт. Какой наименьший эксперимент для тестирования этого предположения? Одной из идей для следующего минимально жизнеспособного продукта может быть создание статических интернет-страниц для нескольких владельцев ресторанов, которые проявили интерес, и посмотреть за их реакцией (см. примечание 3 в конце статьи). Нравится ли им эти сайт? Впечатлило ли их, что вебсайт уже готов? Сколько бы они заплатили за такой сайт, который можно было бы запустить уже сегодня?
Возможно, вы обнаружите, что владельцы ресторанов не заинтересованы настолько, чтобы платить деньги. Ну что ж, хорошо, что вы поняли это только после нескольких дней работы, а не нескольких месяцев разработки продукта.
Или возможно, вы обнаружите, что они готовы заплатить. Тогда вы принимаете платеж за несколько месяцев услуг наличными или чеком (тогда вы не потеряете много времени на создание системы выставления счетов), запускаете их сайты и просите их сообщать по электронной почте, если им необходимо обновление какой-либо информации на сайте. Да, это связано с множеством телодвижений с вашей стороны. Нет, это не увеличит количество ваших клиентов. Но когда вы являетесь крошечным стартапом, не бойтесь делать вещи, которые не масштабируются. Масштабирование – это та головная боль, которая присуща тем, кто создал что-либо стоящее масштабирования.
Но тем временем вам стоит повторить процесс для создания минимально жизнеспособного продукта еще раз:
Какое из ваших предположений связано с наибольшим риском?
Вероятно, на данном этапе ваша маркетинговая стратегия работает. Вы не можете лично обойти все рестораны мира. Какой наименьший эксперимент для тестирования этого предположения? Вашим минимально жизнеспособным продуктом может быть посадочная страница, которая рассказывает о вашем продукте, и о том, чем он может быть полезен, на ней стоит привести примеры сайтов для ресторанов, которые вы создали ранее, и дать возможность посетителям оставлять адрес своей электронной почты, если они хотят узнать больше подробностей о запуске веб-сайта. Затем вы можете потратить несколько сотен баксов на рекламу в Google, Facebook, Twitter или LinkedIn, чтобы привлечь трафик на вашу посадочную страницу и посмотреть, что будет дальше (см. примечание 4 в конце статьи).
Если потенциальные клиенты не готовы даже дать вам адрес своей электронной почты, то скорее всего они не готовы платить за ваши услуги. Гораздо проще понять это, разместив текст и несколько фотографий на посадочной странице, нежели переписывать тысячи строк кода в целом продукте! Чем раньше вы находите ошибки, тем меньше времени тратите на создание ненужных вещей.
Это в двух словах и есть процесс создания минимально жизнеспособного продукта. Вне зависимости от того, занимаетесь ли вы разработкой продукта, маркетинговым планом или написанием кода, всегда задавайтесь вопросами:
Что такое MVP и зачем его делать
Продолжаем серию постов по быстрому погружению в продакт-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains, а здесь — вторая лекция в формате для чтения. Педагог — Евгений Паршин, CPO «Альфа-Банка»
Minimum viable product (MVP) — это минимально жизнеспособный продукт. Есть два определения MVP:
Сначала можно разработать MVP согласно первому определению, а после подтверждения спроса доработать функционал и выпустить на рынок MVP №2.
Как выделить главное в MVP?
Когда появляется идея продукта, то хочется сразу сделать огромную платформу или огромное мобильное приложение, но на первых порах не нужно «впихивать невпихуемое», нужно мыслить категориями «проблема → решение».
Чтобы выделить главное в MVP, пообщайтесь с пользователем, поймите его проблему и придумайте её решение. Как правило, пользовательская проблема одна и решить ее можно одной фичей.
Кейс 1
Клиент обратился в нашей агентство, чтобы запустить мобильное приложение по инвестициям для начинающих. У него было огромное техническое задание и длинный список функций, которые нужно реализовать.Приложение обещало стать «огромным монстром». При этом на запуск было 5 месяцев и 2,5 млн рублей.
Мы сказали, что это здорово, и предложили применить продуктовый подход. Провели исследование, пообщались с пользователями, выделили пользовательские сегменты и нашли у этих сегментов проблемы, которые нужно решить с помощью мобильного приложения.
Клиент пришёл к нам со списком из 15 проблем. Часть из них были выдуманными, часть основаны на личном опыте. Проведя исследование, выяснили, что у пользователей всего три проблемы. Вместо того чтобы сразу запускать мобильное приложение, начали тестировать проблемы по одной.
Проблему информирования по событиям компаний, в которые вложены деньги, решили через чат-бота в телеграме. Пользователь выбирает компании и раз в день получает новости (собирали вручную). Гипотеза была проверена и подтверждена за пять дней: людям оказалась нужна эта функция.
Потом сделали посадочную страницу, на которой рассказали о приложении и датах запуска, начали собирать почты пользователей. Общались с ними, чтобы понять, что такого они увидели в приложении, что могло решить их проблему.
В итоге оказалось, что из функций, которые придумал клиент, больше половины никому не нужно. Мы сэкономили кучу денег, времени, усилий. Запустили приложение с нужными функциями. Сейчас продукт состоит из обучения, информирования по событиям инвестиций, инвестирования.
Кейс 2
Клиент хотел запустить персональное обучение творческим профессиям (например, графическому дизайну). По плану продукт должен был состоять из консультаций наставников, составления персонального плана обучения и скрининга навыков. На запуск этой идеи было 2,5 месяца и 600 тыс. рублей.
Вместо того чтобы сразу запускать продукт, решили проверить идею. Провели интервью с пользователями и выяснили, что им не нужно персональное обучение, они смотрят уроки на ютубе или проходят большие курсы.
Когда общались с пользователями, обнаружили другую потребность. Например, человек уже работает графическим дизайнером, выполняет коммерческие заказы и хочет, чтобы перед отправкой работы заказчику, кто-то её проверил (ему нужно убедиться, что он сделал классную штуку). Сейчас мы запускаем сервис по ревью работ для графических дизайнеров.
Создали посадочную страницу с формой заявки, где рассказали о сервисе,. Пока что работы проверяет один преподаватель. Привлекаем трафик и запускаем проект с минимальным бюджетом.
Пример Zappos
Zappos — это интернет-магазин обуви, который появился в 1999 году. У его основателя была гипотеза о том, что у людей есть потребность в покупке обуви через интернет. Он мог пойти по классическому сценарию: закупить обувь, арендовать склад, взять на работу продавцов, менеджеров и курьеров. Это было бы долго и дорого. Вместо этого основатель Zappos пошёл в ближайший магазин обуви, сфотографировал все товары, разместил их на сайте, и начал получать заказы. Когда приходил заказ, он бежал в магазин и выкупал нужную пару, потом шел в службу доставки, отправлял её и получал деньги. Таким образом, основателю Zappos удалось протестировать гипотезу быстро и без вложений. В итоге Zappos сильно разросся, и в 2009 году основатель продал свою долю «Амазону» за 1 млрд долларов.
Пример Dropbox
Dropbox — облачное хранилище, запущенное в 2007 году. В то время было не очевидно, что такой продукт кому-то нужен. Чтобы проверить идею, основатель Dropbox смонтировал видео, в котором рассказал о своём продукте, и разместил его на The Hacker News. Посетителям сайта настолько понравилась его идея, что они начали писать ему в личку, оставлять контакты, чтобы получить информацию о старте. Так основатель Dropbox проверил рисковую гипотезу. Плюс у него появилась лояльная база пользователей, с которыми он мог общаться, чтобы узнавать, какая именно функциональность им нужна. На данный момент капитализация DropBox составляет 8 млрд долларов.
Нецифровой пример
Однажды мне пришла идея запустить магазин, в котором будут продаваться окрашенные новые бамперы. По задумке это поможет клиентам сэкономить деньги и время — после аварии им не придётся ехать в магазин, выбирать бампер, ехать в автосервис и ждать, пока его покрасят и поменяют. Им нужно только приехать ко мне, купить окрашенную запчасть и поехать в автосервис — вопрос 40 минут, а не целого дня. Плюс экономия на покупке бампера, потому что мне их красят оптом, что дешевле. Нужно было выбрать между классическим способом проверки гипотезы и продуктовым.
Классический подход проверки
Гипотеза достаточно рисковая. На тот момент прямых конкурентов не было.
MVP-подход
Я нашёл графического дизайнера, фото неокрашенного бампера и все возможные цвета авто. Отдал дизайнеру, чтобы он размножил и окрасил фото. Сделал посадочную страницу с информацией о том, что продаю бамперы на Hyundai Solaris, разместил фотографии окрашенных бамперов, настроил форму заявки и пригнал трафик из контекстной рекламы.
Люди начали оставлять заявки. Я звонил им и говорил, что мы тестируем идею, предлагал два варианта развития событий: подождать месяц и купить бампер со скидкой, либо не обижаться и купить запчасть в другом месте. Негатив в ответ не получил ни разу. На проверку гипотезы ушло 15 тыс. рублей.
Потом я нашёл партнёра, мы вложили в запуск бизнеса по 100 тыс. рублей и запустили его. В итоге эта история взлетела, мы начали расширяться.
Зачем делать MVP?
Уменьшить риск неопределённости. Когда человек решает запустить продукт, перед ним открывается огромный «туман войны»: он не знает рынок, пользователей, каналы их привлечения, сегменты. MVP — это один из способов понять и снизить неопределённость.
Сэкономить деньги и время.
Снизить риск выдать желаемое за действительное.
Понять метрики (LTV, CAC, воронку и т.д.) Большинство продуктов, которые сейчас запускаются, проваливаются потому, что у них не сходится экономика продукта. А это следствие того, что не сходится экономика в каналах.
Пример из жизни преподавателя
С «выдавать желаемое за действительное» сталкиваются абсолютно все. Кажется, что нужно бежать и привлекать инвестиции, пока идею не украли. Но на деле идея может оказаться пустышкой. У меня такая была.
Я решил делать сервис «Автозапчасти без переплаты». Покупая годовой абонемент на автозапчасти, клиент получал возможность покупать запчасти без наценки — экономия 30-40%. То есть стандартные магазины автозапчастей зарабатывают на наценке, а я зарабатываю, продавая абонемент.
Я бегал с этой идеей 8 месяцев, ходил по инвесторам, рассказывал. На восьмом месяце почти привлёк инвестиции, но в последний момент решил проверить гипотезу. В итоге оказалось, что такой сервис никому не нужен.
Для проверки я сделал посадочную страницу (на это ушло 1,5 недели), выделил пользователей по ценностным предложениям, тестировал гипотезы по сегментам (на это потребовалось ещё 2 недели). В итоге за 3,5 недели я понял, что продукт никому не нужен и я мог не тратить 8 месяцев зря.
Когда пора делать MVP?
Существует три подхода к запуску MVP.
Какие бывают MVP?
Прототип сервиса
BestDoctor — стартап, который решает одну из главных проблем на рынке добровольного медицинского страхования (ДМС). Например, компания хочет оформить сотрудникам ДМС, идёт в страховую, покупает страховку на год на одного человека за 60 тыс. рублей. Некоторые из членов команды могут ни разу не сходить в клинику. В конце года деньги «сгорают» — остаются в страховой. Чтобы решить проблему, BestDoctor предложил владельцам компаний другой сервис — платить за страхование сотрудника по факту посещения им медицинского центра. В результате клиенты BestDoctor экономят порядка 50% бюджета, выделенного на ДМС.
На старте, чтобы проверить гипотезу, основатели BestDoctor сделали макет личного кабинета, в котором показали, как отслеживать посещения сотрудниками клиник и скачивать платёжные поручения. Оформили красивую продающую презентацию: прописали в ней УТП и разместили макеты. Затем начали рассылать её потенциальным клиентам. Многие компании заинтересовались предложением и начали заключать с BestDoctor контракты. Процесс подписания договоров длился долго, за это время основатели BestDoctor провели переговоры с медицинскими центрами. Сказали, что есть пять крупных компаний, которые хотят обслуживать своих сотрудников у них, и предложили подключиться к сервису. Клиники согласились.
Лендинг
Aviasales запускает сервис организации командировок. Они упаковали его в красивую историю о том, что сначала запустили продукт внутри компании, сами им пользовались, и теперь хотят предложить его миру. Была посадочная страница, на которой были размещены макеты личного кабинета нового сервиса и кнопка «создать аккаунт». При ее нажатии можно было увидеть, что сервиса нет — предлагали оставить почту и первым узнать о запуске. Я оставил в конце 2019 года, и оповещение пока не пришло. Так Aviasales протестировал идею и узнал, что она не востребована.
Чат-боты
Допустим, я хочу сделать сервис, который по фотографиям будет подбирать людям одежду. Планирую научить этому искусственный интеллект, разработать мобильное приложение и ещё кучу всего. Звучит красиво, но рискованно.
Чтобы проверить, давайте запустим чат-бот. Пользователь заходит в него, проходит небольшой опрос и загружает свои фотографии. Во время их загрузки мы присылаем пользователю уведомление о том, что искусственный интеллект обрабатывает фото и скоро вернётся с ответом. На самом деле фотография пришла мне, и я начал подбирать образы. Вот и весь искусственный интеллект на данном этапе, а для пользователя это выглядит как магия.
Краудфандинг
Если у человека есть идея продукта, но нет денег на её реализацию, он может зайти на краудфандинговую площадку, разместить информацию о продукте, и проблемах, которые он решает. Начать собирать деньги.
Группы в социальных сетях
InDriver — международный сервис пассажирских перевозок, в котором пассажир назначает стоимость поездки, а водитель либо принимает её и приезжает, либо нет. Сервис появился в небольшом городе Якутии из группы во «Вконтакте» для местных таксистов. Когда человеку нужно было куда-то доехать, он публиковал пост: «Нужно доехать из точки А в точку Б за 300 рублей». Водители писали, могут или не могут взять заказ.
Запомните, в рамках MVP у вас может не быть продукта. Совсем. Запускаете один из видов MVP, тестируете спрос, общаетесь с пользователями, понимаете ценность, которую несёте, и только потом вкладываетесь в разработку. Не раньше.
В следующих статьях мы продолжим выкладывать лекции по быстрому погружению в продакт-менеджмент. Весь курс сразу, бесплатно и в видеоформате уже доступен на GeekBrains.
Продолжаем серию постов по быстрому погружению в продакт-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains, а здесь — вторая лекция в формате для чтения. Педагог — Евгений Паршин, CPO «Альфа-Банка»
Minimum viable product (MVP) — это минимально жизнеспособный продукт. Есть два определения MVP:
Сначала можно разработать MVP согласно первому определению, а после подтверждения спроса доработать функционал и выпустить на рынок MVP №2.
Как выделить главное в MVP?
Когда появляется идея продукта, то хочется сразу сделать огромную платформу или огромное мобильное приложение, но на первых порах не нужно «впихивать невпихуемое», нужно мыслить категориями «проблема → решение».
Чтобы выделить главное в MVP, пообщайтесь с пользователем, поймите его проблему и придумайте её решение. Как правило, пользовательская проблема одна и решить ее можно одной фичей.
Кейс 1
Клиент обратился в нашей агентство, чтобы запустить мобильное приложение по инвестициям для начинающих. У него было огромное техническое задание и длинный список функций, которые нужно реализовать.Приложение обещало стать «огромным монстром». При этом на запуск было 5 месяцев и 2,5 млн рублей.
Мы сказали, что это здорово, и предложили применить продуктовый подход. Провели исследование, пообщались с пользователями, выделили пользовательские сегменты и нашли у этих сегментов проблемы, которые нужно решить с помощью мобильного приложения.
Клиент пришёл к нам со списком из 15 проблем. Часть из них были выдуманными, часть основаны на личном опыте. Проведя исследование, выяснили, что у пользователей всего три проблемы. Вместо того чтобы сразу запускать мобильное приложение, начали тестировать проблемы по одной.
Проблему информирования по событиям компаний, в которые вложены деньги, решили через чат-бота в телеграме. Пользователь выбирает компании и раз в день получает новости (собирали вручную). Гипотеза была проверена и подтверждена за пять дней: людям оказалась нужна эта функция.
Потом сделали посадочную страницу, на которой рассказали о приложении и датах запуска, начали собирать почты пользователей. Общались с ними, чтобы понять, что такого они увидели в приложении, что могло решить их проблему.
В итоге оказалось, что из функций, которые придумал клиент, больше половины никому не нужно. Мы сэкономили кучу денег, времени, усилий. Запустили приложение с нужными функциями. Сейчас продукт состоит из обучения, информирования по событиям инвестиций, инвестирования.
Кейс 2
Клиент хотел запустить персональное обучение творческим профессиям (например, графическому дизайну). По плану продукт должен был состоять из консультаций наставников, составления персонального плана обучения и скрининга навыков. На запуск этой идеи было 2,5 месяца и 600 тыс. рублей.
Вместо того чтобы сразу запускать продукт, решили проверить идею. Провели интервью с пользователями и выяснили, что им не нужно персональное обучение, они смотрят уроки на ютубе или проходят большие курсы.
Когда общались с пользователями, обнаружили другую потребность. Например, человек уже работает графическим дизайнером, выполняет коммерческие заказы и хочет, чтобы перед отправкой работы заказчику, кто-то её проверил (ему нужно убедиться, что он сделал классную штуку). Сейчас мы запускаем сервис по ревью работ для графических дизайнеров.
Создали посадочную страницу с формой заявки, где рассказали о сервисе,. Пока что работы проверяет один преподаватель. Привлекаем трафик и запускаем проект с минимальным бюджетом.
Пример Zappos
Zappos — это интернет-магазин обуви, который появился в 1999 году. У его основателя была гипотеза о том, что у людей есть потребность в покупке обуви через интернет. Он мог пойти по классическому сценарию: закупить обувь, арендовать склад, взять на работу продавцов, менеджеров и курьеров. Это было бы долго и дорого. Вместо этого основатель Zappos пошёл в ближайший магазин обуви, сфотографировал все товары, разместил их на сайте, и начал получать заказы. Когда приходил заказ, он бежал в магазин и выкупал нужную пару, потом шел в службу доставки, отправлял её и получал деньги. Таким образом, основателю Zappos удалось протестировать гипотезу быстро и без вложений. В итоге Zappos сильно разросся, и в 2009 году основатель продал свою долю «Амазону» за 1 млрд долларов.
Пример Dropbox
Dropbox — облачное хранилище, запущенное в 2007 году. В то время было не очевидно, что такой продукт кому-то нужен. Чтобы проверить идею, основатель Dropbox смонтировал видео, в котором рассказал о своём продукте, и разместил его на The Hacker News. Посетителям сайта настолько понравилась его идея, что они начали писать ему в личку, оставлять контакты, чтобы получить информацию о старте. Так основатель Dropbox проверил рисковую гипотезу. Плюс у него появилась лояльная база пользователей, с которыми он мог общаться, чтобы узнавать, какая именно функциональность им нужна. На данный момент капитализация DropBox составляет 8 млрд долларов.
Нецифровой пример
Однажды мне пришла идея запустить магазин, в котором будут продаваться окрашенные новые бамперы. По задумке это поможет клиентам сэкономить деньги и время — после аварии им не придётся ехать в магазин, выбирать бампер, ехать в автосервис и ждать, пока его покрасят и поменяют. Им нужно только приехать ко мне, купить окрашенную запчасть и поехать в автосервис — вопрос 40 минут, а не целого дня. Плюс экономия на покупке бампера, потому что мне их красят оптом, что дешевле. Нужно было выбрать между классическим способом проверки гипотезы и продуктовым.
Классический подход проверки
Гипотеза достаточно рисковая. На тот момент прямых конкурентов не было.
MVP-подход
Я нашёл графического дизайнера, фото неокрашенного бампера и все возможные цвета авто. Отдал дизайнеру, чтобы он размножил и окрасил фото. Сделал посадочную страницу с информацией о том, что продаю бамперы на Hyundai Solaris, разместил фотографии окрашенных бамперов, настроил форму заявки и пригнал трафик из контекстной рекламы.
Люди начали оставлять заявки. Я звонил им и говорил, что мы тестируем идею, предлагал два варианта развития событий: подождать месяц и купить бампер со скидкой, либо не обижаться и купить запчасть в другом месте. Негатив в ответ не получил ни разу. На проверку гипотезы ушло 15 тыс. рублей.
Потом я нашёл партнёра, мы вложили в запуск бизнеса по 100 тыс. рублей и запустили его. В итоге эта история взлетела, мы начали расширяться.
Зачем делать MVP?
Уменьшить риск неопределённости. Когда человек решает запустить продукт, перед ним открывается огромный «туман войны»: он не знает рынок, пользователей, каналы их привлечения, сегменты. MVP — это один из способов понять и снизить неопределённость.
Сэкономить деньги и время.
Снизить риск выдать желаемое за действительное.
Понять метрики (LTV, CAC, воронку и т.д.) Большинство продуктов, которые сейчас запускаются, проваливаются потому, что у них не сходится экономика продукта. А это следствие того, что не сходится экономика в каналах.
Пример из жизни преподавателя
С «выдавать желаемое за действительное» сталкиваются абсолютно все. Кажется, что нужно бежать и привлекать инвестиции, пока идею не украли. Но на деле идея может оказаться пустышкой. У меня такая была.
Я решил делать сервис «Автозапчасти без переплаты». Покупая годовой абонемент на автозапчасти, клиент получал возможность покупать запчасти без наценки — экономия 30-40%. То есть стандартные магазины автозапчастей зарабатывают на наценке, а я зарабатываю, продавая абонемент.
Я бегал с этой идеей 8 месяцев, ходил по инвесторам, рассказывал. На восьмом месяце почти привлёк инвестиции, но в последний момент решил проверить гипотезу. В итоге оказалось, что такой сервис никому не нужен.
Для проверки я сделал посадочную страницу (на это ушло 1,5 недели), выделил пользователей по ценностным предложениям, тестировал гипотезы по сегментам (на это потребовалось ещё 2 недели). В итоге за 3,5 недели я понял, что продукт никому не нужен и я мог не тратить 8 месяцев зря.
Когда пора делать MVP?
Существует три подхода к запуску MVP.
Какие бывают MVP?
Прототип сервиса
BestDoctor — стартап, который решает одну из главных проблем на рынке добровольного медицинского страхования (ДМС). Например, компания хочет оформить сотрудникам ДМС, идёт в страховую, покупает страховку на год на одного человека за 60 тыс. рублей. Некоторые из членов команды могут ни разу не сходить в клинику. В конце года деньги «сгорают» — остаются в страховой. Чтобы решить проблему, BestDoctor предложил владельцам компаний другой сервис — платить за страхование сотрудника по факту посещения им медицинского центра. В результате клиенты BestDoctor экономят порядка 50% бюджета, выделенного на ДМС.
На старте, чтобы проверить гипотезу, основатели BestDoctor сделали макет личного кабинета, в котором показали, как отслеживать посещения сотрудниками клиник и скачивать платёжные поручения. Оформили красивую продающую презентацию: прописали в ней УТП и разместили макеты. Затем начали рассылать её потенциальным клиентам. Многие компании заинтересовались предложением и начали заключать с BestDoctor контракты. Процесс подписания договоров длился долго, за это время основатели BestDoctor провели переговоры с медицинскими центрами. Сказали, что есть пять крупных компаний, которые хотят обслуживать своих сотрудников у них, и предложили подключиться к сервису. Клиники согласились.
Лендинг
Aviasales запускает сервис организации командировок. Они упаковали его в красивую историю о том, что сначала запустили продукт внутри компании, сами им пользовались, и теперь хотят предложить его миру. Была посадочная страница, на которой были размещены макеты личного кабинета нового сервиса и кнопка «создать аккаунт». При ее нажатии можно было увидеть, что сервиса нет — предлагали оставить почту и первым узнать о запуске. Я оставил в конце 2019 года, и оповещение пока не пришло. Так Aviasales протестировал идею и узнал, что она не востребована.
Чат-боты
Допустим, я хочу сделать сервис, который по фотографиям будет подбирать людям одежду. Планирую научить этому искусственный интеллект, разработать мобильное приложение и ещё кучу всего. Звучит красиво, но рискованно.
Чтобы проверить, давайте запустим чат-бот. Пользователь заходит в него, проходит небольшой опрос и загружает свои фотографии. Во время их загрузки мы присылаем пользователю уведомление о том, что искусственный интеллект обрабатывает фото и скоро вернётся с ответом. На самом деле фотография пришла мне, и я начал подбирать образы. Вот и весь искусственный интеллект на данном этапе, а для пользователя это выглядит как магия.
Краудфандинг
Если у человека есть идея продукта, но нет денег на её реализацию, он может зайти на краудфандинговую площадку, разместить информацию о продукте, и проблемах, которые он решает. Начать собирать деньги.
Группы в социальных сетях
InDriver — международный сервис пассажирских перевозок, в котором пассажир назначает стоимость поездки, а водитель либо принимает её и приезжает, либо нет. Сервис появился в небольшом городе Якутии из группы во «Вконтакте» для местных таксистов. Когда человеку нужно было куда-то доехать, он публиковал пост: «Нужно доехать из точки А в точку Б за 300 рублей». Водители писали, могут или не могут взять заказ.
Запомните, в рамках MVP у вас может не быть продукта. Совсем. Запускаете один из видов MVP, тестируете спрос, общаетесь с пользователями, понимаете ценность, которую несёте, и только потом вкладываетесь в разработку. Не раньше.
В следующих статьях мы продолжим выкладывать лекции по быстрому погружению в продакт-менеджмент. Весь курс сразу, бесплатно и в видеоформате уже доступен на GeekBrains.