Еще раз о Minimum Viable Products

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

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

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

MVP обладает тремя отличительными особенностями.Первая. У MVP достаточно функций, чтобы потребители покупали продукт, а компании было проще его продвигать.

1. У MVP достаточно функций, чтобы потребители покупали продукт, а компании было проще его продвигать.
2. Предусмотрен механизм обратной связи, с помощью которого пользователи оставляют отзывы.
   
3. MVP дает преимущества первым пользователям. Так, например, Google предоставил бесплатное обновление ОС пользователям Nexus.
   

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

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

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

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

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

Как на самом деле разработать минимально жизнеспособный продукт? Как узнать, что уже есть MVP, готовый к запуску?

Вот три необходимых стратегических шага.

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

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

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

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

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

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

• Исследование пользователей;
• Конкурентный анализ;
• Скорость итерации по определенным типам функций (на основании отзывов от пользователей);
• Относительные затраты на реализацию пользовательских историй или эпиков.

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

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

Spotify ⸺ модный сервис. В 2006 году его основали как стартап на нескольких ключевых предположениях:

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

В то время потоковая передача музыки (например, Real Player) была реализована ужасно, а пиратство считалось нормой. Поэтому, техническая часть задачи строилась на следующих вопросах:

• Можно ли сделать сервис, который будет передавать музыку мгновенно, сразу после нажатия кнопки «Воспроизвести»?
• Можно ли избавиться от надоедливого индикатора выполнения буферизации?

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

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

Но создатели Spotify передали проект в руки реальных пользователей ⸺ друзей и родственников, и быстро получили обратную связь. Да, технически это было возможно. И да, людям понравился продукт или, скорее, то, каким он может стать! Поставленные гипотезы подтвердились, а работающий прототип помог убедить музыкальные лейблы и инвесторов. Что было дальше ⸺ уже история.

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

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

Пример Spotify это отлично показывает. Не путайте MVP и демо-версию.