В 2007 году дизайнеры из Сан-Франциско Брайан Чески и Джо Геббиа решили заработать немного денег, сдав на выходные три спальных места в своём лофте, который снимали сами. Они могли бы выложить свои объявления в популярную базу электронных объявлений Craigslist, но там они затерялись бы в куче информации. Поэтому Чески и Геббиа создали собственный простенький сайт с картой, фотографиями своего лофта и обещанием домашнего завтрака. За первые выходные они заработали $240, а после получили множество писем со всего мира с вопросом, когда их сервис станет доступен в других странах. Так появился Airbnb.
Этот MVP очень точно показывал ценность и философию нового продукта: не безликие базы объявлений, а прямое предложение от хозяина жилья. В успехе проекта это сыграло не последнюю роль.
Если вы разрабатываете машину и в качестве первого релиза выпускаете колесо, пользователи даже не поймут, что вы имеете в виду.
Если вашим минимально жизнеспособным продуктом становится самокат или велосипед, пользователям это понравится больше, ведь на этом уже можно ездить и получать некий опыт. Но здесь возникает ошибка с целевой аудиторией, поскольку самокат и машина — очень разные вещи. Аудитория самоката будет недовольна перспективой превращения продукта в машину, которой нужен бензин и дорогое ТО, а те, кому нужна машина, изначально не обратят на ваш самокат никакого внимания.
Как же выбрать для своего MVP те характеристики, которые максимально точно передадут его суть?
Инструмент №1. Принцип Парето
Принцип Парето гласит «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата». Это эмпирический принцип, а значит многие явления в мире подчиняются соотношению 80/20. С приложениями это тоже работает: 80% пользователей обычно используют 20% функциональностей.
Чтобы применить это для создания MVP, можно составить полный фичер-лист нашего приложения и определить те 20% функциональностей, которые закроют 80% потребностей пользователей. Для удобства можно нарисовать два столбца — «Функциональности» и «Потребности», вписать туда пункты и соединять их линиями.
Ошибки, или «Зацени, я придумал новый Facebook»
Какие заблуждения могут помешать при определении функциональностей MVP?
1) «У меня не продукт, а только идея»
Распространённая ошибка. Сама по себе идея ничего не стоит, пока из неё не сформировано видение — набор конкретных гипотез, которые можно протестировать в рамках MVP. Те из них, что пройдут эту проверку, станут основой продукта.
2) Проблема родительского отношения
Автору настолько нравится его продукт, что он любит все его функциоанльности и не готов отказаться ни от одной из них.
Как бороться с родительским отношением? Пригласить человека, которому наплевать. И попросить его применить один из вышеописанных инструментов.
3) «Я порезал слишком много»
В стремлении к объективности некоторые выбрасывают слишком много функциональностей. Но при определении минимально жизнеспособного продукта важно держать в голове, что продукт производит комплексное впечатление и должен хотя бы немного превосходить своих конкурентов.
Особенно это важно для продуктов из высококонкурентных категорий — новых мессенджеров, браузеров, социальных сервисов.
В 2011 году существовало уже достаточно много мессенджеров, но ни один из них не предлагал удалять весь контент сразу после просмотра. На первый взгляд эта идея может показаться странной и легкомысленной, но, если вдуматься, она означает совершенно новый уровень конфиденциальности при сетевом общении. Именно она легла в основу мессенджера Snapchat, созданного гарвардскими студентами Эваном Шпигелем и Реджи Брауном, и сегодня около половины американских подростков называют Snapchat своим любимым приложением.
MVP — это не минимальный список фич, это самый выгодный способ убедить свою целевую аудиторию в том, что ей стоит заинтересоваться вашим продуктом.
