Mvp проекта что это
Mvp проекта что это
Минимально жизнеспособный: как MVP помогает продукту выйти на рынок
Содержание
MVP (или Minimum Viable Product, «минимально жизнеспособный продукт») — это самая ранняя версия продукта, у которой есть минимальный набор функций, достаточный для презентации публике и проверке на первых потребителях. Однако такой продукт обязан демонстрировать достаточную ценность для пользователей.
Понятие ввел в оборот в 2001 году соучредитель и президент консалтинговой фирмы SyncDev Фрэнк Робинсон. Он определил MVP как итог «синхронной разработки» или одновременного развития продукта и исследования целевой аудитории.
MVP отличается от прототипа тем, что представляет собой рабочий продукт, который должен выполнять обозначенную функцию наилучшим образом. К примеру, это может быть бета-версия сайта компании, функциональность которой затем дополнят, изучив поведение первых посетителей.
Чем MVP полезен для бизнеса
Создание MVP дает прямые и косвенные финансовые преимущества. Оно позволяет бизнесу:
Примеры MVP
Гаррет Кэмп и Трэвис Каланик в 2010 году запустили приложение для iPhone UberCab, которое позволяло пассажирам арендовать для поездки автомобили премиум-класса всего в полтора раза дороже стоимости обычного такси. Идея у создателей родилась после того, как они заметили, что тарифы на городское такси стали несоразмерно высокими. Изначально приложение работало на ограниченной территории и с узкой целевой аудиторией, но спустя год бета-тестирования создатели смогли привлечь первые крупные инвестиции.
В 2008 году Брайан Чески и Джо Геббиа не смогли платить за квартиру-лофт в Сан-Франциско и решили проверить, существует ли спрос на аренду комнат напрямую от хозяина. Они создали простой одностраничный сайт с фотографиями своей квартиры и начали сдавать собственный чердак. Молодым дизайнерам удалось рассчитаться со всеми долгами. Уже в 2009 году их стартап привлек внимание Пола Грэма и получил первые инвестиции от его бизнес-инкубатора Y Combinator. После этого Чески и Геббиа поехали в Нью-Йорк, где ходили по домам клиентов и расспрашивали их об опыте аренды. Вскоре они поняли, что многих квартиросъемщиков отталкивают изображения плохого качества, которые фигурировали в объявлениях. Тогда молодые дизайнеры взяли напрокат зеркальный фотоаппарат и отправились по адресам в Манхэттене и Бруклине, чтобы самим фотографировать квартиры арендодателей.
Разработчики MVP стримингового сервиса сконцентрировались на функции потоковой передачи музыки. По итогам закрытого бета-тестирования приложения для Windows они заключили контракты с крупными лейблами и смогли получить значительное финансирование для своего проекта.
Авторы идеи создали MVP с чеки́нами и наградами за них в виде бейджей. После тестирования они начали расширять возможности сервиса, добавили рекомендации и путеводители по городам.
Изначально создатели сервиса купонов запустили сайт The Point, объединяющий людей, которые не могли в одиночку выполнить какую-либо задачу. Тестирование показало, что идею нужно сузить. Тогда был запущен кастомизированный блог на платформе WordPress, куда вручную добавляли информацию о возможностях коллективных скидок. При подписке на сайт его пользователи получали по почте рассылку с PDF-файлами о скидках.
Основательница маркетплейса Татьяна Бакальчук сначала закупила женскую одежду из Германии, затем создала сайт и запустила рекламу своего магазина на платформе Passions.ru. Бакальчук использовала каталоги Otto и Quelle, которые работали в России только через агентов, но не были представлены в сети. В отличие от агентов, которые брали около 15% комиссии, она выставила агентское вознаграждение в размере 10% и не брала предоплату.
История файлового хостинга началась с трехминутного демо-видео, которое объясняло идею и ценность будущего продукта. Оно получило множество положительных отзывов и набрало миллионы просмотров, что помогло привлечь инвесторов.
В 2009 году Ян Кум и Брайан Эктон решили создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании и так далее. Контакты пользователей этой книги получали соответствующие всплывающие уведомления. Однако вскоре они стали использовать статусы для общения. Тогда создатели выпустили новую версию WhatsApp с функцией отправки сообщений.
Типы MVP
Существует несколько основных подходов к созданию MVP. В зависимости от этого выделяют несколько типов такого продукта.
Волшебник страны Оз использовал трюки, чтобы притворяться тем, кем он на самом деле не был. То же можно сказать о данном типе MVP. Продукт только кажется функциональным, но на самом деле его разработчик делает всю работу вручную. Это нужно для того, чтобы проверить саму концепцию продукта и понять, востребован ли он. Так развивался сайт заказа обуви Zappos. Изначально у авторов идеи не было ни склада, ни закупленных партий товара, а существовал лишь сайт с фотографиями обуви. Когда ее начали заказывать, разработчики обновили функциональность сайта.
Продукт работает по тому же принципу, что и в случае с Волшебником страны Оз: изначально все работы выполняются вручную. Однако клиенты при этом осознают, что за товаром или услугой стоит человек. Сотрудники службы финансового планирования и инвестиций Wealthfront изначально общались напрямую с клиентами, которым нужна была помощь в управлении капиталом, а автоматизированная система появилась позднее. Такой тип MVP помогает сформировать план развития продукта и собрать фидбэк от целевой аудитории.
Цель такого типа продукта состоит в том, чтобы донести до клиентов ценность использования существующих инструментов вместо создания уникального решения. Его используют, чтобы проверить и реализовать идею без разработки уникального программного обеспечения. Так начал работать Groupon. Создатели начали с сайта на WordPress, где все взаимодействие с пользователями осуществлялось по электронной почте. Лишь позднее сервис дополнили социальными функциями, полноценной email-рассылкой и мобильным приложением.
Это рабочий продукт с минимальным набором функций, которые нужно проверить. Такой тип MVP позволяет сформировать целевую группу, получить обратную связь и проанализировать ее, а также провести тестирование функциональности.
Этапы создания MVP
Чтобы создать успешный продукт, потребуется детальный план его развития. Предварительно нужно подтвердить базовые принципы и методы MVP. Команда должна следовать им на протяжении всего процесса. При этом нужно стремиться потратить как можно меньше денег и усилий.
Выделяют несколько этапов проверки идеи и превращения ее в продукт.
Идея MVP отвечает концепции «бережливого стартапа». Главная цель создания заключается в тестировании концепции или продукта на рынке. Именно по его итогам бизнес может принимать решения о выпуске. Автор методики развития клиентов Стив Бланк говорит, что главная причина провала успешных по многим показателям проектов — это недостаточное знание своих клиентов. Это подтверждает и исследование CB Insights, согласно которому в 42% случаев причиной провала стартапа становится отсутствие рыночного спроса. Создание MVP позволяет понять потребности аудитории на ранних стадиях развития продукта и не выпускать на рынок товар или услугу, которая не будет пользоваться популярностью.
MVP подходит не только для стартапов, но и при разработке решений на предприятиях. Зачастую разработка нового продукты достаточно сложна, а изменения сопряжены с серьезными рисками. Концепция Minimum Viable предполагает небольшие и постепенные изменения, которые достаточно безопасны и позволяют внедрять функции или обновления, не доставляя неудобств клиентам.
MVP — проверка идеи «в бою». Когда это нужно бизнесу и как сделать MVP?
Подробно разбираем минимально жизнеспособный продукт: суть, виды, этапы разработки и отличия от похожих концепций.
Иллюстрация: Meery Mary для Skillbox Media
Почти 90% стартапов проваливаются, и около половины этих неудач происходит из-за отсутствия спроса на товар или сервис. Чтобы тестировать гипотезы с минимальными рисками, используют MVP — минимально жизнеспособный продукт.
В материале разберём:
Что такое MVP — на примере Uber
MVP расшифровывается как Minimum Viable Product — минимально жизнеспособный продукт. Простыми словами: это неидеальный продукт, который всё же выполняет основную функцию и уже представлен пользователям. Ключевая идея MVP в том, чтобы создать продукт с минимальными усилиями, предложить его клиентам и после дорабатывать.
Например: приложение, с помощью которого можно увидеть маршруты общественного транспорта, однако с примитивным дизайном и без дополнительных функций.
Термин в 2001 году ввёл в оборот соучредитель и президент консалтинговой фирмы SyncDev Фрэнк Робинсон. MVP применяют в разных сферах, но чаще всего аббревиатуру можно встретить в области разработки программного обеспечения и цифровых сервисов.
Сам Робинсон определял MVP как результат «синхронной разработки» — одновременного развития продукта и исследования целевой аудитории.
MVP — часть концепций Lean Startup и Customer Development. Концепция Lean направлена на то, чтобы сократить затраты на запуск бизнес-проектов. Подробно о ней мы рассказываем здесь. Customer Development — это методика исследования потребителей, в том числе и с помощью MVP. Как исследовать аудиторию — читайте в этой статье.
Один из самых известных примеров MVP — Uber. Сначала приложение могло только соединять клиентов с водителями. Когда основатели убедились в жизнеспособности идеи, они начали добавлять дополнительные функции.
Чем MVP отличается от PoC
MVP иногда путают с PoC — Proof of Concept, проверкой концепции. Эти понятия связаны, но не взаимозаменяемы. Две методики решают разные задачи.
PoC — это всё, что доказывает жизнеспособность идеи: предзаказы, инвестиции на краудфандинговых платформах, маркетинговые исследования. Основатели Dropbox показали аудитории видео о функциональности несуществующего сервиса и получили 75 тысяч подписчиков. Это послужило доказательством правильности концепции.
PoC используют в разработке MVP: собирают доказательства во время работы над продуктом или до старта, как в случае с Dropbox. Сам MVP — не аргументы за идею, а продукт, которым можно воспользоваться. Его продают клиентам за деньги.
Какие виды MVP бывают и в чём разница между ними
Можно встретить разные подходы к MVP, к классификации таких продуктов и к стадиям их разработки. Например консалтинговая компания AlexSoft, разрабатывающая программное обеспечение, выделяет четыре основных вида: однофункциональный, поэтапный MVP, «консьерж» и «Волшебник страны Оз».
Однофункциональный MVP — готовый продукт с минимальным набором функций, необходимых потребителю. В 2009 году таким был WhatsApp: его создали как приложение для отслеживания статуса контактов. Потом создатели заметили, что пользователи общаются статусами, и ввели функцию отправки сообщений.
Поэтапный, или разрозненный, MVP — сложный продукт, собранный из готовых простых решений. Пример — сервис коллективных скидок Groupon. Его основатель Эндрю Мейсон не разрабатывал уникальный софт, а использовал для создания предложений о скидках сайт на WordPress, PDF-документы из AppleScript и электронную почту.
Консьерж MVP — модель, в которой идею продукта тестируют без разработки софта. Задачи целевой аудитории решают люди, и потребители знают это. Основательницы сервиса проката дизайнерской одежды Rent the Runway лично предлагали платья напрокат студенткам. Сайт запустили, только когда убедились в востребованности сервиса, — и в первый же день на нём зарегистрировались сто тысяч человек.
Метод «Волшебника страны Оз», или MVP Флинстоуна, похож на консьержа. Всю работу делают вручную, но для потребителя создают иллюзию полноценного продукта. Основатель интернет-магазина обуви Zappos Ник Свинмерн фотографировал обувь в местных магазинах и размещал снимки на сайте. Когда поступал заказ, он покупал пару и отправлял её клиенту. В глазах покупателей процесс уже был автоматизирован, но полноценный интернет-магазин создали позже.
Как создают MVP и сколько длится процесс
Порядок действий может меняться — он зависит от рынка, команды, ниши. Чаще всего работы делят на восемь этапов:
Циклов тестирования и доработки до полноценного решения может быть сколько угодно в зависимости от продукта.
Когда MVP полностью доработан и в него добавили все запланированные функции, это уже продукт. Дальше его поддерживают или продолжают улучшать.
Что ещё почитать в Skillbox Media о работе над продуктами
Почему MVP вашего продукта может привести к краху идеи? Или как тестировать продукт на сформированном рынке
MVP(Minimum Viable Product) или “Минимально Жизнеспособный Продукт” — достаточно популярный термин среди стартапов. Но мало кто знает, что даже успешный MVP может потерпеть крах, поскольку не только качество MVP влияет на успешность проекта, но и ряд других факторов.
Часто стартапы путают термин MVP с прототипом продукта, но, к сожалению, прототип нельзя продать. MVP должен быть уже рабочим продуктом, за который ваша ЦА готова заплатить.
Успешные примеры использования MVP
Spotify
Wildberries
Татьяна Бакальчук, основательница маркетплейса, начала с закупки женской одежды, затем создала сайт и запустила рекламу своего интернет магазина на платформе Passions.ru, в первый же день получила несколько заказов. Непременно на начальном этапе развития были проблемы, но это совсем другая история. Сейчас Wildberries является самым крупным маркетплейсом в России с оборотом в 223.5 млрд рублей.
К сожалению не нашел фотографии первой версии маркетплейса.
Dropbox
Проверка жизнеспособности продукта — это не обязательно готовый сервис. В случае с Dropbox всё началось с демо-видео, в котором всего за 3 минуты была представлена идея. При этом, самого продукта ещё не было. Видео получило положительные оценки, миллионы просмотров, тысячи комментариев, и помогло привлечь инвесторов.
Всех этих проекты объединяет то, что они запускали свой продукт на несформированном рынке, либо на рынке, где нет очевидного лидера. Но что если вы решили запустить таск-менеджер с новой фичей? Либо новый маркетплейс или мессенджер?
В случае, когда рынок сформирован, MVP не даст вам результата. Вы не можете выпустить продукт с базовым набором функционала.
Когда рынок устоявшийся и на нем уже присутствуют игроки, которые решают данную потребность, вы не можете выйти с тем же базовым продуктом. Для примера можно вспомнить проект Basecamp для работы с проектами: какой вау-эффект был во второй половине нулевых, а теперь это никому не интересно. Сейчас клиентам нужен продукт, которым можно пользоваться. Также, Павел Дуров, выпуская продукт Telegram, запустил быструю версию WhatsApp, со всеми базовыми функциями которые были на тот момент. Он не сделал user experience хуже, чем в современных мессенджерах, которым пользовались многие люди, а это уже не MVP. Данный метод работает во многих сферах бизнеса. Вы не можете запустить MVP и сказать “Ребята используйте пока так, но мы скоро допилим продукт и он будет нормальным”. Только ваши друзья могут потерпеть, а клиенты запомнят какой плохой продукт и вряд ли вернутся, чтобы протестировать его еще раз после полноценного запуска. Сейчас рынку нужна хотя бы бета-версия на небольшую аудитория, либо совсем небольшой продукт без лишних фич.
Успешные проекты, которые запустились без MVP, но добились успеха:
Маркетплейс Beru.ru не запускался поэтапно, его выпустили с уже имеющимся продуктами и полезными фичами. Также, сделали крутые маркетинговые акции. Что было бы если бы это был такой же проект, как Wildberries? Или же вообще, с таким же начальным функционалом, с которым начинал Wildberries? Я думаю, проект сразу закрылся бы.
Binance.com
Когда рынок криптовалют начал набирать стремительные обороты, появилась биржа под названием Binance со штаб-квартирой в Гонконге. Благодаря удобному функционалу и доступным инструментам, биржа быстро стала популярной. Спустя 7 месяцев, на платформе было зарегистрировано более 7.5 млн человек.
Но если бы биржа пошла по пути тестирования идеи и ее презентации (как это делали другие биржи), этот рынок мог бы занять другой игрок с более удобным и мощным функционалом.
Яндекс.Такси
Когда Яндекс запустил проект с собственным таксопарком, он разработал полноценный продукт, не хуже конкурентов, которые присутствовали на тот момент. Кроме базовых функций, он смог быстрее всех подавать автомобили и тем самым вытеснил с рынка других игроков.
Основатель Zoom Эрик Юань ушел из компании WebEx, чтобы запустить собственный продукт, напрямую конкурирующий с вчерашним работодателем. Когда запускался Zoom, на рынке уже существовали такие игроки как Skype, Google Hangouts и другие. Главным драйвером роста для Zoom были привлекательные условия с заметно лучшим качеством связи. Когда остальные продавали видеоконференции за 30-70 долларов в месяц. Zoom предложил 40 минут бесплатного общения, либо безлимит всего за 15 долларов.
MonoBank
Мобильный банк, созданный бывшими топ менеджерами “ПриватБанк”. Когда ребята запускали Mono Bank, они по сути создали лучшую версию “ПриватБанка”. Главной фишкой нового банка стал кэшбек. На данный момент, банк имеет более 1.3 млн клиентов.
Подобных проектов, которые смогли предложить рынку лучшую услугу, чем доступные на рынке в тот момент, достаточно много. Поэтому, на уже сформированном рынке сложно разработать продукт с минимальными затратами, только чтобы проверить гипотезу.
Давайте рассмотрим примеры проектов, которые не смогли добиться успеха, так как их продукт проигрывал конкурентам по user experience.
Стартапы с хорошей идей, но с провальным MVP
Социальная сеть “Аура”
Когда Яндекс объявил о запуске социальной сети Аура, все побежали регистрироваться и тестировать продукт. Фишка социальной сети была в том что сервис автоматически подбирает собеседников и сообщества на основе предоставленной пользователем информации: увлечения, геолокация, лайки и т.п.
В первый месяц проект был достаточно популярным, но, со временем, люди перестали им пользоваться, т.к. социальная сеть работала только в официальном приложении от компании Яндекс. Социальная сеть не имела отдельного приложения и имела ряд проблем, которые усложняли взаимодействие с “Аурой”. По итогу, в августе 2020 года компания Яндекс объявила о закрытии социальной сети Аура.
Браузер Амиго
Интернет браузер “Амиго” от IT гиганта Mail.ru был запущен в 2011 году, но так и не добился успеха. Кроме того, что браузер не особо выделялся среди своих конкурентов, так он еще и заработал плохую репутацию за счет агрессивного маркетинга. Пользователи жаловались, что браузер устанавливается без их разрешения. Здесь та же история с user experience.
Мессенджер «ICQ»
Достаточно популярный мессенджер в начале нулевых со временем стал никому не нужным, т.к. на рынке появились конкуренты, которые предложили решение той же потребности с лучшим user experience и дополнительными фишками.
Flatora
Travelmenu
Подводя итог, хочется обратить внимание новых стартапов, которые планируют выйти на сформированный рынок, что перед запуском бета версии следует убедиться, что ваш продукт, как минимум, имеет базовой функционал, покрывающий основные потребности рынка, и имеет свою уникальность — особую фишку, за счет которой вы будете привлекать пользователей.
MVP – это не черновой вариант! Точно?
Что такое MVP?
MVP (minimum viable product — минимально жизнеспособный продукт) – это продукт, который разрабатывается с максимальной экономией денег и ресурсов, как правило, с единственной целью – проверки гипотезы. Гипотеза, как правило, заключается в необходимости и/или полезности этого продукта.
MVP ни в коем случае не означает “черновой вариант”, сделанный в спешке, который после завершения выбросят и будут писать с нуля.
Если вы убеждены в обратном, то вам точно стоит остановиться, пересмотреть приоритеты разработки и прочитать эту статью. Стоит уменьшать функционал продукта, но ни в коем случае не пытаться сделать все и сразу, в безумной спешке, упуская важные части функционала и оставляя за собой вереницу багов. Нужно точно определить, какой функционал является основным, а какой не используется в большей части случаев.
В этой статье я расскажу о нашем личном опыте создания MVP и в конце приведу список полезных советов, которые вы сможете использовать в своей разработке.
Личный опыт создания MVP
Как правило если вы создаете MVP, то вы ограничены во времени и человеческих ресурсах. Так, например, у нас было на создание “минимального” проекта было около трех месяцев, один frontend-разработчик и один backend-разработчик на старте. Позже присоединилось еще два backend-разработчика. Но в любом случае это небольшие человеческие ресурсы. Поэтому, первый и главный шаг – определить основной функционал, без которого это приложение не имеет смысла, то ключевое действие, которое должно осуществляться.
На старте создания продукта у нас было описание продукта с абсолютно всеми хотелками. Продукт разрабатывался для внутреннего использования в компании, поэтому заказчики были по совместительству и будущими пользователями. С одной стороны это упрощало задачу, потому что можно было вести постоянную коммуникацию и собирать обратную связь в процессе разработки. Но с другой стороны, это и мешает процессу упрощения продукта, т.к. появляется множество пунктов “нам хотелось бы вот так”. Поэтому приходилось балансировать на каждом этапе… По статистике из всего существующего функционала приложений постоянно пользуются всегда только 12%. В нашей ситуации можно было очень удобно приоритизировать части “хотелок” обычным вопросом “а насколько это необходимый функционал?” и выбрать в список MVP только самые ожидаемые.
Что касается технической стороны разработки, нужно сразу понять, от каких элементов стоит отказаться. Самая большая и распространенная ошибка разработчиков в том, что mpv это “черновой вариант”. Это не так! В будущем, при успешной проверке гипотезы, было бы здорово просто продолжить разработку текущего продукта, а не выкидывать на ветер все деньги, потраченные на разработку текущей версии продукта. Поэтому не стоит подходить скептически, например, к покрытию тестами MVP.
От чего мы НЕ отказались:
Рефакторинг
То, от чего точно не стоит отказываться. При создании минимального продукта очень важно, чтобы он был гибким, масштабируемым и готовым развиваться в любую сторону. Поэтому если становится очевидным, что какая-то часть приложения не является гибкой или потенциально не способной к масштабированию, то стоит остановиться и исправить положение, потому что в будущем это может обернуться плачевно.
Стиль кода и линты
Казалось бы, такое можно упустить, но нет. Акцент на стиль кода как никогда уместен там, где важна скорость. Потому что на любом этапе разработки может появиться возможность подключить дополнительные ресурсы в виде людей. Максимальная скорость входа нового разработчика в контекст – наша основная цель. Сюда же относится и наличие документации. Появление нового человека в команде должно ускорять разработку, а не замедлять. Замедлиться она может от появившихся у него большого количества вопросов по коду и приложению в целом. Поэтому как и технические, так и архитектурные моменты стоит сразу вносить в документацию.
Дизайн
Крайне спорным моментом в разработке оказалась потребность в дизайне. В действительности ожидать разработки дизайна прежде, чем начинать разработку продукта, было бы крайне глупо – порой на разработку дизайна может уйти больше времени, чем выделено на всю разработку. Но в тоже время стоит помнить, что очень важно сделать продукт, которым захотят пользоваться. Будет везением, если у разработчиков есть крайне редкая способность делать “красиво”, но в действительности это не всегда так.
От чего мы все-таки отказались
Процессы
Процессы – то, чем мы действительно пожертвовали. Построение процессов это всегда дорогостоящее действие. Конечно, у нас были элементарные: постановка задач, спринты, ориентированные на выполнение целостной части функционала, попытки оценивать задачи. Но в действительности все выходило из под контроля, так как всегда нужно было быть максимально гибким: где-то задачу можно было упростить, а где-то внезапно нужно было доработать функционал, который был упущен или трактован неверно. Но тем не менее мы всегда ставили для себя небольшие ориентиры в виде ближайших дедлайнов с пониманием, что должно быть готово к этому моменту.
Что еще может ускорить разработку MVP?
Уже готовые наработки. На этапе создания MVP точно не стоит заниматься разработкой своих библиотек и плагинов. Максимальную часть таковых стоит брать извне и обращаться к Open Source. Возможно какие-то части функционала уже разрабатывались в других продуктах вашей компании или вами ранее в свое удовольствие. В том числе, это касается и компонентов. Отлично, если в вашей компании уже существует единый UI Kit, который можно использовать. Как результат: ускорение разработки и единый стиль продуктов компании из коробки. Об опыте использования единого UI Kit-а в компании я рассказывала вот в этой статье.
Прямая коммуникация разработки и заказчиков
Многие разработчики не любят общаться и коммуницировать в жизни, не то, чтобы общаться с заказчиками. Но общение действительно обладает большим потенциалом в ускорении разработки. На нашем опыте было много ситуации, когда заказчики неявно навязывали какое-то техническое решение, к которому они уже привыкли или придумали сами. Но выяснив настоящую цель, зная о самих целях продукта, возможностях текущего приложения и уже реализованного функционала, разработчик может предложить решение, которое в тоже время поможет решить задачу заказчика и сэкономить львиную часть времени.
Быть командой, а не набором специалистов
Повышенный уровень коммуникаций в команде поможет быстрее приходить к оптимальному решению. Например, у нас постоянно напрямую коммуницировал Frontend и Backend, садясь за стол переговоров и решая, на какой стороне будет осуществляться та или иная логика, кто будет определять формат контрактов и какие данные действительно понадобятся в API. Очень важно, чтобы каждая часть разработки могла оперативно реагировать на просьбы другой части, чтобы не блокировать разработку в целом.
Мотивация команды и разработчиков лично
Создание MVP иногда может быть стрессовым и вызывать много спорных моментов, в которых могут рождаться жаркие и порой непростые споры. Очень важно, чтобы в таких ситуациях кто-то выступал катализатором и не позволял команде терять мотивацию и командный дух. Как правило, это обязанность руководителя текущей разработки, но часто бывает так, что ему просто некогда или, что еще хуже, просто нет до этого дела. Не стоит недооценивать, насколько это сказывается на скорости разработке. Сплоченная и мотивированная команда лучше коммуницирует и охотно задержится вечером перед дедлайном по своей воле и желанию.
Четкое распределение ответственности: как ролей, так и разработки
Касаемо разработки у нас была договоренность, которая точно ускоряла процесс. А именно – все необходимые API и требования back ждал от front-а, а требования на front поступали от совместных коммуникаций с заказчиками и резюме технолога. Так если на backend чего-то не хватало в API, ответственность за это лежала на frontend части, каким бы это странным не казалось. Но это было нашим внутренним соглашением. Касаемо контрактов была договоренность, что конечное решение всегда было за back-ом, а с front всегда шло предложение и необходимые данные. Такие внутренние соглашение о том, на ком лежит ответственность за конкретные части приложения и разработки, значительно ускоряет и сам процесс разработки, и помогает избегать спорных моментов.
Когда коммуникация идет напрямую между разработкой и заказчиками, то стоит определить в самом начале, кто ведет встречи и какому плану все следуют, кто именно принимает на себя роль аналитика (если такого не имеется), а кто предлагает конечное решение. У нас в команде роли были “размазаны” по всей команде и в этом нет ничего плохого, а вот четко не определенная конечная ответственность – это действительно проблема. Это может превратиться в “дважды соленый суп, из-за двух поваров на кухне” и “забытого ребенка в детском саду”. Распределением ответственности в команде опять же должен заниматься руководитель текущей разработки.
Синхронизация понимания продукта
В начале разработки продукта очень важно выстроить план построения архитектуры приложения и коллективно обсудить это с командой – так мы поступали перед каждой сложной частью приложения. Описание архитектуры разработки, ряд обсуждений, и мы получаем готовый план. На такую документацию ориентировались одновременно и front, и back, и дизайн, и даже аналитик. Так у нас всегда было общее понимание приложения, и мы не тратили время на то, чтобы подстраиваться друг под друга. Самый простой пример: у нас была сложная работа с данными и табличным представлением. У каждого ключа этой таблицы могло быть свое представление. Прежде чем делать дизайн, или frontend часть, или логику на back-е, или организации данных в базе, очень важно было синхронизировать понимание всех этих частей в единую картину и прийти к соглашению о названиях и терминах. С этим же помогал нам и общий глоссарий. Казалось бы мелочь, но это действительно упрощает коммуникации. Как следствие – ускорение разработки. Отлично, когда аналитик и дизайнер понимают, что такое компонент; front и back называют одни и те же данные одним именами; заказчики и разработка называют одну и ту же часть функционала один и тем же именем.
Резюмируем:
MVP не равно “черновой вариант”!
Мне очень понравилась иллюстрация, которую я прикрепила в начале статьи. Она хорошо отображается суть разработки, где на каждом этапе мы имеем уже работоспособный и полезный продукт. Дальше он только улучшается и дополняется новым функционалом, а не разрабатывается функционал, который сам по себе не имеет никакого смысла и не является целостным.
В этой небольшой статье я поделилась нашим опытом создания MVP и некоторыми советами, которые подчеркнула для себя из проделанной работы. На данный момент MVP успешно прошел этап подтверждения гипотезы, и ожидается дальнейшая его разработка без выбрасывания уже разработанной части.
Спасибо, что прочитали мою статью до конца. Оставляйте полезные советы о разработке MVP из своего личного опыта в комментариях и задавайте вопросы, если такие остались.
Секрет успешных стартапов. Minimum Viable Product: что это, и как его создают
MVP — это не только лучший игрок в команде (most valuable player). В сфере стартапов это ещё и минимально жизнеспособный продукт (minimum viable product). Сервис, обладающий достаточными качествами для того, чтобы привлечь первых пользователей.
Это очень важно в условиях, например, стартапа — для получения обратной связи и понимания того, в какую сторону стоит двигаться (и стоит ли двигаться вообще, или лучше похоронить идею).
Сбор информации через MVP — обходится намного дешевле, чем разработка полноценного продукта с большим набором функций. MVP позволяет во много раз снизить затраты и риски, и, при грамотном подходе, в итоге выйти на бизнес-идею, которая работает.
Для примера, возьмем онлайн-планировщик. Сразу мечтать о создании конкурента ToDoist или Trello — нет смысла. На такое не хватит никакого бюджета, и даже с неограниченными финансами (см. Google) победа не обеспечена. Поэтому в соответствии с теорией MVP-тестирования нужно создать основу, «костяк» продукта. Например, простой сервис, способный записывать новые задачи и отмечать их как сделанные, с тегами, возможностью фильтрации и выставления приоритетов.
Когда хорошие стартапы задумываются о выпуске планировщика, они обычно начинают с этого короткого списка. А дальше всё зависит от дизайна, маркетинга и пары-тройки выделяющихся функций. Если пользователям понравится — можно развивать идею, добавлять возможности и постепенно становиться одним из главных игроков. Если MVP себя оправдал.
Термин «минимально жизнеспособный продукт» был придуман Фрэнком Робинсом в 2001 году. И популяризован Эриком Рисом, который в 2009-м в деталях описал его в своём бестселлере Lean Startup (на русский его перевели как «Бизнес с нуля»).
Как видим, концепт родился сравнительно недавно. В России о том, что такое МВП, и о его принципах почти не знают. К большому сожалению, у нас больше укрепились модели «выйдем и сразу всё захватим!», где компании прожигают сотни миллионов, стараясь сразу стать монополистом. А также модели «Яндекса», Mail.ru и «Сколково», когда новые идеи подводят под технологические цепочки существующих крупных компаний. Мы в Rubrain занимаемся разработкой MVP для стартапов из США и Британии уже около пяти лет, и знаем, что если у вас мало денег (и они свои) — это единственный путь к созданию успешного проекта.
Почти все успешные стартапы на Западе начинают свой путь к успеху с минимально жизнеспособного продукта. Это наименее опасный и затратный подход, об этом хорошо знают жители Кремниевой долины. Другой вариант — «откол» проекта от более крупной компании, или разработка большого продукта после привлечения солидных инвестиций (зачастую — от сооснователей).
Но всё же большая часть известных в США и Европе стартапов начинали с простой версии MVP, которая позволила им протестировать рынок, набрать базу клиентов, освоиться, доказать инвесторам свою идею, а потом — начать добавлять в продукт новые функции и продолжить развивать успех.
Вот пять характерных примеров:
MVP отличается от раннего релиза проекта с открытым исходным кодом, поскольку релиз учитывает потребности и предпочтения пользователей, но не рассчитан на то, чтобы они напрямую определяли направление развития продукта. Видение проекта зачастую уже существует, и оно будет поддерживаться на протяжении всего жизненного цикла, несмотря на наличие прямой и косвенной обратной связи. MVP призван проверить потребность рынка, а если её нет — попробовать её создать. До вложения большого количества денег и времени.
Dropbox стал одним из характерных примеров MVP
Стив Бланк считает, что стратегия создания минимально жизнеспособного продукта может быть использована как часть методологии custdev (развития клиента). Это один из принципов движения «Бережливый стартап». Ученик Бланка Эрик Рис и сделал MVP частью дискуссии в кругах Кремниевой долины. Это самая успешная стратегия быстрого тестирования идей, получения обратной связи с клиентами и выбора жизнеспособной бизнес-модели.
Кстати, стратегию можно сделать ещё успешнее, если представлять аудитории несуществующие продукты и функции, и проверять свои гипотезы путём A/B-тестирования среди веб-пользователей. В основном стартапы, с которыми сотрудничает Rubrain, до обращения к нам именно так и поступали. А потом приходили к нам с уже оформленным планом: какие возможности должен содержать их MVP, и какие функции (скорее всего) нужно будет добавлять в их сервис или программу по мере получения одобрения от рынка.
Конечно, минимальный жизнеспособный продукт имеет свои недостатки. Первый, очевидный — срезание углов не в тех местах. Конечно, целью является создание сервиса с минимумом затрат, и только самыми ключевыми функциями. Но некоторых затрат всё равно не избежать. А некоторые вещи урезать нельзя.
В первую очередь это касается пользовательского опыта. Хороший UX — вещь обязательная. Без него весь MVP может показывать, что проект «не взлетает» и не оправдывает ожиданий аудитории. В то время как проблема состоит только в UX, а весь остальной продукт работает вполне достойно.
Другая проблема MVP — состоит даже не в таком продукте, а в подходе, который иногда с ним ассоциируют. Рид Хоффман, основатель LinkedIn, как-то сказал: «Запуститесь так рано, чтобы вы были опозорены своим 1.0 релизом». Конечно, он имел в виду, что это потом заставит вас работать сильнее. Но такая стратегия приносит больше вреда и компании, и её пользователям. MVP — это, наоборот, продукт, за который не стыдно. Пусть по нему видно, что он бюджетный, но он показывает потенциал. И не отталкивает, а привлекает аудиторию.
Мы в Rubrain не раз замечали, что для многих команд главная проблема с разработкой MVP заключается даже не в самом проекте, а в отношении к нему. Они используют не тот подход. Идея MVP в том, чтобы это был процесс создания крутого продукта. Первый жёлтый кирпичик по дороге в Изумрудный город. Вместо этого разработчики рассматривают MVP как отдельную цельную вещь, и не уделяют должного внимания сбору данных или анализу аудитории. Которые потом позволили бы скорректировать продукт и сделать его успешным. Они выпускают такие MVP, которые скорее похожи на прототипы или концепты. И слишком сосредоточены на своей изначальной идее, даже если рынок намекает на её несостоятельность.
Из-за ловушек сознания, к которым иногда может привести MVP, в последние годы появилась другая идея. Некоторые стартапы теперь ставят своей целью не Minimum Viable Product, а Minimum Valuable Product (MVaP). Минимальный ценный продукт. Так становится проще напоминать себе и команде, что задача — не выпуск какой угодно вещи при низких затратах. А создание продукта, который несёт в себе какую-то ценность для пользователей. И позволит вам набрать изначальную аудиторию, поведение которой потом можно будет анализировать.
MVaP ставит в приоритет своих пользователей, их потребности и ожидания. Проводит исследования, анализирует юзабилити, оценивает демографию, создает use cases. Всё с целью определения наилучших способов для удовлетворения запросов потенциальных клиентов.
Обычно есть несколько разных идей о том, как лучше достигнуть этой задачи. Здесь на помощь приходит тестирование прототипов. Функциональные прототипы представляются реальным пользователям, чтобы увидеть, какой вариант устроит их лучше всего. Это важный шаг в создании MVaP.
Но минимально ценный продукт должен приносить пользу не только клиентам. Он создаёт ценность и для самого проекта. Как и MVP, он обязан уметь извлекать полезную информацию о том, как продукт воспринимается рынком.
Ценность с MVaP также создаётся для бизнеса в целом. Один из рисков выпуска MVP, минимально жизнеспособных продуктов, — в том, что они могут плохо отразиться на бренде (если сделать это неаккуратно и представить «сырой» вариант). Крупная компания, от которой пользователи ждут определенного уровня, позволить себе такого не может. Поэтому для её лучше выбирать более безопасный путь — MVaP. Такой продукт часто стоит дороже в разработке, зато он гарантированно несёт в себе ценность, и позитивно влияет на имидж бренда, который он представляет. По этой стратегии с нашими программистами сейчас сотрудничают «Яндекс» и Mail.ru.
Если вы не крупная компания, и создаете буквально один из своих первых сервисов, концепт простого MVP для вас вполне подходит.
Для начала нужно определить проблему, которую продукт будет решать. И создать проект с минимальным набором функций, решающих эту проблему. А дальше — начинать учиться понимать пользователей, и улучшать свой продукт в соответствии с реальными требованиями рынка.
Идея в том, чтобы сервис проверил ваши основные предположения. Может ли это быть чем-то, чем люди интересуются? Если да, то дальше стартап может развивать свою деятельность: набирать команду, искать финансирование.
Итак, по шагам, нужно:
Раньше, на «Диком Западе» интернета, всё было попроще. Но сейчас успех стратегии MVP во многом зависит от продуманного бизнес-плана. В США для этого сейчас любят использовать канву бизнес-модели. Этот полезный инструмент был предложен в 2005 году Александром Остервальдером, швейцарским предпринимателем и бизнес-теоретиком. Почитать о нём подробнее можно в интернете, для этого есть десятки специализированных сайтов. Но если вкратце, такая канва позволяет на одной странице описать все основные бизнес-процессы компании. В том числе:
Канва бизнес-модели — простой способ прийти к тому, как должен выглядеть ваш минимально жизнеспособный продукт. В ней есть все модули, необходимые для формирования общей стратегии.
Главное — это позволяет лучше понять, на каких функциях сосредоточиться, в чём основная цель продукта, и что будет отличать его от конкурентов.
Взять, к примеру, первый iPhone. Все телефоны в то время имели ряд функций, которые Apple специально не включила в свой девайс. В нём не было функции копирования и вставки (!), не было SDK, не было 3G-связи. Даже нельзя было отправлять текстовые сообщения сразу нескольким контактам.
Но Стив Джобс знал, на чём сосредоточиться. Он представил MVP, минимально жизнеспособный продукт. С мультитачем и большим экраном. В нём были ровно те основные возможности, которые выделяли его на фоне остального рынка. На отсутствии привычных фич специально не заостряли внимание — ни публики, ни разработчиков. Аудитория этот MVP, как показывает история, приняла, и теперь, на двенадцатой итерации, в смартфоне есть все недостающие функции, и даже более того.
Если вы пока что не Стив Джобс, есть некоторые полезные сервисы для начала работы над своим первым минимально жизнеспособным продуктом:
Можно обратиться к опытной компании, предлагающей свои услуги по разработки MVP для стартапов. У неё должно хватать дизайнеров и программистов с опытом в этой сфере. Заказчики с идеей и определенным количеством денег сейчас обычно так и делают. Не обязательно искать разработчиков, решать легальные вопросы, с нуля создавать команду. Если есть хорошая идея и вариант её продвижения — найдется достаточно опытных фирм, которые возьмутся за работу за вас. Это будет намного дешевле, чем начинать с нуля, а временные затраты несопоставимы.
В следующем материале расскажем о примерах крутых идей для MVP, которые позволили основателям компаний почти из ничего создать бизнесы на несколько миллиардов.
MVP (минимально жизнеспособный продукт)
MVP (minimum viable product) — это минимально жизнеспособный продукт. Такой продукт обладает ограниченным функционалом, но его достаточно, чтобы потребители начали им пользоваться.
Для чего нужен MVP
MVP проверяет рабочие гипотезы и помогает получить отклик потребителей.
Нередко компании тратят годы работы, чтобы убедиться в том, что они выбрали неправильный путь. Тщательно проработанный продукт, на который потрачено много времени и средств, оказывается никому не нужным. Исследование CB Insights показало, что в 42% случаев причиной провала стартапа становится отсутствие рыночного спроса. MVP помогает убедиться в востребованности продукта или своевременно отказаться от убыточной идеи.
Ключевая идея MVP заключается в том, что вы создаёте реальный продукт, который можно предложить клиентам. А дальше вы наблюдаете за реакцией на него и дорабатываете решение с учётом предпочтений потребителей.
Основная задача MVP — сократить время и усилия на тестирование идеи до начала разработки полноценного продукта.
Минимально жизнеспособный продукт позволяет:
Разновидности MVP
«Выдуманный» продукт
В качестве MVP клиентам представляют ещё не существующий проект как реальный продукт.
Пример Wizard Of Oz MVP — крупнейший обувной интернет-магазин Zappos. Его со-основатель Ник Свинмерн для проверки бизнес-идеи размещал в сети фотографии обуви, сделанные в местных магазинах. Если клиент заказывал товар, Свинмерн шёл и покупал нужную обувь, а затем отправлял заказчику. Для клиента процесс выглядел полностью автоматизированным. Так Свинмерн смог убедиться в востребованности идеи и решиться на открытие настоящего интернет-магазина.
Сервис проката дизайнерской одежды Rent the Runway протестировал свою идею, предлагая платья на прокат студенткам. Когда основательницы убедились, что их идея востребована, они запустили сайт сервиса по аренде платьев. В день запуска в сервисе зарегистрировалось 100 тысяч человек.
MVP-контент
Идею представляют через контент. Причём сам минимально жизнеспособный продукт может ещё не существовать.
История компании Dropbox началась с короткого видео о функционале сервиса.
Обзор привлёк 75 тысяч подписчиков, которых заинтересовала идея облачного хранилища. А основатели смогли таким образом убедиться, что бизнес-идея жизнеспособна.
Целевая страниц а. Принцип в том, что для тестирования идеи создают страницу несуществующего продукта. А дальше анализируют реакцию пользователей.
Прежде, чем создать сервис отложенных постов для соцсетей Buffer, его основатель Джоэл Гаскойн рассказал в Twitter о функционале инструмента. Заинтересованные люди могли перейти по ссылке «Планы и цены» и оставить свой email.
Убедившись, что идея интересна людям, Джоэл представил потенциальным пользователям три варианта тарифов.
Только после подтверждения того факта, что люди готовы платить за реальный продукт, Джоэл приступил к разработке Buffer.
В 2006 году Тим Феррис искал лучшее название для нынешнего бестселлера «4-часовая рабочая неделя: побег 9-5, живи где угодно и присоединяйся к новым богатым». Тим запустил несколько рекламных объявлений через Google Ads с рекламой книги под разным названиями. Затем он выбрал название, которое привлекло больше всего внимания. При этом поначалу автор отдавал предпочтение совсем иным наименованиям.
Сбор средств
В этом случае гипотезу проверяют, собирая средства на создание продукта. Если идея вызывает отклик аудитории и люди готовы платить за продукт, можно запускать проект.
Компания Sony использовала стратегию предпродажи для Playstation 4. До выпуска продукта компании удалось привлечь 1,5+ млн предзаказов.
Однофункциональный MVP
Одной из самых частых ошибок многих MVP становится перенасыщенность функциями. При тестировании идеи сложно понять, какая именно фича привлекла внимание аудитории. Цель однофункционального MVP — продемонстрировать самую главную функцию, ради которой потребители будут использовать продукт.
Мессенджер WhatsApp был создан на основе однофункционального MVP. В момент запуска в 2009 году мобильное приложение не имело функций для отправки сообщений. Единственное, что могли делать пользователи, — указывать свой текущий статус, который тут же видели другие пользователи из списка контактов.
Вскоре создатели мессенджера заметили, что пользователи используют статусы для обмена мгновенными сообщениями. С этого времени началась активная доработка приложения и привлечение инвесторов. К февралю 2013 года база WhatsApp увеличилась до 200 миллионов активных пользователей.
Как создать MVP
Составить подробную инструкцию по созданию MVP довольно сложно. Порядок действий варьируется от типа продукта, рыночной ситуации, возможностей команды. Но в общих чертах порядок создания minimum viable product можно представить в виде следующей последовательности этапов.
1. Определите основную задачу продукта
Чтобы продукт был востребован, он должен решать конкретную проблему потребителя. Поймите, зачем потенциальному клиенту нужен ваш продукт и почему он должен его приобрести. Подробно сформулированный ответ поможет понять, какие задачи должен решать MVP в первую очередь.
2. Установите «узкую» целевую аудиторию
Огромная ошибка — создавать MVP для широкой аудитории. Большой объём информации и слишком большое количество противоречивых отзывов от пользователей затрудняет поиск рабочей модели продукта. Поэтому важно сузить аудиторию.
На этой стадии опишите портрет идеального покупателя — человека, которого точно удовлетворит ваше решение. Чем точнее вы опишите своего клиента, тем лучше:
В процессе тестирования MVP предлагайте продукт аудитории, которая максимально соответствует образу идеального покупателя.
3. Исследуйте конкурентный рынок
Даже если вы придумали действительно новый продукт, возможно, на рынке уже существуют похожие решения. Изучите рынок и выясните, что именно предлагают конкуренты, какую долю рынка занимают, как привлекают клиентов. Сторонний опыт может пригодиться при корректировании собственного решения.
4. Выполните SWOT-анализ
SWOT-анализ — это методика стратегического планирования. Её суть состоит в анализе факторов, влияющих на исследуемый объект.
В частности нужно определить для продукта:
Сильные и слабые стороны обусловлены влиянием внутренних факторов. Возможности и угрозы относят к внешним факторам. Задача SWOT-анализа — сосредоточиться на преимуществах, выявить и минимизировать недостатки, предотвратить вероятные угрозы и полноценно использовать имеющиеся возможности для развития.
5. Постройте карту пути клиента
После того как вы проанализировали будущий продукт, самое время оценить его с позиции потребителя. Нужно понять порядок действий пользователей для приобретения вашего MVP.
Путь клиента должен быть коротким, простым и удобным. Подробное описание всех действий клиента поможет понять, какой информации не хватает или какие детали помогут в представлении продукта.
6. Выберите основные функции
Возможно, ваш конечный продукт будет решать сразу несколько задач. Но большое количество возможностей на этапе тестирования лишь запутает потребителей. Вы не сможете полноценно протестировать идею и потеряетесь в огромном объёме отзывов.
Для начала выделите основные функции, которые позволяют решить главную задачу продукта. Таких функций не должно быть много — одна, две, три — и именно они составят основу MVP. Все прочие возможности отсортируйте по степени важности — их вы добавите после запуска продукта, сбора обратной связи и анализа результатов тестирования.
7. Найдите оптимальный метод разработки и создайте MVP
Существует несколько методов разработки программного обеспечения, применимых к созданию MVP:
8. Запустите альфа- и бета-тест MVP
Первую версию продукта запустите для узкой группы потребителей. Это альфа-тестирование. Обычно первыми пользователями становятся друзья, знакомые, родственники. Если недоработок нет, можно перейти к бета-тестированию. Предложите продукт реальным потребителям. Спустя одну-две недели соберите и проанализируйте обратную связь. Доработайте MVP и снова протестируйте.
Длительность и количество циклов тестирования-доработки всецело зависит от продукта и от того, как быстро удастся создать полноценное решение. Возможно, что спустя несколько циклов придётся вернуться на первый этап или продолжить итеративное улучшение MVP. В любом случае решение вы будете принимать не на основе предположений, а исходя из реальных фактов.
Основная ошибка при создании MVP
При разработке MVP очень важно найти оптимальное соотношение затрат и качества. И зачастую акцент делают на минимализме, чтобы сэкономить средства и время. В итоге потребители критикуют сырую тестовую версию, а разработчики ошибочно отвергают саму идею.
MVP нередко путают с PoC (Proof of Concept) — доказательством правильности концепции. Хотя эти понятия похожи, но они не равносильны. PoC — это демонстрация практической осуществимости метода, технологии или идеи. Для этого создают небольшой образец или прототип, который может обладать лишь частичным функционалом итогового продукта. Так подтверждают, что выбранный способ создания или технологию реально применить на практике. MVP — это не доказательство, а вполне работоспособный продукт.
В то же время MVP нельзя назвать классическим прототипом в виде схематичных набросков. Несмотря на то, что это жизнеспособный продукт, который поддерживает минимальную функциональность, он не может быть «сырым». Более того, продукт должен как можно лучше выполнять основные функции, которые решают конкретную проблему потребителя. То есть, если в качестве MVP представлен прототип — это должен быть рабочий прототип. Потребители должны чётко понимать, как будет выглядеть готовый продукт.
Важно учитывать, что основной принцип MVP — быстро и дешёво создать продукт, который люди захотят купить. И здесь целесообразно использовать модель, которую предложил Юсси Пасанен — вместо последовательного создания слоёв, создать хотя бы минимальный кусочек на каждом слое.
Принцип создания MVP по модели Пасанена
Уделяйте внимание не только функционалу. Продукт должен быть надёжным, удобным в применении и привлекательным с точки зрения дизайна.
Допустим, что конечный продукт компании – это торт. Его основная задача — удовлетворить вкус потребителя. Для разработки MVP решено применить метод послойного создания продукта. Разработчик представляет клиентам первую версию — бисквитный корж (основа). Из обратной связи узнаёт, что корж вкусный, но не хватает крема (начинки). При этом часть потребителей уже разочаровались в продукте.
Разработчик добавляет крем – и снова не то. На этом этапе ещё часть аудитории отказывается от продукта. Теперь клиентам не хватает декора (дизайн). Разработчик украшает свой торт и получает положительные отзывы, а также пожелания сделать торт двухъярусным. Осталось немного доработать MVP, чтобы получить отличный готовый продукт. Увы, но в процессе тестирования компания уже потеряла долю потенциальных клиентов.
А теперь представьте другой подход — создание MVP методом среза. Разработчик выпекает небольшое пирожное: в нём есть и основа, и начинка, и дизайн. Представление начальной версии проходит успешно, и разработчик создаёт торт. Из обратной связи узнаёт, что потребителям всё нравится, но хотелось бы получить торт большего размера. Теперь разработчик делает большой торт и всё — продукт готов. При этом удалось сохранить всю аудиторию, которой понравилась первая версия MVP.
Получается, что если вы хотите узнать, будет ли кто-то покупать у вас торт, — продавайте именно торт, а не основу для него, или начинку, или дизайн по отдельности. Изготовление тортов затратно, поэтому для начала можно сделать их мини-версию — пирожные. Характеристики остаются те же, но времени и средств на производство уходит меньше. Точно также и с любым другим минимально жизнеспособным продуктом — предлагайте потребителям то, что позволит составить объективное мнение об итоговой версии.
Какой бы гениальной ни была бизнес-идея, она не является итоговым результатом. Трудно судить об успехе, опираясь на предположения. Минимально жизнеспособный продукт позволяет проверить, заинтересует ли идея потенциальных потребителей. MVP поможет предотвратить финансирование провальных проектов, выбрать наиболее приоритетное направление развития и заранее собрать базу потенциальных клиентов.
MVP: что это такое и как работает?
Читая новости про новые проекты и сервисы, вы могли часто сталкиваться с понятием MVP. Но что скрывается под этой аббревиатурой и почему MVP так часто используют на начальных этапах развития продукта? Давайте прямо сейчас вместе разберемся в этом.
Minimal Viable Product (минимально жизнеспособный продукт) — тестовая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.
MVP создают для тестирования гипотез и проверки жизнеспособности задуманного продукта, насколько он будет ценным и востребованным на рынке.
Результаты тестирования минимально жизнеспособного продукта и обратная связь от целевой аудитории помогают понять, стоит ли развивать проект дальше, какие изменения следует внести в стратегию, а что оставить в первоначальном виде.
В 2008 году, когда аренда отеля или жилья во время путешествия была большой проблемой, два энтузиаста решили подойти к вопросу нестандартно и сдали свою квартиру по простому факсу. По сути, это тоже MVP, в котором тестировалась основная функция. Эксперимент показал, что продукт получит спрос, а сегодня Airbnb — одна из крупнейших площадок по поиску краткосрочной аренды жилья.
Proof of Concept (PoC) — доказательство правильности концепции и некоторые новички часто путают его с минимально жизнеспособным продуктом. PoC описывает процессы выяснения технической жизнеспособности концепции программного обеспечения (или любого другого продукта).
Да, эти определения взаимосвязаны, но не взаимозаменяемые. Proof of Concept — описание процессов на начальной стадии развития продуктов, которые потом реализуются фактически, из чего получается MVP.
Есть много разных подходов к созданию минимально жизнеспособного продукта, но на практике чаще всего используют некоторые из них. Далее поговорим о наиболее популярных.
Помните, как в популярном мультике «Флинстоуны» глава семейства создавал иллюзию передвижения на автомобиле? Так вот, этот подход предусматривает имитирование наличия функционала, хотя на самом деле технически он никак не реализован. MVP нацелен на проверку гипотезы, доказательство жизнеспособности выбранной модели развития бизнеса.
Он сделал сайт и опубликовал фото разных моделей обуви. Получил заказ, пошел в магазин, приобрел нужную пару и отправил покупателю. Так он проверил жизнеспособность идеи продаж обуви через интернет, при этом изначально он не тратил деньги на аренду склада и закупку продукции, а лишь имитировал их наличие.
Эта методология больше подходит для онлайн-сервисов, конечная цель которых — автоматизировать решение проблем целевой аудитории. На начальных этапах реализации продукта услуга оказывается вручную.
Например, мы хотим сделать сервис по финансовому учету и планированию для физических лиц. Но чтобы проверить, будет ли пользоваться спросом эта идея, сначала сделаем несколько финансовых планов для клиентов вручную через Excel. Так мы сможем понять, кто и сколько готов платить, какие функции нужно реализовать в первую очередь и т.п. Часто консьерж MVP помогает в генерации новых идей, которые впоследствии делают конечный продукт лучше.
Эту модель в конце 90-х годов использовал Чак Темплтон — основатель сервиса по онлайн-бронированию ресторанов, билетов и многого другого. Он не стал сразу вкладывать сотни тысяч долларов в техническую реализацию сервиса, а бронировал для других людей столики в ресторанах вручную. Так он проверил жизнеспособность идеи, понял, кто, сколько и за что готов платить и познакомился с целевой аудиторией.
Метод разрозненного MVP используют, когда идею можно проверить и реализовать без разработки уникального программного обеспечения. Вместо этого собирают готовые инструменты, объединяют в одну систему и преподносят в едином интерфейсе.
Если бы все компании начинались с разработки уникальных решений, которая обходилась бы в сотни тысяч долларов, мы бы не увидели много крутых проектов. К этому, как правило, переходят после запуска, получения обратной связи и первых результатов.
Посмотрите на популярный сервис совместных покупок Groupon. Когда-то он был простеньким сайтом на WordPress, где все взаимодействие с пользователями осуществлялось по электронной почте. Только после получения первой обратной связи и финансовых результатов были разработаны социальные функции, полноценная email-рассылка, автоматизация и мобильное приложение.
Эту разновидность используют чаще всего, когда есть готовый продукт с минимальным набором функций (как правило, одной). По такому принципу действовали основатели Spotify, которых упомянули в начале статьи.
Выпуск продукта с одной функцией (параметром) позволяет сузить целевую аудиторию, получить обратную связь и проанализировать ее, после чего приступить к тестированию.
Приступайте к разработке MVP на начальных стадиях развития продукта. Идея может быть крутой только у вас в голове (да, такова уж суровая реальность), так зачем сразу вкладывать большие деньги в разработку, когда есть вариант с маленькими затратами и точной проверкой? После выпуска минимально жизнеспособного продукта вы определите спрос и поймете, в правильном направлении развиваете проект или нет.
Но самое крутое в MVP — сбор ценной информации от первых пользователей. Именно конечный потребитель расскажет о правильной реализации проекта. Собранные данные используйте для планирования дальнейших обновлений и определения наиболее приоритетных целей: какие функции реализовать в первую очередь.
В теории вы узнали, что такое минимально жизнеспособный продукт, теперь поговорим о практической части — создании MVP. Для получения хорошего результата разложите работу на мелкие итерации (шаги/этапы), обозначьте цели для команды в целом и задачи для каждого члена. Но в первую очередь донесите до коллектива общие принципы работы и создания продукта.
Проведите общее собрание коллектива, который примет участие в разработке MVP. На нем вы должны разобраться, все ли члены команды понимают, зачем это нужно. Обсудите видение минимально жизненного продукта, сложите все воедино и постройте первый примерный план дальнейшей работы.
В ходе общего собрания обсудите следующие вопросы:
Постарайтесь привлечь к общему собранию максимум специалистов, чтобы рассмотреть идею и варианты тестирования с разных сторон. Обязательно составьте протокол собрания, в котором будут отражены основные мысли, идеи и принятые решения.
После определения основных принципов MVP, ответьте на вопрос: «Какую проблему решает продукт?». Опишите его ценность в нескольких предложениях. Во-первых, это полезно для себя и команды, во-вторых, в дальнейшем поможет в создании уникального торгового предложения, лендинга и рекламной кампании.
Например, создаем сервис по финансовому планированию для физических лиц. Он решает проблему «бесконтрольного расходования денежных средств, помогает организовать бюджет и ставить долгосрочные цели».
Распространенная ошибка начинающих продактов и предпринимателей — они считают, что их проект решает проблему широкой аудитории (всех людей). Такой подход в разы повышает вероятность провала. Сфокусируйтесь на определенной целевой аудитории.
Составьте портрет клиента, который обязательно купит продукт. Опишите его пол, возраст, социальное положение, уровень дохода, потребности, привычки, используемую им технику, распространенные проблемы, предпочтения в отдыхе и т.п.
Не торопитесь на этом этапе! Лучше потратить несколько часов для формирования портрета ЦА, чем потом «слить» весь рекламный бюджет и получить минимальную конверсию. И не забывайте про то, какую проблему решает MVP (это определяется на первом этапе).
Пример с сервисом по составлению финансовых планов для физических лиц:
Составлен примерный портрет, даже такой минимум позволяет ориентироваться и дает понимание, кому продаем продукт. Эта информация в дальнейшем поможет в организации рекламной кампании.
Не думайте, что ваш продукт (идея) уникален и такого больше нигде нет. Если вы с ним не сталкивались лицом к лицу, это не гарантирует уникальность. И вообще есть гипотеза «множественного открытия»: все исследования и изобретения делаются сразу несколькими учеными независимо друг от друга.
Эту гипотезу подтверждает история с разработкой радио. В России считают, что его изобрел Александр Попов, а вот в Италии лавры отдают Гульельмо Маркони. Оба начали работать над реализацией идеи в 1894 году, но Попов свою разработку презентовал в марте 1896 года (но при этом не запатентовал), а Маркони в июне 1896 года подал документ на патент. Кстати, есть еще несколько ученых в разных странах, которые также претендуют на звание «создатель Радио».
История с MVP аналогичная: вы должны потратить немало времени, но постараться найти конкурентов. Вам повезет, если идея все-таки окажется уникальной, а если нет, тогда решите следующие задачи:
В сборе информации помогут специальные аналитические инструменты: Similar Web, Ahrefs, Quantcast, App Annie, AppFollow и другие. Соберите данные о популярности конкурентов, ежемесячном трафике, основных интересах целевой аудитории, географическом расположении клиентов и т.п.
Для удобства советуем составлять сводную таблицу со всей собранной информацией. Впоследствии будет проще ориентироваться в больших массивах данных и принимать какие-либо решения.
SWOT-анализ представляет собой таблицу, состоящую из четырех блоков:
Опять же, его лучше проводить коллективно или, по крайней мере, с основными членами командами. Важно объективно оценивать каждый пункт и не бояться признавать слабые стороны. Посмотрим реализацию SWOT-анализа на примере сервиса по финансовому планированию для физических лиц:
Не расписывайте пункты на целые абзацы. Они должны быть короткими и понятными для всей команды.
Обратите внимание, что таблица разделена на две части. Сильные и слабые стороны, как правило, относятся к внутренним факторам, а возможности и угрозы — к внешним.
Цель SWOT-анализа выявить сильные стороны и возможности, чтобы сосредоточить работу на них для минимизации негативных последствий от слабых сторон и угроз. Сделанные выводы помогут выбрать стратегию развития и позиционирования бизнеса на рынке.
Простой блиц для определения удобства продукта: если вы сами не понимаете, что надо делать с вашим сервисом (продуктом, услугой и т.п.), то потребитель разобраться точно не сможет!
Чтобы избежать такого недоразумения, на пятом этапе создания минимально жизнеспособного продукта составляют карту пути пользователя — что делает пользователь при взаимодействии с продуктом. Вы должны понимать, какие у аудитории требования к контенту, дизайну, интерфейсу.
Кстати, не забывайте корректировать карту пути пользователя (user flow) после получения обратной связи от первых клиентов. Они расскажут, что хорошо, а что плохо или неудобно. На основе этого корректируйте карту, чтобы конечный потребитель получал то, что хочет.
Например, для сервиса по финансовому планированию сделали такую карту:
Провели первые тестирования, за два месяца в поддержку написали несколько человек: «у нас были финансовые планы в Excel, пришлось потратить часа два, чтобы все данные перенести в ваш сервис». Что делаем? Правильно! Добавляем функцию экспорта существующих в Excel финансовых планов.
На прошлом этапе вы определили основные взаимодействия пользователя с продуктом, теперь для каждого опишите конкретные функции. Для удобства составьте специальную карту: взаимодействия и функции для каждого. Сначала она выглядит так:
Дальше для каждого взаимодействия определяется перечень функций. Здесь помогут логика и пользовательские истории. В первом случае самостоятельно или вместе с командой подумайте, что нужно сделать для обеспечения того или иного взаимодействия.
Но как вы помните, наше видение часто искажено, а вот реальные пользователи дают объективную информацию на основе опыта. Пользовательские истории описывают те или иные действия людей, на основе которых определяются необходимые функции.
Дальше расставьте все функции по приоритету. Самые востребованные (которыми пользуются чаще всего) ставим в начало списка, редко используемые — в конец. Должна получиться вот такая карта:
На этом этапе вы должны определить функционал MVP или иными словами — запланировать объем минимально жизнеспособного продукта. Для начала определите несколько основных функций, без которых проект вообще не сможет существовать, от него не будет никакого толку. Это — каркас или наименьшая полезная версия продукта.
Каркас как дом без отделки — вроде бы, жить можно, но как-то не очень. Поэтому в большинстве случаев MVP дополняют разными «полезностями». Для этого необходимо определить существенные и несущественные функции: какие нужны сейчас, а какие можно доработать потом в процессе развития проекта.
Опять же, классифицировать функции лучше коллективом. Обсуждения, споры, аргументация — это приведет к определению оптимального объема минимально жизнеспособного продукта. На карте выделите каркас и дополнительные функции в рамках MVP для удобства дальнейшего планирования. Должно получиться что-то наподобие этого:
Такую карту с объемом минимально жизнеспособного продукта можно сделать на компьютере или на магнитной доске, стоящей в переговорной или аналогичном помещении. В ходе разработки допускается внесение корректировок.
Вы готовы к началу работы: определена идея, задачи, цели объем MVP. Осталось выбрать модель управления для достижения максимальной эффективности и соблюдения установленных сроков разработки. Возможно несколько вариантов:
Этот этап — один из важных. Можно придумать крутую идею, разработать качественный концепт, собрать команду высококлассных спецов, но если выберите неправильную модель управления, забудьте о достижении успеха. Поэтому хорошо подумайте, с какой системой работать в рамках реализации того или иного продукта.
Тестируйте MVP короткими итерациями: альфа- и бета-тестированием. Альфа — внутренний этап: закончили разработку, пользуйтесь продуктом внутри команды несколько дней. Если все окей, запускайте бета-тестирование — внешний этап, дайте доступ к проекту первым пользователям. Длительность: 7-14 дней.
После первой беты соберите отзывы, статистику посещений, аналитику поведений и проанализируйте весь массив данных. Так вы узнаете, что надо доработать, что можно убрать, а что, наоборот, надо добавить в срочном порядке.
Несколько итераций «разработка-альфа-бета» помогут прийти к оптимальной первой версии продукта, который можно выпускать на рынок для массового пользователя и продолжать дорабатывать.
Еще раз поговорим всю последовательность этапов:
Пройдя 10 этапов, вы получите хороший минимально жизнеспособный продукт, который впоследствии перерастет в первую версию полноценного проекта. И не бойтесь вносить правки: отказываться от каких-то этапов, добавлять собственные и т.п. Данная последовательность шагов — не строгое правило, а лишь пример или образец, на основе которого вы можете построить что-то собственное и уникальное.
Теперь вы знаете, как создать свой MVP. Но есть еще один момент: новички (им это простительно, кстати) часто допускают ошибки при планировании первых минимально жизнеспособных продуктов. На второй-третий раз, набравшись опыта, они работают быстрее и эффективнее.
Но зачем учиться на собственном опыте, когда есть чужой? Почему бы не использовать его и постараться избежать неточностей на своем пути? Поэтому далее поговорим о самых распространенных ошибках начинающих продакт-менеджеров и предпринимателей.
Закройте в клетке своего перфекциониста, потому что в ходе разработки MVP он сыграет с вами злую шутку! Запомните, задача минимально жизнеспособного продукта — дать пользователю базовое представление о продукте, он априори не должен и не может быть идеальным.
Вы тестируете гипотезу! Поверьте, маленького MVP хватит для определения потенциала идеи. Если она крутая, то спрос на продукт не испортит даже плохой дизайн, интерфейс и минимальная скорость работы. И только при подтверждении этой гипотезы начинайте тратить ресурсы на юзабилити и красивый фантик.
Если MVP не должен быть идеальным, это не значит, что его можно делать, как попало. Некоторые продакты бросаются из крайности в крайность, в результате получает вообще что-то непонятное.
Минимально жизнеспособный продукт должен быть простым, но качественным. Например, если делаете сервис, то купите хотя бы домен второго уровня, не надо оставлять его на поддомене какого-то бесплатного конструктора.
Некоторые новички так увлекаются разработкой, что забывают о приоритетной цели — сборе обратной связи. Еще на стадии планирования следует определить ключевые метрики, которые покажут успешность проекта. Это может быть количество скачиваний или покупок, число новых пользователей, коэффициент удержания клиентов и т.п.
Когда «глаза горят», есть ощущение способности свернуть горы! И в такие моменты руководитель начинает делать анонсы крутых и необычайных возможностей. Конечно, это все здорово с точки зрения маркетинга, но если не сдерживать обещания, пользователи начнут покидать проект.
Поэтому всегда принимайте решения о новых анонсах на «холодную» голову. Объективно оценивайте, что сможете сделать, а что нет.
Окрыленность собственной идеей часто дурманит разум и вся команда перестает обращать внимание на объективные факты: плохие метрики, отрицательные отзывы и т.п. Начинают думать, что просто пользователи не все понимают сейчас, а вот когда финальная версия продукта будет готова, тогда они оценят.
Нет, не оценят. В этом деле всегда важен объективизм. Есть обратная связь от реальных пользователей, слушайте ее, корректируйте работу проекта в соответствии с желаниями конечных потребителей, иначе во всей этой суете нет никакого смысла.
Итак, подведем краткий итог: MVP — минимально жизнеспособный продукт, который делают для тестирования идей и гипотез, сбора обратной связи от первых потребителей (и да, MVP ≠ PoC). Реализовать можно за 10 этапов и постараться избежать наиболее распространенных ошибок. Если вы планируете создание нового продукта, начинайте с MVP: это позволит избежать больших ресурсных потерь в случае плохого потенциала идеи.
MVP: что это такое и как работает?
Читая новости про проекты и сервисы, вы могли часто сталкиваться с понятием MVP. Но что скрывается под этой аббревиатурой и почему MVP так часто используют на начальных этапах развития продукта? Давайте прямо сейчас вместе разберемся в этом.
Что собой представляет MVP
Minimal Viable Product (минимально жизнеспособный продукт) — тестовая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.
MVP создают для тестирования гипотез и проверки жизнеспособности задуманного продукта, насколько он будет ценным и востребованным на рынке.
Результаты тестирования минимально жизнеспособного продукта и обратная связь от целевой аудитории помогают понять, стоит ли развивать проект дальше, какие изменения следует внести в стратегию, а что оставить в первоначальном виде.
В 2008 году, когда аренда отеля или жилья во время путешествия была большой проблемой, два энтузиаста решили подойти к вопросу нестандартно и сдали свою квартиру по простому факсу. По сути, это тоже MVP, в котором тестировалась основная функция. Эксперимент показал, что продукт получит спрос, а сегодня Airbnb — одна из крупнейших площадок по поиску краткосрочной аренды жилья.
MVP и PoC — одно и то же?
Proof of Concept (PoC) — доказательство правильности концепции и некоторые новички часто путают его с минимально жизнеспособным продуктом. PoC описывает процессы выяснения технической жизнеспособности концепции программного обеспечения (или любого другого продукта).
Да, эти определения взаимосвязаны, но не взаимозаменяемые. Proof of Concept — описание процессов на начальной стадии развития продуктов, которые потом реализуются фактически, из чего получается MVP.
Виды MVP
Есть много разных подходов к созданию минимально жизнеспособного продукта, но на практике чаще всего используют некоторые из них. Далее поговорим о наиболее популярных.
MVP Флинстоуна
Помните, как в популярном мультике «Флинстоуны» глава семейства создавал иллюзию передвижения на автомобиле? Так вот, этот подход предусматривает имитирование наличия функционала, хотя на самом деле технически он никак не реализован. MVP нацелен на проверку гипотезы, доказательство жизнеспособности выбранной модели развития бизнеса.
Он сделал сайт и опубликовал фото разных моделей обуви. Получил заказ, пошел в магазин, приобрел нужную пару и отправил покупателю. Так он проверил жизнеспособность идеи продаж обуви через интернет, при этом изначально он не тратил деньги на аренду склада и закупку продукции, а лишь имитировал их наличие.
Консьерж MVP
Эта методология больше подходит для онлайн-сервисов, конечная цель которых — автоматизировать решение проблем целевой аудитории. На начальных этапах реализации продукта услуга оказывается вручную.
Например, мы хотим сделать сервис по финансовому учету и планированию для физических лиц. Но чтобы проверить, будет ли пользоваться спросом эта идея, сначала сделаем несколько финансовых планов для клиентов вручную через Excel. Так мы сможем понять, кто и сколько готов платить, какие функции нужно реализовать в первую очередь и т.п. Часто консьерж MVP помогает в генерации новых идей, которые впоследствии делают конечный продукт лучше.
Эту модель в конце 90-х годов использовал Чак Темплтон — основатель сервиса по онлайн-бронированию ресторанов, билетов и многого другого. Он не стал сразу вкладывать сотни тысяч долларов в техническую реализацию сервиса, а бронировал для других людей столики в ресторанах вручную. Так он проверил жизнеспособность идеи, понял, кто, сколько и за что готов платить и познакомился с целевой аудиторией.
Разрозненный MVP
Метод разрозненного MVP используют, когда идею можно проверить и реализовать без разработки уникального программного обеспечения. Вместо этого собирают готовые инструменты, объединяют в одну систему и преподносят в едином интерфейсе.
Если бы все компании начинались с разработки уникальных решений, которая обходилась бы в сотни тысяч долларов, мы бы не увидели много крутых проектов. К этому, как правило, переходят после запуска, получения обратной связи и первых результатов.
Посмотрите на популярный сервис совместных покупок Groupon. Когда-то он был простеньким сайтом на WordPress, где все взаимодействие с пользователями осуществлялось по электронной почте. Только после получения первой обратной связи и финансовых результатов были разработаны социальные функции, полноценная email-рассылка, автоматизация и мобильное приложение.
Продукт с одним параметром
Эту разновидность используют чаще всего, когда есть готовый продукт с минимальным набором функций (как правило, одной). По такому принципу действовали основатели Spotify, которых упомянули в начале статьи.
Выпуск продукта с одной функцией (параметром) позволяет сузить целевую аудиторию, получить обратную связь и проанализировать ее, после чего приступить к тестированию.
Когда и для чего нужно делать MVP?
Приступайте к разработке MVP на начальных стадиях развития продукта. Идея может быть крутой только у вас в голове (да, такова уж суровая реальность), так зачем сразу вкладывать большие деньги в разработку, когда есть вариант с маленькими затратами и точной проверкой? После выпуска минимально жизнеспособного продукта вы определите спрос и поймете, в правильном направлении развиваете проект или нет.
Но самое крутое в MVP — сбор ценной информации от первых пользователей. Именно конечный потребитель расскажет о правильной реализации проекта. Собранные данные используйте для планирования дальнейших обновлений и определения наиболее приоритетных целей: какие функции реализовать в первую очередь.
Как сделать MVP правильно
В теории вы узнали, что такое минимально жизнеспособный продукт, теперь поговорим о практической части — создании MVP. Для получения хорошего результата разложите работу на мелкие итерации (шаги/этапы), обозначьте цели для команды в целом и задачи для каждого члена. Но в первую очередь донесите до коллектива общие принципы работы и создания продукта.
Нулевой этап: определяем основные принципы создания MVP
Проведите общее собрание коллектива, который примет участие в разработке MVP. На нем вы должны разобраться, все ли члены команды понимают, зачем это нужно. Обсудите видение минимально жизненного продукта, сложите все воедино и постройте первый примерный план дальнейшей работы.
В ходе общего собрания обсудите следующие вопросы:
Первый этап: поиск проблемы, которую решит MVP
После определения основных принципов MVP, ответьте на вопрос: «Какую проблему решает продукт?». Опишите его ценность в нескольких предложениях. Во-первых, это полезно для себя и команды, во-вторых, в дальнейшем поможет в создании уникального торгового предложения, лендинга и рекламной кампании.
Например, создаем сервис по финансовому планированию для физических лиц. Он решает проблему «бесконтрольного расходования денежных средств, помогает организовать бюджет и ставить долгосрочные цели».
Второй этап: находим целевую аудиторию
Распространенная ошибка начинающих продактов и предпринимателей — они считают, что их проект решает проблему широкой аудитории (всех людей). Такой подход в разы повышает вероятность провала. Сфокусируйтесь на определенной целевой аудитории.
Составьте портрет клиента, который обязательно купит продукт. Опишите его пол, возраст, социальное положение, уровень дохода, потребности, привычки, используемую им технику, распространенные проблемы, предпочтения в отдыхе и т.п.
Не торопитесь на этом этапе! Лучше потратить несколько часов для формирования портрета ЦА, чем потом «слить» весь рекламный бюджет и получить минимальную конверсию. И не забывайте про то, какую проблему решает MVP (это определяется на первом этапе).
Пример с сервисом по составлению финансовых планов для физических лиц:
Третий этап: определяем основных конкурентов
Не думайте, что ваш продукт (идея) уникален и такого больше нигде нет. Если вы с ним не сталкивались лицом к лицу, это не гарантирует уникальность. И вообще есть гипотеза «множественного открытия»: все исследования и изобретения делаются сразу несколькими учеными независимо друг от друга.
Эту гипотезу подтверждает история с разработкой радио. В России считают, что его изобрел Александр Попов, а вот в Италии лавры отдают Гульельмо Маркони. Оба начали работать над реализацией идеи в 1894 году, но Попов свою разработку презентовал в марте 1896 года (но при этом не запатентовал), а Маркони в июне 1896 года подал документ на патент. Кстати, есть еще несколько ученых в разных странах, которые также претендуют на звание «создатель Радио».
История с MVP аналогичная: вы должны потратить немало времени, но постараться найти конкурентов. Вам повезет, если идея все-таки окажется уникальной, а если нет, тогда решите следующие задачи:
Для удобства советуем составлять сводную таблицу со всей собранной информацией. Впоследствии будет проще ориентироваться в больших массивах данных и принимать какие-либо решения.
Четвертый этап: проводим SWOT-анализ
SWOT-анализ представляет собой таблицу, состоящую из четырех блоков:
Не расписывайте пункты на целые абзацы. Они должны быть короткими и понятными для всей команды.
Обратите внимание, что таблица разделена на две части. Сильные и слабые стороны, как правило, относятся к внутренним факторам, а возможности и угрозы — к внешним.
Цель SWOT-анализа выявить сильные стороны и возможности, чтобы сосредоточить работу на них для минимизации негативных последствий от слабых сторон и угроз. Сделанные выводы помогут выбрать стратегию развития и позиционирования бизнеса на рынке.
Пятый этап: создаем карту пути пользователя
Простой блиц для определения удобства продукта: если вы сами не понимаете, что надо делать с вашим сервисом (продуктом, услугой и т.п.), то потребитель разобраться точно не сможет!
Чтобы избежать такого недоразумения, на пятом этапе создания минимально жизнеспособного продукта составляют карту пути пользователя — что делает пользователь при взаимодействии с продуктом. Вы должны понимать, какие у аудитории требования к контенту, дизайну, интерфейсу.
Кстати, не забывайте корректировать карту пути пользователя (user flow) после получения обратной связи от первых клиентов. Они расскажут, что хорошо, а что плохо или неудобно. На основе этого корректируйте карту, чтобы конечный потребитель получал то, что хочет.
Например, для сервиса по финансовому планированию сделали такую карту:
Шестой этап: составляем перечень функций продукта
На прошлом этапе вы определили основные взаимодействия пользователя с продуктом, теперь для каждого опишите конкретные функции. Для удобства составьте специальную карту: взаимодействия и функции для каждого. Сначала она выглядит так:
Дальше для каждого взаимодействия определяется перечень функций. Здесь помогут логика и пользовательские истории. В первом случае самостоятельно или вместе с командой подумайте, что нужно сделать для обеспечения того или иного взаимодействия.
Но как вы помните, наше видение часто искажено, а вот реальные пользователи дают объективную информацию на основе опыта. Пользовательские истории описывают те или иные действия людей, на основе которых определяются необходимые функции.
Дальше расставьте все функции по приоритету. Самые востребованные (которыми пользуются чаще всего) ставим в начало списка, редко используемые — в конец. Должна получиться вот такая карта:
Седьмой этап: определяем функции MVP
На этом этапе вы должны определить функционал MVP или иными словами — запланировать объем минимально жизнеспособного продукта. Для начала определите несколько основных функций, без которых проект вообще не сможет существовать, от него не будет никакого толку. Это — каркас или наименьшая полезная версия продукта.
Каркас как дом без отделки — вроде бы, жить можно, но как-то не очень. Поэтому в большинстве случаев MVP дополняют разными «полезностями». Для этого необходимо определить существенные и несущественные функции: какие нужны сейчас, а какие можно доработать потом в процессе развития проекта.
Опять же, классифицировать функции лучше коллективом. Обсуждения, споры, аргументация — это приведет к определению оптимального объема минимально жизнеспособного продукта. На карте выделите каркас и дополнительные функции в рамках MVP для удобства дальнейшего планирования. Должно получиться что-то наподобие этого:
Такую карту с объемом минимально жизнеспособного продукта можно сделать на компьютере или на магнитной доске, стоящей в переговорной или аналогичном помещении. В ходе разработки допускается внесение корректировок.
Восьмой этап: выберите метод управления и разработки
Вы готовы к началу работы: определена идея, задачи, цели объем MVP. Осталось выбрать модель управления для достижения максимальной эффективности и соблюдения установленных сроков разработки. Возможно несколько вариантов:
Девятый этап: проводите тестирования
Тестируйте MVP короткими итерациями: альфа- и бета-тестированием. Альфа — внутренний этап: закончили разработку, пользуйтесь продуктом внутри команды несколько дней. Если все окей, запускайте бета-тестирование — внешний этап, дайте доступ к проекту первым пользователям. Длительность: 7-14 дней.
После первой беты соберите отзывы, статистику посещений, аналитику поведений и проанализируйте весь массив данных. Так вы узнаете, что надо доработать, что можно убрать, а что, наоборот, надо добавить в срочном порядке.
Несколько итераций «разработка-альфа-бета» помогут прийти к оптимальной первой версии продукта, который можно выпускать на рынок для массового пользователя и продолжать дорабатывать.
Еще раз поговорим всю последовательность этапов:
Самые распространенные ошибки при создании MVP
Теперь вы знаете, как создать свой MVP. Но есть еще один момент: новички (им это простительно, кстати) часто допускают ошибки при планировании первых минимально жизнеспособных продуктов. На второй-третий раз, набравшись опыта, они работают быстрее и эффективнее.
Но зачем учиться на собственном опыте, когда есть чужой? Почему бы не использовать его и постараться избежать неточностей на своем пути? Поэтому далее поговорим о самых распространенных ошибках начинающих продакт-менеджеров и предпринимателей.
Попытки достигнуть идеала
Закройте в клетке своего перфекциониста, потому что в ходе разработки MVP он сыграет с вами злую шутку! Запомните, задача минимально жизнеспособного продукта — дать пользователю базовое представление о продукте, он априори не должен и не может быть идеальным.
Вы тестируете гипотезу! Поверьте, маленького MVP хватит для определения потенциала идеи. Если она крутая, то спрос на продукт не испортит даже плохой дизайн, интерфейс и минимальная скорость работы. И только при подтверждении этой гипотезы начинайте тратить ресурсы на юзабилити и красивый фантик.
Небрежная работа
Если MVP не должен быть идеальным, это не значит, что его можно делать, как попало. Некоторые продакты бросаются из крайности в крайность, в результате получает вообще что-то непонятное.
Минимально жизнеспособный продукт должен быть простым, но качественным. Например, если делаете сервис, то купите хотя бы домен второго уровня, не надо оставлять его на поддомене какого-то бесплатного конструктора.
Отсутствие обратной связи
Некоторые новички так увлекаются разработкой, что забывают о приоритетной цели — сборе обратной связи. Еще на стадии планирования следует определить ключевые метрики, которые покажут успешность проекта. Это может быть количество скачиваний или покупок, число новых пользователей, коэффициент удержания клиентов и т.п.
«Пустые» обещания
Когда «глаза горят», есть ощущение способности свернуть горы! И в такие моменты руководитель начинает делать анонсы крутых и необычайных возможностей. Конечно, это все здорово с точки зрения маркетинга, но если не сдерживать обещания, пользователи начнут покидать проект.
Поэтому всегда принимайте решения о новых анонсах на «холодную» голову. Объективно оценивайте, что сможете сделать, а что нет.
Отказ от анализа и аналитики
Окрыленность собственной идеей часто дурманит разум и вся команда перестает обращать внимание на объективные факты: плохие метрики, отрицательные отзывы и т.п. Начинают думать, что просто пользователи не все понимают сейчас, а вот когда финальная версия продукта будет готова, тогда они оценят.
Нет, не оценят. В этом деле всегда важен объективизм. Есть обратная связь от реальных пользователей, слушайте ее, корректируйте работу проекта в соответствии с желаниями конечных потребителей, иначе во всей этой суете нет никакого смысла.
Итак, подведем краткий итог: MVP — минимально жизнеспособный продукт, который делают для тестирования идей и гипотез, сбора обратной связи от первых потребителей (и да, MVP ≠ PoC). Реализовать можно за 10 этапов и постараться избежать наиболее распространенных ошибок. Если вы планируете создание нового продукта, начинайте с MVP: это позволит избежать больших ресурсных потерь в случае плохого потенциала идеи.
Минимально жизнеспособный продукт: гайд по выживанию
Чтобы запустить новый сериал, режиссеры сначала снимают пилотную серию, которая имеет все «базовые настройки» будущего сериала. Отзывы аудитории о ее сюжете, персонажах и атмосфере позволяют создателям понимать, куда развиваться и над чем работать. Та же схема работает и в IT-проектах: для ее воплощения придумали MVP – minimum viable product. Он наделен основными функциями конечного продукта и дает о нем неплохое представление. От успеха минимально жизнеспособного продукта напрямую зависит будущее приложения: разработка полной версии, релиз и отклик пользователей. В этой статье мы расскажем, как из идеи получить живучий MVP и вырастить из него полноценный продукт.
По данным информационного агентства investopedia.com, 90% стартапов закрываются в первый год работы. Из них 42% проваливаются из-за отсутствия спроса, а еще 17% – из-за того, что конечный продукт недостаточно прост и удобен в использовании. Вот еще несколько причин, по которым амбициозные бизнесмены испытывают неудачи:
Большинства провалов можно было бы избежать еще на этапе создания продукта. Любой предприниматель должен взять за правило создавать MVP: minimum viable product. Это простейшая версия продукта, которая обладает базовыми функциями будущего бизнеса, строения, изобретения. MVP поможет подтвердить ценность изначальной идеи или отказаться от нее, если она окажется неудачной. В этой статье мы поговорим о частном случае – мобильных приложениях и их базовых версиях.
MVP должен быть приближен к готовой версии приложения и давать правильное представление о конечном результате. Так с его помощью можно будет получать достоверные данные исследования рынка и понимание, куда развиваться дальше. Для наглядности это можно изобразить так:
MVP необходим каждому, кто хочет подойти к разработке нового приложения внимательно и рационально. В большинстве случаев он позволяет избежать многих ошибок и дает преимущества перед теми, кто сразу создает продукт целиком.
Кроме того, людям может не понадобиться часть функций, на которые вы планировали потратить много времени и усилий. Это сократит стоимость и сроки разработки и позволит вам сфокусироваться на том, что больше всего нужно аудитории.
Перед работой над MVP необходимо построить гипотезы, которые вам нужно подтвердить или опровергнуть. Так вы не просто запустите демо-версию приложения, а поймете, что вам нужно добавить или убрать – в зависимости от реакции пользователей. Это нужно сделать как можно раньше: ваша идея может быть отличной, но если ее реализация не подходит аудитории, то нужно исправлять это на первых этапах работы.
Еще один пример – Uber. Изначально его создатели, разочарованные ценами на поездки по городу, предлагали пользователям аренду лимузинов, которая стоила всего в 1,5 раза дороже обычного такси. Продукт оказался куда более востребованным, чем ожидалось, хотя охватывал аудиторию на ограниченной территории. Поняв это, разработчики развили идею и быстро получили инвестиции, чтобы Uber работал по всему миру.
Одностраничный сайт с фотографиями квартиры тоже может из MVP стать огромным прибыльным бизнесом. С помощью этого лендинга разработчики, которые не могли платить за квартиру в Сан-Франциско, хотели проверить, интересуются ли люди арендой комнат напрямую от собственников. Как выяснилось, интересуются – этот маленький проект вырос в сайт Airbnb, на котором люди арендуют жилье от собственников, не тратя время и деньги на риэлторов и заполнение документов.
Что такое и зачем нужен MVP
Мы часто говорим об MVP (minimum viable product) когда речь заходит о разработке. О том, что это минимально жизнеспособный продукт знают многие. Но мы решили еще шире раскрыть это понятие и подробно рассказать о значении MVP в процессе создания новых продуктов.
Представим, что у вас есть идея — приложение с полным набором функций и опций, доступное на всех платформах, способное обслуживать миллионы пользователей по всему миру. Отлично!
А теперь давайте переведем разговор в более приземленную плоскость и сделаем вид, что идея вашего приложения — это эклер. Но не просто пирожное, а экстра-эклер в форме таксы, заправленный кремом на основе альпийского масла, со взбитыми сливками и посыпкой из трех видов шоколада. Это вкусный, привлекательный и очень сложный продукт. А еще непонятно, нужен ли он людям.
Здесь-то и пригодится MVP, чтобы проверить идеи. Самая первая версия вашего приложения должна быть больше похожа на простой эклер — тот, что люди знают, любят и хотят попробовать от нового поставщика. MVP приложения должны быть включены только основные функции. Когда будет готов программный продукт, с ним можно познакомить пользователей. Такое решение будет относительно дешевым и быстрым в разработке.
Форма MVP и конечного продукта зависит от технологии разработки. Это могут быть нативные или кроссплатформенные решения, о таком выборе мы уже писали в нашем блоге, загляните.
В любом случае стоит проконсультироваться с разработчиками, с которыми вы решили сотрудничать. Они дадут информацию о сроках, затратах, размере команды и, возможно, предложат новые решения. Например, вместо создания мобильного приложения вы можете начать с PWA (прогрессивное веб-приложение) и собирать отзывы от первых пользователей, прежде чем тратить ресурсы на реальный продукт.
С живым приложением вы можете продолжить разработку, основываясь на фактах, а не на предположениях. Реальные пользователи протестируют продукт и дадут обратную связь: расскажут, что им не понравилось, а что нужно добавить.
Благодаря отзывам вы узнаете, как поживает ваш «обычный эклер» и получите дополнительную информацию о том, как его можно улучшить. Если никто не просит оригинальную форму таксы, возможно, пока нет смысла вкладывать средства в ее разработку.
Подход MVP дает хорошее представление о будущих потребностях в развитии продукта. Вы можете продолжать добавлять сливки и посыпать эклер. Но что, если продукт станет настолько популярным, что люди захотят его повсюду, а не только в одной кондитерской? Тогда будет актуальней задуматься о масштабировании.
Мобильное приложение будет иметь ограничения на количество пользователей, которые оно может обслуживать, не засоряя сервер. У него также есть географические ограничения — язык или страны, в которых оно доступно. Имея данные об использовании приложения, вы теперь можете расставить приоритеты, что делать дальше: совершенствовать рецепт или открывать новые кондитерские.
Причина номер один. Минимально жизнеспособный продукт становится упрощением большого проекта и позволяет узнать, чего хотят пользователи. Становятся очевидны потребности рынка и функции, имеющие решающее значение для успеха продукта. Это идеальный способ проверить предположения и получить четкое представление о пути, по которому должен идти проект.
Причина номер два. Стартапам получить инвестирование с помощью MVP проще, потому что есть прямая презентация действующего мобильного приложения. Это демонстрирует серьезность намерений и укрепляет позиции.
Причина номер три. MVP дает возможность узнать, как компоненты UX и UI способствуют удобству использования и интуитивности мобильного приложения.
Причина номер четыре. MVP также является отличной стратегией для проверки идей монетизации. Гипотезы для заработка лучше протестировать с помощью MVP и определить, какая из них принесет наибольшую прибыль.
Причина номер пять. С помощью MVP можно быстрее выйти на рынок и по-прежнему иметь достаточно пространства для изменений.
Минимальный жизнеспособный продукт дает возможность стать лучше: вы сможете вносить существенные изменения в бизнес-процессы, основываясь на реальном пользовательском опыте. Можно отложить разработку менее важных функций и потратить деньги на срочные задачи.
Предположим, у вашего эклера есть серьезный недостаток, например, плохое качество муки. В таком случае это будет важнее исправить, чем добавлять новые фичи и еще больше усложнять ситуацию.
MVP — это перспективный путь реализации идей с опорой на потребности пользователей и требования владельца.
Если убрать демагогию и манипуляцию с сознанием заказчика, то придется вместо:
«что идея вашего приложения — это эклер. Но не просто пирожное, а экстра-эклер в форме таксы, заправленный кремом на основе альпийского масла, со взбитыми сливками и посыпкой из трех видов шоколада. Это вкусный, привлекательный и очень сложный продукт. А еще непонятно, нужен ли он людям.»
написать:
«что идея вашего приложения — это небоскреб. И не просто небоскреб, а 200-этажный небоскреб в форме летящей чайки и прозрачный после 115-го этажа. Это очень сложный продукт. А еще непонятно, нужен ли он людям. «
Поэтому давайте очень быстро из говна и палок построим сарайчик дачного типа, и расскажем заказчику, что строя сарайчик мы поняли, из КАК и из КАКИХ МАТЕРИАЛОВ строить небоскреб. ))) Идеи в статье применимы, если инфоцыганам нужно тестировать две гипотезы в неделю на маркет фит, или если нужно сделать одностраничник для кофейни. Для чего-то посложнее нужен архитектор, исследование и бэкенд, где сосредоточено 80% системы.