Зачем нужен MVP

Привет, VC! Я продолжаю серию статей для предпринимателей по разработке продуктов и проектов. В прошлой статье “Есть идея IT-продукта. Что делать дальше?” рассказал про продуктовую аналитику, которую необходимо провести до начала реализации идеи, и закончил на проблемном интервью. Если вы не читали ее, рекомендую это исправить, чтобы повествование получилось целостным и более полезным: будет много отсылок.

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

Еще до начала проведения аналитики, описанной в прошлой статье, у вас в голове скорее всего было некое видение продукта. Чем раньше это видение сформировалось, тем больше этапов аналитики вы подсознательно на него примеряли. Это не хорошо и не плохо, так работает наш мозг. Но в начале данного этапа важно отодвинуть видение в сторону и хотя бы несколько дней “повариться” в проблеме. Посмотрите свежим взглядом на полученные на прошлом этапе данные: может есть более эффективные варианты решения. Ваше видение подтвердилось? Отлично. Оно поменялось? Еще лучше! Обязательно изложите его письменно-графически. Важно иметь возможность в любой момент наложить новую гипотезу на текущую концепцию, и ничего при этом не упустить.

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

Видение будет вашей путеводной звездой, но не ближайшей целью. Не спешите сразу сделать “идеальный” сервис - это невозможно. Сделать даже хороший продукт в один заход - огромная удача. Что такое сервис с продуктовой точки зрения? Это набор связанных между собой гипотез. Речь идет о сотнях или даже тысячах гипотез, про которые вы говорите “я в это верю”. На таких объемах выдавать высочайшее подтверждение гипотез могут только гении. Но это только продуктовый уровень. На проектном, то есть во время реализации, гипотезы могут раскладываться на десятки более мелких.

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

Для этого мы пока забудем о концепции IT-продукта и еще раз обратим внимание на термин “минимальный жизнеспособный продукт”. Это продукт самым простым образом решающий проблему или дающий новую возможность(далее для простоты буду говорить про проблему). Не обязательно с помощью IT.

Жили были пещерные люди и была у них проблема - чтобы попить воды, надо к реке идти, еще и всей семьей. По дороге напал серый волк и съел пару детишек. Проблема так проблема. И вряд ли ее решением был бы водопровод, даже если они смогли его представить? Логичнее было взять полое дерево или сделать конструкцию из палок и шкур, которая позволила бы донести воду из реки в пещеру. Проблема решена! Но идеальное ли это решение? Нет! Значит, давайте решать его самую главную проблему - простоту создания. Шло время, и придумали глиняные сосуды лепить и обжигать. Еще один шаг вперед. Потом люди стали отдаляться от водоемов, в результате чего придумали колодцы, акведуки и, наконец, современный водопровод. Решение проблемы развивалось итерационно и постоянно меняло свой вид.

Подумайте, как вы можете решить проблему не для всей большой ЦА, а для одного или нескольких ее представителей. Не гонитесь за эффективностью. Вам надо при наименьших затратах времени и денег убедиться, что люди готовы платить за ваши услуги. Для идеи сервиса по выгулу собак из предыдущей статьи MVP будет объявление в подъезде, чате дома или района в мессенджерах или просто знакомство с собачниками на улице. Вы ничего не вкладываете и даже зарабатываете, тестируя свою гипотезу. Но не забываем про проблемное интервью. Предложите свою услугу его участникам. Используйте максимум возможных каналов, чтобы протестировать спрос. Если вашими клиентами станут только те, у кого брали интервью, о масштабировании не может быть и речи.

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

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

Но далеко не всегда гипотезу можно протестировать так просто, особенно когда мы говорим про IT. Что же делать в такой ситуации?

Начнем с решенческого интервью. Если в проблемном интервью вы концентрировали внимание опрашиваемого на предыдущем опыте, теперь настало время поговорить о решении проблемы с помощью продукта. Ваша задача - максимально объективно его описать, чтобы выяснить две вещи: решает ли он проблему и готовы ли его купить. Сделать это можно в виде презентации, прототипа или даже устно, в зависимости от сложности концепции.

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

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

Затем опишите продукт, и как именно он решает проблему. Решает ли он дополнительные проблемы или создает возможности. Тот же сервис по выгулу не просто убирает необходимость гулять с собакой, когда не хочется. Он позволяет найти время на поход в кино или встречу с друзьями. А может у него есть неприятные “побочные эффекты”? Можно сколько угодно описывать, какие вкусные пирожные в новой кондитерской, но нельзя не обратить внимание на их калорийность.

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

Завершите интервью блоком вопросов про стоимость и покупку. Начнем со стоимости. Здесь может быть несколько вариантов:

Узнайте, кто будет платить(или уже платит) за решение проблемы. Если пользователь и плательщик - разные люди, продумайте, как будет выстраиваться продажа.

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

Если же опрашиваемый не идет на встречу, стоит еще раз вернуться к получению обратной связи о продукте. Загнав в “логический угол”: проблема есть, решить ее выгодно, бюджет есть, почему не покупает? Так вы сможете получить более честное мнение, чем изначально.

Если хотите протестировать реальный спрос, одним из часто используемых приемов является создание лендинга(одностраничного сайта), на который пускается реклама. Преподнесите свою идею как готовый продукт, для использования которого надо зарегистрироваться. Заполнение этой формы будет прямым сигналом заинтересованности: просто так контакты не оставляют. Свяжитесь с такими пользователями, поблагодарите за интерес и честно объясните ситуацию. Персональный подход творит чудеса: договоритесь с такими пользователями об участии в тестировании и бесплатном(или со скидкой) использовании продукта. Они могут стать вашими самыми преданными пользователями, давать качественную обратную связь и рассказывать о сервисе другим.

Итак, вы уже убедились в целесообразности создания первой цифровой версии продукта. Что же она должна из себя представлять? Я бы выделил 2 основных варианта: когда у вас уже есть работающий на минимальных объемах оффлайн-продукт, и когда ее нет.

Под первую ситуацию как раз подходит выгул собак. Этот продукт можно разделить на несколько составляющих: привлечение собачников, привлечение выгульщиков, личные кабинеты для каждого из них и внутренняя логика сервиса. Для обслуживания 5 клиентов в день никакая разработка не нужна, повышаем до 10, все еще вывозите? Рассчитайте, при каком количестве оказания услуг вы перестанете справляться. Так вы найдете бутылочное горлышко своего продукта. Это самое узкое место, определяющее производительность всей системы, а значит повышение производительности других частей не приведет к повышению производительности системы. Следовательно, для масштабирования необходимо постоянно отслеживать, где бутылочное горлышко сейчас, где будет в дальнейшем, и расширять его.

Как раз в этом расширении и помогут разработка и различные сервисы. Допустим, с привлечением все хорошо, но обработка заявок, которые сейчас поступают в мессенджеры, занимает слишком много времени. Создайте анкету в гугл формах и разгрузите сотрудника. Слишком сложно стало контачить выгульщиков и собачников вручную? Скорее всего вам пора переходить к разработке, о чем расскажу в следующих статьях.

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

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

Когда гипотезы сформированы, наступает этап генерации идей: какой минимум нужно разработать, чтобы проверить гипотезы. Казалось бы, опасность этого этапа - сделать слишком мало. Но как бы не так, больше 80% моих клиентов входили в такой раж, что даже несмотря на уговоры сделать меньше, в итоге делали значительно больше.

Почему так происходит? На мой взгляд, причины 2: желание сразу сделать “очень хорошо” и чрезмерная уверенность в собственных умозаключениях. Мотивы положительные, от чего еще сложнее разглядеть их огромные минусы. Как писал выше, сразу попасть в цель с бОльшим количеством реализованных пользовательских историй сложнее, чем с меньшим. При этом продукт становится менее гибким к изменениям. Некоторые делали слишком сложную и многоуровневую структуру, рассчитанную на 100+ человек, а по факту и через год не могли привлечь больше 10. Другие сразу “полировали” все части продукта, а спустя месяц приходили к решению сделать пивот, и этот функционал терял ценность.

Здесь можно провести аналогию с перекрестком. В мегаполисе он должен соответствовать гигантскому количеству требований: разметка, пешеходные переходы, куча запрограммированных светофоров. Это продуманная экосистема. Но есть ли смысл делать то же самое на сельской окраине, рассчитывая, что через некоторое время она станет таким же мегаполисом? Конечно нет. Такое решение не просто будет излишним для участников дорожного движения и черной дырой местного бюджета. Оно будет контрэффективным: зачем постоянно стоять на светофоре, если на дороге никого?

После составления списка пользовательских историй я крайне рекомендую каждую из них сверить с вашими гипотезами. Если история не работает на подтверждение гипотезы, выбросьте ее из MVP. Если история позволяет подтвердить гипотезу, но есть другая история, которая делает это более эффективно, выбросьте ее из MVP. Мне самому до сих пор тяжело отказываться от историй, глядя на которые думаешь “это точно будет полезно”. Но это необходимо для увеличения шансов продукта на успех.

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

PoC (Proof of Concept = Подтверждение концепции) - своего рода риск-менеджмент. Если идея построена на интеграциях с другими сервисами или на создании новой технологии, перед созданием MVP вам может потребоваться проверка, можно это в принципе создать, и целесообразно ли будет масштабирование с учетом затрат на создание.

Prototype (= Прототип) - черновик будущего MVP, направленный на проверку гипотез(чаще одной). В IT прототип часто используется для тестирования дизайна до начала разработки.

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

Если хотите увидеть отдельную сравнительную статью про эти 3 подхода, пишите в комментариях.

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

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