Что такое mvp прототип
Что такое MVP, зачем он нужен и как его правильно создать
Хотите создать стартап, но не уверены в его успехе? Или необходимо понять, будет ли пользоваться спросом новая функция в уже существующем продукте? Кажется, пришло время запускать MVP!
MVP («минимально жизнеспособный продукт») — это ранняя версия продукта, которая имеет набор всех основных функций, но ещё нуждается в тестировании на реальных пользователях. Она позволяет создателям находить баги и проблемы в полевых условиях, собирать отзывы клиентов и дорабатывать продукт. С MVP можно оценить жизнеспособность идеи и улучшить её без больших финансовых затрат.
В этой статье поговорим о преимуществах MVP для бизнеса, обсудим этапы создания и расскажем, почему для запуска первой версии продукта стоит выбрать NoCode-инструменты.
Как обычно, вещает студия NoCode-разработки ZeroToOne 🙂
Коротко — это ранняя версия продукта со всеми основными функциями. Суть MVP в том, чтобы быстро превратить концепт в вашей голове в практическое решение, которое можно проверить на реальных пользователях.
У MVP продукта есть две главные цели:
На этом этапе опирайтесь на следующие правила:
4. Разработайте проект MVP. Тут необходимо определиться с форматом (лендинг, прототипирование, e-mail-рассылка и т. д. — подробнее о видах MVP поговорим далее). А теперь запускайте MVP и тестируйте гипотезы.
5. Доработайте продукт с учётом фидбека и составьте Blueprint — карту взаимодействия пользователя с продуктом. Выясните, как пользователи на самом деле ведут себя с продуктом, постройте их путь, проанализируйте его, доработайте сценарий взаимодействия с MVP.
Тут можно опираться на следующие метрики:
Blueprint или Service blueprint — это спроектированный вами, желаемый путь пользователя внутри продукта. Он строится на основе карты клиентского опыта (customer journey map) — фактического пути пользователя по сервису.
CJM показывает опыт клиента таким, как он есть, и помогает понять, как привести пользователя к решению, которое предлагаете вы.
Как только люди начнут пользоваться продуктом, вы поймёте, что именно работает, а что вы упустили. Возможно, вы выбрали немного не те цвета и расположение кнопок, не доработали юзабилити, переборщили с элементами или наоборот — что-то не добавили. Опора на обратную связь от аудитории — ваш ключ к победе.
Как мы уже сказали, MVP подойдёт всем: и начинающему, и зрелому бизнесу.
Стартапу MVP необходим, потому что с ним можно уже на старте с минимальными вложениями выбрать правильную траекторию развития и получить шанс вырасти в успешный, глобальный проект.
Для крупного бизнеса создание MVP будет полезным в случае внедрения новых функций в уже рабочий продукт или создания новых направлений деятельности. Например, прежде чем запускать новый образовательный курс и набирать преподавателей, онлайн-школе стоит сделать лендинг и открыть предзапись, чтобы понять, будет ли оно того стоить. Так MVP поможет снизить риски лишних трат в случае неудачного запуска.
Чаще всего для создания первой версии продукта используются:
E-mail-рассылки или чат-боты. Этот вид MVP поможет сосредоточиться на рассказе о продукте и позволит сделать его подробным. К тому же, благодаря тому, что у вас будет прямой контакт с аудиторией, вы сможете быстро получать обратную связь и постепенно совершенствовать свою идею. Для настройки e-mail-рассылки можно взять такие NoCode-инструменты, как Sendpulse или Unisender, а создать чат-бота поможет Chatforma.
Необязательно использовать лишь один вид MVP — они также могут работать сообща. Например, можно выпустить рекламный ролик с тезисным рассказом о продукте и предложить перейти на сайт для регистрации на альфа- или бета-тестирование. Или начать знакомство аудитории с вашим сервисом через чат-бота, который будет вести на лендинг, например, для записи на курсы.
При разработке MVP важно быстро реагировать на фидбек пользователей и иметь под рукой гибкие инструменты работы. Если каждая правка будет затягиваться на несколько недель, то запустить и доработать MVP получится нескоро, а релиз основного продукта может сильно отложиться. И ещё было бы здорово, если бы MVP не «украл» большую часть финансов у основного продукта.
Основные преимущества NoCode-инструментов — высокая скорость разработки и более низкая стоимость по сравнению с традиционной сборкой сайта или приложения. Кроме того, NoCode позволяет вносить правки буквально за несколько часов, если подобрать грамотные решения. Выходит, что NoCode идеально подходит для запуска MVP.
Надеемся, что примеры ниже смогут воодушевить не только владельцев стартапов и тех, кто только подумывает их создать, но и сотрудников крупных компаний.
Product Hunt — это социальная сеть для разработчиков, где они могут делиться идеями продуктов, опытом, обсуждать последние новости IT, дизайна и маркетинга, задавать вопросы и даже искать работу или сотрудников.
Product Hunt вырос из почтовой рассылки на NoCode-инструментах MailChimp и Telescope — она и была MVP проекта. Его основатель, Райан Хувер, долго интересовался стартапами и однажды понял, что в Интернете ещё не существует ресурса для обсуждения именно новых продуктов. В 2013 году он решил запустить эксперимент — e-mail-рассылку с новостями о стартапах и рейтингом 5 лучших проектов за прошедшие сутки. За пару недель база подписчиков выросла до 200 человек и превратилась в полноценный продукт: сайт и приложение.
Это студия разработки мобильных и браузерных игр, ставшая популярной благодаря FarmVille и CityVille. Они были запущены в 2009 году на базе Facebook и тогда же Zynga стала разработчиком с наибольшим количеством активных пользователей: на Facebook в игры студии играли 40 миллионов пользователей ежемесячно.
В разработке игр Zynga регулярно использует MVP: студия создаёт лендинги и короткие рекламные ролики («sneak peeks») о новых играх и о функциях уже существующих, чтобы получить обратную связь от игроков и узнать, в каких направлениях стоит развивать свои продукты. Также студия использует предрегистрацию, чтобы набрать базу игроков перед запуском.
Создание MVP или как разработка прототипа может значительно повысить вероятность выживания стартапов
Что мы знаем об MVP (minimum viable product)? Это ранняя версия продукта, в которую заложен минимальный набор функций. Создается она с целью тестирования гипотезы о жизнеспособности продукта и получения обратной связи от пользователей. По сути, MVP — это прототип изначально задуманного полноценного продукта.
В силу того, что на территории русскоязычного пространства термин “MVP” еще не достаточно популярен, многие начинают путаться в понятиях.
На различных ресурсах можно встретить статьи на тему “Как создать прототип и какие инструменты для этого использовать”. Но под словом “прототип” авторы, как правило, подразумевают набросок или макет страницы, который отображает правильное расположение элементов. Зачастую именно прототип в таком понимании служит техническим заданием для дизайнера.
На мой взгляд, более правильным и понятным обозначением будет “прототип интерфейса”. Кстати, он тоже играет важную роль при создании визуальной части web-продукта, но сейчас речь не об этом.
В статье я поднимаю вопрос полноценного функционального прототипа продукта, который поможет понять, насколько идея (даже самая гениальная, на ваш взгляд) сможет “выжить” в современном VUCA мире.
Итак, для чего нужен прототип (MVP) продукта:
Чтобы прототип показал реальную картину, необходимо правильно подойти к его разработке. Согласитесь, созданный в спешке “сырой” продукт вряд ли позволит подтвердить гипотезу о его востребованности. Но, с другой стороны, MVP необходимо создать максимально быстро, с минимум потраченных денег, и включать он должен только самые ключевые функции (пользовательскую потребность в которых нам и нужно проверить).
Первое, что необходимо определить перед разработкой MVP — это какие инструменты, фичи и возможности станут для вашего продукта ключевыми. Например, если вы создаете систему дистанционного обучения, ключевым функционалом будет конструктор курсов, тестов, опросов, возможность проверки домашних заданий и итоговой оценки студента, загрузка конспектов и видео. А такие инструменты, как геймификация, диалоговые тренажеры, возможность кастомизации кабинетов, дополнительные роли в системе, могут быть «допилены» позже, когда потенциальные клиенты начнут тестировать систему и давать обратную связь.
Гнаться за идеалом и совершенствовать продукт можно бесконечно, а правило Парето еще никто не отменял. 80% ваших клиентов, скорее всего, будут использовать только 20% функционала. Им может быть вполне достаточно того, что есть или нужно совершенно не то, на что вы делали ставку. Поэтому важно сосредоточиться именно на этих на 20% функциональных возможностей.
Итак, мы пришли к выводу, что создание MVP помогает избежать разработки ненужного функционала, который не будет нести ценности для потребителя, но при этом потратит ваши ресурсы.
А теперь, предположим, что вы нащупали свободную нишу на рынке. Вы четко знаете, какой функционал нужен потребителю и быстро хватаетесь за разработку серьезного проекта, чтобы попасть в голубой океан. Но разработка затягивается (что может произойти по многим причинам), а если проект действительно масштабный, то процесс может затянуться не на один год. Продукт, наконец, готов, вы выпускаете его “в свет”, но тут оказывается, что голубой океан превратился в красный. И пусть ваш продукт будет функционально сильнее, влиться в конкурентную среду будет уже не так просто. Это уже не говоря о высокой стоимости разработки и возможной утрате актуальности заложенного функционала.
Согласно исследованию, из 3200 быстрорастущих интернет-стартапов 74% потерпели неудачу по причине преждевременного масштабирования.
Что же нужно для успешного MVP?
Поэтому, прежде чем инвестировать деньги в полноценный продукт, разумнее разработать MVP, которая поможет сократить затраты, минимизировать риски и понять, насколько ваша идея жизнеспособна.
Какие инструменты можно использовать для создания MVP?
Их, как и термины, можно разделить на 2 вида:
В первом случае все предельно понятно. Существует множество сервисов, разобраться в которых не составит труда. Это Proto.io, Marvel, InVision, Moqups и другие.
В случае с MVP дело обстоит сложнее. Здесь, как правило, приходится привлекать программистов, что делает разработку прототипа дорогостоящей и зачастую затянувшейся (особенно, если у вас ранее не было опыта работы с такими проектами).
Какие еще есть варианты?
Если у вас есть навыки работы с версткой, можно попробовать разработать MVP своими силами, используя cms системы, такие как Joomla или WordPress. Но этот вариант подойдет для создания несложной архитектуры продукта. Если вы планируете более серьезный проект, вам, скорее всего, не обойтись без знания PHP.
Также в помощь могут прийти и конструкторы сайтов. Их минус в том, что из-за ограниченного функционала вы постоянно будете упираться в необходимость использовать только существующие шаблоны. Да и полноценную пользовательскую логику там не построишь, честно говоря.
Разобравшись самостоятельно или пройдя недолгое обучение, манипулируя графическими элементами и прописывая логику, вы сможете не только самостоятельно создать MVP, но и постепенно дорабатывая приложения, получая фидбек от рынка, создать действительно крутое решение с минимальными инвестициями в разработку.
В заключение, хочу отметить, не важно какой продукт вы планируете создать и какой у него масштаб, создание его минимальной жизнеспособной версии, поможет не только выявить сильные и слабые стороны, но и сократить возможные риски провала проекта.
А о нашем опыте запуска стартапов, читайте в предыдущей статье:
Что такое MVP, и как создать минимально жизнеспособный продукт
Чтобы добиться успеха с минимальными рисками и затратами в условиях, где закрывается 92% запущенных стартапов, каждый проект стоит начинать с запуска минимально жизнеспособного продукта. В этой статье мы разберем понятие, типы и этапы построения MVP.
MVP — подробное руководство по созданию минимально жизнеспособного продукта
Согласно исследованию CB Insights, в 42% случаев причиной провала стартапа становится отсутствие рыночного спроса. Почти в половине случаев предприниматели тратят месяцы и даже годы работы лишь затем, чтобы осознать, что гипотеза была ошибочной, и никто не заинтересован в их продукте.
Концепция MVP (Minimum Viable Product) — разработана, чтобы минимизировать риск такой ситуации. Она применима для создания любого продукта, но чаще используется для разработки программного обеспечения и цифровых сервисов.
Понятие MVP ввел в оборот в 2001 году Фрэнк Робинсон (Frank Robinson), соучредитель и президент консалтинговой фирмы SyncDev. Робинсон определяет MVP, как результат «синхронной разработки» — одновременного развития продукта и исследования целевой аудитории, ее реакции на продукт. MVP — такая версия будущего проекта, которая позволяет собрать максимум практических данных о том, как с ним взаимодействуют клиенты, при минимальных затратах.
Отличия MVP от PoC
MVP часто путают с PoC — Proof of Concept — доказательством правильности концепции. Эти понятия взаимосвязаны, но не равнозначны. В качестве PoC выступают: реакция потенциальных клиентов на анонс, число предзаказов, маркетинговые и социологические исследования и другие теоретические свидетельства того, что будущий продукт интересен рынку. MVP — больше, чем доказательство, это — работоспособный продукт.
Отличия MVP от прототипа
Вместе с тем, MVP — не прототип. Минимально жизнеспособный продукт содержит только самую необходимую функциональность, но он не должен быть сырым или примитивным. Напротив, основную функцию MVP должен выполнять как можно лучше.
Задачи MVP
Minimum Viable Product создается не для тестирования технологий, а чтобы проверить на практике, нужен ли пользователям такой продукт, верны ли гипотезы, лежащие в основе бизнес-модели. Главная задача MVP — минимизировать время и усилия, затраченные на тестирование реакции рынка на идею.
MVP позволяет привлечь к проекту реальных пользователей в качестве проводников, которые помогут скорректировать бизнес-модель и базовые характеристики будущего продукта, наметить направления развития и спланировать дорожную карту обновлений. Положительные результаты на стадии MVP дают зеленый свет для разработки полной версии продукта.
Пример MVP
Показательный пример MVP — мессенджер WhatsApp, который в момент публикации в 2009 году не имел функций для отправки сообщений.
Создатели WhatsApp — Ян Кум (Jan Koum) и Брайан Эктон (Brian Acton) исходили из простой идеи — создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании, за рулем, в спортзале и так далее. Когда пользователи указывали статус, их контакты получали всплывающее уведомление.
Вскоре Кум и Эктон заметили, что пользователи стали использовать статусы для общения. Ухватившись за эту идею, они выпустили новую версию WhatsApp, в которой было больше функций, связанных с отправкой сообщений. В результате небольшая пользовательская база в считанные дни выросла до 250 000 человек, доказав, что разработчики на верном пути.
Преимущества MVP
Таким образом, минимально жизнеспособный продукт позволяет:
Разновидности MVP
Среди многочисленных подходов к созданию Minimum Viable Product выделяют три основных подхода.
1. Продукт с единственным параметром
Наиболее распространенный вариант создания MVP уже был описан на примере WhatsApp. Это приложение или программа, выполняющие одну-две функции, которые необходимы для проверки жизнеспособности вашей идеи. Если основная функциональность приложения неинтересна пользователям, то продолжать вкладывать в разработку силы, время и ресурсы бессмысленно.
2. Разрозненный MVP
Этот подход применяют, если идею продукта можно реализовать без разработки уникальных программных решений, при помощи набора готового программного обеспечения.
Объединение различных инструментов в единый комплекс и, тем более, разработка оригинального ПО — делают тестирование бизнес-идеи трудозатратным и дорогостоящим. Иногда к этим стадиям разработки стоит переходить уже после получения обратной связи от пользователей.
Так запустился сервис Groupon. На старте он представлял собой лишь примитивный сайт на основе открытого исходного кода. Все услуги Groupon оказывал по электронной почте. Социальные функции, полноценная email-рассылка, автоматизация, мобильное приложение — все это было разработано потом, когда стало ясно, что коллективные покупки востребованы.
3. Волшебник страны Оз и консьерж
Эти близкие разновидности Minimum Viable Product подразумевают отказ от длительной и дорогостоящей разработки в пользу ручного труда.
Герой сказки Фрэнка Баума (Lyman Frank Baum) изображал из себя волшебника, а MVP этого типа притворяются полнофункциональными сервисами и приложениями. На деле же, вместо алгоритмов работу Minimum Viable Product обеспечивают люди.
Волшебник страны Оз не афиширует этот факт. Так поступал основатель Zappos — крупного американского интернет-магазина. Чтобы убедиться в жизнеспособности идеи, он начал продажи задолго до того, как автоматизировал заказы и даже арендовал склады. Первых клиентов Ник Свинмурн (Nick Swinmurn) обслуживал лично, приобретая товары со скидками в рознице и перепродавая их.
Отличие продуктов, построенных по консьерж-модели, в том, что они открыто позиционируются, как предоставляющие услуги реальных людей, и используют этот факт, как одно из конкурентных преимуществ.
Создание MVP: пошаговое руководство
Чтобы запустить минимально жизнеспособный продукт, необходимо пройти через восемь подготовительных этапов. Первые четыре шага нацелены на предварительное уточнение бизнес-идеи. Пятый и шестой этапы касаются проектирования продукта, и только на седьмом и восьмом пунктах дело дойдет непосредственно до разработки и тестирования.
1. Сформулируйте задачу
Каждый продукт создается для решения некой задачи, и речь не о получении прибыли. Здесь требуется клиентоориентированный подход. Для чего пользователю нужен продукт?
Внятно сформулировав ответ, вы получите представление о задаче продукта и о его ценности для пользователя. Так, открывая сервис для краткосрочной аренды парковочных мест, вы решаете проблему, с которой сталкиваются все водители, — облегчаете поиск места, где можно оставить машину.
2. Определите аудиторию и выделите ее ядро
Ориентироваться на потребности широкой аудитории при проектировании MVP — ошибочная стратегия. Сужение целевой аудитории позволяет точнее ориентировать будущий продукт. Для этого необходимо сформулировать портрет «идеального» пользователя, человека, который без раздумий купит ваше решение и останется доволен его возможностями.
Обычно в такой портрет включают информацию о возрасте пользователя, уровне образования, доходах, привычках, интересах и увлечениях. Эти детали необходимы, чтобы понять, насколько хорошо продукт подходит будущему пользователю, и помогут позднее, на этапе рекламы и продвижения.
3. Изучите конкурентов
Даже если вы придумали нечто новое, найдутся компании, которые уже действуют в выбранной отрасли. Их опыт, преимущества и недостатки стоит внимательно изучить. Выясните, какова их доля на рынке, зачем к ним приходят клиенты и что делает их уникальными. Эти подробности помогут скорректировать MVP.
4. Проведите SWOT-анализ
Этот метод стратегического планирования используется крупными компаниями для принятия управленческих решений и формирования бизнес-политики с 1963 года. И хотя обычно он используется в куда большем масштабе, SWOT-анализ хорошо подходит для определения сильных и слабых сторон, возможностей и угроз для минимально жизнеспособного продукта.
5. Составьте карту путей
После фундаментального анализа бизнес-идеи самое время взглянуть на будущий продукт с точки зрения пользователя. Карта путей — тот порядок действий, который пользователь совершает, чтобы достигнуть своей цели, например, приобрести товар или найти и арендовать парковочное место.
Этот путь должен быть не просто максимально коротким, но и простым и удобным. Продумав, как пользователь взаимодействует с будущим приложением, вы поймете, на какой стадии предоставить дополнительную информацию, где добавить подсказку и как оптимально спроектировать интерфейс.
6. Выделите основные функции для реализации и рассчитайте объем MVP
Каким бы масштабным ни был задуманный проект, для MVP необходимо перечислить и приоритезировать его функции. При создании Minimum Viable Product предпочтение отдается тем из них, что непосредственно связаны с основной целью будущего продукта.
Введение дополнительных возможностей в прототип только запутает пользователей и снизит достоверность результатов исследования бизнес-идеи. Их можно добавлять уже после развертывания MVP, сбора и анализа первичной обратной связи.
7. Выберите подходящую методологию и разработайте MVP
Определив объем, порядок и направление работ, можно приступить к разработке минимального жизнеспособного продукта.
От того, как именно будет построен процесс разработки, во многом зависит результат. Для MVP принципиально важно использовать один из итеративных подходов к разработке. Lean, Scrum, Kanban, экстремальное программирование — все они позволяют наладить регулярный выпуск обновлений, совершенствовать продукт «на ходу», по мере поступления обратной связи. Выбор конкретной методологии зависит от предпочтений команды разработчиков и особенностей конкретного проекта.
8. Протестируйте продукт
Минимально жизнеспособному продукту требуется регулярное тестирование на всем протяжении разработки. Альфа-тестирование проводится внутри команды силами тестировщиков, но для бета-тестирования потребуется помощь посторонних. Хорошо, если это будут люди из числа будущих пользователей. Желающих поучаствовать в тесте можно найти на таких сайтах, как BetaList, ProductHunt, Reddit, Quora или привлечь через собственные каналы связи: социальные сети, блоги и email-рассылку.
Основной задачей тестирования будет техническое совершенствование MVP. Перед выпуском продукт должен работать без ошибок, чтобы проблемы технического характера не помешали пользователям оценить его функциональность.
Запуск минимально жизнеспособного продукта
Для команды проекта работа еще только начинается. С момента запуска необходимо собирать, сохранять и анализировать обратную связь, начиная со статистики и заканчивая данными о поведении и отзывами пользователей. Эта информация — то, ради чего все затевалось.
Данные, собранные при помощи MVP, позволят понять, есть ли у проекта перспективы, помогут сгенерировать новые идеи и разработать стратегию развития продукта, основанную, не на предположениях, а на фактах. Таким образом, MVP тестирование полностью себя оправдает.
Наш опыт позволяет нам оценивать полученные данные и анализировать фидбек от клиентов. Мы понимаем, что запустить MVP, протестировать продукт и обработать обратную связь — сложные и затратные задачи, которые требуют профессионального подхода.
Если вы запускаете новый продукт и не знаете с чего начать — свяжитесь с нами через форму обратной связи, и мы поможем реализовать ваш проект.
MVP: что это такое и как работает?
Читая новости про проекты и сервисы, вы могли часто сталкиваться с понятием MVP. Но что скрывается под этой аббревиатурой и почему MVP так часто используют на начальных этапах развития продукта? Давайте прямо сейчас вместе разберемся в этом.
Что собой представляет MVP
Minimal Viable Product (минимально жизнеспособный продукт) — тестовая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.
MVP создают для тестирования гипотез и проверки жизнеспособности задуманного продукта, насколько он будет ценным и востребованным на рынке.
Результаты тестирования минимально жизнеспособного продукта и обратная связь от целевой аудитории помогают понять, стоит ли развивать проект дальше, какие изменения следует внести в стратегию, а что оставить в первоначальном виде.
В 2008 году, когда аренда отеля или жилья во время путешествия была большой проблемой, два энтузиаста решили подойти к вопросу нестандартно и сдали свою квартиру по простому факсу. По сути, это тоже MVP, в котором тестировалась основная функция. Эксперимент показал, что продукт получит спрос, а сегодня Airbnb — одна из крупнейших площадок по поиску краткосрочной аренды жилья.
MVP и PoC — одно и то же?
Proof of Concept (PoC) — доказательство правильности концепции и некоторые новички часто путают его с минимально жизнеспособным продуктом. PoC описывает процессы выяснения технической жизнеспособности концепции программного обеспечения (или любого другого продукта).
Да, эти определения взаимосвязаны, но не взаимозаменяемые. Proof of Concept — описание процессов на начальной стадии развития продуктов, которые потом реализуются фактически, из чего получается MVP.
Виды MVP
Есть много разных подходов к созданию минимально жизнеспособного продукта, но на практике чаще всего используют некоторые из них. Далее поговорим о наиболее популярных.
MVP Флинстоуна
Помните, как в популярном мультике «Флинстоуны» глава семейства создавал иллюзию передвижения на автомобиле? Так вот, этот подход предусматривает имитирование наличия функционала, хотя на самом деле технически он никак не реализован. MVP нацелен на проверку гипотезы, доказательство жизнеспособности выбранной модели развития бизнеса.
Он сделал сайт и опубликовал фото разных моделей обуви. Получил заказ, пошел в магазин, приобрел нужную пару и отправил покупателю. Так он проверил жизнеспособность идеи продаж обуви через интернет, при этом изначально он не тратил деньги на аренду склада и закупку продукции, а лишь имитировал их наличие.
Консьерж MVP
Эта методология больше подходит для онлайн-сервисов, конечная цель которых — автоматизировать решение проблем целевой аудитории. На начальных этапах реализации продукта услуга оказывается вручную.
Например, мы хотим сделать сервис по финансовому учету и планированию для физических лиц. Но чтобы проверить, будет ли пользоваться спросом эта идея, сначала сделаем несколько финансовых планов для клиентов вручную через Excel. Так мы сможем понять, кто и сколько готов платить, какие функции нужно реализовать в первую очередь и т.п. Часто консьерж MVP помогает в генерации новых идей, которые впоследствии делают конечный продукт лучше.
Эту модель в конце 90-х годов использовал Чак Темплтон — основатель сервиса по онлайн-бронированию ресторанов, билетов и многого другого. Он не стал сразу вкладывать сотни тысяч долларов в техническую реализацию сервиса, а бронировал для других людей столики в ресторанах вручную. Так он проверил жизнеспособность идеи, понял, кто, сколько и за что готов платить и познакомился с целевой аудиторией.
Разрозненный MVP
Метод разрозненного MVP используют, когда идею можно проверить и реализовать без разработки уникального программного обеспечения. Вместо этого собирают готовые инструменты, объединяют в одну систему и преподносят в едином интерфейсе.
Если бы все компании начинались с разработки уникальных решений, которая обходилась бы в сотни тысяч долларов, мы бы не увидели много крутых проектов. К этому, как правило, переходят после запуска, получения обратной связи и первых результатов.
Посмотрите на популярный сервис совместных покупок Groupon. Когда-то он был простеньким сайтом на WordPress, где все взаимодействие с пользователями осуществлялось по электронной почте. Только после получения первой обратной связи и финансовых результатов были разработаны социальные функции, полноценная email-рассылка, автоматизация и мобильное приложение.
Продукт с одним параметром
Эту разновидность используют чаще всего, когда есть готовый продукт с минимальным набором функций (как правило, одной). По такому принципу действовали основатели Spotify, которых упомянули в начале статьи.
Выпуск продукта с одной функцией (параметром) позволяет сузить целевую аудиторию, получить обратную связь и проанализировать ее, после чего приступить к тестированию.
Когда и для чего нужно делать MVP?
Приступайте к разработке MVP на начальных стадиях развития продукта. Идея может быть крутой только у вас в голове (да, такова уж суровая реальность), так зачем сразу вкладывать большие деньги в разработку, когда есть вариант с маленькими затратами и точной проверкой? После выпуска минимально жизнеспособного продукта вы определите спрос и поймете, в правильном направлении развиваете проект или нет.
Но самое крутое в MVP — сбор ценной информации от первых пользователей. Именно конечный потребитель расскажет о правильной реализации проекта. Собранные данные используйте для планирования дальнейших обновлений и определения наиболее приоритетных целей: какие функции реализовать в первую очередь.
Как сделать MVP правильно
В теории вы узнали, что такое минимально жизнеспособный продукт, теперь поговорим о практической части — создании MVP. Для получения хорошего результата разложите работу на мелкие итерации (шаги/этапы), обозначьте цели для команды в целом и задачи для каждого члена. Но в первую очередь донесите до коллектива общие принципы работы и создания продукта.
Нулевой этап: определяем основные принципы создания MVP
Проведите общее собрание коллектива, который примет участие в разработке MVP. На нем вы должны разобраться, все ли члены команды понимают, зачем это нужно. Обсудите видение минимально жизненного продукта, сложите все воедино и постройте первый примерный план дальнейшей работы.
В ходе общего собрания обсудите следующие вопросы:
Первый этап: поиск проблемы, которую решит MVP
После определения основных принципов MVP, ответьте на вопрос: «Какую проблему решает продукт?». Опишите его ценность в нескольких предложениях. Во-первых, это полезно для себя и команды, во-вторых, в дальнейшем поможет в создании уникального торгового предложения, лендинга и рекламной кампании.
Например, создаем сервис по финансовому планированию для физических лиц. Он решает проблему «бесконтрольного расходования денежных средств, помогает организовать бюджет и ставить долгосрочные цели».
Второй этап: находим целевую аудиторию
Распространенная ошибка начинающих продактов и предпринимателей — они считают, что их проект решает проблему широкой аудитории (всех людей). Такой подход в разы повышает вероятность провала. Сфокусируйтесь на определенной целевой аудитории.
Составьте портрет клиента, который обязательно купит продукт. Опишите его пол, возраст, социальное положение, уровень дохода, потребности, привычки, используемую им технику, распространенные проблемы, предпочтения в отдыхе и т.п.
Не торопитесь на этом этапе! Лучше потратить несколько часов для формирования портрета ЦА, чем потом «слить» весь рекламный бюджет и получить минимальную конверсию. И не забывайте про то, какую проблему решает MVP (это определяется на первом этапе).
Пример с сервисом по составлению финансовых планов для физических лиц:
Третий этап: определяем основных конкурентов
Не думайте, что ваш продукт (идея) уникален и такого больше нигде нет. Если вы с ним не сталкивались лицом к лицу, это не гарантирует уникальность. И вообще есть гипотеза «множественного открытия»: все исследования и изобретения делаются сразу несколькими учеными независимо друг от друга.
Эту гипотезу подтверждает история с разработкой радио. В России считают, что его изобрел Александр Попов, а вот в Италии лавры отдают Гульельмо Маркони. Оба начали работать над реализацией идеи в 1894 году, но Попов свою разработку презентовал в марте 1896 года (но при этом не запатентовал), а Маркони в июне 1896 года подал документ на патент. Кстати, есть еще несколько ученых в разных странах, которые также претендуют на звание «создатель Радио».
История с MVP аналогичная: вы должны потратить немало времени, но постараться найти конкурентов. Вам повезет, если идея все-таки окажется уникальной, а если нет, тогда решите следующие задачи:
Для удобства советуем составлять сводную таблицу со всей собранной информацией. Впоследствии будет проще ориентироваться в больших массивах данных и принимать какие-либо решения.
Четвертый этап: проводим SWOT-анализ
SWOT-анализ представляет собой таблицу, состоящую из четырех блоков:
Не расписывайте пункты на целые абзацы. Они должны быть короткими и понятными для всей команды.
Обратите внимание, что таблица разделена на две части. Сильные и слабые стороны, как правило, относятся к внутренним факторам, а возможности и угрозы — к внешним.
Цель SWOT-анализа выявить сильные стороны и возможности, чтобы сосредоточить работу на них для минимизации негативных последствий от слабых сторон и угроз. Сделанные выводы помогут выбрать стратегию развития и позиционирования бизнеса на рынке.
Пятый этап: создаем карту пути пользователя
Простой блиц для определения удобства продукта: если вы сами не понимаете, что надо делать с вашим сервисом (продуктом, услугой и т.п.), то потребитель разобраться точно не сможет!
Чтобы избежать такого недоразумения, на пятом этапе создания минимально жизнеспособного продукта составляют карту пути пользователя — что делает пользователь при взаимодействии с продуктом. Вы должны понимать, какие у аудитории требования к контенту, дизайну, интерфейсу.
Кстати, не забывайте корректировать карту пути пользователя (user flow) после получения обратной связи от первых клиентов. Они расскажут, что хорошо, а что плохо или неудобно. На основе этого корректируйте карту, чтобы конечный потребитель получал то, что хочет.
Например, для сервиса по финансовому планированию сделали такую карту:
Шестой этап: составляем перечень функций продукта
На прошлом этапе вы определили основные взаимодействия пользователя с продуктом, теперь для каждого опишите конкретные функции. Для удобства составьте специальную карту: взаимодействия и функции для каждого. Сначала она выглядит так:
Дальше для каждого взаимодействия определяется перечень функций. Здесь помогут логика и пользовательские истории. В первом случае самостоятельно или вместе с командой подумайте, что нужно сделать для обеспечения того или иного взаимодействия.
Но как вы помните, наше видение часто искажено, а вот реальные пользователи дают объективную информацию на основе опыта. Пользовательские истории описывают те или иные действия людей, на основе которых определяются необходимые функции.
Дальше расставьте все функции по приоритету. Самые востребованные (которыми пользуются чаще всего) ставим в начало списка, редко используемые — в конец. Должна получиться вот такая карта:
Седьмой этап: определяем функции MVP
На этом этапе вы должны определить функционал MVP или иными словами — запланировать объем минимально жизнеспособного продукта. Для начала определите несколько основных функций, без которых проект вообще не сможет существовать, от него не будет никакого толку. Это — каркас или наименьшая полезная версия продукта.
Каркас как дом без отделки — вроде бы, жить можно, но как-то не очень. Поэтому в большинстве случаев MVP дополняют разными «полезностями». Для этого необходимо определить существенные и несущественные функции: какие нужны сейчас, а какие можно доработать потом в процессе развития проекта.
Опять же, классифицировать функции лучше коллективом. Обсуждения, споры, аргументация — это приведет к определению оптимального объема минимально жизнеспособного продукта. На карте выделите каркас и дополнительные функции в рамках MVP для удобства дальнейшего планирования. Должно получиться что-то наподобие этого:
Такую карту с объемом минимально жизнеспособного продукта можно сделать на компьютере или на магнитной доске, стоящей в переговорной или аналогичном помещении. В ходе разработки допускается внесение корректировок.
Восьмой этап: выберите метод управления и разработки
Вы готовы к началу работы: определена идея, задачи, цели объем MVP. Осталось выбрать модель управления для достижения максимальной эффективности и соблюдения установленных сроков разработки. Возможно несколько вариантов:
Девятый этап: проводите тестирования
Тестируйте MVP короткими итерациями: альфа- и бета-тестированием. Альфа — внутренний этап: закончили разработку, пользуйтесь продуктом внутри команды несколько дней. Если все окей, запускайте бета-тестирование — внешний этап, дайте доступ к проекту первым пользователям. Длительность: 7-14 дней.
После первой беты соберите отзывы, статистику посещений, аналитику поведений и проанализируйте весь массив данных. Так вы узнаете, что надо доработать, что можно убрать, а что, наоборот, надо добавить в срочном порядке.
Несколько итераций «разработка-альфа-бета» помогут прийти к оптимальной первой версии продукта, который можно выпускать на рынок для массового пользователя и продолжать дорабатывать.
Еще раз поговорим всю последовательность этапов:
Самые распространенные ошибки при создании MVP
Теперь вы знаете, как создать свой MVP. Но есть еще один момент: новички (им это простительно, кстати) часто допускают ошибки при планировании первых минимально жизнеспособных продуктов. На второй-третий раз, набравшись опыта, они работают быстрее и эффективнее.
Но зачем учиться на собственном опыте, когда есть чужой? Почему бы не использовать его и постараться избежать неточностей на своем пути? Поэтому далее поговорим о самых распространенных ошибках начинающих продакт-менеджеров и предпринимателей.
Попытки достигнуть идеала
Закройте в клетке своего перфекциониста, потому что в ходе разработки MVP он сыграет с вами злую шутку! Запомните, задача минимально жизнеспособного продукта — дать пользователю базовое представление о продукте, он априори не должен и не может быть идеальным.
Вы тестируете гипотезу! Поверьте, маленького MVP хватит для определения потенциала идеи. Если она крутая, то спрос на продукт не испортит даже плохой дизайн, интерфейс и минимальная скорость работы. И только при подтверждении этой гипотезы начинайте тратить ресурсы на юзабилити и красивый фантик.
Небрежная работа
Если MVP не должен быть идеальным, это не значит, что его можно делать, как попало. Некоторые продакты бросаются из крайности в крайность, в результате получает вообще что-то непонятное.
Минимально жизнеспособный продукт должен быть простым, но качественным. Например, если делаете сервис, то купите хотя бы домен второго уровня, не надо оставлять его на поддомене какого-то бесплатного конструктора.
Отсутствие обратной связи
Некоторые новички так увлекаются разработкой, что забывают о приоритетной цели — сборе обратной связи. Еще на стадии планирования следует определить ключевые метрики, которые покажут успешность проекта. Это может быть количество скачиваний или покупок, число новых пользователей, коэффициент удержания клиентов и т.п.
«Пустые» обещания
Когда «глаза горят», есть ощущение способности свернуть горы! И в такие моменты руководитель начинает делать анонсы крутых и необычайных возможностей. Конечно, это все здорово с точки зрения маркетинга, но если не сдерживать обещания, пользователи начнут покидать проект.
Поэтому всегда принимайте решения о новых анонсах на «холодную» голову. Объективно оценивайте, что сможете сделать, а что нет.
Отказ от анализа и аналитики
Окрыленность собственной идеей часто дурманит разум и вся команда перестает обращать внимание на объективные факты: плохие метрики, отрицательные отзывы и т.п. Начинают думать, что просто пользователи не все понимают сейчас, а вот когда финальная версия продукта будет готова, тогда они оценят.
Нет, не оценят. В этом деле всегда важен объективизм. Есть обратная связь от реальных пользователей, слушайте ее, корректируйте работу проекта в соответствии с желаниями конечных потребителей, иначе во всей этой суете нет никакого смысла.
Итак, подведем краткий итог: MVP — минимально жизнеспособный продукт, который делают для тестирования идей и гипотез, сбора обратной связи от первых потребителей (и да, MVP ≠ PoC). Реализовать можно за 10 этапов и постараться избежать наиболее распространенных ошибок. Если вы планируете создание нового продукта, начинайте с MVP: это позволит избежать больших ресурсных потерь в случае плохого потенциала идеи.