Цифровые продукты ·
MVP и SaaS отвечают на разные вопросы
Основатель говорит: «Хочу сделать MVP, а потом превратить его в SaaS». Фраза звучит логично, но смешивает этап проверки идеи со способом работы продукта. MVP может с первого дня быть SaaS. И наоборот: действующий SaaS давно перестал быть экспериментом. Разница важна для сметы, архитектуры и честного ответа на вопрос, что именно должно получиться после первого этапа.
MVP — способ проверить предположение
Minimum Viable Product — минимальная версия решения, с помощью которой команда получает достоверное знание о клиентах, затратив минимум усилий. В этой формулировке Эрика Риса важно не слово «минимальная», а проверка: какое предположение мы испытываем и какое действие человека позволит сделать вывод? Авторское объяснение MVP подчёркивает, что речь не просто о продукте с меньшим числом функций.
Предположение может звучать так: «Небольшие магазины готовы передавать данные об остатках в один сервис, если он заранее предупреждает о дефиците». Тогда первая версия должна позволить реальному владельцу подключить данные, получить предупреждение и решить, полезно ли оно. Экран с красивым графиком, заполненным демонстрационными числами, может быть хорошим прототипом, но не проверит это предположение.
У MVP есть срок для решения. После наблюдений команда продолжает идею, меняет её или прекращает работу. Это не постоянный знак на продукте и не оправдание сломанного основного сценария. Ненужные функции можно отложить; результат, ради которого человек пришёл, должен быть настоящим.
SaaS — способ предоставлять и поддерживать программу
Software as a Service означает, что клиент пользуется приложением поставщика через сеть, а поставщик отвечает за работу программной среды. Определение NIST описывает доступ к приложению провайдера без управления базовой облачной инфраструктурой со стороны клиента. В продуктовой работе к этому добавляются постоянные задачи владельца сервиса: доступы, обновления, поддержка, данные и восстановление после сбоев. AWS описывает SaaS шире — как бизнес-модель и способ поставки с повторяемым обслуживанием клиентов.
Подписка часто сопровождает SaaS, но не является самим определением. Можно брать оплату за пользователя, за объём использования или применять другую коммерческую схему. Так же и браузерный интерфейс сам по себе не делает всякий сайт SaaS: информационный сайт показывает материалы, а SaaS даёт человеку повторяемый рабочий инструмент, за функционирование которого отвечает поставщик.
MVP отвечает на вопрос «что нужно проверить сейчас?». SaaS отвечает на вопрос «как клиент получает и продолжает использовать программу?». Эти вопросы расположены на разных осях, поэтому выбирать между MVP и SaaS нельзя.
Один продукт может быть и MVP, и SaaS
Представим сервис, который помогает магазину замечать риск отсутствия товара. Для первого испытания команда предлагает одному типу клиентов загрузить таблицу и увидеть список позиций, требующих внимания. Если данные действительно обработаны, предупреждение понятно, а владелец магазина возвращается к нему при следующем заказе, это может быть MVP будущего SaaS. Часть обработки допустимо выполнять вручную, если это честно обозначено и не искажает проверку ценности.
Когда сервис начинает обслуживать разные магазины регулярно, появляются обязанности, которые нельзя оставлять «на потом»: отделение данных клиентов, права доступа, устойчивое обновление, обработка ошибок, помощь пользователю и понятный выпуск изменений. Это не перечень функций для первого экрана, а условия доверия к работающему сервису. Если MVP уже принимает реальные данные, необходимые меры защиты и восстановления нужны уже в эксперименте.
Бывает и другая комбинация. Компания создаёт MVP внутреннего приложения для своей команды и не собирается предоставлять его внешним клиентам как сервис. Или покупает зрелый SaaS у другого поставщика — в этом случае экспериментом может быть новое рабочее правило компании, но купленная программа не становится её MVP.
Не путайте проверку спроса с готовностью платформы
Команды часто говорят «сначала MVP» и закладывают в первый этап регистрацию, несколько тарифов, оплату, роли, сложную аналитику и панель администратора. Если главная неопределённость — нужна ли услуга вообще, этот объём отодвигает встречу с реальным пользователем. Сначала сформулируйте одно рискованное предположение и самый короткий полноценный путь, на котором его можно проверить.
Обратная ошибка — показать нескольким людям интерфейс и назвать проверку успешной. Похвала макету не равна использованию. Нужны наблюдаемые действия: человек возвращается, передаёт данные, выполняет задачу, готов обсуждать оплату или выбирает ваш способ вместо прежнего. Какие именно действия важны, зависит от обещания продукта; универсальной «нормы конверсии MVP» нет.
При этом малая версия не должна скрывать ограничения. Если расчёт делает человек, а не алгоритм, так и объясните. Если доступ открыт только пилотной группе, назовите границы. Честный эксперимент даёт более полезный вывод, чем имитация готовой автоматизации.
Как поставить задачу на разработку
Для MVP в брифе достаточно точно назвать аудиторию, проблему, проверяемое предположение, основной сценарий и признак, по которому команда примет решение. Добавьте ограничения по сроку, бюджету и данным. Это позволяет отложить второстепенное, не вырезав саму ценность.
Для SaaS-проекта отдельно опишите модель доступа, обязанности поставщика, хранение и разделение данных, поддержку, обновления и способ оплаты, если он нужен. Не все механизмы обязаны быть сложными в первой версии, но критические границы должны быть понятны до появления реальных клиентов. Так становится видно, где можно начать с ручной операции, а где экономия создаст риск для пользователя.
Я начинаю такие проекты с карты предположений и одного сквозного сценария. Если задача ещё не доказана, спроектируем MVP, который позволит принять решение о продукте. Если спрос уже подтверждён и нужен сервис для регулярной работы клиентов, заложим обязанности SaaS в архитектуру и план развития. Иногда это один и тот же продукт на разных этапах — но объём первой работы становится ясным только после разделения двух вопросов.
От идеи к цифровому продукту
Если задача требует сервиса или внутреннего инструмента, определим первый законченный сценарий и путь к работающей версии.