Стоит ли создавать MVP перед созданием приложения?

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

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

Занимаетесь ли вы созданием мобильных приложений или продуктов SaaS, задумывались ли вы об использовании минимально жизнеспособных продуктов (MVP) для защиты инвестиций ваших клиентов?

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

Вот что вам нужно знать.

Ценность MVP в разработке приложений

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

Эрик Рис, автор книги «Бережливый стартап», был одним из первых сторонников MVP, и еще в 2013 году он рассказал несколько интересных вещей о том, почему и как мы должны их использовать:

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

Возьмем, к примеру, Dropbox. Вот как выглядела целевая страница продукта в 2009 году:

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

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

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

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

Есть и другие преимущества создания MVP:

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

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

Как создать ценный MVP, который пользователи захотят протестировать

Успех вашего MVP зависит от его способности использовать идеи и отзывы, полученные от первых последователей — тех, кто на 100% на вашей стороне, верит в продукт и хочет помочь вам заполнить пробелы. Так что не упускайте из виду это.

MVP — это не какое-то наполовину собранное приложение. Это все еще должно быть ценным.

Вот некоторые вещи, которые вы должны сделать, прежде чем создавать и запускать свой MVP:

1. Определите цель продукта

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

Например, вот как Uber (тогда еще UberCab) продавал себя во время бета-тестирования в 2010 году:

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

Забегая на год вперед, вы увидите, что Uber начал укреплять свою идентичность и ценностное предложение с официальным запуском продукта:

Это было еще в 2011 году, когда Uber отказался от «Cab» и назвал себя частной службой вождения по вызову. Это был способ позволить потребителям испытать определенные роскошные привилегии, которые они иначе не смогли бы себе позволить.

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

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

2. Найдите своих идеальных пользователей

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

В частности, вам нужно подумать о месте.

В приведенном выше примере с Uber видно, что бета-версия продукта тестировалась только в Сан-Франциско.

Первоначальная версия Airbnb делала нечто подобное. Джо Геббиа, соучредитель Airbnb, рассказывает историю своего MVP в выпуске 2017 года «Как я это построил».

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

Поэтому он и его партнер создали веб-сайт под названием «AirBed & Breakfast». Однако после того, как он был запущен, он распространился далеко за пределы первоначальной тестовой зоны Сан-Франциско.

В 2009 году аренда AirBnB была в 72 странах. Сегодня у вас практически есть выбор в любом городе мира. Но все началось с Сан-Франциско.

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

3. Выберите формат MVP

Формат вашего MVP — еще одна важная вещь, о которой нужно подумать, прежде чем строить.

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

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

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

В 2018 году Рэнд Фишкин объявил, что покидает Moz, компанию, соучредителем которой он был в 2004 году. Одновременно он анонсировал новый продукт под названием SparkToro.

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

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

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

Если вы действительно пойдете по этому пути, вам также понадобится действительно хороший раздел объяснения. Это то, что SparkToro имеет на своей странице «Что мы строим»:

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

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

4. Найдите свой фактический минимум

Если вы посмотрите видео Эрика Риса, то увидите, что он предлагает формулу для определения минимальных характеристик вашего MVP. Это выглядит так:

Количество минимальных функций, которые, по вашему мнению, вам нужны / 8 = Истинный минимум

Это имеет смысл, если эта формула вызывает у вас опасения. Но подумайте об этом так:

Вы создаете MVP настолько простым, насколько это возможно, но при этом не становящимся бесполезным. Вы отправляете его пользователям и даете им возможность оставить отзыв.

В результате может произойти несколько вещей:

Они абсолютно ненавидят это.

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

Им это нравится, но им это не нравится… пока.

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

Им понравится как есть.

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

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

5. Создайте свою целевую страницу заранее

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

Игровые приложения и SaaS были бы особенно хорошим выбором для раннего запуска страницы регистрации бета-версии. Вот пример из Hytale:

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

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

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

6. Определите свои критерии успеха

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

Рассмотрим следующее:

• Сколько посетителей посетили вашу целевую страницу?
• Сколько из этих людей подписались на бета-тестирование?
• Сколько пользователей вы удержали за установленный период (1 месяц, 3 месяца и т. д.)?
• Сколько человек предоставили отзывы и было ли их достаточно, чтобы принять обоснованное решение о дизайне и функциях продукта в будущем?
• Соответствовала ли демография вашего набора пользователей аудитории, для которой вы разработали приложение? Как вы думаете, почему это было?
• Сколько времени в среднем пользователи проводят в приложении?
• На какие функции они потратили больше всего времени? В мере?
• Какие функции получили самые положительные отзывы? В мере?
• Были ли определенные пользователи, у которых был положительный опыт использования продукта? Что отличало их?

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

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

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

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

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