MVP

MVP — это Minimum Viable Product, минимально жизнеспособный продукт. Так называется продукт, который еще не готов до конца, но который тем не менее уже можно выпускать на рынок.

Что такое MVP

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

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

Для чего MVP нужен бизнесу

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

Оценка потенциала. С помощью MVP создатели могут оценить, насколько идея жизнеспособна: как ее восприняла аудитория, оказался ли продукт нужен людям, реально ли его поддерживать и как это лучше сделать. По итогам можно сделать вывод, стоит ли развивать проект дальше.

Снижение рисков. MVP стоит дешевле, чем конечный продукт. Если пользователи не оценили идею, можно изменить направление развития сразу и не уйти в минус из-за огромных затрат на ненужный продукт.

Экономия средств. MVP — это относительно недорого, а прибыль от него можно начать получать сразу. Продукт выходит на рынок не совсем готовым, но уже работает и может приносить доход. А еще это способ сэкономить на аналитике: вместо нее можно сразу посмотреть, как идея работает непосредственно на рынке.

Направление развития. MVP позволяет сразу увидеть, куда стоит развиваться дальше, где у идеи слабые места, которые лучше закрыть в первую очередь, а что стоит оставить как есть. Реальный пример: в рамках тестирования MVP сервиса Airbnb создатели быстро поняли, что людей отпугивают некачественные фотографии жилья под сдачу. И ввели правило, согласно которому фото должны быть качественными, — и сами начали помогать делать такие фотографии.

Привлечение инвесторов. Благодаря MVP проектом могут заинтересоваться инвесторы. Для них перспективнее вложиться в продукт, который уже работает, чем в абстрактную идею, которая никак не доказала свою состоятельность. А с помощью инвестиций можно привлечь средства для дальнейшего развития продукта. Пример — сервис доставки продуктов «Сбермаркет»: изначально это был стартап под названием «Инстамарт», но благодаря удачному MVP проектом заинтересовался Сбер.

Примеры успешных MVP

Многие продукты, которые сейчас всемирно известны, когда-то начинали как MVP со скромной функциональностью. Несколько примеров:

• сервис для поиска жилья Airbnb начинался с простейшего сайта-одностраничника, с помощью которого создатели сдавали собственный чердак;
• музыкальное приложение Spotify когда-то было простым MVP, который умел только потоково передавать музыку. Сейчас программа известна своими умными алгоритмами подбора мелодий и другими многочисленными фишками;
• популярный мессенджер WhatsApp* тоже начинал как MVP — своего рода телефонная книга, где показывалось, в сети ли контакт;
• российский маркетплейс Wildberries вырос из примитивного интернет-магазина одежды из-за рубежа, которая продавалась с меньшей наценкой, чем обычно.

Особенности MVP

Функциональность. MVP — это функциональный продукт, которым можно пользоваться. Пример из быта: тесто — это еще не MVP. Простые булочки, испеченные из этого теста, — MVP: их можно съесть или предложить кому-то за деньги. А потом продукт можно дорабатывать: экспериментировать с начинками, добавлять специи и посыпки. Но главное — чтобы начальным продуктом можно было пользоваться.

Минимум затрат. Идея MVP — функциональность при минимальном количестве временных и финансовых затрат. Если без какой-то функции можно обойтись, она пока что откладывается в сторону. Разработчики концентрируются только на основной идее: той, без которой продукт просто не может работать. Продолжая пример с булочками: если нет нужды сразу делать их с начинкой — лучше отложить это на потом и выпекать простую сдобу.

Синхронная разработка. Для создания успешного MVP нужно исследование целевой аудитории. Об этом говорил автор самого термина MVP, сооснователь SyncDev Фрэнк Робинсон. Он считал, что минимально жизнеспособный продукт — результат синхронной разработки. То есть команда одновременно разрабатывает продукт и исследует рынок и благодаря этому выпускает нужный людям MVP.

Проверка идеи, а не технологии. MVP не обязательно должен быть чем-то сверхсложным с точки зрения технологий. Даже наоборот: ранняя реализация может быть совершенно примитивной, но показывать пользователям новую идею. Например, это может быть простейший сайт на WordPress, но предлагающий что-то новое — скажем, заказ продуктов через интернет в короткие сроки.

Кто создает и развивает MVP

Созданием самого продукта занимается команда разработчиков, тестировщиков и других специалистов. Процессом управляют продуктовые менеджеры, задача которых — решить, что будет включать в себя MVP и как это будет выглядеть. Впрочем, в стартапах редко собирается команда специалистов с четко обозначенными обязанностями: часто вся компания состоит из 2–3 человек, каждый из которых берет на себя несколько ролей. А некоторые стартапы — и вовсе проекты одного человека.

Чем MVP отличается от похожих понятий

Минимально жизнеспособный продукт часто путают с похожими терминами из бизнес-разработки: например, с прототипом или PoC. Разберемся, в чем разница.

Прототип

MVC и прототип — тестовые версии для проверки какой-то идеи, в этом сходство. Но прототип — это не готовый продукт, его нельзя выводить на рынок и полноценно пользоваться. Это более узкое понятие: прототип делают не для продукта целиком, а для проверки конкретной технологии. Например, компания хочет выпустить велосипед с усовершенствованным механизмом руления. Прототипом будет модель самого механизма руления, а MVC — самая примитивная версия полноценного велосипеда.

PoC

PoC — это Proof of Concept, или доказательство концепции, то есть проверка, насколько идея жизнеспособна. Это более ранний этап развития, чем MVC: для реализации PoC вообще не обязательно создавать продукт. Например, доказательством могут послужить предзаказы или активный сбор на проект с помощью краудфандинга. Если людям интересно, значит, проект им нужен и, следовательно, жизнеспособен. Яркий пример тут — Dropbox: когда-то они выпустили презентацию не существующего еще сервиса и получили 75 тысяч подписчиков. Это послужило аргументом в пользу того, что сервис нужен людям.

Виды MVP

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

Однофункциональный. MVP, который выполняет одну заявленную функцию, а дополнительных у него пока что нет. Эта единственная функция, на которой концентрируется продукт, и есть реализация основной идеи. Такой подход сужает целевую аудиторию, зато помогает оценить перспективу и обратную связь, заложить фундамент на будущее. По такому принципу развивались Spotify и WhatsApp*. Обычно его используют, если есть какой-то в своем роде уникальный продукт, уже готовый, но еще довольно простой и нуждающийся в обкатке.

Разрозненный. MVP, который состоит из множества простых деталей, образующих сложную систему. Такой продукт собран из готовых решений и плагинов, которые вместе составляют что-то интересное. Это помогает обойтись без дорогостоящей разработки сложного уникального софта на ранних этапах. Подход используют, если идея — какой-то сложный сервис с множеством параметров. Например, этот тип MVP использовал сервис скидочных купонов Groupon: поначалу там был только простой сайт на WordPress, email-рассылка без автоматизации и еще несколько готовых компонентов. Зато потом система стала сложной и куда более продвинутой.

Консьерж. MVP, в котором якобы автоматические процессы на первых этапах выполняются вручную. Готовый продукт должен что-то автоматизировать, но на этапе MVP вместо алгоритмов работают люди. Алгоритмы дорабатываются уже потом. Ведь их разработка может обойтись дороже, чем наем специалиста на первое время, — а пока нужно проверить гипотезу, и таких расходов желательно избежать. Скажем, в Америке был сервис бронирования билетов, который начинал работу именно по такой модели. Владелец принимал заявки на бронирование и вместо автоматизации сам руками бронировал билеты, а потом отправлял заказчику. Сервис достиг успеха, и в 2014 году его за два миллиарда долларов купила компания Booking Holdings — владелец одноименного сайта.

Флинтстоун. «Флинтстоуны» — это мультфильм о приключениях семьи в каменном веке. У главы семьи был «автомобиль», который фактически не работал: чтобы машина двигалась, нужно было бежать самостоятельно. Примерно так работает этот тип MVP, который еще называют «Волшебником из страны Оз» — тот тоже имитировал магию.

Это MVP, который только притворяется полноценным продуктом. На самом деле создается только оболочка, а все заявленные функции на первое время имитируются. Например, интернет-магазин обуви Zappos изначально работал как флинтстоун-MVP: создатель просто покупал обувь в обычных магазинах и отправлял заказчикам. У него не было ни своего склада, ни отлаженных процессов. Он просто хотел доказать, что обувь можно покупать через интернет. Кстати, сейчас Zappos стоит больше 2 миллиардов долларов и давно уже работает как полноценный маркетплейс обуви.

Как запустить MVP

При создании нового продукта начать с MVP часто выгоднее и удобнее, чем сразу делать большой и дорогостоящий проект. Но минимально жизнеспособный продукт тоже нужно делать правильно: иначе получится или неминимальный, или нежизнеспособный. Соответственно, никаких преимуществ неправильный MVP не даст.

Специалисты советуют делить создание MVP на этапы и выполнять их последовательно — пусть результат предыдущего этапа помогает на следующих.

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

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

Определить ЦА. Сразу делать продукт для широкой аудитории ошибочно — это повышает риски прогореть, ведь угодить всем невозможно. Поэтому сначала стоит отобрать основную целевую аудиторию, составить ее портрет и разрабатывать MVP под ее нужды и привычки.

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

Провести SWOT-анализ будущего продукта. Анализ состоит из четырех пунктов: сильные стороны, слабые стороны, возможности и угрозы для продукта. У него есть определенная методология проведения, и его лучше проводить или всей командой, или хотя бы ее основной частью.

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

Определить основные функции MVP. Можно посмотреть на карту пути и по ней сделать вывод, какие функции нужны для продукта. Они должны помогать решить основную задачу. Каждый шаг в карте — своя функция или набор функций. Сначала лучше продумать все функции полноценного продукта, потом нужно будет отобрать из них основные — те, которые стоит реализовать в MVP.

Разработать MVP. Разработка обычно проходит быстро, и в процессе используют готовые решения, применяют гибкие методологии и экономят ресурсы. Часто пользуются Scrum или экстремальным программированием, могут также применять Lean-методологию или канбан. Выбрать методику важно: если организация процессов будет неподходящей, все развалится еще до выхода на рынок.

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

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

Подробнее про создание MVP вы можете узнать на наших курсах. Станьте специалистом в современной отрасли: максимум практики, минимум скуки!

* Принадлежит корпорации Meta, которая признана экстремистской и запрещена на территории РФ.