Чтобы добиться успеха с минимальными рисками и затратами в условиях, где закрывается 92% запущенных стартапов, каждый проект стоит начинать с запуска минимально жизнеспособного продукта. В этой статье мы разберем понятие, типы и этапы построения MVP.
Согласно исследованию CB Insights, в 42% случаев причиной провала стартапа становится отсутствие рыночного спроса. Почти в половине случаев предприниматели тратят месяцы и даже годы работы лишь затем, чтобы осознать, что гипотеза была ошибочной, и никто не заинтересован в их продукте.
Концепция MVP (Minimum Viable Product) — разработана, чтобы минимизировать риск такой ситуации. Она применима для создания любого продукта, но чаще используется для разработки программного обеспечения и цифровых сервисов.
Понятие MVP ввел в оборот в 2001 году Фрэнк Робинсон (Frank Robinson), соучредитель и президент консалтинговой фирмы SyncDev. Робинсон определяет MVP, как результат «синхронной разработки» — одновременного развития продукта и исследования целевой аудитории, ее реакции на продукт. MVP — такая версия будущего проекта, которая позволяет собрать максимум практических данных о том, как с ним взаимодействуют клиенты, при минимальных затратах.
MVP часто путают с PoC — Proof of Concept — доказательством правильности концепции. Эти понятия взаимосвязаны, но не равнозначны. В качестве PoC выступают: реакция потенциальных клиентов на анонс, число предзаказов, маркетинговые и социологические исследования и другие теоретические свидетельства того, что будущий продукт интересен рынку. MVP — больше, чем доказательство, это — работоспособный продукт.
Вместе с тем, MVP — не прототип. Минимально жизнеспособный продукт содержит только самую необходимую функциональность, но он не должен быть сырым или примитивным. Напротив, основную функцию MVP должен выполнять как можно лучше.
Minimum Viable Product создается не для тестирования технологий, а чтобы проверить на практике, нужен ли пользователям такой продукт, верны ли гипотезы, лежащие в основе бизнес-модели. Главная задача MVP — минимизировать время и усилия, затраченные на тестирование реакции рынка на идею.
MVP позволяет привлечь к проекту реальных пользователей в качестве проводников, которые помогут скорректировать бизнес-модель и базовые характеристики будущего продукта, наметить направления развития и спланировать дорожную карту обновлений. Положительные результаты на стадии MVP дают зеленый свет для разработки полной версии продукта.
Показательный пример MVP — мессенджер WhatsApp, который в момент публикации в 2009 году не имел функций для отправки сообщений.
Создатели WhatsApp — Ян Кум (Jan Koum) и Брайан Эктон (Brian Acton) исходили из простой идеи — создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании, за рулем, в спортзале и так далее. Когда пользователи указывали статус, их контакты получали всплывающее уведомление.
Вскоре Кум и Эктон заметили, что пользователи стали использовать статусы для общения. Ухватившись за эту идею, они выпустили новую версию WhatsApp, в которой было больше функций, связанных с отправкой сообщений. В результате небольшая пользовательская база в считанные дни выросла до 250 000 человек, доказав, что разработчики на верном пути.
Таким образом, минимально жизнеспособный продукт позволяет:
Среди многочисленных подходов к созданию Minimum Viable Product выделяют три основных подхода.
Наиболее распространенный вариант создания MVP уже был описан на примере WhatsApp. Это приложение или программа, выполняющие одну-две функции, которые необходимы для проверки жизнеспособности вашей идеи. Если основная функциональность приложения неинтересна пользователям, то продолжать вкладывать в разработку силы, время и ресурсы бессмысленно.
Этот подход применяют, если идею продукта можно реализовать без разработки уникальных программных решений, при помощи набора готового программного обеспечения.
Объединение различных инструментов в единый комплекс и, тем более, разработка оригинального ПО — делают тестирование бизнес-идеи трудозатратным и дорогостоящим. Иногда к этим стадиям разработки стоит переходить уже после получения обратной связи от пользователей.
Так запустился сервис Groupon. На старте он представлял собой лишь примитивный сайт на основе открытого исходного кода. Все услуги Groupon оказывал по электронной почте. Социальные функции, полноценная email-рассылка, автоматизация, мобильное приложение — все это было разработано потом, когда стало ясно, что коллективные покупки востребованы.
Эти близкие разновидности Minimum Viable Product подразумевают отказ от длительной и дорогостоящей разработки в пользу ручного труда.
Герой сказки Фрэнка Баума (Lyman Frank Baum) изображал из себя волшебника, а MVP этого типа притворяются полнофункциональными сервисами и приложениями. На деле же, вместо алгоритмов работу Minimum Viable Product обеспечивают люди.
Волшебник страны Оз не афиширует этот факт. Так поступал основатель Zappos — крупного американского интернет-магазина. Чтобы убедиться в жизнеспособности идеи, он начал продажи задолго до того, как автоматизировал заказы и даже арендовал склады. Первых клиентов Ник Свинмурн (Nick Swinmurn) обслуживал лично, приобретая товары со скидками в рознице и перепродавая их.
Отличие продуктов, построенных по консьерж-модели, в том, что они открыто позиционируются, как предоставляющие услуги реальных людей, и используют этот факт, как одно из конкурентных преимуществ.
Чтобы запустить минимально жизнеспособный продукт, необходимо пройти через восемь подготовительных этапов. Первые четыре шага нацелены на предварительное уточнение бизнес-идеи. Пятый и шестой этапы касаются проектирования продукта, и только на седьмом и восьмом пунктах дело дойдет непосредственно до разработки и тестирования.
Каждый продукт создается для решения некой задачи, и речь не о получении прибыли. Здесь требуется клиентоориентированный подход. Для чего пользователю нужен продукт?
Внятно сформулировав ответ, вы получите представление о задаче продукта и о его ценности для пользователя. Так, открывая сервис для краткосрочной аренды парковочных мест, вы решаете проблему, с которой сталкиваются все водители, — облегчаете поиск места, где можно оставить машину.
Ориентироваться на потребности широкой аудитории при проектировании MVP — ошибочная стратегия. Сужение целевой аудитории позволяет точнее ориентировать будущий продукт. Для этого необходимо сформулировать портрет «идеального» пользователя, человека, который без раздумий купит ваше решение и останется доволен его возможностями.
Обычно в такой портрет включают информацию о возрасте пользователя, уровне образования, доходах, привычках, интересах и увлечениях. Эти детали необходимы, чтобы понять, насколько хорошо продукт подходит будущему пользователю, и помогут позднее, на этапе рекламы и продвижения.
Даже если вы придумали нечто
Этот метод стратегического планирования используется крупными компаниями для принятия управленческих решений и формирования бизнес-политики с 1963 года. И хотя обычно он используется в куда большем масштабе, SWOT-анализ хорошо подходит для определения сильных и слабых сторон, возможностей и угроз для минимально жизнеспособного продукта.
После фундаментального анализа бизнес-идеи самое время взглянуть на будущий продукт с точки зрения пользователя. Карта путей — тот порядок действий, который пользователь совершает, чтобы достигнуть своей цели, например, приобрести товар или найти и арендовать парковочное место.
Этот путь должен быть не просто максимально коротким, но и простым и удобным. Продумав, как пользователь взаимодействует с будущим приложением, вы поймете, на какой стадии предоставить дополнительную информацию, где добавить подсказку и как оптимально спроектировать интерфейс.
Каким бы масштабным ни был задуманный проект, для MVP необходимо перечислить и приоритезировать его функции. При создании Minimum Viable Product предпочтение отдается тем из них, что непосредственно связаны с основной целью будущего продукта.
Введение дополнительных возможностей в прототип только запутает пользователей и снизит достоверность результатов исследования бизнес-идеи. Их можно добавлять уже после развертывания MVP, сбора и анализа первичной обратной связи.
Определив объем, порядок и направление работ, можно приступить к разработке минимального жизнеспособного продукта.
От того, как именно будет построен процесс разработки, во многом зависит результат. Для MVP принципиально важно использовать один из итеративных подходов к разработке. Lean, Scrum, Kanban, экстремальное программирование — все они позволяют наладить регулярный выпуск обновлений, совершенствовать продукт «на ходу», по мере поступления обратной связи. Выбор конкретной методологии зависит от предпочтений команды разработчиков и особенностей конкретного проекта.
Минимально жизнеспособному продукту требуется регулярное тестирование на всем протяжении разработки. Альфа-тестирование проводится внутри команды силами тестировщиков, но для бета-тестирования потребуется помощь посторонних. Хорошо, если это будут люди из числа будущих пользователей. Желающих поучаствовать в тесте можно найти на таких сайтах, как BetaList, ProductHunt, Reddit, Quora или привлечь через собственные каналы связи: социальные сети, блоги и email-рассылку.
Основной задачей тестирования будет техническое совершенствование MVP. Перед выпуском продукт должен работать без ошибок, чтобы проблемы технического характера не помешали пользователям оценить его функциональность.
Для команды проекта работа еще только начинается. С момента запуска необходимо собирать, сохранять и анализировать обратную связь, начиная со статистики и заканчивая данными о поведении и отзывами пользователей. Эта информация — то, ради чего все затевалось.
Данные, собранные при помощи MVP, позволят понять, есть ли у проекта перспективы, помогут сгенерировать новые идеи и разработать стратегию развития продукта, основанную, не на предположениях, а на фактах. Таким образом, MVP тестирование полностью себя оправдает.
Наш опыт позволяет нам оценивать полученные данные и анализировать фидбек от клиентов. Мы понимаем, что запустить MVP, протестировать продукт и обработать обратную связь — сложные и затратные задачи, которые требуют профессионального подхода.
Если вы запускаете новый продукт и не знаете с чего начать — свяжитесь с нами через форму обратной связи, и мы поможем реализовать ваш проект.
