Как рождается продукт. Часть 1: MVP

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

Ответ на него - MVP. Но здесь начинается путаница, которая стоит людям времени и денег.

Зачем нужен MVP и нужен ли он вообще

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

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

Главная ошибка: MVP и Minimal Lovable Product

Многие люди думают, что делают MVP, хотя ожидают от первой версии другого результата. Для этого есть термин Minimal Lovable Product, или MLP, - минимальный продукт, который пользователю приятно использовать.

Разница принципиальная.

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

У нас бывают ситуации, когда заказчик говорит: «У нас обязательно должна быть вот эта функция. А без неё кому вообще нужен сервис?» За каждой такой функцией стоит ожидание. Нужно разобраться, что именно она проверяет.

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

Типичный сценарий: фаундер называет первую версию MVP, но рассчитывает, что с запуска она заработает как полноценный бизнес. Люди начнут делиться продуктом, рассказывать друзьям, возвращаться. Иногда так бывает.

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

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

Типы MVP: от лендинга до людей за кулисами

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

Лендинг

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

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

Стоимость страницы и тестовой рекламы зависит от выбранного объёма. Бюджет эксперимента вы определяете заранее.

Что особенно полезно: такой способ получить отклик доступен основателю без собственной команды разработки.

Wizard of Oz - человек под капотом

Это MVP, в котором пользователь видит интерфейс или сервис, а часть работы за ним выполняют люди. Команда вручную обеспечивает результат, который позднее планирует автоматизировать.

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

Похожую историю часто рассказывают об «умных» кассах, которые якобы целиком обслуживались людьми за камерами. С конкретными примерами здесь нужна аккуратность: Amazon описывает работу Just Walk Out как автоматическую и отдельно объясняет роль сотрудников в разметке данных. Такой кейс нельзя выдавать за доказательство полностью ручной кассы.

Главная ловушка Wizard of Oz другая. Гипотеза подтвердилась, сервис востребован, всё хорошо. А потом выясняется, что ручной процесс слишком сложно автоматизировать. С ростом бизнеса пропорционально растут операционные расходы.

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

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

Консьерж-сервис

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

В раннем Airbnb основатели лично привлекали пользователей и помогали улучшать объявления. Эту работу описывает Пол Грэм. В раннем Zappos основатель фотографировал обувь в магазинах, размещал её в интернете, а после заказа покупал и отправлял пару.

Сначала команда вручную находит путь к клиенту и решает конкретную проблему. Затем оценивает, какие части этого пути можно автоматизировать и масштабировать.

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

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

Смок-тест

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

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

Так можно проверить интерес, заранее не заполняя склад.

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

Техдолг как инструмент первой версии

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

Допустим, для проверки достаточно обслужить 10 000 пользователей. Тогда инфраструктуру на миллион стоит обсуждать, когда появятся основания для такого масштаба. Число здесь - условие примера, а реальная нагрузка оценивается через сценарии использования.

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

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

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

P.S. Наверное, при десятках тысяч кофеен станет выгодно производить часть вещей самостоятельно. До этого ещё нужно дорасти.

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

Сроки: когда MVP перестаёт быть MVP

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

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

Здесь полезно понимать природу процесса. Разработчики пишут код. Каждая новая идея заказчика добавляет им работу. Рассчитывать, что кто-то сам остановит разрастание продукта, опасно.

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

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

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

Затем его становится тяжело обслуживать. Формально это всё ещё ранняя стадия: рынок требует быстрых изменений, а система уже большая. Резкие повороты приводят к временным обходным решениям. Их накапливается всё больше, и маневрировать становится труднее.

Финтех: где опасно экономить

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

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

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

Подходящий готовый сервис помогает сократить объём работ. Но выбрать поставщика, проверить интеграцию и разобраться с границами ответственности всё равно придётся. Готовый модуль не освобождает основателя от этих вопросов.

Что в итоге

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

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

Определите необходимый минимум, чтобы проверить идею или получить первую оплату. Выйдите к пользователям. Соберите обратную связь. Решите, что менять. Затем повторите цикл.

В следующей части поговорим о Product Market Fit: что происходит после запуска и как понять, нужен ли продукт рынку.