Несмотря на то, что термин «минимально жизнеспособный продукт» или сокращенно «приложение MVP» был популяризирован Эриком Райсом в его книге «Экономичный стартап» почти десять лет назад, все еще существует путаница относительно того, что такое MVP, а что нет. Например, некоторые люди путают MVP с различными инструментами для проверки идей, такими как прототипы, а другие думают, что что-то «новое и незрелое» эквивалентно приложению MVP, что не всегда верно. В этой статье постараемся кратко познакомить вас с концепцией приложения MVP и сравнить ее с некоторыми другими методами проверки.

Чтобы глубже понять определение MVP и всю концепцию, давайте сначала поговорим о том, зачем нам вообще нужна валидация. Затем мы пытаемся выделить некоторые другие методы проверки, такие как Proof of Concept и Prototype. После этого мы перейдем к причинам, по которым спустя почти 10 лет термин «MVP» по-прежнему является модным словом. Также мы обсудим несколько примеров различных подходов к MVP. В конце концов, мы кратко рассмотрим новый начинающий проект - Minimum Lovable Product (MLP).

Способы проверки ваших предположений

По словам профессора Гарвардской школы бизнеса Клейтона Кристена, 95% новых продуктов для клиентов, запускаемых каждый год, в конечном итоге обречены на провал. Редко причиной неудач является отсутствие настойчивости, навыков или удачи (хотя они иногда так же имеют место), а скорее сам продукт, а точнее:

1. Во-первых, в продукте не было необходимости.
2. Необходимость отпала еще до того, как продукт вышел на рынок.
3. Стоимость и время создания продукта превысили первоначальные предположения.
4. Хотя потребности рынка были удовлетворены, ожидания клиентов не оправдались.

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

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

Доказательство концепции (PoC)

Цель: проверить техническую осуществимость идеи.

Основная цель PoC - проверить, является ли идея технически осуществимой и стоит ли ее развивать. Речь идет не о том, чтобы узнать, что ваши пользователи хотят или не хотят, или о том, есть ли спрос на решение, а скорее о том, возможно ли и стоит ли реализовать идею с технической точки зрения. В конце концов, вы же не хотите  развивать идею, реализация которой оказывается в 10 раз сложнее (и дороже), чем вы изначально ожидали. Это может быть быстрая проба для разработки бета-версии самого рискованного технологического допущения или просто более глубокий анализ имеющихся технических возможностей. Proof of Concept обычно не передается конечным пользователям и используется как внутренний инструмент.

Основные особенности PoC:

1. Снижает риск вовлечения в невыполнимые проекты.
2. Позволяет улучшить планирование прототипов / MVP.
3. Для внутреннего использования, иногда передается инвесторам.
4. Бюджетный.
5. Не проверяет востребованность идеи.
6. Помогает оценить стоимость внедрения.
7. Не растянутость во времени.

Прототип

Цель: дешево собрать раннюю обратную связь.

Создание прототипов показывает нам, как продукт будет выглядеть после разработки. В то время как PoC больше фокусируется на скрытой части, прототипирование больше касается части UX / UI. Цель состоит в том, чтобы без больших затрат построить простую экспериментальную модель идеи для тестирования и проверки концепции перед инвестированием в реальный продукт. Практически все может быть прототипом - макеты на бумаге, цифровая демонстрация, презентация в PowerPoint, имитирующая сайт, и многое другое. Способность получить обратную связь на раннем этапе и на раннем этапе найти лазейки в идее может стать решающим фактором успеха продукта.

Основные характеристики прототипа:

1. Недолговечный
2. Сосредоточен на общей идее и частях UX / UI.
3. Можно создать прототип всего продукта или только его части.
4. Позволяет получить раннюю обратную связь.
5. Бюджетный.
6. Значительно снижает риск создания нежелательной продукции.

Минимально жизнеспособный продукт (приложения MVP)

Цель: запустить продукт как можно скорее и с минимальными затратами, проверить предположения, собрать отзывы пользователей и повторить.

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

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

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

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

Основные характеристики MVP:

1. Среднестатистический.
2. Средняя стоимость (дороже прототипа, дешевле полного продукта).
3. Реальный продукт на рынке.
4. Создание MVP позволяет проверять предположения без создания всего продукта.

Типы MVP

Идея MVP может звучать как «версия продукта, лишенная большинства функций». Хотя по сути это правда, существует несколько подходов к развертыванию MVP, и вычеркивание большинства функций - не единственный (если даже осуществимый) способ. Давайте рассмотрим несколько примеров, чтобы понять, как работает MVP.

Волшебник страны Оз

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

Если вы читали роман, вы, вероятно, знаете, почему е него такое название, а если нет, то предупреждаем о спойлере - страшный волшебник на самом деле просто старый аферист, который все время сидит за кулисами и дергает за рычаги, как в случае нашего приложения для собачников. Это отличный способ собрать отзывы и проверить свой тезис, прежде чем вкладывать деньги в дорогостоящее программное обеспечение.

Консьерж

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

Волшебник страны Оз vs Консьерж - такие похожие, но такие разные.

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

По частям

Несмотря на то, что специально разработанное программное обеспечение почти всегда является лучшей идеей, для проверки гипотезы и получения ранней обратной связи может быть разумным решение использовать уже существующие решения. Самый яркий пример поэтапного MVP - Groupon. Компания, которую мы знаем сегодня, представляет собой огромную экосистему со встроенными платежами, почтовыми системами, генераторами купонов и т. д., Но все начиналось иначе. Они использовали уже существующие решения и соединили их, создав маленького Франкенштейна. Они использовали WordPress для управления своими сайтами, а сообщения WordPress выполняли роль предложений, купоны создавались FileMaker, а автоматическая рассылка осуществлялась через Apple Mail. Хотя смешивание такого количества различных решений не является масштабируемым долгосрочным решением, этого было более чем достаточно, чтобы привлечь первых клиентов и получить от них бесценные отзывы.

Smoke-test / Landing Page

При таком подходе мы не предоставляем рабочий продукт. Идея состоит в том, чтобы создать простой веб-сайт, часто просто с целевой страницей, которая описывает ценностное предложение продукта и имеет четкую кнопку с призывом к действию, например, для покупки услуги. После нажатия кнопки CTA пользователь часто получает сообщение о том, что продукт еще не доступен, но можно войти в список рассылки / сделать предварительный заказ услуги. Это отличный способ оценить потенциальный интерес клиентов и подтвердить / опровергнуть гипотезу о необходимости продукта на рынке.

Ведутся дискуссии о том, следует ли рассматривать этот подход как MVP - в конце концов, у вас нет рабочего продукта. Тем не менее, он соответствует критериям «создайте новый продукт, который позволяет команде собрать максимальное количество подтвержденных сведений о клиентах с наименьшими усилиями».

И многое другое…

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

Как определить свой MVP?

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

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

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

Когда вы подумываете о создании собственного минимально жизнеспособного продукта,  удалите любую функцию, процесс или усилия, которые не способствуют непосредственно желаемому вами обучению. - Эрик Райс, Lean Startup

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

Причины, почему вам нужно создавать приложение MVP?

Пора торговать

Время вывода продукта на рынок - один из наиболее важных факторов, определяющих успех или неудачу продукта. Слишком долгое время разработки считается самым большим препятствием, когда речь идет о повышении рентабельности инвестиций в новый продукт (Источник: BCG Global Innovation Survey, 2015). Подумайте только, рынок динамично меняется, ежедневно появляются десятки новых продуктов и меняются тенденции. То, что сегодня кажется популярным, может полностью устареть через год, но иногда люди решают потратить годы на создание экспериментального продукта, просто чтобы понять, что он больше не нужен.

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

Цикл проверки-построения-измерения-изучения

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

Снижение риска и затрат

Сосредоточение внимания на наиболее важных источниках ценности и сокращение времени вывода на рынок не только значительно увеличивает шансы на успех, но также снижает общие затраты на разработку и риски проекта. Запуск MVP может стоить всего 5-10% от стоимости полного решения, и он начинает приносить доход с первого дня. Вы уменьшаете риск неправильного понимания своих клиентов, а если вы неправильно истолковали их потребности, то вы узнаете это быстро. Возможность запустить продукт в течение недель, а не лет снижает риск изменения рынка. А в худшем из возможных сценариев, когда ваш продукт полностью не соответствует рынку и потребностям клиентов, вы рискуете потерять эти 5-10% стоимости MVP, а не годы разработки полного продукта.

Не слишком увлекайтесь

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

Шанс запустить продукт с небольшим капиталом

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

Как «MVP» - одно из наиболее часто употребляемых слов при разработке продукта.

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

Минимальный привлекательный продукт (MLP) - MVP, выведенный на новый уровень?

Хотя несколько лет назад сам MVP был лидером в разработке продуктов, сегодня все меньше веры в то, что такого подхода к продукту достаточно. MVP - это здорово, когда кто-то запускает инновационную идею с неподтвержденным тезисом, но хотя десять лет назад такие решения, как Uber, Shopify, Amazon, PayPal и т. д., были чем-то совершенно новым и инновационным на рынке, в 2020 году их было более 100000 новые приложения выпускаются каждый месяц только в Google Play, конкуренция высока, а шансы обнаружить что-то новое на рынке невелики. Компании часто предпочитают улучшать и настраивать существующую идею, придавая ей какое-то конкурентное преимущество, и запуск MVP может быть не вариантом - переключитесь ли вы со Spotify на минимальную версию, лишенную большинства функций и UX, только из-за нескольких новых незначительных функций? Возможно нет.

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

Итог (он же - давайте создадим MVP!)

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

Разработка MVP - один из наиболее известных методов доставки мобильных приложений и веб-систем. Это позволяет быстро вывести продукт на рынок при низких затратах и рисках и, если все сделано правильно, получить невероятный опыт обучения. Хотя существует несколько подходов к созданию MVP, важно понимать, что не все «новое и блестящее» следует называть MVP. Если вы создаете свой MVP, было бы неплохо несколько раз вернуться к определению Эрика: «MVP - это версия нового продукта, которая позволяет команде собрать максимальное количество подтвержденных знаний о клиентах с наименьшими усилиями».