(Перед вами перевод бесплатного курса «Minimum viable products» от UxPin. Если вы здесь впервые, то лучше начните сначала)
Используйте минимализм в меру, и вы создадите изящную жемчужину, которая недорого стоит и стимулирует высокий уровень обучения. Если переборщить с шлифованием функционала, в итоге вы получите низкопробный прототип, который не просто не отвечает вашей гипотезе, но еще и может скомпрометировать ваш бренд.
Так как же создать урезанную версию продукта, которая будет доступной и привлекательной?
Начните с понимания разницы между двумя следующими вопросами:
Вопрос А: Как создать продукт, максимально простой с точки зрения технического исполнения?
Вопрос Б: Как создать продукт, который максимально прост, но при этом отвечает требованиям ранних последователей?
Первый подход ставит главной целью вывод продукта на рынок. Это приводит к таким ошибкам, как использование шины, чтобы протестировать концепцию машины. Второй подход фокусируется на ключевой ценности продукта. Этот принцип гораздо больше способствует процессу обучения, который вам так нужен.
Далее мы рассмотрим советы экспертов по использованию минимализма для создания качественного, сфокусированного эксперимента для ваших самых важных пользователей.
Используйте ваше нечестное преимущество как можно быстрее
Когда мы создавали MVP UXPin для американского рынка, мы опрашивали авторитетных пользователей, чтобы выяснить, каких функций им не хватало в существующих UX инструментах. Мы обсуждали идеи по стратегии развития продукта и даже зарисовывали wireframe-ы на салфетках. Мы просили их совета, чтобы лучше понять образ мысли ранних последователей и чтобы избежать выпуска “минимального продукта”, который не отражал бы нашего видения.
Бывший евангелист Apple, Гай Кавасаки (Guy Kawasaki), в своих размышлениях об MVP предполагает, что MVP не должен быть идеальным, но должен быть революционным. Цель минимализма — снизить время, впустую потраченное на разработку. Это возможно благодаря разработке только тех функций, которые являются вашим нечестным преимуществом, которое завоюет интерес ранних последователей.
Эти ранние последователи могут либо принести вашей идее успех, либо разрушить ее. Поэтому, чтобы извлечь максимальную пользу из этих факторов повышения эффективности, в MVP нужно сделать упор на душу вашего продукта.
Как пишет Стелла Фейман (Stella Fayman), со-основательница matchist.com считает, что для того, чтобы оставаться в строю, нужно “согласовать” три вопроса:
- Направляю ли я ресурсы на упрощение MVP (simplifying the MVP)?
- Строю ли предположения на основании лишь ключевой ценности(core value)?
- Максимально ли таймлайн соответствует проекта принципам lean?
Если бы хотите, чтобы ваш минималистический подход укоренился в реальности пользователя, особенно важно концентрироваться на втором вопросе.
Как предполагает Фейман, нужно начинать с сопоставления функций и предположений и добавлять в MVP новые слои функциональности по мере того, как предположения проверяются на практике. В этом случае, вне зависимости от глубины набора функций, вы всегда сможете с их помощью обеспечить ранним последователям стабильный опыт взаимодействия.
Понять минимализм в абстрактном плане может быть сложно, поэтому давайте рассмотрим примеры из реальной жизни:
Работая в Fliggo (сайт, который сейчас объединен с Vidly), Крис Бейдер (ныне со-основатель и chief product officer в Secret), хотел проверить предположение, что пользователям нужна возможность иметь свой собственный сайт с видео.
В то время не было возможности просто осуществить это, создав сайт на WordPress и вставив видео с YouTube. В итоге они, применив минимализм в нужной пропорции, создали MVP, который позволил Fliggo не просто проверить желание ранних последователей зарегистрироваться, но и их готовность платить.
Проверив уровень спроса на продукт, каким мы его видим, (в нашем случае проверка подтвердила правильность видения), мы можем в следующей итерации MVP проверить уровень цен. Для этого нужно повышать или понижать месячный платеж на лэндинге. Такой подход является минималистичным, так как не разрушает взаимодействие с формой при ее заполнении, а фокусируется на дальнейшем обучении.
Хотя это простой и дешевый способ, лэндинг не является универсальным инструментом любого MVP. Специалист по стартапам и основатель Extreme Lean TV, Рамли Джон не советует использовать такой унифицированный подход для любого MVP. Опасно полностью полагаться только на лендинг, потому что вы рискуете не получить никакой обратной связи от ранних последователей, зарегистрировавшихся на лэндинге (какие у них проблемы? за что они готовы платить?), а недостаток регистраций может объясняться не самим продуктом, а плохими текстами или отвлекающим дизайном.
Рамли советует другие недорогие, зато богатые на фидбэк инструменты MVP, такие как email, блоги и видео. На самом деле, как подчеркивает Рамли, известный сайт для стартаперов по поиску инвестиций AngelList тестировал свою систему нетворкинга путем рассылки электронных писем между стартаперами и потенциальными инвесторами.
Так они проверяли свою бизнес-гипотезу и, в то же время, предоставляли ранним последователям достаточно приятный опыт взаимодействия. Упростив весь процесс до одного этого нечестного преимущества, в AngelList создали правильный MVP.
Фокусируйтесь на предположениях, чтобы избежать увеличения масштаба
Важным аспектов MVP-минимализма является посвященное разработке время, потому что этот ресурс такой же драгоценный, как деньги и рабочнее время сотрудников. Хотя с проектами зачастую случается такое явление, как расширение масштаба, вряд ли это можно назвать одним из самых понятных аспектов дизайна и разработки MVP.
Так как же понять, что на разработку MVP потрачено слишком много времени? Рик Скрента, создатель поисковика Blekko, утверждает, что все зависит от продукта. Некоторым веб-приложениям (вроде Fliggo) достаточно лэндинга. Если ваше предложение подразумевает более высокий уровень ожиданий или требует большей огласки и внимания, разработка MVP может занять больше времени. Иначе из-за череcчур простого дизайна или некачественного исполнения продукта может произойти его отторжение. В качестве подтверждения этой мысли Рик приводит в пример свой поисковик, на создание MVP которого ушло 3 года.
В противоположность категории “как долго разрабатывать?” можно назвать более уместную категорию “что разрабатывать?”. В общем-то, ответ на первый вопрос неизменно отвечает и на второй. На рисунке ниже, взятом с сайта Signal vs. Noise, Райан Сингер (product-менеджер из Basecamp) предполагает, что минимализм в сфере MVP достигается через баланс между базовым качеством исполнения и соответствующим количеством функций.
Основатель KISSMetrics Нил Патель приводит несколько интересных примеров примечательно робких запусков MVP: разных по масштабу, но стабильных в плане исполнения:
- Dropbox: все началось с трехминутного видео с MVP, а в результате количество регистраций выросло с 5,000 до 75,000 человек за ночь. И это все при отсутствии реального продукта!
- Foursquare: все началось со сбора фидбэка от пользователей при помощи Google Docs;
- Virgin Air: всего 1 самолет и 1 маршрут в начале для проверки гипотезы. Самолеты и маршруты добавлялись по мере того, как совершенствовался бизнес.
- Groupon: в начале был блог WordPress с виджетом, который посылал PDF-купоны по email;
MVP Virgin был самым ресурсоемким, а вот MVP Foursquare — самым “легким”. Однако каждый MVP сложен ровно настолько, насколько сложны предположения, которые он должен проверять.
Что еще более важно, вы можете заметить, что ни один MVP не был упрощен столько, что пострадали бы его ценность или опыт взаимодействия с ранними последователями.
Сегодня Groupon, к примеру, все еще предлагает пользователя ту же ценность, что и в MVP: он рассылает купоны для клиентов по email, вот только посредством более изящного и изысканного интерфейса.
Марсин Тредер, CEO и со-основатель UXPin, уверен, что лучший способ определить правильный масштаб MVP — это понять, чем MVP не является. “К сожалению, самое распространенное заблуждение состоит в том, что MVP — это минимальный продукт”, — говорит Тредер.
“На самом деле, MVP не является самым быстрым или самим идеальным продуктом. Это, скорее, продукт, представляющий максимальную ценность, на разработку которого потрачены минимальные усилия”.
Чтобы добиться этого на практике, вы должны создать максимально эффективный тест, который либо подтвердит, либо опровергнет вашу гипотезу. Важно узнать не только то, что работает, но и то, что не работает. Так вы сможете найти нужный фокус методом дедукции.
Вне зависимости от вашей тактики, убедитесь, что ваша MVP-стратегия всегда концентрируется на проверке предположений, а не на отсечении лишних функций ради удобства. До тех пор, пока MVP отражает уникальную ценность вашего продукта, вы всегда можете добавить всякие полезности в одной из следующих итераций, основываясь на фидбэке ранних последователей.
На картинке выше отражено “ДНК” машины: относительная эффективность перемещения из пункта А в пункт Б. В каждой итерации масштаб продукта увеличивается на несколько функций, но вот уникальная ценность (быстрая транспортировка) остается неизменной.
В этом примере, достаточно было бы настолько простого MVP, как элементарный опрос людей с целью выяснить, нужен ли им более быстрый способ передвижения по городу. Именно так проще всего проверить нечестное преимущество в минимальном масштабе (то есть с минимальными затратами средств и ресурсов дизайнера и инженера). Далее, на основании фидбэка от ранних последователей, мы сможете спроектировать скейтборд, который в одной из последующих итераций станет машиной.
Гаган Бияни, со-основатель Udemy и Sprig, уверен, что первая версия MVP должна тестировать ваш ключевую ценность, в то время как в дальнейших итерациях должны проверяться новые гипотезы. “MVP не должен быть просто продуктом. Он должен быть направлен на минимально жизнеспособное тестирование гипотезы X”, — говорит Гаган. “Серия последовательных MVP, проверяющих различные предположения, позволит вам осуществлять запуск продукта быстрее и лучше”.
“MVP не должен быть просто продуктом. Он должен быть направлен на минимально жизнеспособное тестирование гипотезы X”
К примеру, одним из ранних MVP Udemy был онлайн курс за 20$, снятый со-основателями компании. Он позволил протестировать гипотезу, что люди готовы платить за высококачественный видео-курс. А в Sprig был такой MVP: участник команды на одну ночь стали доставщиками еды, чтобы проверить гипотезу о том, что еду можно достовлять за менее чем 20 минут. Как и в случае со скейтбордом, первый MVP подтвердил предположение, лежащее в основе бизнеса, что позволило тестировать более сложные гипотезы в последующих итерациях.
Пусть все будет просто и в экспериментальном ключе
Ключ успеха MVP — это тестирование рыночного спроса на какой-то альтернативный продукт без упора на конкретные функции.
Ограничив масштаб проекта до передачи лишь ключевой ценности продукта, вы получаете право на ошибку, которая вас не разорит. Запомните — цель MVP не в том, чтобы сразу попасть в точку, а в том, чтобы максимизировать обучение при минимальных затратах и не пойти по неправильному пути.
← Назад | Продолжение (Глава 2) →