Что должен — и не должен — включать ваш SaaS-MVP на старте

Слово «минимальный» в minimum viable product — это та часть, которую все игнорируют. Основатели кивают идее начать с малого, а потом передают спецификацию с сорока экранами, тремя ролями пользователей, биллинговым движком, аналитической панелью и «а ещё оно должно интегрироваться со всем подряд». Это не MVP. Это полноценный продукт с оптимизмом, выкрученным на максимум. И это самая частая причина, по которой первые запуски выходят с опозданием, превышают бюджет и каким-то образом всё ещё лишены той единственной вещи, которую клиенты действительно хотели.

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

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

Чем MVP на самом деле является (и чем нет)

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

Ключевое слово — viable (жизнеспособный). Распространённая ошибка — прочитать «минимальный» и выпустить нечто настолько голое, что это смущает пользователя: половину потока, который падает, регистрацию, ведущую на пустой экран. Это не минимально-жизнеспособное, это минимально-сломанное. Другая неудача — противоположная: продукт настолько «полный», что на его постройку ушёл год, а к этому времени вы сожгли свои резервы, доказывая догадку, которую могли проверить за восемь недель.

Вот мысленный тест, который я использую. Для каждой функции в списке спросите: если бы мы её убрали, мог бы пользователь всё ещё получить тот единственный основной результат, ради которого существует продукт? Если ответ «да», это почти наверняка не MVP. Один этот вопрос разрежет большинство спецификаций пополам — и та половина, что отсекается, и есть та, что собиралась вас задержать.

Найдите ту единственную задачу, которую решает ваш продукт

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

Попробуйте закончить это предложение вслух: «Пользователь приходит в мой продукт, чтобы ______, и уходит, ______.» Инструмент для графиков: руководитель приходит опубликовать расписание на следующую неделю и уходит со всеми сменами закрытыми и командой уведомлённой. Приложение для счетов: фрилансер приходит выставить счёт клиенту и уходит с отправленным, отслеживаемым счётом. Если вы не можете заполнить это предложение чисто, вы ещё не готовы очерчивать объём — вы готовы думать.

Что действительно нужно любому SaaS-MVP

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

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

Заметьте, чего нет в этом списке: биллинга, изысканного онбординга, страниц настроек, мобильных приложений, интеграций. Через минуту дойдём до того, почему. Смысл пола в том, что он достаточно мал, чтобы его закончить, и достаточно прочен, чтобы на нём учиться. Вход, который работает, один поток, который доставляет результат, настоящие данные и способ наблюдать за пользователями и говорить с ними. Это жизнеспособный продукт.

Что осознанно оставить за пределами v1

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

Автоматический биллинг и сложное ценообразование

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

Сложные роли и права доступа

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

Интеграции, нативные мобильные приложения и панель

«Оно должно интегрироваться со всем» — это фраза, которая тихо удваивает сроки. Выберите максимум одну интеграцию, и только если она часть основной задачи. Нативные приложения для iOS и Android почти всегда могут подождать — адаптивное веб-приложение работает на телефоне уже сегодня. А та аналитическая панель, которую все хотят? Пользователи не могут анализировать данные, которые ещё не создали. Сначала выпустите то, что создаёт данные; визуализируйте их, когда будет что показать.

Простой метод провести черту

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

1. 1
   Выпишите каждую функцию, которую вы себе представили

   Вывалите всё — пока без фильтрации. Положите полный список желаний на стол, чтобы ничто не таилось невысказанным и не всплыло посреди разработки как сюрприз.
2. 2
   Отметьте каждую относительно основной задачи

   Для каждой функции спросите: нужно ли это пользователю, чтобы завершить одну основную задачу от начала до конца? Пометьте её «ядро», «полезное» или «когда-нибудь». Будьте честны — большинство попадёт в последние две.
3. 3
   Оставьте для v1 только «ядро»

   Ваш MVP — это куча «ядра» и ничего больше. Кучи «полезное» и «когда-нибудь» не отвергнуты — это ваша дорожная карта, припаркованная там, где ей место.
4. 4
   Проверьте отсечение на здравый смысл

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

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

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

По другую сторону черты есть свой режим провала, и его стоит назвать. В спешке выпустить нечто маленькое некоторые основатели выпускают нечто убогое — и называют это MVP. Основной поток, который теряет вашу работу, регистрация, выдающая 404, тексты, набитые заглушками. Это не проверяет вашу идею честно; это проверяет, стерпят ли пользователи сломанный опыт, и ответ всегда «нет». Вы заключите, что идея провалилась, тогда как на самом деле провалилось исполнение.

«Минимальный» относится к объёму, никогда — к качеству той части, что вы сохраняете. Меньше функций, каждая прочная. Тот единственный рабочий поток, что вы выпускаете, должен ощущаться завершённым — быстрым, ясным и заслуживающим доверия — даже если это единственное, что делает продукт. Узкий продукт, сделанный хорошо, всякий раз бьёт широкий продукт, сделанный плохо, особенно когда вы просите незнакомцев доверить вам их работу.

MVP — не финишная черта, а первое показание

Вот часть, которая переосмысляет всё: запуск — не цель. Цель — то, что вы узнаёте в недели после него. MVP, который выходит и говорит вам «пользователи любят ядро, но всё просят X», — оглушительный успех, даже если X означает ещё месяц работы. MVP, который выходит в тишину, где никто не возвращается, тоже выполнил свою работу: он избавил вас от постройки остальных тридцати функций на фундаменте, который никому не был нужен.

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

Частые вопросы