MVP (Minimum Viable Product) to najmniejsza wersja produktu zdolna generować zweryfikowaną wiedzę u realnych użytkowników. Koncepcja spopularyzowana przez Erica Riesa w *The Lean Startup* służy testowaniu hipotezy biznesowej — nie pokazywaniu dema. Zasada jest brutalna: jeśli nikt z niego nie korzysta, nie płaci za niego ani go nie poleca, to nie jest MVP, lecz makieta. O słowie viable zbyt często się zapomina na rzecz minimum: tnie się tyle funkcji, że produkt przestaje się trzymać kupy.
Kluczowe rozróżnienie: POC dowodzi, że technologia działa (wykonalność), prototyp pokazuje ergonomię (UX), a MVP testuje równanie ekonomiczne (sprzedać, utrzymać, zainkasować). Dla SaaS B2B porządne MVP obejmuje minimum: uwierzytelnianie, onboarding, funkcjonalność rdzenia, fakturowanie, wsparcie. Wycięcie fakturowania, „żeby było szybciej”, to klasyczny błąd — nigdy nie dowiesz się, czy ludzie by zapłacili. Sześć do dwunastu tygodni oprogramowania na zamówienie zwykle wystarcza, aby osiągnąć ten zakres.
Dobre MVP nie jest produktem brzydkim, lecz wąskim. Jedna persona, jeden przypadek użycia, jeden kanał pozyskania. Następnie mierzymy retencję na D7/D30, NPS, współczynnik konwersji free → paid i iterujemy. Jeśli po 3 miesiącach na rynku nie znaleźliście sygnału product-market-fit, to nie problem funkcji — to problem pozycjonowania lub grupy docelowej. Aby zaprojektować MVP, które się obroni, wspólnie spisujemy specyfikację przed pierwszą linijką kodu.
4 klasyczne błędy MVP
- Mylenie MVP z demem: brak płatności, brak onboardingu, brak wsparcia → nie testujesz niczego biznesowego.
- Za dużo funkcji: MVP z 15 ficzerami nie jest już minimalne i maskuje sygnał realnego użycia.
- Za mało viable: rozbite UI, blokujące bugi, katastrofalna wydajność → użytkownicy odchodzą, zanim sprawdzą wartość.
- Brak metryk: bez śledzenia retencji i churnu nie sposób się czegokolwiek nauczyć.
