Я Алексей, разработчик Appex.Media. Ко мне регулярно приходят основатели с подробным ТЗ на 80 страниц и бюджетом на год разработки. Первое, что я предлагаю: давайте сначала проверим, нужен ли продукт людям. Для этого существует MVP. Ниже расскажу, какие бывают MVP, как мы укладываем первую версию в 8 недель, какие функции оставляем на потом, какие ошибки встречаются чаще всего и что делать с результатами после запуска.
Чего ждут от первой версии
Основатели обычно хотят, чтобы первая версия выглядела как готовый продукт: личный кабинет, уведомления, админка, интеграции, красивый дизайн. Кажется, что иначе пользователи не воспримут продукт всерьёз. На практике первые пользователи прощают простой интерфейс, если продукт решает их задачу, и не прощают продукт, который задачу не решает, каким бы красивым он ни был. Второе ожидание: после запуска MVP останется только дорабатывать. Иногда данные показывают, что идею нужно серьёзно менять, и это хороший результат: вы узнали это за два месяца, а не за год.
Что такое MVP
MVP (minimum viable product, минимально жизнеспособный продукт) это первая версия, в которой есть только функции, необходимые для решения главной проблемы пользователя. Цель MVP: как можно быстрее получить реальных пользователей и узнать, готовы ли они пользоваться продуктом и платить за него.
MVP часто путают с прототипом. Прототип показывает, как будет выглядеть продукт, но им нельзя пользоваться по-настоящему. MVP работает: человек может зарегистрироваться, выполнить главное действие и получить результат. От «сырой версии» MVP отличается тем, что в нём мало функций, но те, что есть, работают надёжно.
Почему это важно: по анализу CB Insights 101 закрывшегося стартапа, главной причиной провала в 42% случаев было отсутствие потребности рынка. Команды строили то, что никому не нужно. MVP помогает узнать это до того, как потрачен весь бюджет.
Какие бывают MVP
Не каждая проверка требует разработки. Лендинг-MVP: посадочная страница с описанием продукта и кнопкой «Оставить заявку» или «Предзаказ». Если на рекламу никто не откликается, писать код рано. Ручной MVP: услугу выполняют люди вручную, а клиент видит простой интерфейс. Так проверяют спрос на сервисы доставки, подбора, консультаций. MVP на конструкторах: продукт собирают из готовых сервисов без программирования, это быстро и дёшево, но плохо масштабируется. Полноценный минимальный продукт: собственный код с одной ключевой функцией, на котором потом строятся следующие версии. В 8 недель мы обычно делаем последний вариант, а если гипотеза совсем сырая, советуем начать с лендинга или ручной проверки.
Как сформулировать гипотезу
Хорошая гипотеза умещается в одно предложение и содержит цифру. Например: «Владельцы небольших салонов готовы платить за сервис, который сам напоминает клиентам о записи, и не менее 20 из 100 зарегистрировавшихся оплатят подписку в первый месяц». В такой формулировке есть аудитория, ценность и критерий успеха. Плохая гипотеза звучит как «людям понравится наше приложение»: её невозможно ни подтвердить, ни опровергнуть, и через два месяца спор о результатах будет бесконечным.
План на 8 недель
Неделя 1. Гипотеза и пользователи. Формулируем, для кого продукт, какую проблему он решает и как мы поймём, что гипотеза подтвердилась. Записываем конкретные цифры: например, 30% зарегистрировавшихся должны выполнить главное действие в первую неделю.
Неделя 2. Функции и прототип. Из списка желаемого оставляем только то, без чего продукт не решает главную задачу. Делаем кликабельный прототип и показываем его 5-10 потенциальным пользователям. Их реакция часто меняет приоритеты сильнее, чем недели обсуждений внутри команды.
Недели 3-6. Разработка. Двухнедельные спринты, промежуточные демо. Используем готовые сервисы для авторизации, оплаты и уведомлений, чтобы не писать с нуля то, что уже существует. Каждую неделю основатель видит, что готово, и может поменять порядок задач.
Неделя 7. Тестирование и подготовка к запуску. Подключаем аналитику, чтобы видеть, как люди пользуются продуктом, и проверяем основные сценарии на реальных устройствах.
Неделя 8. Запуск на первых пользователях. Для привлечения первых клиентов подключаем команду: Ольга запускает тестовую рекламу в соцсетях и Яндексе, Михаил готовит посадочную страницу под продвижение в поиске, Ирина помогает с соцсетями, если аудитория там.
Как выбрать функции для MVP
Для каждой функции задаём вопрос: если её убрать, сможет ли пользователь решить свою главную задачу? Если да, функция ждёт второй версии. Личный кабинет с аватаркой, тёмная тема и интеграция с десятью сервисами почти никогда не нужны в первой версии.
Удобно делить функции на четыре группы: обязательные (без них продукт не работает), важные (нужны во второй версии), желательные (если останется время) и ненужные сейчас. В MVP идёт только первая группа. Если она получается слишком большой, гипотеза, скорее всего, сформулирована слишком широко, и её стоит разбить на две.
В сообществах основателей на Reddit есть популярная мысль: если первая версия продукта не вызывает у вас лёгкого смущения, вы запустились слишком поздно. Она хорошо описывает подход: лучше выпустить простой продукт и учиться на реакции пользователей, чем полировать то, что никто не увидит.
Где найти первых пользователей
План привлечения составляется в первую неделю, параллельно с гипотезой. Самый быстрый источник это люди, с которыми вы говорили на этапе прототипа: попросите их стать первыми пользователями. Дальше профильные сообщества и чаты, где собирается ваша аудитория, небольшой рекламный бюджет на точную аудиторию и посадочная страница со списком ожидания. Для первых выводов обычно хватает нескольких десятков активных пользователей, сотни тысяч на старте не нужны.
Ошибки, которые мы видим чаще всего
- Нет критерия успеха. Через месяц после запуска никто не может сказать, подтвердилась ли гипотеза.
- MVP раздут до полноценного продукта. Восемь недель превращаются в восемь месяцев.
- Нет плана привлечения первых пользователей. Продукт готов, а показать его некому.
- Не подключили аналитику, и решения принимаются по ощущениям.
- Код написан «на выброс», и для второй версии приходится начинать заново.
Какие метрики смотреть после запуска
- Активация: какая доля зарегистрировавшихся выполнила ключевое действие.
- Удержание: возвращаются ли пользователи через неделю и через месяц.
- Готовность платить: сколько людей перешли на платный тариф или оставили предоплату.
- Качественная обратная связь: интервью с пользователями.
Что делать после MVP
Результат запуска обычно ведёт к одному из трёх решений. Если метрики выше целевых, развиваем продукт: добавляем функции из второй группы и увеличиваем привлечение. Если пользователи приходят, но не возвращаются, меняем ключевую функцию или аудиторию и проверяем снова. Если интереса нет совсем, честно закрываем идею или ищем другую проблему у тех же пользователей. Каждый из этих вариантов дешевле, чем год разработки продукта, который никому не нужен.
От чего зависит бюджет MVP
Бюджет определяют количество обязательных функций, платформы (веб, iOS, Android) и интеграции с внешними сервисами. MVP в виде веб-приложения обычно дешевле мобильного, а одно мобильное приложение на кроссплатформенной технологии дешевле двух нативных. Точную оценку даём после первой недели, когда список функций зафиксирован.
Что вы получите
- Работающий продукт на реальных пользователях через 8 недель.
- Данные для решения: развивать, менять или закрывать идею.
- Код, на котором можно строить следующие версии.
- Материалы для инвесторов: метрики и обратную связь пользователей.
Частые вопросы
Можно ли сделать MVP быстрее 8 недель?
Да, если функций совсем мало или достаточно лендинга и ручной проверки. Восемь недель это реалистичный срок для собственного кода с одной ключевой функцией.
Нужен ли MVP, если я уверен в идее?
Уверенность основателя не заменяет данные пользователей. MVP почти всегда меняет хотя бы часть планов, и лучше узнать это до большого бюджета.
Если ваш продукт мобильный, проверьте заранее, окупится ли приложение. А как мы ведём проекты после MVP, читайте в статье «Разработка ПО на заказ».
Есть идея продукта? Мы бесплатно проведём сессию на 1 час: сформулируем гипотезу, выберем функции для MVP и оценим сроки. Записаться на сессию по разработке MVP.
Источники
- CMO Council. Define the Need Before You Bleed (по данным CB Insights), 2021.
Алексей, разработчик Appex.Media
