W skrócie: Dobre MVP to najmniejsza wersja produktu, która rozwiązuje jeden kluczowy problem użytkowników na tyle dobrze, że można zmierzyć, czy pomysł działa. Planowanie zaczyna się od hipotezy do weryfikacji (nie listy funkcji), a zakres wyznacza pytanie „bez czego produkt nie ma sensu w pierwszym tygodniu używania?".
Spis treści
Krótka odpowiedź
MVP (minimum viable product) to najmniejsza wersja produktu, która realnie rozwiązuje problem i pozwala zmierzyć, czy pomysł działa. Kluczowe są oba człony: produkt-wydmuszka niczego nie weryfikuje, a produkt-kombajn weryfikuje za późno i za drogo.
Najdroższy błąd: budowanie listy życzeń
Typowa historia: founder ma wizję, spisuje funkcje, wycenia u software house'u, tnie trochę „na później", po czym buduje 12 miesięcy. Premiera. Cisza. Użytkownicy korzystają z 20% funkcji, a kluczowa hipoteza („czy ktoś za to zapłaci?") wciąż czeka na odpowiedź, tyle że budżetu już nie ma.
Problem nie leży w wykonaniu, tylko w punkcie startu: MVP planuje się od hipotezy, nie od listy funkcji.
Krok 1: nazwij hipotezę
Dokończ zdanie: „Wierzymy, że [kto] ma problem [jaki] i zapłaci za [rozwiązanie]". Przykład: „Wierzymy, że małe biura rachunkowe tracą godziny na ręczne przypomnienia klientom o dokumentach i zapłacą za automatyzację tego procesu".
Z tak nazwanej hipotezy wynika wszystko: kto jest pierwszym użytkownikiem, co produkt musi robić oraz, co równie ważne, czego nie musi.
Krok 2: wyznacz rdzeń
Dla każdej funkcji z listy życzeń zadaj pytanie: „czy bez tego produkt nie ma sensu w pierwszym tygodniu używania?". Odpowiedzi dzielą funkcje na trzy koszyki:
- Rdzeń: bez tego nie ma produktu (w przykładzie: lista klientów, harmonogram przypomnień, wysyłka).
- Wzmocnienia: ułatwiają życie, ale poczekają (panel statystyk, integracja z systemem księgowym, aplikacja mobilna).
- Fantazje: pomysły „a fajnie by było" (AI przewidujące opóźnienia, marketplace szablonów).
Brutalna praktyka: rdzeń to zwykle 20–30% pierwotnej listy. I to wystarcza, bo pierwsi użytkownicy wybaczą brak statystyk, ale nie wybaczą, jeśli rdzeń działa słabo.
Krok 3: najpierw prototyp, potem kod
Zanim powstanie linijka kodu, klikalny prototyp kluczowych przepływów testowany z 5 użytkownikami wyłapie większość błędnych założeń. Koszt: dni pracy. Te same odkrycia w działającym produkcie kosztują tygodnie. W naszym anonimizowanym case study SaaS testy prototypu wywróciły dwa przepływy, które „na papierze" wyglądały świetnie.
Krok 4: zaplanuj pomiar przed startem
MVP bez planu pomiaru to strzał w ciemność. Przed premierą ustal: co jest sygnałem sukcesu (aktywacja? powrót w drugim tygodniu? płatność?), jakie liczby uznacie za „działa", i wbuduj analitykę produktową od pierwszego dnia.
Typowe pułapki
- MVP-potwór: „minimalna wersja" budowana 18 miesięcy. Antidotum: twardy horyzont 3–6 miesięcy.
- MVP-atrapa: wycięto tyle, że produkt nie rozwiązuje problemu i „weryfikuje" jedynie to, że nikt nie chce atrapy.
- Cięcie jakości zamiast zakresu: wolny, zabugowany produkt testuje cierpliwość, nie hipotezę. Tnij funkcje, nie jakość rdzenia.
- Brak właściciela decyzji: zakres MVP rozjeżdża się, gdy każdy interesariusz dorzuca „jeszcze jedno".
Od czego zacząć
Od warsztatu zakresu: dzień–dwa pracy z decydentami, z którego wychodzą hipoteza, rdzeń funkcji, szkic przepływów i realny budżet. Tak właśnie zaczynamy projekty produktowe w Sweet Lava. Zobacz, jak wygląda proces, albo po prostu opowiedz nam o swoim pomyśle.