Spotkanie. Pytam o MVP. Słyszę: „Programista już klepie. Za miesiąc będzie gotowe”. Na liście funkcji jest ich kilkadziesiąt: logowanie przez trzy serwisy, czat, panel administratora, wersja angielska. Na wszelki wypadek.
To nie jest MVP. To pełny produkt, tylko jeszcze niegotowy. I miesiąc, w którym nikt z zewnątrz go nie zobaczy.
Nawet miesiąc bywa w startupie całą epoką. Pieniądze się kończą, motywacja spada, konkurencja startuje, a pierwszy klient widzi produkt dopiero wtedy, gdy na zmiany jest już za późno.
Skąd się bierze to nieporozumienie
MVP to skrót od minimum viable product. Spopularyzował go Eric Ries w książce „The Lean Startup”. Większość ludzi słyszy w nim słowo „produkt” i pomija resztę.
Tymczasem sedno MVP to nauka, a nie produkt. Chodzi o to, żeby jak najmniejszym kosztem dowiedzieć się, czy pomysł ma sens. Jeśli przy okazji powstanie coś, co da się sprzedać, to bonus.
Drugi powód jest bardziej ludzki. Pokazanie światu czegoś niedokończonego jest niewygodne. Łatwiej dopieszczać produkt w ukryciu niż wystawić go na ocenę.
Szczególnie gdy jesteś ekspertem. Lekarz czy inżynier całe zawodowe życie uczył się, że błędów się nie pokazuje. W startupie ten odruch kosztuje najwięcej.
MVP to pytanie, a nie odpowiedź
Każde MVP zaczyna się od jednej hipotezy. Jednej, nie pięciu. Najprościej zapisać ją tak:
Wierzę, że [kto] zrobi [co], bo [dlaczego].
Źle: „Ludziom spodoba się nasza aplikacja”. Tego nie da się sprawdzić, bo nie wiadomo, jakim ludziom i co znaczy „spodoba się”.
Dobrze: „Wierzę, że właściciele małych gabinetów zapiszą się na listę oczekujących na narzędzie do przypomnień SMS, bo pacjenci nie przychodzą na wizyty”.
Dopiero z takim zdaniem wiadomo, co budować. Zwykle dużo mniej, niż zakładał plan. I to jest dobra wiadomość.
Pięć MVP, które nie wymagają programisty
Większość pomysłów da się sprawdzić bez jednej linijki kodu.
| Rodzaj MVP | Na czym polega | Co sprawdza |
|---|---|---|
| Landing page z zapisem | Strona opisuje produkt, którego jeszcze nie ma, i zbiera maile chętnych. | Czy problem i obietnica kogoś obchodzą. |
| Przedsprzedaż | Sprzedajesz produkt, zanim powstanie, z jasną datą dostawy. | Czy ktoś zapłaci, a nie tylko kliknie. |
| Ręczna obsługa | Robisz osobiście to, co kiedyś zrobi aplikacja. Klient wie, że to człowiek. | Czy usługa w ogóle rozwiązuje problem. |
| „Czarnoksiężnik z Oz” | Klient widzi gotowy system, a za kulisami wszystko robisz ręcznie. | Czy ludzie skorzystają z gotowego rozwiązania. |
| Film lub makieta | Pokazujesz, jak produkt będzie działał, zanim powstanie pierwszy ekran. | Czy ludzie rozumieją pomysł i chcą więcej. |
Zappos zaczynał od zdjęć butów zrobionych w zwykłych sklepach. Gdy ktoś zamówił parę, założyciel szedł do sklepu, kupował ją i wysyłał. Dropbox, zanim udostępnił produkt szerzej, pokazał krótki film o tym, jak ma działać, i lista chętnych gwałtownie urosła.
Żaden z nich nie czekał na gotowy produkt, żeby sprawdzić, czy ktoś go chce.
Kryterium sukcesu ustal przed testem, nie po
Najczęstszy błąd przy testowaniu MVP to brak liczby. Test się kończy, wyniki są „całkiem niezłe” i nikt nie wie, co to znaczy.
Dlatego zanim cokolwiek uruchomisz, zapisz kryterium sukcesu. Na przykład: „Jeśli w ciągu dwóch tygodni zapisze się 50 osób, idziemy dalej. Jeśli mniej niż 20, wracamy do rozmów z klientami”.
Liczba ustalona po teście zawsze się zgadza. Dlatego nic nie znaczy.
Historia z inkubatora: start, który wisiał na cudzym terminie
Klasyczny scenariusz: zespół pokazuje harmonogram. Start za osiem miesięcy, bo najpierw musi być integracja z zewnętrznym systemem, a do niej potrzebne są zgody i formalności. Cały produkt wisi na cudzym terminie.
Pytam: „A gdyby na start klient wpisywał te dane ręcznie?”. Chwila ciszy. „No… to by działało”.
Często na start wystarczy rozwiązanie półręczne, na przykład dane wpisywane przez użytkownika z prostą weryfikacją. Pełną automatyzację można dodać w kolejnej wersji, kiedy są już pierwsi klienci.
Morał: MVP nie musi robić wszystkiego. Musi zrobić jedną rzecz, za którą ktoś zapłaci, i wystartować, zanim skończy się kasa.
Po czym poznasz, że Twoje MVP jest za duże
- Budowa trwa dłużej niż kilka tygodni.
- Ma więcej niż jedną kluczową funkcję.
- Nie umiesz powiedzieć, jaką hipotezę sprawdza.
- Odkładasz pokazanie go klientom, bo „jeszcze nie jest gotowe”.
- Do jego zbudowania potrzebujesz kredytu albo całej dotacji.
Reid Hoffman, współzałożyciel LinkedIna, powtarza: jeśli nie wstydzisz się pierwszej wersji produktu, to start był spóźniony. Lekki wstyd to dobry znak.
Checklista: zanim zbudujesz MVP
- Mam jedną hipotezę zapisaną w jednym zdaniu.
- Wiem, jaka liczba oznacza sukces, a jaka porażkę.
- Test to najtańszy sposób sprawdzenia tej hipotezy, jaki znam.
- Test potrwa najwyżej kilka tygodni.
- MVP zobaczą prawdziwi klienci, nie tylko znajomi.
- Wiem, co zrobię po wyniku: idę dalej, zmieniam kierunek albo wracam do rozmów.
Jeśli odhaczasz wszystko, uruchamiaj test. Jeśli nie, przycinaj MVP, aż się da.
Na koniec
MVP nie ma być ładne. Ma odpowiedzieć na jedno pytanie, zanim wydasz pieniądze na odpowiedzi na wszystkie inne.