Jak zweryfikować pomysł na SaaS, zanim napiszą Państwo choć jedną linijkę kodu
Najpierw budować, a pytania zadawać później to najdroższy sposób na sprawdzenie pomysłu na SaaS. Oto wersja spokojna i praktyczna: jak dowiedzieć się, czy ktokolwiek naprawdę chce Państwa oprogramowania, zanim wydadzą Państwo na nie choćby grosz.

Najdroższy sposób, by dowiedzieć się, czy ludzie chcą Państwa oprogramowania, to zbudować je. A jednak właśnie to robi większość początkujących założycieli — poświęcają sześć miesięcy i oszczędności na przekształcenie pomysłu w kod, uruchamiają go w ciszy i dopiero wtedy zaczynają pytać, czy ktoś tego potrzebował. Walidacja to tania wersja tej lekcji. Dzięki niej kupują Państwo odpowiedź za kilka tygodni rozmów zamiast za rok swojego życia.
Widziałem wielu mądrych ludzi wpadających w tę samą pułapkę. Mają naprawdę dobre spostrzeżenie — realną uciążliwość w branży, którą znają — i zakładają, że przepaść między spostrzeżeniem a produktem to wyłącznie kwestia inżynierii. Tak nie jest. Ta przepaść jest pełna pytań bez odpowiedzi: czy ktoś inny odczuwa ten ból na tyle mocno, by zapłacić? Czy zrezygnują z tego, co robią teraz? Czy mogą Państwo do nich dotrzeć bez przepalania pieniędzy? Na te pytania nie odpowiada się pisaniem kodu. Odpowiada się na nie, rozmawiając z ludźmi i obserwując, co naprawdę robią.
To więc przewodnik, który daję założycielom, zanim zatrudnią kogokolwiek do budowy czegokolwiek. Nie chodzi o teatr lean-startupu ani o wypełnianie kanwy. Chodzi o garść uczciwych, tanich eksperymentów, które powiedzą Państwu, czy pomysł ma puls — oraz o dyscyplinę, by uwierzyć w wyniki, nawet gdy bolą.
Dlaczego budowanie najpierw wydaje się produktywne — a zwykle nie jest
Budowanie kusi, bo przypomina widoczny postęp. Na koniec sesji kodowania jest ekran, który działa, przycisk, który coś robi, rzecz, którą można pokazać partnerce. Rozmowa z obcymi o problemie nie wytwarza żadnego artefaktu. Jest niewygodna, powolna, a na koniec ma się jedynie notatki. Założyciele sięgają więc po klawiaturę, bo klawiatura nagradza ich szybciej.
Kłopot w tym, że działający ekran nie mówi prawie nic o tym, czy pomysł jest trafny. Można zbudować piękny, bezbłędny produkt na problem, którego nikt nie ma, a będzie tak samo martwy jak produkt brzydki. Kod jest odpowiedzią na pytanie „jak to dostarczymy?” — nie „czy ktoś tego chce?” Spędzanie miesięcy nad pierwszym pytaniem, zanim odpowie się na drugie, to sposób, w jaki dobrzy inżynierowie budują eleganckie rozwiązania wyimaginowanych problemów.
“Kod jest odpowiedzią na „jak”, a nie na „czy”. Większość nieudanych produktów SaaS odpowiedziała na „jak” znakomicie i nigdy nie sprawdziła „czy”.”
Walidacja odwraca kolejność. Poświęcają Państwo kilka tygodni i bardzo mało pieniędzy, by udowodnić — lub obalić — najbardziej ryzykowne założenie pomysłu zanim zobowiążą się Państwo do budowy. Jeśli pomysł jest mocny, wchodzą Państwo w rozwój z dowodami, jaśniejszą specyfikacją i pierwszymi użytkownikami już czekającymi. Jeśli jest słaby, dowiadują się Państwo tego za cenę kilku kaw i strony docelowej, a nie za cenę produktu.

Znajdź jedno założenie, które może pogrzebać całość
Każdy pomysł na SaaS opiera się na stosie przekonań, a nie są one jednakowo niebezpieczne. Niektóre są bezpieczne — „ludzie używają e-maila”, „małe firmy nie lubią papierkowej roboty”. Inne to zakłady, od których zależy całe przedsięwzięcie, a jeśli są błędne, nic innego nie ma znaczenia. Zadaniem walidacji nie jest testowanie wszystkiego. Jest nim znalezienie najbardziej ryzykownego założenia i zaatakowanie go w pierwszej kolejności.
By je znaleźć, proszę zapisać swój pomysł jednym zdaniem: „[ci ludzie] mają [ten problem] na tyle dotkliwie, by zapłacić za [to rozwiązanie] zamiast [tego, co robią teraz]”. Następnie proszę zapytać siebie bezlitośnie: które słowo w tym zdaniu, gdyby okazało się fałszywe, zatopiłoby pomysł? Zwykle nie jest to rozwiązanie. To kwestia, czy problem jest na tyle bolesny, by zań płacić, albo czy w ogóle da się dotrzeć do tych ludzi w przystępny sposób.
Ta sekwencja ma znaczenie, bo koszt testowania rośnie na każdym kroku. Wywiad o problemie jest darmowy. Test gotowości do zapłaty kosztuje stronę docelową. Test rozwiązania może wymagać klikalnego prototypu. Budowanie jest najdroższym testem ze wszystkich. Chcą Państwo polec tanio i wcześnie, a nie drogo i późno — dlatego najtańsze, najbardziej zabójcze testy stawia się na początku.
Rozmawiaj z ludźmi — ale rób to dobrze
Najbardziej użyteczną rzeczą, jaką mogą Państwo zrobić, jest rozmowa z ludźmi, o których sądzą Państwo, że mają ten problem. Nie ze znajomymi, nie z innymi założycielami — z prawdziwymi osobami, które by tego używały. I tu kryje się pułapka, która rujnuje większość prób: ludzie są uprzejmi. Proszę zapytać „czy użyłby Pan narzędzia, które robi X?”, a niemal każdy powie tak, bo powiedzenie tak jest darmowe i miłe. To „tak” jest bezwartościowe. Pogrzebało więcej startupów niż jakakolwiek awaria techniczna.
Rozwiązaniem jest przestać pytać o przyszłość, a zacząć pytać o przeszłość. Przyszłość to miejsce, gdzie ludzie kłamią z grzeczności; przeszłość to miejsce, gdzie żyje prawda. Zamiast „czy by Pan tego użył?”, proszę zapytać „proszę opowiedzieć o ostatnim razie, gdy mierzył się Pan z tym problemem”. Co zrobili? Ile to trwało? Ile ich kosztowało? Czy szukali rozwiązania? Czy za nie zapłacili? Realne zachowanie za każdym razem bije hipotetyczny entuzjazm.
Pytania, na które padają szczere odpowiedzi
- „Proszę przeprowadzić mnie przez ostatni raz, gdy to się wydarzyło”. — odsłania prawdziwy przebieg pracy, nie wyidealizowany.
- „Co Pan z tym zrobił?” — ujawnia, czy naprawdę im zależy, czy tylko machają ręką.
- „Ile czasu lub pieniędzy to Pana kosztowało?” — zamienia mglisty ból w liczbę.
- „Czy próbował Pan już to naprawić? Co się stało?” — mówi, czy jest budżet i intencja.
- „Co jest teraz bardziej irytujące niż to?” — sprawdza, czy Państwa problem w ogóle mieści się w ich pierwszej piątce.
Ile rozmów? Mniej, niż mogłoby się wydawać. Zanim przeprowadzą Państwo dziesięć szczerych, dobrze poprowadzonych wywiadów z właściwymi osobami, wzorzec zwykle jest oczywisty. Albo trzy czy cztery z nich rozpalają się i zaczynają barwnie opisywać ból — albo wszystkie są uprzejmie letnie, i żadne sprytne budowanie tego nie naprawi. Dwanaście do piętnastu w zupełności wystarczy, by podjąć decyzję, której można zaufać.
Tanie sposoby na sprawdzenie realnego popytu
Rozmowy mówią, czy problem jest realny. Następne pytanie brzmi, czy ludzie zadziałają — a jedynym sposobem, by to wiedzieć, jest poproszenie o małe zobowiązanie, zanim produkt powstanie. Tu walidacja robi się trochę niewygodna, a zarazem szczera. Słowa są tanie; kliknięcie, adres e-mail czy zaliczka — nie.
Nie trzeba niczego budować, by przeprowadzić te testy. Potrzebna jest jedna strona, która jasno opisuje obietnicę i prosi o jedno konkretne działanie. Działanie to dane. Jeśli ludzie przeczytają Państwa propozycję i nic nie zrobią, to jest Państwa odpowiedź — i jest to odpowiedź znacznie tańsza niż uruchomienie produktu w ciszy za pół roku.
- 1Wystawcie jednostronicową ofertęProszę opisać problem i swoje rozwiązanie prostym językiem, z jednym jasnym wezwaniem do działania. Wystarczy zwykła strona docelowa — na razie bez produktu za nią.
- 2Poproście o realny sygnałNie o „polubienie”. Proszę poprosić ludzi, by zapisali się na listę oczekujących, podając e-mail, złożyli przedsprzedaż lub umówili rozmowę. Im więcej kosztuje ich powiedzenie tak, tym więcej to tak znaczy.
- 3Skierujcie trochę uczciwego ruchuProszę udostępnić to tam, gdzie Państwa realna grupa odbiorców już jest — odpowiednia społeczność, mała reklama, kilka wiadomości bezpośrednich. Chcą Państwo obcych, nie swojej wspierającej sieci.
- 4Czytajcie konwersję, nie komplementySpośród wszystkich, którzy naprawdę zrozumieli ofertę, ilu podjęło działanie? Garść realnych zapisów od właściwych osób bije tysiąc mglistych życzeń powodzenia.
Najmocniejszym testem popytu ze wszystkich jest poproszenie o pieniądze z góry. Przedsprzedaż, płatny pilotaż, zaliczka na wczesny dostęp — wszystko, przy czym otwiera się portfel. Wydaje się to agresywne, a jest najuczciwszą rzeczą, jaką mogą Państwo zrobić dla samych siebie. Ktoś, kto przekazuje choćby drobną kwotę na produkt, który jeszcze nie istnieje, mówi Państwu coś, czego żadna ankieta nigdy nie powie. Jeśli znajdą Państwo trzy czy cztery takie osoby, nie mają już Państwo pomysłu. Mają biznes czekający na zbudowanie.

Sprzedaj to, zanim zbudujesz
Między „ludzie są zainteresowani” a „ludzie będą płacić co miesiąc” jest krok wart osobnej uwagi: dostarczanie wartości ręcznie, zanim ją Państwo zautomatyzują. Jeśli Państwa pomysł to narzędzie, które, powiedzmy, zamienia chaotyczne e-maile od dostawców w schludny cotygodniowy raport, proszę najpierw zrobić to ręcznie dla trzech czy czterech klientów. Stają się Państwo oprogramowaniem. Jest to powolne i nieskalowalne — i o to chodzi — pozwala bowiem nauczyć się, co produkt naprawdę musi robić, zanim zostanie to zapisane w kodzie.
To robi dwie rzeczy naraz. Dowodzi, że ludzie zapłacą za rezultat, a nie tylko za samą ideę. I uczy Państwa prawdziwego przebiegu pracy — przypadków brzegowych, wyjątków, drobiazgów, na których klientom zależy, a których nigdy nie zgadliby Państwo z wywiadu. Zanim zaczną Państwo budować, nie zgadują specyfikacji. Kodują Państwo proces, który już przeprowadzili ręcznie i za który otrzymali zapłatę.
Uczciwe odczytywanie sygnałów
To wszystko działa tylko wtedy, gdy są Państwo gotowi uwierzyć w wyniki — a to trudniejsze, niż brzmi, bo do tej pory są już Państwo przywiązani do pomysłu. Niebezpieczeństwem nie są złe dane; jest nim założyciel, który każdy sygnał interpretuje jako zachętę. Letnie zainteresowanie zapamiętuje się jako entuzjazm. Uprzejmy zapis na listę oczekujących staje się „silnym popytem”. Trzeba tu walczyć z własnym optymizmem.
Pomaga ustalić z góry, jak wygląda zaliczenie. Przed przeprowadzeniem testu proszę zapisać wynik, który skłoniłby Państwa do kontynuacji, oraz wynik, który kazałby Państwu przerwać. „Jeśli mniej niż X moich rozmówców opisze to jako realny, powracający problem, odpuszczam”. Ustalenie poprzeczki, zanim zobaczą Państwo dane, to jedyna pewna obrona przed wmówieniem sobie budowy, której nie powinni Państwo podejmować.
| Co obserwujesz | Co to prawdopodobnie oznacza | Następny ruch |
|---|---|---|
| Ludzie z własnej inicjatywy szczegółowo opisują ból | Problem jest realny i odczuwany | Przetestuj gotowość do zapłaty |
| Uprzejme zainteresowanie, brak mocnych historii | Lekka uciążliwość, nie problem płatny | Sprawdź inny segment albo odpuść |
| Zapisy, ale nikt nie zapłaci z góry | Miłe, lecz nie pozycja budżetowa | Wyostrz ofertę lub przemyśl cennik |
| Kilka osób płaci, zanim to istnieje | Prawdziwy popyt | Zbuduj dla nich małą pierwszą wersję |
| Wszyscy to uwielbiają, nikt nie działa | Słyszą Państwo komplementy | Podnieś koszt powiedzenia tak |
A czasem uczciwą odpowiedzią jest nie. To nie porażka — to działający system. Proces walidacji, który nigdy nie może zwrócić „nie buduj tego”, nie jest walidacją, lecz szukaniem przyzwolenia. Założyciele, którzy wygrywają w skali kariery, to nie ci, którzy nigdy nie mają złych pomysłów. To ci, którzy zabijają złe pomysły w trzy tygodnie za kilkaset euro, zamiast pielęgnować je przez rok.
Kiedy naprawdę są Państwo gotowi budować
Załóżmy, że sygnały są dobre. Problem jest realny, ludzie opisali go z emocjami, kilkoro z nich wyłożyło pieniądze. Teraz — i dopiero teraz — budowanie ma sens. Ale nawet tu powściągliwość się opłaca. Celem pierwszej wersji nie jest być produktem, który Państwo sobie wyobrażają. Jest nim dostarczenie jednego kluczowego rezultatu, za który płacą Państwa zwalidowani klienci — i niczego więcej na razie.
Tu walidacja po cichu wręcza Państwu prezent: ostrą, popartą dowodami specyfikację. Wiedzą Państwo, dla kogo to jest, jakie jest kluczowe zadanie, ile ludzie zapłacą i które funkcje pojawiały się raz za razem, a które obchodziły wyłącznie Państwa. Ta jasność jest warta więcej niż jakakolwiek ilość projektowania z góry. To różnica między zbudowaniem właściwej małej rzeczy a zbudowaniem kosztownego wszystkiego.

Pomysł zwalidowany? Zbudujmy właściwą pierwszą wersję.
Gdy już wiedzą Państwo, że ludzie tego chcą, kolejnym ryzykiem jest przebudowanie. Pomagamy założycielom przekuć zwalidowany pomysł w ostrą, lekką pierwszą wersję — dopasowaną do tego, za co naprawdę płacą pierwsi klienci, a nie do wszystkiego, co mogą sobie Państwo wyobrazić.
Zobacz, jak budujemy oprogramowanieCzęste pytania
Jak długo powinna trwać walidacja pomysłu na SaaS?
Z iloma osobami muszę porozmawiać?
Co, jeśli ludzie mówią, że uwielbiają pomysł, ale nie zapłacą?
Czy nie mogę po prostu szybko zbudować MVP i zobaczyć, co się stanie?
Czy walidacja nie grozi tym, że ktoś ukradnie mi pomysł?

Have a nice day to studio programistyczne, które pomaga małym i średnim firmom w cyfryzacji — automatyzacja, sztuczna inteligencja i oprogramowanie na zamówienie, które działa w codziennej pracy, a nie tylko na slajdach.