что такое mvp в разработке
Минимально жизнеспособный продукт: типы, методы, этапы построения
30 минут на чтение
Оглавление
Что такое MVP?
MVP (от англ. Minimum Viable Product, «минимально жизнеспособный продукт») — это самая ранняя версия продукта, которая обладает только необходимыми функциями, достаточными для того, чтобы донести основополагающие ценности до аудитории и проверить их на первых пользователях.
Ключевой момент идеи MVP заключается в том, что компания производит реальный товар, который затем поставляет на рынок. Это может быть одностраничный сайт или, на вид, полностью автоматизированная услуга, которая в действительности выполняется вручную. Разработчики наблюдают за поведением людей, впервые использующих услугу. На основе информации, полученной в ходе эксперимента, команда продолжает, корректирует или отменяет работу над продуктом.
Когда предприниматель запускает стартап, он может только гадать, оценят ли потребители его замысел, будут ли они использовать продукцию по назначению. Он предполагает, что у клиентов есть потребность, а продукт, над которым работает команда, удовлетворяет её. Чтобы узнать наверняка, необходимо представить клиентам MVP и собрать максимальный объем подтвержденной информации об их впечатлении от использования продукта.
Однако получение обратной связи от ЦА — не единственная польза от реализации MVP в бизнес-стратегии. Тестирование бета-версии на клиентах обеспечивает прямые и косвенные финансовые преимущества:
Почему MVP важен для успешного развития бизнеса?
Стартапы предлагает товар или услугу, чтобы удовлетворить определённые потребности ЦА. Чем выше значимость проблемы для потребителя, тем ценнее предложенное решение. Реализация MVP позволяет на начальных этапах развития бизнеса установить, насколько продукт соответствует ожиданиям и нуждам клиента. Соответственно, руководство компании и инвесторы получают данные, необходимые для принятия решения о дальнейшей судьбе стартапа.
По статистике, провальными оказываются около 70% стартапов. Отчасти неудачи связаны с выпуском бесполезных или несвоевременных товаров. Вспомнить, например, легендарную историю появления пакетиков-стикеров для сахара. Их изобретатель хотел упростить пользователям жизнь. Он предполагал, что посетители кафе смогут разламывать пакетики посредине и высыпать содержимое, не проронив ни крошки. Однако клиенты кафе продолжали по привычке отрывать уголок пакетика. Гениальная, на первый взгляд, идея оказалась совершенно бесполезной на практике. И хоть позднее стикеры получили популярность благодаря удобству транспортировки, они не принесли прибыли своему изобретателю.
Создавая MVP, команда может понять интерес клиентов к продукту, не затрачивая время и силы на доведение идеи до совершенства. Чем раньше создатели получат фидбэк от покупателей, тем меньше усилий и затрат уйдет на «мертворожденную» идею. MVP дает более надежный результат, чем опросы целевой аудитории и позволяет пронаблюдать реальное взаимодействие пользователя и программы. А значит, уже в процессе создания разработчики будут понимать потенциальную окупаемость.
Эта концепция основана на философии бережливого стартапа и подразумевает итеративный процесс построения цикла измерения—обучения до полного удовлетворения потребностей рынка. Начиная с минимально жизнеспособного продукта, команда сосредоточена на основных функциях и ценности предложенной идеи. Она чётко осознаёт наиболее важные задачи и реализует их в приоритетном порядке. Например, в случае с разработкой программного обеспечения программисты переходят к оптимизации пользовательского интерфейса только после выпуска минимально жизнеспособного продукта.
Типы MVP
Волшебник страны Оз (иногда называют MVP Флинстоуна)
Оба названия этого типа минимально жизнеспособного продукта символизируют его принцип работы. Подобно тому, как Флинстоун создавал иллюзию того, что у него есть реальная машина, а Волшебник страны Оз использовал трюки, чтобы притворяться гигантской зеленой головой, феей, огненным шаром или монстром, этот тип MVP только кажется полностью функциональным. В реальности стартапер выполняет всю работу вручную, вместо того чтобы использовать программное обеспечение. Базовое программное обеспечение отсутствует вовсе, зато есть концепция продукта, которая требует проверки.
Nick Swinmurn, основатель Zappos, доказал, что данная стратегия работает. В самом начале он ни доллара не потратил на покупку обуви и аренду склада. Он опубликовал фотографии обуви на сайте. Как только покупатели начали заказывать обувь, он пошел в магазин, купил нужную пару и отправил ее. Осознав, что проект жизнеспособен, он обновил функциональность сайта.
Консьерж MVP
Предприниматели, которые выбирают консьерж MVP, также предоставляют практические услуги. Но в этом случае клиент знает, что за предоставленной услугой стоит реальный человек. Wealthfront, служба финансового планирования и инвестиций, начала с консьерж MVP. Сотрудники Wealthfront общались напрямую с клиентами, которым нужна была помощь в управлении капиталом.
Важное отличие консьерж MVP от типа «Волшебник страны Оз» состоит в том, что он направлен на генерацию идей о будущем продукта, предоставление услуги и общение с клиентом.
Разрозненный MVP
Идея разрозненного MVP — донести ценность использования существующих инструментов вместо создания уникального решения. Прототип продукта выглядит как комплексный продукт. Вы можете использовать простое программное обеспечение, собрать все воедино и добавить необходимую функциональность после получения обратной связи.
Groupon — отличный пример разрозненного MVP. Его основатель Andrew Mason запустил сайт на WordPress, где вручную размещал изображения еды каждый день. Он генерировал предложения в виде PDF-документов, используя AppleScript, и отправлял их по электронной почте через Apple Mail. Так он подтвердил гипотезу Groupon.
Продукт с одним параметром
MVP может быть реальным программным обеспечением с минимальным набором функций, основных, необходимых для проверки. С их помощью вы сможете сузить целевую группу, получить обратную связь и проанализировать ее, сосредоточиться на тестировании.
Независимо от того, какой тип MVP вы выберете, для создания минимально жизнеспособного продукта вам потребуется выполнить несколько основных шагов.
Пошаговое руководство по построению MVP
Продукт всегда начинается с идеи. Основное отличие успешного продукта от невостребованного состоит в том, что популярный продукт — результат осуществимой идеи, трансформированной с помощью детального плана развития.
Мы предлагаем пошаговое руководство по проверке вашей идеи и превращению ее в продукт. Вы сможете создать MVP за семь шагов. Шаг 0 — введение в основные принципы и методы. Восьмой и девятый шаги — о подходах к управлению проектами.
Шаг 0. Подтвердите базовые принципы и методы MVP
Шаг 1. Обозначьте проблему, которую хотите решить
Шаг 2. Определите целевую аудиторию и сузьте ее
Удовлетворить потребности широкой аудитории — ошибочное решение. Увеличьте свои шансы на успех — выберите определенную аудиторию. Сделайте развернутое описание персоны, которой может понравиться ваш продукт, которая купит его без колебаний. Вы должны знать, сколько лет этому человеку, какое у него образование, где он работает и какие доходы имеет. Описание конкретных привычек и хобби дополнит портрет потенциального покупателя. Чтобы узнать больше о создании персон покупателей, посмотрите нашу историю о начале бизнеса SaaS.
Представления об образе жизни интересной вам аудитории помогут понять, сможет ли ваш будущий продукт решать проблемы потенциальных покупателей, с которыми они сталкиваются регулярно.
Шаг 3. Проанализируйте конкурентов
Шаг 4. Сделайте SWOT-анализ
Наилучшая практика проведения SWOT-анализа — использование кратких описаний, понятных всем членам команды
Цель SWOT-анализа — сосредоточить усилия на сильных сторонах, определить и минимизировать слабые стороны, избежать угроз, а также использовать существующие возможности для дальнейшего развития. Сильные и слабые стороны обычно связаны с внутренними факторами. Возможности и угрозы — с внешними.
SWOT-анализ помогает компаниям анализировать конкурентов и выбирать стратегию позиционирования на рынке.
Шаг 5. Определите карту путей пользователя
User flow — путь, который проходит пользователь при взаимодействии с продуктом. Он должен быть логичным и понятным.
Карта путей пользователей — руководство с требованиями к контенту и дизайну сайтов / приложений. При построении хорошей карты путей пользователей вы должны понимать, что хотят получить клиенты при использовании вашего продукта. Убедитесь, что вы предоставили пользователям дополнительную информацию и выясните возможные недочеты, которые могут помешать им перейти на следующий шаг.
Давайте на примере доставки еды навынос из местных ресторанов рассмотрим список задач, которые пользователи должны решить, чтобы достичь основной цели. Путь пользователя будет следующим: формирование заказа, управление заказом, оплата еды, получение заказа. После того, как шаги обозначили, необходимо определить функции для каждого из них.
Шаг 6. Составьте список функций с градацией по приоритету
Вам необходимо перечислить обязательные функции для будущего продукта. Метод составления историй (или пользовательские истории) поможет вам на этом этапе планирования.
Пользовательские истории — двойственный подход к управлению историями пользователей. Он позволяет сосредоточиться на отдельных частях функциональности и в то же время не терять полного представления о продукте.
Методика направлена на то, чтобы помочь разработчикам выбирать полезные функции с точки зрения пользователей. Ее автор и практик Jeff Patton считает, что описание функций должно содержать действие, выполняемое человеком.
Мы перечислили 4 шага, которые пользователи совершают с помощью нашего продукта: формирование заказа, управление заказом, оплата еды, доставка заказа.
Сейчас мы должны описать функции для каждого шага и записать их на карточках. Например, чтобы настроить заказ, пользователь может:
Теперь давайте расставим приоритеты. Вы должны выяснить, насколько важна и ценна конкретная функция, как часто она используется, имеет ли риски, сколько пользователей к ней обращаются.
После того, как вы упорядочили функции в соответствии с их приоритетом, начертите вертикальную линию и разместите их в нужной последовательности. Самое важное и часто используемое поставьте в верх списка, остальное — разместите снизу.
Шаг 7. Определите объем MVP
После того, как вы расставили функции по их приоритету, можно определить объем MVP. Первый горизонтальный ряд на карте называется ходячим скелетом (каркасом). Этот ходячий скелет — наименьшая полезная версия продукта, которой недостает «мяса», то есть функциональности. Сначала мы должны создать каркас.
В некоторых случаях MVP совпадает с каркасом, а иногда обладает ограниченной функциональностью. Чтобы понять, какие есть отличия между каркасом, минимально жизнеспособным продуктом и его дальнейшей концепцией, вы должны классифицировать функции.
Начертим линию, чтобы отделить главные функции от несущественных. Функции, которым вы даете наивысший приоритет, представляют минимально жизнеспособный продукт. Остальные могут быть добавлены после развертывания MVP и анализа обратной связи.
Шаг 8. Выберите наиболее подходящий метод управления и разработки MVP
Это набор таких практик разработки, как рефакторинг кода, небольшие релизы, упрощенный дизайн, стандарты кодирования, которые позволяют улучшить код и обновить его в кратчайшие сроки. Циклы разработки с XP не превышают одной недели, поэтому вы можете выполнять первую версию быстрее, а затем масштабировать ее. XP хорошо подходит для MVP, который в значительной степени опирается на качество кода.
Выбор одного из итеративных подходов к разработке имеет решающее значение, поскольку позволяет создавать последовательный цикл обратной связи.
Шаг 9. Используйте альфа- и бета-тестирование
Альфа — так называемое внутреннее тестирование, когда ограниченная группа людей (в основном друзья или члены семьи) оценивают продукт. Если продукт прошел этот тест, вы можете перейти к бета-тестированию — позволить реальным пользователям попробовать продукт в течение одной-двух недель. Проанализируйте обратную связь и определите, какие функции необходимо добавить или заменить, чтобы сделать продукт лучшим.
Если вы собрали достаточно отзывов, можете обновить продукт, затем снова протестировать его и получить обратную связь. Количество циклов «создания-тестирования-обучения» и их временные рамки зависят от продукта. После того, как вы завершили несколько циклов, можете вернуться к шагу 0, изменить направление или продолжить итеративное улучшение вашего продукта.
Примеры MVP в различных отраслях
MVP должен передавать суть идеи в ее простейшей форме, которая зависит от контекста. Соответственно, и минимально жизнеспособные продукты варьируются в зависимости от проекта: от одностраничного сайта до рабочего прототипа программного обеспечения.
Например, в 1999 году Ник Суинмурн задумал продавать обувь через интернет, поэтому ему потребовался полноценный сайт Shoesite.com. Он запустил бизнес без каких-либо запасов или инвентаря, покупая продукцию под каждый оформленный заказ. Это дало ему возможность с низким уровнем риска проверить свою идею, не затрачивая средства на пополнение складских запасов. Вскоре Shoesite.com превратился в компанию Zappos, которую Amazon приобрел в 2009 году.
Чуть больше усилий к реализации своей концепции приложили создатели Uber. Гаррет Кэмп и Трэвис Каланик были разочарованы высокими расценками в такси Сан-Франциско. В 2010 году они запустили UberCab, простое приложение для iPhone, которое позволяло пассажирам арендовать для поездки лимузин по цене лишь в 1,5 раза выше стоимости городского такси. Изначально проект охватывал ограниченную территорию и, очевидно, предназначался для ограниченной целевой аудитории. Однако бета-версия помогла создателям донести ценность идеи и получить год спустя первые крупные инвестиции.
Один из самых простых в реализации MVP представили в 2008 году Брайан Чески и Джо Геббиа. Они не могли платить за квартиру-лофт в Сан-Франциско и решили проверить, существует ли спрос на аренду комнат напрямую от хозяина. Предприниматели создали простой MVP, который был не чем иным, как одностраничным сайтом с фотографиями собственной квартиры. Так был основан ныне всемирно известный Airbnb.
MVP и PoC: в чем разница
MVP не следует путать с доказательством правильности концепции (PoC — proof of concept). Последнее можно интерпретировать по-разному в зависимости от отрасли.
Прежде всего, доказательство правильности концепции — не ранняя версия продукта. PoC в разработке программного обеспечения описывает процессы, направленные на выяснение того, жизнеспособна ли концепция программного обеспечения технически. Команда также может выбрать этот подход с целью определения необходимого объема работы и лучших технологий разработки, выявления возможных технических проблем и поиска их решений.
Drew Houston, основатель Dropbox, сделал объяснительное видео и рассказал в нем, как должен работать Dropbox. Около 75 000 человек подписались на него в первую же ночь. Подобный метод может быть реализован с помощью блога, в котором вы делитесь с аудиторией идеями о продукте, который планируете разработать. Хоть и некоторые относят доказательство правильности концепции к MVP, мы склонны классифицировать эту трактовку отдельно как PoC.
Термины MVP и PoC взаимосвязаны, но не взаимозаменяемы. Доказательство правильности концепции, реализуемое оптимальным образом, становится минимально жизнеспособным продуктом.
Как определить функционал MVP и влюбить клиента в пилотную версию продукта
Итак, MVP. Достаточно заезженная тема, на мой взгляд. Каждый, кто хоть как-то связывал себя с разработкой программного обеспечения за последние 5 лет, с 99% вероятностью слышал эти 3 буквы. Но даже несмотря на обилие информации, народ все равно наступает на грабли «идеального продукта» при создании проектов.
Эта статья не претендует на то, чтобы быть истиной в последней инстанции. Она не про важность и необходимость MVP. И не про его роль в бережливом запуске стартапов. Я просто порассуждаю о том, каким должен быть минимально жизнеспособный продукт на момент пилотного выхода на рынок.
Начну с вирусной зарисовки пути развития стартапа по принципу MVP, которая гуляет по интернету и которую вы наверняка встречали.
90% авторов используют иллюстрацию в своих публикациях в буквальном смысле, что вводит в заблуждение читателей.
Разберем?
Верхняя строка ничего общего с MVP не имеет. Это понятно. На ней изображен классический цикл разработки. Автор использовал его как преувеличение ради контекста в примере ниже. Разумеется, ни о каком минимально жизнеспособном продукте на первом этапе с колесом речи и быть не может. Продукт прошел 3 стадии разработки (колеса, кузов, двигатель), прежде чем смог выполнить свое предназначение — ехать.
Но и вторая строка, на мой взгляд, также не совсем корректно отображает принцип MVP.
Почему мое внутреннее понимание минимально жизнеспособного продукта не сходится с такой концепцией? Если предположить, что она отражает путь разработки какого-то продукта, становится очевидно, что он претерпел 4 коренных перестройки. В итоге его создатели получили три группы товарно-родовых конкурентов: 1 — скейт-самокат-велосипед; 2 — мотоцикл; 3 — автомобиль.
Да, покупатель, как мы знаем, покупает не продукт, а решение своей проблемы. И скейт вроде бы решает базовую потребность (передвигаться быстрее, чем пешком). Но ведь скейт и автомобиль — это абсолютно разные средства передвижения, нацеленные на разную аудиторию и цель езды для каждого из них имеет совершенно разную специфику. Продукты по-разному удовлетворяют запросы к комфорту, цене, сложности техобслуживания, скорости и т.д. В результате, у каждого своя целевая аудитория.
У автомобиля более широкий охват: пожилые и молодые люди, те, кто путешествует в одиночку или в компании, кто ездит на работу или мотается в другой город — им нужна скорость, комфортное размещение и езда при любых погодных условиях. Скейт предназначен исключительно для одного человека, чаще ребенка или подростка, да и цель езды носит больше развлекательный характер. Аудитория скейта воспримет в штыки перспективу трансформации продукта в машину, которой нужно топливо, дорогостоящее ТО и возраст 17+, не говоря уже о цене самого автомобиля. А те, кому нужна машина, изначально не обратят на ваш самокат никакого внимания. Да, каждый из этих продуктов может иметь MVP, но они не являются MVP друг для друга.
Хенрик Книберг, автор этой картинки, не раз писал о том, что его изображение не всегда интерпретируется в правильном контексте. Дело в том, что он вкладывал в нее метафорический смысл, при котором цель разработки — не построить автомобиль, а решить задачу «добраться из пункта А в пункт Б». И самым простым жизнеспособным вариантом решения этой задачи является скейт. То есть на ней абстрактно и очень упрощенно передан некий концепт поиска продукта. Скейт или самокат не являются MVP для машины. Это факт. На картинке лишь изображена идея того, что в рамках создания продукта можно сделать несколько пивотов и в итоге найти MVP.
А эта переосмысленная версия MVP мне больше пришлась по душе:
В продуктовом бизнесе MVP продукта — это сам продукт, только выполненный с какими-то упрощениями, сокращениями, удешевлениями. MVP высотного здания — это та же высотка, но не на 24 этажа, а на 5, без лифта, мусоропровода и прочих благ. MVP автомобиля — это автомобиль. Только попроще. Сначала из досок и сваренной на скорую руку рамой, с двигателем послабее (или вообще без него), сидениями от мебельного гарнитура. Но три ключевые функции, отстраивающие его от скейта или самоката, — скорость, вместительность и дальние поездки — уже будут при нем.
Что завернуть в MVP, чтобы его захотели попробовать?
С концепцией MVP разобрались. Теперь поговорим о том, как определить начинку пилотного продукта, приоритезировать функционал и сделать первую версию продукта востребованной.
Первое, что необходимо сделать, — это выяснить, какие инструменты, фичи и возможности станут для вашего продукта must have.
Принцип Парето
«20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата». Это эмпирический принцип, а значит многие явления в мире, в том числе и разработка, подчиняются такому соотношению. 80% ваших пользователей будут использовать только 20% функционала. Поэтому не нужно тратить месяцы на то, чтобы отполировать до кристального сияния свой продукт перед запуском. Пропишите полный перечень функций будущего приложения и определите те 20%, которые закроют 80% потребностей пользователей.
MVP = обязательно + просто
Слышали про матрицу приоритетов? Популярная техника приоритезации задач, которая распределяет фичи по шкалам «обязательно» и «просто». Изобразите две оси, где горизонтальная будет отображать увеличение сложности реализации конкретной функции, а вертикальная — путь от желательного к обязательному. Раскидайте весь запланированный функционал на этой схеме, отвечая на 2 вопроса:
Получив готовый список с помощью этой матрицы, можно смело обращаться к разработчикам.
Формула Rice Score
Еще один эффективный метод приоритезации идей и фич для MVP. Вам нужно оценить каждую функцию по четырем факторам и подставить значения в простую формулу.
Рассчитайте оценку для каждой фичи, согласно формуле:
Вместо итога
MVP подход играет роль подушки безопасности и позволяет адекватно прогнозировать коммерческий и технический потенциал продукта. Поэтому, когда мы брифуем заказчиков, то настаиваем на том, что стартовать разработку лучше с него. И, разумеется, помогаем определиться с ключевым функционалом. Если вы планируете создание минимально жизнеспособного продукта, то лучший вариант — построить его на NoCode технологии. Сегодня платформы для разработки приложений без кода пользуются бешеным спросом. Они позволяют быстрее и дешевле создавать web-приложения любой сложности, а существующие биржи NoCode фриланса помогают подобрать подходящую под запросы бизнеса технологию и проверенного специалиста. Осмелюсь предположить, что тенденция к упрощению и удешевлению разработки будет только усиливаться. И сейчас самое время задействовать ее потенциал.
MVP – это не продукт, а процесс. Думаете, что это не так?
MVP это не просто продукт с половиной урезанных фич. По факту, MVP не является продуктом вообще. И это, конечно, не то что вы сделали один раз и считаете что работа уже окончена. Скорее всего, вы вообще не понимаете, что это такое.
MVP – это не продукт, а процесс. Думаете, что это не так?
MVP это процесс, где вы повторяете все раз за разом: определяете свои гипотезы, находите самые быстрые варианты их проверки и используете полученные результаты для изменения стратегии.
Когда вы делаете продукт, у вас изначально много предположений. Вы думаете что вы знаете что хотят пользователи, что они ищут, каким должен быть дизайн, какую маркетинговую стратегию использовать, какая архитектура будет наиболее эффективной, как монетизировать продукт.
Неважно насколько вы хороши, всё равно какие-то из ваших гипотез окажутся ошибочными. Только есть одна проблема – вы не знаете какие именно.
В последнем исследовании сотни стартапов, CB Insights определило, что самая главная причина провала (42% всех случаев) – это отсутствие рыночного спроса. Почти половина этих стартапов потратили месяцы, или даже годы, делая продукт до момента, пока не осознали, что их гипотеза была неправильной – что кто-то вообще заинтересован в их продукте.
Единственный путь проверить гипотезу – это дать продукт потенциальному клиенту как можно быстрее. И если вы будете делать это постоянно, то вы поймёте, что большинство гипотез проваливаются. И вам придётся каждый раз возвращаться к началу, тестируя разные гипотезы.
И это не новшество в разработке продуктов. Когда вы пишите книгу или эссе, то много времени тратите на редактирование, доработку. Когда пишите код, вы тоже несколько раз перерабатываете его. Каждое креативное стремление человека требует огромного количества проб и ошибок.
В этом мире, кто быстрее находит ошибки и исправляет их, тот и становится победителем. Некоторые люди называют эту философию «Fail fast» (проваливайся быстро). В TripAdviser мы называем это «Speed wins» (Скорость — это преимущество). Эрик Райз называет эту методику “Lean” (бережливый), Кент Бэк (один из создателей Agile Manifesto) и другие программисты называют это Agile.
По сути, не важно как вы будете называть это. Самое главное – это как можно быстрее определить, какие из ваших гипотез ошибочны, с помощью фидбека реальных пользователей.
Когда вы делаете продукт, пишете код или разрабатываете маркетинговый план, вы всегда должны задать себе несколько вопросов:
Какая гипотеза в проекте самая сомнительная?
Как быстрее всего её проверить?
MVP как процесс в действии.
Давайте разберём пример, шаг за шагом. После него вы точно поймёте, что такое MVP.
Например, вы решили сделать продукт, который позволит рестораторам создавать мобильные приложения для их заведений в несколько кликов. У приложения будет простой интерфейс – drag and drop, готовые шаблоны, календарь событий, новостная лента, чек-ины, фотогалерея, чат в реальном времени, интеграция с сайтами-обозревателями, социальными сетями и Google maps.
И самое главное – приложение будет предлагать бронирование места, заказы на вынос, и использование купонов, с которых вы будете снимать небольшой процент, чтобы монетизировать продукт. Вроде бы выглядит очень даже круто!
Вы найдете несколько друзей, которые станут вашими ко-фаундерами. В идеальной ситуации (которая не произойдёт в 99.9% случаев) “поднимите” немного денег у зажиточного бизнес-ангела, запрётесь в комнате на 12 месяцев и будете пилить все эти фичи.
Если вы более прокачаны, то урежете половину фич, которые вам кажутся не первостепенными. И сможете запустить свой MVP за 8 месяцев, а не за 12.
В обоих случаях вы скорее всего провалитесь.
Почему? Окей, учитывая сколько предположений вы сделали, все может оказаться катастрофически неправильным.
Вы потратили месяцы продумывая как запустить клевое приложение для клиентов, не учитывая то, чего хотят рестораторы на самом деле. Возможно, всё гораздо-гораздо проще: они хотят адаптивный сайт, который легко найти в гугле. И всё. Им больше ничего не нужно.
Или вы две недели пилили онлайн-чат, но только после реальных тестов поняли, что рестораторы предпочитают общаться по электронной почте и не хотят сидеть за компом целый день.
Или самое худшее — вы увидели, что рестораторы вообще не хотят сражаться с этими новейшими технологиями. И вообще — использовать мобильное приложение. У них нет особого интереса к такому навороченному продукту.
8 месяцев работы (или даже 12, а может 24), для того чтобы увидеть все слабые моменты – это слишком долго и дорого. В лучшем случае, такая потеря будет просто тратой времени, в худшем – это разрушит ваш бизнес (а может и жизнь).
По словам Питера Друкера «Нет ничего настолько бессмысленного, как создание бесполезного продукта, никому не нужного продукта».
Делаем приложение по MPV-процессу
Давайте опробуем MVP процесс и прикинем, как можно было бы избежать всех косяков. Мы будем делать продукт постепенно, задавая себе два одних и тех же вопроса на каждой стадии:
Какая гипотеза в проекте самая сомнительная?
Как быстрее всего её проверить?
В самом начале, самое смелое предположение: Рестораторам нужно такое мобильное приложение
Поэтому первое MVP должно быть наброском мобильного приложения – может быть даже таким, которое будет сделано на обороте ресторанной салфетки (как в тему, да?).
Походите по рестораторам в вашем районе, и спросите используют ли они новые технологии в своей сфере? И вообще есть ли у них мобильные приложения? А если нет, то почему? Хотели бы они его себе? Насколько они технически подкованы? Понимают ли они возможную выгоду?
Покажите им мок-ап (набросок), и подумайте будет ли это хорошим решением их проблем.
Вы сможете увидеть, что у рестораторов мало интереса для того, чтобы такой проект стал серьезным бизнесом. Да, это обидно. Но хорошо то, что вам это стоило пару часов беседы, вместо месяцев разработки.
С другой стороны, возможно вы узнаете, что рестораторы заинтересованы не в мобильном приложении, а в простом адаптивном сайте. И это прогресс!
Но вы еще не закончили. Сейчас вы должны повторить процесс, что бы выстроить следующий MVP.
Какая гипотеза в проекте самая сомнительная?
«Захотят ли рестораторы платить за адаптивный сайт?»
И как можно это проверить?
Одной из идей для следующего MVP может быть создание статических страниц для нескольких заинтересованных рестораторов, чтобы посмотреть, как они реагируют на него.
Им нравится? Они впечатлены, тем что сайт делается в пару кликов? Сколько они готовы заплатить, чтобы такой же ресурс был у них уже вчера?
Возможно, когда придёт время платить за сайт, вы поймёте, что рестораторы не сильно то и готовы это делать. Хорошо то, что вы поняли это за несколько дней, а не несколько месяцев тупой разработки.
Или допустим, вы поймёте, что они хотят платить. Вы возьмёте плату за несколько месяцев вперёд — наличными или чеком — запустите их сайты и попросите в случае необходимости обновлений писать прямо на e-mail (то есть все изменения на сайте будете делать вручную на этом этапе)
Да, это требует больших усилий с вашей стороны. Да, это нельзя масштабировать на сотни клиентов. Но если вы мелкий стартап, не бойтесь делать точно так же. Пускай первым клиентам вы будете делать всё вручную, имитируя автоматический сервис. А когда поймёте, что людям нужен ваш продукт и они будут платить за него, тогда и начинайте автоматизировать все процессы.
Продолжаем дальше наш MVP-процесс.
Какая гипотеза в проекте самая сомнительная?
В этот раз, возможно ваша маркетинговая стратегия по привлечению клиентов сработала. Но вы не сможете обойти все рестораны в мире.
Тогда возникает вопрос как проверить эту гипотезу на большем количестве людей с минимальными затратами?
Ваш MVP может быть лендингом, который объяснит суть продукта. Показывайте простые сайты ресторанов, которые вы сделали раньше, и стимулируйте посетителей оставлять свои контакты, если их это заинтересовало. Вы можете купить рекламу на несколько сотен бакосв, что бы пустить трафик на лэндинг. И понаблюдать, что будет дальше.
Если потенциальные клиенты даже не оставляют свою почту, значит они и не выложат ни одного бакса за ваш сервис. Намного легче понять это, с помощью размещения текста и нескольких картинок на лендинге, чем переписывать тысячи строк кода в целом продукте!
Чем раньше вы обнаружите ошибки, тем меньше времени вы потратите на бесполезные, ни кому не нужные вещи.
Чувак, это MVP
Когда вы разрабатываете дизайн продукта, создаёте маркетинговый план или пишите код, всегда спрашивайте себя:
Какая гипотеза в проекте самая сомнительная?
Как быстрее всего её проверить?
Всего два простых вопроса, которые могут сэкономить вам очень много времени и денег. Запишите и повесьте их прямо перед вашим рабочим местом.
Читайте также наши другие популярные статьи: