Чому більшість MVP зазнають невдачі до запуску

Понад 100 продуктів запущено протягом кар'єр обох засновників. І режим невдачі майже завжди один і той же. Не неправильний технологічний стек. Не погана команда розробки. Нарада з планування, за шість тижнів до дедлайну, де хтось сказав "поки ми тут, давайте також додамо..." і ніхто не заперечив.

Проблема визначення

MVP означає Мінімально Життєздатний Продукт. Не Мінімальний Набір Фіч. Не "все, що нам здається потрібним, мінус дві речі". Мінімальний. Найменша річ, що доводить ключове припущення бізнесу.

Більшість команд визначають MVP, починаючи з усього, що хочуть, і прибираючи те, що здається очевидно несуттєвим. Це навпаки. В результаті ви отримуєте продукт, на будівництво якого пішло чотири місяці, що є 70% від задуманого, і все ще не перевірив єдину річ, що визначає, чи працює бізнес.

Справжня причина додавання фіч

Ніхто не додає фічу з недбалості. Її додають, бо відчувається безвідповідальним не додавати. "Ми не можемо запустити без сповіщень — користувачі не повернуться." "Нам потрібен дашборд звітності, або корпоративні клієнти не довірятимуть." "Конкурент має це — ми маємо відповідати."

Кожне з цих тверджень правдоподібне. Жодне не перевірено. Це припущення, одягнені у вимоги. І кожне подовжує терміни на тиждень, який стає двома з урахуванням складності, що вноситься в суміжні фічі.

Фіча, додана "про всяк випадок" — та, що затримує запуск на три тижні і все одно видаляється при переписуванні v2.

Тест, який має пройти кожна фіча

Перед додаванням будь-якої фічі до обсягу MVP вона має відповісти на це питання: "Якщо ми не включимо це, чи зможемо ми все одно перевірити, чи є ключова ціннісна пропозиція реальною?"

Якщо відповідь "так" — фіча не належить MVP. Вона належить v2. Мета MVP — не вражати. Мета — вчитися — якомога швидше й дешевше — чи вирішує те, що ви будуєте, проблему, за яку люди платитимуть.

Фічі, що майже ніколи не належать MVP:

• Розширена фільтрація та пошук (п'яти користувачам не потрібен Elasticsearch)
• Система email-сповіщень (ручні листи працюють до 50 користувачів)
• Адмін-дашборди звітності (експорт у таблицю витримує перші три місяці)
• Тури онбордингу та підказки (натомість розмовляйте з користувачами напряму)
• Мобільний застосунок (адаптивний веб-застосунок запускається вдвічі швидше)
• Інтеграції з інструментами сторонніх розробників (якщо ядро продукту не працює, інтеграції не мають значення)

Терміни брешуть, і ви їм вірите

Другий режим невдачі — прийняття термінів, що не можуть пережити контакт з реальністю. Розробник каже, що фіча займе два дні. Вона займає чотири. Помножте це на 12-тижневу збірку — і ви втратили три тижні ще до написання першого рядка CSS.

Виправлення — не точніше оцінювання. Оцінки завжди будуть неправильними. Виправлення — будувати по фазах із жорсткими воротами обсягу. На четвертому тижні ви демонструєте те, що існує. Якщо чогось нема — воно вирізається, а не відкладається. Терміни фіксовані. Обсяг рухається.

Як виглядає робочий процес MVP, що працює

Ми запускали продукти за вісім тижнів, що були живі на ринку, приносили дохід, ще до того, як "повністю укомплектована фічами" версія, яку спочатку описував клієнт, була б наполовину готова. Ось патерн, що працює:

• Починайте з одного шляху користувача — того, що перевіряє ключове припущення. Все інше — шум.
• Будуйте лише те, що вимагає цей шлях. Проведіть лінію до початку збірки і тримайте її.
• Запустіть для п'яти реальних користувачів до додавання чого-небудь. Їх зворотній зв'язок вартує більше, ніж будь-яка запланована фіча.
• Ставтеся до v1 як до дослідницького інструменту, а не продукту. Ви купуєте інформацію, а не будуєте ПЗ.
• Вирішуйте, як виглядатиме v2, на основі того, що ви дізналися з v1 — а не на основі дорожньої карти, написаної до запуску.

Жорсткіша правда

Найважча частина будівництва MVP — не будівництво. Це дисципліна не будувати. Це засновник, який має сказати "ні" власним ідеям. Менеджер продукту, який має розчарувати стейкхолдера. Розробник, який має відкинути вимогу, що звучить розумно, але додає три тижні.

Ця дисципліна — те, що відокремлює команди, які запускають і вчаться, від команд, що витрачають шість місяців на будівництво чогось, що нікому не потрібне, саме так, як вони це уявляли.

MVP, що запускається за вісім тижнів і зазнає невдачі, вчить вас чомусь. MVP, що запускається за шість місяців і зазнає невдачі, просто коштує вам шість місяців.