MVP, prototyp czy proof of concept: co zbudować najpierw

Każde z nich sprawdza inne ryzyko. Ta tabela porównuje je obok siebie.

Proof of concept, w skrócie PoC, sprawdza, czy coś jest technicznie możliwe. Zwykle to mały fragment kodu, który rozwiązuje jeden trudny problem i pomija całą resztę: bez designu, bez kont, bez dopracowania.

Przykład: startup, który chce odczytywać sumy ze zdjęć odręcznie wypisanych paragonów, powinien najpierw sprawdzić, czy model AI potrafi je odczytać wystarczająco dokładnie. Jeśli nie, żaden design nie uratuje produktu.

Większość produktów nie potrzebuje PoC. Jeśli pomysł składa się ze sprawdzonych elementów, takich jak konta, płatności, formularze i dashboardy, ryzyko techniczne jest niskie, a PoC tylko odsuwa właściwe pytanie.

Kod z PoC zwykle trafia do kosza. Napisano go, żeby szybko odpowiedzieć na jedno pytanie, a nie żeby utrzymał produkt.

Prototyp pokazuje, jak produkt będzie działał, zanim ktokolwiek napisze kod produkcyjny. Może to być zestaw szkiców albo klikalny, realistyczny interfejs, który zachowuje się prawie jak prawdziwy produkt.

Poradnik Nielsen Norman Group o prototypach niskiej i wysokiej wierności dobrze wyjaśnia ten wybór. Proste szkice powstają szybciej i zachęcają do szczerej krytyki; dopracowane prototypy pokazują realistyczne zachowanie, co ma znaczenie, gdy testujesz konkretne ścieżki.

Prototyp to także najlepsze narzędzie, żeby wszyscy się porozumieli. AutoIntel, narzędzie B2B dla niemieckiego rynku samochodów używanych, zaczął się jako interaktywny prototyp na przykładowych ogłoszeniach. Klient przeszedł przez niego ze swoim zespołem i jeszcze przed wyceną przetwarzania danych wszyscy ustalili, które pola i filtry są ważne.

MVP, czyli minimum viable product, to najmniejsza wersja produktu, z której prawdziwi użytkownicy mogą naprawdę korzystać. Ma działające konta, prawdziwe dane i, tam gdzie to ważne, prawdziwe płatności.

Celem jest nauka, a nie start dla samego startu. Według Lean Startup MVP buduje się po to, żeby „jak najszybciej rozpocząć proces uczenia się”.

MVP mierzy to, czego prototyp zmierzyć nie może: czy ludzie wracają i czy płacą. W CarPixly, studiu fotograficznym AI dla ogłoszeń samochodowych, każdy może się zarejestrować i za darmo poznać studio, a płatność pojawia się w momencie wartości, przy renderze. Taki model jasno pokazuje, ilu odwiedzających staje się płacącymi użytkownikami.

Większość MVP powstaje w 6–14 tygodni, zależnie od złożoności. Nasze poradniki o tym, ile trwa stworzenie MVP i ile kosztuje MVP SaaS, podają przedziały dla każdego poziomu.

Zacznij od najbardziej ryzykownej niewiadomej. Zadaj sobie te pytania po kolei:

• Czy jest realna szansa, że nie da się tego zbudować? Na przykład produkt zależy od modelu AI, czujnika sprzętowego albo API, którego jeszcze nie sprawdzono. Zbuduj proof of concept.
• Nie wiadomo, czy ludzie rozumieją rozwiązanie albo czy go chcą? Zbuduj prototyp i przetestuj go z użytkownikami.
• Ludzie rozumieją rozwiązanie i go chcą, a otwarte pytanie brzmi, czy będą z niego korzystać i płacić? Zbuduj MVP.

Większość startupów zatrzymuje się na drugim pytaniu. Technologia zwykle jest sprawdzona; niesprawdzone jest to, czy produkt ma sens dla ludzi, dla których powstaje.

Nie wiesz, które ryzyko w twoim pomyśle jest największe? Wyślij nam krótki brief, a powiemy, od którego kroku byśmy zaczęli i dlaczego.

Prototyp jest przydatny tylko wtedy, gdy wypróbują go prawdziwi ludzie. Dobra wiadomość: testerów potrzeba mniej, niż sądzi większość założycieli.

Badania Jakoba Nielsena pokazały, że testy z 5 użytkownikami ujawniają większość problemów z użytecznością projektu. Nielsen radzi przeprowadzać kilka małych rund zamiast jednego dużego badania.

Prosta runda testów wygląda tak:

• Daj każdej osobie realistyczne zadanie, na przykład „zarezerwuj usługę na przyszły wtorek”.
• Obserwuj, co robi, nie pomagając i niczego nie tłumacząc.
• Zapisuj, gdzie się waha, źle coś odczytuje albo się poddaje.
• Napraw najpoważniejsze problemy, a potem przetestuj kolejną wersję z nowymi osobami.

Pytaj też o obecne zachowanie: jak ludzie rozwiązują ten problem dziś i ile ich to kosztuje. To mówi o popycie więcej niż pytanie, czy „korzystaliby” z twojego produktu.

Prototyp ze szkiców jest narzędziem do nauki i później rysuje się go od nowa. Dopracowany prototyp zbudowany z prawdziwych komponentów to co innego: jego ścieżki, ekrany i design system stają się punktem wyjścia MVP.

Dlatego projektujemy na komponentach wielokrotnego użytku od pierwszego ekranu. Gdy prototyp jest przetestowany i zatwierdzony, programowanie rusza na tych samych komponentach, zamiast interpretować obrazek od nowa.

Z proof of concept jest odwrotnie. Jego kod odpowiada na jedno pytanie i zwykle zostaje porządnie przepisany w MVP, bo nigdy nie miał obsługiwać prawdziwych użytkowników.

Każdy krok powinien kończyć się jasną odpowiedzią, a nie wrażeniem. Zapisz przed startem, co oznacza „sukces”, żeby wyniku nie dało się potem nagiąć do wcześniejszych oczekiwań.

• Proof of concept się udał, gdy trudna część działa na realistycznych danych, z dokładnością albo szybkością, jakiej potrzebuje produkt. „Działa na trzech plikach testowych” nie wystarczy, jeśli użytkownicy będą przysyłać tysiące.
• Prototyp się udał, gdy większość testerów wykonuje główne zadanie bez pomocy i własnymi słowami opisuje problem, który on rozwiązuje.
• MVP się udało, gdy prawdziwi użytkownicy wracają bez przypominania albo płacą, i to na tyle często, że kolejna inwestycja ma sens.

Jeśli krok się nie uda, to też jest przydatne. Nieudany proof of concept oszczędza drogą budowę. Niezrozumiały prototyp mówi, że trzeba zmienić ścieżkę, póki zmiany są jeszcze tanie.

Ustal też limit czasu dla każdego kroku. Prototyp, który po kilku miesiącach wciąż jest szlifowany, przestał być testem i stał się produktem, z którego nikt jeszcze nie może korzystać.

Czasem tak. Jeśli pomysł jest już sprawdzony, na przykład dzięki ręcznej wersji usługi, możesz wiedzieć wystarczająco dużo, żeby od razu budować MVP.

Przykład: osoba, która od miesięcy ręcznie łączy klientów z korepetytorami, korzystając z arkuszy i wiadomości, zna już ścieżki i pytania, jakie zadają ludzie. Prototyp w dużej mierze potwierdziłby to, co już wie.

Pominięcie prototypu ma sens, gdy spełnione są trzy warunki: technologia jest sprawdzona, widać już, jak prawdziwi ludzie przechodzą przez proces, i wiadomo, którą część procesu oprogramowanie ma przejąć najpierw. Jeśli czegoś z tego brakuje, prototyp wciąż jest tańszym sposobem, żeby się tego dowiedzieć.

Te same błędy powtarzają się raz po raz:

• Nazywanie prototypu MVP. Kliknięcia w prototypie pokazują zrozumienie, a nie korzystanie czy płacenie. Nie myl jednego z drugim.
• Szlifowanie proof of concept aż do produktu. Kod napisany, żeby odpowiedzieć na jedno pytanie, staje się kruchą podstawą wszystkiego, co powstaje na nim.
• Pomijanie prototypu. Budowa MVP przed przetestowaniem ścieżek oznacza płacenie programistom za odkrywanie problemów z designem.
• Wkładanie do MVP zbyt wiele. Każda dodatkowa funkcja odsuwa moment, w którym dowiesz się, czy rdzeń działa.
• Testowanie na znajomych. Ludzie, którzy cię lubią, pochwalą pomysł. Testuj z osobami, które mają ten problem i nie mają powodu, żeby być miłe.

Chcesz wybrać pierwszy krok? Opowiedz nam o swoim pomyśle, a pomożemy zdecydować między proof of concept, prototypem i MVP.