MVP, это не минимальный продукт. Это цена входа.

НАЧАТЬ С МАЛОГО

Не обязательно начинать с разработки

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

Большие цифровые продукты почти всегда выглядят убедительно ещё до того, как начинают работать.

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

А иногда есть и $100,000.

И в этот момент возникает очень простой вопрос, который почему-то часто задают последним:

А нам действительно нужно сейчас строить всё это?

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

Для меня MVP, это не минимальный продукт. Это цена входа.

Это возможность создать первую работающую версию, запустить её в реальной среде и получить ответ на главный вопрос: стоит ли строить дальше, и если да, то что именно?

И иногда эта цена входа может быть намного меньше, чем предприниматель предполагает.

Сегодня ситуация вообще изменилась.

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

Отдельно это касается AI-инструментов, они окончательно убрали барьер входа в разработку. Но AI отвечает на вопрос «как быстро собрать», а не на вопрос «что именно строить», а это совершенно разные задачи. Мы разбирали это подробнее здесь: AI упростил разработку. Построить успешный продукт, нет.

И я считаю это хорошей новостью.

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

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

Потому что наша задача, не сделать как можно больше разработки.

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

Это принципиальная разница.

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

«Но ведь это было ваше ТЗ».

Формально всё правильно.

Но я считаю такую работу неправильной.

Если в процессе разработки мы видим, что сама бизнес-гипотеза вызывает вопросы, наша задача не молча продолжать производство. Наша задача, показать риск и предложить способ проверить его дешевле.

Потому что плохой продукт можно построить идеально.

И это не сделает его хорошим бизнесом.

ПЕРВЫЙ MVP PERETZ

Первый MVP PERETZ тоже был маленьким

Один из самых понятных примеров для меня, наш собственный дизайн-бизнес.

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

У нас просто не было сотен проектов.

Был небольшой набор работ, которые мы могли показать.

Мы сделали landing page, запустили рекламу, подключили аналитику и начали смотреть, что происходит.

Какие люди приходят.

На что реагируют.

Какие запросы работают.

Что приводит к обращениям.

Что не работает вообще.

И только после этого начали развивать систему.

Из первого лендинга вырос сайт на CMS. Потом появился следующий сайт , уже на кастомном фреймворке.

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

Мы начали с того, что могли проверить.

А дальше продукт рос вместе с данными.

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

MEDPRESSO

Medpresso: когда продукт слишком большой для одного запуска

Другой пример, Medpresso.

Это уже совершенно другой масштаб. Большой медицинский портал с большим количеством контента, функций и бизнес-процессов невозможно разумно рассматривать как маленький продукт.

Но это не означает, что его нужно сначала полностью построить, а потом впервые показать рынку.

Мы запускали его поэтапно.

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

В какой-то момент сам процесс запуска стал частью развития продукта.

Мы рассказывали аудитории, что появится дальше, какие функции мы готовим, какие страницы запускаем. Это создавало интерес ещё до появления следующего этапа. Более полную историю этого запуска можно прочитать в кейсе Medpresso.

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

Потому что у большого продукта есть одна неприятная особенность:

его очень легко строить дольше, чем бизнес может себе позволить.

СЪЕСТЬ БИЗНЕС

Большой проект может съесть бизнес

Когда команда сразу начинает делать большую платформу, она принимает огромное количество решений на основании предположений.

Какая функция нужна?

Какая архитектура будет оптимальной?

Какие интеграции понадобятся?

Какая модель поведения пользователя окажется правильной?

Какие процессы нужно автоматизировать?

На каждое такое решение уходят дизайн, разработка, управление проектом и деньги.

А затем может выясниться, что бизнесу вообще не нужно было половины того, что мы построили.

И это не преувеличение. По данным исследования Pendo, основанного на реальной телеметрии использования сотен цифровых продуктов, около 80% функций в среднем продукте почти не используются пользователями вообще.

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

Разработка может съесть деньги, которые были нужны бизнесу для запуска.

Компания потратила $100,000 на создание продукта.

Продукт готов.

Но теперь нет денег на маркетинг.

Нет бюджета на привлечение первых пользователей.

Нет ресурсов на продажи.

Нет денег на эксперименты.

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

Это одна из самых дорогих ошибок в digital product development.

По данным CB Insights, которые проанализировали 385 закрывшихся стартапов, ключевая причина провала в 43% случаев, несоответствие продукта рынку. А нехватка капитала, которую обычно называют причиной смерти компании, на самом деле лишь симптом, который проявляется позже.

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

НЕ ПЛАН РАЗРАБОТКИ

$100,000, это не план разработки

Представим, что ко мне приходит предприниматель и говорит:

«У меня есть идея платформы. Бюджет, $100,000».

Первое, что я спрошу, не сколько функций он хочет.

Я спрошу:

Для чего нужна эта платформа?

Какая бизнес-идея за ней стоит? Какой бизнес-процесс она должна решать? Кто её клиент? Кто инвестор? И почему вообще определён бюджет именно в $100,000?

Потому что мы можем потратить эти деньги очень быстро. И после этого обнаружить, что главного ответа у нас всё ещё нет: нужен ли рынку этот продукт?

Иногда после исследования оказывается, что $100,000 действительно необходимы.

Иногда оказывается, что сначала достаточно $20,000.

Иногда, $5,000.

А иногда вообще не нужно начинать с разработки.

Сегодня существует огромное количество инструментов, с помощью которых предприниматель может самостоятельно проверить часть своей идеи: собрать landing page, прототип, форму, тестовую воронку, автоматизацию или даже первый рабочий сценарий продукта.

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

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

СЛИШКОМ БОЛЬШАЯ ИДЕЯ

Хорошая идея тоже может быть слишком большой

Есть ещё одна проблема, которую часто не видно в самом начале.

Предприниматель может искренне считать, что его идея достаточно простая.

Это нормально.

Он видит бизнес снаружи: несколько функций, личный кабинет, каталог, интеграция, платежи.

Мы начинаем разбирать его изнутри.

Изучаем рынок. Пользовательские сценарии. Бизнес-процессы. Интеграции. Данные. Ограничения. Будущую поддержку. И внезапно оказывается, что за простой формулировкой «сделать платформу» стоит очень сложная система.

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

И это, пожалуй, один из самых неприятных сценариев.

Исследование показывает, что рынок существует. Людям нужен продукт. Бизнес-модель потенциально работает.

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

Тогда есть только два плохих варианта: отказаться от идеи или попытаться построить всё сразу и поставить под угрозу весь бизнес.

И есть третий.

Разбить продукт на этапы.

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

Не потому, что идея плохая.

А потому, что бизнес должен дожить до момента, когда хорошая идея сможет себя доказать.

НЕ ВРЕМЕННЫЙ

MVP не обязан быть временным

Здесь же возникает вечный спор о технологии.

Кто-то говорит:

«Мы сделали MVP на CMS, а потом обязательно перенесём всё на Laravel».

Я всегда спрашиваю:

А зачем?

Если ответ, «потому что Laravel быстрее», я спрашиваю: в каком смысле?

Если ответ, «потому что Symfony лучше подходит для командной разработки», следующий вопрос: а какая у вас бизнес-модель и действительно ли это ограничение существует уже сейчас?

Технология, это инструмент.

Я могу купить самый дорогой и самый мощный инструмент в мастерской. Но если простая отвёртка решает мою задачу точно так же, пользователь не почувствует разницы.

CMS может быть прекрасным решением.

Custom development может быть прекрасным решением.

Гибрид может быть прекрасным решением.

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

Это тот же вопрос, что стоит и на уровне всего продукта, строить самим или использовать готовое. Уравнение build vs buy за последние годы сильно изменилось, и большинство компаний его ещё не пересчитали: Уравнение Build vs. Buy изменилось. Большинство компаний его ещё не пересчитали.

И это касается не только разработки.

НЕ ДОЛЖЕН ВЫГЛЯДЕТЬ МАЛЕНЬКИМ

Маленький продукт не должен выглядеть маленьким

Есть ещё одна вещь, которую я считаю принципиальной.

MVP часто воспринимают как что-то, что можно показать пользователю со словами:

«Ну вы понимаете, это пока MVP».

Нет.

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

Мы можем сделать MVP с полноценным UX, качественным UI и pixel-perfect реализацией.

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

Просто внутри него будет ровно столько функций, сколько необходимо для проверки первой гипотезы.

Минимальным должен быть объём, а не качество.

И в этом смысле идеальный MVP для меня выглядит очень просто:

Запустили.
Получили данные.
Поняли, что работает.
Исправили то, что не работает.
Запустили следующий этап.

Это не компромисс.

Это нормальный способ строить продукт.

ПОКАЗЫВАЕТ НЕ СТРОИТЬ

Иногда MVP показывает, что строить дальше не нужно

Был у меня и проект, где MVP, по сути, подтвердил наши первоначальные сомнения.

Идея была интересной: клиент хотел продавать кастомизированные видеоролики и построить вокруг этого полноценный e-commerce-продукт.

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

Сам продукт мы сделали. Он был красивым, технически интересным и вполне рабочим.

Но вопрос возник ещё до разработки:

а существует ли достаточный спрос?

И вот здесь как раз был момент, когда полноценная разработка была не лучшим первым шагом. Клиент хотел сразу полноценный e-commerce, хотя правильнее было бы сначала проверить саму модель.

Это хороший пример того, почему MVP нужен не только для экономии денег.

Иногда его главная задача, разрешить себе ошибиться дёшево.

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

Вы не потеряли год.

Не потратили весь бюджет.

Не построили огромную систему, которую теперь нужно поддерживать.

Вы просто получили ответ.

И этот ответ может быть:

«Нет, эту модель нужно изменить».

Это тоже успех MVP.

САМАЯ ДОРОГАЯ ОШИБКА

Иногда самая дорогая ошибка, ничего не запустить

Но есть и обратная сторона.

Я знаю клиентов, у которых была действительно хорошая идея, но они просто не решились её запустить.

И это тоже определённый риск.

Потому что хорошее свободное место на рынке редко остаётся свободным навсегда.

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

Иногда даже хочется самому позвонить и сказать:

«Посмотрите на эту идею ещё раз. Возможно, сейчас самое время её проверить».

Но здесь есть важная граница.

Мы не можем хотеть бизнес сильнее, чем его собственник.

Инициатива должна исходить от человека, который действительно собирается этот бизнес строить.

Потому что самые сильные проекты всегда имеют одну общую черту: у собственника есть огонь в глазах.

Есть желание проверить идею.

Есть готовность получить не только положительный, но и отрицательный ответ.

Есть готовность после первого результата изменить то, что он считал правильным.

В таком случае MVP становится не просто инструментом разработки.

Он становится способом дать хорошей идее шанс начаться.

УСЛЫШАТЬ ПЕРВЫМ

Иногда продукт нужно услышать до того, как он зазвучит целиком

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

В её начале происходит что-то странное. Ты ещё не понимаешь, что слушаешь. На сцене появляется человек, который выглядит почти как персонаж из другой истории. Музыка начинается очень просто.

А потом постепенно вступают инструменты.

Один.

Второй.

Третий.

И в какой-то момент ты понимаешь, что то, что сначала казалось странным и неполным, всё это время было только началом.

Мне кажется, хороший MVP работает примерно так.

Он не обязан сразу показывать весь продукт.

Он должен дать первую ноту.

Если она работает, можно добавить следующую.

Потом ещё одну.

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

И вот здесь, мне кажется, происходит самое интересное:

MVP перестаёт быть MVP. Он становится продуктом.

РАЗГОВОР С РЕАЛЬНОСТЬЮ

MVP, это разговор бизнеса с реальностью

В конечном итоге я не воспринимаю MVP как обязательную стадию каждого проекта.

Это инструмент.

Иногда самый правильный MVP, landing page.

Иногда, прототип.

Иногда, небольшой e-commerce.

Иногда, первая часть большой платформы.

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

А иногда исследование показывает, что MVP делать пока не нужно.

И это тоже нормальный результат.

Перед разработкой я бы хотел, чтобы у бизнеса были ответы хотя бы на три вопроса:

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

Какой минимальный работающий продукт позволит её проверить?

Какая метрика покажет нам, что гипотеза действительно работает?

Именно для поиска ответов на эти три вопроса мы в какой-то момент оформили отдельный формат, Strategic Session: разговор, в котором мы вместе разбираем бизнес, а не сразу продаём разработку.

Если ответы есть, можно строить.

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

Если ответов нет, возможно, сначала нужно исследовать.

И если для проверки гипотезы существует способ потратить $500 вместо $50,000, я считаю правильным сначала попробовать $500.

Не потому, что мы хотим сделать меньше.

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

Сейчас мы как раз разбираем новый MVP-проект в healthcare. Пока я не могу рассказывать о самом продукте, это конфиденциально. Но могу сказать, откуда он к нам пришёл: клиент нашёл нас после того, как прочитал именно такие материалы о нашем подходе к бизнесу. Не портфолио, не кейсы, не прайс-лист, а то, как мы думаем. И это само по себе неплохое доказательство того, что WHY работает лучше, чем HOW. Именно работа над этим проектом и стала одной из причин, почему я решил сформулировать эти мысли.

Каждый сложный проект снова возвращает меня к одному вопросу:

Что действительно нужно построить первым?

Потому что иногда лучший способ построить большую систему, сначала не строить её целиком.

И именно поэтому для меня MVP, это не минимальный продукт.

Это цена входа.

Автор: Евгений Боровой, основатель Peretz Agency.