В прошлой части мы разобрались, стоит ли вообще заходить в проект - есть ли рынок, откуда деньги, кто будет работать [Как рождается продукт. Часть 0: Идея]. Если вы это прояснили и решили двигаться дальше, следующий вопрос один: как проверить, что вы не ошиблись, потратив минимум ресурсов?
Ответ на него - MVP. Но здесь начинается путаница, которая стоит людям времени и денег.
Зачем нужен MVP и нужен ли он вообще
MVP обязателен почти всегда. Исключение одно - если у вас достаточно денег, чтобы тестировать гипотезы наугад, пока что-то не выстрелит. Тогда MVP действительно не нужен: вы можете позволить себе просто запускать и смотреть. Остальным он нужен по одной простой причине - удешевить проверку гипотезы.
Не построить продукт. Не запустить бизнес. Не получить первых клиентов. Именно - дёшево проверить, работает ли базовая идея. Это всё, что от него требуется.
Главная ошибка: MVP против Minimal Lovely Product
Большинство людей, которые думают, что делают MVP, а на самом деле делают другое. Называется это Minimal Lovely Product (MLP) - минимальный продукт, в который можно влюбиться.
Разница принципиальная.
MVP проверяет гипотезу. MLP пытается очаровать пользователя в уже понятном для создателя рынке с понятной проблемой. Это разные задачи.
У нас бывают ситуации когда заказчик говорит "у нас обязательно должна быть вот эта функция, а если без неё, то кому вообще нужен этот сервис" - он строит MLP, а не MVP. Каждая "обязательная" функция - это шаг в сторону от проверки и шаг к разрастанию проекта, росту стоимости и затягиванию сроков.
Типичный сценарий: фаундер называет это MVP, но по факту ожидает, что с первого запуска продукт начнёт работать как полноценный бизнес - люди будут им делиться, рассказывать друзьям, возвращаться. Иногда так бывает.
Но для этого нужен либо невероятный продукт с опытным основателем. Но что важнее продукт должен быть с бюджетом на несколько лет вперед, либо удачно выбранный рынок и проблема, ну или в целом удача. Рассчитывать на удачу при построении первой версии - сомнительный вариант, а то будут у вас деньги на все ваши хотелки на несколько лет вперед или нет вы и сами поймете еще до запуска
Типы MVP: от лендинга до миллиона индусов за кадром
Лендинг-пейдж
Самый простой и дешёвый вариант. Одностраничный сайт с описанием продукта и одним транзакционным действием - оставить заявку, нажать кнопку, зарегистрироваться. Задача не в красоте, а в одном вопросе: нажимают или нет?
Если нажимают - гипотеза подтверждается, есть смысл строить дальше. Если нет - вы узнали это за копейки, а не за несколько месяцев разработки.
Сделать лендинг стоит дёшево. Пролить на него рекламу - вопрос бюджета, который вы сами определяете. Это самый быстрый способ получить ответ от рынка.
Но что важнее данный вариант проверки отклика от рынка доступен вообще любому основателю\предпринимателю.
Wizard of Oz - человек под капотом
Это тип MVP, где пользователь видит интерфейс или сервис, а за ним - живые люди, которые всё делают руками. Технологии нет. Есть имитация результата.
Не так давно был известный случай с сетью магазинов, где запустили "умную" кассу без кассиров: берёшь товар, уходишь, деньги списываются автоматически. На деле за камерами сидели люди и вручную фиксировали покупки. Это воспринимается как обман, но с точки зрения проверки гипотезы - абсолютно рабочий подход.
Главная ловушка такого MVP: гипотеза подтвердилась, бизнес работает, всё хорошо. Но потом оказывается, что процесс невозможно автоматизировать. Система остаётся полуручной, и вместе с ростом растут операционные расходы. Особенно грустно будет вашим инвесторам, когда они узнают как работает ваш бизнес, если вы привлекали внешнее финансирование. IT-бизнес ценен именно тем, что масштабирование не требует пропорционального роста затрат. Если автоматизация не получается - этого преимущества нет.
Поэтому, если вы выбираете этот тип MVP, важно заранее понять: то, что люди делают руками сейчас, можно будет автоматизировать потом?
Для этого необходимо не так много описать процессы и проконсультироваться с несколькими программистами которые способны стать CTO в вашей компании. И рекомендуем делать этот вариант MVP только с собственных средств.
Консьерж-сервис
Похож на Wizard of Oz, но с важным отличием: здесь вы не прячете процесс. Команда или сами основатели открыто обслуживают клиентов вручную, полностью погружаясь в процесс.
Airbnb начинался именно так - команда вручную отбирала объекты, обрабатывала заявки, общалась с клиентами по телефону. Zappos - основатель лично ходил в магазины, фотографировал обувь, выкладывал, получал заказ, шёл покупать и отправлял. Никакой автоматизации, только система и решение конкретной проблемы. По сути это компания которая вручную дошёл до клиента другим путём, и этот путь в дальнейшем можно автоматизировать и масштабировать
Это, пожалуй, лучший подход из всех - если ваш бизнес связан с реальным физическим сегментом. Вы не просто проверяете концепцию. Вы погружаетесь в контекст своих клиентов, начинаете понимать их изнутри и принимаете решения, основанные на реальном опыте, а не на предположениях.
Любая череда гипотез даже хороших, всегда проигрывают реальному опыту, так как опыт и отклик быстрее приводит к результату.
Смок-тест
Самый минималистичный вариант. Суть - продавать то, чего у вас ещё нет.
Хотите торговать стаканчиками для кофе - разместите объявление о продаже. Смотрите, сколько звонков, по каким ценам берут, какой интерес. Только после этого закупайте. Вы узнали всё нужное, не потратив деньги на товар и не забив склад.
Отлично работает там, где нужно жёстко замерить конверсию или где физическое наличие продукта требует крупных первоначальных вложений, без понимания реального спросса.
Техдолг - это не ошибка, это инструмент
Техдолг - это когда вы намеренно делаете что-то не так хорошо, как могли бы. Не потому что некомпетентны, а потому что сейчас это не нужно.
Для MVP достаточно, чтобы сервис держал 10 000 пользователей?
Это значит не нужно строить инфраструктуру на миллион. Не нужна собственная система авторизации - интегрируйте готовую. Не нужна своя платёжная инфраструктура - подключите Stripe, ЮKassa, e-money. Не нужна своя KYC-верификация - возьмите готовое решение.
Правило простое: если есть выбор между "сделать самим" и "взять готовое" - берите готовое. Всегда, в рамках MVP. Ваше время и деньги должны уходить на бизнес-логику продукта: как он выглядит, как работает для пользователя, какую проблему решает и решает ли вообще.
Основатель кофейни не думает о том, чтобы самостоятельно производить столы или выращивать кофе. Он купил готовые и сфокусировался на приготовлении кофе. MVP - та же история.
P.S Наверно если у вас десятки тысяч кофеен то становится выгодно и производить столы и кофе самостоятельно)
Сроки: когда MVP перестаёт быть MVP
Хороший MVP - это 2-4 месяца разработки. В идеале - квартал. За это время вы должны выпустить продукт на рынок и получить обратную связь.
Если сроки уходят в полгода и дольше, и вы не в финтехе с его обязательными требованиями по безопасности - скорее всего, это уже не MVP. В продукт попало слишком много функций. Нужно обрезать.
Здесь важно понимать природу разработчиков. Им в целом всё равно, быстро вы запускаетесь или нет. Они пишут код. Чем больше фантазий и идей добавляет заказчик, тем дольше и интереснее процесс с их стороны. Ни один разработчик сам по себе не скажет вам "стоп, хватит, это лишнее". Мы своим заказчикам стараемся это говорить но часто получаем сопротивление в ответ, а что говорить о просто разработчиках в вашей компании.
Это ваша задача - или задача команды, которая работает с ориентацией на бизнес-результат, а не на количество написанного кода.
Долгострои очень часто не доходят до пользователя вовсе - продукт обрастает таким объёмом функций и взаимосвязей, что выходит на рынок сырым, перегруженным и непонятным.
Но что важнее такой проект часто становится просто слишком тяжелым в обслуживании, так как каким бы большим не был проект это все еще MVP стадия рынок требует менять под него проект быстро, а он уже большой и в момент резких пивотов, растет количество костылей и сомнительных решений, которые в итоге приводят проект в технический тупик.
Финтех: где MVP всегда дороже
Отдельный разговор - финтех-стартапы. Здесь есть вещи, которые нельзя сделать дёшево. Прежде всего это безопасность.
Сэкономить на безопасности в финтехе - значит рисковать как минимум репутацией, как максимум - прямыми финансовыми потерями клиентов. Или вы можете присесть на несколько лет в места не столь отдаленные. Это не то место, где стоит выбирать техдолг.
При этом всё, что можно взять готовым, берётся готовым: KYC, AML, платёжные интеграции, верификация. Делать это самостоятельно с нуля - дорого, долго и не оправдано на этапе MVP. Готовые решения существуют именно для того, чтобы не тратить ресурсы там, где проблема уже решена.
Что в итоге
MVP - не конечная цель. Это инструмент для одного конкретного вопроса: работает концепция или нет?
Всё, что MVP должен сделать - это доказать или опровергнуть основную гипотезу с минимальными затратами. Не больше.
Если вы поймали себя на мысли "но нам ещё нужна вот эта функция, без неё непонятно" - остановитесь. Спросите: эта функция проверяет гипотезу или просто делает продукт красивее? Если второе - она не для MVP.
Сделайте минимум, необходимый, чтобы проверить основную гипотезу или заработать. Выйдите на рынок. Получите обратную связь. Поймите, что улучшать. Вот и весь цикл.
Автор: Помазанов Павел Александрович, Генеральный директор компании Defence.Investments & SECURA.FINANCE
Спасибо за прочтение, следите за нами на САЙТЕ в наших соц. сетях:
Instagram | Telegram | VK | X(Twitter) | VC | TenChat