MVP; MLP; MMP; RAT

https://gemini.google.com/app/8790ffb03161175a

MLP, MMP или RAT. Сейчас в стартап-среде идет активная дискуссия о том, что классический MVP (минимально жизнеспособный продукт) перестал работать, потому что пользователи стали более требовательными.

MVP (Minimum Viable Product) остается фундаментом. Это классика методологии Lean Startup (бережливый стартап).

Что такое MVP на самом деле и Почему от него начали уходить к MLP (смотри ниже) ?

MVP ( Консьерж — MVP; MVP «Волшебник из страны Оз»; Landing Page Одностраничник ) — это версия продукта, которая позволяет собрать максимум подтвержденных знаний о клиентах с минимальными усилиями.

Для MVP важно:

быстро проверить гипотезу
а не «быть занятым»

Главная ошибка — думать, что это «недоделанный» продукт. На самом деле это самая ранняя версия, которая решает одну конкретную проблему пользователя.

Главные принципы MVP

Минимум функций: Вы берете только одну «киллер-фичу» (главную ценность), без которой продукт не имеет смысла.
Жизнеспособность: Продукт должен работать. Если это сервис по доставке, еда должна приехать, даже если заказ принимает не бот, а вы лично по телефону.
Цикл обратной связи: Цель MVP — не заработать миллионы, а ответить на вопрос: «Нужно ли это рынку?».

Знаменитая метафора про скейтборд: Если ваша цель — создать машину, то MVP — это не колесо (оно само не едет), а скейтборд. Он тоже перевозит человека из точки А в точку Б, хоть и менее комфортно. Затем вы делаете самокат, велосипед и, наконец, автомобиль.

Зачем нужен MVP?

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

Виды MVP (которые часто путают с самим продуктом)

Консьерж — MVP: Вы выполняете всю работу вручную вместо алгоритма. (Например, вручную подбираете туры, имитируя работу сложного сайта).
MVP «Волшебник из страны Оз»: Снаружи кажется, что всё автоматизировано, но «за ширмой» человек вручную обрабатывает запросы.
Landing Page (Одностраничник): Просто описание продукта и кнопка «Оставить заявку». Если люди кликают и оставляют почту — спрос есть.

Почему от него начали уходить к MLP?

Проблема в том, что в 2020-х годах «просто работающего» продукта (MVP) часто уже недостаточно. Рынок избалован. Если ваш «скейтборд» скрипит, выглядит ужасно и разваливается, пользователь не будет ждать, пока вы сделаете велосипед — он уйдет к тому, у кого уже есть красивый самокат.

Как составить список функций для MVP по моей идее, чтобы отсечь всё лишнее? (нажми чтобы раскрыть делали)

https://gemini.google.com/app/080416599944b959

Создание MVP (минимально жизнеспособного продукта) — это упражнение на дисциплину. Ваша задача не в том, чтобы сделать «дешевую версию» продукта, а в том, чтобы проверить главную гипотезу, затратив минимум ресурсов.

Вот пошаговый алгоритм, который поможет вам отфильтровать лишнее:

1. Сформулируйте «Проблему» и «Решение» в одно предложение

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

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

Все функции, которые не относятся к «поиску передержки», в MVP не входят.

2. Составьте User Journey Map (Путь пользователя)

Распишите шаги, которые должен пройти пользователь, чтобы достичь цели.

Пример для сервиса передержки:

Регистрация/Вход.
Поиск (фильтр по датам и району).
Просмотр анкет догситтеров.
Бронирование и оплата.
Чат для связи.

3. Используйте метод приоритизации MoSCoW

Выпишите все идеи функций и распределите их по четырем корзинам:

Must Have (Должно быть): Без этого продукт вообще не имеет смысла (например, кнопка «Забронировать»).
Should Have (Следовало бы): Важно, но можно запустить первую версию без этого (например, система отзывов).
Could Have (Можно было бы): Приятные мелочи (например, пуш-уведомления или темная тема).
Won’t Have (Не будет): То, что вы официально откладываете на будущее (например, интеграция с умными ошейниками).

4. Матрица «Ценность vs Сложность»

Оцените оставшиеся функции по двум критериям: насколько это важно для юзера и насколько дорого/долго это разрабатывать.

Quick Wins (Быстрые победы): Высокая ценность, низкая сложность. Делаем в первую очередь.
Big Bets (Большие ставки): Высокая ценность, высокая сложность. Делаем одну-две.
Fill-ins (Мелочевка): Низкая ценность, низкая сложность. Делаем, если осталось время.
Thankless Tasks (Бесполезная работа): Низкая ценность, высокая сложность. Удаляем безжалостно.

Главные вопросы для самопроверки:

Можно ли это сделать вручную? (Например, вместо сложного алгоритма подбора — вы сами присылаете варианты в Telegram).
Сломается ли бизнес-логика без этой функции? Если нет — удаляйте.
Нужно ли это для проверки гипотезы? Если вы проверяете, будут ли люди платить за услугу, вам нужна форма оплаты, но не нужна страница «О компании».

Хотите, попробуем разобрать вашу идею? Расскажите в двух словах, что вы задумали, и мы вместе набросаем список Must-have функций.

Вот основные варианты того, о чем вы могли слышать:

1. MLP — Minimum Lovable Product

(Минимально привлекательный/любимый продукт)

Это самая популярная альтернатива сегодня.

Суть: Если MVP фокусируется только на функциональности (чтобы просто работало), то MLP делает упор на эмоции.
Зачем это нужно: Рынок перенасыщен. Если вы выпустите «гадкого утенка», пользователи просто уйдут к конкурентам с более красивым интерфейсом. MLP должен быть не только полезным, но и приятным в использовании с первого дня.

2. MMP — Minimum Marketable Product

(Минимально пригодный для продажи продукт)

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

3. RAT — Riskiest Assumption Test

(Проверка самого рискованного предположения)

Суть: Это даже не продукт, а эксперимент. Вместо того чтобы строить прототип, вы проверяете самую слабую точку вашей идеи.
Пример: Если вы хотите запустить доставку еды дронами, ваш главный риск — не приложение, а «полетят ли вообще дроны в городе?». RAT — это тест именно этого факта.

Сравнение подходов

Термин	На чем фокус?	Главный вопрос
MVP	Функциональность	Работает ли это?
MLP	Дизайн и опыт	Полюбят ли это пользователи?
MMP	Продажи	Купят ли это люди?
RAT	Риски	Не ошибаемся ли мы в самой основе?