Кожна розмова про MVP починається з довгого списку функцій. Корисне питання — не «що ми можемо зібрати за десять тижнів?», а «що має бути правдою після запуску, щоб ми дізналися щось реальне?»
Ця різниця здається дрібницею, але вона змінює майже кожне наступне рішення — що будувати, що прибрати і що взагалі означає «готово» для першого релізу. Нижче — фреймворк, яким ми проводимо клієнтів під час discovery, ще до того, як написано перший рядок коду.
Назвіть один головний результат
Приклади: «Клініка може публікувати вільні слоти й отримувати записи» або «Диспетчер бачить статус водіїв у реальному часі». Якщо результат вимагає трьох непов'язаних перемог одразу — це не один MVP: спершу візьміть найризикованіше припущення.
Корисний тест: якщо ви не можете сформулювати результат одним реченням без слова «і» — швидше за все, ви скоупите два продукти. Розділити їх — це не компроміс, а те, що робить перший з них можливим до запуску за тижні, а не квартали, і дає реальну відповідь ще до того, як бюджет піде на другий.
Пропишіть non-goals у брифі
Явні відмови запобігають розповзанню скоупу: без адмін-аналітики, без мультимовності, без кастомного брендингу в v1. Стейкхолдери підписують не лише цілі, а й non-goals.
Це важливіше, ніж здається більшості команд. Список цілей каже всім, що ви будуєте; список non-goals каже всім, чого ви поки не будуєте — і саме це речення потім цитують посеред спринту, коли хтось питає «а можна ще й...». Без цього на папері кожен розумно звучний запит перетворюється на переговори. З цим — відповідь уже узгоджена заздалегідь.
Вертикальний зріз замість горизонтальних шарів
Тонкий наскрізний шлях через auth, дані й UI переважає ідеальну дизайн-систему без жодного робочого флоу. Полірування йде після доказу.
Ми постійно бачимо, як команди роблять навпаки: три тижні на бібліотеку компонентів, гарну дизайн-систему, повністю нормалізовану схему бази — і жодної кнопки, на яку користувач може натиснути, щоб отримати те, заради чого продукт існує. Спершу збудуйте потворний, але робочий шлях. Коли реальні дані вже течуть через нього, дизайн-системі є до чого прикріпитися, а схема перевіряється реальним використанням, а не здогадками.
Плануйте другий реліз ще до запуску
Знання, що входить у v1.1, зменшує панічні запити на нові функції під час UAT. Команди працюють спокійніше, коли roadmap видимий.
Це не означає детальні специфікації для v1.1 — лише короткий, узгоджений список «наступне, але не зараз». Коли стейкхолдер бачить бажану функцію посеред тестування, відповідь — не «ні», а «так, вона вже в списку на v1.1, приблизно тоді». Це одне речення знімає більшість тиску, який інакше перетворює двотижневе вікно UAT на переговори про скоуп заново.
Вимірюйте одну метрику
Оберіть completion rate, time-to-first-value або конверсію — не дванадцять дашбордів. Підключіть її до запуску, а не після перших скарг.
Якщо ви не можете назвати те єдине число, яке покаже, чи спрацював MVP, у вас поки немає інструмента для навчання — є здогадка в одязі продукту. Підключайте цю єдину метрику в тому ж спринті, де будуєте функцію, яку вона вимірює, а не окремим тікетом «на потім». Команди, які відкладають аналітику на потім, майже завжди запускаються без неї, а потім перші два тижні після релізу сперечаються про враження замість даних.
Хто повинен приймати рішення про скоуп
Скоупінг працює найкраще, коли на боці клієнта є одна людина з повноваженням сказати «ні» — засновник, product lead, хтось, хто може приймати компроміс «результат проти функції» без голосування комітету. Коли рішення про скоуп розподілені між п'ятьма стейкхолдерами з різними пріоритетами, «ріжемо рішуче» тихо перетворюється на «не ріжемо нічого», і MVP знову розростається до того ж списку побажань на десять тижнів, з якого й починався.
З нашого боку це зазвичай коротка фаза discovery: робоча сесія, щоб назвати результат, разом накидати список non-goals і накреслити вертикальний зріз до будь-яких оцінок. Дешевше витратити на це два дні тут, ніж виявити реальний скоуп через три спринти.
Типові помилки в MVP
Кілька патернів повторюються в проєктах незалежно від індустрії:
- Паритет функцій зі зрілим конкурентом. Нічиєму v1 не потрібно наздоганяти продукт, у якого за плечима п'ять років і повна команда. Наздоганяти базові очікування ринку замість доведення власної відмінності — спалити весь бюджет на те, що не відповідає на головне питання.
- Побудова під масштаб, якого ще немає. Інфраструктура, розрахована на десять тисяч користувачів, коли ви валідуєте продукт на п'ятдесятьох, відкладає те, що насправді має значення — отримання реального даних про використання.
- Відсутність власника списку скорочень. Non-goals без імені людини, яка їх відстоює, зазвичай розмиваються вже до третього тижня.
- Ставлення до MVP як до дешевшого повного продукту. MVP — це інструмент для навчання з інтерфейсом, а не урізана версія майбутнього продукту. Змішування цих двох речей — звідки починається більшість розмов «чому цей MVP робився так довго».
MVP провалюються, коли намагаються бути маленькими продуктами замість інструментів для навчання. Скоупте рішуче, запускайте чесно й ітеруйте на основі даних — а не почуття провини.