Dziś zapraszam Cię na kolejny odcinek specjalny 🇬🇧 podcastu „Dodane do Backlogu". Naszym gościem jest Daniele Ronca - organizator jednej z najszybciej rosnących społeczności i konferencji produktowych w Europie - berlińskiego ProductLab.

Dzisiaj Daniele ściąga na jedną scenę liderów z Google, Amazona, Stripe, n8n, GetYourGuide oraz speakerów pokroju Raviego Mehty (ex-CPO Tinder). A zaczynał od czegoś, czego nikt sobie nie życzy: w 2024 roku zwolniono jego i cały jego zespół produktowy.

Rozmawiamy o tym:

• Jak zbudował biznes od zera po lay-offie - traktując community jak produkt. JTBD, marketplace, retencja, discovery - dokładnie te narzędzia, których używasz w pracy.

• Co łączy najlepsze produktowe społeczności w Europie i jak wyglądają kulisy organizacji konferencji ze speakerami z topowych produktowych firm;

• Jak maksymalnie skorzystać ze społeczności i eventów, na które chodzisz.

Zaczynamy 👇

Słuchaj na Spotify

lub Apple Podcast.

• Dlaczego po lay-offie Daniel rozpoczął pracować nad ProductLab-em?

• Jaki problem naprawdę rozwiązują dziś produktowe community - i dlaczego connection stał się cenniejszy niż wiedza

• Jak budować community jak produkt - JTBD, dynamika marketplace’u i dlaczego warto stawiać na podaż, nie popyt

• Jak wyciągać realną wartość z konferencji i meetupów (i jedno pytanie, które otwiera każdego product leadera)

• Największe mity o budowaniu community - w tym ten o darmowym alkoholu

• Kulisy organizacji jednej z największych konferencji produktowych w Europie - ze speakerami z n8n, Stripe, Reforge, Parloa i Ravim Mehtą

Poniżej znajdziesz też moje rozbudowane notatki z rozmowy z Daniele ⤵️

Moje notatki z podcastu

• 1️⃣ Od PMa do Foundera (jak to się zaczęło)

• 2️⃣ Daniele podszedł do społeczności jak do produktu

• 3️⃣ Samotność lidera - problem, o którym mało kto mówi

• 4️⃣ Jak wyciągać wartość z community (bez cringe’u)

• 5️⃣ Podsumowanie

• 🎁 Bonusy dla społeczności (~500 euro)

1️⃣ Od PMa do Foundera (jak to się zaczęło)

Zacznijmy od czegoś, co łatwo przeoczyć w tej historii - timingu. Fala produktowych layoffów przetoczyła się przez Berlin (i całą Europę) w 2024. Setki produktowców nagle szukało tego samego: miejsca, gdzie mogą się uczyć, poznawać ludzi i szukać nowych szans.

A takiego miejsca nie było.

„Wiele osób, jak ja, szukało community, żeby się uczyć, znaleźć nowe kontakty. I go nie było.”

To jest moment, w którym większość ludzi widzi tylko własny problem („straciłem pracę”). Daniele zobaczył rynek. Berlin - stolica, tech hub, tysiące PM-ów. Po COVID robienie eventów nie było modne, więc konkurencji praktycznie zero. Lenny dopiero zaczynał uruchamiać community z ambasadorami, Luma raczkowała.

Timing, market size, realna potrzeba i brak konkurencji. Jeśli to brzmi znajomo, to dlatego, że to dokładnie ta sama checklist, którą stosujesz, oceniając czy warto budować nowy produkt. Daniele po prostu zastosował ją do siebie.

„To znów był timing. Jak w każdej firmie - zaczynasz od timingu, company, market size i need. To normalny startup.”

Pierwsza lekcja: świetne produkty (i community) nie powstają z genialnego pomysłu. Powstają, gdy realna potrzeba spotyka się z odpowiednim momentem. Twoja robota jako PM-a to ten moment rozpoznać - a nie wymyślić.

2️⃣ Daniele podszedł do społeczności jak do produktu

Tu jest sedno całej historii i powód, dla którego w ogóle o niej piszę.

Daniele nie myśli o Product Lab jak o zwykłej konferencji. Myśli o tym jak o produkcie. Dosłownie. Gdy pytam go, co przeniósł z product managementu do budowania community, odpowiada bez wahania: Jobs to be Done i continuous discovery.

2.1. Za co ludzie naprawdę płacą?

Zadaj sobie pytanie: po co ktoś miałby płacić setki euro za bilet na konferencję albo poświęcać wolny wieczór na meetup? Wiedza jest dziś za darmo.

„Jesteśmy w momencie, gdzie ludzie nie potrzebują już informacji ani wiedzy. To jest publicznie dostępne za darmo albo bardzo tanio.”

Lenny’s Newsletter, setki innych newsletterów, podcasty, YouTube, książki. Każda druga osoba ma swój side-project edukacyjny. Jeśli chcesz się czegoś nauczyć, materiał jest na wyciągnięcie ręki.

Więc wiedza to nie jest job to be done, który rozwiązuje community.

To, co zostaje deficytowe - i według Daniele będzie coraz cenniejsze - to connection. Możliwość spotkania ludzi, którzy pozwolą Ci zbenchmarkować, gdzie jesteś. Jak wygląda rynek naprawdę. Jak te firmy rekrutują. Kto może Cię komuś przedstawić, zamiast wysyłania CV w próżnię na LinkedIn.

To jest głęboko produktowe myślenie. Daniele nie sprzedaje features (prelekcje, warsztaty, networking). Sprzedaje outcome: „poczujesz, gdzie jesteś i z kim warto się połączyć, żeby ruszyć dalej”.

2.2. Continuous discovery - “wywiady” z dosłownie każdą osobę

Najbardziej uderzyło mnie to, jak Daniele robi discovery. Każdej osobie, która dołączyła do zeszłorocznej konferencji, napisał na LinkedIn. Zagadał. Zapytał, czego szuka i dlaczego.

„Każdą osobę, która dołączyła w zeszłym roku, przywitałem na LinkedIn. Pytałem - przez czat albo rozmowę - czego szukają i dlaczego.”

I tu pada obserwacja, którą zna każdy, kto robił discovery interviews:

„To ‘dlaczego’ jest naprawdę trudne. Ludziom ciężko powiedzieć, po co tam są. Albo nie potrafią, albo wolą nie mówić.”

Znasz to uczucie, prawda? To samo dzieje się w rozmowach z userami. Ludzie nie mówią wprost, o co im chodzi - musisz to wyłuskać. Daniele traktuje uczestników community jak userów swojego produktu. Bo nimi są.

2.3. Społeczność to… marketplace

To jest fragment, po którym zapisałem sobie notatkę „to trzeba dać do newslettera”.

Daniele traktuje community jak marketplace. I nie chodzi tu o przenośnię. On naprawdę traktuje swoją społeczność według zasad związanych w zbudowanym produktu typu marketplace.

W tym marketplace masz dwie strony:

• Podaż (supply) - ludzie z wiedzą i doświadczeniem. Ci, którzy wnoszą 7, 10, 15 lat doświadczenia i wychodzą na scenę.

• Popyt (demand) - ludzie, którzy chcą connection i learningu. Czyli większość.

I teraz uwaga - większość organizatorów skupia się na popycie. Bo to popyt kupuje bilety, popyt wypełnia salę, popyt generuje przychód. Daniele robi odwrotnie.

„Od początku skupiam się bardziej na podaży niż na popycie.”

Dlaczego? Bo to strona podażowa napędza całą wartość. To ludzie z doświadczeniem przynoszą okazje, zostają mentorami, kształtują trajektorię kariery innych. Jeśli przyciągniesz najlepszych ludzi po stronie podaży, popyt przyjdzie sam. Odwrotnie to nie działa.

Jeśli myślisz o marketplace’ach w kategoriach produktowych, od razu widzisz tu network effect. Wartość community rośnie z każdym kolejnym wartościowym człowiekiem po stronie podaży - a to przyciąga jeszcze więcej popytu. Klasyczna pętla, którą znasz z Airbnb czy Ubera.

I Daniele idzie o krok dalej. Zauważył, że najcenniejsza jest strona podażowa - więc buduje community wewnątrz community. Osobne grupy dla liderów (CPO, VP Product), bo ich problemy są zupełnie inne niż seniora czy principala. Small people management, stres, boardroomy. Zaczął od group coachingu, teraz eksperymentuje z podgrupami tylko dla liderów.

Lekcja, którą wyciągnąłem: w każdym marketplace (i w wielu produktach) jedna strona jest trudniejsza do zdobycia i cenniejsza. Zidentyfikuj ją i skup tam większość energii. Reszta podąży.

2.4. Jak mierzyć, czy community działa?

Pytanie, które zadaliśmy wprost: jakie sygnały mówią, że community naprawdę działa? Bo „fajna atmosfera” to nie jest metryka.

Retencja - jak w produkcie

Pierwszy sygnał był ode mnie: czy ludzie z poprzedniego wydarzenia pojawiają się na następnym.

„To jak retencja w product managemencie. Jeśli pokazali się na poprzednim i chcą się pokazać na następnym - wiem, że chcą być w tym community.”

To jest dokładnie retencja, którą śledzisz w swoim produkcie. Ilu userów wraca? Ale Daniele dorzucił do tego ważną uwagę - w Niemczech pojawił się teraz nadpodaż eventów, więc sam wskaźnik show-upu spada wszystkim i przestaje być wiarygodny w oderwaniu od kontekstu.

Klasyczna pułapka metryki, która działa, dopóki nie zmieni się rynek.

„Time to yes” - metryka, której nie znałem

I tu pada coś, co usłyszałem pierwszy raz w życiu, a jest genialne w swojej prostocie.

Daniele mierzy „time to yes” - jak długo zajmuje przekonanie topowego speakera (z firmy poziomu TOP 10, którą wszyscy znają, często z osobnym procesem PR), żeby powiedział „tak, wchodzę w to”.

„Czujesz to po prostu. Jak szybko idzie operacja.”

Rok temu ściągnięcie mocnego nazwiska wymagało rund wprowadzeń, przekonywania, proszenia o intro. W tym roku - jedno intro i „lecimy”. To proxy dla siły brandu. Im silniejszy Twój brand i pozycjonowanie, tym szybciej najlepsi mówią „tak”.

Pomyśl, ile Twoich produktowych „metryk” to tak naprawdę wyczucie, które wyrobiłeś przez powtarzanie. Time to yes to dokładnie to - Daniele nie liczy tego w arkuszu, ale czuje różnicę między rokiem pierwszym a drugim. I to mu wystarcza, żeby wiedzieć, że idzie w dobrą stronę.

3️⃣ Samotność lidera - problem, o którym mało kto mówi

Teraz coś osobistego, bo ten wątek trafił we mnie mocno.

Prowadzę kilka community, w tym jedno mniejsze - meetup dla senior PM-ów i product leaderów. I wiesz, co się okazało głównym powodem, dla którego ludzie tam przychodzą?

Samotność.

Im wyżej jesteś w produkcie, tym mniej masz z kim rozmawiać o produkcie. Brzmi paradoksalnie, ale sam tego doświadczyłem - jako head of product wtedy i teraz, w scale-upie.

Masz Zarząd, ale Zarząd nie myśli produktowo. Masz zespół, ale to są Twoi product managerowie, którym raczej Ty nadajesz kierunek, niż odbijasz z nimi trudne decyzje jak z równymi sobie. I nagle okazuje się, że nie masz nikogo na swoim poziomie, kto zrozumie, z czym się mierzysz.

„Jesteś CPO albo VP Product i nie masz z kim pogadać w firmie.”

To jest realny, głęboki job to be done dla wielu - i według mnie jeden z najsilniejszych motorów całego ruchu community. Ludzie nie przychodzą tam po wiedzę (tę mają za darmo). Przychodzą, żeby znaleźć ludzi, którzy myślą tak jak oni. Którzy łapią te same wewnętrzne żarty, ten sam żargon, te same frustracje.

To zresztą łączy się z czymś, o czym rozmawialiśmy w odcinku - Marcin przywołał książkę Cultish Amandy Montell, o języku fanatyzmu. Jeśli odłożysz na bok mroczną stronę „kultów”, zostaje fascynujący mechanizm: ludzie są zaprogramowani, żeby szukać przynależności i sensu w grupach. Dwa pytania, na które community odpowiada, brzmią: „kim jestem?” i „gdzie pasuję?”.

I jako product leader - jeśli to czytasz i czujesz tę izolację - to nie jest Twoja słabość. To strukturalna cecha roli. Warto o tym wiedzieć i świadomie szukać swojego kręgu.

4️⃣ Jak wyciągać wartość z community (bez cringe’u)

Skoro już wiesz, po co iść na konferencję czy meetup, to zostaje pytanie: jak robić to dobrze? Bo większość ludzi przychodzi, konsumuje, łapie za darmowe piwo i wychodzi bez jednego wartościowego kontaktu. Marcin ujął to wprost: „ludzie przychodzą, konsumują i wychodzą”. Szkoda, bo realna wartość konferencji nie jest na scenie - jest w korytarzu.

Rozłóżmy więc na czynniki pierwsze, jak podejść do tego jak PM. Bo - i to jest sedno tej sekcji - dobry networking to nie sprzedaż siebie. To discovery. Te same zasady, których używasz w rozmowach z userami, działają w rozmowie z founderem przy kawie.

Zasada 1: Otwieraj pytaniem o problem (a nie o pogodę ;))

Marcin ma swoje ulubione pytanie otwierające, które naprawdę działa:

„What’s on top of your mind?” - co teraz najbardziej zaprząta Ci głowę?

Świetnie sprawdza się przy product liderach, bo rozpakowuje realny problem, nad którym ktoś aktualnie siedzi. Otwiera prawdziwą rozmowę, a nie small talk o tym, jak dojechałeś na konferencję.

To dokładnie ta sama mechanika co w dobrym discovery. Nie pytasz, co jest świetne - pytasz, co nie działa. Nikt Ci nie powie nic wartościowego, jeśli poprosisz o komplement. Ludzie otwierają się dopiero, gdy dotkniesz czegoś, co ich uwiera.

Zasada 2: Najpierw chemia, potem szczerość

Jest jeden warunek, o którym łatwo zapomnieć: musisz najpierw zbudować minimum chemii. Nikt senior nie odpowie Ci szczerze na pytanie o swoje problemy, dopóki nie poczuje, że warto z Tobą gadać.

I tu pada ciekawe pytanie, które sam zadałem w rozmowie - czym w ogóle jest ta „chemia”, skoro spotykasz kogoś pierwszy raz w życiu? Bo to nie jest znajomość. To raczej ten sam poziom energii, wspólny kontekst, może anegdota, która pokazuje, że rozumiesz świat rozmówcy. W praktyce: zanim zadasz mocne pytanie, daj drugiej osobie sygnał, że jesteś „z tego samego plemienia”.

Zasada 3: Do najlepszych podchodź jak do randki, nie jak do rekrutera

A jak zdobyć uwagę naprawdę zajętych ludzi - speakerów, top founderów, sponsorów? Tu Daniele rzuca porównanie, które zostaje w głowie:

„To nie różni się od randkowania. Wysyłanie kwiatów speakerom, żeby przyszli na konferencję, to jak ‘chcesz iść na kawę?’. Są zajęci. Wiele osób do nich pisze.”

Ich LinkedIn to 30 nieodpisanych wiadomości. I - co gorsza - każda ma ten sam „pickup”: „szukam pracy”, „szukam nowych możliwości”. Jeśli podejdziesz z tym samym, wtapiasz się w tłum i zostajesz zapomniany w 5 sekund.

Jak się wyróżnić? Nie idź z własnym celem wypisanym na czole. Przyjdź z ciekawą myślą, która coś doda do sposobu myślenia tej osoby albo go przełączy.

„Jeśli przyjdziesz z interesującą myślą, która zmieni ich sposób myślenia albo coś do niego doda - zapamiętają Cię.”

To brzmi miękko, ale ma twardą logikę. Ci ludzie są bystrzy i przemyślani. Nie kupisz ich charyzmą (chyba że naprawdę ją masz), za to możesz ich kupić treścią. Paradoks polega na tym, że im mniej pchasz swój cel, tym większa szansa, że ktoś sam do niego wróci - bo Cię zapamiętał.

Zasada 4: Zbuduj sieć, zanim jej potrzebujesz

I tu dochodzimy do najważniejszej rzeczy, którą powiedział Marcin - takiej, która zmienia całe podejście do networkingu:

Najlepsi freelancerzy i PM-owie nie szukają pracy. To praca szuka ich.

Nie dlatego, że mają szczęście. Dlatego, że latami, meetup po meetupie, budowali sieć kontaktów, która ich pamięta i odzywa się, gdy pojawia się okazja. Networking to nie jest coś, co odpalasz, gdy stracisz pracę (patrz: historia Daniele z początku artykułu). To coś, co budujesz zanim będzie Ci potrzebne.

To zresztą łączy się z metryką „time to yes” z wcześniejszej sekcji. Daniele w rok skrócił czas potrzebny na ściągnięcie topowego speakera z 10 godzin do 30 minut - bo przez ten rok konsekwentnie budował relacje. Ty budujesz dokładnie to samo, tylko dla własnej kariery.

Ciekawostka: Ile… pije się na konferencjach produktowych?

I jeszcze jedno, obalony mit. Myślisz, że konferencje to picie? Daniele przy pierwszej edycji zapytał ChatGPT, ile alkoholu zamówić - dostał rekomendację 3 litry na osobę, zamówił 4. Skończyło się na oddaniu 20 skrzyń napojów.

„Ludzie piją mniej, niż myślisz. Ledwie dwa litry dziennie, i to głównie kawa.”

Najlepsi freelancerzy i PM-owie nie mają problemu ze znalezieniem pracy - to praca znajduje ich. Bo latami, meetup po meetupie, budowali sieć kontaktów, która pamięta ich i odzywa się, gdy pojawia się okazja.

5️⃣ Podsumowanie

Nawet jeśli nigdy w życiu nie zbudujesz community, historia Daniele daje Ci kilka rzeczy do zastosowania od zaraz 👇

• ✅ Timing bije pomysł. Świetne produkty (i community) powstają, gdy realna potrzeba spotyka odpowiedni moment. Twoja robota to go rozpoznać, nie wymyślić.

• ✅ Sprzedawaj outcome, nie features. Daniele nie sprzedaje prelekcji. Sprzedaje connection i benchmark. Zapytaj siebie: jaki realny job to be done rozwiązuje mój produkt?

• ✅ Zidentyfikuj trudniejszą stronę marketplace’u. W community to podaż. W Twoim produkcie może to być coś innego - ale prawie zawsze jedna strona jest cenniejsza i trudniejsza. Skup tam energię.

• ✅ Mierz to, co naprawdę mówi o zdrowiu produktu. Retencja. Time to yes. Czasem najlepsza metryka to wyczucie wyrobione przez powtarzanie - byle było oparte na realnym sygnale.

• ✅ Jeśli jesteś liderem i czujesz się samotnie - to normalne. Znajdź swój krąg ludzi, którzy myślą jak Ty. To nie luksus, to potrzeba.

• ✅ Networking to discovery, nie sprzedaż siebie. Przyjdź z ciekawą myślą, nie z CV. Pytaj, co nie działa, nie proś o komplementy.

Cała ta rozmowa utwierdziła mnie tylko w czymś, co powtarzam od dawna: realny product craft to sposób myślenia, który działa wszędzie - na produkcie, na własnej karierze, na budowaniu społeczności, a nawet (jak pokazał Daniele) na wyjściu z zawodowego dna.

🎁 Bonusy dla społeczności (~500 euro)

Powyżej wyciągnąłem najważniejsze wątki, ale w odcinku jest znacznie więcej - m.in. pełny lineup berlińskiej konferencji, kulisy zapraszania speakerów i cała dyskusja o tym, jak zmienia się rola product leadera.

A jeśli chcesz zobaczyć to na żywo - Daniele organizuje w Berlinie trzydniową konferencję ProdcutLab (15-17 września) ze speakerami z n8n, Stripe, Reforge, Parloa i Ravim Mehtą. Spacjlanie dla społeczności “Dodane do Backlogu” przygotował promocody na konferencję:

• 🏆 €100 zniżki dla dwóch liderów na bilet Leadership Workshop + 3 dniowy bilet konferencję.

• 🎟️ 20% ZNIŻKI dla 5 osób na 3 dniowy bilet na konferencję.

Szczegóły i kody w opisie odcinka na Spotify ⤵️

→ Posłuchaj odcinka

Niedawno stanąłem przed konkretnym wyzwaniem: potrzebowałem dokładnego opisu wszystkich funkcji swojego produktu - jako kontekst dla agentów AI, z którymi nad tym produktem pracuję.

Zamiast pisać to ręcznie - skorzystałem z agenta AI w przeglądarce (Commet) i w kilkanaście minut miałem mapę modułów, funkcji i subfunkcji z dokładnymi opisami.

Dziś pokażę Ci krok po kroku, jak to zrobiłem (jest wideo) 👇

W dzisiejszym wydaniu:

• 1️⃣ Po co PM-owi taksonomia funkcji (i kiedy realnie jej używam)

• 2️⃣ Wideo krok po kroku - jak zrobiłem to agentem AI (7 min)

• 3️⃣ Przeglądarka AI Comet i alternatywy - czym to zrobić i na co uważać

• 4️⃣ Gotowy prompt do skopiowania (PL + EN)

Subscribe now

👉 Partnerem dzisiejszego wydania… jestem ja sam i mój 10x Product Bootcamp, gdzie ćwiczymy wykorzystanie AI na konkretnym produktowym case study. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

Niedawno stanąłem przed konkretnym wyzwaniem: potrzebowałem dokładnego opisu wszystkich funkcji mojego produktu. Chciałem mieć taki opis jako kontekst dla moich agentów AI, z którymi pracuję nad produktem.

Jakość pracy agenta AI zależy od kontekstu, który mu dasz. Im lepiej rozumie, co produkt realnie robi - każdy moduł, każdą subfunkcję - tym sensowniej pomaga przy prototypowaniu, analizie czy planowaniu rozwoju. A taki kompletny opis trzeba najpierw skądś wziąć.

Mogłem zrobić to ręcznie - przeklikać całą aplikację i spisać funkcję po funkcji. Dzień, może dwa nudnej dłubaniny (tak bym zrobił jeszcze 2 lata temy). Zamiast tego zatrudniłem teraz do tego agenta AI w przeglądarce. Zalogowałem się do produktu, wkleiłem jeden prompt - i agent sam przeszedł przez aplikację, klikał, czytał tooltipy i przygotował szczegółowe opisy modułów, funkcji i przypadków użycia.

Pokazuję krok po kroku, jak to powtórzyć u siebie - z gotowym promptem na końcu. Zaczynamy! 👇

1️⃣ Po co PM-owi taksonomia funkcji produktu?

Ten “dokładny opis”, o którym pisałem we wstępie, ma swoją nazwę: taksonomia funkcji. To mapa Twojego produktu w 3 poziomach:

• Moduł - główny obszar (np. “Analityka”, “Integracje”)

• Funkcja - konkretna wartość dla użytkownika (np. “Dashboardy”)

• Subfunkcja / akcja - szczegół (np. “Eksport dashboardu do PDF”)

Do każdego elementu dochodzi opis. Brzmi jak nudna dokumentacja? Może. Ale taki dokument zarabia na siebie w kilku sytuacjach, w których realnie go używam:

• Kontekst dla agentów AI. To był mój główny powód. Agent pracujący nad produktem - przy prototypowaniu, pisaniu specyfikacji, analizie - jest tak dobry, jak kontekst, który dostanie. Kompletna mapa funkcji to dla niego podstawa do dawania lepszych odpowiedzi.

• Wdrożenie do nowego produktu. Wchodzisz jako nowy PM i w godzinę masz pełen obraz zakresu, zamiast zbierać go tygodniami po standupach.

• Analiza konkurencji. Robisz tę samą mapę dla konkurenta i kładziesz obok swojej. Łatwiej zrobić wtedy porównanie.

• Prototypowanie i planowanie. Masz bazę do tworzenia prototypu swoich pomysłów. Twój agent ma kontekst całego produktu.

• Polowanie na niepotrzebne ficzery. Widzisz czarno na białym, ile funkcji robi to samo albo nie robi nic.

Najlepsze jest to, że agent może obejrzeć produkt oczami użytkownika - chodzi po zalogowanej aplikacji, a nie po pięknym marketingowym opisie na landing pageu. A to często dwa różne produkty (i każdy PM o tym wie 😉).

2️⃣ Wideo: jak zrobiłem to krok po kroku? (7 min)

W nagraniu pokazuję cały proces na żywo - od logowania do gotowego dokumentu. W skrócie wygląda to tak:

• 🛠 Loguję się do produktu w przeglądarce Comet.

• 🤖 Wklejam prompt instruujący agenta, żeby zrobił taksonomię. Agent zaczyna “klikać” po produkcie i budować strukturę funkcji.

• ✨ Agent generuje surową taksonomię - z opisami i przypadkami użycia.

• 📝 Formatuję output - wrzucam dane do Gemini (równie dobrze Claude albo NotebookLM) i robię z tego czytelny dokument.

Efekt końcowy: dokładna mapa modułów, funkcji i subfunkcji - gotowa do wrzucenia agentom AI jako kontekst (albo do analizy konkurencji czy prototypowania, co tam akurat potrzebujesz).

3️⃣ Przeglądarka Comet i jej alternatywy

Ja skorzystałem z przeglądarki Commet. Comet to Inteligentna przeglądarka oparta na silniku Chrome, z wbudowanym asystentem i agentem AI (od Perplexity). Agent AI może nie tylko odpowiadać na pytania, ale też wchodzić w interakcję ze stroną WWW – klikać, przechodzić po stronach, zbierać dane.

Nie musisz używać akurat Comet. Kilka alternatyw do tego samego zadania:

Alternatywy co przeglądarki Comet

• Manus – agent AI działający jako komputer control model.

  • Może automatycznie zakładać konto, przechodzić onboarding, eksplorować produkt.

  • Wymaga podania danych logowania lub użycia tymczasowego maila.

  • Dobre narzędzie do głębszego „user journey”, ale z ograniczeniami (np. reCAPTCHA).

• ChatGPT Agent Mode albo wtyczka Claude do Chrome

  • Wbudowany w ChatGPT tryb, w którym AI uruchamia wirtualną maszynę i działa jak użytkownik komputera. Potrafi wejść na stronę, klikać elementy i eksplorować interfejs. Trzeba przekazać login/hasło albo pozwolić mu zalogować się w VM - co rodzi problem bezpieczeństwa.

  • Alternatywnie - wtyczka np. Claude do Chrome - dzięki czemu najpierw sam się logujesz, a Claude “steruje” przeglądarką.

• Inne przeglądarki eksperymentalne (np. z wbudowanymi AI agentami)

⚠️ Bezpieczeństwo

To największe ryzyko całej zabawy. Dawanie agentowi loginu i hasła do produkcyjnego produktu to proszenie się o kłopoty. Moje zasady:

• Używam narzędzi, gdzie loguję się sam, a agent tylko steruje tym, co widzi (Comet, wtyczka Claude do Chrome). Dane logowania zostają u mnie.

• Nie wklejam produkcyjnych danych dostępowych, których nie kontroluję.

• Jeśli produkt ma wrażliwe dane - robię to na koncie testowym albo w sandboxie.

4️⃣ Gotowy prompt do skopiowania

Poniżej prompt, który wkleiłem agentowi. Podmień [PRODUKT] na nazwę swojego produktu (albo konkurenta) - i tyle.

<rola>
Twoja misja: Zmapuj wszystkie funkcje dostępne dla klienta w docelowym produkcie [PRODUKT] i przygotuj uporządkowaną taksonomię funkcji z jasnymi opisami i przypadkami użycia.

Efekt ma umożliwić pełne zrozumienie zakresu możliwości produktu w sposób, który może być użyty przez Product Managera, zespół UX oraz zespół developerski jako baza wiedzy - bez marketingowych ogólników, w formie dokumentacji produktowej.
</rola>

<cele_wysokiego_poziomu>
Przeanalizuj produkt od A do Z
- przejdź przez wszystkie menu, ustawienia i ścieżki dostępne dla typowego użytkownika.
Zidentyfikuj każdą unikalną funkcję
- zanotuj nazwy, etykiety w UI i lokalizację każdej funkcji w interfejsie.
Stwórz taksonomię funkcji
- uporządkuj możliwości produktu w hierarchii 3-poziomowej:
* Moduł (obszar najwyższego poziomu)
* Funkcja (wartość dla klienta)
* Podfunkcja / Akcja (szczegółowe zadania lub ustawienia)
Opisz i nadaj kontekst
- dla każdej (pod)funkcji przygotuj:
* Jasny, konkretny opis w 2-4 zdaniach, zaczynający się od czasownika w formie czynnej (np. "Twórz...", "Automatyzuj...", "Wizualizuj...").
* Wyjaśnij dlaczego ta funkcja jest ważna i co daje użytkownikowi.
* Kluczowe przypadki użycia w formie punktów, zaczynające się od "Gdy..." lub "Kiedy...".
Przygotuj prostą tabelę przedstawiającą hierarchię modułów i powiązanych funkcji.
</cele_wysokiego_poziomu>

<szczegolowe_instrukcje>
A. Wstępne rozpoznanie
Wejdź na stronę główną -> przeczytaj etykiety nawigacji i treść hero.
Przejrzyj publiczne podstrony: "Funkcje", "Cennik", "Dokumentacja", "Centrum pomocy", "Blog".
Stwórz wstępną listę modułów/funkcji, które się pojawiają.

B. Eksploracja praktyczna (jeśli dostępna wersja próbna/demo)
Przejdź przez proces onboardingu, notując każdy ekran.
Otwórz każdy główny element nawigacji; w każdym z nich kliknij wszystkie zakładki, przyciski i rozwijane menu.
Dla złożonych widżetów (dashboardy, edytory, kreatory) otwórz podpowiedzi, ustawienia i zaawansowane menu.
Po eksploracji każdego modułu od razu zapisz obserwacje, aby nic nie umknęło.

C. Gromadzenie dowodów
* Dla każdej nieoczywistej nazwy funkcji - najedź/kliknij podpowiedź i zanotuj wyjaśnienie.
* Jeśli funkcja odsyła do zewnętrznej strony dokumentacji - otwórz ją i przeczytaj dwa pierwsze akapity, by zrozumieć cel.
* Zrób screenshoty kluczowych ekranów (do użytku prywatnego przy tworzeniu opisów).

D. Czego unikać
* Ignoruj marketingowe hasła - skup się na konkretnych funkcjach dostępnych bezpośrednio dla użytkownika.
* Nie uwzględniaj wewnętrznych narzędzi administracyjnych, jeśli nie są widoczne dla standardowych użytkowników.

E. Kontrola jakości przed zakończeniem
* Każda funkcja musi należeć dokładnie do jednego modułu.
* Opisy muszą być konkretne, mierzalne i pozbawione pustych frazesów.
* Przypadki użycia opisuj językiem klienta ("Kierownik wsparcia..." zamiast "użytkownik").
</szczegolowe_instrukcje>

<format_wyniku>
Zwróć jeden dokument, który zawiera:
* Nazwę produktu
* URL
* Tabelę z kolumnami: Moduł | Funkcja | Podfunkcja/Akcja | Opis | Przypadki użycia
* Wszystkie moduły, funkcje i podfunkcje z opisami i przypadkami użycia

Wzór opisu (mini-template):
[Podfunkcja] - [czasownik + opis co robi + dlaczego ważne]
Przykładowe użycie:
- Gdy...
- Kiedy...
</format_wyniku>

🇬🇧 Wersja angielska promptu

Robisz taksonomię anglojęzycznego produktu? Wersja EN promptu często działa lepiej - agenty AI radzą sobie sprawniej po angielsku przy zadaniach agentowych. Wrzucam ją niżej.

<role>
Your mission: map every customer-facing capability of the target software product [PRODUCT_NAME] and deliver a structured feature-taxonomy with clear descriptions and use-cases.
</role>

<high-level_objectives>
Explore the product end-to-end
- navigate all menus, settings, and flows a typical user can access.
Capture every distinct capability
- note names, UI labels, and where each feature lives in the interface.
Synthesize a feature-taxonomy
- organize capabilities into a 3-tier hierarchy:
* Module (top-level area)
* Feature (customer-valuable function)
* Sub-feature / Action (granular tasks or settings)
Describe & contextualize
- for every (sub-)feature, write:
* Clear 2-4-sentence description (what it does & why it matters)
* Key use-case(s) in bullet form (when a real user would rely on it)
Create a simple table to show the hierarchy of modules and their associated features.
</high-level_objectives>

<detailed_instructions>
A. Initial reconnaissance
Land on the home page -> read nav labels & hero copy.
Crawl public pages: "Features", "Pricing", "Docs", "Help Center", "Blog".
Build an initial list of modules/features mentioned.

B. Hands-on exploration (if trial/demo available)
Create a trial account using the email address I provided.
Complete onboarding flows and note each screen.
Open every primary navigation item; within each, click all tabs, buttons, or expandable menus.
For complex widgets (dashboards, editors, builders) open tooltips, settings, and advanced menus.

C. Evidence capture
* For any non-obvious feature name, hover/click tooltips and note the explanation.
* If a feature references an external doc page, open it and skim the first two paragraphs for intent.

D. Avoid these traps
* Ignore marketing hype; focus on concrete capabilities users can directly access.
* Do not include purely internal admin tools unless visible to standard users.

E. Quality checks before finishing
* Every feature must belong to exactly one module.
* Descriptions should start with an active verb ("Create...", "Automate...", "Visualize...").
* Use-cases use customer language ("A support manager..." not "the user").
</detailed_instructions>

<output_format>
Return one document that includes the following:
* Product Name
* Url
* Table
* Module Name
* Module Description
* All feature names and feature descriptions that tie to that module
* All sub-feature names, descriptions, and use cases
Do that for all Modules and Features
</output_format>

Podsumowanie

Mapowanie produktu ręcznie to godziny klikania i dokument, który dezaktualizuje się po następnym sprincie. Agent AI w przeglądarce robi 80% tej roboty w kilkanaście minut - resztę dograsz sam. A na koniec masz gotowy kontekst, którym karmisz swoje agenty AI przy pracy nad produktem.

Co zrobić po przeczytaniu:

1. Wybierz narzędzie, w którym logujesz się sam (Comet albo wtyczka Claude do Chrome).

2. Odpal prompt na swoim produkcie - i wrzuć gotowy opis agentom jako kontekst (albo po prostu zobacz, jak Twoja aplikacja wygląda “oczami agenta”).

3. Albo od razu na konkurencie - i połóż jego mapę obok swojej. To najszybsza analiza konkurencji, jaką zrobisz w tym tygodniu.

A potem najważniejsze: zweryfikuj output z produktem otwartym obok. AI ma Ci oszczędzać czas, nie zastępować Twojej głowy.

Dasz znać, jak Wam poszło? Odpisz na tego maila albo rzuć w komentarzu - ciekaw jestem, do czego pierwszego użyjecie tej mapy: agentów czy podejrzenia konkurencji. 👋

✅ Co z tym możesz zrobić w tym tygodniu?

Jeśli z tego newslettera masz wynieść jedną rzecz:

👉 Weź swój własny produkt i puść po nim dowolnego agenta w przeglądarce. To dosłownie kilkanaście minut.

1. Wybierz narzędzie, w którym logujesz się sam - Comet albo wtyczka Claude do Chrome.

2. Zaloguj się do swojego produktu - jeśli masz wrażliwe dane, zrób to na koncie testowym.

3. Wklej prompt z sekcji 4️⃣, podmień [PRODUKT] na nazwę i puść agenta - niech sam przejdzie po aplikacji.

4. Sformatuj output (Claude / Gemini / NotebookLM) i wrzuć gotową mapę swoim agentom jako kontekst.

Daj znać w komentarzu, jak u Ciebie zadziałało i ile Twój produkt ma realnie funkcji 👇

Przegryzłem się przez te dane, żeby wyciągnąć to, co najważniejsze dla nas - jak wygląda rynek pracy dla product managerów i zespołów produktowych. No i nie mogłem się jak zawsze powstrzymać by dorzucić kilka słów komentarza z moją prywatną 🇵🇱 perspektywą ;)

• 1️⃣ Ofert dla PM-ów jest najwięcej od 3 lat

• 2️⃣ Rośnie liczba… rekruterów (i to dobre info)

• 3️⃣ Dobrze jest być AI PMem

• 4️⃣ Praca zdalna - koniec wzrostów

• 5️⃣ Big tech wcale nie zwalniają połowy ludzi

• 🔗 Pełne wyniki ankiety

👉 Partnerem dzisiejszego wydania… jestem ja sam i mój 10x Product Bootcamp, gdzie ćwiczymy wykorzystanie AI na konkretnym produktowym case study. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

Subscribe now

1️⃣ Ofert dla PM-ów jest najwięcej od 3 lat

Jest ponad 7 300 otwartych ról dla product managerów w firmach tech na świecie i trend wciąż rośnie. To 75% powyżej dołka z początku 2023 i prawie 20% w górę od początku tego roku. Najwięcej od 2022.

• Brzmi super z globalnej perspektywy - ale tu muszę uczciwie powiedzieć: osobiście w Polsce jeszcze tego nie widzę.

• na razie obserwuję raczej drugą stronę medalu - sporo zwolnień z większych organizacji. Atlassian, Dynatrace - i to nie są małe cięcia. Jak ktoś szuka teraz roboty na polskim rynku, to wie, o czym mówię.

• Więc traktowałbym te 7 300 ofert jako sygnał wyprzedzający, a nie opis polskiej rzeczywistości na dziś. USA ma swój cykl, my zwykle dostajemy odbicie z opóźnieniem. Pytanie tylko - z jak dużym.

Przy okazji - w raporcie są gorsze wieści dla designerów. W połowie 2023 było więcej otwartych ról dla designerów niż dla PM-ów. Dziś jest odwrotnie - i różnica rośnie. PM popyt wyprzedza design już 1.27x. Brzmi niepokojąco dla UXów i klasycznych Product Trio.

2️⃣ Rośnie liczba… rekruterów (i to dobre info)

To moim zdaniem jeden z najciekawszych (i najbardziej optymistycznych) punktów całego raportu. Lenny zwraca uwagę, że liczba otwartych ról dla rekruterów tech wróciła prawie do szczytu z 2022.

• Dlaczego to ważne? Bo rekrutacja to rola, która kurczy się i rośnie razem z zatrudnianiem. Nikt nie zatrudnia armii rekruterów „żeby zwalniać”. Jak firmy zaczynają szukać rekruterów, to znaczy, że szykują się do realnego zatrudniania.

• To bardzo dobry sygnał - zatrudnienie najprawdopodobniej będzie rosło. Wzrost popytu na rekruterów zwykle wyprzedza falę ofert dla PM-ów.

Trzymam kciuki, że ta logika przeleje się też na nasz rynek.

3️⃣ Dobrze jest być AI PMem

Tu nie ma wzrostu - tylko jak by powiedział rasowy PM - wykres pokojowy sygnalizujący doskonały Product-Market FIT :D. Popyt na AI engineerów i AI PM-ów idzie mocno w górę.

Wygląda na to, że dobrą specjalizację wybrałem 8 lat temu 😅 (pozdrawiam SentiOne i pierwsze produkty AI, kiedy „AI PM" brzmiało jak buzzword z przyszłości).

Ale w Polsce bym tu trochę ostudził jeszcze emocje - bo… mało kto u nas buduje produkty z AI na poważnie. Widać to nawet po najważniejszych konferencjach produktowych w PL w których miałem okazję uczesgntoiczyć w ostatnich miesiącach.

• Cała masa wystąpień „jak PM ma używać AI” (czyli o produktywności).

• A praktycznie zero o budowaniu produktów AI - o evalach, o promptach jako warstwie produktu, o pracy z modelami, o tym, jak ogarniać niedeterministyczność.

• To pokazuje, gdzie naprawdę jesteśmy. Uczymy się używać AI jako narzędzia, a dopiero raczkujemy w byciu PM-em, który buduje AI.

Ale to się będzie zmieniać - i to szybciej, niż się wielu wydaje. Jak dla mnie to jeden z najlepszych kierunków, w jaki PM może dziś inwestować swoje kompetencje.

4️⃣ Praca zdalna - koniec wzrostów

Pamiętacie przewidywania, że teraz już każda firma przejdzie na pełny remote, a biurowce za chwile będą wyburzane?

No więc… chyba przedwcześnie biura zostały uśmiercone.

Dziś tylko 25% ofert PM ma opcję zdalną (na szczycie w 2022 było 35%). Spadek o jakieś 20-25% względem peaku w każdej z ról.

U nas widać to samo, tylko w polskim wydaniu: przejście do hybrydy w wielu dużych firmach. Nie pełny powrót do biura, nie pełen remote - złoty (albo zgniły) kompromis.

A ja akurat bardzo lubię pracę z biura, więc… mówiąc wprost - mnie ten trend osobiście nie martwi 😉. Ale rozumiem, że dla wielu osób to była jedna z ważniejszych zdobyczy ostatnich lat i jej kurczenie się trochę boli.

5️⃣ Big tech wcale nie zwalniają połowy ludzi

To ważny punkt - bo idzie pod prąd nagłówkom z LinkedIn.

Narracja jest taka: „Pogromy w big techach! zwolniły masę ludzi i zastąpiły ich AI”. A dane mówią trochę coś innego. Headcount w większości dużych firm tech jest płaski albo lekko rośnie względem zeszłego roku - mimo zwolnień, o których czytamy.

Co się więc realnie stało? Firmy po prostu przestały zatrudniać na potęgę i dalej lekko rosną. Czyli mniej więcej tak, jak powinno wyglądać normalne, zdrowe tempo - po szaleństwie z lat 2021-2022.

Ale dorzucę też od własne zastrzeżenie: nie jestem przekonany, że ten trend musi się utrzymać.

• Pytanie brzmi: jak mocno ten rynek jest jeszcze w stanie rosnąć? Bo cały ten optymizm zakłada, że popyt będzie dalej napędzał zatrudnianie (nawet z AI).

• Pytanie czy userzy w końcu nie przestaną mieć mieć na to wszystko pieniądze.

• Wystarczy jeden mocniejszy makro-zgrzyt i ta „płaska, lekko rosnąca” linia potrafi się szybko przełamać.

Więc tak - jest dobrze i jest powód do optymizmu. Ale tej optymistycznej narracji nie brałbym jak pewnika na najbliższe lata.

🔗 Pełne wyniki

To tylko mój wycinek przez pryzmat PMowego głównie świeta. Pełne wyniki researchu u Lennego zawierają oczywiście dużo więcej danych - design (który stoi w miejscu), rosnące znaczenie Bay Area, dane o zwolnieniach i mnóstwo wykresów dla wszystkich ról:

Lenny's Newsletter

State of the product job market in early 2026

👋 Hey there, I’m Lenny. Each week, I answer reader questions about building product, driving growth, and accelerating your career. For more: Lenny’s Podcast | Lennybot | How I AI | My favorite AI/PM courses, public speaking course, and interview prep copilot…

Read more

3 months ago · 405 likes · 9 comments · Lenny Rachitsky

Polecam subskrypcję jego newslettera - naprawdę warto. Tu mój reflink do subskrypcji (nic z niego nie mam, ale fajnie być w TOP 10 :D)

ElevenLabs pokazał ten model na swoim warszawskim Summit, tego podejścia aktywnie używają tego OpenAI, Palantir, Anthropic, a temat w Polsce promuje jeszcze Tomek Karwatka z Open Mercato.

Czytałem to z dziwnym poczuciem déjà vu.

6 lat temu zderzyliśmy się z tym w SentiOne i w bojach wypracowywaliśmy tę rolę - nie wiedzieliśmy tylko, że to tak się nazywa. Sam pełniłem właściwie taką funkcję. Dlatego dzisiaj rozłożymy ja na czynniki pierwsze i podzielę się tym, czego się wtedy nauczyłem.

W dzisiejszym wydaniu:

1. Czym jest Forward Deployed Engineer?

2. Dlaczego to ważne? Przecież nie buduję nowego ElevenLabs / OpenAI

3. Moja historia z SentiOne, gdy zajmowałem się FDE zanim miało nazwę

4. Co to oznacza dla produktu?

5. Pułapka we wdrożeniu FDE

Subscribe now

1. Czym jest Forward Deployed Engineer?

Zacznijmy od podstaw - bo dopiero niedawno trend stał się popularny i większość osób w Polsce jeszcze tego terminu nie spotkała.

Forward Deployed Engineer (FDE) to rola, która pochodzi z Palantira. Prosta koncepcja, ale zrewolucjonizowała sposób wdrażania produktów w B2B.

• Klasyczne wdrożenie wygląda tak: firma kupuje produkt, dostaje dokumentację, dział IT klienta wdraża, konsultanci robią kilka sesji szkoleniowych. I wszyscy mają nadzieję, że “jakoś zadziała”.

• FDE działa inaczej - inżynier jedzie do klienta i wdraża rozwiązanie na miejscu. Nie wysyła dokumentacji. Nie robi handoffu do działu IT. Jest tam - rozumie kontekst biznesowy, procesy, ludzi, ograniczenia. I dowozi działający system w strukturze klienta.

Role FDE różnią się w zależności od firmy (niektóre kładą większy nacisk na wsparcie sprzedaży, inne na rozwijanie produktu), ale zazwyczaj opierają się na 5 filarach:

1. Solidne inżynierskie fundamenty

2. Współpraca ze sprzedażą w domykaniu kontraktów - Wielu FDE aktywnie pomaga w pozyskaniu klienta. To połączenie produktu z Go-To-Market.

3. Praca bezpośrednio w zespole klienta: Często FDE “osadza się” (embed) u klienta, żeby dobrze zrozumieć jego domenę. W Palantirze to około 25% czasu pracy (onsite), w innych organizacjach nawet 50%.

4. Wpływ na główny produkt (core): FDE podejmuje też kluczowe decyzje o priorytetach: kiedy budować coś specjalnie pod danego klienta, a kiedy zainwestować te siły w rozwój bazowego produktu firmy. Często FDE są bezpośrednio zintegrowani z głównymi zespołami inżynieryjnymi.

5. Obsesja na punkcie sukcesu klienta: Prawdziwym celem nie jest wdrożenie samo w sobie, ale znalezienie najwyżej wycenianego problemu klienta i upewnienie się, że nasze rozwiązanie go likwiduje.

FDE ma już nawet swoją stronę na Wikipedii.

1.1. Co robi FDE?

The Pragmatic Engineer przeanalizował rolę FDE i zapytał FDE jak wygląda ich typowy tydzień. Poniżej cytat świetnie oddający istotę tej roli:

„Większość tygodni spędzam pracując kilka dni w siedzibie klienta. Część tego czasu to spotkania z interesariuszami technicznymi lub biznesowymi, a reszta to monitorowanie, debugowanie, wdrażanie lub konfigurowanie naszego oprogramowania dla tego klienta.

Po powrocie do biura spędzam czas na pisaniu drobnych zmian w kodzie, robieniu code review i badaniu lub planowaniu rozwiązań dla klientów.

Pozostały czas przeznaczam na komunikację z naszymi wewnętrznymi zespołami wsparcia i rozwoju produktu”.

Ogólnie rzecz biorąc, typowy tydzień FDE to mieszanka:

1. Pracy projektowo-wdrożeniowe dla klienta: to absolutny priorytet.

2. Ulepszania produktu: kiedy główna platforma ogranicza budowanie funkcjonalności dla klienta, FDE np. konfigurują nowe modele danych, wprowadzają poprawki stabilności lub dodają rozwiązania (commitują fixy) prosto do rdzenia systemu.

3. Zadań wewnętrznych: bieżąca komunikacja, maile, spotkania, daily, wymienianie się wiedzą i współdzielenie projektów.

1.2. Podejście ElevenLabs

W modelu wykorzystującym FDE działa z sukcesami polski unicorn – ElevenLabs. Pokazała go 1 września na swoim ElevenLabs Summit w bardzo konkretnej formie (tzw. Double Loop).

Zamiast klasycznego, liniowego “głuchego telefonu” (gdzie Produkt tworzy rozwiązanie, Sprzedaż je handluje, a dział IT klienta próbuje je jakoś wdrożyć), ElevenLabs stawia FDE dokładnie w centrum dwóch kluczowych obiegów informacji:

• Pętla lewa: Research & Product → FDE → dane wracają do Research & Product.

  • Główny zespół badawczo-produktowy buduje rdzeń systemu, modele AI i udostępnia zaawansowane API.

  • FDE bierze ten rdzeń i wynosi go “na zewnątrz”.

  • Co jednak najważniejsze – pętla ta działa w dwie strony. FDE nieustannie wraca do zespołu produktowego / researchu z twardymi danymi o tym, jak technologia zachowuje się w starciu ze środowiskami produkcyjnymi.

  • Dzięki temu Product Managerowie nie muszą zgadywać, co budować. Ich backlog zasilają prawdziwe problemy napotkane podczas gigantycznych wdrożeń u klientów.

• Pętla prawa: FDE wdraża u klienta → feedback od klientów wraca do FDE.

  • FDE wchodzi “w teren” i wdraża rozwiązanie bezpośrednio w infrastrukturze firmy kupującej produkt.

  • Zamiast czekać tygodniami na raporty od supportu, inżynier na żywo zbiera feedback od użytkowników końcowych i interesariuszy biznesowych.

  • Jeśli integracja wymaga napisania niestandardowego kodu (np. specyficznego konektora do archaicznego systemu klienta), FDE pisze go na miejscu. Pętla zamyka się natychmiastowo.

Kluczowe tu jest to, że FDE siedzi wewnątrz organizacji klienta. Jest najaktywniejszym punktem styku między tym, co powstaje w R&D, a tym, z czym fizycznie mierzy się organizacja klienta.

Eliminuje to nieporozumienia na linii “nietechniczna sprzedaż – bardzo techniczny produkt” i drastycznie przyspiesza dowożenie wartości.

2. Dlaczego to ważne? Przecież nie buduję nowego ElevenLabs / OpenAI

Trend jest bardzo mocny, bardzo mocno tez rośnie w bańce najszybciej rozwijających się firm AI:

• OpenAI buduje własne zespoły FDE.

• Anthropic robi to samo.

• SAP, Cognizant, ServiceNow idą w tym kierunku.

Możesz pomyśleć: “Okej, Palantir, OpenAI, Anthropic – to giganci z Doliny Krzemowej. Jak to się ma do mojej pracy w Polsce?”.

Ma się bardzo konkretnie. Podejście FDE to odpowiedź na problem, z którym jako produktowiec mierzysz się na co dzień:

2.1. To dotyczy każdego złożonego produktu B2B

• Jeśli budujesz produkt B2B, który wymaga integracji, zmiany procesów u klienta lub dostosowania do jego specyfiki, masz ten sam problem.

• Ile razy twój produkt nie dowiózł biznesowej wartości, bo klient “źle go wdrożył”, “nie czytał dokumentacji API” albo “nie zrozumiał, jak z niego korzystać”?

• Klasyczny proces – gdzie sprzedaż obiecuje złote góry, produkt dowozi ficzery, a wsparcie IT klienta zostaje samo z instrukcją – w skomplikowanym B2B po prostu przestaje działać.

2.2. Produkty AI drastycznie przyspieszyły ten trend

• Dlaczego o FDE mówi się teraz tak głośno? Bo w przypadku wykorzystania sztucznej inteligencji trudność wdrożenia i zrozumienia klienta wystrzeliła w kosmos.

• W tradycyjnym SaaS-ie klient musiał nauczyć się klikać w nowy interfejs. W produktach AI – klient musi często zmienić całą filozofię swojej pracy.

• Pomiędzy „kupiliśmy dostęp do AI” a „AI realnie rozwiązuje nasze problemy i daje ROI” mamy gigantyczną przepaść. Wdrożenie tak skomplikowanej i niedeterministycznej technologii wymaga kogoś, który wejdzie głęboko w biznes klienta, zrozumie jego ograniczenia.

Tomasz Karwatka, który mocno działa w produktach B2B dla dużych graczy - podsumował to tak:

Produkty AI w Enterprise to nie jest problem software’owy. To problem wdrożeniowy.

Przepaść między “kupiliśmy dostęp do AI” a “AI realnie nam pomaga” ma niewiele wspólnego z samą technologią. To kwestia kontekstu, integracji, procesów, governance i odpowiedzialności za wynik.

2.3. Mid-market też w to wchodzi

Zaczynają to zauważać nie tylko firmy sprzedające kontrakty za dziesiątki milionów dolarów. Organizacje celujące w średni rynek (mid-market) – jak ClickUp, Webflow, Lindy.ai, Clay czy Zapier – również z sukcesem sięgają po ten model.

Największym wyzwaniem dla mid-marketu są jednak koszty. Budowanie potężnego, wewnętrznego zespołu FDE(jak robi to Palantir) jest dla nich po prostu za drogie. Dlatego firmy te znalazły świetny hack: mocno stawiają na programy partnerskie z wyspecjalizowanymi agencjami wdrożeniowymi.

• Zewnętrzne agencje i eksperci pełnią tam de facto rolę zewnętrznych, wynajętych FDE. Biorą na siebie ciężar zrozumienia biznesu klienta, zintegrowania u niego produktu i wzięcia odpowiedzialności za biznesowy wynik.

• Z kolei do samego twórcy SaaS-a (np. Zapiera) odesłany zostaje potężny, przyspieszony *feedback loop* z rynku. To idealna alternatywa, która pozwala na luksusowe wdrożenia u klientów bez przepalania budżetu własnego działu R&D.

3. Zajmowałem się FDE zanim miało nazwę

Od 2018 roku budowaliśmy SentiOne Automate - platformę do tworzenia botów automatyzujących obsługę klienta (głosową i tekstową). Nie był to wrapper na Open AI, ale własne modele, własny research AI. Doszliśmy z tym do 6,5 mln PLN ARR.

Mieliśmy dwie wersje produktu: klasyczny SaaS oraz potężne wdrożenia on-premise dla Enterprise. I zderzyliśmy się z problemami, które FDE potrafi rozwiązywać:

3.1. Problemy wdrożeń produktów AI

Pierwotnie zakładaliśmy klasyczne podejście B2B: klient kupuje, my pomagamy stworzyć pierwszą wersję bota, po czym klient przejmuje produkt i rozwija go sam, posiłkując się naszą dokumentacją.

• Przy pierwszym wdrożeniu dla ogromnego banku boleśnie zderzyliśmy się z murem. I nie były to problemy techniczne. Klient kompletnie nie rozumiał niedeterminizmu AI. Przychodzili do nas z żądaniem: “Bot się wczoraj pomylił w tej jednej rozmowie, naprawcie to”. Z ich perspektywy, skoro to “błąd” w sofcie, to da się go usunąć.

• Tylko że sztuczna inteligencja to nie jest normalny software. Przy obsługiwaniu setek tysięcy rozmów miesięcznie, statystycznie bot zawsze gdzieś się pomyli. To natura modeli probabilistycznych, a nie bug.

• Samo wytłumaczenie klientowi tej koncepcji i zmuszenie go do przebudowania procesów biznesowych (np. wprowadzenia weryfikacji *human-in-the-loop*) zajmowały nam miesiące.

3.2. Zrozumienie technologii i narodziny Double Loop

Szybko zderzyliśmy się z faktem, że takie wdrożenia miały gigantyczne problemy, jeśli po obu stronach przypisana do nich osoba była mało techniczna i nie chciała wejść naprawdę w głąb naszego produktu. Większa szansa na biznesowy sukces pojawiała się dopiero wtedy, kiedy wdrożeniowiec miał pełne, głębokie zrozumienie technologii pod maską.

Dlatego na początku drogi naszego produktu - poniekąd sam wszedłem w rolę takiego wdrożeniowca dla największych klientów Enterprise. Tylko nie nazywaliśmy tego wtedy Forward Deployed Engineer.

Dzięki temu doświadczyłem siły obu pętli, które przedstawił model ElevenLabs na własnej skórze:

• Z jednej strony pracowałem bezpośrednio z klientem, “osadzałem się” w jego środowisku, zderzałem się z realiami jego biznesu i tłumaczyłem mu koncepcje sztucznej inteligencji (pętla prawa).

• Z drugiej strony natychmiast wracałem z twardym, bardzo technicznym feedbackiem prosto do naszego zespołu badawczego i inżynierów z R&D, bezpośrednio wpływając na to, jak rzeźbimy rdzeń całego systemu (pętla lewa).

Nie nazywaliśmy nas wtedy Forward Deployed Engineers. Byliśmy taką dziwną hybrydą produktu, inżynierii i konsultingu. Ale patrząc na to z dzisiejszej perspektywy, to był czysty FDE i główny powód naszych pierwszych sukcesów komercyjnych.

3.3. Skalowanie

Dopóki cała ta wiedza i specyficzny typ pracy pozostawały bezpośrednio w zespole produktowym – nasza podwójna pętla działała doskonale, dając dokładnie ten sam obieg informacji, którym dzisiaj chwali się ElevenLabs.

Jednak przy skalowaniu konieczne i całkowicie naturalne było wydzielenie ostatecznie osobnego, dedykowanego zespołu wdrożeniowego. Na początku mieliśmy z nim potężne problemy. Naiwnie wierzyliśmy, że ten nowy dział można zbudować klasycznie: Sales sprzedaje, a Project Manager “zarządza wdrożeniem”.

Nasze obserwacje brutalnie to zweryfikowały. Kiedy przypisana do wdrożenia osoba była mało techniczna i nie chciała wejść głęboko pod maskę naszego produktu, projekt po prostu stawał w miejscu. Czysty “project management” i pilnowanie harmonogramu przy wdrażaniu AI absolutnie nie działały.

Co ciekawe, nie każdy inżynier chciał rozmawiać z klientem. Nie każdy PM był wystarczająco techniczny, żeby działać przy wdrożeniu.

Zaczęło to lepiej działać dopiero po czasie, gdy zmieniliśmy profil zatrudnianych tam ludzi. Najlepiej sprawdzały się osoby, które nie miały silnej tożsamości zawodowej do obrony - “trochę inżynier, trochę product, trochę research”. Takie osoby naturalnie żyły na przecięciu i były ciekawe obu stron.

4. Co to oznacza dla produktu?

Coraz bardziej “Shipped” nie znaczy “done”.

Jako PM-owie jesteśmy wytrenowani do myślenia w cyklach: zdefiniuj problem → zbuilduj rozwiązanie → wydaj → zmierz → iteruj. Ale w tym modelu jest ukryte założenie: że kiedy wysyłamy feature lub produkt, klient jakoś sobie z nim poradzi.

W SaaS B2C to często prawda. W produktach B2B, szczególnie gdy coraz więcej jest w nich AI - NIEKONIECZNIE.

Rozjazd między “wdrożyliśmy” a “klient realnie korzysta” jest często większy niż cały czas który poświęciłeś na budowanie. I ta przepaść to nie jest problem inżynierski. To problem produktowy.

Kilka pytań, które warto sobie zadać 👇

• Czy twój produkt ma mechanizm zbierania feedbacku z “dziedzińca klienta”? Nie z ankiet po onboardingu - z realnego użycia, z problemów które pojawiają się miesiąc po wdrożeniu.

• Kto w twoim teamie jest odpowiedzialny za to, co dzieje się PO wysyłce? Jeśli odpowiedź brzmi “customer success” i nie rozmawiasz z nimi regularnie - masz lukę.

• Czy rozumiesz kontekst operacyjny klienta? Nie jego wymagania z RFP. Jak naprawdę działa jego organizacja, kto faktycznie używa produktu, jakie ma ograniczenia.

5. Pułapka we wdrożeniu FDE

Na koniec, nie byłbym sobą, gdyby wrzucił niepopularnego gorącego kartofelka ;)

Większość firm, które teraz kopiują model FDE, zbuduje pustą pętlę.

Spójrz jeszcze raz na diagram ElevenLabs. Działa, bo po lewej stronie jest prawdziwy R&D - własne praca nad AI, własne badania, prawdziwy silnik który może przetworzyć feedback z wdrożeń. Dane zbierane przez FDE mają gdzie trafić.

ElevenLabs ma tę platformę. Palantir ma tę platformę. My w SentiOne też to mieliśmy - feedback z wdrożeń wracał do zespołu produktowego i R&D.

Firma która buduje tylko wrapper na GPT, nie pracuje aktywnie nad AI, nie wykonuje produktowej pracy i zbuduje zespół FDE… - co robi z tym feedbackiem? Prawdopodobnie nic. Będą mieli tylko prawą część pętlu.

“Copy the embedded-engineer part without the real platform underneath and you get a pile of bespoke deployments nobody can maintain.” - a16z

6. Podsumowanie

Można powiedzieć, ze FDE to kolejna modena nazwa na to samo. Trochę na pewno tak - tylko chodzi o to, żeby rzeczywiście pracować z mindsetem, ze klienci potrzebuję aktywnego wsparcia przy wdrożeniu Twojego produktu. Bo bez tego, każdy bardziej złożony produkt B2B będzie miał duże problemy.

Trzy rzeczy do zabrania z tego wydania 👇

• ✅ Shipped ≠ done. Twoja odpowiedzialność jako PM-a nie kończy się na release. Szczególnie jeśli budujesz produkt dla enterprise.

• ✅ Problem wdrożeniowy to Twój problem produktowy. Nie customer success, nie inżynierów. Twój - jak sprawić żeby ludzie realnie korzystali z tego co zbudowałeś.

• ✅ Zanim zaczniecie kopiować model FDE - sprawdź czy masz pętlę zwrotną. FDE bez silnika który przetworzy feedback to koszt bez wartości.

Mi ta koncepcja uświadomiła, że to co robiliśmy w SentiOne - to nie był przypadek.

Brzmi znajomo? No właśnie.

W tym odcinku Dodanego do Backlogu startujemy z nowym formatem - bierzemy cztery takie hot take’i i zderzamy je z tym, co faktycznie widzimy w swoich organizacjach. Spoiler: nie zgadzamy się ze sobą równie często, co z influencerami👇

→ Słuchaj na Spotify

lub Apple Podcast.

• czy ⁠roadmapy umierają? czy małe zespoły z OKR-ami zastąpią długoterminowe planowanie?

• większość PMów nie przetrwa AI - czystka czy hype napędzany strachem?

• determinizm AI stanie się głównym wyróżnikiem produktów - kto okiełzna nieprzewidywalność, wygra

• ⁠liderzy produktu wracają do bycia IC - czy zarządzanie bez kontrybuowania ma jeszcze sens?

Z odcinka dowiesz się:

• (02:13) - Hot take #1: Śmierć roadmap - CPO Slacka ogłosił koniec długoterminowego planowania, zastępując je małymi cross-funkcjonalnymi zespołami z OKR-ami. Czy to kolejny Spotify model, który wszyscy będą naśladować - albo który porzucą po roku?

• (08:30) - Jak roadmapy wyglądają w praktyce naszych organizacji - i dlaczego różnica między “nie mamy roadmapy” a “mamy roadmapę na rok” jest mniejsza niż myślisz

• (19:29) - Hot take #2: Większość PM-ów nie przetrwa AI - czy grozi nam wielka czystka backlog managerów, czy to tylko hype napędzany strachem, który sprzedaje kursy produktowe?

• (27:00) - Czy AI to multiplier dla PM-ów czy wymówka do zwolnień - jak lay-offy przez AI wyglądają od środka i co tak naprawdę jest ich przyczyną

• (35:57) - Hot take #3: Determinizm stanie się głównym wyróżnikiem produktów AI - kto okiełzna nieprzewidywalność LLM-ów, wygra rynek. Jak to się ma do tego, co budujemy dziś?

• (46:33) - Hot take #4: Elena Varna, była head of growth w Amplitude, Miro i Dropboxie, wróciła do roli IC - i mówi, że to jest przyszłość managerów. Coraz mniej liderów zarządzających ludźmi, coraz więcej super-indywidualnych kontrybutorów

• (53:00) - Czy organizacja stanie się softwarem? Wojtek stawia tezę, że people managerowie nie znikną - tylko staną się orkiestratorami opisującymi firmę kodem zamiast rozmowami

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

1. PM ma unikalny profil ryzyka psychicznego. I nie chodzi o “stres w pracy”. Accountability without authority - odpowiadasz za produkt, revenue, OKR-y, a nie masz formalnej władzy nad nikim. Inżynierowie raportują do CTO, designerzy do head of design. Ty każdego dnia przekonujesz wszystkich do wszystkiego. To nie jest normalne napięcie. To się kumuluje - i ma swoją nazwę w psychologii: ciężar emocjonalny.

2. Sandwich pressure wykańcza nie gorzej niż praca w call center. Z góry lecą pytania “czemu tak wolno shipujecie?”, z dołu “czemu ciągle zmieniacie scope?”. Ty jesteś buforem. A bufory się zużywają. Badania pokazują, że pracownicy obsługi klienta - którzy muszą codziennie odbierać czyjąś frustrację i oddawać uśmiech - mają największe problemy z kontrolą emocji. PM w sandwich pressure działa dokładnie tak samo.

3. Impostor syndrome u PM-ów jest na sterydach - i AI go nakręca. Musisz rozmawiać z inżynierami o architekturze, z biznesem o revenue, z data scientistami o metrykach, z designerami o UX. Nigdzie nie jesteś ekspertem. W kulturach nagradzających pewność siebie przyznanie się do “nie wiem” kosztuje ogromnie dużo energii. A AI dokłada do tego AI anxiety - poczucie, że pociąg odjeżdża i nie zdążysz wskoczyć.

4. Traktuj swój well-being jak produkt. PM-owie są ekspertami od rozwiązywania problemów innych - i nagminnie ignorują własne sygnały. Przepis jest prosty: zmierz stan wyjściowy, zdefiniuj konkretny problem, przetestuj rozwiązanie, zmierz ponownie, iteruj. Dokładnie ten sam framework, którego używasz przy produkcie. Ty też możesz być single point of failure.

5. Peer support to nie “miękkie HR-owe rzeczy” - to realna interwencja. Gadaj z innymi PM-ami. Nie żeby rozwiązywać problem, żeby go znormalizować. Usłyszenie od kogoś “mnie też to dotknęło, to jest naprawdę trudne” robi robotę, której żaden framework nie zrobi. Piątkowa kawa z PM-ami, na której wylewacie żale - to jest kozetka u terapeuty. I działa.

6. Porażki niech będą porażkami - przestań szukać happy endu. Fuck Up Nights to świetna technika - ale tylko jeśli nie kończysz każdej historii morałem “i właśnie dzięki temu odnieśliśmy sukces”. Większość porażek nie ma happy endu. Są po prostu porażkami. Normalizowanie tego - bez obowiązku przekucia w lekcję - buduje odporność psychiczną lepiej niż jakikolwiek kurs produktowy.

7. Siła psychiczna to przewaga konkurencyjna - mierzalna w złotówkach. Firma z tysiącem pracowników korzystających z platformy wsparcia psychicznego odzyskuje 0,8 dnia pracy miesięcznie per osoba. W skali roku to równowartość 36 dodatkowych etatów. Wypalona organizacja rosnąca w 40% rocznie to predyktor przyszłego kolapsu - nie sukcesu. Zdrowie psychiczne zespołu to nie koszt. To inwestycja z mierzalnym ROI.

Ostatnio “zatrudniłem” 10 użytkowników do badania. Żaden z nich nie istnieje.

Dziś o syntetycznych użytkownikach: agentach AI, które udają Twoich userów. Pokażę Ci, gdzie to może zadziałać, gdzie jestem sceptyczny, i jak sam użyłem syntetycznych użytkowników w swoim produkcie 👇

👉 Partnerem dzisiejszego wydania… jestem ja sam i mój 10x Product Bootcamp, gdzie ćwiczymy wykorzystanie AI na konkretnym produktowym case study. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

Subscribe now

Co zobaczysz na nagraniu?

1. Czym są syntetyczni użytkownicy i jak działają (w pigułce)

2. Jak wygląda “wynajęcie” agentów do wywiadów i testów użyteczności?

3. Mój realny test Product Academy w Reforge Build - od persony, przez zadania, po wynik

4. Raport z insightami (krytyczne / medium / low) + replay sesji agenta na mobilu

5. Alternatywa - jak puścić agenta po stronie z poziomu Claude w Chrome

ℹ️ Czym są syntetyczni użytkownicy

Idea jest banalnie prosta: zamiast badać prawdziwych użytkowników, tworzysz agenta AI, który ich symuluje.

Dajesz LLM-owi informacje o tym, kim jest Twój user - personę, sposób zachowania, kontekst - a agent zaczyna odwzorowywać tę osobę w trakcie badania. Zamiast rekrutować 10 osób na wywiad, “zatrudniasz” 10 agentów.

Koncepcji zastosowania są co najmniej dwie:

• Wywiady - prowadzisz research z syntetycznymi użytkownikami zamiast z prawdziwymi

• Testy użyteczności - syntetyczni użytkownicy chodzą po Twoim produkcie i wyłapują problemy

I tu jest kluczowa różnica - bo moje doświadczenie z tymi dwoma podejściami jest zupełnie inne.

1️⃣ Wywiady z syntetykami

Pierwsza rzecz, która przychodzi do głowy: użyć agentów jako respondentów w badaniach jakościowych. Zamiast rekrutować uczestników - pytasz agenty.

• Masz do tego gotowe narzędzia, np. syntheticusers.com. Logujesz się, definiujesz kim jest Twój user, ilu chcesz respondentów - i prowadzisz wywiady.

• Alternatywą jest samodzielne stworzenie projektu w swoim asystencie AI, gdzie w instrukcjach opisujesz personę i prosisz, żeby odpowiadał jak ten użytkownik.

I tu powiem wprost: jestem sceptyczny.

Wywiad robimy po to, żeby zejść głęboko - zrozumieć prawdziwe “dlaczego” za zachowaniem użytkownika. A LLM bazuje na danych historycznych. Zachowania userów się zmieniają, a Ty nie masz gwarancji, że syntetyk odpowie tak, jak prawdziwy człowiek w konkretnym kontekście swojego życia.

Nie jestem w tym sceptycyzmie sam. Cała filozofia continuous discovery Teresy Torres stoi na regularnym, cotygodniowym kontakcie z prawdziwymi klientami - bo to z nich wyciągasz insighty, których nie ma w żadnych danych historycznych. Trudno to podmienić na agenta i udawać, że nic się nie zgubiło.

Ale jedno ćwiczenie otworzyło mi głowę

Porównywałem kiedyś wyniki researchu z prawdziwymi użytkownikami z wynikami od syntetyków (podczas szkolenia). I co ciekawe - większość problemów wyłapały obie grupy. Tyle że kolejność ważności była już inna. Syntetycy trafiali w problemy, ale nie zawsze wiedzieli, który z nich boli najbardziej.

Może to wystarczyć do wysokopoziomowego mapowania potrzeb. Do głębokiego discovery już bym na tym nie polegał.

2️⃣ Testy użyteczności

To jest zastosowanie, które realnie u siebie stosuję.

Zamiast rozmawiać z syntetycznym użytkownikiem, wpuszczasz go na swoją stronę lub prototyp. Dajesz konkretne zadania, agent przechodzi przez produkt i zwraca feedback - co działało, co nie, gdzie utknął.

Na wideo pokazuję to na Reforge Build (narzędziu do budowania i testowania prototypów, ostatnio przejęte przez Miro). Ma wbudowaną opcję testów z syntetykami - użyłem jej na stronie Product Academy.

W takim narzędziu definiujesz 3 rzeczy:

1. Zadania dla użytkowników - co mają zrobić na stronie. Ja poprosiłem o:

• eksplorację strony i przejrzenie oferty

• sprawdzenie, czy są w stanie się zapisać, jeśli coś ich zainteresuje

• ogólny przegląd użytecznościowy - czy wszystko działa

2. Urządzenia - desktop, mobile, tablet. Testuj minimum dwa.

3. Persona - kim jest Twój syntetyk. Ja zdefiniowałem prosto: nowy user, który właśnie usłyszał o Product Academy na konferencji i przyszedł sprawdzić, o co chodzi.

Co dostałem w wynikach?

Po kilkunastu minutach test się kończy. Dostajesz dwa rzuty na wyniki: krótkie podsumowanie mailem (wpada, gdy test się zakończy) i pełny raport na stronie. Insighty są podzielone na krytyczne, medium i low - przy każdym opis, co agent zauważył i co mu nie działało.

Z mojego testu Product Academy:

• niedziałające linki URL - znalazł kilka, o których nie miałem pojęcia

• hamburger menu na mobilu - nie działało tak, jak powinno

A teraz najlepsze: poza raportem możesz obejrzeć nagranie każdej sesji. U mnie test wygenerował 12 sesji - po 3 na każde zadanie. Klikasz "Replay" i widzisz krok po kroku, jak agent poruszał się po stronie, gdzie klikał, gdzie utknął.

Wyłapał mi sporo sensownych rzeczy. Od tego czasu co jakiś czas puszczam taki test punktowo - na tyle, na ile pozwala mi pakiet.

🔀 Alternatywa - przeglądarka AI

Reforge Build i syntheticusers.com to dedykowane narzędzia - oczywiście dodatkowo płatne. Chcesz przetestować bez wydawania złotówki, gdy masz dostęp do LLMów?

Możesz spróbować Claude w Chrome (albo inna przeglądarkowa wtyczka AI) - opisujesz agentowi, że ma przejść przez Twoją stronę jako konkretna persona i wyłapać problemy użyteczności.

Działa wolniej i jest mniej ustrukturyzowane niż dedykowane narzędzie - ale na start w zupełności wystarczy, żeby poczuć temat.

Podsumowanie

Syntetyczni użytkownicy to nie magia, która zwolni Cię z rozmów z prawdziwymi ludźmi. Ale może to być ciekawy dodatek do Twojego warsztatu - jeśli wiesz, gdzie ich użyć.

Kiedy sięgnąć po syntetyka, a kiedy po żywego człowieka?

Moja praktyka w trzech zdaniach:

• Wywiady? Ostrożnie. Mogą być ciekawe do pierwszego wysokopoziomowego mapowania potrzeb, słabe do głębokiego “dlaczego”.

• Testy użyteczności? Tu syntetycy się sprawdzają do wyłapania najważniejszych problemów. Wyłapią martwe linki, zepsute menu i rzeczy, których sam już nie widzisz.

• Chcesz spróbować i masz dostęp do LLMa? Odpal Claude w Chrome i zobacz, jak agent przechodzi przez Twój produkt.

A na koniec moja prognoza: wyobrażam sobie, że syntetycy staną się częścią continuous delivery. Tak jak dziś mamy automatyczne testy kodu, tak agent mógłby regularnie chodzić po stronie i wyłapywać problemy użytecznościowe po każdym deployu. To kwestia czasu. ⏳

✅ Co z tym możesz zrobić w tym tygodniu?

Jeśli z tego newslettera masz wynieść jedną rzecz:

👉 Wybierz jedną stronę albo prototyp i puść po nim syntetyka - choćby przez darmową wtyczkę typu Claude w Chrome. Nie potrzebujesz płatnego narzędzia ani budżetu na research. To dosłownie kilkanaście minut.

A potem napraw pierwszą krytyczną rzecz, którą wyłapie.

1. Wybierz jedną stronę lub prototyp do przetestowania (nie całą apkę - jeden ekran wystarczy)

2. Zdefiniuj prostą personę - kim jest user i po co tu wchodzi

3. Odpal agenta (Claude w Chrome albo Reforge Build) i daj mu 2-3 konkretne zadania do wykonania

4. Zobacz, co wyłapał - i napraw pierwszy problem z listy “krytyczne”

Daj znać w komentarzu, jak to u Ciebie zadziałało i co agent znalazł 👇

Niedawno dodawałem nowy ficzer do LABu w Product Academy. I jak każdy PM po wdrożeniu czegoś nowego - zacząłem się zastanawiać: czy ktoś w ogóle z tego korzysta?

Normalnie bym wszedł do PostHoga i poszperał w danych. Teraz coraz częściej robie to z moim agentem AI - Claude. I dostaje szybką odpowiedź w 20 sekund.

Tak wygląda to u mnie zarówno przy własnych produktach, jak i w codziennej pracy. W dzisiejszym wydaniu pokazuję jak to robię na moich danych - i dlaczego zmienia to sposób, w jaki w ogóle myślę o analityce produktowej.

👉 Partnerem dzisiejszego wydania… jestem ja sam i mój 10x Product Bootcamp, gdzie ćwiczymy wykorzystanie AI na konkretnym produktowym case study. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

Subscribe now

Co zobaczysz na nagraniu?

1. Jak podłączyć Clauda do PostHoga przez MCP - to dosłownie kilka kliknięć w connectors.

2. Wykrywanie patternów - pytam “czy widzisz tu jakiś pattern?” i Claude identyfikuje rytm tygodniowy w danych.

3. Analiza rage clicków - gdzie użytkownicy się gubią i na której stronie to się koncentruje.

4. Session recordings - Claude generuje bezpośrednie linki do nagrań sesji z problemem.

5. Weryfikacja hipotezy o nowym ficzerze - czy ktoś w ogóle z niego korzysta i jak wygląda trend po wdrożeniu.

6. Projekt analityczny - jak skonfigurować asystenta, żeby rozumiał Twój produkt i dawał lepsze odpowiedzi.

Najważniejsze wnioski:

1. MCP to nie magia - podłączenie Clauda do PostHoga zajmuje kilka kliknięć w connectors. Nie musisz nic konfigurować ręcznie.

2. Dashboardy zostają - ale nie budujesz nowego na każde pytanie. AI sprawdza się do szybkiej eksploracji i weryfikacji hipotez na bieżąco.

3. Wartość jest w łańcuchu pytań - jedno pytanie prowadzi do kolejnego. Rage clicki → która strona → session recordings → co zmienić. Bez AI każdy krok to osobna sesja w narzędziu.

4. AI jest tak dobry, jak dobry jest kontekst który mu dajesz - projekt analityczny z dokumentacją eventów sprawia, że Claude rozumie Twój produkt. Bez tego dostaniesz poprawne odpowiedzi na złe pytania.

✅ Co z tym możesz zrobić w tym tygodniu?

Jeśli z tego newslettera masz wynieść jedną rzecz:

👉 Sprawdź, czy Twój asystent AI ma integrację z narzędziem analitycznym, którego używasz - PostHog, Mixpanel, Amplitude. Większość z nich już ma MCP lub natywny konektor. To dosłownie kilka kliknięć w connectors.

A potem zadaj jedno proste pytanie o swój produkt.

1. Wejdź w connectors/integracje w swoim asystencie AI

2. Znajdź integrację z Twoim narzędziem analitycznym i podłącz

3. Zadaj pierwsze pytanie - np. “Ilu użytkowników skorzystało z [funkcja] w ostatnim tygodniu?”

4. Zobacz, co dostajesz - i zadaj kolejne pytanie

Daj znać w komentarzu, jak to u Ciebie zadziałało 👇

Nasza produktowa branża jest zakochana w temacie AI jako narzędzia - ChatGPT do PRD, Claude do analizy, Perplexity do researchu. OK, ale mało kto mówi o tym, jak realnie budować produkty i ficzery oparte o AI? Skąd wiem, że ten model AI działa tak jak powinien?

Bo to są trudniejsze pytania.

Na to drugie pytania odpowiada temat AI Evals. I to jest fundament każdego produktu opartego o LLM-y. W tym odcinku Dodane do backlogu pokazujemy jak my do podchodzimy do ewaluacji ficzerów AI. Trzej PMowie, którzy zderzają się z tym problemem na codzień👇

→ Słuchaj na Spotify

lub Apple Podcast.

• czym są evals i skąd bierze się ich rosnąca rola w produktach opartych o AI

• czy evals faktycznie mierzą jakość, czy tylko to, co łatwo zmierzyć

• kto powinien być odpowiedzialny za evals — PM, QA, engineering, czy może zupełnie nowa rola

• jakie są praktyczne metody i sposoby wdrażania evals

• jak evals zmieniają rolę Product Managera i wpływają na strukturę organizacji

Z odcinka dowiesz się:

• (03:50) - Czym w ogóle są AI Evals i dlaczego klasyczne myślenie o testach tu nie działa? - tłumaczymy różnicę między deterministycznym a niedeterministycznym outputem na przykładzie botów konwersacyjnych

• (13:00) - Jak wygląda cykl ewaluacji w praktyce - od ręcznego przeglądania outputów, przez zero-jedynkowe labelowanie, po automatyzację i zamykanie pętli feedbacku do produktu

• (20:45) - Kiedy AI w ogóle nie jest potrzebne - dlaczego prosta reguła deterministyczna często wygrywa z LLM-em i jak to zmienia podejście do budowania evals

• (24:19) - Jakich narzędzi używać do budowania evals - od Excela i CSV, przez gotowe platformy, po moment gdy budujesz własne narzędzie i dlaczego prawie zawsze tam trafiasz

• (29:02) - Gorąca dyskusja: dlaczego to PM, a nie QA powinien być właścicielem jakości AI - i czy rodzi się zupełnie nowa rola w organizacjach produktowych

• (38:37) - Jak wygląda wielka reorganizacja w świecie AI - raport z 50 firm, mniejsze zespoły, nowe role (system architect, validator) i co to znaczy dla PM-ów

• (44:47) - Optymalizacja kosztów LLM-ów jako kluczowa inicjatywa - jak wybierać modele do różnych zadań, dlaczego nie zawsze chcesz najlepszego i jak evals pomagają podjąć tę decyzję świadomie

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

1. Trudność z AI Evals polega na tym, że oceniać coś c o z definicji jest nieprzewidywalne - w klasycznym produkcie dajesz input i dostajesz zawsze ten sam output. W AI ten sam input może dać 99,9% razy świetną odpowiedź - i raz coś kompletnie absurdalnego. Evals istnieją po to, żeby próbować panować nad tym chaosem.

2. Zacznij od ręcznej oceny (nawet jeśli masz miliony generacji LLM miesięcznie) - wszyscy przez to przechodzą - CSV, spreadsheet, człowiek który klika i labeluje. To jest fundament. Bo tylko ręczna próbka pozwala wyłapać problemy, których żaden automat jeszcze nie szuka - bo ich jeszcze nie znasz.

3. Ocena zero-jedynkowa działa lepiej niż skala - zamiast “jak dobra jest ta odpowiedź AI w skali 1-5”, pytaj: “czy to jest zgodne z oczekiwanym zachowaniem, tak czy nie?”. Brzmi prymitywnie, ale lepiej działa. Ułatwia automatyzację i pozwala mierzyć jakość w czasie.

4. Zmiana modelu AI w produkcie bez evals to strzelanie w ciemno - ogólne benchmarki “kłamią” w kontekście naszego produktu. Model, który wygrywa na leaderboardzie, może na Twoich danych i Twoim use case’ie wypaść dramatycznie gorzej. Dopiero jak sprawdzisz na własnych danych - przez własne evale - zobaczysz prawdę. I dlatego bez evals zmiana modelu to kosmos.

5. Nie zawsze potrzebujesz AI od oceny wyników - prosta reguła oparta o regex może zastąpić drogi LLM w zadaniu klasyfikacyjnym. Jeśli człowiek mówi o kredycie hipotecznym, jest skończona liczba słów, których użyje. Zanim wrzucisz problem do modelu - sprawdź, czy deterministyczne podejście nie zrobi tego taniej, szybciej i równie skutecznie.

6. Wybór modelu to decyzja biznesowa, nie techniczna - nie chodzi o “który model jest najlepszy”, tylko o to który jest najlepszy dla tego use case’u, przy tym koszcie, dla tego segmentu klientów. Zmiana modelu to tak naprawdę rozmowa o modelu biznesowym i o tym, na jaki rynek celujesz. Klienci premium akceptują wyższy koszt i oczekują wyższej jakości. I odwrotnie.

7. PM powinien być właścicielem jakości AI - jakość outputu LLM-a staje się produktem samym w sobie. Jeśli Twój produkt stoi na AI, prompt engineering i ocena jakości to często 90% roboty. To zbyt strategiczne, żeby oddać komuś, kto nie rozumie use case’u i kontekstu biznesowego. Możesz angażować innych - ale odpowiedzialność będzie zawsze po Twojej stronie.

Ostatnio zaczynałem nową inicjatywę i jak zawsze pierwsze pytanie brzmiało: “Co my już o tym wiemy?”

Mam raporty z wywiadów, wyniki kilkunastu ankiet ankiety + trochę raportów rynkowych. Wszystko gdzieś jest. Tylko że “gdzieś” to Drive, Notion, Apple Notes.

Brzmi znajomo? 😅

Kiedyś przekopywałem foldery. Dzisiaj mam inny workflow - zbudowany na NotebookLM. I to jest chyba najlepsze AI-owe darmowe narzędzie dla PM-a Pokażę Ci jak tego używam w praktyce.

👉 Partnerem dzisiejszego wydania… jestem ja sam i mój 10x Product Bootcamp, gdzie ćwiczymy wykorzystanie AI na konkretnym produktowym case study. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

• 1️⃣ Jak działa NotebookLM - i czym różni się od Claude/ChatGPT

• 2️⃣ Zastosowanie 1: baza badań dla produktu lub obszaru

• 3️⃣ Zastosowanie 2: research do konkretnej inicjatywy

• 4️⃣ Bonus: funkcje, o których warto wiedzieć

• ✅ Co z tym możesz zrobić w tym tygodniu?

Subscribe now

Zaczynasz nową inicjatywę. Pytasz zespół: “Czy my to już badaliśmy?”. Pada cisza. Ktoś mówi: “Chyba Kasia robiła wywiady w marcu, sprawdzę na Drive’ie”.

Tradycyjne foldery i dokumenty są świetne do przechowywania, ale tragiczne do wyszukiwania. Raport ma 40 stron, wywiad to godzinna transkrypcja, ankieta to 200 odpowiedzi. Nikt tego nie czyta drugi raz.

Efekt? Insighty po jakimś czasie giną w folderach. I to jest główny problem, który rozwiązuje za pomocą NotebookLM.

1️⃣ Jak działa NotebookLM - i czym różni się od ChatGPT

NotebookLM to darmowe narzędzie od Google, które sami nazywają “AI Powered Research Partner”. Znajdziesz je tutaj: notebooklm.google.com

Zasada działania jest prosta:

1. Uploadujesz materiały źródłowe - PDF-y, teksty, strony www, filmy z YouTube, pliki z Drive’a

2. NotebookLM tworzy zamkniętą bazę wiedzy na ich podstawie

3. Pytasz w naturalnym języku - a on odpowiada wyłącznie na bazie tych materiałów

4. Zawsze pokazuje źródła - konkretny fragment konkretnego dokumentu

I tu jest kluczowa różnica względem ChatGPT czy Claude’a.

• Tradycyjny LLM odpowiada na bazie wszystkiego, co wie - i może halucynować albo zmyślać cytaty. NotebookLM najpierw decyduje, który z Twoich dokumentów jest odpowiedni, a dopiero potem odpowiada.

• Drugą ważną rzeczą jest, że NotebookLM wszędzie gdzie podaje jakiś informacje - stara się pokazać dokładne odniesienie - skąd ma tę informację. Można nawet jednym kliknięciem otworzyć materiał źródłowy w tym miejscu.

Praktyczny efekt? Możesz wrzucić dziesiątki dużych plików do jednego notebooka i nadal dostawać precyzyjne odpowiedzi z konkretnymi cytatami. Z dużo mniejszą szansą na degradację jakości, halucynacje, “wymyślanie” cytatów, których nigdy nie było.

Zobaczmy teraz, jak wygląda to w praktyce. Pokażę Ci dwa zastosowania, z których korzystam regularnie.

2️⃣ Zastosowanie 1: baza badań dla produktu lub obszaru

To mój flagowy use case. Tworzysz jeden notebook i wrzucasz do niego wszystkie wyniki badań z danego obszaru.

Zarówno własne, jak i raporty rynkowe, które gdzieś zebrałeś. W Product Academy mam np. notebook

• z wszystkimi badaniami które realizowałem dla Product Management Academy - mojego flagowego szkolenia.

• z badaniami o product managemencie, który zasilam raportami rynkowymi (State of Product, Lenny’s Survey)

2.1. Kiedy to się przydaje

Zaczynasz nową inicjatywę i chcesz wiedzieć, co już wiesz o danym segmencie, zachowaniu lub problemie. Zamiast przeszukiwać foldery - pytasz notebooka.

NotebookLM przeegzaminuje wszystkie wrzucone dokumenty i zrobi jedną z dwóch rzeczy:

• Wskaże Ci konkretny fragment z cytowanym źródłem

• Albo wprost powie, że takich danych w Twoich materiałach nie ma

To drugie jest równie wartościowe. Od razu wiesz, że potrzebujesz nowego badania albo innego źródła. Nie tracisz dnia na przekopywanie folderów, żeby dojść do tego samego wniosku.

2.2. Co wrzucać (a czego nie)?

Polecam wrzucać opracowane wyniki badań, nie surowe transkrypcje. Dlaczego? Baza jest bardziej zwarta, a odpowiedzi precyzyjniejsze. Surowe materiały zostaw na Zastosowanie 2.

Konkretnie warto wrzucić:

• Raporty z wywiadów (syntezy, nie transkrypcje)

• Wyniki ankiet z analizą

• Raporty rynkowe (np. CB Insights, State of Product)

• Artykuły branżowe, na które się powołujesz

• Materiały konkurencji (jeśli takie zbierasz)

2.3. Jak organizować przy większej skali

Kiedy badań robi się naprawdę dużo - twórz osobne notebooki dla różnych obszarów produktowych. Jeden dla onboardingu, drugi dla monetyzacji, trzeci dla retencji.

Utrzymanie struktury od początku oszczędza godziny później. Brzmi oczywiście, ale z doświadczenia wiem, że łatwo wpaść w pułapkę “jednego wielkiego notebooka na wszystko”.

3️⃣ Zastosowanie 2: notebook do researchu konkretnego tematu

Drugie podejście jest bardziej taktyczne. Tworzysz notebook nie dla całego produktu, tylko pod konkretną inicjatywę, temat który aktualnie researchujesz.

Tutaj logika jest odwrotna - raczej wrzucasz surowe materiały:

• Transkrypcje wywiadów z użytkownikami

• Wyniki ankiet ewaluacyjnych

• Surowy feedback z formularzy i Intercom/Zendesk

• Nagrania rozmów sprzedażowych

3.1. Konkretny przykład z mojego workflow

Przy ewaluacji programu Product Management Academy wrzuciłem do notebooka wyniki ankiet ewaluacyjnych z wszystkich edycji. I zadałem jedno pytanie:

“Jakie najważniejsze korzyści i umiejętności wynoszą uczestnicy z kursu PMA?”

NotebookLM nie tylko podsumował odpowiedź - wskazał konkretne fragmenty z ankiet z dosłownymi cytatami uczestników. Mogłem się do nich odwołać w komunikacji marketingowej, na stronie i w rozmowach ze stakeholderami.

Czas, który bym stracił na ręczne przekopanie kilku tysięcy odpowiedzi? Kilka(naście) godzin. Czas w NotebookLM? 15 minut.

3.2. Dlaczego to lepsze niż ChatGPT

W standardowym asystencie masz ograniczone okno kontekstowe. Za dużo materiału i model zaczyna “zapominać” o wcześniejszych fragmentach. Halucynacje rosną, cytaty są wymyślane.

NotebookLM radzi sobie z tym inaczej - najpierw identyfikuje odpowiednie źródło, potem odpowiada. Możesz wrzucić dużo materiału bez utraty jakości odpowiedzi. I bez zgadywanek, czy ten cytat naprawdę padł w wywiadzie.

4️⃣ Bonus: dodatkowe funkcje, o których warto wiedzieć

NotebookLM ma kilka funkcji, o których rzadko się mówi, a które mogą być przydatne w Twoim workflow:

• Audio overview - podsumowanie Twoich materiałów w formie rozmowy dwóch głosów AI. Genialne, jeśli wolisz słuchać w drodze do biura niż czytać raport

• Slide deck - generuje prezentację na bazie materiałów. Dobry punkt startowy do spotkania ze stakeholderami

• Mindmapa - wizualizacja kluczowych tematów i ich powiązań

• Wideo - krótkie podsumowanie z tekstem, które możesz wyeksportować

• Infografika - szybka wizualizacja danych jako punkt startowy

Ja korzystam głównie z czatu (to 90% mojego użycia), ale slide deck i infografika potrafią zaoszczędzić mi godzinę, kiedy muszę szybko przygotować overview z badań dla zarządu.

✅ Co z tym możesz zrobić w tym tygodniu?

Jeśli z tego newslettera masz wynieść jedną rzecz:

Badania nie znikają, bo ludzie są leniwi. Znikają, bo foldery nie są przeszukiwalne. NotebookLM zmienia Twoje rozproszone materiały w przeszukiwalną bazę wiedzy z cytowanymi źródłami.

Dwa zastosowania, które polecam:

1. Baza badań dla produktu - jeden notebook na obszar, opracowane wyniki, raporty rynkowe. Używasz, gdy startujesz nową inicjatywę i chcesz wiedzieć, co już wiecie

2. Notebook dla inicjatywy - surowe transkrypcje, ankiety, feedback pod konkretny projekt. Używasz, gdy pracujesz nad czymś tu i teraz

Co możesz zrobić w tym tygodniu

1. Wejdź na notebooklm.google.com

2. Stwórz jeden notebook dla obszaru, który aktualnie badasz

3. Wrzuć 3-5 najważniejszych materiałów

4. Zadaj pytanie, które ostatnio sobie zadawałeś przy inicjatywie

Daj znać w komentarzu albo odpisz na tego maila, jak to u Ciebie zadziałało 👇

Dlatego w kolejnym odcinku podcastu Dodane do backlogu porozmawialiśmy z najlepszą osobą łączącą świat produktu i zdrowia psychicznego - Adamem Ploną, CEO Mindgram (platforma wsparcia psychicznego) i produktowcem z 18-letnim stażem.

Accountability without authority. Sandwich pressure. Decision fatigue. Impostor syndrome na sterydach. I AI anxiety na dokładkę. Czas potraktować swój well-being tak samo poważnie, jak traktujesz backlog.

→ Słuchaj na Spotify

lub Apple Podcast.

Adam Plona jest współzałożycielem i CEO Mindgram - największej platformy wsparcia psychicznego dla organizacji w Polsce, z dostępem dla prawie miliona pracowników i ich rodzin. Wcześniej przez 18 lat rozwijał produkty cyfrowe m.in. w Wirtualnej Polsce, Domodi i Homebook. Ukończył program executive na Stanford University. W Mindgramie zaczynał jako COO - rolę CEO objął w 2025 roku.

Z odcinka dowiesz się:

• (03:27) - Skąd wziął się Mindgram i dlaczego Adam - po 18 latach kariery produktowej - uznał, że to ludzie, nie technologia, są wąskim gardłem w skalowaniu organizacji

• (09:04) - 4 główne bariery w dostępie do pomocy psychologicznej i gdzie technologia naprawdę może pomóc (a gdzie nie)

• (17:37) - Jak mierzyć ROI ze zdrowia psychicznego? Adam rozkłada na czynniki pierwsze, ile odzyskanych dni pracy znaczy dla firmy w złotówkach

• (37:40) - Unikalny profil ryzyka PM-a: accountability without authority, sandwich pressure, decision fatigue i impostor syndrome na sterydach - dlaczego ta rola jest naprawdę trudna psychicznie

• (43:48) - AI anxiety - czyli dlaczego sztuczna inteligencja nakręca poczucie bycia z tyłu, nawet jeśli już z niej korzystasz

• (46:36) - Potraktuj swój well-being jak produkt: zmierz, przetestuj rozwiązanie, iteruj - praktyczny framework dla PM-a, który świetnie rozwiązuje cudze problemy, ale ignoruje własne

• (50:46) - Peer support, Fuck Up Nights i Gratitude Friday - konkretne techniki, które działają i kosztują dosłownie zero złotych

• (56:38) - Osobiste doświadczenia Adama: od sceptyka terapii do człowieka, który świadomie buduje swoją siłę psychiczną jako przewagę - i co konkretnie zmienił w codziennym funkcjonowaniu

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

1. PM ma unikalny profil ryzyka psychicznego. I nie chodzi o “stres w pracy”. Accountability without authority - odpowiadasz za produkt, revenue, OKR-y, a nie masz formalnej władzy nad nikim. Inżynierowie raportują do CTO, designerzy do head of design. Ty każdego dnia przekonujesz wszystkich do wszystkiego. To nie jest normalne napięcie. To się kumuluje - i ma swoją nazwę w psychologii: ciężar emocjonalny.

2. Sandwich pressure wykańcza nie gorzej niż praca w call center. Z góry lecą pytania “czemu tak wolno shipujecie?”, z dołu “czemu ciągle zmieniacie scope?”. Ty jesteś buforem. A bufory się zużywają. Badania pokazują, że pracownicy obsługi klienta - którzy muszą codziennie odbierać czyjąś frustrację i oddawać uśmiech - mają największe problemy z kontrolą emocji. PM w sandwich pressure działa dokładnie tak samo.

3. Impostor syndrome u PM-ów jest na sterydach - i AI go nakręca. Musisz rozmawiać z inżynierami o architekturze, z biznesem o revenue, z data scientistami o metrykach, z designerami o UX. Nigdzie nie jesteś ekspertem. W kulturach nagradzających pewność siebie przyznanie się do “nie wiem” kosztuje ogromnie dużo energii. A AI dokłada do tego AI anxiety - poczucie, że pociąg odjeżdża i nie zdążysz wskoczyć.

4. Traktuj swój well-being jak produkt. PM-owie są ekspertami od rozwiązywania problemów innych - i nagminnie ignorują własne sygnały. Przepis jest prosty: zmierz stan wyjściowy, zdefiniuj konkretny problem, przetestuj rozwiązanie, zmierz ponownie, iteruj. Dokładnie ten sam framework, którego używasz przy produkcie. Ty też możesz być single point of failure.

5. Peer support to nie “miękkie HR-owe rzeczy” - to realna interwencja. Gadaj z innymi PM-ami. Nie żeby rozwiązywać problem, żeby go znormalizować. Usłyszenie od kogoś “mnie też to dotknęło, to jest naprawdę trudne” robi robotę, której żaden framework nie zrobi. Piątkowa kawa z PM-ami, na której wylewacie żale - to jest kozetka u terapeuty. I działa.

6. Porażki niech będą porażkami - przestań szukać happy endu. Fuck Up Nights to świetna technika - ale tylko jeśli nie kończysz każdej historii morałem “i właśnie dzięki temu odnieśliśmy sukces”. Większość porażek nie ma happy endu. Są po prostu porażkami. Normalizowanie tego - bez obowiązku przekucia w lekcję - buduje odporność psychiczną lepiej niż jakikolwiek kurs produktowy.

7. Siła psychiczna to przewaga konkurencyjna - mierzalna w złotówkach. Firma z tysiącem pracowników korzystających z platformy wsparcia psychicznego odzyskuje 0,8 dnia pracy miesięcznie per osoba. W skali roku to równowartość 36 dodatkowych etatów. Wypalona organizacja rosnąca w 40% rocznie to predyktor przyszłego kolapsu - nie sukcesu. Zdrowie psychiczne zespołu to nie koszt. To inwestycja z mierzalnym ROI.

Dziś bez deep dive’a. Za to z ogłoszeniem, na które czekałem od dawna. Bardzo miło mi ogłosić że… produktowy podcast “Dodane do Backlogu” oficjalnie dołącza do Product Craft 🎉.

Bardzo się cieszę, bo chłopaki z podcastu - to mega dziki product managementu. Każda rozmowa z nimi to dla mnie kopalnia doświadczeń.

Połączenie podcastu z newsletterem to naturalna synergia. Po pierwsze - sam jestem członkiem "Dodane do Backlogu”. Po drugie - podcast reprezentuje dokładnie to, co od zawsze publikuję w tym newsletterze - realny craft produktowy. Doświadczeni goście, którzy zderzają się hands-on z problemami każdego dnia.

Nie teoria, nie influencerzy, nie hype - tylko hands-on praktyka.

Poniżej znajdziesz szczegóły tej zmiany:

1. Czym jest podcast “Dodane do Backlogu”?

2. Co opublikowaliśmy do tej pory?

3. Co to zmienia dla Ciebie? Subskrybent newslettera

4. Co dalej?

1. Czym jest podcast “Dodane do Backlogu”?

Czterech Senior+ PM-ów z globalnych produktów rozmawia o zarządzaniu produktami. Każdy z nas ma kilkanaście lat doświadczenia hands-on w budowaniu globalnych produktów. Różne firmy, różne środowiska, różne specjalizacje - ale wszyscy to hands-on praktycy.

Subskrybuj na Spotify

Kim jesteśmy:

• Wojtek Smajda - Senior Tech PM w IBM, wcześniej PM w Zendesk i TomTom, advisor w Huge Thing. Ogromne doświadczenie w PMowaniu deep techowych produktów.

• Marcin Jędrzejczak - Principal PM w Celonis, wcześniej SAP, NordClaud. Pracuje w międzynarodowych środowiskach korporacyjnych z setkami (a nawet tysiącami) PM-ów.

• Jakub Tutaj - Senior Growth PM w Mixmax, wcześniej m.in. Softr, Zendesk. Silne growthowe i PLG-owe doświadczenie.

Przy chłopakach z IBM, Celonis i Mixmax czasem czuję się jak impostor, który usiadł przy złym stoliku - ale ktoś musi wnosić perspektywę scaleupową i AI-ową. No i tą osobą chyba jestem ja ;)

Podcast wyrósł z naszych prywatnych cotygodniowych mastermindów. Od pewnego poziomu doświadczenia zauważyliśmy, że najwięcej dają nie proste odpowiedzi, ale zderzanie perspektyw i naszego “to zależy”. W pewnym momencie stwierdziliśmy, że rozmowy, które prowadzimy, są zbyt wartościowe, żeby zostawiać je tylko dla siebie. I postanowiliśmy tę wartość przekazać dalej w podcaście “Dodane do Backlogu”.

2. Co opublikowaliśmy do tej pory?

12 odcinków od przełomu 2024/2025 roku. Każdy odcinek to produktowa wymiana naszych doświadczeń oraz odcinki specjalne z gośćmi którzy w globalnym product managemencie znaczą bardzo wiele m.in.

Marty Cagan (SVPG):

David Pereira (CPO MailerLite),

Todda Romana (SVP Zendesk).

Dla mnie osobiście to niesamowita okazja, żeby regularnie odbijać myśli z innymi doświadczonymi PM-ami. To coś, czego brakuje wielu z nas w codziennej pracy - szczera rozmowa z kimś, kto rozumie kontekst.

3. Co to zmienia dla Ciebie?

W skrócie: więcej wartościowych treści od doświadczonych PMów.

Nowe odcinki będą pojawiać się w newsletterze Product Craft. Nie musisz szukać podcastu osobno - będzie do Ciebie trafiał razem z newsletterem. Na Substacku możesz sobie ustawić, czy chcesz dostawać powiadomienia o nowych odcinkach (domyślnie są włączone).

• Odcinki trafią na stronę newslettera w dedykowanej sekcji: 👉 newsletter.productcraft.pl/s/dodane-do-backlogu

• Części odcinków będą towarzyszyć dodatkowe materiały dostępne dla subskrybentów. Tak jak np. tekstowy wywiad z Marty Caganem, który opublikowaliśmy wcześniej.

• Sam podcast “Dodane do Backlogu” dalej żyje jako osobny brand → subskrybujecie podcast na Spotify, dołączcie do nas na LinkedIn.

Chcę też, żebyście mieli wpływ na tematy. Komentujcie, dzielcie się pomysłami o czym powinniśmy rozmawiać. Jako społeczność macie teraz większy głos w tym, co nagrywamy.

4. Co dalej? Mocny odcinek

Już niedługo pojawi się nowy odcinek, w którym rozmawiamy z Adamem Ploną (CEO Mindgram, wcześniej m.in. VP of Product w Grupie Wirtualna Polska) o temacie, o którym za mało się mówi w naszej branży - zdrowiu psychicznym PM-ów.

Adam łączy ten temat z product managementem w swojej firmie, więc to nie jest ogólnikowa gadka o wellbeingu. To konkretna rozmowa o tym, jak dbać o siebie robiąc jedną z najbardziej stresujących robót w techu.

Zostawiam Was z tym - i do usłyszenia.

—
Pozdrawiam(y),
Tomek + Wojtek, Marcin, Jakub

PS. Jeśli jeszcze nie słuchasz “Dodane do Backlogu” - subskrybuj podcast na Spotify i nadrabiaj. 12 odcinków z naprawdę mocnymi gośćmi czeka.

PPS. Jeśli znasz kogoś, kto powinien słuchać tego podcastu - prześlij mu ten newsletter.

→ Słuchaj na Spotify

lub Apple Podcast.

Zderzyliśmy jak zawsze nasze różne doświadczenia - jak planujemy tydzień, żeby dowieźć to co naprawdę ważne (a nie tylko być zajętym), jakieś są nasze rutyny i jak nasza praca ewoluowała przez lata.

Trochę taktycznie, ale jak zawsze na bazie naszych kilkudziesięciu (:D) lat błędów i doświadczeń w pracy produktowej:

• Wojtek Smajda (Senior Product Manager, IBM)

• Jakub Tutaj (Growth Product Manager, Mixmax)

• Marcin Jedrzejczak (Principal Product Manager, Celonis)

• Tomek Tomaszewski (Head of Product, BrainBits.ai)

W odcinku usłyszysz:

• (01:36) - Nasza poranna rutyna w pracy i wojna o Slacka - czy sprawdzać wiadomości od razu po przebudzeniu?

• (10:20) - Jak dbamy o czas na „Deep Work”?

• (16:16) - Budżet uwagi: Czy wydajesz go na drobne po 5 groszy, czy na grube tematy?

• (28:00) - Zasada 5 wiadomości: Kiedy przestać pisać i po prostu zadzwonić?

• (47:00) - Planowanie tygodnia: Metoda 3 celów i dlaczego poniedziałek jest lepszy niż piątek.

• (58:23) - Dlaczego przestaliśmy chodzić na wszystkie spotkania

Słuchaj odcinka

Moje najważniejsze insighty z rozmowy:

1. Twój budżet deep work to średnio 2-4 godziny dziennie - i koniec. Nie 8 godzin „skupienia”. Nie 6. Dosłownie 2-4 godziny efektywnej pracy głębokiej to wybitny dzień. Resztę zjada bieżączka, kontekst switching i rozgrzewka. Im szybciej to zaakceptujesz i zaczniesz chronić te godziny jak skarb, tym lepsze będą Twoje wyniki.

2. Sprawdzenie Slacka rano nie jest złe - ale masz świadomie wybrać, kiedy to robisz. Jedni zaczynają od przeglądu (żeby wiedzieć, czy nie ma pożaru - to JA), inni chronią rano jak źrenicę oka i wchodzą w deep work od razu. Nie ma jednej odpowiedzi. Jest tylko jedna pułapka: wchodzenie na Slacka odruchowo, bez intencji. To właśnie kradnie Ci focus zanim w ogóle zaczniesz myśleć.

3. Nie musisz odpowiadać szybko – musisz ustawiać oczekiwania u stakholderów. Kuba ma na to fajną zasadę, którą komunikuje wprost: „Jeśli jestem online, odpiszę w ciągu godziny – ale ta odpowiedź może Cię nie zachwycić.”. Responsywność nie polega na byciu zawsze dostępnym. Polega na tym, żeby ludzie wiedzieli, czego i kiedy mogą się po Tobie spodziewać. To jest zarządzanie zależnościami, nie unikanie ich.

4. Tygodniowe planowanie działa - ale tylko jeśli masz max 3 priorytety. Jeden duży cel + dwa poboczne. Jeśli zrobiłeś te 3 rzeczy – był zarąbisty tydzień. Reszta to szum, który i tak się pojawi. Im wyższe seniority, tym krótsza lista: junior PM pisze 15 rzeczy, senior – dwie. Nie dlatego, że robi mniej. Dlatego, że wie, co naprawdę jest ważne

5. Rozmowa na żywo czasem rozwiązuje w 3 minuty to, co na Slacku ciągnie się godzinami. Praca synchroniczna nie jest złem. Złem jest brak intencjonalności - czyli gadanie non-stop, bo wszyscy siedzą w jednym pokoju. Ale jeśli w wątku na Slacku wymieniasz już piątą wiadomość i nadal nie ma decyzji - zrób calla.

6. Większość naszej pracy i tak okazuje się błędna – więc wykryj to jak najszybciej. Bez względu na to, jak świetnie priorytetyzujesz, zbierasz insighty i prowadzisz discovery – duża część rzeczy, które robisz, okaże się po prostu nietrafionym kierunkiem. Nie ma czym się frustrować. To jest powód, żeby budować krótkie pętle feedbackowe i nie wkładać 3 miesięcy pracy w coś, zanim sprawdzisz czy w ogóle warto.

7. PM odpowiada za energię zespołu - nawet gdy sam ma dołek. Kiedy eksperyment nie wyszedł, sprint leży, a morale siada – ktoś musi powiedzieć żart, zrobić oddech i zapytać „dobra, jak do tego podchodzimy jeszcze raz?". Nie chodzi o udawanie, że jest dobrze. Tylko o świadome zarządzanie atmosferą, która bezpośrednio wpływa na to, czy zespół spróbuje kolejny raz z energią - czy odpuści.

Niedawno w zespole podejmowaliśmy decyzję, która dla wielu AI-influencerów krzyczących o „najlepszych modelach” brzmiałaby jak herezja - NIE wybraliśmy najlepszego w benchmarkach modelu AI na rynku.

Dlaczego? Bo prawdziwe pytanie nie brzmi „jaki jest najlepszy model?”. Brzmi: „Jaki jest najlepszy model do NASZYCH zastosowań?” I to jest pytanie, na które powinien odpowiedzieć AI PM.

W dzisiejszym wydaniu:

1. Dlaczego nie wybraliśmy “najlepszego” modelu?

2. Dlaczego koszty modeli mają gigantyczny znaczenie?

3. Jak podejść do wyboru modelu?

4. Czego unikać - klasyczne pułapki, w które sam wpadałem

5. Podsumowanie

Subscribe now

Ogłoszenia:

• W dniach 21-22 maja odbędzie się Product Pro Summit w Sopocie - dwudniowa produktowa unconference, bilety 4 292 zł.

• Pozostały ostatnie 2 bilety na naszą wiosenną edycję Product Management Academy - 6 tygodniowy program warsztatów dla PMów (3 239 zł).

1. Dlaczego nie wybraliśmy “najlepszego” modelu?

Kilka tygodni temy decydowaliśmy w produkcie o zmianie głównego wykorzystywanego modelu AI. Mieliśmy konkretny problem z wynikami LLM-a blokujący ekspansję.

Oczywiste rozwiązanie? Upgrade na „najlepszy” model.

Jaki model jest najlepszy? Możemy wejść na LLM Stats albo AI Arena i sprawdzić, który model jest „najlepszy”. Odpowiedź zaczyna się już tu niuansować - to zależy od tego, na który benchmark patrzysz.

GPQA? SWE-bench? MMLU? AIME? Każdy z nich mierzy coś innego.

Ale najważniejsze - żaden z nich nie mierzy tego, co naprawdę ważne - jak model radzi sobie z TWOIM konkretnym problemem, na TWOICH danych, w TWOJEJ skali.

Dlatego to co zrobiliśmy to…

1️⃣ Przetestowaliśmy modele na naszych datasetach - nie na abstrakcyjnych metrykach, tylko na danych dotyczących problemu, który faktycznie rozwiązujemy w produkcie. Zmierzyliśmy to, co ma znaczenie dla naszych użytkowników.

Efekt? Zupełnie INNY RANKING niż publiczne leaderboardy. Część modeli z TOP5 globalnych rankingów była u nas daleko w tyle. Modele, które „teoretycznie” powinny dominować, na naszych danych dawały gorsze wyniki niż modele spoza pierwszej dziesiątki.

2️⃣ Policzyliśmy realne koszty — tak, jest model, który daje X% lepsze wyniki... ale kosztuje Y razy więcej. Czy X% poprawa uzasadnia Y-krotny wzrost kosztów?

I właśnie tutaj zaczyna się prawdziwa DECYZJA PRODUKTOWA, nie techniczna:

• 👉 Atakujemy wyższy rynek z wyższymi marżami, ale musimy szybko walczyć o skalę, żeby to miało sens?

• 👉 Czy zostajemy na aktualnym rynku, gdzie obecne wyniki są „good enough”, skalujemy go, wiedząc, że wynik produktu będzie trochę gorszy?

Witamy w niedeterministycznym świecie rozwijania produktów AI.

2. Dlaczego koszty mają gigantyczne znaczenie?

Żeby zobaczyć to jeszcze bardziej obrazowo - policzmy koszty dla konkretnego scenariusza - produktu AI z 1 milion generacji LLM miesięcznie (na podobnej skali sam pracuję). Każda generacja to:

• 5 000 tokenów wejściowych (prompt + kontekst dla LLM-a)

• 1 000 tokenów wyjściowych (odpowiedź modelu)

To daje nam miesięcznie:

• Input: 5 miliardów tokenów (5 000 milionów)

• Output: 1 miliard tokenów (1 000 milionów)

A teraz porównajmy dwa przykładowe modele z TOP 10:

• Claude Opus 4.6 - najlepszy model w większości benchmarków

• Kimi K2.5 - model od firmy Moonshot AI

• $50 000 vs $5 500 miesięcznie. Prawie 9x różnicy.

• $600 000 vs $66 000 rocznie. Za ten sam milion generacji.

I to nie jest porównanie typu „FC Barcelona” vs „Chełmnianka Chełmno” (klub z mojego rodzinnego miasteczka ;). Kimi K2.5 to model z 1 bilionem parametrów, który na wielu benchmarkach niewiele ustępuje popularnym modelom:

Oczywiście - Claude Opus 4.6 to świetny model. Na wielu zadaniach da lepsze wyniki o kilka %. Ale pytanie nie brzmi „który jest lepszy?”, tylko:

Czy różnica w jakości modeli uzasadnia 9-krotny wzrost kosztów w kontekście TWOJEGO produktu (Twoich danych) i TWOJEGO rynku?

Czasem tak, ale bardzo często odpowiedź będzie negatywna. Dlatego tak ważne jest dobranie modelu do konkretnych zastosowań.

Oczywiście takie obliczenia to uproszczenie - trzeba wziąć pod uwagę choćby kwestię cachowanie promptów. Dlatego tak ważne jest testowanie na swoich danych + przygotowanie takiej analizy z/przez DEV / AI Lead-a.

3. Jak podejść do wyboru modelu?

Na bazie naszych doświadczeń - oto jak podchodzę do wyboru modelu LLM w produkcie. Nie jest to rocket science, ale zdziwisz się, ile zespołów pomija krok 2 i 3.

1️⃣ Zacznij od benchmarków

Użyj LLM Stats, Artificial Analysis albo Chatbot Arena, żeby stworzyć shortlistę 4-6 modeli, które wyglądają obiecująco dla Twojego typu zadań.

Nie więcej. To oszczędza czas. Benchmarki służą do wstępnej selekcji, nie do podejmowania decyzji.

-

2️⃣ Przetestuj na SWOICH danych

To kluczowy krok, którego większość PM-ów pomija.

Przygotuj reprezentatywny zestaw przykładów z prawdziwego ruchu Twojego produktu. Przepuść przez każdy model ze shortlisty. Zmierz to, co faktycznie ma znaczenie dla Twoich użytkowników - nie abstrakcyjne metryki.

• Jeśli budujesz narzędzie do analizy tekstu - mierz jakość analizy na Twoich tekstach.

• Jeśli chatbot - mierz trafność odpowiedzi na pytania, które zadają Twoi użytkownicy.

• Jeśli generujesz raporty - oceń jakość raportów na Twoich danych.

I tak, to wymaga pracy. Ale to jest dokładnie ta praca, która odróżnia produkty AI, które działają, od tych, które „powinny działać”.

-

3️⃣ Policz koszty w skali

Nie w „cenie za 1 zapytanie”, ale w miesięcznym budżecie przy realistycznym wolumenie.

Różnica kilku centów na zapytaniu staje się różnicą dziesiątek tysięcy dolarów rocznie. Tak jak policzyliśmy powyżej - $50 000 vs $5 500 miesięcznie to nie jest detal, tylko fundament wpływający na opłacalność Twojego modelu biznesowego.

Weź swój miesięczny wolumen (albo prognozowany), wrzuć do kalkulatora i porównaj realne koszty. Sprawdź kalkulator tokenów na langcopilot.com - uwzględnia caching i Batch API.

-

4️⃣ Zdefiniuj trade-off

Tu wchodzisz w sedno decyzji produktowej:

• Jaki poziom jakości jest „good enough” dla Twojego rynku?

• Gdzie przebiega granica między „tańszy, ale wystarczający” a „droższy, ale otwiera nowy segment”?

• Czy Twoi użytkownicy zauważą różnicę 2% w jakości? A 5%?

To jest moment, w którym PM przestaje być „osobą od backlogu” i zaczyna podejmować realne decyzje produktowe w produkcie AI. Wybór modelu AI to nie kwestia techniczna - to decyzja produktowa.

-

5️⃣ Podejmij decyzję produktowa, nie techniczną

Model AI to nie cel. To narzędzie do realizacji strategii produktowej.

Wybierz model, który najlepiej pasuje do Twojego modelu biznesowego, nie ten z najwyższym benchmarkiem. Czasem „gorszy” model jest lepszą decyzją, bo pozwala Ci skalować szybciej, daje wyższe marże, albo po prostu Twoi użytkownicy nie potrzebują dodatkowych 3% jakości.

4. Czego unikać?

Parę klasycznych pułapek, w które sam wpadałem (i tak, mówię z doświadczenia):

--

🔹 „Ten model jest najlepszy na benchmarkach, więc musi być najlepszy dla nas”

Nie. Benchmarki mierzą coś innego niż Twój produkt. GPQA mierzy wiedzę ogólną, SWE-bench mierzy umiejętność naprawiania bugów w open source. A Ty potrzebujesz modelu, który dobrze analizuje opinie klientów w branży telco po polsku. To nie jest to samo. Zawsze testuj na swoich danych.

--

🔹 „Zmienimy model - to jest proste”

Każdy model ma inną charakterystykę. Twoje prompty, ewaluacje, esse case’y będą od tego zależy. Inny model inaczej reaguje na te same instrukcje. Inaczej się „myli”. Inaczej formatuje output.

--

🔹 „Weźmiemy najdroższy, bo na pewno jest najlepszy”

Widziałeś tabelkę powyżej. 9x w cenie ≠ 9x w jakości. Na naszych danych różnica w jakości między najdroższym a najtańszym modelem na shortliście wynosiła kilka procent, a różnica w kosztach - rząd wielkości.

--

🔹 Ignorowanie kosztów cachingu

Zarówno Anthropic (prompt caching z 90% zniżką na powtarzalne prompty), jak i Kimi (automatyczny cache z 75% oszczędnością) oferują mechanizmy, które mogą drastycznie obniżyć rachunki. Jeśli Twoje zapytania mają powtarzalny system prompt (a pewnie mają), to musisz to policzyć. Różnica bywa ogromna.

5. Podsumowanie

Nie ma „najlepszego modelu”. Jest model najlepszy dla Twojego produktu, Twoich użytkowników i Twojego modelu biznesowego.

Trzy rzeczy, które możesz zrobić po przeczytaniu tego newslettera:

• ✅ Zbuduj własny eval dataset - zbierz realne przykłady z Twojego produktu i przetestuj na nich 3-5 modeli. Nie polegaj tylko na publicznych rankingach. To jest najprostszy sposób, żeby uniknąć złej decyzji.

• ✅ Policz koszty w skali - weź swój miesięczny wolumen (albo prognozowany), wrzuć go do kalkulatora i porównaj realne koszty. Różnica Cię zaskoczy.

• ✅ Zamień pytanie techniczne w biznesowe - zamiast „który model jest najlepszy?”, zapytaj „jaki rynek chcemy obsługiwać i jaki trade-off jakość/koszt akceptujemy?”. Odpowiedź na to pytanie powie Ci więcej niż wszystkie benchmarki razem wzięte.

Nic tak realnie nie inspiruje, jak podpatrzeć JAK „ROBIĄ PRODUKT” inni, najlepiej doświadczeni produktowi praktycy - ich konkretne problem, decyzje, artefakty i na końcu realne wyniki. Zobaczyć jak wyglądało w praktyce zastosowanie frameworka, czy rozwiazanie konkretnego produktowego problemu z którym sam się mierzę.

To właśnie dlatego tak bardzo uwielbiam format realnych case study. Dlatego też jest on na stałe obecny w newsletterze i w moich programach szkoleniowych.

Pamiętam jak kilka lat temu zaczęliśmy wprowadzać je do Product Management Academy. I na dodatek jeszcze płacić za tę wiedzę najlepszym polskim praktykom - coś nie do pomyślenia dla wielu (także zresztą i dzisiaj ;))

W Product Academy mamy już 25+ takich case study od polskich PMów: LiveChat, Atlassian, Zendesk, Brand24, Scanie, SentiOne, Freeletics, Softr.io, Tandem, Luxemd, SAP i… wiele więcej.

🔓 OTWIERAM DOSTĘP do 4+1 pełnych nagrań CASE STUDIES

Szkoda by te case studies trzymać tylko dla siebie (no i dla absolwentów PA) ;). Dlatego postanowiliśmy, że 🔓 OTWIERAMY TYMCZASOWO DOSTĘP do 4+1 pełnych nagrań CASE STUDIES z płatnego programu Product Management Academy.

• 🎦 Atlassian: „Jak w praktyce pracuję z metrykami adopcji i zaangażowania” - (Olga Springer, Senior PM) - 15 min

• 🎦 Softr.io: „Konwersja w produkcie spada! Co robić?” (Jakub Tutaj, Growth PM) - 60 min

• 🎦 SentiOne Automate: “Discovery (krok por koku) dla inicjatywy produktowej z wykorzystaniem PRD”(Tomasz Tomaszewski, Head of Product) - 12 min

• 🎦 OKR Poland: „Synchronizacja pracy zespołów produktowych w dojrzałych produktach poprzez OKRs” (Elena Zhukova, funder) - 60 min

🚨 Jednorazowo akcja, wysyłka we wtorek do ZAPISANYCH osób, potem ponownie zamykamy dostęp.

🔓 Odblokuj te Case Study

🎁 A gdzie to piąte case study?

Czytelnicy Product Craft jak zawsze mają lepiej i dla was 1️⃣ dodatkowe case study znajdzie bezpośrednio poniżej w newsletterze.

Jest to moje własne case study wykorzystania szablonu oceny funkcji produktu w produkcie SentiOne Listen. Ten temat przyda Ci się szczególnie na początku pracy z produktem - by dokonać pierwszego przeglądu funkcji produktu i obrać wstępną strategię dotyczącą ich rozwoju.

🎦 Ocena funkcji produktu | SentiOne Listen (25 min)

Do oceny funkcji wykorzystałem 3 kluczowe metryki produktowe - adopcję, zaangażowanie i satysfakcję użytkowników. Następnie na podstawie modelu 4 typów funkcji produktowych - sklasyfikujemy najważniejsze funkcje oraz dobrałem do nich strategię działania.

Otwórz Case Study

Możesz też zobaczyć jak koncepcję adopcji i zaangażowania wykorzystuje Olga Springer w Atlassianie - jej case study znajdziesz we wspomnianej wyżej paczce case study z PMA.

Wiadomo, udostępniamy te case studies z dobyć serca, ale też… w celach promocyjnych. Jeśli uważasz że to wartościowe rzeczy, będę wdzięczny jeśli podasz je dalej - żeby się niosło 🤝.

Dzisiaj kontynuujemy Przewodnik 101 po Cursorze dla PM/PO. Jeśli przeszedł_ś pierwszą część, masz już działający projekt w Cursorze i wiesz, jak zlecać AI zadania.

Czas na następny poziom: zapisane komendy („Commands”). Przestajesz szukać i robić ciągłe copy & paste swoich najważniejszych procedur i promptów we współpracy z AI. Trzymasz je w projekcie i wywołujesz jednym wygonie jednym konkretnym znakiem: /

Zostały ostatnie 4 bilety na 10x Product Bootcamp, gdzie ćwiczymy wykorzystanie AI na konkretnym produktowym case study. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

• 1️⃣ Moja historia zarządzania promptami

• 2️⃣ Czym są komendy (Commands)?

• 3️⃣ Dwa poziomy komend - project vs user

• 4️⃣ Tworzenie własnej komendy w Curosorze

• 5️⃣ Mój konkretny use-case

• 6️⃣ Kiedy używać Commands, a kiedy innych mechanizmów?

• 7️⃣ Jak to wygląda w innych środowiskach? Przykład Claude Code

• 👉 Co dalej?

Subscribe now

1. Moja historia zarządzania promptami

Kilka lat temu, gdy zaczynałem intensywnie pracować z ChatGPT, szybko natrafiłem na problem: gdzie trzymać dobre prompty? Też masz / miał_ś z tym pewnie problem.

Najpierw stworzyłem publiczną bazę najlepszych promptów dla product managerów - opisałem ją w artykule na Product Craft, gdzie przez 30 dni testowałem ChatGPT jako swojego wirtualnego asystenta. Każdy działający prompt zapisywałem, żeby móc go powtórnie użyć.

Potem baza wylądowała w Apple Notes. Wydawało się, że to spoko miejsce - z notatek dużo korzystam, niby zawsze pod ręką. Ale działało to tak: otwierasz Notes, szukasz prompta, kopiujesz, wracasz do ChatGPT, wklejasz, dodajesz kontekst, wysyłasz. Siedem kroków zamiast jednego.

Największy problem był inny - prompty były oderwane od systemu pracy. Leżały sobie w jakimś folderze w aplikacji do notatek, kompletnie niezintegrowane z tym, nad czym akurat pracujesz.

Moja praca z agentami AI - i Cursorem w szczególności - to zmieniła. Teraz konkretne komendy, w tym prompty które mi się sprawdzają, mogę zapisać wprost w projekcie i wywoływać jednym gestem. Bez szukania, bez kopiowania, bez tracenia kontekstu.

2. Czym są komendy (Commands)?

Commands to zapisane prompty lub procedury, które wywołujesz wpisując /nazwa w czacie Cursora (lub innego środowiska - takiego jak Claude Code czy Google Antigravity).

Wyobraź sobie makra w Excelu - coś, co robisz regularnie, zapisujesz raz i uruchamiasz jednym kliknięciem. Commands działają dokładnie tak, tylko dla pracy z AI.

Kilka przykładów co możesz zapisać jako komendę:

/napisz-taska - tworzy opis zadania w Twoim formacie

/podsumuj-spotkanie - przetwarza surowe notatki na czytelne podsumowanie

/weekly-brief - przechodzi przez swoja stanrdową procedurę tygodniową

/analiza-feedbacku - kategoryzuje feedback od użytkowników według priorytetów

/brief-ficzer - generuje brief dla nowej funkcji zgodnie z Twoim templatem

3. Dwa poziomy komend - project vs user

Zanim stworzysz komendę, warto wiedzieć że masz dwa poziomy - i wybór zależy od tego, do czego komenda ma służyć:

Project commands - komendy przypisane do konkretnego projektu/folderu:

• Zapisywane w .cursor/commands/ wewnątrz folderu projektu

• Widoczne tylko gdy masz ten projekt otwarty w Cursorze

• Idealne gdy komenda jest specyficzna dla danego produktu, zespołu lub klienta (np. format tasków właśnie dla tego zespołu dev, styl dokumentacji pod konkretny projekt)

User commands - komendy globalne, dostępne wszędzie:

• Zapisywane w ~/.cursor/commands/ w folderze domowym na Twoim komputerze

• Dostępne w każdym projekcie, niezależnie od tego co masz otwarte

• Idealne dla komend, których używasz bez względu na projekt (np. /podsumuj-spotkanie, /napisz-maila, /analiza-feedbacku)

3. Tworzenie własnej komendy w Curosorze

Krok 1: Tworzenie Commmand

Możesz tworzyć komendy bezpośrednio z interfejsu Cursora - w ustawieniach jest dedykowana sekcja Commands, gdzie dodasz nową komendę bez wychodzenia z aplikacji (tam też wybierasz poziom: project lub user).

Możesz też stworzyć folder i plik ręcznie - efekt jest identyczny:

twoj-projekt/
└── .cursor/
    └── commands/
        └── napisz-taska.md      ← project command
        
~/.cursor/
└── commands/
    └── podsumuj-spotkanie.md   ← user command (globalny)

Dodaj więcej pierwszą komendę - dla przykładu zrobimy sobie komendę opisującą zadanie do Jira w odpowiednim, używanym przez nas, formacie.

Krok 2: Napisz komendę jako plik Markdown

Zawartość pliku to po prostu instrukcja dla AI - opisz co ma robić, kiedy wywołasz tę komendę.

Tu przykładowa komenda:

Na podstawie poniższych informacji - napisz opis zadania 
dla zespołu developerskiego na Jira. 

## Format opisu

Każde zadanie powinno mieć:
- Tytuł: format User Story
- 2-3 zdania: jaki jest problem i dlaczego to ważne
- Sekcja "Possible solution" z punktorami (opcjonalna, nie techniczna)

## Zasady
- Pisz po angielsku
- Skup się na problemie biznesowym, nie na implementacji
- Jeśli brakuje informacji, zapytaj mnie

## Kontekst Produktu

Kontekst produktu znajdziesz w [nazwa pliku]

• Jeśli dodajesz komendę z interfejsu użytkownika w ustawieniach - po prostu wpisz tam tę powyższa komendę.

• Jeśli tworzysz plik to pamiętaj, że nazwa pliku = nazwa komendy. Plik napisz-taska.md → to komenda /napisz-taska.

Krok 3: Wywołaj komendę

W czacie Cursora wpisz / - pojawi się lista dostępnych komend z autocomplete:

/napisz-taska opis funkcji eksportu raportów do PDF... (i tu dalszy opis)

Wszystko co napiszesz po nazwie komendy trafia jako dodatkowy input do AI. Finalnie to co dostaje AI składa się z:

4. Mój konkretny use-case

Jako PM w BrainBits mam swój ustalony sposób opisywania zadań do backlogu. Krótko, problem-first, bez zbędnych technicznych szczegółów (od tego jest zespół).

Problem był taki: za każdym razem gdy prosiłem AI o napisanie taska, dostawałem rozbudowany, techniczny opis z milionem szczegółów, których nie chciałem. AI nie wiedziało, na jakim opsie taska mi zależy.

Stare rozwiązanie (korzystałem z aystenta AI):

• miałem więc swój prompt, który doklejał do każdego wywołania w ChatGPT. Kopiowałem go z mojego notesu.

• Potem zrobiłem sobie dedykowany projekt w ChatGPT (“JIRA TASK”) - który w kontekście projektu miał moją instrukcje opisywania zadania. Teoretycznie to działało, ale problem tylko był taki, że rozkminiając jakiś temat z AI, gdy już wiedziałem jakie zadanie che stworzyć - musiałem kopiować treść, zmieniać projekt na “JIRA TASK” i tam dalej pracować nad zadaniem.

Dzięki pracy z agentem w Cursorze, w dowolnym momencie, dowolnej rozmowy używam po prostu komendy:

/jira-task [opcjonalnie dodatkowy opis taska]

Jeden slash, często nawet nie musze dodawać dodatkowego opisu, bo to przecież wynika z historii rozmowy. No i AI wie dokładnie jak ma wyglądać wynik.

Mój plik komendy wygląda tak:

# jira-task

Write task descriptions that are short, problem-focused, and dev-friendly.

## Task Structure

```
title: [Action verb] + [What] + [Where/Context]

[2-3 sentences: What's the problem? Why does it matter?]

Possible solution:
* [Bullet points with implementation hints - optional, not prescriptive]
```

## Writing Rules

1. **Title**: Start with action verb (Add, Fix, Enable, Implement, Remove)
2. **Problem first**: Describe current pain point and business impact
3. **User perspective**: Use "As a [role]..." or "Currently..." or "We want to..."
4. **Solutions are hints**: Suggest direction, don't dictate implementation
5. **Keep it short**: 3-6 lines total (excluding title)

## Examples

**Good:**
```
title: Add link to specific message in Transactions view

Problem: Currently, the Transactions view shows transaction 
records but lacks a direct link to the message that triggered the transaction. 
As a user I need to manually search for the relevant message,
sometimes is time-consuming.

Possible solution:
* Add link to amount of money
```

**Good:**
```
title: Possibility to calculate LLM generation time

We want to review how long it takes to generate LLM response 
(generation time) - it will help AI team evaluate LLM performance.

TO DO:
* save additional data in database that will make possible 
to get or calculate "LLM generation time"
```

**Bad (too technical, no problem statement):**
```
title: Implement PostgreSQL trigger for message_id foreign key

Add trigger function that creates index on transactions.message_id
column and implements JOIN optimization for message lookup queries using CTE.
```

## Language

Write in English. Use simple, direct sentences.

Kluczowa zaleta: jeśli zmieni mi się sposób opisywania tasków - edytuję jeden plik. Mogę o tę edycje poprosić nawet agenta - nie muszę tego robić sam. Najważniejsze, że wszystkie przyszłe wywołania /napisz-taska będą używać nowego formatu.

5. Jak to wygląda w innych środowiskach? Przykład Claude Code

Commands to nie wynalazek Cursora - to universal pattern w pracy z agentami AI. Niezależnie od narzędzia, idea jest ta sama: zapisujesz procedurę raz, wywołujesz wielokrotnie.

Jeśli już uczysz się tej filozofii w Cursorze - w Claude Code (lub innym systemie z agentami) będziesz się czuł jak w domu. Pliki komend mają tę samą strukturę Markdown, ta sama lokalizacja, ten sam sposób wywołania.

“Uczysz się raz, stosujesz wszędzie. Twoje komendy to Twoje know-how w formie kodu.”

6. Kiedy używać Commands, a kiedy innych mechanizmów?

W Cursorze są trzy sposoby na zapisanie swoich “instrukcji” dla AI. Ważne, żeby wiedzieć kiedy których używać:

Na razie skup się na Commands - to najprostszy i najszybszy sposób na zorganizowanie swoich promptów. Rules i Skills opiszę w kolejnych częściach tej serii.

✅ Zadanie dla Ciebie:

Zastanów się jakie powtarzalne akcje najczęściej wywołujesz ze swoim asystentem AI i spróbuje dla nich zrobić komendę w Cursorze.

👉 Co dalej?

Commands rozwiązują realny problem każdego PM-a pracującego z AI: gdzie trzymać dobre prompty i jak je szybko wywoływać.

Zamiast szukać po Apple Notes / Notion - wpisujesz / i wybierasz z listy. Twoje instrukcje żyją tam, gdzie pracujesz.

W kolejnym artykule z serii opiszę kolejne mechanizmy zarządzania kontekstem - Agents.md, Skills i Rules. Ale najpierw wejdź w komendy - to fundament.

Dzięki temu mam okazje obserwować, doświadczać i też samemu kreować jak AI zmienia pracę zespołów produktowych. A zmienia. I to mocno.

Dlatego w ostatnim czasie pracuję nad 6-tygodniwym programem: 10x Product Bootcamp, w którym podzielę się swoimi doświadczeniami, ale też przede wszystkim wspólnie, hands-on na warsztatach, będziemy mogli eksperymentować z AI.

Dlaczego 10x? Bo samo używanie AI nie zrobi z Ciebie lepszego PM-a. Ale połącz AI z doskonałym mindsetem produktowym - i nagle możesz osiągać 10x więcej. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach.

Tak pracują najlepsze zespoły które obserwuję (i w których mam przyjemność pracować od 8 lat rozwijając produkty AI) i do tego poziomu chcemy aspirować.

🔹 10x Product Bootcamp (1.04 - 13.05)

• 🔹 6 tygodni “learning by doing”. Razem przechodzimy przez kompletny product sprint od A do Z dla konkretnego wzywania - case study konkretnego produktu. Tak jak w prawdziwej pracy.

• 🔹 Pracujesz na cotygodniowych warsztatach, w małej grupie (max 20 osób), a nie tylko samotnie “w swoim czasie”. Przed warsztatem otrzymujesz 30 minutowy pre-work.

• 🔹 [Opcjonalnie] 4x power sessions i office hours z mentorami, praktyczne indywidualne zadania projektowe rozszerzające pracę nad case study, lekcje i materiały online.

• 🔹 Pierwsza edycja dla early adopterów, wiec cena Early Birds tylko 3 000 zł → 1 899 zł netto (2 335,77 zł brutto) 💰.

Wszystkie pierwotnie planowane bilety wyprzedaliśmy w 24h 🫣. Dlatego uruchomiliśmy dodatkową grupę warsztatową i pulę wejściówek. To już na pewno OSTATNIA pula biletów.

Szczegóły i rezerwacja biletu

I jeszcze jedno fajne INFO:

Do składu trenerskiego Bootcampu dołącza Jakub Uniejewski - Kuba aktualnie pracuje w Devinity (współtwórcy polskiego modelu AI “Bielik"), wcześnie HoP i PM globalnych produktów taki jak OLX, SkyScanner, Freeletics, Tandem. Mało kto w PL ma takie produktowe doświadczenie jak Kuba.

Czyli jak zawsze w Product Academy - mocny “hands-on” praktyk, a nie influencer ;).

Jesteś na poziomie 0% zrozumienia. Co teraz?

Tradycyjnie, musiał_byś spędzić godziny na ręcznym przeglądaniu wierszy i kolumn, próbując zrozumieć, co się w nich kryje.

Dzisiaj pokaże Ci trzyetapowy framework o nazwie DIG, którą stosuję by za pomocą asystenta AI wstępnie przeanalizować każdy, nawet zupełnie nieznany zbiór danych. Sam go wykorzystywałem podczas analizy wyników satysfakcji z ostatnich edycji Product Management Academy.

I na tym przykładzie pokażę Ci jak to działa (+ przykładowy dataset na którym możesz samemu eksperymentować).

🔔 BTW. Ruszyła kolejna edycja 10x Product Bootcamp, gdzie łączymy AI z doskonałym mindsetem produktowym. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

• Co analizowałem?

• Metoda DIG (Description, Introspection, Goal Setting - czym jest?

• 📂 Dataset do testów

• 1️⃣ Krok: D - Description

• 2️⃣ Krok: I – Introspection (Introspekcja)

• 3️⃣ Krok: G – Goal Setting (Ustalenie Celu)

Subscribe now

Co analizowałem?

Niedawno zakończyliśmy 10 edycję Product Management Academy, czyli naszego flagowego programu szkoleniowego w Product Academy. Po każdej edycji robimy ankietę ewaluacyjną, żeby móc usprawniać program. Ankieta jest przeprowadzana na ostatnich zajęciach każdej edycji. Uczestnicy mają 10-15 minut na uzupełnienie ankiety.

Ankieta zawierała zarówno dane ilościowe (np. NPS, ocena satysfakcji), jak i bezcenne dane jakościowe (odpowiedzi na pytania otwarte, takie jak “Co Ci się podobało?” i “Co powinniśmy poprawić?”, “Co jeszcze chcesz nam przekazać”). Z 10 edycji zebrało się ok 500 wyników.

Poniżej rzut okiem jak to mniej więcej wyglądało ⤵️

Metoda DIG (Description, Introspection, Goal Setting)

Metoda, którą poznasz, to DIG. Jest to uproszczona wersja standardowej branżowej metodyki EDA (Exploratory Data Analysis). Nazwa DIG jest łatwiejsza do zapamiętania, a zasady są podobne.

Opiera się ona na analizie danych w 3 następujących po sobie krokach:

• D - Description (Opis): Zrozum, co znajduje się w pliku.

• I - Introspection (Introspekcja): Zastanów się, jakie pytania można zadać na podstawie tych danych.

• G - Goal Setting (Ustalenie Celu): Skoncentruj analizę na konkretnym celu biznesowym.

Z każdym krokiem tej metody Twoje zrozumienie danych rośnie (oraz zrozumienie przez asystenta AI), aż w końcu jesteś w stanie wyciągnąć wnioski, które bez tego procesu mogłyby Ci umknąć.

Kiedy stosować?

Podejście DIG ma sens stosować przy nieznanych Ci do końca i bardziej skomplikowanych danych. To wtedy najlepiej w taki bardziej uporządkowany sposób podejść do analizy.

📂 Dataset do testów

Jeśli chcesz sobie przetestować do podejście do analizy możesz skorzystać z przykładowego datasetu z danymi o filmach z AppleTV (źródło Kaggle)

Pobierz plik z danymi

1️⃣ Krok: D - Description

Cel: Jak najszybciej zrozumieć, co zawiera plik danych.

Na tym etapie chcemy, aby AI opisało nam podstawową strukturę i zawartość danych z pliku. Użyjemy do tego serii prostych poleceń (promptów). Potraktuj to jako przykładowe prompty - chodzi bardziej o wysoko poziome kolejne kroki analizy danych zgodne z modelem DIG.

Ja załadowałem cały plik z wynikami ankiety NPS programu Product Management Academy. Jako że obejmowało to 10 edycji, to byłoby to prawie 500 wierszy, każdy zawierający kilkanaście kolumn.

PROMPT 1: Co mamy?

Masz przed sobą arkusz feedbackiem uczestników Product Management Academy. Co dokładnie zawiera ten arkusz? Wymień wszystkie kolumny w załączonym arkuszu i pokaż mi próbkę danych z każdej z nich.

• Zmuszasz AI do przejrzenia każdej kolumny w zbiorze danych.

• Dostajesz szybki, skondensowany przegląd zamiast przytłaczającej ściany danych.

—

PROMPT 2: Próbka danych

Pobierz 5 dodatkowych losowych próbek danych z każdej kolumny, aby upewnić się, że rozumiesz format i typ informacji w każdej z nich.

• Więcej przykładów pomaga zauważyć wzorce i niespójności

—

PROMPT 3: Kontrola jakości

Przeprowadź kontrolę jakości danych w każdej kolumnie. W szczególności poszukaj:
- Brakujących, pustych wartości lub wartości typu 'null' (podaj ich liczbę i wartość procentową)
- Nieoczekiwanych formatów lub typów danych
- Wartości odstających lub podejrzanych

• Ten prompt pozwala proaktywnie zidentyfikować problemy, zanim zaczniesz właściwą analizę.

2️⃣ Krok: I - Introspection (Introspekcja)

Cel: Odkryć, jakie pytania analityczne można zadać, korzystając z dostępnych danych.

Na tym etapie prosimy AI, aby wcieliło się w rolę analityka i zaproponowało możliwe kierunki dalszych badań. To testuje, czy AI “naprawdę” zrozumiało dane.

PROMPT 1: 10 pytań badawczych

Podaj 10 interesujących pytań, na które moglibyśmy odpowiedzieć, korzystając z tego zbioru danych, i wyjaśnij, dlaczego każde z nich byłoby wartościowe.

• Dobre, trafne pytania oznaczają, że AI rozumie kontekst biznesowy.

• Słabe pytania sygnalizują, że coś trzeba wyjaśnić.

A tu fajne propozycje, które dostałem dla swojego Datasetu z PMA:

—

PROMPT 2: Deep Dive w pytanie

Dla [wybrane pytania] wskaż dokładnie, których kolumn należałoby użyć i czy obecne dane są wystarczające do udzielenia na nie odpowiedzi.

• Teraz zmuszamy AI do “pokazania swojej pracy”.

• AI potwierdza, dla których pytań dane są wystarczające, dla których nie, dla których wymagają oczyszczenia (co możemy zlecić AI w kolejnym kroku).

—

PROMPT 3: Szukanie luk

Jakie pytania, Twoim zdaniem, ktoś chciałby zadać na temat tych danych, ale na które nie możemy odpowiedzieć z powodu brakujących informacji?

• To mój ulubiony prompt na tym etapie.

• Ujawnia luki w Twoim zbiorze danych.

• Pomaga zarządzać oczekiwaniami swoimi i interesariuszy co do możliwych do uzyskania wyników.

Jeśli zidentyfikujesz kluczową lukę (np. brak danych), możesz poszukać innego zbioru danych, który ją wypełni, a następnie poprosić AI o połączenie obu zbiorów za pomocą wspólnej kolumny.

Dla mojego datasetu z PMA - dostałem fajne informacje, by być świadomym co będzie ograniczało moje dalsze analizy, ale też - o jakie dane warto by było uzupełnić dataset (a w naszym przypadku też uzupełnić po prostu ankietę ewaluacyjną).

3️⃣ Krok: G – Goal Setting (Ustalenie Celu) i właściwa analiza

Cel: Ukierunkować analizę na konkretny problem biznesowy, aby jej wyniki były użyteczne.

Teraz możemy już zacząć analizować dane pod konkretny cel. Możesz skorzystać z pytań, które zasugerował Ci wcześniej asystent.

—

PROMPT 1: Określenie celu

Moim celem jest [opisz swój cel, który chcesz osiągnąć]. Biorąc pod uwagę ten cel, na których aspektach danych powinniśmy się skupić?

Dajesz AI jasny kierunek, co pozwala mu priorytetyzować istotne informacje i ignorować te nieistotne oraz ustalić plan działania.

To jest ten moment, gdzie możesz zacząć pogłębiać analizę odpowiednimi pytaniami:

• Dzięki krokowi Description - wiesz co już jest w danych dokładnie

• Dzięki korkowi Introspection - odkryłeś (Ty i AI) czego można się dowiedzieć i co warto pogłebiać

• Dzięki krokowi Goal Setting - określiliście finalnie kontekst z AI nad którym będziecie pracować dalej z AI.

—

Dlaczego to ważne? Plan vs działanie

Zwróć uwagę, że dzięki takiemu podejściu - najpierw przygotowujemy z AI razem plan. Dzięki temu możemy potem zrobić lepszą analizę.

W przypadku datsetu AppleTV i mojej analizy: “Czy produkcje z udziałem krajów spoza USA osiągają lepsze lub gorsze wyniki od czysto amerykańskich” - asystent fajnie wyłapał że musimy to doprecyzować, np:

• co uznajemy za “wynik”

• jak segmentujemy produkcje filmowe?

• czy wszystkie kraje razem, czy poszczególne rynki nas interesują?

• w jakim formacie przygotować wyniki

• itd.

Dzięki temu możemy uzupełnić finalny prompt. Lub odpowiadając na te pytania - dać kontekst AI.

Jeśli przejdziemy od razu do analizy - to dostaniemy od razu odpowiedź, ale niekonicznie nas satysfakcjonującą. To taki rezultat:

—

PROMPT 2: Gdy masz już gotową analizę

Zanim zaprezentujesz wyniki, zawsze zadaj AI ostatnie pytanie:

Jakie kluczowe pytania mogłaby zadać osoba czytająca moją analizę i w jaki sposób powinniśmy na nie proaktywnie odpowiedzieć?

• To polecenie pomoże Ci przygotować się na trudne pytania od menedżerów i kolegów z zespołu, co sprawi, że Twoja prezentacja będzie znacznie solidniejsza.

Jak jeszcze poprawić analizę?

To co możesz zrobić w swoim realnym przykładzie w produkcie to… dodanie kontekstu produktowego - czyli informacji o tym czym jest produkt którego dane analizujesz.

Surowym danym z ankiet zwykle brakuje kontekstu produktowego. Ty masz go w głowie, ale nie Twój AI. To często prowadzi do problemów:

• Bez zrozumienia propozycji wartości i struktury produktu, AI skupia się tylko na objawach zgłaszanych przez użytkowników, a nie na ich fundamentalnych przyczynach.

• Analiza bezkontekstowa traktuje wszystkich respondentów jako jednorodną grupę, przez co nie jest w stanie wychwycić problemów specyficznych dla kluczowych segmentów klientów.

• Rekomendacje formułowane w próżni, bez odniesienia do celów produktu, mają mniejszą siłę przebicia i nie wiadomo, jak przyczynią się do jego sukcesu.

• Nieznajomość działania produktu, jego formatu sprawia, że rekomendacje AI stają się ogólnikowe i często bezsensowne. Np. dla moich danych PMA - AI nie wie, że program trwają wiele tygodni i przedstawia to jako rekomendację zmian.

Dlatego zawsze mam pod ręką plik z kontekstem produktowym - który może AI wykorzystać. Można oczywiście na stałe wrzucić go w funkcje projektów swojego asystenta.

Konkretny widoprzykład przeprowadzania analizy w oparciu o model DIG dla danych w ofercie Apple TV+ znajdziesz u Jeffa Su. To u niego poznałem tę metodę :)

📈 Ocena satysfakcji to 4,6 / 5, a finalny NPS mamy na poziomie 80+. A ja pierwszy raz dostałem jako trener ocenę 5/5 od uczestników 😍😱.

Po każdej edycji zostają ze mną moje własne produktowe lessons learned. Zebrałem je w tym wydaniu - znajdziesz w nich kluczowe koncepcje do wykorzystania przy rozwoju produktów cyfrowych.

Na końcu wpisu znajdziesz też mały bonus 🎁 - udostępniliśmy 5 wybranych pełnych lekcji z PMA (zupełnie za BEZPŁATNIE) 🙌. Z lekcji skorzystało już 1400+ osób.

BTW. Właśnie wystartowały zapisy na kolejną edycję PMA.

• 1️⃣ [KICK-OFF + FOUNDATION] Budowanie własnego AI co-pilot - Twój najlepszy partner w produktowej pracy

• 2️⃣ [FOUNDATION] Pierwsze 30 dni z nowym zespołem - warsztaty z Team Alignementu

• 3️⃣ [DISCOVERY] Ocena pewności przy priorytetyzacji pomysłów - różne skala (nie)pewności w Discovery

• 4️⃣ [DELIVERY] Czy Product Manager powinien zajmować się delivery? - moje wnioski i wskazówki

• 5️⃣ [ANALYTICS] Ewaluacja nowych funkcji w produkcie - Framework TARS

• 🎁 BONUS: 5 pełnych lekcji z PMA -

1️⃣ AI co-pilot - najlepszy partner w produktowej pracy

W module Kick-off i Foundation mówimy o układaniu sobie fundamentów pracy w produkcie i w zespole produktowym. W dobie AI szkoda nie wykorzystać tutaj siły asystenta AI – swojego second brain, thinking partnera, z którym zbijasz sobie wszystkie najważniejsze koncepcje produktowe.

To nowy element PMA i mój ulubiony temat w tym obszarze.

W lekcji pokazałem, jak sam tworzę sobie produktowego co-pilota, który na co dzień pomaga mi w pracy produktowej. A tu poniżej moje 2 najważniejsze insighty po roku pracy z własnymi copilotami.

Moje najważniejsze WNIOSKI:

• 1️⃣ AI nie ma cię zastąpić. Ma być Twoją supermocą

  • Samo AI nie zrobi z Ciebie lepszego PM-a. Ale połącz AI z doskonałym mindsetem produktowym – i nagle możesz osiągać 10x więcej.

  • Większość PM-ów używa AI do „szybszego dowożenia” tych samych rzeczy: wygenerują generyczną strategię w 20 minut, opiszą zadania do Jiry 10x szybciej, zbudują MVP bez zespołu dev.

  • Najlepsi liderzy produktowi łączą AI z doskonałym mindsetem produktowym. Pracują ramię w ramię z zespołem, żeby podejmować dzięki AI lepsze produktowe decyzje – a nie „szybciej zarządzać taskami”.

• 2️⃣ Context jest wszystkim

  • Najważniejszą cechą skutecznego co-pilota nie są “dobre prompty” tylko odpowiedni CONTEXT - głębokiej wiedzy i kontekstu dotyczącego Twojej pracy, firmy, zespołu oraz bieżących zadań i projektów.

  • Dzięki temu kontekstowi AI może wspierać Cię w dyskusjach, pomagać w podejmowaniu decyzji produktowych, formułować komunikaty dostosowane do kultury Twojej organizacji oraz tworzyć dokumenty zgodne z wewnętrznymi standardami i oczekiwaniami.

  • To pozwala mu nie tylko przyspieszać wykonywanie rutynowych zadań, ale również challengować Twoje myślenie, proponować alternatywne perspektywy oraz pomagać w strukturyzowaniu złożonych problemów produktowych.

Dlatego sam od dłuższego czasu mocno korzystam z Cursora - on mi pozwala łatwo zarządzać kontekstem podczas produktowych sparingów z AI.

2️⃣ Pierwsze 30 dni z nowym zespołem

AI, AIem, ale przecież w firmach pracujemy z innymi ludźmi. I współpraca z nimi to jest z najważniejszych aspektów pracy dobrego PMa.

Jak zacząć i ułożyć sobie współpracę z nowym zespołem? …od tego ćwiczenia i dyskusji zwykle zaczynamy warsztaty o fundamentach. Myśląc od nowych środowisku - zwykle najlepiej znajdujemy fundamenty którymi powinniśmy się zająć.

Przygotowując się do warsztatów z uczestnikami, wróciłem do case study Patrycji Walencik: jak dołączyła do zespołu w Zendesku i jak zbudowała w nim alignment. Z tego case’u wyniosłem warsztat team alignmentu.

Moje LESSONS LEARNED:

• 1️⃣ Na start schowaj ego i najpierw poznaj wartości zespołu.

  • Zespół ma już swoje wartości i sposób pracy. To one w dużej mierze determinują, czy się dogadacie. Zamiast od razu „naprawiać” procesy, warto najpierw zrozumieć: co dla nich jest ważne, jak rozumieją dobrą współpracę i co ich irytuje. Bez tego każda Twoja propozycja może brzmieć jak narzucanie.

• 2️⃣ Ty też jesteś „ciałem obcym” – i zespół chce Cię poznać.

  • Członkowie zespołu naturalnie pytają: jaki jest ten nowy PM, na co można liczyć, jak reaguje w trudnych sytuacjach. Warto być na to przygotowanym: mieć w głowie (albo na kartce) swoje zasady, granice i sposób komunikacji. Jasna autoprezentacja buduje zaufanie szybciej niż same deklaracje.

• 3️⃣ Bez team alignmentu nie ma sensownej pracy produktowej.

  • Alignment dotyczy zarówno relacji między ludźmi w zespole, jak i Ciebie jako nowego PM-a. Chodzi o wspólne rozumienie: jak ze sobą współpracujemy, jaki mamy kierunek, cele, priorytety i na czym polega nasza strategia. Bez tego każdy ciągnie w swoją stronę – i „produkt” się rozjeżdża.

• 4️⃣ Wyraźnie określcie role i wzajemne oczekiwania.

  • Różne zespoły i firmy mają różne wyobrażenia o roli PM-a i o tym, jak „powinna” wyglądać współpraca. Zamiast zakładać, że wszyscy grają w tę samą grę – nazwijcie to: kto za co odpowiada, od kogo czego się oczekuje i gdzie są granice. To oszczędza konfliktów i rozczarowań.

• 5️⃣ Nie chodzi o opasłe dokumenty - chodzi o rozmowę.

  • Na start świetnie sprawdza się warsztat team alignmentu (np. w Miro czy Muralu): wspólna rozmowa, zapisane ustalenia, konkretne zasady. Potem warto to co jakiś czas weryfikować – np. na retro – czy wciąż się sprawdza, czy coś trzeba odświeżyć lub zmienić. Alignment to nie jednorazowy dokument, tylko żywa umowa zespołu.

3️⃣ Ocena pewności przy priorytetyzacji pomysłów

W PMA dużo mówimy o tym, że priorytety to nie tylko „co jest ważne”, ale też „na ile jesteśmy pewni, że to w ogóle ma sens”. Jednym z narzędzi, które najlepiej to pokazuje – i które regularnie wykorzystuję w pracy – jest skala niepewności (confidence level). Daje ona wspólny język do rozmowy z zespołem i stakeholderami: gdzie tak naprawdę jesteśmy z danym pomysłem i ile discovery jeszcze przed nami.

Skala niepewności (mam swoją, ale też można stosować choćby skalę Itamar-a Gilad, Confidence Meter) pomaga odłożyć intuicję na bok i uczciwie ocenić, na jak solidnych dowodach opieramy nasze przekonania:

• ❌ NISKA PEWNOŚĆ - masz jedną opinię szefa lub stakeholderów, że „to musi być zrobione”. To nie dowód, tylko życzenie. Pewności praktycznie zero.

• 🤔 ŚREDNIA PEWNOŚĆ - pojawiają się pojedyncze opinie użytkowników, anegdoty, pierwsze wywiady czy feedback. Coś już wiesz, ale do sensownej pewności wciąż daleko.

• 🖤 WYSOKA PEWNOŚĆ - dopiero gdy masz badania ilościowe, eksperymenty, wypuszczone MVP i analizę danych, możesz mówić, że założenia mają solidne wsparcie.

Samo pokazanie takiej skali osobom, które przychodzą z kolejnym „mega ważnym i pilnym” pomysłem, często zmienia grę: zasiewa ziarno wątpliwości i skłania do większego discovery zamiast od razu „robić”.

ICE Score zamiast zgadywania

Skala świetnie też nadaje się na literkę C w ICE score, którego często używamy do priorytetyzacji pomysłów ze stakeholderami.

ICE score =  Impact x CONFIDENCE x Ease. 

Zamiast ustawiać Confidence „na czucie” (np. 1–5), warto oprzeć go właśnie o poziom pewności z tej skali. Jest czytelna, obrazowa i trudno się z nią spierać – wszyscy widzą, na jakich dowodach się opieramy.

Kluczowe pytanie brzmi zawsze: “gdzie jesteśmy na tej skali?” I co z tego wynika dla discovery? Nawet przy tych samych „dowodach” odpowiedź bywa przedmiotem gorącej dyskusji – i to dobrze. Sam proces dochodzenia do odpowiedzi ma dużą wartość.

Idea Prioritization With ICE and The Confidence Meter

4️⃣ Czy Product Manager powinien zajmować się product DELIVERY 👀?

To pytanie w module Product Delivery jak zawsze mocno rozgrzało salę. Były jak zwykle dwa obozy:

• Pierwszy mówi, że PM powinien być blisko zespołu i delivery, w końcu pełni rolę Product Ownera w zespole scrumowym, a Agile mówi żeby cały czas ze sobą pracować.

• Drugi odpowiada: to przecież rola zespołu dev albo delivery managera; PM ma się skupiać na discovery, strategii i „co”, a nie na „jak” i harmonogramach.

Dyskusje bywają gorące – i słusznie, bo to decyzja o modelu współpracy.

Moje INSIGHTy:

1️⃣ „To nie moja rola” to ryzykowna wymówka

• Słaba praca nad outputami przekłada się na słabą pracę nad outcome’ami – a to wprost wpływa na szansę sukcesu produktu i na to, jak ja jako PM jestem postrzegany (i jaki mam realny wpływ).

• Dlatego - pewnie to niepopularna opinia - zawsze czuję się odpowiedzialny za to, czy nasze delivery działa dobrze, nawet jeśli są do tego dedykowane role. Nie chodzi o to, żeby moja rola sprowadzała się do backlog managementu, dowożenia ficzerów i usprawniania procesu.

• Chodzi o to, żeby delivery po prostu działało – i żebym reagował i wspierał, gdy jest to potrzebne.

2️⃣ Delivery to nie „drugi etap po discovery” – to dalsze testowanie.

• Każdy release to kolejna runda weryfikacji: czy budujemy to, co trzeba, czy użytkownik i biznes na tym zyskują, czy w ogóle dajemy radę to zbudować 🛠️.

• Sztywny podział „najpierw discovery, potem delivery” jest mylący – w praktyce cały czas obniżamy niepewność. Warto tak też dobierać to, co i w jakiej kolejności dostarczamy.

3️⃣ Tempo delivery = tempo uczenia się.

• Wolniejsze lub słabsze dostarczanie oznacza mniej cykli, mniej danych z rynku, mniej szans na korektę. Jako PM nie mogę traktować tempa i jakości delivery jako „sprawy zespołu” – bo to bezpośrednio ogranicza to, jak szybko mogę dopasować produkt do rzeczywistości.

• Dopiero jak wypuścimy pierwszą wersję naszego rozwiązania na rynek, która zderzy się z realnym użytkownikami, będziemy wiedzieli, czy poczliśmy w dobrą stronę. Czy przyniosło to wartość dla użytkownika 🎁, wartość biznesową 💰 i czy byliśmy w stanie to zbudować 🛠️.

4️⃣ Product Trio ma sens tylko wtedy, gdy delivery jest wspólnym tematem.

• Kluczowa jest współpraca PM–tech lead–zespół: nie „ty delivery, ja discovery”, tylko wspólna odpowiedzialność za to, że produkt faktycznie wychodzi i się uczenia na nim.

• Bez tego Product Trio staje się trzema osobami przy tym samym stole, ale z różnymi planami 🛠️.

5️⃣ Ewaluacja przy pomocy frameworka TARS

„Jakie metryki wybrać do oceny funkcji?” – w module Product Analytics podczas każdej kolejnej edycji PMA jednym z narzędzi, które robiło największą robotę, jest zawsze framework TARS (od Reforge). Prosty w strukturze, a daje wspólny język do rozmowy: czy nasza funkcja w ogóle trafia do ludzi, czy z niej korzystają, czy wracają i czy są zadowoleni.

Co dokładnie mierzymy w TARS?

TARS to akronim czterech miar, które warto brać pod uwagę przy każdej funkcji (nie tylko „ile mamy użytkowników”):

• 1️⃣ T - Targeted users (użytkownicy docelowi): aktywni użytkownicy, dla których ta funkcja w ogóle ma sens. Nie każda funkcja jest dla całej bazy – może to być 80%, 50% czy 30% użytkowników. To od razu zmienia perspektywę: nie „wszyscy”, tylko „ci, do których strzelamy”.

• 2️⃣ A – Adopted users: z tej grupy docelowej (Targeted) – ilu choć raz skorzystało z funkcji? Czy w ogóle wyrazili zainteresowanie i czy nasza propozycja wartości do nich dotarła.

• 3️⃣ R – Retained users: jaki procent z nich wraca i używa funkcji w swojej rutynie (dziennej, tygodniowej lub miesięcznej – zależnie od use case’u). Retencja pokazuje, czy rozwiązanie realnie wchodzi w życie.

• 4️⃣ S – Satisfied users: jaki procent jest zadowolonych (np. Customer Effort Score). Czy nie tylko używają, ale i cenią rozwiązanie / UX.

Razem te cztery miary pozwalają ocenić nie tylko „czy coś zrobiliśmy”, ale czy trafiamy z wartością, czy ludzie to adoptują, zostają i są zadowoleni.

Lessons Learned

• TARS porządkuje myślenie o analityce - dla mnie framework uporządkował sposób patrzenia na cały produkt i na poszczególne funkcje. Zamiast gubić się w dziesiątkach metryk, mam prosty zestaw pytań: kto jest targetem, ilu adoptuje, ilu wraca, ilu jest zadowolonych. To ułatwia też śledzenie, jak zmiany w produkcie przekładają się na realne zachowania.

• Kolejność ma znaczenie – najpierw adopcja - Jeśli użytkownicy nie zauważają funkcji albo nie rozumieją, po co z niej korzystać, mało da się poprawiać retencję i satysfakcję. Trzeba najpierw weryfikować hipotezy związane z adopcją (czy w ogóle trafiamy do grupy docelowej i czy wartość jest czytelna). Dopiero gdy ludzie zaczynają używać – sens ma głęboka praca nad retencją i satysfakcją.

🎁 BONUS: 5 wybranych pełnych lekcji z Product Management Academy.

Z ostatnich edycji Product Management Academy wynika coś, co nas samych pozytywnie zaskoczyło: dodatkowe lekcje wideo i materiały online z programu bardzo dużo znaczą dla uczestników. Pozwalają wrócić do konkretnych koncepcji i frameworków wtedy - kiedy zaczynasz je realnie stosować.

W ankietach dostajemy na ten temat mnóstwo dobrego feedbacku – i często słyszymy, że ludzie wracają do tych materiałów jeszcze długo po zakończeniu Akademii.

Dlatego jakiś czas temu, wypuściliśmy w świat 5 wybranych pełnych lekcji z PMA (bezpłatnie) 🎉. Po jednej lekcji z każdego kluczowego modułu - dokładnie te same materiały, z których korzystają uczestnicy i uczestniczki Akademii.

Odbierz lekcje

Zawartość lekcji

Jest to 5 ciekawych i dokładnie opracowanych tematów:

1. [FOUNDATION] Adopcja i zaangażowanie – ocena funkcji produktu. W tej lekcji dowiesz się w jaki sposób podejść do analizy i oceny funkcji produktu.

2. [DISCOVERY] 4 typy niepewności produktowych - W tym materiale poznasz koncepcję czterech typów niepewności produktowych, które będziesz systematycznie weryfkować w procesie product discovery.

3. [DELIVERY] Jak prowadzić Backlog refinement? - najważniejsze informacje i wskazówki dotyczące prowadzenia backlog refinmentu

4. [LEADERSHIP] Jak ułożyć współpracę z interesariuszami - techniki i narzędzia pozwalające efektywnie współpracować i budować zaufanie.

5. [STARTEGY] Synchronizacja pracy zespołów produktowych poprzez OKRs - Elena Zhukowa opowie o swoim case study wdrażania OKRs w dojrzałej organizacji produktowej.

Lekcje zawierają nagranie wideo, materiały dodatkowe, a część z nich także szablony do wykorzystania w praktyce. Tutaj mały sneak peek:

Odbierz lekcje

Po odebraniu lekcji damy Ci też znać o kolejnej edycji Product Management Academy (właśnie startujemy zapisy, połowę miejsc mamy już zarezerwowanych).

W poprzednim tygodniu 200+ osób przyszło na mój MasterClass LIVE o tym jak wykorzystuję Cursora w pracy produktowej. Wiele zainspirowanych osób potem pytało: “Jak zacząć? Ale tak od zera?”

Poświęciłem weekend żeby pomóc: przed Tobą kompletny przewodnik Cursora od podstaw dla Product Managera. Krok po kroku, od instalacji do pierwszego realnego zadania. Bez założenia, że cokolwiek wiesz o edytorach kodu.

Masz dwie formy: 🎦 video (30 min) i pisemny 📕 przewodnik z zdaniami (45 min) do którego możesz wracać. Na końcu - masz prosty workflow, który możesz wykorzystać od jutra w pracy.

Ruszyła kolejna edycja 10x Product Bootcamp, gdzie łączymy AI z doskonałym mindsetem produktowym. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

• 1️⃣ Dlaczego Cursor do produktowej pracy?

• 2️⃣ Instalacja Cursora i pierwsze uruchomienie

• 3️⃣ Interfejs (pierwsze 5 minut z Cursorem)

• 4️⃣ Markdown - język komunikacji z AI

• 5️⃣ Podstawowa rozmowa z AI (tryb ASK)

• 6️⃣ Tryb Agent (AI wykonuje działania)

• 7️⃣ Tryb Plan - dla złożonych zadań

• 8️⃣ Praktyczny przykład - opisywanie tasków

• 9️⃣ Co dalej? Podsumowanie

To tzw. Crash Curse - dla tych którzy dopiero chcą zacząć. Jeśli korzystasz już na codzień z Cursora, to nie będzie przewodnik dla Ciebie. Natomiast już w kolejnym wydaniu podzielę się bardziej zaawansowanym use case’ami :).

Subscribe now

Pracujesz jako Product Manager i używasz ChatGPT lub Claude? Świetnie. Ale za każdym razem kopiujesz te same pliki, wklejasz kontekst od nowa, tracisz historię rozmów między sesjami?

W tym tutorialu pokażę Ci Cursor - narzędzie, które zmieni sposób, w jaki pracujesz z AI. Krok po kroku przejdziemy od instalacji do pierwszego realnego zadania. Na koniec będziesz mieć działający workflow, który możesz używać codziennie.

Ten tutorial jest dla Ciebie, jeśli:

• Jesteś Product Managerem lub Product Ownerem (na dowolnym poziomie)

• Używasz AI do pracy (ChatGPT, Claude, Gemini)

• Chcesz pracować szybciej i wygodniej

• Nie musisz umieć programować

Czas na przejście tutoriala: około 45-60 minut (z wykonaniem wszystkich zadań)

1. Dlaczego Cursor do produktowej pracy?

1.1. Problem z ChatGPT i innymi asystentami AI

ChatGPT i inni webowi asystenci to świetne narzędzia, ale mają jeden fundamentalny problem: to przede wszystkim chat.

Za każdym razem, gdy zaczynasz nową rozmowę: uploadujesz te same pliki od nowa lub masz je na STAŁE zapisane w projekcie. Nie możesz dynamicznie zarządzać kontekstami dla AI, ani tych plików łatwo aktualizować. Co więcej AI Ci tylko odpowiada, ale nie ma dostępu do Twojego świata - nie może edytować Twoich plików, korzystać z przeglądarki, tworzyć sobie skryptów.

1.2. Fundamentalna zmiana

Cursor to coś zupełnie innego. Nie tylko chatujesz z AI - wskazujesz mu folder na swoim komputerze i dajesz dostęp do czytania, zapisywania plików, korzystania z przeglądarki.

Wyobraź sobie, że masz asystenta - agenta AI, który nie tylko z Tobą „gada”, ale siedzi przy Twoim biurku i ma dostęp do Twoich dokumentów. Pracujesz na prawdziwych folderach z prawdziwymi plikami, w połączeniu z Twoimi narzędziami i mówisz AI, żeby wykonało jakąś pracę za Ciebie.

Konkretnie, Agent AI Cursora:

• Ma dostęp do całego folderu z Twoimi plikami

• Dzięki plikom możesz dobierać kontekst na jakim ma pracować agent

• Może edytować Twoje pliki za Ciebie (nie tylko proponować zmiany)

• Może wykonywać złożone, wieloetapowe akcje jako agent

• Może korzystać z Twojej przeglądarki, integracji, napisać kawałek kodu

To jest właśnie siła agentów AI. Możesz dać agentowi złożone zadanie z wieloma krokami - on je zaplanuje i po kolei wykona. Dostosuje zaproponowane kroki, gdy napotka problemy. Dopyta, gdy będzie miał wątpliwości. Może pracować równolegle nad różnymi częściami zadania.

Działa to tak:

1. Powiedz AI, co ma zrobić
2. AI sam czyta pliki, edytuje, zapisuje, korzysta z integracji, MCP, przeglądarki
3. Ty tylko przeglądasz plany, rozwiązanie i je akceptujesz

1.3. Który pakiet wybrać?

Przed zainstalowaniem Cursora musisz wybrać pakiet. Wszystkie pakiety Cursora mają generalnie te same funkcje. Różnią się tylko tym, ile możesz pracować z AI - czyli limitem tokenów. Im wyższy pakiet, tym więcej tokenów możesz wykorzystać w miesiącu.

• Hobby (Free) - $0

  • Dla kogo: Testowanie - bardzo niskie limity, szybko się skończą

• Pro - $20 / msc

  • Dla kogo: Rekomendowane dla PM-ów - wystarczy do codziennej pracy

• Wyższe pakiety - >$60 / msc

  • Dla kogo: Dla tych, którzy chcą też kodować własne produkty

“Do takiej produktowej pracy, do rozsądku, do rozkminiania, do robienia analizy konkurencji - wersja PRO będzie jak najbardziej wystarczająca”

2. Instalacja Cursora i pierwsze uruchomienie

Zacznijmy od zainstalowania Cursora na Twoim komputerze. Aplikację do pobrania znajdziesz na cursor.com

Przy pierwszym uruchomieniu Cursor poprosi Cię o:

1. Wybór motywu (jasny/ciemny) - wybierz, co Ci pasuje

2. Założenie konta - podaj email i hasło

3. Weryfikację emaila - sprawdź skrzynkę i kliknij link

✅ Zadanie dla Ciebie:

1. Wejdź na stronę cursor.com

2. Pobierz wersję na swój system (Mac lub Windows)

3. Zainstaluj Cursora na swoim komputerze

4. Otwórz Cursora i załóż konto (email + hasło)

5. Wybierz pakiet zgodnie z rekomendacją z sekcji 1 (lub zacznij od trial Pro)

Nie przechodź dalej, dopóki nie masz otwartego Cursora!

3. Interfejs (pierwsze 5 minut z Cursorem)

Masz otwartego Cursora? Świetnie. Teraz pokażę Ci, jak się w nim poruszać.

3.1. Cursor pracuje na projektach - folderach

To najważniejsza rzecz do zrozumienia: Cursor to tak naprawdę zaawansowany edytor plików. Kiedy otworzysz folder w Cursorze:

• AI widzi wszystkie pliki w tym folderze

• Może je czytać, analizować, edytować

Dlatego pierwszą rzeczą, którą zrobisz, jest otwarcie folderu - to będzie Twój projekt w którym będziesz działać.

Poza klasycznym lokalnym folderem, możesz też podłączyć repozytorium GitHub.

3.2. Tryb Editor vs Agent

Na górze Cursora zobaczysz też przycisk ustawień i przełącznik między podstawowymi trybami pracy:

• Editor - bardziej naturalny na start, panel AI jest po prawej

• Agent - pełnoekranowy tryb czatu (o tym później)

Na start zostań w trybie Editor.

3.3. Układ interfejsu

Po otworzeniu folderu zobaczysz, że Cursor ma trzy główne panele (ich kolejność może się czasem różnić - Cursor dużo eksperymentuje z domyślnym ułożeniem okien):

• Lewy panel (Explorer) - przeglądarka plików, jak Finder na Macu lub Eksplorator w Windows. Jeśli go nie ma - kliknij na ikonę z plikami w bocznym pasku.

• Środkowy panel (Editor) - tutaj edytujesz zawartość plików

• Prawy panel (AI Chat) - tutaj rozmawiasz z AI (otwierasz klikając ikonę Cursora)

3.4. Przydatne skróty klawiszowe

Nie musisz ich zapamiętywać od razu, ale mogą się przydać:

• Cmd/Ctrl + B - Pokaż/ukryj panel plików

• Cmd/Ctrl + L - Otwórz Chat z AI

• Cmd/Ctrl + I - Otwórz Composer (edytor wieloplikowy)

• Cmd/Ctrl + S - Zapisz plik

✅ Zadanie dla Ciebie:

1. W Cursorze kliknij File > Open Folder

2. Stwórz nowy folder na swoim komputerze (np. “pm-workspace” lub “cursor-demo”)

3. Otwórz ten folder w Cursorze

4. Kliknij + w panelu plików po lewej stronie

5. Stwórz plik o nazwie opis-produktu.md

6. Wpisz w nim 2-3 zdania o produkcie, nad którym pracujesz (lub wymyśl fikcyjny), np.:

„Pracuję nad aplikacją do zarządzania zadaniami dla małych zespołów. Główne funkcje to: lista zadań, przypisywanie do osób, terminy. Nasi użytkownicy to małe firmy 5-20 osób.”

Masz teraz swój pierwszy plik w Cursorze - przejdź dalej!

4. Markdown - język komunikacji z AI

Zauważ, że plik, który stworzyłeś, ma rozszerzenie .md. To format Markdown - i jest bardzo ważny przy pracy z AI.

4.1. Dlaczego Markdown, a nie Word czy PDF?

• Mało tokenów - Markdown to czysty tekst z prostymi znacznikami. Kiedy wysyłasz plik do AI, zajmuje dużo mniej miejsca niż Word czy PDF z całym ich formatowaniem.

• Czytelny dla AI - AI doskonale rozumie strukturę Markdown. Wie, co jest nagłówkiem, co listą, co cytatem.

• Czytelny dla człowieka - Nawet bez podglądu widzisz strukturę dokumentu - nagłówki zaczynają się od #, listy od -.

Markdown jest bardzo prosty - z jednej strony ja mogę wizualnie zobaczyć formatowanie, z drugiej jak wysyłam do AI, to zżera bardzo mało tokenów.

4.2. Podstawowa składnia (wystarczy do 90% pracy)

# Nagłówek główny (jeden hash)
## Podtytuł (dwa hashe)
### Mniejszy nagłówek (trzy hashe)

**pogrubienie** - dwie gwiazdki z każdej strony
*kursywa* - jedna gwiazdka z każdej strony

- wypunktowanie (myślnik i spacja)
- kolejny punkt
- jeszcze jeden

1. numerowana lista
2. kolejny punkt
3. i tak dalej

> Cytat - zaczyna się od znaku większości

To wszystko. Z tymi kilkoma znacznikami napiszesz 90% dokumentów PM-owych.

4.3. Jak wygodnie pracować z Markdown w Cursorze

Włącz zawijanie linii:
Menu View > Word Wrap (zaznacz) - bez tego długie linie będą uciekać poza ekran

Podgląd sformatowany:
Kliknij prawym przyciskiem na plik > Open Preview - zobaczysz dokument z formatowaniem

Edycja i podgląd obok siebie:
View > Editor Layout > Split Right - możesz edytować po lewej, podgląd po prawej

Opcjonalnie - plugin Markdown Editor:
Jeśli chcesz toolbar jak w Wordzie, zainstaluj plugin:

1. Kliknij ikonę Extensions (kwadraty po lewej stronie)

2. Wyszukaj “Markdown Editor”

3. Zainstaluj plugin od Markdown

✅ Zadanie dla Ciebie:

1. Otwórz swój plik opis-produktu.md

2. Włącz zawijanie linii: View > Word Wrap (zaznacz)

3. Przeformatuj go używając Markdown:

   • Dodaj nagłówek # Opis produktu

   • Stwórz sekcję ## Główne funkcje z listą punktową

   • Wyróżnij najważniejsze słowa pogrubieniem

5. Kliknij prawym przyciskiem na plik > Open Preview - zobacz jak wygląda sformatowany

Teraz masz strukturalny dokument, który AI będzie mógł łatwo czytać i edytować!

5. Podstawowa rozmowa z AI (tryb ASK)

Teraz przejdziemy do sedna - rozmowy z AI. Cursor ma trzy tryby pracy z AI: Ask, Agent i Plan. Zaczniemy od najprostszego.

5.1. Tryby rozmowy z AI

U góry panelu czatu zobaczysz dropdown z trybami:

• Ask - AI odpowiada na pytania, ale nie edytuje plików

• Agent - AI może edytować pliki za Ciebie

• Plan - AI tworzy plan działania przed wykonaniem

Na start zostań w trybie Ask. W trybie Ask:

• AI widzi pliki z Twojego projektu

• AI odpowiada, radzi, analizuje

• AI NIE edytuje plików - tylko proponuje zmiany

5.2. Wybór modelu AI

Na dole panelu AI zobaczysz dropdown z wyborem modelu. Masz do wyboru:

• Claude Sonnet - Rekomendowane do pracy PM - dobre myślenie, analiza

• Claude Opus - Najbardziej zaawansowany, ale wolniejszy i zżera dużo tokenów.

• Gemini - też bardzo dobry do pracy produktowej, od Google

• GPT-4o - Alternatywa, jeśli wolisz OpenAI

• Auto - Cursor wybiera sam (zoptymalizowane pod kodowanie)

• Composer 1 - Model przygotowany przez twórców Cursora. Tańszy, ale przeznaczony głownie do kodowania.

Moja rekomendacja: Claude Sonnet lub Gemini do rozkmin produktowych.

5.3. Używanie @ do wskazywania plików

To jest kluczowa funkcja. Aby załączyć konkretny plik jako kontekst dla swojego agenta AI, możesz użyć @:

Zamiast:

[kopiujesz całą zawartość pliku]
Na podstawie tego opisu - jakie metryki powinienem śledzić?

Użyj:

@opis-produktu.md jakie metryki powinienem śledzić?

Kiedy wpiszesz @, Cursor pokaże Ci listę plików z Twojego folderu. Możesz:

• Wybrać konkretny plik z listy

• Kontynuować pisanie, żeby przefiltrować listę

• Użyć @ kilka razy, żeby dodać wiele plików

Jak to działa pod spodem?

1. Cursor automatycznie dołącza zawartość tego pliku do Twojego pytania

2. AI widzi całą zawartość pliku

3. Odpowiedź jest oparta na rzeczywistej treści pliku

Nie musisz nic kopiować. AI ma dostęp do Twoich plików.

Przykłady:

• “Co myślisz o tym podejściu w @strategy.md?”

• “Jakie ryzyka widzisz w @roadmap.md?”

• “Porównaj @competitor-a.md i @competitor-b.md”

5.4. Kiedy używać trybu Ask?

• Chcesz zapytać o coś, nie zmieniać w plikach

• Potrzebujesz wyjaśnienia lub sugestii

• Testujesz pomysł przed wprowadzeniem zmian

• Szukasz informacji w swoich plikach

o wszystko. AI sam czyta plik.

✅ Zadanie dla Ciebie:

1. Kliknij ikonę Cursora po prawej stronie (lub Cmd/Ctrl + L)

2. Upewnij się, że masz włączony tryb Ask (nie Agent) - zobacz dropdown na górze panelu

3. Wybierz model Claude Sonnet lub Gemini

4. Wpisz w czacie: Opowiedz mi o moim produkcie na podstawie @opis-produktu.md.

5. Poczekaj na odpowiedź - AI przeczyta Twój plik i odpowie!

6. Zadaj dodatkowe pytanie: Jakie 3 najważniejsze metryki powinienem śledzić dla tego produktu?

Właśnie przeprowadziłeś pierwszą rozmowę z AI, które zna kontekst Twojego produktu!

6. Tryb Agent (AI wykonuje działania)

Tryb Ask to dobry start, ale prawdziwa moc Cursora jest w trybie Agent. Tu AI nie tylko odpowiada - on działa:

• AI może edytować pliki

• Może tworzyć nowe pliki

• Może wykonywać wieloetapowe zadania

• Pokazuje Ci zmiany do zaakceptowania

• Może kodować, odwoływać się do integracji itp.

6.1. Jak używać trybu Agent?

1. Przełącz dropdown z “Ask” na “Agent”

2. Napisz, co AI ma zrobić (nie tylko “powiedz mi”, ale “zrób to”)

3. AI wykona zadanie i pokaże Ci zmiany

4. Ty akceptujesz lub odrzucasz

Zamiast pytać:

Jak powinienem rozbudować opis produktu?

Powiedz AI, żeby zrobił:

Rozbuduj @opis-produktu.md o sekcję z opisem grupy docelowej.
Dodaj konkretne persony użytkowników. 

Przykłady zadań dla Agenta:

• “Stwórz plik z notatkami ze spotkania w formacie @meeting-template.md”

• “Rozbuduj @user-stories.md o kryteria akceptacji”

• “Dodaj sekcję z ryzykami do @roadmap.md”

6.2. Workflow z Agentem

Kiedy zlecasz AI zadanie w trybie Agent:

1. Wpisujesz polecenie - np. “Popraw literówki w @opis-produktu.md”

2. Agent analizuje - czyta pliki, planuje zmiany

3. Agent proponuje zmiany - widzisz, co chce zmienić

4. Ty przeglądasz - akceptujesz lub odrzucasz każdą zmianę

5. Zmiany są wprowadzane - plik jest zaktualizowany

6.3. Potwierdzenie działań agenta

Kiedy Agent proponuje zmiany, zobaczysz podgląd:

• Zielony = tekst dodany lub nowy

• Czerwony = tekst usunięty lub zmieniony

Przy każdej zmianie masz przyciski:

• Keep - zatwierdź tę zmianę

• Reject - odrzuć tę zmianę

Możesz też użyć Accept All żeby zaakceptować wszystko naraz.

6.4. Szybka edycja z Cmd+K

Jest jeszcze szybszy sposób na małe edycje w pliku:

1. Zaznacz fragment tekstu w pliku

2. Wciśnij Cmd/Ctrl + K

3. Wpisz instrukcję (np. “przeredaguj bardziej formalnie”)

4. AI edytuje tylko ten fragment

To świetne do szybkich poprawek bez otwierania pełnego czatu.

Możesz też dodać fragment pliku do głównwgo Chatu jako kontekst (Add to Chat).

6.5. Wielowątkowość

Możesz mieć wiele rozmów z AI naraz:

• Kliknij + w panelu AI, żeby otworzyć nowy czat

• Historia poprzednich rozmów jest dostępna z boku

• Przydatne, gdy jedno zadanie trwa długo, a chcesz zrobić coś innego

✅ Zadanie dla Ciebie:

1. Przełącz tryb z Ask na Agent (kliknij na “Ask” i wybierz “Agent”)

2. Wpisz: Rozbuduj @opis-produktu.md o sekcję “## Grupa docelowa”

   z opisem 2-3 person użytkowników.

3. Poczekaj aż agent zaproponuje zmiany

4. Przejrzyj zmiany (zielone = dodane, czerwone = usunięte)

5. Kliknij Keep przy zmianach, które chcesz zachować

6. Sprawdź plik - zmiany są już wprowadzone!

Gratulacje - AI właśnie wyedytowało Twój plik za Ciebie!

7. Tryb Plan - dla złożonych zadań

Jest jeszcze trzeci tryb pracy z AI: Plan. Używasz go, gdy zadanie jest złożone i chcesz mieć kontrolę nad tym, co AI zrobi, zanim zacznie działać.

Tryb Agent:

• Od razu wykonuje zadanie

• Pokazuje wynik

• Szybki, ale mniej kontroli

Tryb Plan:

• Najpierw pokazuje plan działania oraz często zadaje pytania doprecyzowujące.

• Możesz go edytować

• Dopiero potem wykonuje

7.1. Jak działa tryb Plan?

1. Dajesz zlecenie - opisujesz, co chcesz osiągnąć

2. AI tworzy plan - pokazuje szczegółowo jak zrozumiał zadanie oraz rozpisuje kroki, które zamierza wykonać

3. Ty przeglądasz plan - możesz go edytować, dodać komentarze

4. Klikasz Build - AI wykonuje plan krok po kroku

To, co jest fajne, to to, że ja mogę na tym etapie sobie zmienić ten plan, tego, co ten agent ma zrobić.

7.2. Kiedy używać trybu Plan?

• Złożone, wieloetapowe projekty - np. “stwórz kompletną dokumentację produktu”

• Gdy potrzebujesz kontroli - chcesz widzieć plan Agenta przed wykonaniem i mieć na niego wpływ

Dla większości codziennych zadań będziesz stosować tryb Ask i Agent. Plan używaj dla większych zadań.

✅ Zadanie dla Ciebie:

1. Przełącz tryb na Plan (obok Ask i Agent w dropdown)

2. Wpisz: Rozbuduj mój opis produktu @opis-produktu.md o następujące sekcje: 1. Główne problemy użytkowników, 2. Kluczowe metryki sukcesu, 3. Konkrencja.

3. Przeczytaj plan, który AI przygotuje

4. Jeśli chcesz coś zmienić - edytuj plan ręcznie lub dopisz komentarz

5. Kliknij Build żeby AI wykonał plan

Tryb Plan daje Ci kontrolę nad złożonym zadaniem zanim AI zacznie działać.

8. Praktyczny przykład - opisywanie tasków

Dość teorii. Zróbmy teraz coś praktycznego - stwórzmy workflow do tworzenia tasków dla zespołu developerskiego. To zadanie, które robisz pewnie w swojej pracy.

8.1. Problem: AI pisze nie tak jak chcesz

Kiedy poprosisz AI o napisanie taska, dostaniesz często coś takiego:

Napisz mi task do JIRA o tym, że chcę stworzyć agenta AI 
do odpowiadania klientom w naszej aplikacji.

Rezultat: Rozbudowany, techniczny opis z milionem szczegółów, które nie muszą wcale być prawdą. AI nie wie, jak U was w zespole opisujcie zadania.

# Stworzenie agenta AI do automatycznego odpowiadania klientom w aplikacji

## Typ
Story / Task

## Priorytet
Medium / High

## Opis

Stworzenie agenta AI, który będzie automatycznie odpowiadał na pytania i zapytania klientów w aplikacji Product Academy. Agent ma wspierać użytkowników Campus Product Academy, odpowiadając na pytania związane z kursami, szkoleniami i funkcjonalnościami platformy.

## Cel biznesowy

- Zwiększenie dostępności wsparcia dla klientów (24/7)
- Redukcja obciążenia zespołu supportu poprzez automatyzację odpowiedzi na częste pytania
- Poprawa doświadczenia użytkowników dzięki szybkim i precyzyjnym odpowiedziom
- Skalowanie wsparcia bez proporcjonalnego zwiększania zespołu

## Zakres prac

### 1. Analiza wymagań
- Zidentyfikowanie najczęstszych pytań i scenariuszy wsparcia
- Określenie zakresu wiedzy, którą agent powinien posiadać
- Zdefiniowanie integracji z istniejącymi kanałami komunikacji

### 2. Projektowanie rozwiązania
- Wybór technologii AI/LLM odpowiedniej do potrzeb
- Projekt architektury agenta i jego integracji z aplikacją
- Określenie źródeł wiedzy (dokumentacja, kursy, FAQ)

### 3. Implementacja
- Budowa agenta AI z dostępem do bazy wiedzy Product Academy
- Integracja z platformą Campus (Circle) lub innymi kanałami komunikacji
- Implementacja mechanizmów eskalacji do zespołu wsparcia

### 4. Testowanie i optymalizacja
- Testy jakości odpowiedzi
- Optymalizacja na podstawie feedbacku użytkowników
- Monitoring i analityka działania agenta

## Kryteria akceptacji

- [ ] Agent AI jest zintegrowany z aplikacją i dostępny dla użytkowników
- [ ] Agent odpowiada na najczęstsze pytania z zakresu kursów, szkoleń i funkcjonalności platformy
- [ ] Implementowany jest mechanizm eskalacji do zespołu wsparcia, gdy agent nie jest w stanie odpowiedzieć
- [ ] Agent posiada dostęp do aktualnej bazy wiedzy Product Academy
- [ ] Zaimplementowany jest system monitoringu i analityki odpowiedzi agenta
- [ ] Dokumentacja techniczna rozwiązania jest kompletna
- [ ] Przeszkolony zespół wsparcia w zakresie zarządzania i optymalizacji agenta

## Wymagania techniczne

- Integracja z platformą Campus (Circle) lub innymi kanałami komunikacji w aplikacji
- Dostęp do bazy wiedzy zawierającej materiały kursowe i dokumentację
- Możliwość ciągłego uczenia się i aktualizacji wiedzy
- Bezpieczeństwo danych użytkowników zgodne z RODO

## Szacowany czas
TBD

## Zależności

- Dostęp do bazy wiedzy Product Academy
- Integracja z platformą komunikacji
- Zatwierdzenie wybranej technologii AI/LLM

## Notatki

Agent powinien być zaprojektowany w sposób umożliwiający łatwą rozbudowę i dodawanie nowych funkcjonalności w przyszłości. Ważne jest, aby odpowiedzi były spójne z tonem komunikacji Product Academy i dostosowane do potrzeb różnych person użytkowników.

Ja np. przychodzę do zespołu głównie z problem użytkownika, a to zespół definiuje rozwiązanie i jeśli chce to opisuje sobie rozwiązanie technicznie. Opis moich tasków jest bardzo prosty.

8.2. Rozwiązanie: Stwórz swój format

Zamiast za każdym razem tłumaczyć AI, jak ma pisać, stwórz plik z formatem. AI będzie go używać jako wzorca.

Krok 1: Stwórz plik opisujący forma zadań

Stwórz nowy plik jira-task-format.md:

# Format opisu zadań do JIRA

Chcę, żeby zadania były tworzone w prosty sposób:

## Struktura
- Krótki, konkretny tytuł (max 10 słów)
- Krótki opis: dlaczego to robimy + co jest do zrobienia
- Bez szczegółów technicznych implementacji
- Przynajmniej jedno kryterium akceptacji

## Zasady
- Jeśli brakuje informacji, zapytaj mnie
- Opisuj zadania po angielsku
- Zapisuj do folderu tasks/

## Przykład

**Tytuł:** Add AI assistant to customer support

**Opis:** 
We want to reduce response time for common customer questions.
Create an AI assistant that can answer FAQ-type questions in our app.

**Acceptance Criteria:**
- [ ] Assistant responds to at least 10 most common questions
- [ ] Response time under 3 seconds

Krok 2: Poproś o użycie formatu

Teraz możesz napisać:

Napisz mi task do JIRA wykorzystaj format @jira-task-format.md 
o tym, że chcę stworzyć funkcję eksportu raportów do PDF.

Rezultat: Krótki, konkretny opis zgodny z Twoim formatem.

8.3. Kluczowa zaleta

Bardzo prosto mogę zarządzać tym kontekstem. Jeśli chcę zmienić format, to po prostu edytuję plik. Żadnego uploadowania na nowo.

Kiedy zmieni się Twój sposób opisywania zadań - edytujesz jeden plik. Wszystkie przyszłe taski będą używać nowego formatu.

Możesz mieć różne formaty dla różnych typów zadań:

• jira-spike-format.md - dla zadań badawczych

• jira-bug-format.md - dla zgłoszeń błędów

• jira-feature-format.md - dla nowych funkcji

Wystarczy użyć odpowiedniego pliku przez @.

Wystarczy użyć odpowiedniego pliku przez @.

✅ Zadanie dla Ciebie:

1. Stwórz folder tasks w swoim projekcie (kliknij prawym > New Folder)

2. Stwórz plik jira-task-format.md i wklej do niego przykładowy format powyżej

3. Dostosuj format do swoich potrzeb (np. zmień język na polski, dodaj pola)

4. Przełącz na tryb Agent

5. Wpisz: Napisz mi task do JIRA wykorzystaj format @jira-task-format.md

   o tym, że chcę dodać możliwość filtrowania listy zadań po statusie.

6. Przejrzyj wynik - czy jest zgodny z Twoim formatem? Jeśli nie - popraw format i spróbuj ponownie

Masz teraz własną procedurę tworzenia tasków, którą możesz używać wielokrotnie!

9. Co dalej? Zaawansowane możliwości

Cursor ma znacznie więcej możliwości niż te, które pokazałem w tym tutorialu. Oto funkcje, które warto poznać:

• Slash commands (/nazwa) - Możesz zapisać często używane prompty i wywoływać je jednym poleceniem. Zamiast pisać za każdym razem “napisz task do JIRA...”, możesz stworzyć komendę /task i używać jej jednym kliknięciem.

• AGENTS.md - kontekst projektu - Specjalny plik, który AI czyta automatycznie przy każdej rozmowie. Możesz tam wpisać kontekst firmy, produktu, zespołu - i AI zawsze będzie go znać.

• Rules - stałe zasady dla AI - Pliki z zasadami, które AI zawsze bierze pod uwagę. Np. “zawsze pisz po polsku”, “używaj mojego stylu pisania”, “pamiętaj o kontekście firmy”.

• Skills - inteligentne procedury - Bardziej zaawansowana wersja Rules - AI sam rozpoznaje, kiedy użyć danej procedury i automatycznie ją stosuje.

• Serwery MCP - integracje z narzędziami - Cursor może się łączyć z zewnętrznymi narzędziami:

  • JIRA - tworzenie i aktualizacja tasków bezpośrednio

  • Notion - synchronizacja z dokumentacją

  • Figma - dostęp do designów

  • Slack - wysyłanie wiadomości

• Możliwość “rozmawiania z kodem” Twojego produktu

Te możliwości i konkretne zastosowania Cursora w pracy produktowej pokazałem na moim warsztacie Masterclass w Product Academy (od 37 minuty):

Tutaj pełne nagranie:

👉 Jeśli chcesz kontynuacji poradnika krok po kroku o te zaawansowane opcje - daj znać w komentarzu (lub odpisz na maila), będę wiedział, że warto je przygotowywać :)

Leave a comment

Podsumowanie

Przeszliśmy razem przez podstawy Cursora. Teraz umiesz:

1. Zainstalować Cursora i wybrać odpowiedni pakiet

2. Stworzyć folder roboczy i pierwsze pliki Markdown

3. Rozmawiać z AI w trybie Ask - używając @ do wskazywania plików

4. Zlecać AI edycję plików w trybie Agent - i przeglądać zmiany

5. Używać trybu Plan dla złożonych zadań

6. Tworzyć własne formaty i procedury - jak format tasków JIRA

Cursor to narzędzie, które poznaje się przez używanie. Im więcej będziesz go używać, tym więcej odkryjesz sposobów na przyspieszenie swojej pracy. Powodzenia w jego stosowaniu!

✅ Twoje ostatnie zadanie:

1. Wybierz jedno realne zadanie z Twojej pracy (np. przygotowanie notatki ze spotkania, opis funkcji, analiza feedbacku)

2. Wykonaj je w Cursorze zamiast w ChatGPT

3. Porównaj doświadczenie - czy było szybciej? Wygodniej?

4. Jeśli tak - zacznij używać Cursora regularnie przez tydzień

Claude Code, Cursor - to doskonałe środowiska pracy. Początkowo dla developerów, teraz coraz bardziej używane przez PM-ów i pozostałą część zespołów. Z drugiej strony praca w terminalu, IDE, komendy - to coś, co wiele osób odstrasza.

Claude Cowork ma wypełnić tę lukę.

Jest to Agent AI z dostępem do plików i przeglądarki, które w końcu nie wymaga od Ciebie znajomości terminala. Przetestowałem wiec go w praktyce, żebyś Ty nie TEŻ musiał(a).

🔔 Ruszyła kolejna edycja 10x Product Bootcamp, gdzie łączymy AI z doskonałym mindsetem produktowym. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach z AI. Zacznij pracować w ten sposób.

Oto moje pierwsze eksperymenty i spostrzeżenia:

• 1️⃣ Czym jest Claude Cowork?

• 2️⃣ Kluczowe funkcje Coworka

• 3️⃣ Moje pierwsze eksperymenty

• 4️⃣ Ograniczenia Cowork (po dłuższych testach)

• 5️⃣ Podsumowanie i moja ocena

Subscribe now

1️⃣ Czym jest Claude Cowork?

W skrócie: Cowork to agnet Claude Code dla osób, które nie chcą dotykać terminala. Sami nazywają to wprost:

Kontekst całego produktu jest ciekawy i stanowi doskonałą lekcję dla każdego PMa jak teraz można budować produkty. Boris Cherny, szef Claude Code w Anthropic, zauważył że nie-techniczny użytkownicy masowo próbują używać Claude Code do nieprogramistycznych zastosowań - walczą z linią komend, żeby organizować pliki, robić research, przetwarzać dokumenty. Samo narzędzie było na tyle użyteczne, że ludzie przebijali się przez techniczne bariery.

Więc Cherny zbudował „fix”. W 10 dni. Nazwał to Claude Cowork.

Fundamentalna zmiana z Cowork polega na tym, że nie tylko chatujesz z AI - wskazujesz Claude’owi folder na swoim komputerze i dajesz mu dostęp do czytania, zapisywania plików, korzystania z przeglądarki.

Wyobraź sobie, że masz asystenta, który nie tylko z Tobą „gada”, ale siedzi przy Twoim biurku i ma dostęp do Twoich dokumentów i komputera. Pracujesz na prawdziwych folderach z prawdziwymi plikami i mówisz AI żeby wykonało jakąś prace dla Ciebie.

Pod spodem działa ta sama technologia co Claude Code. Ale interfejs jest zupełnie inny - wizualny, bez terminala.

Cowork wystartował w zeszłym tygodniu i był dostępny tylko w wersji MAX (200 USD/miesiąc). Teraz trafiło do planu PRO - dzięki czemu miałem okazję przetestować go przez ostatnie kilka dni.

Czy to jest tak potężne jak Claude Code? Nie. Nie możesz budować custom agentów. Nie widzisz dokumentów w tym samym widoku. Ale to może być fajny złoty środek, jeśli praca w terminalu (Claude Code) czy developerskim IDE (nie jest dla Ciebie).

2️⃣ Kluczowe funkcje Coworka

2.1. Praca w folderach

To jest fundament Cowork. W lewym dolnym rogu znajdziesz opcję “Open folders”. Wybierasz folder ze swojego dysku, dajesz Claude’owi dostęp do zmiany plików (odczytywania / zapisywania), i od teraz Claude pracuje wewnątrz tego kontekstu.

Dokładnie tak działa Cursor / Claude Code - różnica w tym, że robisz to przez GUI zamiast przez terminal.

2.2. Korzystanie z Chrome

Tu robi się jeszcze ciekawiej. Claude Cowork zintegrowany jest z wtyczką do Chrome i dzięki temu daje Cowork możliwość kontrolowania Twojej przeglądarki.

Włączasz go w menu Connectors (przycisk plus w lewym dolnym rogu). Kiedy jest włączony, możesz powiedzieć Claude’owi żeby nawigował do URL, spojrzał na stronę i wyciągnął informacje.

W chrome zobaczysz pomarańczową poświatę wokół taba przeglądarki kiedy Claude go kontroluje. Dosłownie używa “oczu” przez Chrome connector żeby patrzeć na to co jest na ekranie.

2.3. Wieloetapowa i równoległa praca jako agent

To jest prawdziwa siła agentów AI. Możesz dać Cowork złożone zadanie z wieloma krokami - i on je po kolei wykona. Dostosuje te zaproponowane kroki, gdy napotka problemy. Dopyta, gdy będzie miał wątpliwości.

Możesz mu dać explicite listę kroków:

Zadanie: Przygotuj analizę konkurencji

1. Przeczytaj notatki z folderu /research
2. Wejdź na stronę competitor1.com i zbierz info o pricing
3. Wejdź na stronę competitor2.com i zrób to samo
4. Porównaj z naszym pricingiem z pliku pricing.md
5. Stwórz tabelę porównawczą w Excel
6. Napisz rekomendacje w pliku recommendation.md

Ale co ważniejsze - Cowork potrafi sam zaplanować kroki. Możesz po prostu napisać:

Przygotuj mi pełną analizę konkurencji na podstawie notatek z folderu /research. 
Sprawdź strony konkurentów, porównaj z naszą ofertą, daj rekomendacje.

I Cowork sam rozłoży to na plan z etapami, wykona je sekwencyjnie, a Ty widzisz postęp w panelu “Progress”. Możesz nawet dawać feedback do tego planu.

Możesz też uruchomić równoległe sesje dla osobnych tasków.

2.4. Claude Skills

Skills to coś, co robi prawdziwą różnicę w ekosystemie Claude - i są też wykorzystywane w Cowork.

Czym jest skill? To plik z instrukcjami, który mówi Claude’owi jak robić coś konkretnego. W uproszczeniu jest to prompt, który jest inteligentnie doklejany do Twojego promptu, gdy Claude uzna że należy go zastosować. Niezależnie od wątku / projekty w którym korzystasz z Claude.

Możesz mieć proste, własne skille - na przykład:

• Jaki jest Twój styl pisania (formalny vs luźny, krótkie vs długie zdania)

• Jak formatujesz dokumenty w swojej firmie

• Jakich terminów używasz w branży

Ale masz też dostęp do rozbudowanych, gotowych skilli od Anthropic. Oficjalne skille znajdziesz na github.com/anthropics/skills:

• Front-end design - tworzenie landing pages produkcyjnej jakości

• Presentations - tworzenie prezentacji w PowerPoint

• Spreadsheets - praca z Excelem i danymi

• PDF - przetwarzanie i tworzenie dokumentów PDF

• Brand guidelines - zachowanie spójności wizualnej

• I więcej...

Gotowe skill znajdziesz też w internecie. Aby je zainstalować: Settings → Capabilities → przewiń do Skills → add your own → uploaduj plik SKILL.md.

Subscribe now

3️⃣ Moje pierwsze eksperymenty

Teoria teorią, ale oczywiście postanowiłem sprawdzić co Cowork potrafi w praktyce. Oto kilka zadań które mu dałem.

3.1. Analiza wywiadów + competitive research

Miałem folder z 11 transkrypcjami wywiadów z userami. Chciałem wyciągnąć kluczowe potrzeby i sprawdzić jak konkurencja je adresuje. Fajnie byłoby całość dostać w jednym pliku.

Chciałem przetestować tu

• jak Cowork działa na plikach

• czy jest w stanie wykonywać wielostopniowe złożone operacje

• jak działa korzystanie z Chrome

Prompt który dałem:

Przeanalizuj wywiady z folderu /interviews/transcripts. 
Wyciągnij top 5 analytics needs.
Następnie:
1. Otwórz Intercom.com i znajdź info o ich analytics features
2. Otwórz Zendesk.com - to samo
3. Otwórz HubSpot.com - to samo
4. Dla każdego need zrób tabelę: które narzędzie to ma, jak to rozwiązuje
5. Stwórz dokument 'competitive-analysis.md' w folderze /research
6. Dodaj recommendations: gdzie są gaps, co możemy zrobić lepiej
Potem daj mi znać że skończyłeś.

Co się stało:

Cowork przeczytał wszystkie 11 wywiadów, wyciągnął potrzeby, a potem sam otworzył Chrome i zaczął przeglądać strony konkurencji.

Co fajne - na stronie Intercom napotkał na problem (nie mógł znaleźć strony) i sam go rozwiązał. Widziałem w panelu Steps jak nawiguje po Intercom, szuka w menu “Product”, używa wyszukiwarki gdy strona nie istnieje.

Na końcu stworzył dokument competitive-analysis.md z:

• Podsumowaniem top 5 potrzeb z wywiadów

• Tabelą porównawczą (potrzeby vs jak rozwiązuje Intercom vs Zendesk vs HubSpot)

• Sekcją gaps i recommendations

Rzeczywiście powstał taki dokument tez na dysku:

3.2. Research na Reddicie (i jego ograniczenia)

Chciałem zbadać “pain pointy” PM-ów związane z user research. Plan był prosty - niech Cowork przeszuka Reddit, tam przecież dzieje się wiele produktowych dyskusji.

Prompt który dałem:

Zadanie: Zbadaj pain pointy PM-ów związane z user research

Workflow:

1. Otwórz Reddit.com/r/productmanagement
2. Wyszukaj posty o ‘user research’, ‘user interviews’, ‘customer discovery’
3. Przeczytaj top 10 threads z ostatnich 3 miesięcy
4. Dla każdego thread - wyciągnij:
   - Główny pain point
   - Jak ludzie to teraz rozwiązują (workarounds)
   - Co by chcieli mieć (ideal solution)

5. Zrób to samo dla r/userexperience
6. Agreguj wszystko w /research/reddit-pain-points.md

Przeglądaj autonomicznie.

Co się stało:

Cowork otworzył Chrome, próbował wejść na Reddit... i dostał blokadę. Reddit ma security policies które blokują automatyczne przeglądanie przez AI.

Ale tu się dzieje coś ciekawego. Cowork nie poddał się. Sam zaproponował alternatywę - użył Web Search i znalazł dane z innych źródeł:

• Raporty branżowe (Maze, User Interviews, ResearchOps)

• Artykuły i blogi PM-ów

• Badania z 2024-2025

Na końcu stworzył raport z Top 10 “pain pointów”.

• Z jednej strony - widać że coraz więcej stron blokuje roboty AI.

• Z drugiej - Cowork wykazał się inicjatywą i znalazł obejście. To nie jest idealne (wolałbym mieć dane z Reddita), ale pokazuje jak agent radzi sobie z przeszkodami.

BTW. Dla Reddita ja zbudowałem sobie dedykowany scraper (przez API) ale też można skorzystać po prostu z Perplexity:

3.3. Tworzenie prezentacji dla stakeholderów

Na podstawie danych z Eksperymentu 1 postanowiłem przetestować tworzenie prezentacji. Dałem Cowork szczegółową strukturę 8 slajdów.

Prompt który dałem:

Prepare stakeholder presentation o feature: 'Analysis for Creator Bots'

ZADANIE - zrób to autonomicznie:

1. RESEARCH PHASE:
   - Przeczytaj dane z folderu

2. CREATE PRESENTATION:
   - Otwórz Keynote (lub PowerPoint jeśli nie ma Keynote)
   - Stwórz 8-slide deck: Title, Problem, User Need, Market Validation, 
     Competitive Landscape, Our Opportunity, Recommendation, Next Steps

3. VISUAL ENHANCEMENT:
   - Dla każdego slide znajdź relevant icon/image
   - Użyj consistent color scheme

4. SAVE:
   - Zapisz jako .pptx w /presentations
   - Export też jako PDF

Rób to wszystko autonomicznie. Update me tylko przy major milestones.

Co się stało:

Cowork zaczął działać - widziałem w Steps że pracuje, czyta dane, planuje slajdy. Użył Claude Skill do tworzenia prezentacji PPTX.

Byłem podjarany, bo widziałem że już kilka minut pracuje i...

W drugim podejściu (następnego dnia) stworzył prezentację.

Efekt? Mocno “taka sobie”. Wiele elementów się rozjeżdżało, formatowanie niespójne.

Prezentacje to chyba za ambitne zadanie na obecny stan Cowork. Lepiej wygenerować content w Markdown i samemu wrzucić do PowerPointa. Albo użyć dedykowanego narzędzia typu Gamma.ai.

Subscribe now

4️⃣ Ograniczenia Cowork (po dłuższych testach)

Pobawiłem się Coworkiem dłużej i przetestowałem do rzeczywistej produktowej pracy - bardziej konkretnej analizy wywiadów, konkurencji, przetwarzanie dokumentów.

Mała prywata: Na początku próbowałem też korzystać z przykładów od dużych influencerów produktowych. Szybko się okazało, że większość z nich… nie działa.

Po tym jak poznałem Cowork bliżej, widzę że nie mają prawa działać. Wyglądają jakby pisał je ChatGPT dla kogoś kto nigdy nie używał tego narzędzia. Sam Cowork mówi, że są one niewykonalne 🤷‍♂️.

Oto co zauważyłem:

✅ Co działa fajnie

• Lokalne pliki - czytanie, tworzenie, organizowanie. To core funkcjonalność i działa solidnie.

• Analiza dokumentów - przetwarzanie tekstu, wyciąganie insights, tworzenie podsumowań.

• Wieloetapowy Agent AI - zwykł Claude też już go coraz bardziej ma. Ale tu może robić jeszcze więcej.

❌ Co działa “tak sobie”

• Connectors - czasem zawodne, nie zawsze się wywołają, a czasem… wywołają się zupełnie niepotrzebnie

• AI w Chrome - nie zawsze dobrze działa, działa też bardzo powoli

• Bot detection - niektóre strony blokują automatyczne przeglądanie

• Brak wyboru kontekstu - nie da się precyzyjnie wskazać które dokumenty ma Claude brać pod uwagę z folderu. W Cursorze czy Claude Code używasz @ żeby dodać konkretny plik do kontekstu. Tu dajesz dostęp do całego folderu i Claude sam decyduje co czyta.

• Zjadanie tokenów - tak samo jak Claude Code, Cowork bardzo szybko konsumuje limit. Kilka większych zadań i widzisz jak twój limit tokenów topnieje

• Mac only - na razie brak wersji na Windows i Linux. Jeśli nie masz Maca, musisz czekać

5️⃣ Podsumowanie i moja ocena

Eksperymentowanie z Cowork mnie mocno zajarało. IMHO to może być przyszłość.

Ale czy porzucam Cursora, w którym pracuję na co dzień? Nie. Przynajmniej nie teraz.

• Prawda jest taka: dużo z tych rzeczy dało się już robić w Claude Desktop przez Connectors i MCP. Ale teraz jest jeszcze łatwiej - nie musisz konfigurować serwerów MCP, konektorów do plików itp.

• Dla kogo to jest? Myślę że Cowork to świetna alternatywa dla osób, które nie chcą schodzić do technikaliów. Jeśli terminal Cię przeraża, a chcesz agentowych możliwości - to dobre miejsce żeby zacząć.

• Co mi przeszkadza: Bardzo szybkie zjadanie tokenów. Tak samo jak w Claude Code - kilka zadań i widzisz jak limit PRO topnieje. W Cursorze zupełnie tego nie odczuwam.

Mocno czekam na rozwój. IMHO Anthropic jest na drodze do zbudowania pierwszego prawdziwego agenta dla non-koderów. Są skupieni, szybko iterują, mają fajne pomysły.

Mój drugi bet w tym wyścigu? Google. Dzięki integracji z całym Google Workspace (Docs, Sheets, Calendar, Gmail, Drive) mogą zbudować agenta który żyje tam, gdzie większość ludzi pracuje.

A ja? Sam na razie zostaję na Cursorze + Cluade Desktop i Gemini. A że Cowork jest wbudowany w Claude Desktop to… czasem będzie wykorzystywany :)

Niezależnie - mocno zachęcam do testów.