По следам лекции для Университета 20.35: что такое MVP и зачем он нужен

В конце мая наш директор Алексей Кулаков провел лекцию для студентов сетевого интенсива Университета 20.35. Разбирали, что же такое MVP, как его сформулировать и почему мы считаем его прежде всего станком для проверки гипотез. Поговорили и о том, как определить барьеры, которые мешают изменить пользовательское поведение, и как с помощью MVP их преодолеть. Ну и вообще, как понять, что MVP работает.

Из лекции мы сделали статью — читайте ее ниже!

 

 

Что такое MVP

Давайте начнем с вопроса, на который сначала ответите вы, а уже потом я расскажу, что про него думаю я. Как вы понимаете, что такое MVP? 

Ответы:

• самое простое решение, позволяющее организовать бизнес-процессы и решить проблему;

• минимально жизнеспособный продукт;

• начальный продукт, который уже имеет функциональность и ценности и который можно тестировать на пользователе;

• то, что уже на стадии разработки поможет узнать, чего именно хотят пользователи;

• прототип, который позволит понять, рабочая у вас идея или нет, чтобы инвестор ее протестировал.

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

Бизнес — это структура, которая изменяет поведение людей так, чтобы за это изменение кто-то платил. Чаще всего те люди, чье поведение мы помогаем изменить, это изменение и оплачивают. Поэтому, когда мы занимаемся бизнесом (в частности, на очень ранней стадии), мы должны выяснить: способны ли мы изменить поведение людей так, чтобы они за это заплатили? 

MVP — это станок для проверки гипотез. В нашем случае — экспериментов по изменению поведения людей.

Но кроме «станка для экспериментов» нам нужны еще три вещи: 

• гипотеза, которую мы тестируем;

• люди, чье поведение мы попробуем изменить;

• способ измерить результат.

Самая простая формула гипотезы:
«Если мы сделаем [вот что], получится изменить поведение [вот каких людей] [вот таким образом], благодаря [вот таким качествам] продукта». 

 

Сразу разберем на конкретном кейсе: вот мы все сейчас участвуем в созвоне, поэтому у нас точно есть общий опыт, на котором мы можем что-то понять. Допустим, мы хотим создать продукт, который лучше, чем Zoom, для таких мероприятий, как наш вебинар.

 

Теперь подготовим постановку гипотезы.

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

Давайте перечислим аудитории на примере нашего вебинара: 

• все пользователи (максимально широкая рамка),

• спикер, 

• целевые слушатели, 

• случайные слушатели (которые пришли без приглашения), 

• организаторы. 

 

2. Формулируем задачу 

Тренироваться мы будем в формулировке MVP. Начнем с того, как НЕ надо. 

Определение вроде «работать будет на следующих платформах, звонить можно будет один на один» — это не то, что нас сейчас интересует, потому что из этого определения не понятно, какие люди, как и ради чего изменят свое поведение.

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

 

Вот пример неправильной формулировки. 

Ситуация: «Нам не нравится, что на вебинаре появляются «тролли», которые пытаются сорвать мероприятие».

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

 

На выходе мы не узнаем, начали ли наши пользователи вести себя по-другому. Получится в лучшем случае проверить, способны ли наши программисты сделать то, что мы им описали.

 

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

 

3. Формулируем то же самое в терминах изменения поведения людей

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

 

4. Устраняем барьер

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

Давайте вернемся к примеру про «троллей». Как мы хотим изменить их поведение? Сделать так, чтобы их не было. Это ответ на вопрос, как должно измениться их поведение: они не должны прийти.

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

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

Зачем так подробно обсуждать изменение поведения каждой группы людей? Заметьте, мы еще не думали, что нужно делать программе. Мы говорили о людях: о разных группах и о том, как изменить их поведение. Сначала необходимо определить, как изменить поведение людей (не работу техники!), а потом — с помощью чего. Тогда, когда мы будем выбирать организационные и технические средства, у нас будет критерий — ответ на вопрос, хорошее ли это решение. Начинать надо с узких групп, потому что на них проще заметить специфику. И уже потом можно обобщить ее для более крупных рыночных ниш. 

 

С чего начинается бизнес

Бизнес начинается с простого вопроса, кто и за что платит:

• кто наши клиенты? 

• за какое изменение качества жизни они заплатят? 

Иногда бывает так, что мы «работаем» на одних людей, а платят другие. Например, в образовании — мы меняем поведение учеников, а платит родитель. Но, на самом деле, это означает, что родитель заплатит за изменения в своем опыте. Это значит, что и начинать анализ надо с опыта клиента. 

Когда мы демонстрируем людям первый опыт, они должны сказать: «Да, за такое изменение я бы заплатил». И в идеале — заплатить прямо сейчас.

Обострю тезис. Люди платят только за ожидание, что их опыт изменится. Ожидание нового опыта — это единственный товар, который мы покупаем. Это означает, что у клиента есть предположение, какие изменения ему предстоит испытать после покупки. И уже после покупки он сравнит свое ожидание, с реальным опытом, который он получит. Если ничье поведение мы не изменили, значит, у человека, который нам заплатит, не будет желания взаимодействовать с нами еще хоть раз или рассказывать другим о своем позитивном опыте. 

 

Что такое хороший MVP? 

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

Чуть подробнее. Хороший MVP:

• проверяет большее количество гипотез в единицу времени; 

• во время наблюдения дает предпринимателю более глубокие инсайты;

• дает нам результаты, в которых мы уверены (результат эксперимента однозначен, мы можем отделить факты от мнений и оценок); 

• стоит как можно меньше ресурсов и времени. 

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

 

Из чего можно собрать MVP? Вариантов несколько:

• из людей и некоторых обещаний, которые одни люди дают другим; 

• из людей, которые предоставляют услугу вручную (иногда снаружи это выглядит как автоматизация);

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

• из программного кода, который мы написали под задачу. Обычно это самый дорогой вариант. Его стоит выбирать, только если предыдущими способами проверить гипотезу никак не получается. 

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

 

Какие гипотезы мы проверяем?

В цикле взаимодействия с клиентом у нас есть несколько последовательных гипотез.  

Первая гипотеза: «будут ли нам платить за обещание [вот такого опыта]?». Мы меняем поведение людей в моменте, когда продаем продукт. Результат — люди откликаются и платят деньги.

Вторая: «как клиенты отнесутся к опыту, который с ними произошел во время покупки?» Мы выстраиваем процесс, при котором их поведение меняется (и они это замечают). Результат — жизнь людей меняется так, как мы обещали.

Третья: «сможем ли мы сделать что-то в нашем бизнесе с меньшей себестоимостью, чем другие?». Проверяем гипотезу, что мы можем изменить их жизнь дешевле, чем другие рыночные решения. 

Получилось? Мы сделали инновацию. Инновация в бизнесе это всегда способ сделать что-то всем нужное с более низкой себестоимостью. 

Для проверки этих гипотез нам нужны разные качества продукта и разная постановка на эксперимент. Давайте вернемся к его подготовке. 

 

Начнем с того, что дадим обещание 

Тактика fake landing page — есть только посадочная страница (одностраничный сайт), на которой мы рассказываем о нашем продукте, при этом самого продукта еще нет. За этой страницей может больше ничего не быть, главное, что есть место, где мы даем обещание и после этого получаем контакты людей, которые готовы за такое обещание платить.

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

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

Когда мы начинаем решать, за счет каких качеств продукта мы хотим изменить поведение клиента/спикера, возникает вопрос: а за чей счет праздник? В нашем примере с семинаром могут платить:  

• все пользователи,

• только слушатели,

• только спикеры,

• только организаторы.

Кто наш клиент? От кого мы принимаем деньги? Чью жизнь мы должны менять? 

 

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

За что могут заплатить организаторы? За снижение затрат. Тогда мы предлагаем им:

• тратить меньше времени на сбор группы участников,

• привлекать участников дешевле, чем раньше,

• модерировать менее квалифицированным сотрудником,

• не отвлекаться на устранение технических неполадок.

Также организаторы могут заплатить за увеличение доходности. Тогда мы предлагаем им: 

• продавать большему количеству клиентов,

• брать больше денег с одного клиента,

• добиться того, чтобы клиенты платил большее количество раз.

Давайте попробуем дать организатору обещание. 

Например: «Вы платите нам 5 тысяч в месяц, и вы не будете отвлекаться на устранение технических неполадок». 

Заказчик потребует доказательств и ответа на вопрос «с чего это мне верить, что я правда перестану отвлекаться?». Нам надо предоставить реальные доводы, что жизнь заказчика станет легче. Это, скорее всего, значит, что нам придется знать ответ на вопрос, как работает наше решение (по изменению поведения людей) до того, как мы его начнем делать, уже на этапе обещания. 

 

Давайте поймем, можем ли мы доставить им ценность, которую обещали?

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

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

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

Итак, мы поняли:

• поведение каких людей мы хотим менять,

• какие люди будут за это платить,

• как мы будем их поведение изменять,

• как сделать это дешевле.

Вспомним формулу: «Если мы сделаем вот что, получится изменить поведение вот каких людей вот таким образом, благодаря вот таким качествам продукта». 

 

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

У нас есть готовая формула MVP, и при этом мы еще не потратили ни рубля: ни на копирайтеров, ни на дизайнеров, ни на программистов. Мы просто сформировали идею и пошли к клиенту с вопросом: «Вы нам за это заплатите?».

 

Можно ли это считать MVP? 
В классике — нет. Никакой функциональности мы же не создали. И если считать, что MVP это минимальная функциональность, то мы еще ничего не сделали.

Но если считать, что MVP — это станок для проверки гипотез по доставке ценности, то это хороший (дешевый, дающий инсайты, позволяющий взаимодействовать с аудиторией) станок для экспериментов. 

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

 

Но это уже другая история ) 

Ну и напоследок. Полезные сервисы для создания прототипа:

• Figma (то, на что проектировщики интерфейсов переходят со Sketch или Photoshop) — дизайнерский инструмент, в котором можно проектировать интерфейсы. В нем можно собрать целиком интерфейс, работает в браузере, очень полезен в веб-разработке.

• Tilda, Bitrix24, Wix — позволяют сделать сайт без навыков программирования, не требуют особых знаний для создания страницы продукта.

 

А если вы задумались о разработке MVP для своего сервиса, вы всегда можете написать нам. Мы поможем!