Менеджмент продуктов
Три инструмента составления требований к MVP

Minimum viable product (MVP) переводится как «минимально жизнеспособный продукт». Это версия будущего продукта, в котором присутствуют только самые важные функциональности, наиболее ценные для целевой аудитории.

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

Минимально жизнеспособный продукт, энциклопедический пример

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

В 2007 году дизайнеры из Сан-Франциско Брайан Чески и Джо Геббиа решили заработать немного денег, сдав на выходные три спальных места в своём лофте, который снимали сами. Они могли бы выложить свои объявления в популярную базу электронных объявлений Craigslist, но там они затерялись бы в куче информации. Поэтому Чески и Геббиа создали собственный простенький сайт с картой, фотографиями своего лофта и обещанием домашнего завтрака. За первые выходные они заработали $240, а после получили множество писем со всего мира с вопросом, когда их сервис станет доступен в других странах. Так появился Airbnb.

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

Обычно в рамках MVP проверяется две гипотезы: гипотеза ценности и гипотеза монетизации. Будет ли продукт востребован целевой аудиторией? Будет ли аудитория платить?

Суть MVP

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

Для правильного выбора функциональностей необходимо верно понимать саму суть MVP. Её неплохо передаёт эта иллюстрация:

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

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

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

Самыми востребованными функциональностями этого примера являются: поиск игрока и добавление его в друзья, карта площадок с возможностью добавить площадку или подписаться на неё, создание игры со страницей игры. Они закрывают 6 из 8 потребностей.


Какова единственная ценность, которую я хочу донести до пользователя? Если бы в продукте можно было оставить только одну функциональность, какую бы я оставил?
Задвайте себе эти вопросы в процессе определения функциональностей

Инструмент №2. Прототипирование и UX-тестирование

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

Продукт реализуется в виде кликабельного прототипа. Для его создания мы используем InVision.

Готовые прототипы дадут нам возможность провести тестирование на нашей целевой аудитории. Загружаем прототипы на смартфон или планшет и предлагаем пользователям поработать с ними. При этом на каждом экране задаем им три вопроса:


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

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

Как долго опрашивать? Пока не обнаружится тенденция.

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

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

Принципы кликабельного прототипа можно применять и на уровне отдельных функциональностей после первого релиза. Речь об использовании такой вещи, как pre-function: если необходимо проверить востребованность какой-либо функциональности, но не хочется тратить ресурсы на её разработку, поставьте в приложении кнопку этого элемента со счётчиком. Это позволит узнать, насколько она востребована.

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

Пишите код только тогда, когда нет другого способа проверить гипотезу
Марк Рендал, VP Creativity Adobe

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


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

В описанной системе координат возникают четыре сегмента:

  1. Желательно и сложно — скорее всего, эти функциональности не понадобятся даже в полном продукте. Они требуют много ресурсов, при этом пользователь может легко обойтись без них. Смело отказывайтесь от них — они сэкономят деньги и время, а также помогут сохранить продукт целостным.
  2. Обязательно и сложно — эти функциональности могут частично появиться в полном продукте, но для начального этапа развития они обычно не подходят, так как требуют слишком больших инвестиций, длинных периодов тестирования и трудоёмкого анализа обратной связи. Их можно упростить или отложить для реализации в последующих обновлениях.
  3. Желательно и легко — эти функциональности мало увеличивают ценность продукта. Примером может служить загрузочный экран приложения. С одной стороны, это привычная и не совсем бесполезная вещь, но никакую ценность не несёт.
  4. Обязательно и легко — именно эти функциональности должны стать основой MVP.

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

Ошибки, или «Зацени, я придумал новый Facebook»

Какие заблуждения могут помешать при определении функциональностей MVP?

1) «У меня не продукт, а только идея»

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

2) Проблема родительского отношения

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

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

3) «Я порезал слишком много»

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

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



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

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