Якби мене попросили залишити підприємцю-початківцю лише три літери, я не вибрав би ні CEO, ні ROI, ні навіть USD. Я залишив би MVP. Minimum Viable Product, мінімальний життєздатний продукт. За багато років роботи з бізнесом я бачив, як ці три літери економили людям роки життя, і бачив, як їхня відсутність зʼїдала і роки, і квартири, і шлюби. Звучить драматично, але я не перебільшую: найдорожчий продукт у світі це той, який робили три роки, а потім зʼясували, що він нікому не потрібен. Гроші можна заробити знову. Три роки ні.
Три літери, у кожної своя робота
Кожну літеру в MVP люди чомусь читають по-своєму і майже завжди гублять одну з них. Тому розберу їх окремо, як деталі механізму, який не працює, якщо вийняти хоча б одну шестерню.
M, Minimum. Мінімальний не означає бідний, кривий чи соромний. Мінімальний означає, що з продукту прибрано все, без чого він усе ще розвʼязує головну проблему. Це скульптура в розумінні Мікеланджело: береш брилу й відсікаєш зайве. Найскладніше тут не програмування, а сміливість відсікти. Кожна фіча в голові засновника здається необхідною, у кожної є захисник, і зрештою «мінімальний» продукт обростає особистим кабінетом, трьома ролями, мобільним застосунком та інтеграцією з бухгалтерією. Це вже не мінімум, це просто страх.
V, Viable. Життєздатний. Саме цю літеру гублять найчастіше. Гарний макет у Figma не життєздатний, ним не можна пройти, ним не можна скористатися, за нього ніхто не заплатить. Життєздатність означає, що реальна людина може прийти, розвʼязати своє завдання і піти задоволеною. Нехай криво, нехай частину роботи за лаштунками робить живий оператор замість алгоритму, але цінність доставлена по-справжньому.
P, Product. Продукт, а не проєкт і не презентація. У продукту є користувач, у користувача є поведінка, а поведінку можна виміряти. Якщо Ви не можете сказати, що саме вимірюватимете після запуску, у Вас не продукт, а експонат.
Самокат проти лімузина
Є відома картинка, яку люблять малювати на тренінгах: якщо клієнтові потрібен автомобіль, погана команда спершу дає йому колесо, потім вісь, потім кузов, і лише наприкінці машину. Клієнт увесь цей час стоїть пішки й злиться. Добра команда спершу дає самокат, потім велосипед, потім мотоцикл, потім автомобіль. На кожному кроці людина вже їде. Повільно, незручно, але їде, і на кожному кроці каже Вам, що їй насправді потрібно. Іноді на етапі велосипеда зʼясовується, що машина їй узагалі не потрібна, вона просто хотіла діставатися на роботу без заторів. Ви зекономили завод.
Я обожнюю цю метафору, але в житті є нюанс, про який на тренінгах мовчать. Засновники не люблять самокати. Самокат несолідно показувати інвесторам, дружині, колишнім одногрупникам. Хочеться одразу лімузин, зі шкіряним салоном і підсвіткою. І от тут починається головна драма: лімузин будують три роки, а за цей час дорога встигає змінитися.
MVP це не урізаний продукт. Це питання, поставлене ринку мовою, яку ринок розуміє: мовою дій, а не слів.
Чому це економить роки й мільйони
Кожен проєкт стоїть на кількох припущеннях. Людям потрібна ця річ. Вони готові за неї платити. Ми можемо доставляти її дешевше, ніж беремо. Ми зможемо знайти клієнтів за розумною ціною. Якщо хоч одне з них хибне, проєкт мертвий, скільки б грошей у нього не вклали. Класична розробка перевіряє ці припущення в самому кінці, коли все вже збудовано. MVP перевертає порядок: спершу перевіряємо найнебезпечніше припущення, а будуємо потім. Це як сапер, який спершу перевіряє мінне поле, а вже потім несе на нього рояль.
У нас був клієнт, який прийшов із повним технічним завданням на велику платформу: десятки екранів, складна система ролей, звіти на всі випадки життя. Я спитав, скільки людей уже користуються його послугою зараз, без жодної платформи, через телефон і таблиці. Виявилося, жодної. Платформа мала створити попит, якого ще не існувало. Ми домовилися зробити маленьку робочу версію одного сценарію і дати її першому десятку живих клієнтів. За місяць половина пунктів із того величезного завдання просто зникла: клієнтам вони були не потрібні, натомість спливли дві речі, про які ніхто не подумав. Це не провал ТЗ, це нормальна робота MVP. Ринок виправив план швидше й дешевше, ніж будь-який аналітик.
У 2026 році MVP став ще важливішим, а не простішим
Зараз багато хто каже: навіщо мучитися з мінімальністю, якщо код пише штучний інтелект за вихідні? Я відповім парадоксом. Код подешевшав, а помилка в напрямку ні. Нейромережа з однаковим ентузіазмом згенерує і потрібний продукт, і непотрібний. Швидкість розробки зросла в рази, і це означає, що сьогодні можна поїхати не туди в рази швидше. Тому дисципліна MVP, тобто чітка гіпотеза, метрика і рішення «продовжуємо чи ні», зараз важливіша, ніж будь-коли. Швидко зібрана демка ще не MVP. MVP стає тоді, коли в неї зʼявляється питання і чесний спосіб отримати відповідь.
Ми в Ingello використовуємо для цього Fractal: систему описують, а генератор породжує код, базу, API та адмінку. Це дозволяє зробити життєздатну першу версію за дні. Але я завжди попереджаю клієнтів: швидкість генерації не замінює мислення, вона лише звільняє для нього час. Основну роботу, як і раніше, робить голова, яка вирішує, що відсікти.
Що робити завтра
- Сформулюйте одним реченням найнебезпечніше припущення Вашого проєкту.
- Придумайте найменший продукт, який доставить реальну цінність і водночас відповість на це питання.
- Заздалегідь запишіть, який результат означатиме «так», а який «ні». Якщо цього не зробити, будь-який результат Ви потім пояснитимете на свою користь.
- Покажіть його живим людям протягом місяця, а не року.
Три літери. Мінімальний, життєздатний, продукт. Якщо тримати в голові всі три одразу, вони працюють як компас, що не дає піти в болото перфекціонізму чи в пустелю презентацій. Решта прикладеться.
