Минимально жизнеспособный продукт 📦 — что такое MVP проекта и продукта

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

Разработка продукта в его "совершенном виде" стоит дорого. Кроме того, вы не можете быть уверены в том, что это именно то, что нужно клиенту. Создание MVP позволяет снизить риски и начать быстрее получать обратную связь от заказчика.

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

Компания IMVU специализируется на создании электронных «аватаров» — картинок, посредством которых пользователи могут общаться между собой не напрямую, а через картинки своих персонажей.

На раннем этапе создания продукта команда получала обратную связь, что аватары должны двигаться (до этого была только картинка, которая никак не двигалась и не изменялась).

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

Команда решила вопрос следующим образом: ввести предположительно допустимый вариант движения — если пользователь кликал в какое–то место, «аватар» появлялся именно там, как бы телепортировался. Низкое качество? Похоже на это. Зато — дешево и быстро. И позволяет быстро получать обратную связь по качеству готового MVP.

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

И вот как оценил этот кейс в IMVU Эрик Рис:

Это простое решение, не потребовавшее особых затрат, оказалось для пользователей важнее многих других функций, которыми мы так гордились и на которые мы потратили гораздо больше времени и денег

Все мы стремимся создавать хорошие продукты. Если мы создадим что–то низкокачественное, то это будет угнетать. Как же так, неужели это все, на что можно было рассчитывать?

Больше всего смущает в минимально жизнеспособном продукте (MVP), так это то, что он не соответствует традиционным представлениям о качестве. В любой сфере деятельности настоящие профессионалы стремятся создавать качественные продукты и гордятся этим.

Многие современные подходы к созданию и управлению продуктами направлены на то, чтобы делать качественный продукт. Шесть сигм, бережливое производство, дизайн мышление, экстремальное программирование, и другие многочисленные технологии призваны сделать продукты лучше, качественнее.

Однако все меняется, когда мы начинаем говорить про стартапы. Здесь важно быстро и дешево сделать минимально жизнеспособный продукт, чтобы начать получать обратную связь от пользователей как можно раньше.

В основе идеи о разработке качественного продукта лежит один как минимум один важный тезис, одно важное допущение — мы уже знаем, чего хотят наши клиенты, что для них важно и ценно.

Когда идет речь о стартапе, такое допущение оказывается опасным. На начальных этапах разработки инновационного продукта мы даже не знаем, кто наши клиенты.

Эрик Рис предлагает «принцип качества», который отзывается нашей команде:

Если мы не знаем кто наш клиент, мы не знаем, что такое качество.

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

Все встает на свои места, если мы начинаем думать о том, что мы используем MVP как мост между отсутствием продукта и качественным продуктом. Без такого моста вероятность создания качественного продукта значительно снижается.

Клиенты часто относятся к продукту, находящимся на этапе MVP, довольно скептично, а иногда и с негодованием. «Как так? У вас же еще ничего не готово!»

Является ли это проблемой? На самом деле нет. Это возможность. Благодаря этой негативной обратной связи вы сможете понять, что важно для ваших клиентов. Другими словами, если качество продукта на этапе MVP вызывает негативную обратную связь, это значит, что минимальная работоспособность еще не достигнута.

Здесь есть риск сразу начать удовлетворять потребности пользователей. Например, пользователям кажется, что приложению просто необходимо какая–то функция. А вы понимаете, что её разработка требует большого количества времени и денег.

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

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

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

Качество продукта оценивает пользователь и только пользователь. Это важно для стартапа, важно для любой инновации. В конце концов, какая разница, насколько качественным вы считаете свой продукт, если люди им не пользуются, если он оказывается никому не нужен?

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

Продукт должен быть качественным ровно настолько, насколько нужно, чтобы привлечь клиентов.

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

Содержание:

1. Что такое MVP и каких типов бывает.

2. HADI — цикл.

3. Итеративная vs инкрементная разработка продукта.

4. Разные MVP на разных этапах развития проекта.

5. Ошибки при создании MVP

6. Примеры MVP

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

Согласно Эрику Рису (человеку, который написал книгу бережливый StartUp), MVP — это такая версия нового продукта, которая позволяет команде собрать максимальное количество валидированных(проверенных) данных о клиентах с наименьшими усилиями(вложениями).

Ключевая предпосылка идеи MVP заключается в том, что вы создаете реальный продукт (который может быть не более чем landing page, или сервис с видимостью автоматизации, хотя на самом деле под капотом все делается вручную), который вы можете предложить клиентам и изучить их реальное взаимодействие с этим продуктом или сервисом.

Увидеть, что люди реально делают с продуктом гораздо надежнее, чем спрашивать людей о том, чтобы они могли с ним делать.

2.

HADI–цикл

H — hypothesis — гипотеза

A — action — действие

D — data — данные

I — insights — инсайты/выводы

HADI–цикл в контексте создания MVP, являет собой довольно простой алгоритм по которому удобно итеративно проверять гипотезы и улучшать продукт.

PDCA–цикл — примерно то же самое, но в стартап тусовке принято про HADI говорить.

Цикл выглядит следующим образом:

Гипотеза:

Мы делаем предположения, гипотезы (желательно в метриках), какой эффект мы получим по окончании теста (временной интервал на тест обсуждаем и зависит от продукта), если изменим «то–то». Гипотезы и вообще все действия должны иметь определенную цель (бизнес цель, деловую цель).

Действие:

Мы делаем MVP продукта, выпускаем его на рынок.

Данные:

Мы собираем полученные данные в виде заявок, подписок, покупок и т.д.

Выводы:

Делаем анализ и выводы по полученным данным. Чтобы понять результат эксперимента (а это именно эксперимент) нам необходимо иметь те самые начальные гипотезы (в виде метрик) относительно которых мы и проверяем результат.

Важно!

Относитесь к этому, как к научному эксперименту. Все шаги и этапы должны быть записаны, чтобы всегда можно было узнать откуда взялись те или иные данные. Это важно, учитывая то, что HADI–циклы непрерывно повторяются один за другим и процесс улучшения продукта постоянно продолжается.

3.

Итеративная vs инкрементная разработка

Здесь все просто. Важно, чтобы MVP даже на самой первой стадии был продуктом — то есть выполнял(или обещал выполнить) работу для клиента, чтобы получать данные о продукте и улучшать его. Итеративная модель разработки помогает нам в этом.

4.

MVP на разных стадиях продукта

Можно выделить 3 стадии развития продукта, для которых имеет смысл сосредоточиться на разных сторонах MVP.

— Ранняя стадия. Customer Development. MPV создается за один день. Цель — найти первого клиента, получить обратную связь по продукту.

— Вторая стадия. Поиск каналов для продукта. Ищем пути к клиентам. Тестируем каналы. Находим 1-2 работающих канала. 1 — 10 дней.

— Третья стадия. Масштабирование. Автоматизация процессов. 1 — 2 месяца.

5.

Ошибки при создании MVP

• Игнорировать рынок

• Слишком вкладываться в создание MVP

• Пропустить фазу прототипирования

• Игнорировать обратную связь от пользователей

6.

Примеры MVP.

Zappos

Отличный пример тестирования гипотезы минимальными средствами.

В 1999 Nick Swinmurn почувствовал, что продажа обуви через интернет может сработать. Он не стал искать инвесторов. Он сделал простой сайт на котором разместил фотографии обуви с ценами из ближайшего магазина. Если приходил заказ, то Ник шел в магазин, покупал эту пару обуви и отправлял клиенту. Почитайте, кстати книгу основателя Zappos. Интересно и полезно!

Airbnb

В 2008 году, Brian Chesky и Joe Gebbia думали о том, как протестировать идею нового startup. Идея была проста, что есть рынок клиентов для людей, которые хотят сдать в аренду свои собственные дома. Они не стали идти классическим путем, вкладывая деньги в создание большого webсайта и договоров с владельцами домов. Они создали самый простой лэндинг с фотографиями своей квартиры. Это и был MVP, который позволил протестировать идею быстро, без вложений извне.

После трех оплаченных гостей они основали Airbnb и использовали средства с дохода, чтобы улучшить website дизайн и его функционал.

Uber

В 2008 году, Garret Camp и Travis Kalanick были недовольны ценами на такси в Сан–Франциско. Идея была в том, чтобы как–то соединять в пару водителя и пассажира, которому нужна поездка. В этот момент большинство предпринимателей начало бы создавать дорогостоящие приложения и websites. Ребята сделали самое простое приложение, которое работало толко под iPhone, через sms и только в городе Сан–Франциско. Это приложение помогло им доказать, что у их идеи есть рынок. Их MVP позволило им протестировать большие риски за небольшие деньги.

Спасибо, что прочитали статью!