O czym jest ten film
- Chris Raroque zbudował w tydzień Moonjara — aplikację desktopową, w której agenci AI (Claude Code, Codex) tworzą dopracowane zrzuty ekranu i nagrania.
- Ten sam produkt pojawił się na Twitterze dwukrotnie: pierwsze podejście przyniosło 15 zapisów w dobę, drugie kilka dni później — ponad 400 (na wstępie autor mówi łącznie o ponad 500 w ciągu 24 godzin). Jedyną różnicę zrobiło demo.
- Sedno metody: jedno demo albo jeden zrzut, który w mniej niż dziesięć sekund, bez ani słowa wyjaśnień, pokazuje, co produkt robi i dlaczego chce się go mieć.
- Główne narzędzie testowe to „zimna reakcja”: pokazanie materiału jednej osobie (Cecylii) bez żadnego kontekstu i obserwacja dwóch rzeczy osobno — zrozumienia i ekscytacji.
- Kolejne wersje dema rozwiązywały kolejne problemy: najpierw brak zrozumienia („co ja właściwie oglądam?”), potem brak emocji („kolejna apka do zrzutów”), wreszcie niewidoczna „agentowość” produktu.
- Przełom przyniosło pytanie o realne użycie: okazało się, że Cecilia nie wiedziała, że agent może sam generować zrzuty — sądziła, że to apka z doklejonym czatem do edycji.
- Uwagi z testów dem napędzały decyzje produktowe, nie tylko marketingowe: usunięcie czatu w panelu, powrót szybkich edycji w formie paska, tryb skupienia, podgląd symulatora sterowanego przez agenta.
- Kompas przy decyzjach projektowych: czy zrzut ekranu danej funkcji czyni produkt bardziej zrozumiałym i szybciej doprowadza odbiorcę do „magicznego momentu”?
- Nowa strona produktowa pokazuje efekty i odpowiada na obiekcje zamiast wymieniać funkcje — według „analogii Mario” sprzedajemy wzmocnioną wersję klienta, a nie samo ulepszenie.
- Wszystko to wydarzyło się bez ani jednego użytkownika: około 80% iteracji powstało na podstawie reakcji jednej osoby, reszta po publikacji — wielkiej publiczności nie trzeba.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Lista oczekująca to test pomysłu, a nie zbiórka adresów
Na czym polega: Chris zakłada stronę zapisów zawsze, gdy tylko poczuje, że jest na tropie czegoś wartościowego — nie po to, by gromadzić maile, ale by sprawdzić, czy wybrał właściwy zestaw funkcji na premierę.
Jak stosować: Gdy masz działający prototyp, postaw prostą stronę z jednym demem i patrz nie tylko na liczbę zapisów, lecz na to, czy ludzie rozumieją, po co produkt istnieje.
Na co uważać: Lista niczego nie zweryfikuje, jeśli demo nie przekazuje całej propozycji wartości — wtedy mierzysz jakość materiału, a nie zainteresowanie rynkiem.
2.Jedno demo musi powiedzieć wszystko w dziesięć sekund
Na czym polega: Żelazna zasada autora: strona zapisów ma mieć dokładnie jedno demo lub zrzut, który bez wyjaśnień wywołuje reakcję „rozumiem i chcę tego” w mniej niż dziesięć sekund.
Jak stosować: Przed publikacją pokaż materiał osobie bez kontekstu. Jeśli trzeba coś dopowiedzieć, demo jeszcze nie działa — poprawiaj, aż zrozumienie przychodzi natychmiast.
Na co uważać: „Wystarczająco dobre” potrafi zabić start: poprawne wideo z czatem w panelu nie porywało i nie pokazywało siły narzędzia — i przyniosło piętnaście zapisów.
3.Nie psuj pierwszego wrażenia wyjaśnieniami
Na czym polega: Pierwsze zetknięcie z produktem to zasób jednorazowy. Kto je skaże komentarzem „a tu widać, że…”, ten nigdy się nie dowie, czy materiał mówi sam za siebie.
Jak stosować: Pokaż i zamilcz. Obserwuj twarz i oceniaj osobno dwie rzeczy: jasność (czy odbiorca rozumie, co widzi) oraz ekscytację (czy go to pociąga).
Na co uważać: Po pierwszym kontakcie osoba „już wie, o co chodzi”, więc jej kolejne reakcje są mniej wiarygodne — Chris odnotowuje to wprost przy ocenie „siedem na dziesięć” po wielu rundach testów.
4.Reakcja „co ja właściwie oglądam?” to bezcenna informacja
Na czym polega: Najgorsza możliwa odpowiedź Cecylii — piętnaście sekund wpatrywania się i pytanie o sens obrazu — pokazała, że pierwsze demo nie komunikowało właściwie nic.
Jak stosować: Traktuj niezrozumienie jako tani test, który oszczędza ci publicznej wpadki. Zabieraj się od nowa i poprawiaj komunikację, dopóki reakcja nie będzie natychmiastowa.
Na co uważać: Nie bagatelizuj negatywnej opinii jednej osoby tłumaczeniem, że „się nie zna”. Jeśli ona nie zrozumiała, publiczność też nie zrozumie.
5.Pytaj, jak ktoś naprawdę użyłby produktu
Na czym polega: Przełom nastąpił dopiero, gdy Chris spytał Cecylię o jej scenariusz. Okazało się, że planuje robić zrzuty własnoręcznie i edytować je w czacie — nie przyszło jej do głowy, że agent może przygotować materiały za nią.
Jak stosować: W rozmowach testowych proś o opisanie własnego sposobu użycia. Różnica między tym, co chcesz przekazać, a tym, co ludzie faktycznie słyszą, wychodzi na jaw najszybciej.
Na co uważać: Jeśli demo sugeruje inny model użycia niż zamierzony, winny jest materiał, nie odbiorca.
6.Słaby odzew mierzy komunikację, nie produkt
Na czym polega: Dokładnie ta sama aplikacja zdobyła najpierw piętnaście zapisów, a kilka dni później ponad czterysta na dobę. Różnicę zrobiło wyłącznie demo.
Jak stosować: Gdy właściwa grupa docelowa ignoruje materiał, wróć najpierw do sposobu pokazania wartości — dema i strony — zanim zaczniesz przerabiać sam produkt.
Na co uważać: Wiedza twórcy o własnym narzędziu zaburza ocenę. „Przecież to przecież potrafi…” nie jest argumentem rynkowym.
7.Uwagi z testów dema sterują produktem, nie tylko marketingiem
Na czym polega: Testy komunikatu doprowadziły do realnych decyzji produktowych: czat w panelu bocznym wyleciał całkowicie, bo sugerował, że edycje robi się w aplikacji, a nie w agencie.
Jak stosować: Gdy element interfejsu rodzi wątpliwość co do przeznaczenia narzędzia („edytuję tu czy w Claude Code?”), rozważ jego usunięcie albo przebudowę — małe zamieszanie potrafi zaciemnić całość.
Na co uważać: Nie ignoruj własnych nawyków: Chrisowi zależało na szybkich poprawkach bez uruchamiania agenta, więc funkcję przywrócił w innej formie — jako pasek edycji, który nie budzi oczekiwań pełnego czatu.
8.Demo projektuj pod zrozumienie, nie pod własne potrzeby
Na czym polega: Zwycięski widok — wielu agentów pracujących naraz, krążące kursory, mnóstwo widocznych zmian w kilka sekund — był dla autora funkcjonalnie zbędny, ale natychmiast pokazywał, do czego aplikacja jest zdolna.
Jak stosować: Wybieraj do dema sceny z wyraźnymi, szybkimi zmianami (zmiana tła, obrót obrazu, przestawienie urządzenia) i tnij z interfejsu wszystko, co nie pomaga w zrozumieniu.
Na co uważać: To, co wygodne w codziennej pracy, rzadko nadaje się na materiał sprzedażowy — to dwa różne zadania i dwa różne widoki.
9.Sprzedawaj wzmocnioną wersję klienta, nie listę funkcji
Na czym polega: Stara strona wymieniała możliwości; nowa pokazuje, co agenci stworzą dla użytkownika, i odpowiada na wątpliwości w rodzaju „czemu Claude Code nie zrobi tego sam?”. Analogia z Mario: nikt nie chce kwiatka ognia — wszyscy chcą być wielkim Mario strzelającym ogniem.
Jak stosować: Na stronie produktowej pokazuj efekty i pozwalaj odbiorcy wyobrazić sobie własne materiały; typowe obiekcje rozbieraj wprost, najlepiej w osobnych sekcjach.
Na co uważać: Wyliczanka funkcji nie daje wyobrażenia życia z produktem — odwiedzający musi zobaczyć siebie „po”.
10.Do iteracji nie potrzebujesz użytkowników ani audytorium
Na czym polega: Cały tydzień pracy — zdaniem autora równowartość około pół roku iteracji produktowych — odbył się z jednym użytkownikiem: nim samym. Około 80% decyzji zapadło na podstawie reakcji jednej osoby.
Jak stosować: Wystarczy jedna szczera osoba: partner, ktoś zupełnie obcy, piętnaście minut kogoś z Reddita. Przy każdej funkcji zadawaj pytania o jasność i ekscytację.
Na co uważać: Szczerość znaczy więcej niż liczba opinii — znajomi, którzy chcąc dobrze, podkoloryzują, dadzą mniej niż obcy mówiący wprost, co widzi.
Redakcyjne tłumaczenie
Dwa posty na Twitterze, jeden produkt — i trzydzieści razy większy odzew
W zeszłym tygodniu zabrałem się za nowy projekt. Wrzuciłem go na Twittera i w ciągu dwudziestu czterech godzin na listę oczekujących zapisało się ponad pięćset osób. Setki polubień, mnóstwo wiadomości prywatnych z prośbą o dostęp. A teraz najlepsze: ten sam produkt publikowałem już kilka dni wcześniej. Materiał miał wtedy sporo wyświetleń, ale w ciągu doby zapisy sięgnęły… piętnastu osób. Nikomu specjalnie nie zależało. Co więc się zmieniło?
Chcę w tym filmie pokazać krok po kroku, co zrobiłem, żeby przejść od wersji, którą wszyscy zignorowali, do wersji z prawie pięciuset zapisami na dobę. Tak naprawdę nie planowałem tego materiału, ale w pewnym momencie uświadomiłem sobie, że to gotowy miniwykład o moim sposobie myślenia: jak iteruję produkty, jak podchodzę do projektu, jak szukam w aplikacjach momentów, które robią wrażenie, i jak poprawiam je bezlitośnie, zanim zdążę zdobyć pierwszego użytkownika. Wszystko tego nauczyłem się podczas czterech lat budowania aplikacji. A jeśli trafiasz na mój kanał pierwszy raz — witaj. Nazywam się Chris i tworzę aplikacje zwiększające produktywność.
Czym jest Moonjar i skąd się wziął
Dziś mowa o Moonjarze. To aplikacja desktopowa, dzięki której agenci — na przykład Claude Code czy Codex — tworzą dopracowane zrzuty ekranu bez wysiłku. I uwaga: każdy zrzut i każde nagranie, które widzisz w tym filmie, powstało właśnie w Moonjarze.
Robię ich mnóstwo — tygodniowo chyba ponad sto, na potrzeby moich czterech aplikacji. Trafią do dzienników zmian, centrów pomocy, na social media, do filmów takich jak ten. Sprawienie, żeby wyglądały dobrze, pochłania ogrom czasu. Dlatego jakieś półtora tygodnia temu zacząłem budować Moonjara — po to, żeby to Claude Code albo Codex robiły zrzuty za mnie.
Pierwsza wersja była banalnie prosta: MCP, kilka plików umiejętności i aplikacja desktopowa, żebym widział, co porabiają agenci, i mógł wracać do stworzonych przez nie zrzutów (MCP, czyli Model Context Protocol, to standard pozwalający agentom korzystać z zewnętrznych narzędzi; „pliki umiejętności” to zapisane instrukcje, według których agent wykonuje zadania). Po dobie poprawek i pracy na własny użytek byłem od tego czegoś całkowicie uzależniony. W ogóle nie zamierzałem tego publikować, ale gdy zobaczyłem, jak bardzo jest dla mnie przydatne, uznałem: sporo ludzi będzie tego chciało.
Lista oczekująca — po co zakładam ją naprawdę
Gdy tylko mam działający prototyp, z którego jestem naprawdę zadowolony, stawiam stronę zapisów. Robię to za każdym razem, gdy tylko poczuję, że jestem na tropie czegoś wartościowego — tak było przy wszystkich moich dotychczasowych aplikacjach. I szczerze: na tym etapie nie chodzi nawet o zbieranie adresów. Owszem, to ważne — trzeba mieć grupę beta-testerów i próbkę zainteresowania. Ale prawdziwy powód jest inny. Chcę się dowiedzieć, czy buduję właściwą rzecz. Bo sukces to nie tylko dobry pomysł — to również właściwy dobór funkcji, z którymi wypuszczam produkt na świat. I właśnie to chciałem sprawdzić w wypadku Moonjara.
Mam jedną żelazną zasadę dotyczącą takich stron: musi je zdobić jedno demo albo jeden zrzut ekranu, który mówi wszystko. I dokładnie jedno. Ktoś na nie patrzy i w mniej niż dziesięć sekund — bez ani słowa wyjaśnień z mojej strony — ma powiedzieć do siebie: „Aha, rozumiem. I chcę tego.”
Przykład: Amy, moja aplikacja do liczenia kalorii. Jej demo można obejrzeć w kilka sekund i natychmiast przychodzi reakcja: „No tak, licznik kalorii. Widzę, co robi. Widzę ten efekt «wow». Chcę to.” Podobnie Luna, aplikacja do prowadzenia budżetu. Tak, to zwykła aplikacja budżetowa, nic szczególnego — ale gdy ją pokazywałem kilka lat temu, ludzie patrzyli na materiał i mówili: „Wygląda naprawdę dobrze, muszę spróbować.” Właśnie takiej reakcji szukam za każdym razem, gdy przygotowuję demo na stronę zapisów. I dokładnie o tę reakcję chciałem zawalczyć z Moonjarem.
Cecilia, czyli pierwsza publiczność
Zanim powiesz: „Tobie łatwo, masz wielkie grono odbiorców, ja nie mam” — pierwszą osobą, której pokazuję efekty, jest Cecilia. Podchodzę, pokazuję zrzut ekranu i pytam: „No i co o tym myślisz?”. I zwykle tyle. Świadomie nie podaję żadnego kontekstu, nie tłumaczę, co dzieje się na ekranie. Chcę jej zimnej, szczerej reakcji. Muszę wiedzieć, czy zrobiłem to dość czytelnie — czy rozumienie przychodzi w sekundę, maksymalnie dwie. To bardzo ważne, bo pierwsze wrażenie to jedna z najcenniejszych rzeczy, jakie można dostać. Kto je psuje, tłumacząc, co widać na obrazku, po prostu marnuje tę okazję.
Gdy jej pokazuję materiał, obserwuję twarz i szukam dwóch rzeczy. Pierwsza: jasność — czy rozumie, co ogląda. Druga: ekscytacja — czy to, co widzi, ją pociąga, nawet jeśli nie należy do grupy docelowej.
Reakcja, od której wszystko się zaczęło
Pierwszy zrzut przygotowałem sam i byłem z niego szczerze dumny. Byłem pewien, że Cecilia zareaguje entuzjastycznie. Pokazuję — a ona wpatruje się w ekran dobre piętnaście sekund, co samo w sobie jest złym znakiem. W końcu mówi: „No… okej. Chyba mi się podoba. A co ja właściwie oglądam?”.
To mniej więcej najgorsza możliwa reakcja. Nawet nie zauważyła, że patrzy na aplikację do zrzutów ekranu. Dla mnie ta informacja jest jednak na wagę złota. Wyobraź sobie, że wrzucam to od razu na Twittera — wszyscy zareagowaliby dokładnie tak samo.
Zabieram się więc od nowa. Robię mnóstwo iteracji — naprawdę mnóstwo — i w końcu trafiam na wersję, w której od razu widać, że to zrzuty ekranu. Bo o to właśnie chodziło: gdy patrzyła na pierwszy materiał, w ogóle nie wiedziała, że ma przed oczami aplikację do zrzutów. Trzeba było to zakomunikować.
Pokazuję jeszcze raz. Reakcja: „Okej, fajnie. To są zrzuty ekranu. Trochę mnie przytłacza, no ale tak — to zrzuty ekranu.” Zdecydowanie lepiej: przynajmniej wiadomo już, czym jest ta aplikacja. Część jasności jest. Ekscytacji jednak zero. Po prostu kolejna apka do zrzutów ekranu. A sedno produktu jest inne — działa przez agentów. Fatalnie udało mi się to zakomunikować.
Czat po prawej, czyli fałszywy triumf
Wracam więc do punktu wyjścia i główkuję, jak pokazać, że narzędzie jest agentowe. I wpadam na pomysł: skoro ludzie kojarzą czat z agentami, dorzucę po prostu czat po prawej stronie. Tym razem przygotowuję krótkie wideo: po prawej agentowy czat, po lewej edytowany zrzut ekranu.
Pokazuję. Cecilia: „Okej, fajnie — można edytować zrzuty przez czat. Całkiem niezłe.” Myślę: świetnie, rozumie — mamy to. Znaleźliśmy magiczny moment. Nie znaleźliśmy — jeszcze do tego wrócimy — ale wtedy byłem przekonany. Miałem już serdecznie dość iterowania, więc zdecydowałem: koniec czekania, odpalamy listę oczekujących z tym demem.
Dwa dni nad stroną i ocena trzy na dziesięć
Mając „demo, które mówi wszystko”, buduję stronę w Framerze. Spędzam na niej dwa pełne dni — chcę opowiedzieć historię jak należy. U góry zrzut ekranu, a niżej, przy przewijaniu, wyjaśnienie: narzędzie jest agentowe, podłączysz własnego agenta, nie musisz dotykać interfejsu — i to jest ogromna przewaga nad innymi aplikacjami do zrzutów.
Pokazuję stronę Cecylii. „Okej, fajnie, ładnie.” Ekscytacji jak na lekarstwo — dałbym jej trzy na dziesięć. Co mnie dziwi, bo Cecilia robi mnóstwo zrzutów; takie narzędzie realnie ułatwiłoby jej pracę. Dlaczego więc nie jest zachwycona?
Pytam więc, jak wyobraża sobie korzystanie z aplikacji. Odpowiada: „Pewnie zrobiłabym zrzuty, wgrała je do Moonjara i edytowała w czacie.” Na to ja: „A nie przyszło ci do głowy, żeby po prostu kazać Claude Code albo Codexowi użyć Moonjara i zrobić zrzuty za ciebie? Wdrażasz funkcję, a agent od razu przygotowuje materiały.” Na co ona: „O… nie wiedziałam, że tak można.”
I wtedy mnie olśniło. Cecilia sądzi, że to aplikacja do zrzutów z czatem doklejonym na siłę. I słusznie — bo dokładnie to mówiło moje demo. Nie miała pojęcia, że Claude Code może generować zrzuty za nią: uruchomić symulator, przygotować ujęcia. Że nie trzeba robić nic — ładne zrzuty powstaną same.
Wracam więc do strony i wymieniam główny materiał na nowy: po lewej widać Claude Code, po prawej elegancka animacja, w której agent edytuje zrzut ekranu. Pokazuję Cecylii. Ekscytacja na poziomie może siedmiu na dziesięć — choć od razu zaznaczam, że jest już „zaprana” tematem, więc to nie jest czysta, zimna reakcja. Ale w tym momencie biorę, co dają. Mogę iterować w nieskończoność — w końcu trzeba to wypuścić, wrzucić na Twittera i zobaczyć, co ludzie powiedzą.
Pierwsza publikacja: piętnaście zapisów
Wrzucam stronę na Twittera — piękną stronę i tamto wideo jako demo. Materiał zbiera kilka tysięcy wyświetleń i sporo polubień, ale na listę oczekujących zapisuje się… piętnaście osób. Ludziom to było obojętne. Byłem tym wręcz zaskoczony, bo wiedziałem, co to narzędzie potrafi, a użytkownicy Twittera to dokładnie moja grupa docelowa: ludzie budujący produkty i aplikacje, którzy muszą tworzyć mnóstwo materiałów i nie mają na to ochoty — czyli w praktyce wszyscy na Twitterze. Skoro do nich nie trafia, coś jest nie tak. Źle opowiedziałem tę historię.
Wróciłem więc do tego, co opublikowałem, i zobaczyłem: rany boskie, przecież jako demo użyłem materiału, na który Cecilia zareagowała na trzy na dziesięć. Tego z czatem w panelu bocznym. Było zupełnie w porządku — ale nie porywało i, co gorsza, nie pokazywało siły narzędzia. Możliwości agentowe były w nim po prostu niewidoczne. Wyrzucam więc to wideo i zabieram się od nowa, do kolejnych stu iteracji.
Fragment sponsorsowany: WhisperFlow
(Informacja dodatkowa: poniższy fragment to płatna reklama z oryginalnego filmu — firma jest sponsorem odcinka, a nie tematem materiału.)
Zanim pokażę kolejne iteracje — pewnie zastanawiasz się, jak udaje mi się działać tak szybko. Wszystko, o czym opowiadam, działo się w trzy dni. Udało się dzięki Claude Code i dyktowaniu wszystkiego na głos. Do dyktowania używam WhisperFlow — i wielkie podziękowania dla nich za sponsoring tego odcinka.
WhisperFlow to inteligentne oprogramowanie zamieniające mowę na tekst, działające w każdej aplikacji. Gdy iterowałem Moonjara, po prostu mówiłem do Claude Code rzeczy w stylu: „To główne ujęcie nie jest wystarczająco czytelne. Możesz pokazać, jak Claude Code naprawdę edytuje zrzut ekranu?”.
Dla programistów narzędzie jest idealne, bo rozumie ich żargon. Gdy mówię: „Supabase, Convex, schemat, webhook handler”, zapisuje to poprawnie za każdym razem. Działa z Cursor i Windsurf, więc widzi kontekst kodu, na który patrzysz, a nawet potrafi oznaczać pliki. Popatrz: gdy w Cursor mówię „ulepsz style w subscription_overview.tsx”, narzędzie samo podpina ten plik do polecenia — bez dotykania klawiatury. Jest wersja na komputer (używam jej w Cursor do rozmów z GPT i Claude) oraz na iOS i Androida. WhisperFlow jest darmowe, a link pod filmem daje miesiąc wersji Pro z nielimitowaną liczbą słów. Nie musieli tego oferować — sam o to poprosiłem, więc jeszcze raz dziękuję.
Sto iteracji dalej: widok, który w końcu zadziałał
Do rzeczy. Wideo z czatem w panelu bocznym najwyraźniej nie trafiało do ludzi — nie widzieli w nim pełni możliwości agentowych. Przetestowałem więc kolejne warianty; oto te najbardziej warte uwagi.
Pierwszy pokazywał pojedynczego agenta przy pracy, a pod spodem wszystkie pozostałe zadania, którymi się zajmuje. Miałem ogromną pewność, że to zadziała. Cecilia patrzyła i… nic nie rozumiała. Dobrych trzydzieści sekund wpatrywała się w obraz i nie potrafiła poskładać go w całość.
W następnej wersji po lewej umieściłem Claude Code, na dole mały podgląd — symulator i to, co agent klika — a po prawej edytowany zrzut. Chodziło o to, żeby było widać, że praca toczy się na żywo, że agent faktycznie coś robi. Nadal niewystarczająco. Cecylii to nie przypadło do gustu. Pierwsza reakcja: „Nie mam pojęcia, co to za małe okienko symulatora.”
Po kolejnej serii poprawek i prób wylądowałem na czymś szokująco prostym. Obciąłem ogrom interfejsu. Teraz widać po prostu grupę agentów pracujących jednocześnie, z krążącymi kursorami. Widać ich wszystkich na żywo i widać, co poruszają. Istotne, że specjalnie wybrałem sceny, w których dużo się dzieje: zmienia się tło, obraca obraz, przestawia urządzenie. W kilka sekund — mnóstwo ruchu.
Funkcjonalnie ten widok jest mi osobiście niepotrzebny — niczego mi nie daje. Ale doskonale przekazuje, do czego aplikacja jest zdolna. Gdy Cecilia go zobaczyła, natychmiast zrozumiała, o co chodzi. Pomyślałem: w końcu mamy nasze demo. Czas znów wrzucić je na Twittera.
Druga publikacja: od piętnastu do ponad czterystu zapisów
Opublikowałem. Poszło o niebo lepiej — z piętnastu zapisów zrobiło się ponad czterysta w dwadzieścia cztery godziny, i to dzięki samemu demo. Dokładnie ten sam produkt, dokładnie tydzień później, trzydzieści razy więcej zapisów. Jedyna zmiana polegała na tym, że ludzie w końcu rozumieli propozycję wartości, patrząc na obraz.
Chcę tu zwrócić uwagę na coś ważnego: nie zmieniłem wyłącznie marketingu. Aktywnie kształtowałem sam produkt. Gdy Cecilia przekazywała mi uwagi, obcinałem z aplikacji wszystko, co uznałem za zbędne.
Weźmy czat w panelu bocznym. Wyrzuciłem go całkowicie, bo moim zdaniem wysyłał złe przesłanie. Ktoś patrzący myśli: „Aha, aplikacja do zrzutów z wbudowanym czatem — będę wprowadzać poprawki tutaj.” A potem gubi się: „To edytuję tu czy w Claude Code?”. Ta dwuznaczność strasznie mi się nie podobała. Uznałem, że lepiej zdecydowanie postawić na jedno: edycja bezpośrednio w Claude Code albo Cursorze, koniec z czatem.
A potem, pracując samemu, stwierdziłem: są momenty, w których chcę coś szybko poprawić i nie chcę w tym celu uruchamiać Claude Code ani Cursora. Więc funkcję przywróciłem — ale w bardzo konkretnej formie. Zamiast czatu jest pasek edycji na dole. I to działa zaskakująco dobrze: zachowuje większość zalet czatu, ale nikt nie traktuje go jak czatu. Nikt nie oczekuje serii wiadomości — widać, że służy do pojedynczych drobnych poprawek. Przy okazji: gdy z niego korzystasz, aplikacja używa twojej subskrypcji Cursora lub Claude na twoim komputerze — przez Agent SDK, o którym mówiłem w poprzednich filmach. Mówisz na przykład: „Zmień tło na bardziej wyraziste. A, i dodaj elegancki efekt szkła przy powiększeniu timera albo przy podpisie dla Ellie”, klikasz — i narzędzie wykonuje te zmiany na twoim koncie.
Pomyśl tylko, skąd ta decyzja się wzięła: z samych rozmów z Cecylią, przy zerowej liczbie użytkowników, podjęliśmy ogromną decyzję produktową. Gdybym zostawił czat, doszlifowywałbym go pewnie miesiącami — w złym kierunku.
Widząc zaś, jak trudno zakomunikować, że Moonjar ma działać ramię w ramię z Claude Code czy Cursorem, podjąłem kolejne decyzje. Na przykład nowy tryb skupienia: aplikacja zwija się w boczny pasek unoszący się nad resztą ekranu, żeby dało się z niej korzystać obok Claude Code czy Codexa. Albo taki drobiazg: aplikacja pokazuje na żywo symulator czy komputer, na którym agent pracuje — żeby było jasne: „to właśnie robią Claude i Codex, tym sterują na mojej maszynie”. Takie szczegóły po to, żeby nieustannie uświadamiać użytkownikowi możliwości agentowe.
Pozwól, że to podsumuję. Wiele moich najwcześniejszych decyzji projektowych sprowadza się do jednego pytania, które pełni u mnie rolę kompasu: jeśli zrobię zrzut ekranu tej funkcji, czy produkt stanie się przez to bardziej zrozumiały? Czy przybliży ludzi do momentu, w którym zobaczą jego siłę? Ja używam tego narzędzia codziennie — wszystkie materiały w tym filmie powstały w nim, więc wiem, że działa i robi wrażenie. Moim zadaniem jest teraz tak zaprojektować interfejs, żeby zobaczyli to także inni.
Nowa strona produktowa: sprzedawaj wzmocnionego Mario
Ostatnią rzeczą, którą zmieniłem, gdy byłem już zadowolony z produktu, była strona — nadal wisiała tam stara wersja. Popełniłem przy niej klasyczny błąd, na który chcę zwrócić uwagę. Stara strona była po prostu listą funkcji: to robi tamto, nie musisz dotykać interfejsu, tamto wykona się automatycznie. A dobra strona produktowa pokazuje, co staje się możliwe — tak, by odwiedzający wyobrazili siebie i to, jak bardzo ulepszy się ich życie — i rozbraja wątpliwości.
Nowa strona skupia się na pokazaniu, co agenci mogą dla ciebie stworzyć, i odpowiada na typowe obiekcje: „Dlaczego Claude Code nie zrobi tego bez Moonjara?”, „Czemu nie wystarczyłby plik umiejętności?”.
Mój ulubiony sposób myślenia o tym to analogia z Mario. Nikt w Mario nie chce kwiatka ognia. Ludzie chcą być wielkim Mario sypiącym kule ognia. Nie sprzedajesz ulepszenia — sprzedajesz ulepszoną wersję samego klienta, taką, jakim stanie się, gdy zacznie korzystać z twojego produktu. Ta zmiana optyki mocno zaznaczyła się w nowej wersji strony: pokazuję na niej możliwe efekty, a osobna podstrona prezentuje wszystkie piękne zrzuty, które da się wykonać. Moja nadzieja jest taka, że przeglądający wyobrażą sobie własne produkty i pomyślą: „Kurczę, byłoby świetnie wrzucać takie rzeczy na Twittera albo wstawiać je do dziennika zmian”.
Pół roku iteracji bez ani jednego użytkownika
To był mój tydzień. A najdziwniejsze w tym wszystkim jest to, że nikt jeszcze nie użył tego produktu. Jestem jego jedynym użytkownikiem. Chcę to podkreślić, bo ludzie często powtarzają: „Nie mogę iterować, dopóki nie mam użytkowników”. Ja właśnie odrobiłem równowartość pół roku pracy iteracyjnej, zanim pojawił się pierwszy użytkownik. I zanim powiesz: „Tobie łatwo, masz publiczność” — około osiemdziesiąt procent tych iteracji wydarzyło się przy Cecylii; może dwadzieścia procent po publikacji na Twitterze. Możesz zrobić to samo z kompletnie obcą osobą. Możesz wrzucić coś na Reddita i poprosić kogoś o piętnaście minut szczerej reakcji. Żadnej publiczności do tego nie potrzeba.
Jeśli właśnie iterujesz własny produkt, weź te zasady i zadaj sobie pytanie: czy funkcje, które dodajesz, zwiększają jasność i budzą ekscytację? Jeśli nie — rozważ je ponownie albo znajdą inny sposób ich pokazania.
Nie byłem pewien, czy zrobię z tego serię, ale świetnie się bawię, więc pewnie tak. Jeśli chcecie więcej filmów o Moonjarze, dajcie znać w komentarzach. Nie wspomniałem o tym na początku, ale sporo nauczyłem się o budowaniu produktu zaprojektowanego od podstaw dla agentów — Moonjar to pierwsza moja w pełni „agentowa” aplikacja. Myślałem, że Amy, licznik kalorii, nią była — myliłem się. Dopiero to jest agent-first. I dało mi to przedsmak tego, jak w przyszłości będzie się budować produkty; prawdopodobnie zrobię o tym drugi film — dajcie znać, czy taki chcecie. Jeśli podobają ci się takie treści, zajrzyj na mój Instagram i TikTok — wrzucam tam coś niemal co drugi dzień o budowaniu aplikacji. No i oczywiście: jeśli spodobał ci się ten materiał — zasubskrybuj. Dziękuję, że byliście. Do zobaczenia w następnym.