Являешься ли сторонником MVP

Являюсь ли сторонником MVP

Ответ: да, но с очень большой оговоркой. Я сторонник правильного MVP, а не того, что часто называют MVP в индустрии. Поясню различие.

1. Моя позиция по MVP

Я верю в MVP как методологию, но не как в упрощение качества.

Правильный MVP — это минимальный набор функций, который:

• Решает реальную пользовательскую проблему
• Позволяет собрать feedback для итерации
• Имеет хорошее качество в том, что включено
• Готов к масштабированию

Неправильный MVP (против которого я) — это:

• Продукт, в котором режут качество
• Фича, которая не решает проблему, а только "что-то делает"
• Продукт, который нельзя использовать нормально
• Техдолг, который потом не погашают

2. Преимущества MVP подхода (почему я его люблю)

Скорость валидации гипотезы

• Мы не тратим 6 месяцев на разработку совершенного продукта, который никому не нужен
• Выпускаем MVP за 4-8 недель, собираем feedback, понимаем что нужно
• Экономим 70% разработки на неправильном направлении

Пример: было предположение, что пользователи хотят "advanced analytics". Потратили бы 3 месяца на разработку. Вместо этого выпустили basic analytics за месяц → 80% юзеров даже не открывали analytics → понял что нужно не это.

Ранний feedback от реальных пользователей

• Нет ничего точнее, чем реальное поведение настоящего пользователя
• User tests и interviews ценны, но не как реальная данные
• MVP дает нам данные о том, как люди действительно используют продукт

Пример: думали, что пользователи будут использовать API для интеграции. MVP с базовым API → выяснили, что 85% людей хотят просто UI, API не нужен. Срезал целый раздел разработки.

Быстрое достижение product-market fit

• Вместо одного большого bang, мы делаем множество маленьких итераций
• Каждая итерация приносит нас ближе к PMF
• Если неправильно — быстро меняем направление

Экономия ресурсов

• Не переплачиваем за perfection
• Фокусируем бюджет на том, что действительно важно
• Можем отказать от features, которые никому не нужны

3. Почему я НЕ люблю неправильный MVP

Проблема 1: Технический долг

Часто MVP запускают с shortcuts: hardcode данных, отсутствие обработки ошибок, no tests.

Потом:

• Юзеры хотят масштабирования → надо переделывать
• Хотим добавить фичу → архитектура не позволяет
• Продукт ломается при росте юзеров

Техдолг становится больше, чем сэкономленное время. Я видел компании, которые потратили 6 месяцев на переписание продукта, потому что MVP был сделан без основ.

Проблема 2: Плохой опыт пользователя

Слишком упрощённый MVP может дать плохой first impression.

• "Это не подходит мне" → юзер уходит
• Даже если потом мы добавим нужное, он не вернётся
• First impression важен для viral growth

Я работал с продуктом, где MVP был настолько минимален, что 60% юзеров отказались, думая что это "версия для детей". Потом трудно было их вернуть.

Проблема 3: Неправильное направление

Если MVP слишком маленький, он может не дать достаточно feedback для правильных выводов.

• "Люди не используют фичу" — может быть, потому что она плохо сделана, а не потому что не нужна
• Получаем шум вместо сигнала
• Неправильно меняем направление

4. Мой подход к MVP: баланс

Вместо "максимально минимален", я делаю "правильно минимален".

Критерии для моего MVP:

5. Примеры MVP из практики

Пример 1: Payment system

Полный scope: 4 способа оплаты, рефунды, абонеобслуживание, аналитика, fraud detection. Технически: 3 месяца разработки.

Мой MVP:

• Только кредитные карты (90% платежей)
• Базовый refund через админку (1 неделю вручную)
• Essential аналитика (сколько платежей, сколько денег)
• Обработка ошибок (важно!)
• 50 часов unit-тестов на critical path

Что исключил (но готов добавить):

• PayPal, Apple Pay (позже)
• Subscription management UI (пока в БД вручную)
• Fraud detection (потом, когда будет масштаб)

Результат: MVP за 6 недель вместо 3 месяцев. Потом за 2 недели добавили PayPal (потому что код был правильной архитектуры). Никакого техдолга.

Пример 2: Collaboration features

Полный scope: real-time collaboration, comments, @mentions, notifications, version history, permissions. Технически: 2 месяца.

Мой MVP:

• Real-time editing (это сердце функции)
• Basic notifications (когда кто-то редактирует)
• Отсутствует: comments (потом), @mentions (потом), permissions (пока все видят всё)

Почему отсутствуют? Потому что 80% юзеров работают в маленьких командах (2-3 человека). Им не нужны comments и permissions. Лучше дать ими 1 месяц real-time и собрать feedback, чем всё делать за 2 месяца.

Что включил? Real-time мы делали правильно: с WebSockets, обработкой conflicts, можно масштабировать на 1000 юзеров.

Пример 3: Что-то неправильное (anti-pattern)

Компания выпустила MVP продукта с UI настолько минимальным, что пользователи не понимали как его использовать.

MVP был: простая форма, сохранение данных, всё.

Что не учли:

• Юзеры не знали "почему я это заполняю"
• Не было индикаторов прогресса
• Нет примеров
• Результат: 90% bounce rate

Потом они потратили месяц на улучшение UI, но first impression уже был испорчен. По-правильному: потратить на UI больше (но всё ещё меньше чем на полный продукт), собрать feedback, потом улучшать.

6. Когда MVP может быть плохой идеей

В safety-critical системах

• Медицинское оборудование, финансовые системы — здесь качество НЕ режешь
• MVP здесь = polished product, но с меньше фич
• Тестирование экстремальное

В enterprise B2B

• Customer может ожидать enterprise-quality даже в MVP
• Плохой MVP = потеря доверия
• Но можем сократить фич

В высокой конкуренции

• Если 5 конкурентов уже запустили, и мы хотим MVP
• MVP должен быть лучше их продуктов, но с меньше фич
• Это требует большего качества в том, что есть

7. Мой итоговый взгляд

Я за MVP, когда:

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

Я против MVP, когда:

• Это просто "давайте выпустим что-нибудь быстро"
• Качество режут для скорости
• Нет плана погашения техдолга
• Это даёт плохой first impression
• Это создаёт неправильное направление

8. Правило для себя

Перед тем как назвать что-то MVP, я спрашиваю:

Уточняющие вопросы:

1. Это решает реальную пользовательскую проблему? (если нет → это не MVP, это эксперимент)
2. Пользователь сможет это использовать без help? (если нет → нужен better UX, не значит больше фич)
3. Может ли это сломаться под нагрузкой? (если да → нужна архитектура, не значит больше фич)
4. Есть ли план для итерации? (если нет → это не MVP, это final product)
5. Будет ли техдолг? (если да → нужно его учесть в roadmap)

Заключение

Я большой сторонник MVP как методологии. Это позволяет быстро валидировать гипотезы и экономить ресурсы. Но MVP не значит "сделать плохо и быстро". Это значит "сделать хорошо, но меньше".

Получилось высказывание которое я люблю: "MVP не значит Minimal Viable Product. Это значит Minimum Valuable Product" — должно быть ценно для пользователя, а не просто минимально.

Если мы собираемся выпустить MVP, давайте выпустим то, что действительно решает проблему, а не то, что просто быстро сделано.