Zbudowałem ten produkt całkowicie sam, głównie wieczorami, w weekendy i kosztem większej liczby świąt, niż chciałbym przyznać. Przez długi czas nadal czułem, że to prywatny projekt, który po prostu przypadkiem jest dostępny w sieci.
Uruchomienie płatności zmieniło to odczucie natychmiast. Kod nie stał się nagle bardziej skomplikowany, ale zmieniła się moja odpowiedzialność za produkt. Gdy ktoś może zapłacić, zepsuty flow nie jest już tylko niedokończonym edge case’em. Onboarding, moderacja, retencja, zaufanie i niezawodność przestają być tematami na przyszłość. Stają się częścią obietnicy, którą produkt składa teraz.
To najważniejsza lekcja, którą wyciągnąłem z premiery: zbudować samemu projekt pełen funkcji i operować prawdziwym produktem to dwa różne zadania.
W pracy solo wąskim gardłem stała się uwaga
Podczas budowy prawie zniknąłem z mediów społecznościowych. To nie była strategia premiery. Decyzje produktowe, implementacja, edge case’y, testowanie flow i przygotowanie wydania rywalizowały o te same ograniczone godziny.
Dziś dużo lepiej rozumiem ten aspekt pracy solo. Wąskim gardłem nie zawsze jest szybkość pisania kodu. Jest nim ilość uwagi, którą mogę poświęcić rosnącej liczbie stanów, przejść i sposobów awarii w produkcie.
Udany build nie odpowiada na te pytania. Udana płatność również nie.
Płatności zmieniły dla mnie znaczenie błędu
Przed płatnościami mogłem jeszcze traktować część niedoskonałości jako rzeczy, które naprawię później. Po ich uruchomieniu ten sposób myślenia przestał mi wystarczać. Płatny produkt nie musi być pozbawiony błędów; to nierealne. Ale koszt pozostawienia znanego problemu bez rozwiązania jest inny, gdy ktoś już zaufał produktowi na tyle, żeby zapłacić.
Tak samo jest z onboardingiem i moderacją. W trakcie tworzenia łatwo uznać je za systemy pomocnicze wokół „właściwej” funkcji. W produkcji są częścią funkcji, bo użytkownik doświadcza ich bezpośrednio. Z retencją jest podobnie: dobra pierwsza sesja nie dowodzi jeszcze, że produkt daje powód, by wrócić.
Płatności nie udowodniły, że produkt jest skończony. Pokazały, ile pracy ukrywało się pod słowem „gotowe”.
Premiera dała mi inny rodzaj informacji
Po wydaniu zaczęła się mniej fotogeniczna część pracy: błędy widoczne dopiero po publikacji, zepsute flow, problemy moderacyjne, które stają się realne wraz z użytkownikami, oraz pytania o retencję znacznie trudniejsze niż zrobienie dobrego pierwszego wrażenia.
Staram się nie wyciągać z tych sygnałów zbyt daleko idących wniosków. Bug po wydaniu nie oznacza automatycznie złej architektury. Problem z retencją sam w sobie nie jest diagnozą product-market fit. Problem moderacyjny nie dowodzi, że cały system jest niebezpieczny. Objaw mówi mi, gdzie szukać; nie mówi automatycznie, co jest przyczyną.
Zmienia się jakość dowodów. Przed premierą mogę testować to, czego spodziewam się po użytkownikach. Po premierze muszę mierzyć się z tym, co rzeczywiście robią. Release nie jest momentem, w którym niepewność znika. To moment, w którym część najważniejszej niepewności wreszcie staje się obserwowalna.
Pętla po premierze, której używam teraz
Dziś bardziej interesuje mnie praca po premierze niż polerowanie historii samego launchu: lekcje z płatności, zepsute flow, wyzwania moderacyjne, zachowanie użytkowników, niespodzianki w retencji i małe poprawki, które stopniowo zwiększają niezawodność produktu.
- Obserwuję prawdziwy flow. Nie zakładam, że ścieżka zaprojektowana przeze mnie jest tą samą ścieżką, którą faktycznie idą użytkownicy.
- Oddzielam objawy od przyczyn. Nieudany krok pokazuje, gdzie coś poszło źle, ale nie automatycznie dlaczego.
- Priorytetyzuję awarie związane z zaufaniem. Płatności, dostęp, onboarding i moderacja są dla mnie pilniejsze niż niedoskonałości wizualne, bo koszt błędu jest większy.
- Najpierw naprawiam najmniejszy potwierdzony problem. Wolę usunąć jedno zweryfikowane źródło tarcia niż przebudowywać system wokół przypuszczenia.
- Po poprawce ponownie sprawdzam doświadczenie użytkownika. Zmiana w kodzie może być poprawna technicznie, a mimo to nie rozwiązać problemu użytkownika.
To nie jest uniwersalny framework. To po prostu sposób pracy, który najbardziej ma dla mnie sens po przejściu od budowania do jego obsługi.
Premiera zmieniła moje źródło prawdy
Najważniejsze rozróżnienie widzę dziś między zbudowaniem produktu a gotowością do jego operowania. Budowanie pyta, czy system potrafi robić to, do czego go zaprojektowałem. Operowanie pyta, co się dzieje, gdy prawdziwi ludzie go używają, źle rozumieją, opuszczają, wracają, płacą albo trafiają na ścieżkę, której nie przewidziałem.
Dlatego nie traktuję już premiery jako mety. Przed premierą większość dowodów pochodzi z moich własnych założeń i testów. Po niej produkt zaczyna odpowiadać poprzez realne zachowanie, awarie i powtarzające się użycie.