Концепция минимально жизнеспособного продукта (MVP, minimum viable product, ранняя версия оффера с минимальным функционалом, решающая, по крайней мере, одну проблему потенциального клиента) часто интерпретируется неправильно, что приводит к ее неправильному применению. Кроме того, по причине ограниченности ресурсов, большинство бизнесов фокусируются исключительно на части создания минимального функционала, требуемого для выхода на рынок.
Однако MVP является не просто версией продукта с минимумом функций, а наименее ресурсозатратным инструментом валидации экономической целесообразности бизнес-идеи, который также служит основой конечного оффера.
На самом деле, MVP имеет довольно много интерпретаций, поэтому, чтобы понять суть этой концепции, ознакомимся с мнениями экспертов о том, что такое ранняя версия оффера, как ее использовать и как создавать.
Минимально жизнеспособный продукт (MVP) — определения экспертов
Стартапы и крупные IT-компании все чаще используют MVP как отправную точку для создания успешного программного продукта. Фокусируясь на минимальном наборе ключевых функций, компании разрабатывают основу продукта, которая, при условии успешной валидации на предметы спроса, эффективности и жизнеспособности в рыночных условиях, используется для масштабирования оффера и создания полноценного бизнеса.
Однако многие понятия, которыми руководствуются начинающие бизнесы при определении составляющих MVP, не являются корректными. Возьмем, к примеру, распространенное заблуждение, что ранняя версия продукта создается с целью быстрого выхода на рынок. На самом деле, как было сказано ранее, минимально жизнеспособное решение предназначается для валидации экономической целесообразности, посему скорость разработки может быть приоритезирована только при условии быстрого достижения целей анализа и тестирования MVP.
Резюмируя сказанное, выведем основные цели MVP:
- Тестирование гипотез о продукте с минимальными затратами.
- Ускоренное полученное информации, требуемой для создания решения.
- Экономия времени на разработку.
- Быстрое предоставление продукта, решающего, как минимум, одну проблему, ранним пользователям.
Предприниматели и разработчики должны сформировать собственное представление о предназначении и сути MVP, в чем могут быть полезны мнения опытных экспертов.
Эрик Райс (Eric Ries), соучредитель IMVU (сайт социальных развлечений), сторонник MVP
Эрик определяет MVP как раннюю версию нового продукта, позволяющую получить максимум информации при минимальных усилиях — быстро созданный оффер с минимальным набором функций, подходящий для тестирования сценариев интеракции с целевой аудиторией и гипотез о покупательских потребностях, дает возможность отказаться от дорогостоящих маркетинговых исследований и внушительных вложений в разработку конечного решения при неподтвержденности жизнеспособности идеи.
На картинке выше резюмирован процесс создания MVP — все начинается с разработки ранней версии оффера для тестирования идеи, после чего анализируются полученные данные и формируются новые гипотезы.
Эш Маурья (Ash Maurya), автор книги «Бережливый подход — помощь предпринимателям в достижении успеха» (Running Lean — Helping Entrepreneurs Succeed)
Эш начал разработку MVP с определения целевой группы пользователей и трех основных проблем, с которыми она сталкивалась при работе с доступными на рынке решениями — это позволило ему создать оффер, решающий проблемы ЦА в минимальной степени, и привлечь к нему первых пользователей при помощи landing page. Определив функционал MVP за счет анализа разработанного ранее решения, Маурья значительно сэкономил время и усилия на валидацию предположений о базе потенциальных пользователей.
Руководствуясь своим опытом, Эш делает акцент на том, что MVP должен представлять ценность для потребителей — валидировать значимость проблемы, которую будет решать конечный оффер, можно только при наличии правильного начального продукта.
Используя «шаблон бережливости» (lean canvas), Эш выделил 4 критичных шага для валидации ценности продукта на рынке:
- Подтверждение важности проблемы.
- Определение продукта, решающего проблему в минимальной степени (MVP).
- Разработка и валидация MVP в узких масштабах.
- Подтверждение данных, полученных на 3 этапе, в широких масштабах.
Марсин Тредер (Marcin Treder), соучредитель и генеральный директор UXPin (облачное решение для веб-дизайна)
Первым оффером компании Марсина был бумажный блокнот для прототипирования, а текущим является облачное решение для создания прототипов и макетов. По словам Тредера, он и его команда вовсе не предполагали, что следующая версия их продукта будет цифровой — они лишь были группой дизайнеров, которые хотели помочь своим коллегам стать лучшими профессионалами. Однако осознав, насколько разрозненными были решения на рынке и насколько аудитория была ими не довольна, команда UXPin приступила к созданию облачной платформы.
Тредер считает, что MVP является не идеальным или быстро разработанным продуктом, а оффером, который представляет максимальную ценность с минимумом функций. Он признает, что его первый продукт не был максимально эффективным по сравнению с современными решениями, однако сегодня UXPin занимает значимое место на рынке, что доказывает правильность и эффективность реализованной Марсином стратегии.
Представленная выше матрица приоритетов может быть использована для оптимизации процесса разработки. Безусловно, не все стартапы имеют существующий продукт, который может быть использован как основа для формирования MVP, однако, в большинстве случаев, это необязательно.
Ник Суинмерн (Nick Swinmurn), сооснователь Zappos (интернет-магазин обуви)
Первая жизнеспособная модель Zappos является примером исключительной бережливости — Суинмерн самостоятельно фотографировал обувь в розничных точках и публиковал фото на ресурсе Zappos, а когда приходил заказ, он вновь отправлялся в магазин, чтобы купить нужную пару обуви. Ник не имел реального продукта на начальном этапе — его MVP предназначался для максимального устранения неопределенности касательно жизнеспособности бизнеса.
Стоит заметить, что многие компании (особенно стартапы) довольно часто представляют «фантомное обеспечение» (vaporware) — продукт, который либо не существует, либо находится в процессе разработки.
Синди Альварез (Cindy Alvarez), специалист по пользовательскому опыту в Yammer (корпоративная социальная сеть) и бывший менеджер по продукту KISSmetrics (платформа веб-аналитики)
По мнению Синди, многие допускают ошибку, считая, что MVP обязательно должен быть продуктом. Она утверждает, что целью MVP является максимизация полученной информации при минимизации рисков и инвестиций, посему оффер не должен быть единственным средством достижения этих задач. Рассматривая минимально жизнеспособный продукт исключительно как решение с минимальным набором функций, многие команды начинают создавать конечный продукт и урезать его функционал, вместо того, чтобы заниматься исследованиями.
В качество одного из решений этой проблемы, Сидки рекомендует следовать «модели кекса» (Cupcake Model), то есть создавать полноценный продукт, но с минимумом ключевых функций.
Синди также представила несколько советов о работе над MVP внутри команды. По ее словам, существуют 2 задачи:
1. Правильная формулировка ожиданий.Никто не хочет создавать низкопробный продукт, чувствуя, что его нельзя будет улучшить. Следует сделать акцент на том, что MVP создается, дабы команда не тратила время на разработку ненужного продукта/функционала. Кроме того, разработчики должны знать, что смогут улучшить продут на основе результатов тестирования.
2. Правильное определение целевого пользователя.Не следует разрабатывать продукт под мейнстримную аудиторию — если ее представителям не понравится MVP, будет получена неправильная обратная связь. Вместо этого, следует найти целевую группу с определенной проблемой и представить ей раннюю версию оффера.
Стив Блан (Steve Blank), серийный предприниматель, лектор по теме MVP
«Крестный отец Кремниевой долины» утверждает, что в методиках работы с клиентами недооценена важность продажи видения мечтателем (предоставление минимального набора функций при этом не исключается). По его наблюдениям, многие предприниматели без проблем понимают как построить продукт с минимальным набором компонентов (Minimum Feature Set), однако не осознают, что такой оффер мало кому понравится — как вы думаете, будут ли люди восхищенно рассказывать о софте с несколькими базовыми функциями?
Компаниям следует привлекать первых пользователей и евангелистов (evangelists, потребители с сильной верой в особенность продукта), продавая видение того, насколько лучше станет мир, когда через несколько лет выйдет конечная версия продукта, с минимальным функционалом которого можно ознакомиться уже сегодня.
5 характеристик евангелиста
1. Имеет проблему.
2. Осведомлен о ее наличии.
3. Активно ищет решение.
4. Собрал решение проблемы по частям.
5. Имеет или может собрать бюджет.
Рэнд Фишкин (Rand Fishkin), соучредитель Moz (платформа входящего маркетинга)
Рэнд считает, что первое впечатление имеет огромное значение, поэтому подталкивает коллег превращать свои MVP в так называемые EVP (exceptional viable product, исключительный жизнеспособный продукт). Он утверждает, что неоднократно был свидетелем выхода MVP, практически не представляющих ценность, и убежден, что это является значимой проблемой, ведь оффер нельзя перезапускать несколько раз.
Фишкин предлагает разрабатывать MVP в пределах компании и привлекать к его тестированию всего нескольких потребителей, отзывы которых будут использоваться для итерации. Его идея заключается в том, чтобы собирать отзывы и итерировать продукт до тех пор, пока пользователи не дадут ему высокую оценку — только после этого следует делать EVP доступным для широкой публики. Это может занять дополнительные 30-90 дней, но Рэнд уверяет, что оно того стоит.
Несмотря на то, что эксперты определяют MVP по-разному, суть их трактовок неизменна — минимально жизнеспособный продукт является не урезанной версией конечного оффера, а основной для его создания и инструментом валидации бизнес-идей.
Мнения экспертов о минимализме оффера
Применение минимализма является сложнейшим, но важнейшим аспектом разработки MVP, так как его интерпретация определяет выбор функционала и технических ресурсов.
Оффер с оптимальным минимальным набором функций — элегантный шедевр, который позволяет получить максимум информации при минимальных затратах. Однако избыточный акцент на минимализме может лишить MVP ключевой ценности, в результате чего он не только не подойдет для валидации гипотез, но и испортит образ бренда.
Итак, как же разработать привлекательную раннюю версию продукта при минимальных затратах? Для начала, требуется понять разницу между двумя следующими вопросами:
- Как создать продукт, который будет максимально прост с технической точки зрения?
- Как создать простейший продукт, функционал которого будет резонировать с потребностями первых пользователей?
Приоритетом первого подхода является быстрый запуск продукта — это может привести к разработке неправильного оффера, тестирование с использованием которого будет равносильно тестированию концепта машины, у которой нет ничего, кроме колес. Суть второго подхода заключается в предоставлении ключевой ценности продукта, что куда более действенно для валидации гипотез касательно целевого рынка.
Гай Кавасаки (Guy Kawasaki), один из первых маркетологов Apple
Гай считает, что MVP должен быть не идеальным, но революционным. Целью минимализма является экономия ресурсов, достигаемая путем разработки минимального функционала, в котором реализованы несправедливые преимущества, требуемые для привлечения первых пользователей. Эти «ранние евангелисты», как называет их Гай, могут обеспечить как успех, так и провал идеи, поэтому, чтобы воспользоваться ресурсом первых пользователей для получения максимума полезной информации, следует создавать MVP, который будет представлять ключевую минимальную ценность конечного продукта.
Стелла Фэймэн (Stella Fayman), сооснователь Matchist (сервис, соединяющий разработчиков с предпринимателями и стартапами)
Стелла представила 3 вопроса, которые помогают держаться в правильном направлении при разработке минимально жизнеспособного продукта:
- Направлены ли ресурсы на упрощение MVP?
- Сфокусированы ли гипотезы исключительно на ключевой ценности оффера?
- Соответствует ли график разработки принципам бережливости?
Чтобы минималистичный подход укоренился в реальности пользователей, критично важно фокусироваться на втором вопросе.
Фэймэн рекомендует начать с сопоставления функций с предположениями о потребностях ЦА, а затем добавлять слои функционала по мере тестирования гипотез. Это позволяет добавлять исключительно те компоненты, которые обеспечат качественный опыт первым пользователям.
Так как абстрактно понять минимализм непросто, рассмотрим реальный пример.
Крис Бадэр (Chrys Bader), создатель Fliggo (платформа для создания площадок с видеороликами)
Крис хотел протестировать гипотезу, что пользователи будут заинтересованы в хостинге своего собственного сайта для стриминга видео, который в то время можно было легко создать только при помощи WordPress (платформа для управления контентом на сайте) и YouTube (видео-хостинг).
На картинке выше представлена часть минимально жизнеспособного продукта Fliggo — это целевая страница, которая позволила не только определить спрос на оффер, но и готовность аудитории за него платить. В случае подтверждения спроса (спрос на Fliggo был валидирован), следующей итерацией могло бы быть тестирование ценовой политики путем повышения/понижения стоимости подписки. Такие изменения не выходят за рамки минимализма, так как не влияют на целостность интеракции посетителей с MVP (в данном случае, речь идет о заполнении регистрационной формы) и позволяют получать требуемую информацию.
Рэмли Джон (Ramli John), эксперт по стартапам
Джон считает, что полагаться исключительно на посадочные страницы нельзя, так как всегда есть риск не получить обратную связь. Более того, может быть довольно много причин низкой конверсии (например, неэффективный продающий текст), поэтому точно протестировать привлекательность оффера также нельзя.
Рэмли советует другие дешевые MVP, которые позволяют установить качественную обратную связь: например, email-рассылку, блог или видеоролик. Он подчеркнул, что представители известного сервиса AngelList (платформа для венчурного инвестирования и привлечения инвесторов) тестировали ценность своего нетворкинга путем рассылки представительных писем между стартапами, которые нуждались в инвестициях, и активными инвесторами — это не только позволило валидировать бизнес-гипотезы, но и предоставить положительный опыт первым пользователям. В результате, AngelList создали правильный MVP за счет реализации своего преимущества.
Фокусируйтесь на гипотезах, чтобы избежать масштабирования
Несмотря на то, что нежеланное масштабирование (scope creep) случается довольно часто, это явление нельзя назвать одним из самых понятных аспектов дизайна и разработки MVP.
Как понять, что на разработку потрачено слишком много времени? Создатель Blekko (поисковая система) Рик Скрента (Rick Screnta) утверждает, что это зависит от продукта. Для некоторых решений (например, упомянутого ранее Fliggo) достаточно создать лендинг, а офферы с широкой целевой аудиторией требуют гораздо больше времени — слишком простой или некачественный продукт воспримется публикой крайне негативно. На разработку MVP поисковой системы Рика, например, ушло 3 года.
Однако более релевантной задачей может быть определение цели работы, а не ее продолжительности, так как качественный ответ на первый вопрос позволяет качественно ответить на второй. Райан Сингер (Ryan Singer), менеджер по продукту Basecamp (сервис для организации проектов), утверждает, что минимализм в рамках MVP достигается за счет следования базовым стандартам качества исполнения и соответственной регуляцией функционала.
Основатель KISSmetrics Нил Патель (Neil Patel) привел в пример несколько успешных минимально жизнеспособных продуктов разного масштаба, но последовательного исполнения:
- Dropbox. Известное ныне облачное хранилище начиналось с трехминутного видеоролика, который увеличил подписную базу с 5 000 до 75 000 за одну ночь при отсутствии реального продукта.
- Foursquare.Создатели социальной сети начинали со сбора отзывов при помощи Google Docs.
- Virgin Air. MVP авиакомпании Ричарда Брэнсона (Richard Brenson) — один самолет, который ходил по одному маршруту с целью валидации бизнес-гипотез. Самолеты и маршруты добавлялись по мере роста бизнеса.
- Groupon.Ранней версией всемирно известной площадки для поиска купонов был блог на базе WordPress, на которым был установлен виджет, отправляющий купоны в PDF формате по email.
Наиболее ресурсозатратным был ранний продукт Virgin Air, а наименее — Foursquare. Однако каждый MVP был сложным настолько, насколько были сложны гипотезы, для тестирования которых он разрабатывался. Но что более важно, ни один из представленных выше офферов не был упрощен до такого уровня, при котором бы страдал пользовательский опыт или ценностное предложение. Groupon, например, до сих пор предоставляет ценность своего MVP, отправляя купоны по электронной почте, однако имеет более гладкий и совершенный интерфейс.
Чтобы правильно определить масштабы MVP, следует разработать наиболее подходящий для тестов продукт, который позволит либо подтвердить, либо опровергнуть гипотезы об оффере. Важно определять как правильные, так и неправильные предположения — исключение неверных гипотез также позволяет валидировать идею.
Придерживайтесь ДНК вашего продукта
Независимо от тактики, убедитесь в том, что ваша MVP стратегия сфокусирована на тестировании гипотез, а не сокращении функционала в целях экономии. До тех пор, пока минимально жизнеспособный продукт будет соответствовать вашему уникальному ценностному предложению, вы сможете итерировать его на основе отзывов ранних пользователей.
На картинке выше ДНК машины выражен ее эффективностью как способа перемещения из пункта А в пункт Б по сравнению с ходьбой пешком. Каждая итерация увеличивает масштаб продукта за счет расширения функционала, однако уникальная ценность более быстрого перемещения остается неизменной.
В данном случае, минимально жизнеспособным оффером мог бы быть простой онлайн-опрос о том, нужен ли быстрый способ передвижения — это простейший способ протестировать несправедливое преимущество в минимальных масштабах. На основе пользовательских отзывов мог бы быть разработан скейтборд, который, по мере итерации, превратился бы в авто.
Гаган Бияни (Gagan Biyani), соучредитель Udemy (платформа для создания и прохождения обучающих курсов) и Sprig (доставка здоровой пищи), уверен, что первая версия MVP должна тестировать ценностное предложение, а последующие итерации предназначены для валидации новых гипотез. Гаган выразился по этому поводу так:
MVP должен быть не просто продуктом, а минимально жизнеспособным тестом гипотезы Х. Последовательно итерирующийся ранний оффер, подходящий для тестирования различных тезисов, позволит быстрее выпустить качественный конечный продукт.
Минимально жизнеспособным продуктом Udemy, например, был созданный основателями сервиса онлайн-курс стоимостью в $20, предназначенный для тестирования гипотезы, что люди готовы платить за качественные видео-курсы. MVP Sprig — команда основателей, которая развозила пищу в течение одного вечера, дабы подтвердить, что еду можно доставить в течение 20 минут.
Как и в примере со скейтбордом, описанные выше MVP позволили валидировать бизнес-идею и тестировать новые гипотез за счет итераций.
MVP считается успешным в том случае, если позволяет тестировать спрос на идею. Лимитирование масштаба проекта до тестирования ценностного предложения дает право на ошибку без риска потерять все ресурсы.
Помните, что цель MVP заключается не в создании идеального продукта, а в максимизации полученной информации при минимизации усилий — это позволяет не допускать серьезных ошибок итерации.
Мнения экспертов о жизнеспособности продукта
Работая над MVP, довольно легко сконцентрироваться исключительно на минимализме. Однако работающего продукта недостаточно — он должен быть ориентирован на долгосрочный успех, ибо его запуск будет нецелесообразен.
Показанная выше модель последовательной разработки может привести команду к тому, что итерация оффера будет проходить без тестирования гипотез — приоритетом становится исключительно доработка, а не определение причин для внедрения изменений в продукт. В результате, следование неправильным бизнес-причинам может привести к идеальному, но нежизнеспособному продукту. Следовательно, возникнет потребность в дальнейшей доработке.
На этом изображении показана гибкая модель — команда концентрируется на ширине, а не глубине итераций, что позволяет выбрать оптимальный путь развития продукта и углубиться в разработку.
Стоит заметить, что гибкая методология не способна обезопасить от принятия неправильных решений на основе прошлого опыта. Дабы этого избежать, маркетологи должны концентрироваться исключительно на опыте и потребностях целевого рынка — это позволяет абстрагироваться от собственных выводов и видеть картину целиком. Направление команды на работу небольшими итерациями позволяет чаще валидировать возможность создания продукта, потребность в нем потребителей и их готовность за него платить.
Согласно серийным предпринимателям Стиву Бланку и Бобу Дорфу (Bob Dorf), веб-сервисы могут использовать несколько посадочных страницы для тестирования жизнеспособности различных решений. Например, платежный сервис может быть разработан в 3 прототипах: FastPay, EZPay и FlexiPay. FastPay решает проблему скорости онлайн-платежей, EZPay решает проблему простоты, а FlexiPay — гибкости. Таким образом, благодаря диверсификации и тестированию, команда снижает риски и выбирает наиболее привлекательный для целевого рынка продукт.
Диверсификация и гибкость позволяют специалистам видеть реальные проблемы целевого рынка, а не рассматривать проект исключительно в рамках технической осуществимости. Представленная выше модель удерживает от внедрения изменений, основанных на неправильных гипотезах касательно рынка.
Жизнеспособность продукта и жизнеспособность бизнеса
Жизнеспособность является одним из наиболее спорных аспектов MVP, неправильное понимание которого проводит как к провалу продукта, так и целого бизнеса. Офферы, являющиеся жизнеспособными на ранних стадиях, встречаются настолько редко, что привлекают огромный интерес абсолютно всей IT-индустрии, начиная с инвесторов и венчурных капиталистов, заканчивая предпринимателями и СМИ.
Инновационность (Innovation) продукта является балансом спроса (Desirability), жизнеспособности (Viability) и осуществимости (Feasibility).
Кристина Уодтке (Christina Wodtke), бывший генеральный менеджер Zynga (разработчик онлайн-игр), утверждает, что жизнеспособность следует рассматривать с точки зрения бизнеса— это позволяет убедиться в том, что ранний продукт сфокусирован на рынок. По ее словам, чтобы обеспечить жизнеспособность оффера, его нужно довести до минимального уровня качества, что, как правило, требует меньше всего усилий.
Многие компании, имеющие в наличие достаточно ресурсов, сразу же хотят разработать идеальный жизнеспособный продукт, но это приводит к негативным последствиям — масштабировать в рыночных условиях оффер, который выходит за рамки стандартного MVP, очень непросто.
Определение жизнеспособности продукта
Как правило, жизнеспособность продукта определяется степенью его осуществимости, при определении которой важно учитывать не только технические, но и политические, юридические, рыночные и любые другие факторы, имеющие отношение к продукту. Говоря конкретными категориями: налоговая политика, законодательство и отсутствие технологий могут ограничить развитие MVP.
В качестве реальных примеров, можно привести Airbnb (площадка для размещения и аренды жилья), осуществимость модели которого ограничена законами об аренде и недвижимости, определяющими продолжительность проживания платящих гостей, и Spotify (сервис музыкального стриминга), представителям которого пришлось удалить значимую часть треков из-за проблем с лицензированием. Сегодня обе компании занимают достаточно хорошие позиции на рынке, однако проблемы, возникшие с ранними версиями офферов, наверняка негативно повлияли на темпы масштабирования.
Абстрактным примером осуществимости является изображенный выше нож — если кому-то удалось его произвести, он является осуществимым.
Рассмотрим пример такой модели мышления в гипотетической ситуации. Допустим, бизнесу нужно протестировать полезность беспилотных дронов как инструментов для сбора информации о состоянии урожая. Просмотрев сотни страниц технической документации, команда подтверждает, что существует специальный спектрометр для обнаружения химикатов, полученная информация может быть импортирована в Excel, а правила регуляции гражданской авиации не слишком строгие. В результате, проект признается жизнеспособным.
Однако минимально жизнеспособный продукт может провалиться, так как не тестирует жизнеспособность бизнес-модели путем проверки возможностей компании и рынка. Например, МVP не позволяет узнать, будет ли прибыли достаточно на долгосрочное обслуживание дронов и позволит ли доход покрыть затраты на исследование и разработку продукта.
Резюмируя сказанное: ключом к тестированию жизнеспособности является валидация устойчивости продукта, а не только его осуществимости.
Определение жизнеспособности бизнеса
Переход от ранней адаптации к устойчивому развитию является одним из сложнейших этапов, которые проходит бизнес.
Существует ряд факторов, которые определяют жизнеспособность бизнеса:
1. Спрос
Предполагаемая потребность рынка довольно часто сопровождается негибкой разработкой и статичным видением. Провода аналог с предыдущим примером: команда, планирующая использовать беспилотные дроны, не ответила на критично важный вопрос — нужна ли фермерам информация, которую будет собирать их продукт?
Исполнительный директор и основатель Buffer (решение для постинга в социальных сетях) Джоэл Гаскойн (Joel Gascoigne) убежден, что единственной целью MVP является валидация знаний о текущих потребностях рынка. Разработчики дронов, к примеру, могли бы арендовать летающее устройство, собрать и обработать информацию о состоянии урожая, предоставить ее фермерам и получить их отзывы, которые бы подтвердили или опровергли гипотезы о проблемах целевого рынка.
Дэвид Айкен (David Aycan), директор по дизайну IDEO (дизайнерская фирма), разграничивает создание технически осуществимых продуктов и офферов, в которых есть потребность на рынке. Он считает, что минимализм в контексте MVP подразумевает требуемый потребителям набор функций, но не имеет ничего общего с простотой технической разработки. Следовательно, жизнеспособность является степенью, в которой продукт может революционно удовлетворять ключевые потребности целевой аудитории.
2. Возможность компании создать продукт
Упомянутая ранее Стелла Фэймэн определяет жизнеспособность как способность продукта выполнять свои функции. По ее словам, возможности реализации проекта определяются при взгляде с минималистической точки зрения на техническую осуществимость, так как целью раннего оффера является тестирование гипотез о продукте.
Немаловажную роль в оптимизации осуществимости оффера играют вопросы, которые задают себе разработчики. Приведем несколько правильных вопросов:
- Какой базовый функционал требуется MVP?
- Как определить, что минимально жизнеспособный продукт успешный?
- Какую информацию требуется получить от анализа показателей функционирования продукта?
По мнению Нила Пателя, ключом к реализации проекта является эффективная работа небольшими этапами — это позволяет команде более рационально оценивать значимость функционала. Частые обзоры дизайна и проверки кода улучшают работу команды, позволяя фокусироваться на ключевых аспектах продукта и избегать серьезных ошибок. Кроме того, работа в коротких циклах снижает затраты на разработку, так как позволяет предотвратить серьезные ошибки, которые могут критично снизить ROI проекта: если, например, стоимость переписывания кода будет астрономической, большое количество подписчиков не позволит компенсировать затраты.
Основатель UsabilityCounts (ресурс о юзабилити) Патрик Ниман (Patrick Neeman) считает, что команда должна работать короткими циклами и состоять из разнопрофильных специалистов, так как разработка продукта требует широкого ряда навыков. В идеале, команда MVP должна справляться с менеджментом продукта, итерацией, визуальным дизайном, разработкой, созданием контента и контролем качества. Нанимать специалистов для каждого направления не стоит, однако связанные с ними задачи должны обязательно выполнятся.
По словам Патрика, неспособность специалистов работать в разных направлениях может стать огромной помехой, так как в случае MVP быстрота и гибкость важнее уверенного, медленного продвижения и узкопрофильности.
3. Прибыльность продукта
Опрос потребителей об их готовности купить ваш продукт может помочь определить уровень спроса, однако поставив перед ними препятствие, которым выступит стоимость продукта, вы определите реальную финансовую ценность идеи.
Чтобы это сделать, можно разместить на лендинге кнопку «Купить», после нажатия на которую будет появляться сообщение о том, что продукт находится на стадии альфа-разработки, однако есть возможность стать бета-тестером. Те, кто пройдут процесс регистрации, будут идеальными первыми пользователями, так как покажут готовность платить.
Марсин Тредер считает, что прибыльность MVP определяется качеством обратной связи:
8 000 людей, которые предоставили свой электронный адрес, даже близко не имеют такой ценности, как 30 человек, которые готовы платить уже сейчас. Цель MVP заключается в сборе не огромного количества информации, а качественных данных. Информация, которую дадут готовые к покупке 30 пользователей, позволит получать прибыль с будущих клиентов.
Нил Патель представил несколько советов по переходу к монетизации:
- Проинформируйте об уходе с модели фримиум. Пользователей оттолкнет внезапный переход от бесплатной к платной модели.
- Честно объясните причины установления платы. Большинство пользователей понимают, что MVP не будет вечно оставаться бесплатным.
- Ведите прозрачную ценовую политику и не скрывайте доходы. Честность является отличным способом завоевать доверие, а отображение доходов и зарплат позволяет пользователям понять стоимость содержания сервиса.
- Установите начальную цену ниже уровня прибыли. Объяснив пользователям, что ваша ценовая политика не приносит прибыли, вы смягчите негативный эффект от перехода на платную модель и подготовить их к будущим увеличениям цен.
В качестве альтернативы, можно запустить краудфандинговую кампанию. В отличие от landing page и других MVP, краудфандинговый проект позволит оценить, какая часть аудитории готова платить за продукт. Следовательно, успешная краудфандинговая кампания позволит не только привлечь ранних пользователей, но и сформировать определенные ожидания о ценовой политике, так как от размера инвестиций, внесенных потребителем, зависит ценность, которую он получить.
Джон Саддингтон (John Saddington), партнер The Iron Yard (акселератор стартапов), подтвердил, что люди готовы платить за приложение для обработки фотографий, функционал которого превосходит возможности Facebook и Instagram. Используя Kickstarter (краудфандинговая площадка), Джон собрал 113% из требуемых $50 000 для реализации своего проекта Pressgram. Кампания была настолько успешной, что он планирует провести еще одну для привлечения инвестиций к стационарной версии решения.
Джон советует делать все возможное, чтобы заполучить первых пользователей, так как информацию, которую предоставляют живые клиенты, невозможно получить от тестирования гипотез.
Определите метод обработки количественных данных
При работе над MVP важно обрабатывать как качественные, так и количественные данные — качественные являются более действенными, а количественные — более прямыми.
Далее мы разберемся, как использовать количественные данные при принятии качественных решений.
Бизнес консультант Тристан Кромер (Tristan Kromer) уверен, что оценка данных эффективности MVP важна в такой же степени, как и разработка продукта. Он выделяет 4 составляющих MVP, отсутствие обратной связи по которым разрушает процесс получения данных:
1. Потребитель.
2. Канал.
3. Ценность.
4. Отношения.
Он акцентирует внимание на том, что разработка подразумевает не только создание самого продукта, но и формирование маркетинговых каналов и определение ключевых метрик эффективности.
Shopify (платформа для создания интернет-магазина) и Mashable (онлайн-издание) кратко изложили способы, при помощи которых можно оценить жизнеспособность оффера и сделать продукт жизнеспособным. Если у вас есть готовый продут или вы работаете над его созданием, следуйте 4 следующим шагам:
- Определите 30-40 факторов успеха MVP. Таковые должны быть связаны с продуктом, потребителями, транзакциями, категорией продукта, рынком и т. д.
- Соберите и проанализируйте отзывы клиентов по ключевым факторам. Члены команды также должны оценить факторы по шкале от 1 до 10 — это позволит определить текущую жизнеспособность оффера.
- Суммируйте оценки для получения общего балла по каждому фактору.После этого, индивидуально обсудите оценки с членами команды, дабы убедиться в их корректности. Суммируйте результаты на одной странице.
- Создайте график динамики оценок. Это позволит понять природу изменения факторов успеха, чтобы определить степень эффективности команды.
Ответы на представленные выше вопросы помогут всем членам команды понять, что жизнеспособность является не процессом, а долгосрочной целью.
Дайте продукту жизнь
К сожалению, большинство рассматривает MVP как процесс создания чего-то жизнеспособного с минимальными усилиями, вместо того, чтобы стремиться к созданию продукта, который со временем будет развиваться самостоятельно.
Приняв правильную ментальную установку, сделайте шаг вперед и создайте свой MVP, зная, что это семечко превратится в прибыльный продукт.
Мнения экспертов о качестве продукта
Качество продукта определяется не только временем, затраченным на его разработку, но и понимаем пользователей, природы их работы с продуктом и факторов, которые негативно или позитивно влияют на их восприятие.
Профессор Гарвардской школы бизнеса (Harvard School of Business) Дэвид Гарвин (David Garvin) написал исчерпывающий материал о способах определения качества продукта и 8 плоскостях его оценки:
- Производительность.Основные рабочие характеристики продукта.
- Дополнения. Все, что дополняет базовый функционал.
- Надежность.Вероятность возникновения неисправности в течение определенного промежутка времени (этот фактор лучше оценивать как вероятность отсутствия неполадок).
- Соответствие.Степень соответствия дизайна и производительности установленным стандартам.
- Долговечность.Продолжительность жизнеспособности (с учетом экономической составляющей) оффера.
- Простота ремонта.Осуществимость, скорость, удобство и простота ремонта.
- Эстетика. Оценка продукта органами чувств.
- Восприятие качества.Имидж/репутация оффера.
Играйте на эмоциях — удовлетворите первых пользователей
Многие эксперты, в число которых входит Стив Бланк, считают, что для создания заинтересованности в продукте важно привлекать не только потребителей, но и авторитетных личностей, имеющих влияние в нише — в противном случае, привлечь должное внимание к офферу будет крайне сложно. Более того, завоевывать внимания экспертов должны не только малоизвестные стартапы, но и крупные кампании с развитыми каналами дистрибуции и именитые предприниматели с большой базой последователей.
Однако ни огромная база подписчиков, ни внимание экспертов не спасут посредственный продукт, посему, как советует Рэнд Фишкин, MVP следует дорабатывать до тех пор, пока он не будет идеально выполнять свою ключевую функцию.
В качестве примера, рассмотрим отзыв специалиста в области юзабилити Брайна Донохью (Brian Donohue) об использовании Magic Mouse (мышка компании Apple) и решения для настройки компьютерной мыши MagicPrefs.
Ожидания Брайна касательно продукта Apple были не высоки, однако он остался очень доволен, поскольку испытал ценность функций, о потребности в которых даже не догадывался. По его мнению, Apple удалось сделать восхитительный продукт за счет ограничения функционала до степени, при которой потребитель получает ключевую ценность.
MagicPrefs устанавливает более высокие ожидания в плане возможностей. Технически подкованные пользователи приспособятся к продвинутому функционалу MagicPrefs, а обычные потребители скорее предпочтут более простую Magic Mouse, функционал которой ограничен, но которая имеет ярко выраженное преимущество над другими продуктами.
Из этого примера следует, что успешность MVP как продукта сводится к предоставлению минимальной, но уникальной и высокой ценности.
Добавьте логическую ценность — помогите пользователям действовать
Дизайнер продукта Dropbox Джош Пакетт (Josh Puckett) утверждает, что оценка качества зависит от целей MVP. Приведем его слова:
Единственная задача минимально жизнеспособного продукта заключается в том, чтобы помочь пользователям понять, какую ценность оффер принесет в их повседневную жизнь. Не мешайте им в этом. Если качество (или его отсутствие) мешают пользователям получать ценность, MVP не находится на требуемом уровне.
С этой точки зрения полезно тестировать MVP на эффективность дизайна:
- Вызывает ли дизайн эффект трения?
- Соответствуют ли дизайн и пользовательский опыт уровню конечного продукта?
Если дизайн не проходит один из выше описанных тестов, Джош советует вернуться к его доработке. Он не утверждает, что дизайн должен быть идеальным, а акцентирует внимание на важности устранения значимых недочетов, которые могут негативно влиять на интеракцию — если пользователи будут раздражены или испытывать неудобства при тестировании продукта, полученные в результате тестов данные будут некачественными, независимо от продолжительности эксперимента.
Исполнительный директор Adaptive Path (консалтинговая фирма в области юзабилити) Брэндон Шауэр (Brandon Schauer) рассказал о двух моделях разработки MVP — модели «сухого торта» (Dry Cake) и «кекса».
Следуя первой концепции, команды создают базовый и не очень интересный продукт (что-то похожее на сухой торт), а чтобы сделать его законченным, постепенно добавляют функционал (крем и глазурь). Этот подход, применяемый большинством бизнесов, вполне рационален с операционной точки зрения, однако проблематичен с точки зрения конкуренции и удовлетворения потребителей — посредственный продукт (который, к слову, может разработать любая компания) не привлечет внимание аудитории.
Суть второй концепции заключается в создании небольшого, но полноценного продукта — кекса, который, в отличие от сухого торта, изначально имеет крем и глазурь. Такой оффер будет пользоваться спросом у потребителей, поскольку представляет ценность, и позволит выделиться на фоне посредственных альтернатив.
Автор книги «Соблазнительный интерактивный дизайн» (Seductive Interactive Design) Ствиен Андерсон (Stephen Anderson) считает, что разработка по «модели кекса» является необходимостью, так как большинство компаний конкурируют на зрелых рынках. Приведем его слова:
MVP зачастую используется как оправдание созданию посредственного оффера, качеством которого пожертвовали ради быстрого выхода на рынок. Низкокачественный прототип может быть полезен для валидации кардинально нового решения, однако, в большинстве случаев, компании выходят на зрелые рынки с определенными стандартами качества, посему тестирование неэффективного оффера приведет к получению неправильных данных.
Чтобы определить качество, достаточно знать рынок и трезво оценивать раннюю версию продукта. Как было сказано ранее, разработка низкокачественного прототипа целесообразна при ориентации на свободный рынок — в противном случае, жертвование качеством не следует рассматривать.
Используйте сети, но не полагайтесь на них
Джерард Теллис (Gerard Tellis), профессор школы бизнеса при университете Южной Калифорнии (USC Business School), считает, что качество продукта, весомость которого кардинально возросла за последние несколько лет, является более значимым фактором, нежели сетевой эффект. Более того, так как потребителям предлагаются высококачественные (в некоторых случаях идеальные) продукты, сетевой эффект увеличивает значимость качества.
Марсин Тредер соглашается с этим утверждением, но отмечает, что сетевой эффект является обязательным для все большего количества новых продуктов:
Загвоздка в том, что сети начинают играть все более важную роль в модели многих современных офферов, примерами каковых являются рекламные платформы, социальные сети и торговые площадки. Тем не менее, если сеть является основой продукта, она должна быть одним из аспектов качества, а не расцениваться как отдельный феномен.
Чтобы задействовать сетевой эффект, требуется завоевать лояльность отдельных пользователей. Если не учитывать недостаточно гибкий процесс покупки, безопасность и другие аспекты, ограничивающие пользователей, многие офферы не достигали требуемой степени виральности отчасти потому, что не привлекали конечного пользователя— они были далеки от идеала юзабилити и дизайна, посему о них забывали достаточно быстро.
Зависимость качества от целей продукта
Универсальной формулы дизайна и разработки MVP не существует, так как каждый продукт имеет уникальные критерии качества и эффективности.
Интересную точку зрения касательно качества MVP выражает основатель SoHelpful (сервис бизнес-консультаций) Кевин Диволт (Kevin Dewalt) — он считает, что технический долг (плохая продуманность структуры системы) допустим, так как код, функционал и дизайн начальной версии оффера непостоянны.
Например, если вы строите оффер исключительно в целях валидации идеи, недочеты дизайна и кода допустимы, так как позволяют быстрее выйти на рынок и протестировать гипотезы. Следовательно, пробелы в качестве являются техническим долгом только в том случае, если MVP предназначается для пользователей
Работайте над целостностью продукта, а не функций
Качество продукта связано с глубоким пониманием потребностей целевого рынка, вниманием ко всем аспектам продукта и умением завоевать лояльность отдельно взятого пользователя за счет предоставления реальной ценности. Это требует разработки целостного продукта, имеющего потенциал для масштабирования и оптимизации, а не низкокачественного оффера, который постепенно доводится до приемлемых стандартов.
Продумывание версий продукта наперед все упрощает, однако следует учитывать, что каждый новый оффер дорабатывается на основе информации, полученной при помощи MVP.
Баланс между пользовательским опыт и исполнением
Что важнее: высококлассный пользовательский опыт, который вызывает желание пользоваться продуктом, или завоевание значимой доли рынка путем быстрого запуска продукта с требуемым потребителям функционалом? На самом деле, некоторые клиенты не захотят пользоваться продуктом низкого или среднего качества, а другие будут рады использовать новое низкокачественное решение и помогать в его доработке.
Все сводится к тому, что выбор между UX и бережливостью зависит исключительно от бизнеса и продукта. Однако можно сказать наверняка, что стремление и к быстрому запуску, и к идеальному дизайну заведомо сулит неудачу.
Итак, чем же следует руководствоваться, выбирая между приоритезацией пользовательского опыта и бережливого исполнения?
User Experience
Сооснователь Rocksause Studios (агентство веб-разработки) Кью Мэннинг (Q Manning) выразился по поводу важности UX так:
Найти качественно разработанное приложение не так сложно — многие приложения с низким рейтингом являются отзывчивыми (то есть, имеют отзывчивый дизайн, responsive design) и не имеют багов. Так что же общего у топовых приложений? Они предоставляют фантастический UX — взаимодействие с ними интуитивно в наивысшей степени.
Это заявление, казалось бы, позволяет поставить точку в выборе приоритетов, однако создать идеальный пользовательский опыт очень непросто как минимум потому, что это понятие является слишком обширным. Чтобы в этом убедиться, достаточно посмотреть на схему ниже:
Бережливое исполнение
Работая по модели lean, команда быстро создает и запускает рабочий прототип, получает обратную связь и начинает все заново — иными словами, суть бережливой концепции заключается в создании MVP.
Определить стандарты высококлассного пользовательского опыта, не имея преданных пользователей, попросту нереально. Посему следует начинать с создания предложения, передающего основную ценность концепции, и его выпуска на рынок — на начальных стадиях определение ожиданий целевого рынка важней формирования представления о пользовательском опыте.
Если же задачей MVP является привлечение бета-тестеров, выход продукта не следует преподносить как официальный запуск, дабы не оттолкнуть аудиторию низкокачественным решением. Достаточно лишь найти небольшую аудиторию, заинтересованную в продукте — многие пользователи будут готовы тестировать решение просто ради удовольствия.
Поговорим о составляющих бережливого стартапа.
1. Жизнеспособный бизнес
Несмотря на невероятные истории успеха MVP, каковой, например, можно назвать капитализацию Dropbox с 0 до $1 000 000 000 всего за 4 года, большинство минимально жизнеспособных продуктов ведут к модели минимально жизнеспособного бизнеса (Minimum Viable Business), при которой трафик и прибыль наращиваются медленно и стабильно.
2. Осуществимый продукт
После создания MVB следует убедиться, что финансы, ресурсы, время и технологии позволяют реализовать идею. Если осуществимость продукта не подтверждается, переход на следующий этап не имеет смысла.
3. Желаемый продукт
Последний этап — подтверждение соответствия оффера понятию MDP (Minimum Disrable Product, минимально желаемый продукт). Это понятие впервые ввел Эндрю Чен (Andrew Chen), дав ему следующее определение:
Минимально желаемый продукт — простейший опыт, требуемый для отображения ценности оффера и удовлетворения потребностей аудитории.
Жизнеспособность. Принесет ли продукт доход?
Осуществимость.Возможна ли реализация проекта?
Интерес в продукте.Если ли спрос на продукт?
Глава UX в MailChimp (провайдер email-услуг) и автор книги «Дизайн ради эмоций» (Designing for Emotion) Ааррон Уолтер (Aarron Walter) убежден, что пользовательский опыт является ключом к привлекательности оффера. Он высказался по этому поводу так:
Изначально акцент делался на юзабилити и получении информации, но сегодня создать приложение и выпустить его на рынок очень легко. Что позволит офферу выделиться? Индивидуальность. Функционал всегда можно добавить, но индивидуальность должна присутствовать с самого начала.
Стадии разработки продукта
Важнейшим фактором, определяющим приоритетность UX/бережливости дизайна, является текущая стадия продукта.
Разработка дизайна тесно связана с принимаемыми касательно продукта решениями — на стадии рисования скетчей возможности дизайна неограниченны, однако принятые в начале решения создают определенные рамки дальнейшей разработки. Все доработки должны вливаться в текущий дизайн — в противном случае, каждое нововведение будет означать редизайн, что, очевидно, может быть попросту нереализуемым предприятием.
Это подводит к стратегии уменьшения масштабов проекта с целью фокусировки ресурсов на решении понятных проблем. Следует создать простой дизайн и перейти к следующему этапу разработки. Суть MVP заключается в создании не идеального, но эффективно функционирующего продукта — это позволит дорабатывать ключевой концепт на следующих этапах дизайна и разработки.
Ниже представлено краткое резюме этапов создания продукта.
1. Стадия технологий (больше бережливости, меньше UX)
- Цель— разработка плана и определение потребностей целевого рынка.
- Ключевые соображения— концентрация на MVP, акцент на жизнеспособности. Работа на UX невозможна по причине отсутствия требуемой базы юзеров. Есть предположения касательно целевого рынка, однако точной информации нет. На этом этапе требуется разработать продукт и выпустить его на рынок, чтобы понять, кому интересен продукт и как им будут пользоваться
- Критерии успеха— пользователи (исключая бета-тестеров) заинтересованы в продукте.
2. Стадия функционала (чуть больше UX, чуть меньше бережливости)
- Цель— определение ключевого функционала на основе пользовательского спроса.
- Ключевые соображения— начало формирования UX в рамках процесса принятия решений с целью вызвать у пользователей определенный эмоциональный отклик. Анализ функционала конкурентных решений. Продукт следует запускать только при условии его соответствия стандартам пользовательского опыта.
- Критерии успеха — получение обратной связи от пользователей.
3. Стадия анализа интеракции (работа на UX, никакой бережливости)
- Цель— анализ интеракции пользователей с продуктом.
- Ключевые соображения— добавление функций осуществляется исключительно при крайней необходимости. Осуществляется определение проблем, с которыми сталкиваются юзеры при работе продукта, и степени их значимости (могут ли они стать причиной ухода к конкурентам). На данном этапе следует изучать все эффективные UX-дизайны и применить знания на практике.
- Критерии успеха— пользователи рекомендуют продукт другим, оффер набирает виральность.
Бережливый дизайн против UX-дизайна
На самом деле, разница между этими понятиями небольшая, так как в обоих случаях дизайн оптимизируется под потребности пользователя, от быстроты определения которых зависит успешность продукта. Потребителям не важно, насколько продукт продвинут в техническом плане — им важно лишь то, какую ценность он будет представлять для них.
Рассмотрим как происходит разработка приложения при ориентировании на UX и по принципам бережливости.
UX-дизайн
- Определение аудитории, проблемы и проекта. Пользователям нужно приложение, которое конвертирует рецепты в список покупок.
- Разработка низкокачественных прототипов.На основе приложений для шоппинга и рецептов создается прототип и тестируется в полевых условиях.
- Дизайн. Творческий процесс и фокусировка на UX.
- Обеспечение спроса.Представление приложения заинтересованным сторонам и анализ уровня его привлекательности. Это наиболее недооцененная стадия, на которой продукты становятся хуже либо из-за недостаточно большой пользовательской базы, либо из-за игнорирования пользовательских отзывов.
Бережливый дизайн
- Наблюдение и мозговой штурм. Люди совершают покупки по категориям (например, молочные продукты, мясо, овощи), а затем готовят из того, что купили. Если бы покупатели фокусировались на приобретении ингредиентов для рецептов, опыт шоппинга мог бы быть кардинально иным.
- Минимально жизнеспособный продукт. Получение обратной связи от группы тестеров о ранней версии решения для конвертации рецептов в список покупок.
- Сбор отзывов и итерация.Определение реальной проблемы и возвращение к первому этапу — возможно, что проблема заключается не в составлении списка покупок, а в нахождении рецептов.
Соучредитель MOBX (конференция мобильного юзабилити) Ян Юрса (Jan Jursa) считает, что чем более зрелый рынок, на который ориентирован продукт, тем сильней должен быть акцент на UX-дизайне. Для него создание MVP не подразумевает жертвование фундаментальными качествами полноценного продукта:
Универсальные принципы дизайна существовали и будут существовать на протяжении долгих лет, и если вы считаете, что ваш продукт может обойтись без них, вам стоит пересмотреть свои взгляды. Такие факторы как гармоничность и иерархическая структура определяют восприятие продукта в такой же степени, как и юзабилити.
Будьте бережливы, но работайте на UX
Бережливый дизайн с акцентом на пользовательский опыт обретает значимость в мире дизайна, так как многие компании пытаются соединить 2 подхода воедино.
Однако достижение этой целит требует фокусировки на UX на каждом этапе разработки и дизайна, включая стадии, на которых приоритетом является привлечение пользователей — акцент на пользовательском опыте позволяет с легкостью вносить в дизайн требуемые изменения.
Также требуется получить обратную связь от всех заинтересованных в проекте лиц, но это значит, что приоритетом должно быть общее удовлетворении — дело в том, что отзывы инвесторов и команды менеджмента так же ценны, как и мнения представителей целевого рынка.
Как сказал американский архитектор Фрэнк Ллойд Райт (Frank Lloyd Wright): «Вы либо пользуетесь ластиком на чертежах, либо кувалдой на стройплощадке». Пользоваться ластиком на ранних стадиях гораздо эффективней, так как пользователи будут раздражены, если привычный им дизайн начнет кардинально меняться.
Запускать следует максимально оптимизированное решение, которое можно улучшать, а не кардинально менять. Цифровые продукты не высекают из камня — их следует оптимизировать на основе пользовательских потребностей и дорабатывать при помощи новых технологий.
15 способов протестировать минимально жизнеспособный продукт
Несмотря на то, что MVP предназначен для тестирования гипотез на начальных стадиях проекта, это не значит, что его легко разработать. Суть валидации идеи заключается не в определении технической осуществимости проекта, а потребности в его создании в целом и, что более важно, его способности решать проблемы, за устранение которых люди готовы платить.
Основатель Grant Snap (сервис для оформления запросов на гранты) Владимир Благоевич (Vladimir Blagojevic) написал о важности создании продукта, которым люди захотят пользоваться, и за который будут готовы платить. Однако он считает, что перед переходом к разработке конечно продукта, требуется протестировать раннюю версию оффера — время и деньги являются ценными ресурсами, тратить которые на экономически нецелесообразный продукт как минимум неразумно.
Сложность MVP зависит от продукта — в некоторых случаях, достаточно провести кампанию в AdWords или Директ, а в некоторых обязательна разработка рабочего прототипа. Для тестирования гипотез путем получения информации от пользователей могут быть использованы следующие инструменты и техники:
- Интервью.
- Beta landing page.
- Сплит-тесты.
- Рекламные кампании.
- Краудфандинг.
- Демонстрационные видео.
- Частичный MVP.
- SaaS и PaaS.
- Блог.
- Сырой MVP.
- MVP-консьерж.
- Цифровой прототип.
- Бумажный прототип.
- Однофункциональный продукт.
- Страница предзаказа.
Рассмотрим представленные выше инструменты и концепции более детально.
1. Интервью
В своей книге «4 шага к озарению» (The 4 Steps to Epiphany) Стив Бланк описал концепцию «презентации проблемы потребителям» (Customer Problem Presentation) — важный процесс валидации гипотез о целевом рынке за счет общения с его представителями.
Эта так называемая презентация представляет собой неподготовленное интервью с целевым пользователем, проводимое с целью получения информации о проблеме, которую будет решать продукт. Коммуникация может проходить в формате «вопрос-ответ» — исследователь зачитывает список проблем, а респондент высказывает свою точку зрения касательно них и оценивает степень их важности.
Прямая коммуникация является золотым источником для получения информации, которую можно использовать при принятии решений — даже если гипотезы окажутся неправильными, полученной от респондентов информации будет достаточно для изменения концепции оффера.
Также стоит заметить, что такие интервью проводятся исключительно в целях исследования — цель привлечения к пользованию оффером не преследуется.
2. Beta landing page
Beta landing page— оффер, с которым знакомится пользователь после клика по рекламному объявлению. Эта интеракция является маркетинговой возможностью, которая не только позволяет донести суть и выгоды предложения, но и привлечь к подписке и протестировать жизнеспособность, привлекательность и прибыльность оффера в реальных рыночных условиях.
На практике это доказано сооснователем Buffer Джоэлом Гаскойном, который использовал beta landing page для оценки спроса на определенный функционал и тестирования привлекательности различных тарифных планов.
За счет тестирования тарифных планов Джоэл не только валидировал готовность целевой аудитории платить за решение, но и определил наиболее привлекательные варианты ценообразования.
Один из инструкторов Tradecraft (обучающий центр в области юзабилити) Кейт Раттер (Kate Rutter) является большой поклонницей использования посадочных страниц с целью «сперва продать, потом создать». По ее словам, чтобы лендинг был эффективным, он должен преподносить правильную информацию в правильном контексте. Также важно помнить, что основными задачами MVP являются валидация и анализ, посему сбор аналитических данных является обязательным.
Немаловажным является и то, что эффективность лендинг пейдж зависит от ее составляющих (ценностного предложения, призыва к действию и так далее), которые следует сплит-тестировать и оптимизировать на основе полученных данных.
3. Сплит-тесты
Сплит-тесты используются для тестирования эффективности любых изменений, внедренных в продукт или маркетинговую кампанию: например, сравнивается эффективность двух различных макетов дизайна за счет анализа интеракции посетителей.
Одной части постелей отображается страница А, а второй — страница Б. На основе информации, собранной при помощи различных аналитических инструментов, проводится анализ эффективности офферов по ряду метрик, каковыми могут быть конверсия, показатели отказов и т. д.
4. Контекстная реклама
Отличный способ для тестирования гипотез о и на рынке. Рекламные площадки социальных сетей и поисковых агрегаторов позволяют таргетировать целевых пользователей, что дает возможность определить наиболее важные аспекты продукта за счет их представления потенциальным клиентам или целевым рынкакм.
Статистическая информация (например, клики и конверсии) об эффективности рекламной кампании также позволяет сформировать представление о том, каким должен быть и как должен работать привлекательный для ЦА продукт.
Контекстная реклама не подходит для увеличения осознанности о продукте по причине высокой конкуренции, однако является отличным способом для тестирования гипотез.
Рекламные кампании также хорошо комбинируются со сплит-тестами.
5. Краудфандинг
Краудфандинговые площадки являются не только способом для сбора средств, но и тестирования оффера, так как на них представлено множество MVP, интерес в которых определяется размером пользовательских инвестиций.
Более того, краудфандинг позволяет привлечь ранних пользователей, тем самым обеспечив получение обратной связи и распространение информации о продукте.
6. Демонстрационные видео
Если картинка стоит тысячи слов, видеоролик, в котором демонстрируется опыт взаимодействия с оффером, стоит миллиона. Наиболее известным примером использования демо-ролика с целью валидации предположений о рынке является Dropbox — трехминутный видеоролик, таргетированный на подкованную в техническом плане аудиторию, увеличил подписную базу проекта с 5 000 до 75 000 всего за 1 ночь.
Перед основателями Dropbox стояла непростая задача привлечения аудитории к продукту, который решает проблему, наличие которой ранее было неизвестно. Однако представив пользователям ценность продукта, основатели объяснили, почему за него стоит платить.
7. Частичный MVP
Минимально жизнеспособный продукт создается из доступных на рынке решений и инструментов, что позволяет предоставить ценность без затрат на разработку.
Примером этой концепции является Groupon, ранняя версия которого представляла собой комбинацию WordPress, Apple Mail и Apple Script, создающую и отправляющую PDF файлы.
8. SaaS и PaaS
В данном случае для создания проекта используются платформы и сервисы — это позволяет экономить ресурсы, а также упростить и ускорить разработку. Например, использование фреймворков позволяет избежать часто возникающих проблем (в частности потребности в оптимизации под различные браузеры), что дает разработчикам возможность сконцентрироваться на самом продукте, а не на решении распространенных проблем.
Стоит отметить, что платформа LPgenerator прекрасно подходит для SaaS и PaaS бизнес-моделей (и не только для них). У нас вы можете быстро создать эффективный бета лендинг, настроить рекламную кампанию, оповещения по email и SMS, получить доступные инструменты повышения конверсии, аналитики и многое другое.
9. Блоги
Блог позволяет валидировать бизнес-идею с минимальными затратами при таргетинге на правильный целевой рынок.
Создатель Ghost (платформа для блогинга) писал о своей идеи в блоге, постепенно формируя представление о продукте и базу заинтересованных последователей, помогающих в реализации.
Двухсторонняя коммуникация посредством контента делает блог идеальной платформой для создания интереса и получения пользовательских отзывов в процессе формирования MVP.
Более того, блог может послужить ранним прототипом продукта — книга «Бережливый стартап» Эрика Райса изначально была блогом.
10. Сырой MVP
Концепция, известная как «Волшебник страны Оз» (The Wizard of Oz), при которой продукт/сервис предоставляется вручную, а потребители верят в то, что работают с настоящим решением.
Примером этой модели является Zappos, в начале существования которого Ник Суинмерн фотографировал, покупал и отправлял обувь самостоятельно, что позволило без инвестиций валидировать наличие спроса.
Этот подход также позволяет более эффективно взаимодействовать с клиентами на важных этапах разработки дизайна — живое наблюдение за интеракцией пользователя с продуктом дает возможность получить более качественные данные, чем от проведения опроса, и определить эффективность оффера как способа решения проблем целевого рынка.
Кроме того, осуществляя функционал решения вручную, разработчик может тестировать нововведения на ходу.
Подобный MVP требует немало усилий, однако является целесообразным, так как позволяет фокусироваться на изучении проблем целевой аудитории, а не продукта.
11. MVP-консьерж
Концепция идентична модели «Волшебник страны Оз», однако пользователей осведомляют о том, что работа решения осуществляется усилиями разработчиков или тех поддержки. Оффер преподносится как эксклюзивный сервис для избранной базы клиентов.
Rent the Runaway (сервис для аренды платьев) тестировали свой оффер в живую, предоставляя студенткам возможность померить платье перед тем, как брать его в прокат — это позволило подтвердить гипотезы, что женщины готовы брать платья на прокат, а также получить отзывы о сервисе от реальных целевых клиентов.
Подобный MVP позволяет выявить важные аспекты пользовательского опыта, а также валидировать спрос на продукт и готовность аудитории за него платить.
12. Цифровые прототипы
Цифровые макеты и прототипы, демонстрирующие функционал продукта путем имитации его использования. Таковыми могут быть низкокачественные скетчи и скриншоты, а также более продвинутые приложения, которые эмулируют пользовательский опыт.
13. Бумажные прототипы
Вырезанные из бумаги или нарисованные прототипы используются с целью демонстрации и эмуляции пользовательского опыта.
У бумажных концептов есть два преимущества: во-первых, их может использовать любой член команды, а во-вторых, в них очень просто разобраться.
14. Продукт с одной функцией
Зачастую лучше сфокусироваться на ключевой функции MVP, дабы не тратить время на разработку и не отвлекать пользователей возможным конечным функционалом продукта — в начальной версии Foursquare (социальная сеть), например, была лишь функция check in.
Такой концепт позволяет максимально сузить возможный целевой рынок и фокусироваться на тестировании продукта и жизнеспособности бизнеса, вместо устранения технических проблем.
15. Страницы предзаказа
Подобно краудфандингу, страницы предзаказа создаются с целью презентации продукта целевым покупателям для привлечения их к заказу несуществующего на момент продукта.
Подобные офферы позволяют оценить спрос на конечный продукт и, соответственно, решить его судьбу еще на стадии идеи. Проблема, однако, заключается в том, что сделавшие предзаказ будут опасаться, что не получат продукт — никто не любит фантомные продукты, а пользователи, инвестировавшие в проект на ранних этапах, потребует возвращения денег.
Валидация гипотез и итерация MVP в некотором смысле усложняют реализацию проекта, поэтому при создании минимально жизнеспособного продукта важно фокусироваться исключительно на ключевых деталях и экономить ресурсы.
Также не стоит упускать из виду, что для тестирования гипотез могут понадобиться несколько MVP, поскольку продукт для бизнес-модели и продукт для тестирования рынка могут кардинально отличаться.
Создание минимально жизнеспособного продукта Spotify
Видение Spotify заключалось в предоставлении людям правильной музыки в правильное время и стимулировании артистов гонорарами, размер которых определяется частотой распространения их треков. Очевидно, что несколько лет назад создать платформу для стриминга музыки и сделать ее прибыльной было сложно, однако Spotify удалось пройти все преграды и завоевать базу в 1 000 000 платящих подписчиков в США — рынке, который был не только незнаком шведским разработчикам, но и полон конкурентов.
Как же основателям Spotify удалось реализовать свое видение не обанкротившись? Они применили итеративный подход, соединив методологии бережливости и гибкости, а также концепцию MVP.
Чтобы достичь своей текущей базы в 24 000 000 пользователей, 10 000 000 из которых являются платящими, Spotify разработали простой план быстрого и бюджетного создания прототипа, который был выпущен только по достижению определенных стандартов качества, и его итерирования на основе пользовательских отзывов.
Бережливость и гибкость
По словам консультанта бережливых и гибких стартапов Хенрика Найберга (Henrik Kniber), Spotify использовали итерационный цикл из 4 этапов, по концепции которого небольшие команды, именуемые «отрядами» (squads), выполняют серии задач, разрабатывая целостный продукт. Рассмотрим этапы этой концепции более детально:
- Думай (Think It).Определение типа продукта, разработка и тестирование прототипов в пределах компании.
- Создавай (Build It).Создание MVP, готового для тестирования.
- Предоставляй (Ship It).Постепенный запуск продукта на рынок (сбор даты и оптимизация оффера не прекращаются).
- Дорабатывай (Tweak It). Последовательная итерация на основе пользовательских отзывов, пределом которой является либо технический лимит, либо полное преображение продукта.
Принципы бережливости
Цикл «создание-оценка-информация» бережливой модели используется для достижения качества, быстроты разработки и выполнения ожидания пользователей при снижении ресурсозатратности. Основой бережливого стартапа является минимально жизнеспособный продукт — качественный продукт, созданный быстро и с небольшими затратами и предназначенный для тестирования гипотез. Из этого следует, что модель lean исключает разработку, основанную на предположениях.
Все этапы создания Spotify входят в эти рамки, так как «отряды» всегда тестируют предположения: на первой стадии тестируется концепт MVP, на второй его качество, а на третьей и четвертой, за счет последовательного запуска, сбора отзывов и итерации обеспечивается долгосрочное качество и удовлетворение потребностей клиентов.
Однако следует заметить, что модель Spotify отклоняется от бережливости на второй стадии цикла, так как тестирование проводится внутри компании, а в методологии lean делается акцент на пользовательском тестировании.
Принципы гибкости
Мышление по принципам бережливости необходимо для формирования менталитета, требуемого для внедрения гибких практик. Разница этих методологий заключается в том, что концепция lean используется для эффективного определения и создания продукта, имеющего спрос на рынке, а концепция agile для достижения этих целей в разработке софта. Кроме того, следуя гибкой методике, все члены команды работают вместе короткими отрезками (спринты от 1 до 4 недель), что позволяет эффективней реагировать на требуемые изменения (особенно на 2, 3 и 4 этапах, когда выполняется сложнейшая часть работы).
Над Spotify работал один и тот же состав специалистов на все этапах разработки. Тестирование и валидация, проводимые на каждой из стадий, удерживали Spotify в рамках бережливости, даже когда требовалось менять продукт для оптимизации под потребности рынка и потребителей.
Гибкий жизненный цикл
- Первый этап разработки (инициирование проекта и определение требований к продукту).
- Второй этап разработки.
- Третий этап разработки.
- Запуск продукта.
- Анализ обратной связи.
В случае принятия продукта потребителями проводится тестирование и оффер выходит на рынок. При противоположном раскладе цикл продолжается:
- Определение требуемых изменений и их внедрение.
- Оценка и анализ эффективности доработок.
- Последующая итерация и возвращение к первому этапу.
Изучим цикли стратегии Spotify более детально.
1. Думай
На данном этапе «отряды» работают над определением концепции продукта, а не над способами его создания.
В случае Spotify, фаза Think It является концептуальной стадией MVP, так как подтверждается жизнеспособность и тестируется спрос на продукт при помощи минималистических инструментов (целевых страниц и прототипов).
Приоритезируя жизнеспособность, Spotify убеждаются в целесообразности выделения ресурсов на построение MVP, после чего формируется небольшая команда, в которую входит менеджер продукта, разработчик и дизайнер. «Отряд» работает над созданием описания продукта, которое будет использоваться для разработки прототипа. Происходит поиск ответов на следующие вопросы:
- Кто и как получит пользу от этого продукта?
- По каким метрикам будет определяться эффективность продукта? Например, количество треков в стриминге, число загрузок и т. д.
- Каковы гипотезы?
- Как определить успешность продукта?
- Является ли продукт революционным (улучающим выбранную метрику в 2 раза)? Если улучшения по метрике минимальны, для разработки продукта должна существовать сильная стратегическая причина.
Цель заключается не в определении функционала и технических требований, а в создании ценностного предложения. Основой определения продукта Spotify был нарратив (описание продукта), эффективность которого тестировалась первой итерацией.
Spotify тестируют описания при помощи Google AdWords, а определившись с наиболее эффективным посланием, приступают к разработке низкокачественных бумажных прототипов и высококачественных рабочих. Тестирование внутри компании позволяет сузить число информативных повествований за счет определения наиболее эффективных, которые потом подбираются под прототипы.
Первая стадия является основной MVP-мышления — команда быстро и дешево определяет неправильные варианты продукта, пока не будет найден идеальный концепт.
2. Создавай
Определившись с продуктом, команда переходит от тестирования концептов к созданию реального продукта, качество которого будет достаточно высоким для запуска и тестирования гипотез о рынке.
В случае с функционирующим MVP, должен быть достигнут правильный баланс минимализма и качества — создание конечного продукта требует слишком много времени и денег, а низкокачественный оффер не позволяет получить требуемые данные и вредит образу бренда. Следовательно, Spotify должны разработать продукт, представляющий минимальную ценность, но соответствующий нарративу.
По философии Гая Кавасаки, MVP должен быть не идеальным, но революционным. Он считает, что первые пользователи сильно влияют на успешность новых продуктов, посему их привлечение является критично важным. Однако привлечь аудиторию сможет только ранняя версия оффера, которая будет соответствовать 5 качествам, описанным ниже:
- Глубокий.Качественный продукт имеет идеальный уровень функциональности, которая не перестает быть полезной через несколько недель.
- Разумный.Каждой проблеме ЦА должно быть представлено определенное решение. Более того, пользователей следует осведомить о наличии у них проблем, которые ранее не были известны.
- Целостный.Оффер является абсолютно юзабильным даже на ранних стадиях.
- Вдохновляющий.Решение подталкивает людей к действиям и привлекает их к распространению информации в целях помощи другим.
- Элегантный. Речь идет об интуитивности пользовательского интерфейса.
Основной вопрос, который задавали себе команды Spotify по продукту и менеджменту, звучал следующим образом: «Достаточно ли хорош MVP для реальных пользователей?». Закончив с нарративом, но не доработав окончательный функционал, Spotify создают продукт, соответствующий 5 характеристикам привлекательного MVP.
Spotify следовали «модели кекса», что позволило избежать неправильных заключений о продукте.
3. Предоставляй
Цель этого этапа — последовательно сделать продукт доступным для всех пользователей и убедиться в том, что он соответствует потребностям реального рынка.
Spotify предоставил доступ к продукту небольшому числу пользователей (1-5% подписчиков) для сбора отзывов. На протяжении этой стадии, гипотезы, тестировавшиеся в пределах компании, валидируются в реальных условиях.
Плюсом этой стадии является то, что от Spotify не требуется изначально предоставлять идеальный продукт, а сбор данных, итерация MVP и сплит-тестирование изменений позволяют продолжать получать ценную информацию при минимальных затратах. Предоставив продукт малой части пользователей, Spotify итерировали его до уровня EVP, после чего сделали доступным для всех.
4. Дорабатывай
Если продукт проходит предыдущие этапы, он находится в данной итеративной фазе практически весь жизненный цикл.
Несмотря на подтверждение эффективности на 3 стадии, продукт Spotify не считается конечным — команда продолжает собирать отзывы, проводить сплит-тесты и экспериментировать, в результате чего оффер либо полностью меняется, либо в него вносятся небольшие доработки. Однако, может наступить момент убивающей отдачи, при которой ценность доработок все меньше перестает покрывать их стоимость.
Spotify верят в то, что идеальных продуктов не существует, но понимают, что таковое убеждение является рискованным. Когда продукт достигает «локального максимума», при котором небольшие доработки перестают быть эффективными, команда оценивает возможности развития — если результат не стоит времени, специалисты работают над другими задачами.
Находясь на этой стадии, Spotify избегают риска стать жертвой убеждения, что продукт, вышедший на рынок первым, останется в лидерах. Учитывая, что в 2014 Spotify близко подобрались к доле iTunes на рынке музыки, можно уверенно говорить, что их стратегия работает.
Больше стадий разработки продукта = меньше рисков и затрат
Одной из критичных ошибок для большинства компаний является разработка неправильного продукта — они инвестируют огромные суммы в проекты, в которых, по их мнению, нуждаются потребители, тем самым ускоряя свой провал.
Четырехэтапный цикл Spotify позволил им точно определить правильный продукт и быстро его создать. Продолжительность стадий варьируется в зависимости от проекта, однако постоянный баланс между минимизацией затрат и увеличением качества оффера должен поддерживаться постоянно.
4 причины провала минимально жизнеспособных продуктов
Существует распространенное убеждение, что 80-90% новых продуктов проваливаются. Эти данные, конечно, имеют логическое обоснование, однако стоит задуматься: если большинство стартапов приходят к неудаче, имеет ли смысл специалистам ставить под риск профессиональную карьеру, посвящая время и талант новому продукту? Какой показатель должен быть у 10-20% успешных решений, чтобы покрыть расходы на неудачные проекты? Сколько бы времени потребовалось на определение времени возврата инвестиций? Много ли менеджеров готовы вкладывать время, деньги и усилия в реализацию новых проектов?
На самом деле, в индустрии программного обеспечения и сервиса проваливаются 39-42% решений. Это, безусловно, гораздо меньше, чем предполагают многие, однако риски нельзя недооценивать.
Далее мы поговорим о причинах провала стартапов и о том, какие риски следует систематически устранять, дабы избежать негативного исхода.
Систематическое устранение 3 типов рисков
Эш Маурья считает, что существует 3 подхода к определению наиболее рискованных предположений:
- Положиться на интуицию.
- Оценивать 3 универсальных риска.
- Узнать мнение экспертов.
Поскольку 1 и 3 подход являются наиболее рискованными, мы поговорим о применении второго с использованием бережливого фреймворка.
В одной из своих статей о запуске продукта Маурья описал способ оценки рисков, который представляет собой сфокусированную и систематическую модель мышления, основанную на философии менеджмента под названием «теория ограничений» (Theory of Constaints).
Упомянутая выше парадигма менеджмента основана на распространенной идиоме «цепь не крепче самого слабого звена», то есть слабейший член команды или часть продукта могут либо стать причиной провала проекта, либо, как минимум, негативно повлиять на его успешность. Менеджеры практикуют эту философию путем фокусировки на небольшом количестве ограничений, которые могут лимитировать продукт или систему бизнеса, и работают над реструктуризацией систем вокруг этих ограничений для достижения лучших результатов.
Концепция теории ограничений в рамках MVP имеет 5 шагов:
- Определение ограничений системы.
- Эксплуатация ограничений.
- Направление ресурсов на ограничения.
- Расширение ограничений.
- Повторение процесса.
Поговорим о способах устранения 3 типов рисков.
Риски продукта — устраняются созданием правильного оффера
- Подтверждение актуальности проблемы, которую будет решать продукт.
- Определение характеристик MVP.
- Создание и валидация MVP в малых масштабах.
- Подтверждение гипотез в крупных масштабах.
Риски с потребителями — решаются привлечением пользователей
- Определение аудитории с проблемой, которую решает оффер.
- Выявление потенциальных ранних пользователей, готовых использовать продукт.
- Привлечение можно начинать с внешних каналов.
- Последовательное создание каналов входящего маркетинга (чем раньше, тем лучше).
Риски с рынком — нейтрализуются жизнеспособным бизнесом
- Анализ конкурентов и формирование ценовой политики.
- Тестирование ценообразования на основе покупательских отзывов (путем проведения интервью).
- Анализ поведения пользователей.
- Оптимизация прибыльности бизнес-модели путем оптимизации ценовой структуры.
Поговорим о причинах провала стартапов.
Провал продукта
Решение неправильной проблемы.Подразумевается, что команда либо не определяет предназначение продукта до начала разработки, либо фокусируется на создании решения неправильной проблемы. При любом раскладе, продукт либо не будет пользоваться спросом, либо не подойдет для тестирования гипотез.
Решение неактуальной проблемы. Если неправильное решение можно доработать, то правильное, но решающее слишком незначительную проблему, оптимизировать нельзя.
Некачественная коммуникация с пользователями. Вы не сможете решить проблему целевой аудитории, если будете задавать ее представителям неправильные вопросы.
Проблемы потребителей не превращаются в требования продукту.Проблема определена правильно, однако для ее решения создается неправильный продукт.
Отсутствие итерации.Проблемы аудитории и концепция ее решения определены правильно, однако альтернативы, которые могут быть лучшим решением и давать более качественную информацию при тестировании, не рассматриваются. Отсутствие мозговых штурмов, скетчинга, установления контакта с потребителями, разработки каркаса или быстрого создания прототипов могут негативно повлиять на успешность продукта.
Избыток функций.Правильно решение с избыточным функционалом, который приводит к уходу пользователей либо их раздражению в процессе интеракции. В результате, ухудшается качество данных, полученных при тестировании — информация будет слишком разбросанной и непонятной.
Поздний запуск. Это приводит к потере ресурсов и связи с целевым рынком.
Недостаток данных.Пользовательские действия не отслеживаются или (что еще хуже) отслеживаются неправильно, что не позволяет принимать обоснованные решения и валидировать гипотезы касательно MVP.
Недостаточный масштаб. Недостаток точек данных усложняет валидацию гипотез (особенно по мере совершенствования продукта, когда вопросов о нем появляется все больше).
Проблемы с потребителями
Решение собственных проблем, а не проблем потребителей.Продукт, который решает ваши проблемы, и продукт, который решает исключительно ваши проблемы — это совершенно разные вещи. Чтобы оффер был успешным, требуется найти заинтересованную в нем аудиторию, а затем пытаться ее расширить.
Создание продукта, предназначенного для широкой аудитории.Продукт не может представлять собой решение всех проблем широкой аудитории. Создание подобного предложения приводит к двум негативным последствиям: во-первых, оффер будет решать проблемы большего числа людей, но менее эффективно, а во-вторых, определить на кого ориентировать предназначенный для широкой общественности продукт в первую очередь, крайне сложно. Привлечение потребителей является непростой задачей, требующей немало ресурсов, сложность которой возрастает в разы, если целевой аудиторией является, грубо говоря, весь мир.
Отсутствие ранних пользователей.Привлечение неправильных целевых клиентов равносильно отсутствию фокусировки на целевой рынок. Если ранним пользователям не понравился продукт, то либо решение является некачественным, либо целевая аудитория подобрана неправильно.
Отсутствие маркетингового плана и стратегии заполучения потребителей.Если продукт не будет выпущен на рынок, он медленно придет к провалу по причине отсутствия внимания.
Агрессивное продвижение продукта вместо привлечения к нему пользователей.Масштабирование email-рассылкой и холодными звонками имеет ограниченную результативность. Создание каналов входящего маркетинга является обязательным.
Проблемы с рынком
Отсутствие анализа рыночного ассортимента.Не стоит забывать о важности изучения альтернативных решений, особенно если оффер решает большую проблему.
Бесплатное предоставление решения.Вы не сможете понять, насколько продукт ценен для потребителей, если не установите на него цену (или, по крайней мере, не спросите, сколько потребители готовы за него заплатить). Кроме того, очевидно, что поддерживать продукт без финансовой базы невозможно. Несмотря на то, что проекты, получающие прибыль с рекламы, начинают с модели фримиум, они имеют план получения прибыли непосредственно от пользователей.
Неправильная ценовая политика.Это может привести к неправильной оценке ценности оффера на протяжение долгого времени. Не пытайтесь привлечь аудиторию одними исключительно промоакциями и скидками: во-первых, это может привести к негативным последствиям, а во-вторых, ценовая стратегия должна быть разработана с четким пониманием того, сколько аудитория готова платить.
Отсутствие связи между ценовой политикой и потребительской ценностью. Как правило, продукт представляет различную ценность для различных групп потребителей по ряду причин, зависящих от функционала продукта. Посему продукт должен быть дифференцирован с целью получения максимальной прибыли и предоставления максимальной ценности клиентам.
Прибыльность продукта не оптимизируется.Даже если продукт решает крайне важную проблему, может возникнуть потребность в привлечении новых клиентов или создании нового способа монетизации старых. На прибыльность влияет не только бизнес-модель, но и сам продукт.
Проблемы внутри команды
Несмотря на то, что Маурья не учитывает его в своей схеме, человеческий фактор также критично влияет на успех стартапа.
Отсутствие активности.Сами по себе планы и идеи не представляют ценности — важна их реализация. Избегайте перфекционизма и не пытайтесь продумать все наперед — вы либо потратите слишком много ресурсов, либо позволите кому-то реализовать свои наработки.
Прекращение работы.У вас может не хватить энтузиазма, ресурсов или возможностей — такое случается. Признайте, что проект закончился, и не придумывайте оправданий.
Отсутствие экспертизы.Сбор данных и общение с клиентами важны, однако если вы не знаете как анализировать обратную связь, вполне вероятно, проект будет ждать исход, описанный в предыдущем пункте.
Несогласованность целей.Если команда не работает в одном направлении, реализация проекта может быть под угрозой.
5 сверхуспешных MVP
Подходя к концу этого поста, рассмотрим несколько успешных минимально жизнеспособных продуктов.
Airbnb
В 2007 году жители Сан-Франциско Брайан Чески (Brian Chesky) и Джо Геббия (Joe Gebbia) хотели начать бизнес, но у них не было средств даже на оплату жилья. В город должна была приехать конференция по дизайну, поэтому парни решили за небольшую сумму сдать в аренду верхний этаж своего жилища посетителям конференции, которым не хватило место в отелях.
Они сделали фотографии квартиры и поместили их на простой веб-сайт — вскоре у них были 3 клиента, которые оплатили жилье на время конференции.
MVP-консьерж и общение с гостями позволили Брайану и Джо валидировать гипотезы касательно целевого рынка, определить целевую аудиторию и подтвердить жизнеспособность идеи. Они поняли, что за проживание в чужом доме готовы платить не только студенты.
В результате, 2 жителя Сан-Франциско основали Airbnb — площадку для размещения, поиска и краткосрочной аренды жилья.
Buffer
Джоэл Гаскойн не хотел тратить время на никому не нужный продукт, поэтому начал с простого теста — он создал целевую страницу с подписной формой, описанием оффера и тарифными планами, при выборе одного из которых посетителю отображалось сообщение с предложением получать рассылку и посланием о том, что продукт еще не готов.
За счет базы подписчиков Джоэл установил коммуникацию с целевым рынком и узнал его потребности, а страница с тарифными планами позволила определить готовую к конверсии долю трафика.
После того, как iTunes вытеснил их решение с рынка, команда платформы Odeo начала обдумывать новый продукт — одной из идей была площадка для ведения микроблога, получившая кодовое название «twttr».
Первый прототип использовался как внутренний сервис для сотрудников Odeo, которые им активно пользовались. Это подтолкнуло команду сделать платформу публичной, однако пользовательская база Twitter начала стремительно расти только после его презентации на конференции SXSW в 2007 году.
Zynga
Студия разработки социальных игр, которая получила больше $1 000 000 000 прибыли от in-app покупок в 2013 году. В процессе разработки компания использует целевые страницы и кампании в AdWords, чтобы определить степень интереса к игре или ее определенному аспекту.
Откручивая рекламу в online и текущих играх, Zyngа получает ценные данные, которые позволяют создать план разработки и избежать инвестирования в неинтересные аудитории игры.
Pebble
Производитель часов из электронной бумаги, которому рынок «умных аксессуаров» обязан своей популярность.
Когда закончились деньги инвесторов, основатель Pebble Эрик Мигиковский (Eric Migicovksky) начал кампанию на Kickstarter, которая в итоге стала наиболее успешной за всю историю краудфандинга — заинтересованные в продукте потребители инвестировали в него $10 000 000.
В качестве MVP использовался демонстрационный ролик прототипа, в котором звучала просьба об инвестировании. Требуемая сумма ($100 000) была собрана в течение двух часов, а к концу недели на счету проекта числилось $600 000. По окончании инвестиционного раунда, более 60 000 вложили $10 200 000 в проект Мигиковского.
На 20 марта 2014 года продано более 400 000 единиц продукции Pebble.
Заключение
В своей книге «Бережливый стартап» Эрик Райс рассказывает о том, как выбрать гипотезы для тестирования:
Выбирайте наиболее рискованную гипотезу — если вы не сможете смягчить высочайшие риски, чтобы достичь идеала, требуемого для жизнеспособного бизнеса, нет никакого смысла валидировать другие предположения.
Для большинства стартапов наиболее рискованным предположением является наличие рынка: например, Dropbox тестировали предположение о потребности решения для синхронизации файлов, Zappos определяли, будут ли люди покупать обувь online, а Airbnb валидировали готовность путешественников оставаться в домах незнакомцев. Все MVP упомянутых выше компаний были разработаны с целью получения данных, требуемых для разработки конечного оффера.
Можно сделать вывод, что MVP является больше способом мышления, нежели чем-то, что предназначено для выхода на рынок. Принципы разработки минимально жизнеспособного продукта одинаковы как для ведущих мировых корпораций, так и для предпринимателя, который верит в революционность своей идеи.
Не стоит с головой углубляться в разработку, инвестируя все доступные ресурсы — проведите детальный анализ, умеренно добавляйте функционал и удерживайте концентрацию команды, разделяя разработку на небольшие серии задач. Также не забывайте простую формулу: тестируйте, внедряйте, и снова тестируйте.
Валидируйте идеи, используя таблицу от LPgenerator, представленную ниже, и приступайте к разработке минимально жизнеспособного продукта с помощью нашей платформы.
Высоких вам конверсий!
По материалам uxpin.com, image source: Ashley Baxter