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

Что означает MVP?

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

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

MVP можно рассматривать как несколько MTP (Минимально Тестируемых Продуктов). MTP рассматривается как способ дальнейшего разбиения MVP на более мелкие части. Для тестирования с небольшой группой людей. Отслеживать и анализировать их отзывы, а затем создавать новые функции на основе их отзывов. Этот продукт становится MVP для публичного релиза, когда тестеры готовы были бы заплатить за него. Вот когда вы определяете функциональный набор вашего продукта для его первого публичного релиза.

В чем суть MVP

Это суть MVP: вывести свою основную идею на тестирование с реальными людьми. Чтобы увидеть, является ли это чем-то прорывным, чем-то, что стоит создавать. Что-то, за что люди готовы платить. Вот ключевой момент: какое минимальное количество продукта заставит людей заплатить или, по крайней мере, заинтересоваться им. В этом заключается суть.

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

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

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

Чем меньше, тем лучше

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

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

Определение вашего Минимально Жизнеспособного Продукта

Хорошо, я рассказал вам, насколько должен быть маленький MVP, но как его определить и сколько времени это займет? Время зависит от того, что вы хотите доставить. Чем больше вы хотите доставить, тем дольше это займет, очевидно. Итак, как определить, что вы должны доставить и что нет?

Это довольно просто, что делает ваш продукт уникальным? Если вы — платформа для знакомств, это может быть то, как два человека взаимодействуют, что совершенно отличается от всех остальных на рынке. В этом случае вы бы определили свой MVP (Минимально Жизнеспособный Продукт) как: «Приложение, в котором два человека могут взаимодействовать уникальным образом». Ваша задача может заключаться в жестком закодировании всего, например, совмещении двух людей, место для свидания — все, что не является уникальным для вашей идеи, а затем сделать единственную переменную, которая не подделана или закодирована жестко — вашу идею. В этой ситуации ваша идея может предусматривать, что два человека не могут видеть или знать что-либо друг о друге до свидания, свидание предварительно запланировано вами двоими, и вы должны встретиться впервые, не видя друг друга. Чтобы определить свой масштаб, вы бы сказали: «Пользователь может использовать приложение на своем телефоне, чтобы нажать кнопку, которая случайным образом подберет ему другого человека. Затем они соглашаются о дате, они даже не могут видеть фотографию друг друга заранее». Это делает задачу довольно простой для вашей команды, у них есть четкая цель — совместить двух людей, а затем назначить свидание.

Тестирование каждой итерации

Затем вы можете отправить это приложение нескольким тестовым субъектам и попросить их оценить, как им понравилась ваша идея.

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

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

Запуск вашего MVP

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

Запуск вашего MVP не должен занять более 6 месяцев. Первые несколько раундов тестирования выявят, что хотят ваши пользователи. Чтобы когда вы пойдете на рынок, у вас будет то, что захотят платить люди. А главное — то, что будут использовать!

Тестируйте свой MVP

Лучший способ узнать, что работает и что нет, — это дать вашу идею в руки людям. Идеально, ваш MVP (Минимально Жизнеспособный Продукт) должен быть выпущен для общественности за 6 месяцев. В то же время вы должны предоставить тестовую версию небольшой группе людей. Эти люди расскажут вам, что работает и что нет. С этой информацией вы сможете добавить или убрать функции. Когда люди начинают говорить «Я бы заплатил за это», вы знаете, что у вас уже достаточно функций для релиза. Это не означает, что сейчас нужно выпускать продукт. Просто вы знаете, что у вас есть набор функций для релиза.

При каждом релизе для этих маленьких групп вы должны задавать им несколько вопросов. Это могут быть вопросы как «Что вам нравится в приложении?». «Что вам не понравилось?», даже «Какие функции вы бы хотели видеть?». Вопросов может быть много, но это всего лишь примеры. Вы должны задать как можно больше вопросов и проанализировать результаты. Вы должны взять результаты и изменить направление следующего MTP (Минимально Тестируемый Продукт). Например, если многие пользователи хотят определенную функцию, добавьте ее, а затем повторно протестируйте. Эта одна дополнительная функция может перевести их из неплатящих клиентов в платящих. Это может быть что-то очень простое, о чем вы даже не думали.

Эти тестовые фазы критичны для быстрого и эффективного вывода вашего продукта на рынок.

Что дальше?

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

Теперь настало время планировать функции после релиза MVP.