MVP, це не мінімальний продукт. Це вартість входу.

ПОЧАТИ З МАЛОГО

Не обов'язково починати з розробки

Чому великі цифрові продукти не завжди потрібно будувати повністю, і як перший робочий етап допомагає зрозуміти, куди справді варто інвестувати.

Великі цифрові продукти майже завжди виглядають переконливо ще до того, як починають працювати.

Є ідея. Є презентація. Є бізнес-модель. Є технічне завдання на десятки сторінок. Є список функцій, які «обов'язково мають бути» у першій версії. Є бюджет.

А іноді є й $100,000.

І в цей момент виникає дуже просте питання, яке чомусь часто ставлять останнім:

А нам справді потрібно зараз будувати все це?

Я не проти великих продуктів. Навпаки. Мені подобається працювати зі складними системами, де є архітектура, велика кількість функцій, інтеграцій і бізнес-процесів. Але я вже давно перестав вважати, що складний продукт обов'язково потрібно починати зі складної розробки.

Для мене MVP, це не мінімальний продукт. Це вартість входу.

Це можливість створити першу робочу версію, запустити її в реальному середовищі і отримати відповідь на головне питання: чи варто будувати далі, і якщо так, то що саме?

І іноді ця вартість входу може бути набагато меншою, ніж підприємець собі уявляє.

Сьогодні ситуація взагалі змінилася.

З'явилася величезна кількість інструментів, які дозволяють самостійно запустити лендинг, прототип, форму, тестову воронку, автоматизацію або навіть доволі складний перший сценарій продукту. Багато з них коштують недорого, а деякі дозволяють почати практично безкоштовно.

Окремо це стосується AI-інструментів, вони остаточно прибрали бар'єр входу в розробку. Але AI відповідає на питання «як швидко зібрати», а не на питання «що саме будувати», а це абсолютно різні задачі. Ми розбирали це детальніше тут: AI спростив розробку. Побудувати успішний продукт, ні.

І я вважаю це доброю новиною.

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

Іноді ми навіть прямо показуємо клієнту, як перевірити ідею самостійно.

Бо наша задача, не зробити якомога більше розробки.

Наша задача, допомогти бізнесу зрозуміти, що справді має сенс будувати.

Це принципова різниця.

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

«Але ж це було ваше ТЗ».

Формально все правильно.

Але я вважаю таку роботу неправильною.

Якщо в процесі розробки ми бачимо, що сама бізнес-гіпотеза викликає питання, наша задача, не мовчки продовжувати виробництво. Наша задача, показати ризик і запропонувати спосіб перевірити його дешевше.

Бо поганий продукт можна побудувати ідеально.

І це не зробить його хорошим бізнесом.

ПЕРШИЙ MVP PERETZ

Перший MVP PERETZ теж був маленьким

Один із найзрозуміліших прикладів для мене, наш власний дизайн-бізнес.

Коли ми запускали Dezzign, ми не починали з великого багатосторінкового сайту з десятками розділів, сотнями проєктів і величезною кількістю контенту.

У нас просто не було сотень проєктів.

Був невеликий набір робіт, які ми могли показати.

Ми зробили landing page, запустили рекламу, підключили аналітику і почали дивитися, що відбувається.

Які люди приходять.

На що реагують.

Які запити працюють.

Що призводить до звернень.

Що не працює взагалі.

І лише після цього почали розвивати систему.

З першого лендингу виріс сайт на CMS. Потім з'явився наступний сайт, уже на кастомному фреймворку.

Тобто ми не намагалися заздалегідь вгадати кінцевий продукт.

Ми почали з того, що могли перевірити.

А далі продукт зростав разом із даними.

І для мене це одна з найважливіших особливостей MVP development: перший етап не зобов'язаний бути фінальною архітектурою продукту. Він повинен дати вам достатньо інформації, щоб прийняти рішення про наступний етап.

MEDPRESSO

Medpresso: коли продукт занадто великий для одного запуску

Інший приклад, Medpresso.

Це вже зовсім інший масштаб. Великий медичний портал із такою кількістю контенту, функцій і бізнес-процесів неможливо розумно розглядати як маленький продукт.

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

Ми запускали його поетапно.

З'являлася нова частина продукту, ми дивилися, як вона працює. Запускали наступний функціонал, знову отримували зворотний зв'язок. Аналізували поведінку користувачів, доопрацьовували, тестували і рухалися далі.

У якийсь момент сам процес запуску став частиною розвитку продукту.

Ми розповідали аудиторії, що з'явиться далі, які функції готуємо, які сторінки запускаємо. Це створювало інтерес ще до появи наступного етапу. Більш повну історію цього запуску можна прочитати у кейсі Medpresso.

І, на мою думку, це виявилося набагато ефективнішим, ніж півтора року розробляти весь продукт, не маючи можливості перевірити його в реальному світі.

Бо у великого продукту є одна неприємна особливість:

його дуже легко будувати довше, ніж бізнес може собі дозволити.

З'ЇСТИ БІЗНЕС

Великий проєкт може з'їсти бізнес

Коли команда одразу починає робити велику платформу, вона приймає величезну кількість рішень на підставі припущень.

Яка функція потрібна?

Яка архітектура буде оптимальною?

Які інтеграції знадобляться?

Яка модель поведінки користувача виявиться правильною?

Які процеси потрібно автоматизувати?

На кожне таке рішення йдуть дизайн, розробка, управління проєктом і гроші.

А потім може з'ясуватися, що бізнесу взагалі не потрібна була половина того, що ми побудували.

І це не перебільшення. За даними дослідження Pendo, заснованого на реальній телеметрії використання сотень цифрових продуктів, близько 80% функцій у середньому продукті майже не використовуються користувачами взагалі.

І тут виникає проблема, яку я вважаю значно серйознішою за просто перевитрату бюджету.

Розробка може з'їсти гроші, які були потрібні бізнесу для запуску.

Компанія витратила $100,000 на створення продукту.

Продукт готовий.

Але тепер немає грошей на маркетинг.

Немає бюджету на залучення перших користувачів.

Немає ресурсів на продажі.

Немає грошей на експерименти.

У підсумку компанія розробила продукт, але не може перевірити, чи потрібен він ринку.

Це одна з найдорожчих помилок у digital product development.

За даними CB Insights, які проаналізували 385 стартапів, що закрилися, ключова причина провалу у 43% випадків, невідповідність продукту ринку. А нестача капіталу, яку зазвичай називають причиною смерті компанії, насправді лише симптом, який проявляється пізніше.

Тому я часто кажу: не запустити MVP може бути набагато дорожче, ніж запустити його.

НЕ ПЛАН РОЗРОБКИ

$100,000, це не план розробки

Уявімо, що до мене приходить підприємець і каже:

«У мене є ідея платформи. Бюджет, $100,000».

Перше, що я запитаю, не скільки функцій він хоче.

Я запитаю:

Для чого потрібна ця платформа?

Яка бізнес-ідея за нею стоїть? Який бізнес-процес вона має вирішувати? Хто її клієнт? Хто інвестор? І чому взагалі визначено бюджет саме в $100,000?

Бо ми можемо витратити ці гроші дуже швидко. І після цього виявити, що головної відповіді у нас все ще немає: чи потрібен ринку цей продукт?

Іноді після дослідження виявляється, що $100,000 справді необхідні.

Іноді виявляється, що спочатку достатньо $20,000.

Іноді, $5,000.

А іноді взагалі не потрібно починати з розробки.

Сьогодні існує величезна кількість інструментів, за допомогою яких підприємець може самостійно перевірити частину своєї ідеї: зібрати landing page, прототип, форму, тестову воронку, автоматизацію або навіть перший робочий сценарій продукту.

Якщо це можна зробити самостійно і отримати реальні дані за кілька днів, я скоріше покажу клієнту, як це зробити, ніж запропоную йому одразу замовити в нас розробку.

Бо ми не повинні заробляти на тому, що клієнт поки не знає, чи працює його ідея.

ЗАНАДТО ВЕЛИКА ІДЕЯ

Гарна ідея теж може бути занадто великою

Є ще одна проблема, яку часто не видно на самому початку.

Підприємець може щиро вважати, що його ідея достатньо проста.

Це нормально.

Він бачить бізнес ззовні: кілька функцій, особистий кабінет, каталог, інтеграція, платежі.

Ми починаємо розбирати його зсередини.

Вивчаємо ринок. Користувацькі сценарії. Бізнес-процеси. Інтеграції. Дані. Обмеження. Майбутню підтримку. І раптом виявляється, що за простим формулюванням «зробити платформу» стоїть дуже складна система.

І тоді гарна ідея може зіткнутися не з технологічним обмеженням, а з хвилерізом бюджету.

І це, мабуть, один із найнеприємніших сценаріїв.

Дослідження показує, що ринок існує. Людям потрібен продукт. Бізнес-модель потенційно працює.

Але повноцінна реалізація коштує настільки дорого, що компанія не може дозволити собі пройти цей шлях.

Тоді є лише два поганих варіанти: відмовитися від ідеї або спробувати побудувати все одразу і поставити під загрозу весь бізнес.

І є третій.

Розбити продукт на етапи.

Прибрати те, що не потрібно для першої перевірки. Відкласти функції, які можна реалізувати пізніше. Використати простіший технологічний інструмент. Перевірити частину гіпотези без розробки взагалі.

Не тому, що ідея погана.

А тому, що бізнес повинен дожити до моменту, коли гарна ідея зможе себе довести.

НЕ ТИМЧАСОВИЙ

MVP не зобов'язаний бути тимчасовим

Тут же виникає вічна суперечка про технологію.

Хтось каже:

«Ми зробили MVP на CMS, а потім обов'язково перенесемо все на Laravel».

Я завжди питаю:

А навіщо?

Якщо відповідь, «бо Laravel швидший», я питаю: у якому сенсі?

Якщо відповідь, «бо Symfony краще підходить для командної розробки», наступне питання: а яка у вас бізнес-модель і чи справді це обмеження існує вже зараз?

Технологія, це інструмент.

Я можу купити найдорожчий і найпотужніший інструмент у майстерні. Але якщо проста викрутка вирішує моє завдання так само добре, користувач не відчує різниці.

CMS може бути чудовим рішенням.

Custom development може бути чудовим рішенням.

Гібрид може бути чудовим рішенням.

Проблема починається тоді, коли технологія обирається не під бізнес-задачу, а заради відчуття, що ми будуємо щось серйозне.

Це те саме питання, що стоїть і на рівні всього продукту, будувати самим чи використовувати готове. Рівняння build vs buy за останні роки сильно змінилося, і більшість компаній його ще не перерахували: Рівняння Build vs. Buy змінилося. Більшість компаній його ще не перерахували.

І це стосується не лише розробки.

НЕ МАЄ ВИГЛЯДАТИ МАЛЕНЬКИМ

Маленький продукт не повинен виглядати маленьким

Є ще одна річ, яку я вважаю принциповою.

MVP часто сприймають як щось, що можна показати користувачу зі словами:

«Ну ви розумієте, це поки MVP».

Ні.

Якщо продукт маленький за функціональністю, це зовсім не означає, що він має бути поганим.

Ми можемо зробити MVP з повноцінним UX, якісним UI і pixel-perfect реалізацією.

Він може виглядати так, ніби це закінчений продукт.

Просто всередині нього буде рівно стільки функцій, скільки потрібно для перевірки першої гіпотези.

Мінімальним має бути обсяг, а не якість.

І в цьому сенсі ідеальний MVP для мене виглядає дуже просто:

Запустили.

Отримали дані.

Зрозуміли, що працює.

Виправили те, що не працює.

Запустили наступний етап.

Це не компроміс.

Це нормальний спосіб будувати продукт.

ПОКАЗУЄ НЕ БУДУВАТИ

Іноді MVP показує, що будувати далі не потрібно

Був у мене й проєкт, де MVP, по суті, підтвердив наші початкові сумніви.

Ідея була цікавою: клієнт хотів продавати кастомізовані відеоролики і побудувати навколо цього повноцінний e-commerce-продукт.

(Не називаю клієнта і продукт, це конфіденційний проєкт. Але сама механіка важливіша за деталі.)

Сам продукт ми зробили. Він був красивим, технічно цікавим і цілком робочим.

Але питання виникло ще до розробки:

а чи існує достатній попит?

І ось тут якраз був момент, коли повноцінна розробка не була найкращим першим кроком. Клієнт хотів одразу повноцінний e-commerce, хоча правильніше було б спочатку перевірити саму модель.

Це гарний приклад того, чому MVP потрібен не лише для економії грошей.

Іноді його головна задача, дозволити собі помилитися дешево.

Бо якщо гіпотеза не підтверджується після невеликого експерименту, це корисний результат.

Ви не втратили рік.

Не витратили весь бюджет.

Не побудували величезну систему, яку тепер потрібно підтримувати.

Ви просто отримали відповідь.

І ця відповідь може бути:

«Ні, цю модель потрібно змінити».

Це теж успіх MVP.

НАЙДОРОЖЧА ПОМИЛКА

Іноді найдорожча помилка, нічого не запустити

Але є й зворотний бік.

Я знаю клієнтів, у яких була справді хороша ідея, але вони просто не наважилися її запустити.

І це теж певний ризик.

Бо хороше вільне місце на ринку рідко залишається вільним назавжди.

Іноді я дивлюся на стару ідею клієнта і думаю: зараз якраз той момент, коли її можна було б перевірити. Сьогодні для цього не обов'язково потрібні величезні бюджети. Можна зібрати мінімальну версію, запустити її, подивитися на реакцію ринку і вже після цього вирішити, чи варто інвестувати далі.

Іноді навіть хочеться самому зателефонувати і сказати:

«Подивіться на цю ідею ще раз. Можливо, зараз саме час її перевірити».

Але тут є важлива межа.

Ми не можемо хотіти бізнес сильніше, ніж його власник.

Ініціатива повинна виходити від людини, яка справді збирається цей бізнес будувати.

Бо найсильніші проєкти завжди мають одну спільну рису: у власника є вогонь в очах.

Є бажання перевірити ідею.

Є готовність отримати не лише позитивну, а й негативну відповідь.

Є готовність після першого результату змінити те, що він вважав правильним.

У такому разі MVP стає не просто інструментом розробки.

Він стає способом дати гарній ідеї шанс почати.

ПОЧУТИ ПЕРШИМ

Іноді продукт потрібно почути до того, як він зазвучить повністю

Є одна музична композиція, до якої я іноді повертаюся, коли думаю про запуск продукту.

На її початку відбувається щось дивне. Ти ще не розумієш, що слухаєш. На сцені з'являється людина, яка виглядає майже як персонаж з іншої історії. Музика починається дуже просто.

А потім поступово вступають інструменти.

Один.

Другий.

Третій.

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

Мені здається, хороший MVP працює приблизно так.

Він не зобов'язаний одразу показувати весь продукт.

Він повинен дати першу ноту.

Якщо вона працює, можна додати наступну.

Потім ще одну.

І поступово з маленького робочого рішення виникає продукт, який уже неможливо порівнювати з тим, з чого він починався.

І ось тут, мені здається, відбувається найцікавіше:

MVP перестає бути MVP. Він стає продуктом.

РОЗМОВА З РЕАЛЬНІСТЮ

MVP, це розмова бізнесу з реальністю

Зрештою я не сприймаю MVP як обов'язкову стадію кожного проєкту.

Це інструмент.

Іноді найправильніший MVP, landing page.

Іноді, прототип.

Іноді, невеликий e-commerce.

Іноді, перша частина великої платформи.

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

А іноді дослідження показує, що MVP робити поки не потрібно.

І це теж нормальний результат.

Перед розробкою я б хотів, щоб у бізнесу були відповіді хоча б на три питання:

Яку гіпотезу ми перевіряємо першою?

Який мінімальний робочий продукт дозволить її перевірити?

Яка метрика покаже нам, що гіпотеза справді працює?

Саме для пошуку відповідей на ці три питання ми в якийсь момент оформили окремий формат, Strategic Session: розмова, в якій ми разом розбираємо бізнес, а не одразу продаємо розробку.

Якщо відповіді є, можна будувати.

І на цьому етапі вже має сенс думати не лише про продукт, а й про команду, яка буде його робити: Як найняти віддалену команду розробників і не обпектися.

Якщо відповідей немає, можливо, спочатку потрібно дослідити.

І якщо для перевірки гіпотези існує спосіб витратити $500 замість $50,000, я вважаю правильним спочатку спробувати $500.

Не тому, що ми хочемо зробити менше.

А тому, що ми хочемо зрозуміти більше до того, як бізнес вкладе більше.

Зараз ми якраз розбираємо новий MVP-проєкт у healthcare. Поки я не можу розповідати про сам продукт, це конфіденційно. Але можу сказати, звідки він до нас прийшов: клієнт знайшов нас після того, як прочитав саме такі матеріали про наш підхід до бізнесу. Не портфоліо, не кейси, не прайс-лист, а те, як ми думаємо. І це само по собі непоганий доказ того, що WHY працює краще, ніж HOW. Саме робота над цим проєктом і стала однією з причин, чому я вирішив сформулювати ці думки.

Кожен складний проєкт знову повертає мене до одного питання:

Що справді потрібно побудувати першим?

Бо іноді найкращий спосіб побудувати велику систему, спочатку не будувати її повністю.

І саме тому для мене MVP, це не мінімальний продукт.

Це вартість входу.

Автор: Євген Боровий, засновник Peretz Agency.