Разработка MVP: проверить идею продукта за месяц-полтора

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

Проблема в том, что слово «минимальный» понимают по-разному. Для одних это урезанный продукт со всеми функциями наполовину, для других — один сценарий, сделанный до конца. Работает второе.

Что именно проверяет MVP

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

Как выглядит правильное сужение

Как мы это делаем

1. Формулируем гипотезу и критерий. Что именно проверяем и по какой цифре поймем, что подтвердилось. Без критерия результат всегда трактуется в свою пользу.
2. Отрезаем лишнее. Из всего задуманного оставляем один сценарий, который доводит пользователя до результата. Остальное пишем в список «потом» — не выбрасываем, а откладываем.
3. Прототип за дни. Кликабельные экраны, которые уже можно показать десяти потенциальным пользователям. Часть гипотез отваливается здесь, и это самая дешевая проверка из возможных.
4. Собираем работающую версию. 3–6 недель. Настоящая, с настоящими данными и реальным входом — не демонстрация.
5. Запускаем на реальных людях. Смотрим не на мнения, а на поведение: доходят или нет, возвращаются или нет, платят или нет.
6. Решаем по результату. Развивать, менять направление или закрыть. Третий вариант — тоже результат, и он стоил вам полутора месяцев, а не года.

Что срезаем в первую очередь

• Второй и третий сценарии. Оставляем один путь. Остальные роли и случаи — в список отложенного.
• Админку. На десяти клиентах управление делается напрямую в базе или простым интерфейсом на пять экранов.
• Автоматический биллинг. Первые оплаты принимаются вручную по счету. Это экономит недели и ничего не искажает в проверке.
• Самостоятельную регистрацию. Пока пользователей мало, подключать можно руками — заодно поговорите с каждым.
• Интеграции. Часть данных первое время можно заливать файлом. Это некрасиво и совершенно нормально на этом этапе.
• Оформление. Опрятно и понятно — да. Уникальный дизайн — нет: он не влияет на проверку гипотезы.

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

Где здесь искусственный интеллект

MVP — та область, где инструменты изменили сроки сильнее всего.

• Прототип за часы. Экраны по описанию собираются так быстро, что обсуждение идет не о формулировках, а о том, что видно. Можно показать два варианта вместо спора о том, какой лучше.
• Реалистичные данные для проверки. Заполнить продукт длинными названиями, пограничными значениями и пустыми состояниями теперь дешево, а именно на них ломаются интерфейсы.
• Быстрая сборка каркаса. Формы, списки, авторизация, типовые экраны — рутина, которая раньше занимала недели, сейчас закрывается инструментами под присмотром разработчика.
• ИИ как часть самого продукта. Если гипотеза в том, что модель решает задачу пользователя, — проверять это надо в первой же версии, а не после. Здесь важно сразу считать стоимость обращения: продукт, который дорожает вместе с ростом, потом трудно развернуть.

Оборотная сторона: быстро сгенерированный красивый экран легко принять за продуманное решение. На вопрос «что человек здесь делает и в каком порядке» инструмент не отвечает — на него по-прежнему отвечает человек.

Какие бывают MVP

Минимальная версия — не обязательно продукт. Иногда гипотезу проверяют дешевле.

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

Частые ошибки

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

Что вы получаете

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

Сроки и стоимость

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

Как понять результат

1. Смотрите на поведение, а не на мнения. «Отличная штука, обязательно попробую» — не данные. Данные — зашел, дошел до результата, вернулся через неделю.
2. Считайте доходимость по шагам. Где именно люди отваливаются: на регистрации, на первом действии, перед оплатой. Это показывает, что чинить.
3. Разговаривайте с теми, кто ушел. Они полезнее довольных: довольные объясняют, что вам и так нравится.
4. Держите срок проверки заранее. Две-четыре недели после запуска, и по итогу — решение. Без даты проверка превращается в бесконечную доработку.
5. Отрицательный результат — тоже результат. Он стоил вам полутора месяцев вместо года. Это и есть смысл затеи.

Что бывает после

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

Если продукт пошел, следующий шаг — превратить проверочную версию в полноценную платформу: изоляция данных клиентов, тарифы, платежи, документы для юрлиц. Это уже другая задача, и мы описали ее отдельно: SaaS-платформы.

Кому это обычно нужно

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

Почему это выходит быстро

Короткий срок на MVP получается не за счет спешки, а за счет трех вещей.

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

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

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

Дальше по теме