Про MVP чаще всего читают теорию: что это такое и какие бывают этапы. Тема живёт в основном как учебная — а люди, у которых есть идея продукта, ищут не «MVP», а результат: магазин в телеграме, сервис записи, бота для заявок.
Поэтому здесь — не пересказ методологии, а разговор с той стороны, где идея превращается в работающий продукт: что делать первым, что не делать вообще и почему половина таких проектов не отвечает на свой же вопрос.
MVP — это не урезанная версия
Главное недоразумение, из которого растут все остальные.
MVP часто понимают как «то же самое, но подешевле»: тот же продукт, но с меньшим количеством функций. При таком понимании получается плохой продукт целиком — все разделы есть, и все сделаны наспех.
Правильная логика другая. MVP — это способ получить ответ на конкретный вопрос, и всё, что не нужно для ответа, из него безжалостно выбрасывается.
Вопрос обычно один из трёх:
- Нужно ли это людям вообще? Проверяется тем, приходят ли и пользуются.
- Готовы ли платить? Проверяется только деньгами, а не словами «интересно, напишите, когда сделаете».
- Работает ли это технически на реальных данных? Актуально там, где есть настоящая техническая неопределённость.
Разница между двумя подходами видна на примере. Сервис доставки еды «урезанной версией» — это сайт с каталогом, корзиной, регистрацией и админкой, но с тремя блюдами. MVP — форма заказа в мессенджере, три блюда и курьер, которому вы звоните сами. Второе отвечает на вопрос за неделю, первое — за три месяца.
- Есть все разделы, каждый неглубоко
- Личный кабинет, настройки, админка
- Месяцы до первого пользователя
- Непонятно, что именно не сработало
- Жалко выбрасывать сделанное
- Одно ключевое действие, сделанное хорошо
- Остальное — руками и вручную
- Первые пользователи почти сразу
- Понятно, какое предположение проверено
- Не жалко переделать
Что оставить, а что выбросить
Практический список, который снимает половину споров на старте.
Оставить. Одно действие, ради которого всё затевается: заказать, записаться, получить расчёт, купить доступ. Способ оплаты, если продукт платный. Способ связаться с вами. Всё.
Выбросить и делать руками. Личный кабинет — история заказов первое время присылается сообщением. Админка — заказы смотрятся в таблице или прямо в переписке. Настройки — выставляются вами по просьбе клиента. Восстановление пароля — а лучше вообще без паролей. Отчёты и аналитика — считаются вручную, пока клиентов десятки.
Выбросить и не делать. Всё «на будущее»: роли и права, многоязычность, интеграции «когда вырастем», настраиваемые шаблоны, тонкая гибкость. Каждая такая вещь — недели работы, потраченные до того, как стало известно, нужен ли продукт.
Проверочный вопрос по каждой функции: что мы узнаем, если её не будет? Если ответ «ничего, просто будет неудобно нам» — она не входит в MVP, она входит в ручную работу.
Ручная работа на старте — не костыль, а преимущество. Пока вы обрабатываете заказы руками, вы видите каждого клиента, слышите каждую жалобу и понимаете, что автоматизировать в первую очередь. Автоматизировав это заранее, вы автоматизируете свои догадки.
Чем проверять: способы по возрастанию цены
Проверка не обязана быть продуктом. Часто ответ добывается дешевле, чем кажется, — и выбирать стоит самый дешёвый способ, который отвечает на ваш вопрос.
| Способ | Что проверяет | Цена | Чего не покажет |
|---|---|---|---|
| Разговоры с клиентами | есть ли проблема и как её описывают | время | готовность платить |
| Страница с описанием и кнопкой | интерес и понятность оффера | день работы | реальный опыт использования |
| Предзаказ или предоплата | готовность платить | день-два | удержится ли человек в продукте |
| Ручная услуга под видом сервиса | ценность и реальный процесс | недели своего труда | масштабируемость |
| Работающий продукт с одним действием | всё вышеперечисленное сразу | недели разработки | поведение на объёме |
Четвёртая строка недооценена сильнее всех. Делать работу руками, пока клиент думает, что пользуется сервисом, — самый честный способ проверить ценность: вы отдаёте результат, за который платят, и при этом видите каждый шаг процесса изнутри. Автоматизировать потом становится вопросом техники, а не догадок.
Порядок выбора простой: берите верхнюю строку, которая отвечает на ваш вопрос. Если вопрос «поймут ли оффер», не надо писать код. Если «заплатят ли», нужна оплата, а не опрос. Если «удержатся ли», без работающего продукта не обойтись.
Где живёт продукт на старте
Отдельный выбор, который сильно влияет на срок и стоимость: где именно будет работать первая версия.
Мессенджер. Самый быстрый и самый недооценённый вариант для российского рынка. Бот или мини-приложение внутри Telegram снимает половину вопросов: не нужно приводить людей на сайт, не нужна регистрация, оплата встроена. Подходит для заказов, записи, подписок, доступа к контенту.
Сайт. Нужен, если продукт должны находить поиском или если интерфейс сложный: таблицы, редакторы, длинные формы. Дороже мессенджера, зато не зависит от чужой площадки.
Без интерфейса вообще. Форма для заявок и таблица. Идеально для услуг и всего, что делается людьми: проверяется спрос, а не технология.
Мобильное приложение. Самый дорогой и самый медленный старт: магазины приложений, проверки, обновления. В MVP оправдано редко — обычно только когда нужны фоновая работа, камера или датчики.
Здравый порядок: начинать с самого дешёвого варианта, который способен ответить на ваш вопрос. Мигрировать потом дешевле, чем сразу строить дом там, где, возможно, никто не будет жить.
Порядок работы
- 1Сформулировать предположениекто клиент, за что платит, почему сейчас
- 2Выбрать проверкучто должно случиться, чтобы считать идею подтверждённой
- 3Собрать минимумодно действие, всё остальное руками
- 4Привести людейканал продумывается до запуска, а не после
- 5Смотреть на поведениечто делали, а не что говорили
- 6Решитьдостраивать, менять предположение или закрывать
Первый шаг обычно пропускают, а он решающий. Предположение должно быть сформулировано так, чтобы его можно было опровергнуть: не «людям нужен удобный сервис записи», а «мастера маникюра готовы платить 1 500 ₽ в месяц за сервис, который сам напоминает клиентам о записи».
Второй шаг — критерий. Заранее решённое «если из ста человек десять оплатят, продолжаем» защищает от самообмана. Без критерия результат всегда трактуется в пользу продолжения, потому что жалко потраченного.
Четвёртый шаг — тот, на котором чаще всего всё разваливается. Продукт сделали, а людей не привели: канал никто не продумывал. Молчание в ответ трактуется как «идея плохая», хотя на самом деле её просто никто не видел.
Почему MVP не отвечает на свой вопрос
Пять причин, встречающихся чаще остальных.
Проверяли не главное. Сделали технически интересную часть, а вопрос был не в ней. Классика: собрали умный алгоритм подбора, а люди не пришли, потому что не поняли, зачем им это.
Не было оплаты. Слова «да, я бы пользовался» ничего не стоят. Единственная честная проверка платного продукта — попытка взять деньги, пусть с небольшой суммой.
Некому было прийти. Запустили без канала. Ноль пользователей — это ноль данных, а не отрицательный результат.
Слишком долго делали. За полгода изменилось всё: рынок, конкуренты, интерес основателя. MVP, который делается больше пары месяцев, перестаёт быть MVP.
Не смотрели на поведение. Спрашивали мнение вместо того, чтобы смотреть, что люди делают. Мнение вежливое, поведение честное.
Общий знаменатель: MVP — это эксперимент, а у эксперимента должны быть вопрос и критерий. Без них получается просто маленький продукт, о котором непонятно, что думать.
Как это выглядит на живых примерах
Четыре типичные идеи и то, как выглядит для каждой минимальная честная проверка.
Сервис записи для мастеров. Полная версия: приложение с календарём, кабинетами, оплатой и напоминаниями. MVP: бот, который показывает свободное время одного конкретного мастера и записывает. Расписание ведётся в обычном календаре, напоминания шлёт бот. Проверяется главное — будут ли клиенты записываться сами, вместо того чтобы писать в личку.
Магазин нишевых товаров. Полная версия: каталог с фильтрами, корзиной, доставкой, личным кабинетом. MVP: витрина в мессенджере на десять позиций с оплатой и ручной отправкой заказов. Проверяется спрос и средний чек, а не удобство фильтров.
Сервис для бизнеса на подписке. Полная версия: многопользовательский кабинет с ролями и настройками. MVP: делаете работу руками для трёх первых клиентов, беря за это деньги. Ноль строк кода, зато точное понимание, за что готовы платить и сколько.
Продукт с ИИ внутри. Полная версия: обученная система, интерфейс, интеграции. MVP: один сценарий на готовой модели, который решает конкретную задачу одного отдела. Проверяется качество ответов на реальных данных — та часть, где чаще всего всё и разваливается.
Общее у всех четырёх: ручная работа заменяет то, что дорого автоматизировать, пока неизвестно, нужно ли. Клиенты обычно не замечают разницы, а вы получаете ответ в разы быстрее.
Что делать с обратной связью
Отдельная тема, потому что именно здесь MVP чаще всего трактуют неправильно.
Смотрите на действия, а не на слова. «Классная идея, обязательно попробую» — не данные. Оплата, повторное использование, рекомендация знакомому — данные.
Считайте отказы там, где они происходят. Дошёл до оплаты и ушёл — одна проблема. Не дошёл до ключевого действия вообще — совсем другая. Без этого различия правки делаются наугад.
Разговаривайте с теми, кто ушёл. Они полезнее довольных: довольные объясняют, почему всё хорошо, ушедшие — что именно не сработало. Достаточно короткого вопроса «что вас остановило».
Не чините всё сразу. Из первых жалоб выберите те, что повторяются у нескольких человек. Единичное мнение чаще говорит о конкретном человеке, чем о продукте.
Отделяйте «неудобно» от «не нужно». Первое лечится доработкой, второе — сменой предположения. Путать их дорого: месяцы уходят на полировку того, что никому не требовалось.
Полезная привычка на этом этапе — записывать вопросы, которые люди задают перед покупкой. Через десяток разговоров список повторяющихся вопросов становится и текстом для сайта, и сценарием для бота, и подсказкой, чего в продукте не хватает.
Сколько это стоит
Считать удобно не в деньгах, а в неделях — деньги из них выводятся.
| Что делаем | Срок | Что определяет цену |
|---|---|---|
| Проверка спроса без разработки | дни | ничего, кроме вашего времени |
| Бот со сценарием и заявками | 1–2 недели | число веток и куда падают заявки |
| Продукт в мессенджере с оплатой | 3–6 недель | оплата, каталог, интеграции |
| Сервис со своим интерфейсом | от 6–8 недель | число экранов и внешних систем |
| Всё то же с ИИ внутри | плюс недели | что именно делает модель и на каких данных |
Последняя строка требует оговорки: модель платится не разово, а за каждый ответ. По тарифам GigaChat это 65 ₽ за миллион токенов у младшей модели и 650 ₽ у старшей. На MVP с десятками пользователей в день расход измеряется сотнями рублей в месяц — упереться в него на этом этапе почти невозможно. Считать всерьёз придётся, когда пользователей станут тысячи, и это хорошая проблема.
Главный множитель — число внешних систем, с которыми продукт должен связываться: оплата, доставка, учёт, календарь, CRM. Каждая связь — это не только работа, но и чужие ограничения, документация и сюрпризы. Интерфейс, каким бы красивым он ни был, обычно дешевле интеграций.
Второй множитель — чёткость требований. Проект, где заказчик знает, что должно происходить после оплаты, идёт вдвое быстрее проекта, где это выясняется в процессе. Порядок сумм по близким задачам разобран в статьях про то, сколько стоит чат-бот и сколько стоит ИИ-агент.
Нужен ли в MVP искусственный интеллект
Отдельный вопрос, потому что сейчас его добавляют почти в каждую идею.
Нужен, если продукт без него не существует. Разбор документов, распознавание свободного текста, генерация контента, поиск по смыслу — если суть продукта в этом, модель входит в MVP.
Не нужен, если это украшение. «Добавим ИИ-помощника» к сервису записи — украшение. Оно съест недели и не повлияет на главный вопрос: будут ли люди записываться.
Осторожно с непредсказуемостью. Модель отвечает по-разному на одно и то же. В MVP, где важно понять реакцию людей, это добавляет шум: непонятно, идея не понравилась или конкретный ответ был неудачным.
Разумный порядок: сначала проверить ценность продукта самым простым способом, потом добавлять модель туда, где она снимает конкретную боль. Общий разбор, где нейросети действительно дают эффект бизнесу, — в отдельной статье.
Как понять результат
Три исхода, и все три полезны.
Работает. Люди приходят, пользуются ключевым действием, возвращаются и платят. Дальше достраиваем по порядку жалоб — то, чего им не хватало, а не то, что придумали заранее.
Работает не так. Приходят, но используют иначе, чем задумано. Самый ценный исход: рынок показал настоящую потребность. Правильная реакция — идти за поведением людей, а не тянуть их к первоначальному замыслу.
Не работает. Не приходят или не платят. Прежде чем закрывать, стоит проверить одно: видел ли продукт кто-нибудь вообще. Если канал был, а реакции нет — предположение неверное, и это тоже результат, полученный за недели вместо года.
Худшее, что делают на этом этапе, — достраивают функции в надежде, что заработает. Продукт, который не нужен, не становится нужным от третьей кнопки. Если ключевым действием не пользуются, проблема в предположении, а не в наполнении.
С чего начать на этой неделе
Три шага, не требующих ни бюджета, ни подрядчика.
Запишите предположение одним предложением в формате «кто, за что и почему платит». Если сформулировать не получается, это и есть первая задача — не разработка.
Определите критерий. Что должно произойти за месяц, чтобы вы считали идею подтверждённой. Число, а не ощущение.
Найдите десять человек из вашей аудитории и покажите им идею. Не для одобрения, а чтобы услышать, как они описывают свою проблему своими словами. Половина продуктов после этого разговора меняет формулировку — и хорошо, что до разработки, а не после.
Дальше становится понятно, что именно собирать в первую очередь и можно ли обойтись без разработки вообще. Если продукт с нуля по вашей идее — это то, что нужно, разбор задачи и оценка есть на главной странице: я делаю такие продукты сам, от сценария до приёма оплаты.
