MVP: co to jest i kiedy lepiej zacząć od prototypu

MVP (minimum viable product) to najmniejsza działająca wersja produktu, która pozwala sprawdzić na rzeczywistych użytkownikach, czy rozwiązanie jest potrzebne i czy ktoś za nie zapłaci. Nie jest to prototyp ani okrojona pierwsza wersja pełnego produktu. Jeśli pytanie brzmi „czy użytkownicy to zrozumieją”, a nie „czy będą z tego korzystać i płacić”, taniej i szybciej odpowiada na nie prototyp.

Co to jest MVP?

Pojęcie spopularyzował Eric Ries w metodzie Lean Startup, w której MVP służy do tego, żeby jak najszybciej rozpocząć proces uczenia się w pętli: zbudować, zmierzyć, wyciągnąć wnioski. Miarą dobrego MVP nie jest więc liczba funkcji, tylko to, czy pozwala potwierdzić albo obalić konkretne założenie biznesowe.

Z tej definicji wynikają trzy cechy. MVP jest używane przez prawdziwych użytkowników w prawdziwych warunkach. Realizuje jedną pełną ścieżkę od początku do końca, a nie fragmenty wielu. Ma z góry zapisane pytanie i miarę, po której zespół pozna odpowiedź, na przykład odsetek klientów pilotażowych, którzy po miesiącu nadal korzystają z modułu.

Czym MVP różni się od prototypu i proof of concept?

Te trzy formy nie są etapami obowiązkowymi. Odpowiadają na różne ryzyka: techniczne, użytkowe i rynkowe. Wybór zależy od tego, które z nich jest w danym projekcie największe.

Kiedy lepiej zacząć od prototypu niż od MVP?

Prototyp wystarcza, gdy niepewność dotyczy samego rozwiązania: układu procesu, nazewnictwa, kolejności kroków, tego, czy użytkownik w ogóle dostrzeże korzyść. Klikalny prototyp pokazany kilku użytkownikom odpowiada na te pytania, zanim powstanie kod. Pomaga też wtedy, gdy decyzję o budżecie podejmuje zarząd i potrzebuje zobaczyć produkt, którego jeszcze nie ma.

MVP jest potrzebne, gdy odpowiedzi nie da się uzyskać w badaniu: czy użytkownicy wrócą po tygodniu, czy moduł zmieni ich sposób pracy, czy klient dopłaci za wyższy plan. Na takie pytania odpowiada tylko rzeczywiste użycie.

W praktyce prototyp często poprzedza MVP. Jeśli zespół nie jest zgodny co do kierunku, spór zamyka design sprint, czyli pięć dni pracy zakończonych prototypem sprawdzonym z użytkownikami. Jeśli nie jest jasne, jaki problem MVP ma rozwiązać, pierwszym krokiem jest Warsztat produktowy.

Dla kogo MVP jest dobrą strategią?

MVP kojarzy się ze startupem szukającym pierwszych klientów, ale ta sama logika działa w firmie z dojrzałym produktem. Typowe sytuacje:

• Nowy moduł w istniejącym produkcie B2B. Zamiast udostępniać go wszystkim klientom, firma uruchamia wąską wersję dla kilku wybranych i mierzy użycie, zanim zainwestuje w pełny zakres.
• Nowy segment klientów. Produkt działa w jednej branży, a firma sprawdza, czy z niewielkimi zmianami sprzeda się w drugiej.
• Zastąpienie procesu ręcznego. Zespół wewnętrzny wykonuje pracę w arkuszach, a MVP automatyzuje jeden, najczęstszy przypadek.
• Funkcja oparta na AI. Jakość odpowiedzi modelu na prawdziwych danych klientów da się ocenić dopiero w użyciu, więc wąski pilotaż jest bezpieczniejszy niż pełne uruchomienie.

MVP jest złym wyborem, gdy błąd w pierwszej wersji jest niedopuszczalny, na przykład w oprogramowaniu podlegającym certyfikacji medycznej albo w procesach finansowych, oraz gdy zakresu nie da się zawęzić bez utraty sensu produktu. W takich przypadkach ryzyko ogranicza się wcześniej, na prototypie i w badaniach.

Jak wyciąć zakres MVP?

Zakres MVP wynika z pytania, na które ma odpowiedzieć. Pomaga kolejność:

1. Zapisać jedno założenie do sprawdzenia i miarę, po której będzie widać wynik.
2. Wybrać jedną grupę użytkowników i jedną ścieżkę, którą przejdą od początku do końca. Przy złożonym procesie ścieżkę pomaga wyznaczyć warsztat Event Storming.
3. Podzielić pozostałe funkcje metodą MoSCoW na konieczne, ważne, możliwe i odłożone.
4. To, co da się wykonać ręcznie po stronie zespołu, zostawić na razie ręczne: import danych, raporty, konfigurację kont.

Są obszary, których nie tnie się nigdy: bezpieczeństwo danych użytkowników, zgodność z przepisami, podstawowa dostępność i pomiar użycia. MVP bez analityki nie odpowiada na pytanie, dla którego powstało.

Przykład: MVP Dropboxa nie było działającym produktem

Dropbox jest przywoływany jako wzorcowe MVP, często błędnie, jako prosta pierwsza wersja aplikacji. W rzeczywistości pierwszym sprawdzianem był trzyminutowy film pokazujący synchronizację plików. Jak opisuje Eric Ries, po publikacji filmu lista oczekujących na wersję beta wzrosła z 5 000 do 75 000 osób w ciągu jednej nocy. Zespół potwierdził popyt, zanim dokończył technicznie trudny produkt.

Wniosek dla zespołu produktowego: najmniejsza wersja, która odpowiada na pytanie, bywa mniejsza niż aplikacja. Czasem jest nią film, strona z zapisem na pilotaż albo usługa wykonywana ręcznie dla trzech klientów.

Jakie błędy popełnia się przy MVP?

• MVP bez pytania. Zespół buduje małą wersję, ale nie wie, co ma z niej wyniknąć, więc każdy wynik da się uznać za sukces.
• MVP jako pierwsza faza pełnego zakresu. Lista funkcji jest ta sama, tylko podzielona na etapy. Niczego to nie sprawdza i niczego nie skraca.
• Wycięta jakość zamiast zakresu. Wersja ma wszystkie funkcje, ale żadna nie działa dobrze. Użytkownicy odrzucają produkt z powodu wykonania, a zespół wyciąga błędny wniosek o braku potrzeby.
• Brak decyzji po pomiarze. Dane są zbierane, ale nikt nie ustalił, przy jakim wyniku projekt jest rozwijany, zmieniany albo zamykany.
• Wersja tymczasowa, która zostaje na lata. MVP zbudowane bez myśli o dalszym rozwoju staje się fundamentem produktu. Decyzję, czy kod jest do wyrzucenia, czy do rozbudowy, trzeba podjąć przed startem.

Ile kosztuje MVP, a ile prototyp?

Koszt MVP zależy od liczby ścieżek, integracji z istniejącymi systemami, platform i wymagań bezpieczeństwa. Na cenę wpływa też wybór między no-code, low-code a kodem od zera. W Squares wdrożenie pierwszej wersji aplikacji zaczyna się od 20 000 zł netto, wyceniane z góry albo rozliczane za przepracowany czas. Klikalny prototyp kosztuje od 8 000 zł netto, a kwota zależy od liczby ekranów i zakresu walidacji. Różnica w cenie odpowiada różnicy w tym, co powstaje: prototyp nie ma działającego zaplecza, MVP je ma. Składniki ceny produktów mobilnych rozkładamy we wpisie o tym, ile kosztuje aplikacja mobilna.

Prototyp przed decyzją o budowie

Jeśli nie ma pewności, czy rozwiązanie jest zrozumiałe dla użytkowników, prototyp odpowiada na to pytanie przed wydaniem budżetu na wdrożenie. W ramach usługi Prototyp i MVP ustalamy z zespołem, na jakie pytanie prototyp ma odpowiedzieć, projektujemy ekrany, od których zależy odpowiedź, i sprawdzamy je z użytkownikami albo przygotowujemy do prezentacji przed zarządem.

Najczęstsze pytania

Co oznacza skrót MVP?

MVP to minimum viable product, czyli najmniejsza działająca wersja produktu, która pozwala sprawdzić założenie biznesowe na rzeczywistych użytkownikach. Słowo „minimum” dotyczy zakresu, a nie jakości. Wersja ma realizować jedną pełną ścieżkę na tyle dobrze, żeby wynik pomiaru mówił o potrzebie, a nie o wykonaniu.

Czy MVP to to samo co prototyp?

Nie. Prototyp to klikalne ekrany bez działającego zaplecza, które sprawdzają, czy użytkownik rozumie rozwiązanie. MVP to działający produkt o wąskim zakresie, który sprawdza, czy użytkownicy z niego korzystają i czy za niego płacą. Prototyp powstaje szybciej i taniej, dlatego często poprzedza MVP.

Ile trwa zbudowanie MVP?

Zależy od zakresu, integracji i liczby platform, zwykle są to tygodnie albo miesiące, a nie dni. Jeśli plan MVP przekracza kilka miesięcy, zakres jest najpewniej zbyt szeroki i odpowiada na więcej niż jedno pytanie. Wtedy lepiej wrócić do priorytetów i wybrać jedną ścieżkę.

Czy firma z działającym produktem potrzebuje MVP?

Tak, gdy wprowadza nowy moduł, wchodzi w nowy segment albo dodaje funkcję opartą na AI. Wąska wersja udostępniona kilku klientom pilotażowym pokazuje rzeczywiste użycie, zanim firma zainwestuje w pełny zakres i w utrzymanie funkcji, z której być może nikt nie skorzysta.

Źródła

1. The Lean Startup, Principles (Eric Ries)
2. Eric Ries, How DropBox Started As A Minimal Viable Product (TechCrunch, 19.10.2011)