Как определить функционал MVP и влюбить клиента в пилотную версию продукта

Итак, MVP. Достаточно заезженная тема, на мой взгляд. Каждый, кто хоть как-то связывал себя с разработкой программного обеспечения за последние 5 лет, с 99% вероятностью слышал эти 3 буквы. Но даже несмотря на обилие информации, народ все равно наступает на грабли «идеального продукта» при создании проектов.


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


Начну с вирусной зарисовки пути развития стартапа по принципу MVP, которая гуляет по интернету и которую вы наверняка встречали.


image


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


Разберем?


Верхняя строка ничего общего с MVP не имеет. Это понятно. На ней изображен классический цикл разработки. Автор использовал его как преувеличение ради контекста в примере ниже. Разумеется, ни о каком минимально жизнеспособном продукте на первом этапе с колесом речи и быть не может. Продукт прошел 3 стадии разработки (колеса, кузов, двигатель), прежде чем смог выполнить свое предназначение — ехать.


Но и вторая строка, на мой взгляд, также не совсем корректно отображает принцип MVP.


Почему мое внутреннее понимание минимально жизнеспособного продукта не сходится с такой концепцией? Если предположить, что она отражает путь разработки какого-то продукта, становится очевидно, что он претерпел 4 коренных перестройки. В итоге его создатели получили три группы товарно-родовых конкурентов: 1 — скейт-самокат-велосипед; 2 — мотоцикл; 3 — автомобиль.


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


У автомобиля более широкий охват: пожилые и молодые люди, те, кто путешествует в одиночку или в компании, кто ездит на работу или мотается в другой город — им нужна скорость, комфортное размещение и езда при любых погодных условиях. Скейт предназначен исключительно для одного человека, чаще ребенка или подростка, да и цель езды носит больше развлекательный характер. Аудитория скейта воспримет в штыки перспективу трансформации продукта в машину, которой нужно топливо, дорогостоящее ТО и возраст 17+, не говоря уже о цене самого автомобиля. А те, кому нужна машина, изначально не обратят на ваш самокат никакого внимания. Да, каждый из этих продуктов может иметь MVP, но они не являются MVP друг для друга.


Хенрик Книберг, автор этой картинки, не раз писал о том, что его изображение не всегда интерпретируется в правильном контексте. Дело в том, что он вкладывал в нее метафорический смысл, при котором цель разработки — не построить автомобиль, а решить задачу «добраться из пункта А в пункт Б». И самым простым жизнеспособным вариантом решения этой задачи является скейт. То есть на ней абстрактно и очень упрощенно передан некий концепт поиска продукта. Скейт или самокат не являются MVP для машины. Это факт. На картинке лишь изображена идея того, что в рамках создания продукта можно сделать несколько пивотов и в итоге найти MVP.


А эта переосмысленная версия MVP мне больше пришлась по душе:


image


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


Что завернуть в MVP, чтобы его захотели попробовать?


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


Первое, что необходимо сделать, — это выяснить, какие инструменты, фичи и возможности станут для вашего продукта must have.


image


Принцип Парето


«20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата». Это эмпирический принцип, а значит многие явления в мире, в том числе и разработка, подчиняются такому соотношению. 80% ваших пользователей будут использовать только 20% функционала. Поэтому не нужно тратить месяцы на то, чтобы отполировать до кристального сияния свой продукт перед запуском. Пропишите полный перечень функций будущего приложения и определите те 20%, которые закроют 80% потребностей пользователей.


MVP = обязательно + просто


Слышали про матрицу приоритетов? Популярная техника приоритезации задач, которая распределяет фичи по шкалам «обязательно» и «просто». Изобразите две оси, где горизонтальная будет отображать увеличение сложности реализации конкретной функции, а вертикальная — путь от желательного к обязательному. Раскидайте весь запланированный функционал на этой схеме, отвечая на 2 вопроса:


  1. Сложно это или легко для реализации?
  2. Желательно это или обязательно для пользователя?

image


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


Формула Rice Score


Еще один эффективный метод приоритезации идей и фич для MVP. Вам нужно оценить каждую функцию по четырем факторам и подставить значения в простую формулу.


  • Охват — скольким пользователям вы улучшите жизнь?
    (Оцените в течение определенного периода времени и берите цифры из метрик, а не с потолка)
  • Влияние — насколько вы улучшите жизнь пользователям?
    (Очень сильно = 3х, сильно = 2х, хорошо = 1х, слабо = 0,5х, совсем немного = 0,25х)
  • Уверенность — насколько вы уверены, что гипотеза окажется верна и продукт выстрелит?
    (100% = высокая уверенность, подтвержденная опросами или исследованиями, 80% = средняя уверенность, 50% = слабая уверенность, 50% и ниже = много сомнений)
  • Усилия — сколько человеко-часов, человеко-дней или просто дней уйдет на реализацию?
    (1 человеко-день = это день работы одного разработчика)

Рассчитайте оценку для каждой фичи, согласно формуле:


image


Вместо итога


MVP подход играет роль подушки безопасности и позволяет адекватно прогнозировать коммерческий и технический потенциал продукта. Поэтому, когда мы брифуем заказчиков, то настаиваем на том, что стартовать разработку лучше с него. И, разумеется, помогаем определиться с ключевым функционалом. Если вы планируете создание минимально жизнеспособного продукта, то лучший вариант — построить его на NoCode технологии. Сегодня платформы для разработки приложений без кода пользуются бешеным спросом. Они позволяют быстрее и дешевле создавать web-приложения любой сложности, а существующие биржы NoCode фриланса помогают подобрать подходящую под запросы бизнеса технологию и проверенного специалиста. Осмелюсь предположить, что тенденция к упрощению и удешевлению разработки будет только усиливаться. И сейчас самое время задействовать ее потенциал.

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 18

    0
    Одна из самых наглядных и доходчивых, без воды, статей про MVP.
      0
      Спасибо!) Рад что Вам понравилась статья.
      –1

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


      P.S. Третья картинка существенно хуже второй. Имхо.

        0
        Благодарю за фидбэк. Как оказалось, у многих вторая картинка формирует не совсем правильное понимание концепции MVP. Собственно, поэтому я и рискнул чуток “загнаться” :) и изложить личное видение этого вопроса. А про третью картинку… Чем, по вашему, она хуже? Интересно.
          –1
          Сложно сказать в чем проблема этих «многих», но мне — как человеку из бизнеса (не программисту, соответственно) — вторая картинка объясняет суть — кратко, ясно, и без необходимости задумываться (= тратить время) — правильно ли я ее понял.

          Третья картинка как раз ломает мозг. Первая итерация MVP *вообще* не работает и не выполняет своих задач? Таких криворуких идиотов наверное уж *совсем* меньшинство — зачем их в инфографику совать?
          Вторая — грузовая, третья легковая: у ЦА *в корне* поменялись задачи, что, начиная с 3ей итерации предлагается концептуально иной продукт? А раньше моск где был?
          4я итерация отличается от 3ей *цветом*? Мы точно развиваем продукт, или бабки инвесторов жжем?

          В обшем, я думаю я знаю в чем затык: вы (видимо человек технич. хар-ра), в силу _своей_ профдеформации решили, что детали 3его варианта *важны* и подчеркнут суть. Я, как человек из маркетинга (со *своей* профдеформацией!) понял эту картинку так, как описал выше. А вот второй вариант картинки как раз позволяет правильно понять суть человеку из *любой* структуры. И это, к слову, охрененно важно.
        +1
        Нужно убрать «влюбить клиента в пилотную версию продукта» из топика. Половина статьи о картинках, другая о том, как выбрать фичи. А по топику думаешь, что будет что-нибудь про дизайн MVP продукта или как его позиционировать…

        Я бы предложил написать о том, как готовить MVP, как его тестировать и анализировать, где искать ЦА и тестировщиков. И все в таком духе. Куда полезнее обсуждений о неправильности картинок.
          +1
          Благодарю за фидбэк и отличную идею для будущей статьи ;)
          0
          Судя по тематике и skillum Вы представляете Skillum? Или есть интрига?))
            0
            Интриги нет :) Я представляю компанию Skillum.
            0
            Скейт или самокат не являются MVP для машины. Это факт.

            Имхо, в рассуждениях о продукте, один из примеров которых процитирован выше, я вижу одно серьёзное упущение. Машина не является продуктом и не создаёт value. Продуктом является "перевозка грузов" или "транспорт для одного человека решающие проблемы с паркингом". Для первого случая самокат не будет MVP, а удачно впишется, скажем, телега с впряжённой лошадью. А вот для второго — вполне.

              0
              Зашел почитать про MVP, в итоге прочитал разбор картинки. Узнал ли я для себя что-то новое из области проектирования пилотов? — Нет.
                0
                Жаль, что статья не оправдала ваших ожиданий. Но мне кажется, что успех в проектировании пилотов на 100% зависит от изначально правильно сформированного понимания природы MVP. И с этого стоило начать. Чудесно, что вы разбираетесь в этом вопросе. Но, как показывает практика, у многих этот термин вызывает недопонимание, в результате чего разработка пилота становится врагом стартапа.
                0
                Самый наглядный пример MVP — в серии игр NFS, когда получаешь базовую комплектацию машины и начинаешь её апгрейдить и тюнинговать.
                  0
                  Отличный пример, согласен
                  0
                  Я всегда клиентам приводил пример от Жигулей до Мерседеса.
                  Но многие хотят Мерседес по цене Жигулей и сразу:)
                    0
                    Тоже хороший пример)
                    0
                    Примеряю на наши MVP и не могу не согласиться. Например софт доставки из супермаркетов решили до первого магазина обкатать на детских садах бесплатно. Конечно локально, не часто и бесплатно — как слева внизу на второй картинке)
                      0
                      Про базовый функционал MVP отлично сказано, а то все хотят сразу 100500 фич, а нужны ли они…

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

                      Самое читаемое