Od pomysłu do MVP SaaS: przewodnik krok po kroku dla założyciela

Niemal każdy artykuł o budowaniu SaaS jest w istocie pisany dla kogoś, kto już zebrał finansowanie. Zakłada zespół, zapas gotówki, mapę drogową i spokój płynący ze świadomości, że stać Pana na popełnianie błędów przez rok. Jeśli jest Pan założycielem z prawdziwym pomysłem, etatem i oszczędnościami, których naprawdę Pan potrzebuje, ta porada jest po cichu niebezpieczna. Każe budować duże i szybko — a właśnie tak umiera większość pierwszych produktów, zanim ktokolwiek zapłaci choć grosz.

Od ponad dekady pomagam ludziom zamieniać pomysły w działające oprogramowanie, a założyciele, których pamiętam najlepiej, to nie ci z najśmielszymi planami. To ci, którzy zaczęli skromnie i pozostali uczciwi. Fizjoterapeutka, która zbudowała narzędzie do umawiania wizyt dla własnej kliniki i ostatecznie sprzedała je czterdziestu innym. Dyspozytor logistyczny, który zautomatyzował własne formalności i zorientował się, że połowa branży ma ten sam problem. Żadne z nich nie zaczęło od wielkiej platformy. Zaczęli od jednego bolesnego zadania i gotowości, by pobierać opłatę za jego rozwiązanie.

To zatem przewodnik, który chciałbym wręczyć tym ludziom pierwszego dnia. Bez teatru zbierania funduszy, bez modnej architektury, bez udawania, że pierwsza wersja musi robić wrażenie. Po prostu spokojna ścieżka od przeczucia w Pana głowie do pierwszego płacącego klienta — i rozsądek, by wiedzieć, co po drodze pominąć.

Czym naprawdę jest MVP (a czym nie jest)

Termin minimum viable product rozciągnięto tak daleko, że ledwie cokolwiek znaczy. Niektórzy założyciele słyszą "minimum" i wypuszczają coś żenującego, czego nikt nie może użyć. Inni słyszą "produkt" i spędzają osiem miesięcy, budując dopracowaną platformę z poziomami cenowymi, panelem administracyjnym i trybem ciemnym, zanim choć jeden człowiek potwierdzi, że by za nią zapłacił. Oba są błędami i są tym samym błędem w innym przebraniu: budowaniem, zanim się czegokolwiek nauczyło.

Użyteczne MVP to najmniejsza rzecz, jaką może Pan postawić przed prawdziwym użytkownikiem, by udowodnić, że pański podstawowy pomysł jest wart płacenia. Nie najmniejsza rzecz, jaką da się zbudować — najmniejsza, która uczy czegoś prawdziwego. Jeśli pański pomysł to "narzędzie, które pozwala dentystom automatycznie wysyłać przypomnienia o wizytach kontrolnych", to MVP jest silnikiem przypomnień i niczym więcej. Bez portalu pacjenta, bez panelu analitycznego, bez kont zespołowych. To odpowiedzi na pytania, na które jeszcze Pan nie zasłużył.

Powód, dla którego ma to tak wielkie znaczenie, to koszt. Każda funkcja zbudowana przed walidacją to zakład postawiony w ciemno. Niech Pan przytnie MVP do rdzenia, a postawi Pan jeden mały, odzyskiwalny zakład. Niech Pan zbuduje całą wizję, a postawi Pan oszczędności — na domysł. Dyscyplina "minimum" nie polega na byciu tanim. Polega na pozostaniu przy życiu wystarczająco długo, by mieć rację.

Zwaliduj pomysł, zanim napiszesz linijkę kodu

Oto niewygodna prawda, której nikt sprzedający Panu programowanie nie chce wypowiedzieć: większość pomysłów na SaaS jest w jakimś ważnym aspekcie błędna, a może się Pan o tym przekonać niemal za darmo. Instynkt każe najpierw budować, a pytać później. Niech Pan to odwróci. Najtańszą wersją pańskiego produktu jest rozmowa, a drugą najtańszą — strona docelowa.

Zanim cokolwiek powstanie, chce Pan dowodu na dwie rzeczy. Po pierwsze, że problem jest realny i na tyle bolesny, że ludzie już teraz poświęcają na niego czas lub pieniądze — niezdarnie, z arkuszami, karteczkami i narzędziem, którego nienawidzą. Po drugie, że szczerze zapłaciliby, by się go pozbyć. "To miły pomysł" to nie dowód. "Skorzystałbym z tego" to nie dowód. "Ile to kosztuje i czy mogę zacząć w poniedziałek?" — to dowód.

Strona docelowa z jasną obietnicą i przyciskiem "dołącz do listy oczekujących" lub "umów demo" to kolejny krok. Jeśli nie potrafi Pan nakłonić garstki obcych osób do zostawienia adresu e-mail dla tego, co Pan opisuje, to nie jest problem marketingowy do naprawy później — to sygnał teraz, póki jego usłyszenie jest jeszcze tanie. Walidacja to nie faza, którą się przelatuje, by dotrzeć do przyjemnej części. Dla założyciela wydającego własne pieniądze to jest przyjemna część: tu unika się kosztownego błędu.

Znajdź tę jedną funkcję, bez której produkt nie może istnieć

Każdy pomysł na SaaS, gdy się go po raz pierwszy opisuje, przychodzi opakowany w tuzin funkcji. Jest to, co robi, a potem konstelacja przyjemnych dodatków, które pański umysł już do niego dokleił: raporty, integracje, aplikacje mobilne, role i uprawnienia, publiczne API. Najcenniejszą umiejętnością w przejściu od pomysłu do MVP jest nauczenie się, by odciąć to wszystko i znaleźć tę jedną funkcję, której zniknięcie uczyniłoby całość bezsensowną.

Ta rdzeniowa funkcja to pańskie MVP. Cała reszta to hipoteza, którą sprawdzi Pan później, gdy ludzie będą już używać rdzenia i mówić Panu, czego naprawdę im brakuje. Założyciele konsekwentnie robią to na odwrót — najpierw budują obsadę drugoplanową, bo wydaje się to bezpieczniejsze, i kończą im się czas i pieniądze, zanim ta jedna rzecz, która się liczy, w ogóle ujrzy światło dzienne.

Test jednego zdania

Niech Pan spróbuje opisać, co robi pański produkt, w jednym zdaniu bez "i". "Pozwala klinikom automatycznie wysyłać przypomnienia o wizytach." "Zamienia zdjęcie paragonu w wpis księgowy." "Śledzi, które oferty wysłał rzemieślnik, i przypomina mu o ponownym kontakcie." Jeśli do opisania wartości potrzebuje Pan "i", to prawdopodobnie ma Pan dwa produkty walczące wewnątrz jednego MVP — i powinien Pan wypuścić najpierw bardziej bolesną połowę.

• Niech Pan spisze wszystko, co wyobraża sobie, że produkt robi — niech wszystko wyjdzie, bez filtrowania.
• Przy każdej pozycji niech Pan zapyta: gdyby tego nie było, czy ktoś nadal by zapłacił? Niech Pan skreśli każde "tak".
• Cokolwiek zostanie po skreślaniu, jest pańskim rdzeniem. To MVP.
• Najsilniejsze skreślone pozycje niech Pan przeniesie na listę "na później" — nie usuwa, tylko nie teraz.
• Niech Pan się oprze ich dodawaniu z powrotem. Lista "na później" to miejsce, gdzie dobre pomysły czekają, by na nie zasłużyć, a nie gdzie MVP umierają.

Zbudować, kupić czy udać: jak stworzyć MVP

Gdy zna już Pan swoją jedną rdzeniową funkcję, staje przed wyborem, którego założyciele rzadko dokonują świadomie: ile z tego naprawdę trzeba zbudować od zera? Uczciwa odpowiedź dla pierwszej wersji brzmi zwykle "mniej, niż się Panu wydaje". Są trzy szerokie ścieżki, a mądrym ruchem często jest ich mieszanka.

Ścieżka no-code / klejenia

Dla niektórych MVP można połączyć istniejące narzędzia — formularz, bazę danych, warstwę automatyzacji, usługę e-mail — i zwalidować pomysł bez pisania choćby linijki własnego kodu. To genialne do sprawdzenia, czy ludzie będą używać i płacić za dany przepływ pracy. Jest szybkie i tanie. Granice ujawniają się później: gdy potrzebuje Pan prawdziwego doświadczenia produktu, własnego modelu danych albo czegoś naprawdę wyjątkowego, klej zaczyna pękać. To dobry problem — oznacza, że czas zbudować jak należy, mając już płacących użytkowników w garści.

Ścieżka budowy na zamówienie

Gdy pańska rdzeniowa funkcja jest wyróżnikiem — faktycznym powodem, dla którego klienci wybierają Pana — ta część zasługuje na prawdziwe oprogramowanie szyte na miarę. Błędem jest budowanie na zamówienie wszystkiego wokół niej. Nie musi Pan pisać własnego uwierzytelniania, obsługi płatności ani infrastruktury e-mail; to rozwiązane problemy, które powinien Pan wynająć. Niech Pan zbuduje część, która jest wyłącznie Pana, resztę wynajmie, a utrzyma uczciwy zarówno koszt, jak i harmonogram.

Większość udanych MVP, jakie widziałem, to celowa mieszanka: wynajęte klocki na nudną-lecz-konieczną instalację i skupiona budowa na zamówienie tej jednej rzeczy, która sprawia, że produkt wart jest płacenia. Wiedza, co jest czym — co budować, a co kupić — to dokładnie ten rodzaj decyzji, dla której warto zasięgnąć drugiej opinii, zanim wyda Pan choć grosz.

Co bezpiecznie pominąć w wersji pierwszej

Wiedza, co pominąć, jest równie ważna jak wiedza, co budować, i to tutaj założyciele najbardziej potrzebują przyzwolenia. Więc proszę: ma Pan przyzwolenie, by pominąć niemal wszystko. Pierwsza wersja istnieje, by się uczyć, nie by robić wrażenie, a niemal żadna z rzeczy, które sprawiają, że produkt wydaje się "skończony", w istocie nie pomaga Panu się uczyć.

• Wiele poziomów cenowych — niech Pan wybierze jedną cenę albo początkowo nawet rozlicza ręcznie fakturą.
• Samoobsługowy proces rejestracji — wdrożenie pierwszych dziesięciu klientów ręcznie nauczy Pana więcej niż jakikolwiek zautomatyzowany lejek.
• Panel administracyjny z wykresami — przy dziesięciu użytkownikach może Pan czytać bazę danych wprost.
• Aplikacje mobilne, jeśli witryna na razie dobrze działa na telefonie.
• Role, uprawnienia i konta zespołowe — dopóki prawdziwy klient nie utknie bez nich.
• Dopracowane ustawienia, motywy i każdy przypadek brzegowy — najpierw niech Pan obsłuży typową ścieżkę, resztę gdy ktoś na nią trafi.

Realistyczna droga od pomysłu do pierwszego klienta

Oto sekwencja, przez którą przeprowadziłbym niemal każdego założyciela. Jest celowo wolna na początku i szybka, gdy już Pan buduje, bo kosztowne błędy mieszkają wszystkie we wczesnych krokach — tych, które założycieli najbardziej kusi, by pominąć.

1. 1
   Zapisz problem w jednym zdaniu

   Nie rozwiązanie — problem. "Kliniki tracą pieniądze przez nieobecności, bo przypomnienia są ręczne." Jeśli nie potrafi Pan czysto sformułować problemu, nie jest Pan gotów, by go rozwiązać.
2. 2
   Przeprowadź dziesięć prawdziwych rozmów

   Niech Pan rozmawia z ludźmi, którzy mają ten problem. Niech wsłuchuje się w ból i w pieniądze już wydawane. Niech dostosuje lub porzuci pomysł na podstawie tego, co usłyszy, nie tego, na co liczył.
3. 3
   Postaw stronę docelową i cenę

   Niech Pan opisze obietnicę wprost, poda cenę i poprosi o e-mail lub umówienie demo. Niech zobaczy, czy obcy się pochylą. To walidacja, której można zaufać.
4. 4
   Zdefiniuj jedną rdzeniową funkcję

   Niech Pan przytnie pomysł do tej jednej rzeczy, której brak czyni go bezsensownym. Niech zapisze opis w jednym zdaniu bez "i". To pański zakres budowy.
5. 5
   Zdecyduj budować czy kupić dla każdego elementu

   Na zamówienie niech Pan buduje tylko wyróżnik. Logowanie, płatności, e-mail i hosting niech wynajmie. Niech ułoży tę mapę poprawnie, zanim ktokolwiek napisze kod — ona ustala cały budżet.
6. 6
   Zbuduj najmniejszą działającą wersję

   Niech Pan celuje w tygodnie, nie miesiące. Jeśli sama rdzeniowa funkcja zajmuje dłużej niż kilka miesięcy, zakres wciąż jest za duży — niech znów przytnie.
7. 7
   Wdróż pierwszych klientów ręcznie

   Niech ich Pan przeprowadzi osobiście. Niech patrzy, gdzie się potykają. Pierwszych dziesięciu użytkowników to pański najlepszy zespół produktowy — i pierwszy przychód.
8. 8
   Ulepszaj na podstawie użycia, nie opinii

   Niech Pan zmienia to, co realne użycie każe zmienić. Dopiero teraz zaczyna Pan zdejmować pozycje z listy "na później" — zasłużone popytem, nie dodane na domysł.

Ile to naprawdę kosztuje — w pieniądzach i w czasie

Założyciele zawsze najpierw pytają o koszt, a uczciwa odpowiedź brzmi "to zależy, a większość tego Pan kontroluje". Zdecydowanie największym czynnikiem kosztu jest zakres — ile postanowił Pan zbudować, zanim postanowił się uczyć. Ciasne MVP z jedną rdzeniową funkcją, z wynajętą instalacją, to skromny, zdefiniowany projekt. Ten sam pomysł zbudowany jako pełna platforma ze wszystkim włączonym to inny wszechświat kosztu i znacznie wyższa szansa porażki przed startem.

Kosztem, o którym większość zapomina, jest czas — Pana. Każdy miesiąc spędzony na budowaniu czegoś, czego kupna nikt nie potwierdził, to miesiąc pańskiego życia i oszczędności wydany na domysł. To prawdziwy argument za zaczynaniem skromnie: nie to, że małe jest tanie, lecz że małe jest szybkie, a szybkie znaczy, że uczy się Pan, czy ma rację, póki zakład jest jeszcze odzyskiwalny. Założyciel, który dociera do płacącego klienta w trzy miesiące z wąskim narzędziem, jest w nieporównanie silniejszej pozycji niż ten, który po roku wciąż dopieszcza wielką platformę.

Jest też cichszy koszt: każda wypuszczona funkcja to coś, co teraz musi Pan utrzymywać, wspierać i tłumaczyć. Mały produkt robiący jedną rzecz niezawodnie jest tańszy w utrzymaniu, łatwiejszy w sprzedaży i prostszy w ulepszaniu niż rozrastający się, który robi dziesięć rzeczy połowicznie. Powściągliwość to nie tylko sposób, by przetrwać budowę — to sposób, by biznes pozostał znośny później.

Częste pytania