Co to jest MVP (Minimum Viable Product) i jak stworzyć pierwszą wersję produktu?

MVP, czyli Minimum Viable Product, to najmniejsza wersja produktu, która jest już wystarczająco użyteczna, aby mogła dostarczyć odbiorcy realną wartość i jednocześnie pozwolić twórcy sprawdzić najważniejsze założenia biznesowe lub produktowe.

Najważniejsze słowo w tym pojęciu nie brzmi jednak „minimum”.

Brzmi viable.

Produkt ma być minimalny pod względem zakresu, ale nadal musi działać na tyle dobrze, aby użytkownik rzeczywiście mógł z niego skorzystać.

MVP nie powinno więc oznaczać:

• niedokończonego projektu,
• wersji pełnej błędów,
• produktu pozbawionego podstawowych zabezpieczeń,
• prowizorki, którą wstyd pokazać użytkownikowi,
• najtańszej możliwej wersji wszystkiego.

Chodzi o coś zupełnie innego.

Jeżeli produkt docelowo może posiadać trzydzieści funkcji, być może pierwsza wersja potrzebuje tylko pięciu.

Te pięć funkcji musi jednak pozwalać rozwiązać konkretny problem.

Co oznacza skrót MVP?

MVP rozwija się jako Minimum Viable Product.

W praktyce można to rozumieć jako:

minimalny produkt posiadający wystarczającą wartość, aby mógł być realnie używany.

Każde z tych trzech słów jest istotne.

Minimum

Zakres powinien być możliwie mały.

Usuwamy funkcje, które nie są konieczne do sprawdzenia najważniejszego założenia.

Viable

Produkt musi być użyteczny.

Nie może być jedynie demonstracją pomysłu.

Product

Użytkownik powinien otrzymać coś, z czego rzeczywiście może skorzystać w określonym celu.

Właśnie dlatego nie każda makieta, prototyp albo prezentacja jest MVP.

MVP nie oznacza budowania słabego produktu

To jedno z najczęstszych nieporozumień.

Kiedy projekt ma powstać jako MVP, pojawia się czasami podejście:

Na razie zróbmy byle jak, później się poprawi.

To nie jest idea MVP.

Można ograniczyć liczbę funkcji.

Nie powinno się natomiast świadomie rezygnować z jakości tych elementów, które są niezbędne.

Jeżeli MVP jest sklepem internetowym, płatność powinna działać.

Jeżeli jest systemem przyjmowania zamówień, dane nie powinny ginąć.

Jeżeli jest konfiguratorem produktu, wynik konfiguracji musi być poprawny.

Jeżeli zbiera dane klientów, musi robić to bezpiecznie.

Minimalizujemy zakres, a nie odpowiedzialność.

Po co właściwie tworzy się MVP?

Najważniejszym celem MVP jest ograniczenie ryzyka związanego z budowaniem czegoś, czego użytkownicy mogą nie potrzebować.

W projektach cyfrowych bardzo łatwo stworzyć długą listę funkcji.

Każdy kolejny pomysł brzmi rozsądnie:

• konto użytkownika,
• panel administracyjny,
• system powiadomień,
• rozbudowane filtrowanie,
• integracja z CRM,
• aplikacja mobilna,
• rekomendacje AI,
• wiele wersji językowych,
• rozbudowane raportowanie.

Problem pojawia się wtedy, gdy przed uruchomieniem produktu nikt jeszcze nie wie, czy użytkownik w ogóle potrzebuje jego podstawowej funkcji.

MVP pozwala najpierw sprawdzić fundament.

Najpierw hipoteza, później funkcje

Dobrze zaprojektowane MVP zaczyna się od określenia tego, czego właściwie chcemy się dowiedzieć.

Przykładowa hipoteza może brzmieć:

Klienci hurtowi chcą samodzielnie konfigurować produkt online zamiast przesyłać jego parametry e-mailem.

Jeżeli chcemy to sprawdzić, pierwsza wersja systemu może potrzebować:

• wyboru podstawowych parametrów,
• walidacji konfiguracji,
• wyliczenia ceny,
• wysłania projektu lub zamówienia.

Nie musi jeszcze posiadać:

• programu lojalnościowego,
• rozbudowanego dashboardu,
• pięciu poziomów uprawnień,
• systemu rekomendacji,
• pełnej aplikacji mobilnej.

Te funkcje mogą być wartościowe.

Nie są jednak potrzebne do sprawdzenia podstawowego założenia.

MVP a prototyp – to nie jest to samo

Prototyp służy przede wszystkim do pokazania lub sprawdzenia sposobu działania rozwiązania.

Może być:

• makietą interfejsu,
• klikalnym projektem,
• uproszczonym modelem,
• wersją demonstracyjną.

Nie musi obsługiwać prawdziwych danych ani realizować całego procesu.

MVP powinno już być produktem, który można wykorzystać.

Przykładowo klikalna makieta konfiguratora może być prototypem.

Konfigurator pozwalający rzeczywistemu klientowi skonfigurować produkt i przesłać poprawne zamówienie może być MVP.

MVP a Proof of Concept

Proof of Concept, często określany skrótem PoC, odpowiada zwykle na pytanie:

Czy da się to technicznie zrobić?

MVP odpowiada raczej:

Czy stworzone rozwiązanie rzeczywiście ma wartość dla użytkownika?

Przykładowo można przygotować PoC sprawdzający, czy możliwe jest automatyczne wygenerowanie określonego pliku technicznego na podstawie parametrów produktu.

Dopiero później może powstać MVP, w którym klient wybiera parametry, widzi wynik i składa prawdziwe zamówienie.

MVP a wersja beta

Wersja beta oznacza zazwyczaj produkt znajdujący się już na bardziej zaawansowanym etapie rozwoju, ale nadal intensywnie testowany.

MVP opisuje natomiast przede wszystkim sposób wyboru zakresu pierwszej użytecznej wersji.

Produkt może więc przejść przez MVP, kolejne iteracje, wersję beta i dopiero później osiągnąć pełną dojrzałość.

Jak znaleźć prawdziwe minimum?

To zwykle najtrudniejsza część projektu.

Prawie każda funkcja wydaje się ważna, kiedy patrzymy na nią osobno.

Dlatego zamiast pytać:

Czy ta funkcja byłaby przydatna?

lepiej zapytać:

Czy bez tej funkcji użytkownik nadal może osiągnąć główny cel produktu?

Jeżeli tak, prawdopodobnie można ją odłożyć.

Przydatne jest również drugie pytanie:

Czy brak tej funkcji uniemożliwi nam sprawdzenie głównej hipotezy?

Jeżeli nie, funkcja prawdopodobnie nie należy do pierwszej wersji.

MVP powinno rozwiązywać jeden konkretny problem

Im bardziej rozmyty jest cel produktu, tym trudniej stworzyć jego minimalną wersję.

Projekt opisany jako:

nowoczesna platforma cyfrowa poprawiająca doświadczenie klientów

nie mówi właściwie nic.

Znacznie łatwiej pracować z problemem:

klient musi obecnie wysyłać zapytanie o każdy niestandardowy wariant produktu i czekać na ręczne wyliczenie ceny.

Wtedy można zaprojektować pierwszą wersję rozwiązania:

konfiguracja → walidacja → cena → zamówienie.

To jest konkretny proces, który można uruchomić, obserwować i rozwijać.

Przykład MVP sklepu internetowego

Załóżmy, że firma chce uruchomić nowy model sprzedaży online.

Docelowa wizja obejmuje:

• kilka tysięcy produktów,
• sprzedaż B2C i B2B,
• integrację ERP,
• indywidualne cenniki,
• program lojalnościowy,
• marketplace,
• automatyczny marketing,
• rozbudowane rekomendacje.

Budowa wszystkiego przed pierwszą sprzedażą oznacza duży koszt oraz wiele założeń, których jeszcze nie zweryfikowano.

MVP może rozpocząć się od jednej grupy produktów, jednego modelu klienta i podstawowego procesu zakupowego.

Przy tworzeniu i rozwijaniu sklepów WooCommerce takie podejście może pozwolić najpierw zweryfikować sam proces sprzedaży, a dopiero później dokładać kolejne warstwy systemu.

Przykład MVP konfiguratora produktu

Firma chce stworzyć rozbudowany konfigurator techniczny.

Docelowo system ma:

• pokazywać produkt w 3D,
• obsługiwać setki kombinacji,
• generować dokumentację,
• tworzyć pliki produkcyjne,
• łączyć się z ERP,
• zapisywać projekty klientów,
• obsługiwać rabaty B2B.

Pierwszym pytaniem powinno być jednak:

Jaki podstawowy problem ma rozwiązać konfigurator?

Jeżeli największym problemem jest ręczne zbieranie parametrów zamówienia, MVP może najpierw:

1. pozwalać wybrać parametry,
2. blokować niedozwolone kombinacje,
3. pokazywać wynik,
4. przekazywać poprawne dane do firmy.

Dopiero gdy ten proces zostanie potwierdzony, można rozwijać wizualizację 3D, integracje i automatyzację produkcji.

Przykład MVP narzędzia wewnętrznego

MVP nie musi być produktem sprzedawanym klientom.

Może dotyczyć również systemu wykorzystywanego wewnątrz firmy.

Przykładowo przedsiębiorstwo obsługuje zapytania w arkuszach i chce stworzyć rozbudowany panel operacyjny.

Docelowo system może mieć dziesiątki modułów.

Jeżeli największym problemem jest jednak brak kontroli nad statusem zgłoszeń, pierwsza wersja może obejmować tylko:

• utworzenie zgłoszenia,
• przypisanie osoby,
• status,
• termin,
• historię zmian.

Jeżeli to już poprawia pracę, mamy podstawę do dalszego rozwoju.

MVP automatyzacji procesu

Podobne podejście można zastosować przy automatyzacji.

Firma nie musi od razu automatyzować całego procesu od pozyskania klienta do księgowości.

Można zacząć od jednego wąskiego miejsca, które generuje najwięcej ręcznej pracy.

Przykładowo:

nowe zamówienie → sprawdzenie danych → przekazanie do systemu → zmiana statusu.

Jeżeli taka automatyzacja działa poprawnie i przynosi efekt, można dołączać kolejne etapy.

Przy większych projektach automatyzacji procesów etapowe wdrażanie ma jeszcze jedną zaletę: łatwiej obserwować błędy i dokładnie określić, która część procesu wymaga poprawy.

Dlaczego MVP jest szczególnie przydatne przy projektach niestandardowych?

Im bardziej nietypowy projekt, tym mniej możemy opierać się na gotowych wzorcach.

Jeżeli budujemy standardowy sklep, wiele zachowań użytkowników jest dobrze poznanych.

Jeżeli tworzymy natomiast:

• niestandardowy konfigurator,
• system zamówień technicznych,
• własny portal B2B,
• narzędzie dla produkcji,
• dedykowaną aplikację,

część założeń będzie trzeba zweryfikować dopiero w praktyce.

MVP ogranicza ryzyko stworzenia bardzo rozbudowanego rozwiązania na podstawie błędnych założeń.

Jak zaplanować MVP krok po kroku?

1. Zdefiniuj problem

Najpierw trzeba wiedzieć, co właściwie chcemy poprawić.

Problem powinien być możliwie konkretny.

Nie:

chcemy cyfryzować sprzedaż.

Lepiej:

przygotowanie jednej oferty zajmuje handlowcowi średnio 25 minut, ponieważ ręcznie dobiera warianty i przelicza cenę.

2. Określ użytkownika

Kto będzie korzystał z pierwszej wersji?

Nie każdy typ klienta musi zostać obsłużony od pierwszego dnia.

MVP można przygotować dla jednego, dobrze określonego scenariusza.

3. Zdefiniuj główną wartość

Co użytkownik powinien osiągnąć?

Może to być:

• szybsze złożenie zamówienia,
• samodzielna konfiguracja produktu,
• natychmiastowa wycena,
• łatwiejsze znalezienie informacji,
• uniknięcie błędu,
• oszczędność czasu.

4. Rozpisz pełny proces

Warto najpierw rozpisać wszystko, co docelowo mogłoby znaleźć się w rozwiązaniu.

Dopiero później można ciąć zakres.

Jeżeli od razu próbujemy myśleć „minimalnie”, łatwo pominąć zależność, która okaże się konieczna.

5. Podziel funkcje na konieczne i późniejsze

Można zastosować bardzo prosty podział:

• musi być,
• powinno być,
• może być później.

W MVP pozostaje pierwsza grupa oraz tylko te elementy drugiej, bez których produkt nie będzie rzeczywiście użyteczny.

6. Określ, co chcesz zmierzyć

Jeszcze przed uruchomieniem warto wiedzieć, po czym poznamy, że rozwiązanie działa.

Inaczej po kilku miesiącach możemy posiadać produkt, ale nadal nie wiedzieć, czego się nauczyliśmy.

7. Uruchom produkt dla prawdziwych użytkowników

MVP nabiera wartości dopiero wtedy, gdy trafia do realnego procesu.

Opinie wewnętrznego zespołu są ważne.

Zachowanie prawdziwego użytkownika jest jednak znacznie bardziej wartościowe.

8. Obserwuj, poprawiaj i rozwijaj

Po uruchomieniu nie przechodzimy automatycznie do realizacji pierwotnej listy funkcji.

Najpierw sprawdzamy, czego nauczyła nas pierwsza wersja.

Jak mierzyć sukces MVP?

Nie istnieje jeden wskaźnik odpowiedni dla każdego projektu.

Metryka powinna wynikać z celu.

Dla sklepu może to być:

• liczba zamówień,
• konwersja,
• wartość koszyka,
• liczba porzuceń checkoutu.

Dla konfiguratora:

• liczba rozpoczętych konfiguracji,
• liczba ukończonych projektów,
• liczba błędów,
• czas potrzebny do stworzenia zamówienia.

Dla narzędzia wewnętrznego:

• czas realizacji procesu,
• liczba ręcznych czynności,
• liczba pomyłek,
• liczba operacji wykonanych przez użytkowników.

Właśnie dlatego analityka internetowa i właściwie zaplanowany pomiar powinny pojawić się odpowiednio wcześnie, a nie dopiero po zakończeniu projektu.

MVP powinno zbierać dane od początku

To częsty błąd.

Powstaje produkt.

Zaczynają z niego korzystać użytkownicy.

Po kilku miesiącach pojawia się pytanie:

Co właściwie robią w systemie?

I okazuje się, że nikt tego nie mierzył.

Nie trzeba od razu tworzyć rozbudowanego systemu BI.

Warto jednak wiedzieć:

• czy użytkownicy rozpoczynają główny proces,
• czy go kończą,
• w którym miejscu rezygnują,
• jakie błędy występują,
• które funkcje są używane.

Dane ilościowe nie wystarczą

Jeżeli tylko 30 procent użytkowników kończy proces konfiguracji, analityka pokazuje problem.

Nie zawsze pokaże jego przyczynę.

Dlatego przy MVP warto łączyć dane z:

• rozmowami z użytkownikami,
• zgłoszeniami do obsługi,
• obserwacją sposobu korzystania z produktu,
• analizą błędów.

Statystyka mówi, co się wydarzyło.

Rozmowa może powiedzieć, dlaczego.

Nie pytaj użytkowników wyłącznie, czy produkt im się podoba

To pytanie dostarcza zwykle niewiele informacji.

Znacznie bardziej wartościowe są pytania:

• co próbowałeś zrobić,
• w którym miejscu nie wiedziałeś, co dalej,
• czego brakowało,
• co zrobiłeś zamiast tego,
• która część zajęła najwięcej czasu.

Jeszcze ważniejsze jest rzeczywiste zachowanie.

Użytkownik może powiedzieć, że jakaś funkcja jest świetna, a później nigdy jej nie użyć.

Największy wróg MVP: „skoro już robimy…”

To zdanie potrafi bardzo szybko podwoić zakres projektu.

Skoro już mamy logowanie, dodajmy profile.

Skoro mamy profile, dodajmy wiadomości.

Skoro mamy wiadomości, przydałyby się powiadomienia.

Skoro mamy powiadomienia, zróbmy aplikację mobilną.

Każdy krok osobno wydaje się niewielki.

Po miesiącu budujemy zupełnie inny produkt.

Dlatego scope MVP trzeba chronić.

Feature creep – kiedy projekt zaczyna puchnąć

Feature creep oznacza stopniowe dokładanie kolejnych funkcji poza pierwotnym zakresem.

W projektach MVP jest szczególnie niebezpieczny, ponieważ niszczy główną zaletę tego podejścia.

Zamiast szybko zweryfikować założenie, spędzamy kolejne miesiące na tworzeniu rzeczy, których jeszcze nie wiemy, czy potrzebujemy.

Nowy pomysł nie musi zostać odrzucony.

Można go zapisać na kolejny etap.

Czy MVP powinno być ładne?

Powinno być wystarczająco czytelne i wygodne, aby wygląd nie uniemożliwiał oceny podstawowej wartości produktu.

Nie zawsze potrzebuje natomiast kompletnego, dopracowanego systemu wizualnego.

Jeżeli testujemy nowy proces składania zamówienia, interfejs musi być zrozumiały.

Nie potrzebuje jednak od razu kilkudziesięciu animacji i pięciu wariantów motywu kolorystycznego.

Wizualna prowizorka również może zafałszować test.

Jeżeli użytkownik nie potrafi korzystać z produktu dlatego, że interfejs jest chaotyczny, nie dowiemy się, czy sam pomysł był dobry.

MVP a UX

Minimalny zakres nie oznacza minimalnej troski o doświadczenie użytkownika.

Wręcz przeciwnie.

Jeżeli produkt posiada tylko kilka funkcji, ich obsługa powinna być szczególnie jasna.

W pierwszej wersji warto pilnować:

• logicznej ścieżki,
• czytelnych komunikatów,
• obsługi błędów,
• informacji zwrotnej po wykonaniu działania,
• responsywności.

Czy MVP może być wykonane ręcznie?

Czasami część procesu można świadomie pozostawić ręczną.

To ważna technika ograniczania kosztu pierwszej wersji.

Przykładowo klient może wypełnić konfigurator online, ale pierwsze kilkadziesiąt zamówień nadal może być ręcznie przekazywanych do systemu produkcyjnego.

Dzięki temu można zweryfikować zainteresowanie konfiguracją, zanim powstanie kosztowna integracja ERP.

Warunek jest jeden:

użytkownik musi nadal otrzymywać wartość, którą obiecuje produkt.

Automatyzować teraz czy później?

Nie każda czynność musi być automatyczna od pierwszego dnia.

Jeżeli ręczna obsługa dziesięciu operacji tygodniowo zajmuje kilka minut, budowa skomplikowanej integracji może nie być jeszcze potrzebna.

Jeżeli jednak ręczny etap:

• powoduje błędy,
• wpływa na doświadczenie klienta,
• uniemożliwia skalowanie testu,

powinien znaleźć się wcześniej w zakresie.

MVP nie zwalnia z bezpieczeństwa

Niektórych elementów nie można odłożyć „na później”.

Dotyczy to szczególnie bezpieczeństwa.

Jeżeli produkt:

• przetwarza dane osobowe,
• obsługuje płatności,
• ma konta użytkowników,
• komunikuje się z zewnętrznymi systemami,

podstawowe zabezpieczenia należą do pierwszej wersji.

Brak bezpieczeństwa nie jest ograniczeniem zakresu.

Jest wadą produktu.

MVP a dług techniczny

Szybkie tworzenie pierwszej wersji może prowadzić do kompromisów technicznych.

Nie zawsze jest to problem.

Problem pojawia się wtedy, kiedy rozwiązanie tymczasowe zostaje fundamentem systemu na następnych pięć lat.

Dlatego trzeba wiedzieć, które elementy:

• są świadomym uproszczeniem,
• mogą pozostać na stałe,
• trzeba przebudować po potwierdzeniu produktu.

Dług techniczny może być świadomą decyzją.

Nie powinien być przypadkiem.

Czy architektura MVP powinna uwzględniać przyszłość?

Tak, ale z umiarem.

Nie warto budować infrastruktury dla miliona użytkowników, jeżeli pierwszym celem jest zdobycie stu.

Nie warto również stworzyć rozwiązania, które przy stu pierwszych użytkownikach trzeba będzie wyrzucić w całości.

Dobry projekt pozostawia rozsądne miejsce na rozwój bez budowania od razu całej przyszłej architektury.

MVP nie zawsze musi być publiczne

Pierwsza wersja może trafić tylko do ograniczonej grupy.

Mogą to być:

• wybrani klienci,
• partnerzy B2B,
• pracownicy,
• użytkownicy zapisani do programu testowego.

Taki kontrolowany start pozwala szybciej reagować na problemy i łatwiej zbierać jakościowy feedback.

Soft launch zamiast wielkiej premiery

Nie każdy produkt potrzebuje spektakularnego startu.

Jeżeli uruchamiamy MVP, często rozsądniejszy jest spokojny soft launch.

Najpierw pozwalamy korzystać z produktu niewielkiej grupie.

Obserwujemy:

• błędy,
• niejasności,
• wydajność,
• zachowanie użytkowników.

Dopiero później zwiększamy ruch.

Kiedy MVP jest za małe?

Minimalizm można również przesadzić.

MVP jest za małe, jeżeli użytkownik nie może wykonać kompletnego podstawowego zadania.

Przykładowo konfigurator, który pozwala wybrać wariant produktu, ale nie pozwala niczego zrobić z wynikiem, może być demonstracją.

Nie musi jeszcze być MVP.

Sklep bez możliwości dokonania zakupu również trudno nazwać użytecznym produktem sprzedażowym.

Kiedy MVP jest za duże?

Jeżeli przed pierwszym uruchomieniem powstaje:

• kilkanaście modułów,
• rozbudowana administracja,
• wiele integracji,
• obsługa wszystkich możliwych wyjątków,
• funkcje planowane „na przyszłość”,

warto zadać pytanie, czy nadal testujemy założenie, czy już budujemy pełny produkt.

Najczęstsze błędy podczas tworzenia MVP

Brak konkretnej hipotezy

Powstaje „pierwsza wersja”, ale nikt nie wie, czego ma dowieść.

Za dużo funkcji

Projekt trwa prawie tyle samo, co pełne wdrożenie.

Za mało wartości

Produkt jest tak ograniczony, że użytkownik nie ma powodu z niego korzystać.

Brak pomiaru

Produkt działa, ale nie wiadomo, jak użytkownicy z niego korzystają.

Ignorowanie jakości

Błędy i słaby UX powodują, że testujemy jakość wykonania zamiast wartości pomysłu.

Brak kontaktu z użytkownikami

Zespół rozwija produkt według własnych opinii, mimo że miał uczyć się na podstawie realnego użycia.

Brak decyzji po teście

MVP zostało uruchomione, ale niezależnie od wyników realizowany jest pierwotny roadmap.

Co robić po uruchomieniu MVP?

Po pierwszym okresie używania produktu powinny pojawić się trzy możliwe kierunki.

Rozwijamy

Założenie się potwierdza.

Użytkownicy korzystają z rozwiązania i pojawiają się konkretne potrzeby kolejnych funkcji.

Zmieniamy

Problem istnieje, ale użytkownicy rozwiązują go inaczej, niż zakładaliśmy.

Produkt wymaga zmiany kierunku.

Rezygnujemy

Może się okazać, że problem nie jest wystarczająco ważny albo klienci nie chcą korzystać z proponowanego rozwiązania.

To nie musi oznaczać porażki.

Jeżeli odkryliśmy to po kilku tygodniach i ograniczonym budżecie zamiast po roku rozwoju, MVP spełniło swoje zadanie.

Pivot – kiedy trzeba zmienić kierunek?

Pivot oznacza istotną zmianę założenia produktu na podstawie zdobytych informacji.

Przykładowo zakładaliśmy, że klient chce samodzielnie skonfigurować produkt i od razu go kupić.

Po uruchomieniu okazuje się, że konfiguracja jest używana, ale prawie każdy klient przed zakupem chce jeszcze konsultacji.

Nie musi to oznaczać, że konfigurator jest niepotrzebny.

Być może jego właściwą rolą jest przygotowanie kompletnego projektu do rozmowy z handlowcem, a nie całkowite zastąpienie kontaktu.

To cenna informacja, której nie da się zawsze przewidzieć przy biurku.

Roadmap powinien powstać po MVP, a nie przed nim na kilka lat

Można oczywiście mieć wizję przyszłego produktu.

Nie traktowałbym jednak wieloletniej listy funkcji jako zobowiązania.

Każda kolejna iteracja powinna wynikać z połączenia:

• celów biznesowych,
• danych,
• feedbacku użytkowników,
• ograniczeń technicznych.

Roadmap jest kierunkiem.

Nie powinien być ślepą listą rzeczy do zbudowania.

MVP w istniejącej firmie

Podejście MVP kojarzy się głównie ze startupami, ale bardzo dobrze działa również w działających przedsiębiorstwach.

Firma może wykorzystać je przy:

• nowym kanale sprzedaży,
• portalu B2B,
• konfiguratorze,
• automatyzacji,
• nowym systemie wewnętrznym,
• przebudowie procesu obsługi.

W takim przypadku zaleta jest szczególnie duża, ponieważ nowy system często musi współpracować z istniejącą infrastrukturą.

Etapowe wdrożenie pozwala ograniczyć ryzyko zakłócenia działającego biznesu.

MVP w małej firmie

Mała firma nie musi używać słowa MVP, żeby stosować jego logikę.

Może po prostu przyjąć zasadę:

najpierw rozwiązujemy najważniejszy problem, uruchamiamy rozwiązanie i dopiero na podstawie doświadczeń dokładamy kolejne elementy.

To często znacznie rozsądniejsze niż próba stworzenia od razu kompletnego systemu obejmującego wszystkie możliwe potrzeby.

MVP nie oznacza, że wszystko trzeba zrobić dwa razy

Czasami pojawia się obawa:

Po co budować MVP, skoro później i tak zbudujemy wersję właściwą?

Dobrze zaprojektowane MVP nie musi być produktem jednorazowym.

Może stać się fundamentem rozwijanym w kolejnych etapach.

Nie zawsze jednak wszystkie jego elementy powinny zostać zachowane.

Jeżeli jakieś uproszczenie pozwoliło bardzo tanio zweryfikować ryzykowne założenie, jego późniejsza przebudowa może być ekonomicznie całkowicie uzasadniona.

Czy MVP zawsze obniża koszt projektu?

Nie musi obniżyć całkowitego kosztu produktu, jeżeli ten ostatecznie zostanie bardzo mocno rozwinięty.

Zmniejsza natomiast koszt ryzyka.

Zamiast inwestować cały budżet przed uzyskaniem informacji, wydajemy go etapami.

Po każdym etapie wiemy więcej.

To właśnie jest największa ekonomiczna wartość MVP.

Jak rozpoznać dobre MVP?

Dobre MVP powinno spełniać kilka warunków:

• rozwiązuje konkretny problem,
• ma jasno określonego użytkownika,
• pozwala ukończyć podstawowy proces,
• można je rzeczywiście uruchomić,
• pozwala zebrać dane,
• jego zakres jest świadomie ograniczony,
• wiadomo, czego chcemy się dzięki niemu nauczyć.

Jak ja podchodzę do projektów MVP?

Przy niestandardowym projekcie nie zaczynam od pytania:

Ile funkcji możemy zmieścić w pierwszej wersji?

Najpierw próbuję określić:

• jaki problem rozwiązujemy,
• kto go ma,
• który element procesu daje największą wartość,
• jak można potwierdzić, że rozwiązanie rzeczywiście działa.

Dopiero później powstaje zakres techniczny.

Jeżeli pierwsza wersja może działać bez rozbudowanej integracji, nie dokładam jej tylko dlatego, że docelowo może być potrzebna.

Jeżeli natomiast bez integracji produkt nie dostarcza prawdziwej wartości, powinna znaleźć się już w MVP.

Nie istnieje jedna uniwersalna lista funkcji.

Minimum zależy od konkretnego procesu.

Najważniejsza zasada MVP

MVP nie polega na stworzeniu jak najmniejszego produktu.

Polega na stworzeniu najmniejszego produktu, który pozwala nauczyć się czegoś ważnego na podstawie prawdziwego użycia.

Jeżeli wycinamy funkcję, ale produkt nadal rozwiązuje problem, prawdopodobnie wykonujemy właściwy ruch.

Jeżeli wycinamy tyle, że użytkownik nie może już osiągnąć rezultatu, przekroczyliśmy granicę.

I jeżeli przez pół roku budujemy funkcje, których nikt jeszcze nie użył, być może granicy w ogóle nie zaczęliśmy szukać.

Najlepsza pierwsza wersja produktu nie odpowiada na wszystkie pytania. Powinna natomiast pozwolić zadać kolejne pytania na podstawie rzeczywistych danych, a nie przypuszczeń.