Tworzenie produktu czy rozwiązywanie problemów?

Sześć miesięcy pisania kodu, landing gotowy, cennik przemyślany, w onboardingu nawet animacja, która ładnie się przewija. Wypuszczasz w poniedziałek, wrzucasz link na trzy grupy i czekasz. Do piątku masz czterdzieści rejestracji i zero płatności.

Pierwsza myśl jest zawsze ta sama: coś jest nie tak z produktem. Może onboarding za długi, może cena za wysoka, może brakuje tej jednej funkcji, o którą ktoś zapytał w komentarzu.

Prawie nigdy o to nie chodzi. Produkt nie jest rzeczą, którą zbudowałeś — jest hipotezą o tym, że ktoś inny ma problem wart akurat tych pieniędzy. A hipotezy się nie buduje — hipotezę próbuje się obalić, możliwie najtaniej i możliwie najwcześniej.

Liczby o upadkach nie mówią nic o twoim przypadku

Zacznijmy od uporządkowania tła, bo w tym temacie krąży więcej folkloru niż danych. „Dziewięćdziesiąt procent startupów upada" i „dziewięćdziesiąt dwa procent SaaS nie dożywa trzeciego roku" powtarza się w każdym drugim wpisie, ale próba dojścia do badania źródłowego kończy się na kolejnych postach cytujących inne posty.

Twarde dane mówią coś mniej efektownego. Amerykańskie Bureau of Labor Statistics od lat mierzy przeżywalność nowych firm. Pierwszy rok przeżywa około 80% z nich, a do piątego dociąga mniej więcej połowa. To nie jest apokalipsa, tylko normalna śmiertelność nowych przedsięwzięć, i dotyczy wszystkich branż, nie tylko softwaru.

Skąd więc rozjazd? Z definicji porażki. Shikhar Ghosh z Harvard Business School przeanalizował ponad dwa tysiące spółek finansowanych przez fundusze. Około 75% z nich nigdy nie zwraca inwestorom kapitału, ale tylko 30–40% likwiduje aktywa, czyli upada w potocznym sensie. Ghosh sam zwraca uwagę, że branżowe wskaźniki na poziomie 20–30% opisują tę samą rzeczywistość, tylko liczoną inaczej.

Jedna liczba z tego zestawu jest jednak użyteczna, bo mówi o przyczynie, a nie o wyniku. CB Insights przeanalizowało 431 spółek finansowanych przez fundusze, które zamknęły się po 2023 roku. Na szczycie listy przyczyn stoi wyczerpanie kapitału z wynikiem 70%. Samo CB Insights opatruje to jednak zastrzeżeniem, że pieniądze kończą się na końcu, a nie na początku. Druga pozycja jest tą prawdziwą: słaby product-market fit, wskazany w 43% przypadków.

I tu kończy się użyteczność statystyk. Żadna z tych liczb nie powie ci, czy twój konkretny pomysł ma sens, bo wszystkie opisują cudze próby. Jedyna liczba, która cię dotyczy, jeszcze nie istnieje — i trzeba ją zdobyć, zanim napiszesz resztę kodu.

Produkt jest hipotezą o cudzym problemie

Rozróżnienie, które decyduje o wszystkim dalej, jest subtelne i łatwo je przegapić. Chodzi o to, od czego zaczynasz myśleć.

Pierwszy tryb ma przy tym własną, przewidywalną awarię. Kiedy nie znajdujesz problemu, który pasuje do twojej technologii, dokładasz funkcje w nadziei, że któraś w coś trafi — i tak scope creep wchodzi tylnymi drzwiami.

Problem bez ceny to jeszcze nie problem

Tu jest miejsce, w którym większość walidacji się psuje, choć wygląda na przeprowadzoną. Można zebrać dziesięć rozmów, usłyszeć dziesięć razy „tak, to jest problem" i dalej nie wiedzieć nic.

Brakuje jednej wielkości: ile ten problem kosztuje konkretną osobę w konkretnym miesiącu. Nie „dużo" i nie „sporo czasu", tylko ile godzin, czyich, po jakiej stawce, albo ile pieniędzy wycieka i gdzie dokładnie. Dopóki tej liczby nie masz, twoja hipoteza jest nieobalalna — a hipoteza, której nie da się obalić, nie jest hipotezą, tylko nadzieją.

Wycena bólu robi trzy rzeczy naraz, i dlatego warto o nią walczyć. Po pierwsze daje ci górną granicę ceny, bo nikt nie zapłaci więcej, niż kosztuje go problem. Po drugie odsiewa problemy prawdziwe od deklarowanych. Rzecz, która kosztuje kogoś trzy minuty w tygodniu, jest irytacją, a nie bólem. Po trzecie daje ci zdanie, którym zaczniesz sprzedaż, bo tak właśnie brzmi obietnica zrozumiała bez tłumaczenia.

Zwróć uwagę na konsekwencję, która wygląda niewinnie. Jeśli klient rozwiązuje dziś swój problem w arkuszu w pięć minut tygodniowo, to twoja aplikacja za sto złotych miesięcznie nie jest droga — jest zbędna. Nie przegrywa z konkurencją, tylko ze status quo, które jest darmowe i już działa.

📖 Ze słownika Noraline Product-Market Fit (PMF) — punkt, w którym produkt rozwiązuje problem wystarczająco dobrze, żeby klienci płacili, wracali i polecali go innym. Nie „ludzie się rejestrują" i nie „mamy traction". Test praktyczny jest odwrotny do intuicji: gdybyś zabrał klientom produkt, czy ktoś by zaprotestował? Jeśli mógłbyś go wyłączyć i nikt by nie zauważył, nie masz PMF — masz ruch.

Ankieta powie ci to, co chcesz usłyszeć

Tu działa mechanizm, który opisywałem przy okazji efektu Dunninga-Krugera. Im mniej wiesz o rynku, tym mocniej jesteś przekonany, że pomysł jest oczywisty. Rozmowa z pięcioma osobami, które ten problem faktycznie mają, jest najtańszym znanym lekarstwem na to przekonanie.

Warunek jest jeden i twardy: to mają być rozmowy o ich pracy, a nie prezentacje twojego produktu. Jeśli po pięciu rozmowach nie słyszysz tego samego bólu opisanego innymi słowami, to nie znaczy, że trafiłeś na złych ludzi. To znaczy, że problem, który zakładałeś, nie jest wspólny.

W takiej rozmowie przydaje się przy tym inna umiejętność, niż podpowiada intuicja. Współodczuwanie sprawia, że przytakujesz i wychodzisz z potwierdzoną hipotezą; odtworzenie cudzego procesu w głowie sprawia, że wychodzisz z liczbą. Psychologia rozdziela te dwie rzeczy jako empatię emocjonalną i poznawczą, a test empatii mierzy je osobno — dwanaście pytań i dwa wyniki. Jeśli twoja emocjonalna wyraźnie przewyższa poznawczą, wywiady z klientami będą przyjemniejsze i mniej użyteczne, niż ci się wydaje.

Rejestracja mierzy ciekawość, powrót mierzy potrzebę

Ta sama asymetria wraca po premierze, tylko na innych danych. Rejestracje to metryka, która zawsze wygląda dobrze, bo mierzy ciekawość — a ciekawość jest darmowa.

Fałszywy product-market fit wygląda dokładnie jak prawdziwy przez pierwsze dwa tygodnie. Skok kont, ruch na landingu, kilka miłych wiadomości. Dopiero czwarty tydzień pokazuje, ile osób wróciło, a trzeci miesiąc, ile płaci drugi raz. Retencja jest metryką obalającą i dlatego jest niewygodna.

Product-Led Growth wchodzi w to samo miejsce i bywa mylony z odpowiedzią na problem. Dane z benchmarków OpenView pokazują, że firmy produktowe rosną szybciej i efektywniej wydają pieniądze na sprzedaż — ale to jest przewaga w dystrybucji, nie w rozumieniu rynku.

Slack nie wygrał dlatego, że miał darmowy plan, tylko dlatego, że komunikacja w rozproszonych zespołach była rozwiązana źle, a darmowy plan tylko obniżył próg wejścia do rozwiązania, którego ludzie już chcieli. PLG jest wzmacniaczem. Jeśli pod spodem masz rozwiązany problem, przyspiesza wzrost; jeśli nie masz nic, przyspiesza dostarczanie użytkowników prosto do wyjścia.

Każda dodana funkcja powiększa zakład, którego nie sprawdziłeś

Kiedy hipoteza nie chce się potwierdzić, odruch jest zawsze ten sam: dołożyć. Jeszcze jedną integrację, jeszcze jeden widok, jeszcze eksport do PDF-a, bo ktoś o niego pytał.

To jest ruch, który wygląda jak praca i nią nie jest. Każda dodana funkcja powiększa zakład o to, że problem istnieje, zamiast ten zakład rozstrzygać — a dodatkowo podnosi koszt utrzymania i wydłuża czas do następnej odpowiedzi z rynku.

Dlatego minimalna wersja produktu nie jest wersją okrojoną, tylko wersją, którą da się obalić najszybciej. Jedna funkcja rozwiązująca jeden problem lepiej niż to, co klient robi dzisiaj. Tak działa zasada 70%: wypuść niepełny zakres na czas i pozwól rynkowi dokończyć projektowanie.

Na drodze staje jednak coś, co nie ma nic wspólnego z produktem. Trudno wyrzucić rzecz, w którą włożyło się pół roku — a razem z pieniędzmi zainwestowałeś w nią kawałek własnej tożsamości. To błąd utopionych kosztów i na tym etapie działa najmocniej. „Spędziłem nad tym pół roku" przegrywa merytorycznie z „klienci płacą i wracają", a mimo to wygrywa w praktyce prawie za każdym razem.

Blisko tego siedzi fałszywa produktywność. Commity, refaktory, poprawianie landingu i wybieranie fontu dają poczucie ruchu, którego rozmowa z klientem nie daje. Tyle że pierwsze jest komfortowe, a drugie rozstrzygające.

Zapisz hipotezę w jednym zdaniu i wybierz najtańszy test

Zamiast listy postanowień jedno ćwiczenie, które zajmuje kwadrans i oszczędza miesiące. Zapisz swój pomysł w formie zdania, które da się sprawdzić.

Jeśli w pierwszym zdaniu którekolwiek pole zostaje puste, to nie jest luka w opisie — to jest miejsce, w którym twój pomysł jeszcze nie został sprawdzony. Drugie zdanie jest trudniejsze i dlatego trzeba je wypisać zanim zaczniesz: potem będziesz miał zbyt duży interes w tym, żeby tego nie zobaczyć.

I dopiero mając te dwa zdania, siadaj do kodu. Nie dlatego, że planowanie jest ważniejsze od budowania, tylko dlatego, że budowanie bez nich jest najdroższym sposobem zadania pytania, które można zadać przez telefon.