MVP за 8–10 недель: как запустить продукт и не построить лишнего

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

Что такое MVP на самом деле

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

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

Как резать функции

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

1. Ядро — без этого пользователь не может получить основную ценность. В примере с прокатом — бронь машины на даты.
2. Барьеры — без этого пользователь не начнёт пользоваться: регистрация, импорт данных, понятная первая настройка.
3. Удобства — делают работу приятнее, но без них можно обойтись: тёмная тема, массовые операции, горячие клавиши.
4. Масштаб — нужно, когда пользователей станет много: роли, филиалы, API, сложные отчёты.

В MVP идут первые две группы. Третья — точечно, если без неё сценарий становится мучительным. Четвёртая не нужна почти никогда: если продукт взлетит, у вас будут деньги и данные, чтобы сделать её правильно.

Что можно сделать вручную

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

• Онлайн-оплату можно заменить счётом, который выставляет менеджер.
• Сложный онбординг — созвоном, на котором вы помогаете клиенту настроить аккаунт. Заодно вы увидите, где люди путаются.
• Импорт из любых форматов — ручным переносом данных силами команды для первых десяти клиентов.
• Уведомления в мессенджеры — письмами на почту.

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

План на 8–10 недель

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

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

Пример: как сокращали список функций

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

Гипотеза, которую сформулировали после двух встреч: «Владельцы студий на 1–3 зала перейдут из мессенджера и таблицы в сервис, если клиенты смогут сами записываться на занятия, а владелец будет видеть заполненность групп». После этого список разложили по группам.

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

Как устроить обратную связь после запуска

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

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

Метрики, которые надо определить до старта

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

• Активация: какая доля зарегистрировавшихся дошла до ключевого действия (создала первую бронь, загрузила базу).
• Удержание: сколько пользователей вернулись через неделю и через месяц.
• Готовность платить: сколько пользователей согласились на платный тариф или предоплату. Это самый честный сигнал.

Для B2B-продуктов на старте хватит и 10–20 активных компаний, если вы поговорили с каждой и понимаете, почему они остаются или уходят.

Чего не стоит экономить даже в MVP

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

• Безопасность данных. Разграничение доступа между клиентами, хранение паролей, защита от типовых атак. Утечка в первые месяцы может похоронить продукт. Базовый список описан в чек-листе по OWASP.
• Модель данных. Если продукт будет многопользовательским, данные каждого клиента должны быть изолированы с первого дня. Переделывать это на живой базе — долго и рискованно.
• Резервные копии. Первые клиенты доверяют вам свои данные, и потерять их — значит потерять клиентов.
• Аналитика событий. Без неё вы не узнаете, как пользователи на самом деле работают с продуктом.

Типичные ошибки

Делать MVP для всех. Продукт «для малого бизнеса» проверить невозможно. Продукт «для автопрокатов на 5–30 машин» — можно.

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

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

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

С чего начать

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

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