Od pomysłu do pierwszych płacących użytkowników: jak uruchomiliśmy SaaS B2B

Przyszła z arkuszem kalkulacyjnym, przeczuciem i terminem, który jej branżowa konferencja wyznaczyła jej bez pytania. Za cztery miesiące miała stanąć na małej scenie przed mniej więcej dwustoma osobami prowadzącymi dokładnie taki rodzaj firmy, jaki jej pomysł miał obsługiwać. Chciała pokazać coś prawdziwego — nie slajdy, nie makietę, lecz produkt, do którego ktoś obcy mógłby się zalogować i za niego zapłacić. Od tej rozmowy zaczyna się to studium przypadku, a najcenniejsze w nim jest to, jak zwyczajny był punkt wyjścia.

Celowo zmieniliśmy tu szczegóły umożliwiające identyfikację. Założycielka jest prawdziwa, produkt działa, a liczby są bliskie prawdzie, ale zaokrąglone i złagodzone, tak by nikt nie mógł odgadnąć, o kogo chodzi. Liczy się nie konkretna nisza — lecz kształt tej drogi, bo ten kształt powtarza się niemal za każdym razem, gdy nietechniczny założyciel próbuje przekuć dobry pomysł w działające oprogramowanie. Jeśli jesteś gdzieś blisko początku tej drogi, oto z grubsza, jak mogą wyglądać najbliższe miesiące, gdy idzie dobrze.

Krótka wersja: branża, którą znała na wylot, bolesny ręczny proces, który wszyscy w niej tolerowali, arkusz kalkulacyjny, którym po cichu robiła to lepiej niż jej koledzy po fachu, i zero technicznego zaplecza. Po jedenastu tygodniach skupionej pracy mieliśmy pierwszych płacących użytkowników. Oto jak — i, mówiąc szczerzej, oto gdzie się potknęliśmy.

Sytuacja: arkusz wykonujący prawdziwą pracę

Założycielka prowadziła małą firmę doradczą w regulowanej, intensywnie dokumentowej dziedzinie. Jej klientami były inne małe firmy, a każda z nich zmagała się z tym samym powracającym obowiązkiem — zebraniem stosu formularzy, sprawdzeniem ich kompletności, ściganiem brakujących elementów i przygotowaniem czytelnego podsumowania przed terminem. Większość konkurentów robiła to e-mailami, telefonami i folderem szablonów Worda. Ona robiła to arkuszem, który budowała i dopracowywała przez cztery lata, a klienci po cichu ją za to uwielbiali.

Ten arkusz był całym przełomem. Nie był biznesplanem ani analizą rynku — był dowodem. Ludzie już polegali na jej narzędziu, prosili, by uruchomiła je dla firm, których nawet nie doradzała, oferowali zapłatę za sam dostęp. Gdy klienci próbują coś kupić, zanim to zbudujesz, możesz przestać zgadywać, czy istnieje popyt. Pytanie nigdy nie brzmiało czy warto to robić. Pytanie brzmiało czy może to stać się oprogramowaniem, którego ktoś inny użyje bez niej u boku.

Jej ograniczenia były równie realne. Stały budżet z własnych oszczędności, nie z funduszu. Termin konferencji. I twarda zasada, którą uzgodniliśmy wcześnie: to nie mogło stać się projektem wymagającym jej uwagi każdego dnia, bo wciąż miała firmę doradczą do prowadzenia. Cokolwiek zbudujemy, musiało być możliwe do dokończenia, przystępne cenowo i nudne w obsłudze. Te trzy słowa ukształtowały każdą kolejną decyzję.

Pierwszym zadaniem było zdecydowanie, czego NIE budować

Gdy założyciele opisują produkt swoich marzeń, lista funkcji jest zawsze ogromna, bo wyobrażają go sobie od lat. Jej lista wypełniła dwie strony: pulpity, uprawnienia zespołu, dziennik zmian, automatyczne przypomnienia, portal dla klienta, fakturowanie, analityka, integracje z trzema narzędziami używanymi przez jej klientów i — oczywiście — "gdzieś tam trochę AI." Każda pozycja była rozsądna. Zbudowanie ich wszystkich przed startem byłoby katastrofą.

Przeprowadziliśmy więc ćwiczenie, które robimy z każdym: dla każdej funkcji zadaliśmy jedno bezceremonialne pytanie. Gdyby tego zabrakło w dniu startu, czy klient odmówiłby zapłaty? Nie "czy byłoby milej z tym" — czy sprzedaż naprawdę by przepadła. Większość funkcji oblewa ten test i o to właśnie chodzi. Te, które przetrwają, to twój prawdziwy produkt. Reszta to roadmapa, rzecz urocza, ale nie ta, którą budujesz najpierw.

To, co przetrwało, było aż wstydliwie małe. Użytkownik mógł założyć konto, utworzyć sprawę, zaprosić swojego klienta do przesłania wymaganych dokumentów i otrzymać to samo czytelne, sprawdzone podsumowanie, które tworzył jej arkusz — tyle że automatycznie i bez jej udziału. To wszystko. Żadnych pulpitów. Żadnych ról zespołu. Żadnej AI, jeszcze nie. Cztery funkcje, jedno jasne zadanie, zrobione porządnie.

Co naprawdę zbudowaliśmy w jedenaście tygodni

Pracujemy w krótkich, widocznych cyklach, zamiast znikać na trzy miesiące i wracać z niespodzianką. Mniej więcej co tydzień założycielka dostawała link do czegoś, co mogła kliknąć, nawet gdy było brzydkie i tylko częściowo podłączone. Ten rytm znaczy więcej, niż brzmi: utrzymywał jej decyzje małymi i częstymi, zamiast pozwolić im spiętrzyć się w jeden przerażający przegląd na końcu.

Tygodnie 1–3: kręgosłup

Najpierw zbudowaliśmy nieefektowny rdzeń — konta, bezpieczny sposób przechowywania dokumentów i model danych pod przepływem spraw. Nic z tego nie jest widoczne dla klienta, a wszystko to jest częścią, którą drogo naprawiać później, jeśli się ją zaniedba. Ponieważ produkt obsługiwał wrażliwe dokumenty innych firm, traktowaliśmy kontrolę dostępu i separację danych jako wymóg startu, nie późniejszą aktualizację. To jedno z niewielu miejsc, gdzie odmówiliśmy cięć.

Tygodnie 4–7: właściwa praca

Potem część, która sprawiła, że warto było płacić: przekucie logiki jej arkusza w silnik, który sprawdza kompletność dokumentów i tworzy podsumowanie. To było serce produktu i daliśmy mu najwięcej czasu. Siedzieliśmy z nią i rozkładaliśmy na części, dlaczego każda reguła w jej arkuszu istniała — a kilka okazało się nawykami, a nie wymaganiami, co pozwoliło uprościć. Pod koniec siódmego tygodnia można było przejść prawdziwą sprawę od początku do końca.

Tygodnie 8–11: uczynienie tego bezpiecznym do pobierania opłat

Ostatni odcinek był różnicą między demo a produktem. Płatność, by ludzie mogli faktycznie wykupić subskrypcję. Czysta rejestracja, która nie potrzebowała instrukcji. Tuzin drobnych stanów błędu, które decydują, czy ktoś obcy zaufa twojemu oprogramowaniu, czy odbije. I testy — nudne, powtarzalne testy — z założycielką i dwoma przychylnymi klientami, którzy zgodzili się celowo to zepsuć, zanim zrobią to obcy. Ta ostatnia grupa wielokrotnie zarobiła swoją zniżkę za wczesny dostęp.

Pytanie 'wsadź tam trochę AI', odpowiedź szczera

Na jej liście życzeń była AI, jak na większości list teraz. Stawialiśmy opór i warto wyjaśnić dlaczego, bo to ta sama rada, którą dajemy niemal każdemu. Zadanie, które musiała wykonać wersja pierwsza — sprawdzanie znanego zestawu dokumentów względem znanego zestawu reguł — to zadanie, które reguły robią lepiej niż AI. Jest przewidywalne, jest możliwe do skontrolowania, a gdy regulowany klient pyta "dlaczego system to oznaczył," chcesz jasnej odpowiedzi, a nie wzruszenia ramionami.

To nie znaczy, że AI nie miała miejsca. W przepływie krył się naprawdę chaotyczny, językowy problem: klienci często przesyłali dokumenty niemal poprawne, ale źle oznaczone, albo wklejali informacje jako wolny tekst zamiast wypełnić formularz. Czytanie tego bałaganu i sortowanie go to dokładnie to, w czym nowoczesna AI jest dobra. Odnotowaliśmy to więc starannie — a potem zostawiliśmy na wersję drugą. Dodanie tego przed startem opóźniłoby termin, by dopracować funkcję, za którą jeszcze nikt nie poprosił zapłacić.

Zdobycie pierwszych płacących użytkowników

Oto część, o którą założyciele martwią się najbardziej, a przygotowują się najmniej. Produkt, którego nikt nie może znaleźć, to nie firma, to hobby. Ale ta założycielka miała przewagę wartą więcej niż jakikolwiek budżet marketingowy: miała już publiczność, która jej ufała, a kilkoro z nich prosiło o możliwość zapłaty, zanim oprogramowanie powstało. Plan startu opierał się całkowicie na tym, i twój też powinien, jeśli to masz.

Zamiast hucznego publicznego startu zrobiliśmy odwrotnie — cichy, przemyślany. Dwa tygodnie przed konferencją napisała do garstki klientów, którzy już o to prosili, zaoferowała im cenę członka założyciela i wdrożyła ich ręcznie, obserwując przez rozmowę wideo, jak używają produktu. Każda dezorientacja stawała się poprawką. Gdy stanęła na scenie, nie pitchowała pomysłu; opisywała oprogramowanie, za które jej koledzy po fachu już płacili, i mogła powiedzieć to szczerze.

1. 1
   Zacznij od ludzi, którzy już pytają

   Jej pierwszy kontakt trafił tylko do klientów, którzy wcześniej oferowali zapłatę. Ciepły popyt konwertuje, zanim zimny w ogóle odpowie.
2. 2
   Wdróż pierwszych ręcznie

   Żadnych samoobsługowych wyczynów na starcie. Przeprowadziła każdego wczesnego użytkownika na żywo, zmieniając każdy punkt dezorientacji w konkretną poprawkę.
3. 3
   Wyceniaj dla założycieli, nie na zawsze

   Wcześni użytkownicy dostali wyraźnie ograniczoną czasowo cenę założycielską. Wynagradzała ich ryzyko i dawała późniejszym klientom powód, dlaczego ceny rosną.
4. 4
   Użyj terminu jako startu

   Konferencja nie była marketingowym chwytem doczepionym później — była czynnikiem wymuszającym, który utrzymywał uczciwy zakres przez całą drogę.

Rezultat — i co naprawdę oznacza

Pod koniec miesiąca startu produkt miał pierwszych płacących subskrybentów — niewielką liczbę, taką, którą wciąż policzysz na palcach dwóch rąk, każdy z nich prawdziwa firma płacąca prawdziwą miesięczną opłatę. To brzmi skromnie i takie jest. To zarazem najtrudniejszy kamień milowy w całym życiu produktu programistycznego. Przejście od zera płacących klientów do kilku jest znacznie trudniejsze niż od kilku do wielu, bo to moment, w którym pomysł przestaje być twój i staje się rynku.

Liczby poniżej są poglądowe i zaokrąglone, ale wierne kształtowi tego, co się wydarzyło. Chcemy, byś wyniósł z nich nie cyfry — lecz proporcje. Ciasno wyznaczona zakresem pierwsza wersja, mały skupiony budżet, krótki harmonogram i start wymierzony w ciepły popyt zamiast w cały internet.

Gdzie popełniliśmy błąd

Studium przypadku, które wymienia tylko zwycięstwa, jest reklamą, więc oto szczera część. Popełniliśmy dwa błędy warte nazwania, bo skuszą cię te same.

Po pierwsze, nie doceniliśmy wdrożenia. Starannie wyznaczyliśmy zakres produktu, ale potraktowaliśmy pierwsze pięć minut doświadczenia nowego użytkownika jako sprawę drugorzędną, coś do dopieszczenia na końcu. Okazało się to momentem decydującym i poświęciliśmy nieplanowany tydzień na przebudowę rejestracji oraz pustego pierwszego ekranu, tak by ktoś obcy mógł zrozumieć, co robić, bez tłumaczenia. Następnym razem pierwsze uruchomienie jest funkcją od pierwszego dnia, nie od dziesiątego tygodnia.

Po drugie, pozwoliliśmy jednej "małej" regule w silniku sprawdzającym rozrosnąć się. Założycielka wspomniała o przypadku brzegowym niemal mimochodem, zgodziliśmy się, że jest łatwy, a po cichu pochłonął trzy dni, bo dane z prawdziwego świata były bardziej chaotyczne, niż jej czysty arkusz kiedykolwiek ujawniał. Lekcją nie było "unikaj przypadków brzegowych" — było to, że jej arkusz po cichu wykonywał ręczne porządki, o których zapomniała, że je robi. Oprogramowanie musi uczynić tę niewidzialną pracę widzialną, a to zawsze kosztuje więcej, niż ktokolwiek się spodziewa.

Jeśli stoi Pan/Pani tam, gdzie ona

To, co sprawiło, że zadziałało, nie było sprytną architekturą ani modnym narzędziem. Była to dyscyplina co do zakresu i szczerość co do popytu. Miała dowód, że ludzie tego chcą, zanim napisaliśmy linijkę kodu, a my byliśmy bezwzględni w budowaniu najmniejszej wersji, za którą ktoś jednak zapłaci. Żadne z tego nie wymaga technicznego zaplecza. Oba można zacząć już w tym tygodniu, samodzielnie.

Jeśli ma Pan/Pani arkusz, który ludzie wciąż proszą uruchomić, albo ręczny proces, za który klienci dziękują, może jest Pan/Pani bliżej produktu, niż się wydaje. Niebezpiecznym ruchem jest wyobrazić sobie skończoną, pełną funkcji wersję i zamarznąć na tym, jak duża się wydaje. Proszę tego nie robić. Proszę znaleźć jedno zadanie, które musi bezwzględnie wykonać, zbudować tylko to i przedstawić ludziom, którzy już o to proszą. Roadmapa może poczekać. Pierwszy płacący użytkownik nie może.

Częste pytania