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 👇

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.

Przegryzłem się przez te dane, żeby wyciągnąć to, co najważniejsze dla nas - Product Managerów i Zespołów Produktowych:

• 1️⃣ Co AI faktycznie robi za PM-a?

• 2️⃣ Jakich narzędzi używają PMowie?

• 3️⃣ Wpływ na szybkość pracy

• 4️⃣ Które narzędzie ma Product-Market Fit?

• 5️⃣ Jaki jest Twój stack AI?

• 🔗 Pełne wyniki ankiety

No i nie mogłem się jak zawsze powstrzymać by dorzucić kilka słów komentarza oraz jak to wygląda u mnie ;)

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.

Subscribe now

1️⃣ Co AI faktycznie robi za PM-a?

Z ankiety wynika, że jako PM-owie najczęściej zaprzęgamy AI do trzech zadań:

1. Pisanie PRD (21.5%) – standard, automatyzacja „papierologii”.

2. Tworzenie mockupów i prototypów (19.8%) – to ciekawe, bo wchodzimy mocno w buty designerów.

3. Poprawa komunikacji (18.5%) – maile, prezentacje, szlifowanie tonu.

Prototypowanie na drugim miejscu to ciekawy i IMHO dobry sygnał. Narzędzia jak Lovable, v0 czy Figma Make zmieniają granice ról. Ale jest też druga strona medalu. Patrząc na dolną część listy, widać wyraźny wzorzec: AI pomaga PM-om w produkcji, ale słabo w myśleniu strategicznym. User research to tylko 4.7%, roadmap ideas zaledwie 1.1%.

Opanowujemy to jak szybko wydobyć pomysły z głowy i przekształcić je w dokumenty, prototypy, komunikację. Ale wciąż jest ogromny obszar gdzie jest główna dźwignia nowoczesnego PMa - discovery, research, strategia. Czyli myślenia o tym, co w ogóle budować.

👨‍💻 Jak to wygląda u mnie?

U mnie wygląda to nieco inaczej. Owszem w topce mam też komunikację i pisanie, ale… bardzo dużo używam też AI do

• Opportunity sizing i potem ewaluacji po wdrożeniu - szacowanie wielkości opportunity, analiza metryk, sprawdzanie hipotez w danych. Mam folder z SQL queries, które tworzę z pomocą AI, i mogę je łatwo wyszukiwać i aktualizować.

• Thinking partner do decyzji produktowych - rozkminianie problemów z różnych perspektyw. Nie chodzi o to, żeby AI podjęło decyzję za mnie, tylko żeby pomogło mi zobaczyć problem z różnych perspektyw. Odpalam równolegle trzech agentów z różnymi promptami i po 15 minutach mam trzy kompletne analizy, które mogę porównać obok siebie.

• Product discovery - synteza research, analiza konkurencji, identyfikacja patterns w danych jakościowych.

• Ideacja - generowanie i rozwijanie pomysłów. AI świetnie sprawdza się jako “paring partner” przy brainstormingu. Może jestem po prostu mało kreatywny i potrzebuję wsparcia :D.

Uważam też, że full stackowy, nowoczesny PM - mindsetowo jest też bardzo blisko foundera produktu. Dlatego polecam spojrzeć jak to wygląda właśnie u founderów:

Mi jeszcze na pewno brakuje Growth i GTM. Ze strategią eksperymentuje coraz więcej, ale jeszcze nie jest to mój główny use case.

2️⃣ Jakich narzędzi używają PM-owie?

Według ankiety, ChatGPT dominuje - używa fo 57.7% PM-ów . I jest to jak widać zbieżne z innymi rolami (poza inżynierami).

Na drugim miejscu Claude, potem Gemini. Perplexity też jest wysoko, prawdopodobnie dzięki silnym możliwościom research.

Ale ciekawe rzeczy dzieją się dalej na liście. Lovable (8.7%) i Cursor (7.7%) wchodzą do top 7 dla PM-ów. To potwierdza trend - PM-owie coraz częściej budują rzeczy (prototypy) sami, wkraczając w obszary tradycyjnie zarezerwowane dla designu i inżynierii.

👨‍💻 Mój aktualny stack AI

U mnie jest trochę inaczej - przede wszystkim - ChatGPT u mnie od kilku miesięcy leży. Kilka miesięcy temu zrezygnowałem z wersji premium i prawie go nie używam. W każdym z moich topowych use ceas’ów mam inne narzędzie które zdecydowanie bardzie mi odpowiada.

Mój główny stack wygląda teraz tak:

Cursor

Moje główne narzędzie pracy. To jedna z kluczowym zmian dla mnie od kilku miesięcy. Tak, to narzędzie (IDE) dla programistów. Ale właśnie dlatego może być świetnym środowiskiem pracy.

Dlaczego Cursor a nie ChatGPT (lub inny asystent)? Standardowy asystent działa w izolacji. Wklejasz tekst, dostajesz odpowiedź, koniec.

Cursor to Twoje środowisko pracy, które rozumie kontekst projektu, pracuje z Tobą nad plikami i ma możliwość pracy w agentowy sposób - wykonuje za Ciebie całe działania, fizycznie na komputerze. Może czytać całe foldery, edytować dokumenty, aktualizować kontekst między sesjami, przygotowywać i wykonywać skrypty, integracje. To jest fundamentalna różnica.

• Cursor ma Twój cały kontekst - może pracować na Twoich plikach. Możesz wrzucić do rozmowy odpowiednie dokumenty, markdown, spreadsheets, PDF-y, kod - wszystko w jednym miejscu.

• Cursor to Asystent z twoimi narzędziami. Przez MCP łączysz się z Notion, Linear, Figma, Google Drive.

• Cursor to Asystent który pracuje dla ciebie - AI, które wykonuje zadania powtarzalnie, nie tylko odpowiada na pytania.

• Dzięki Cursorowi możesz rozmawiać z kodem Twojego produktu - w szczegółach wiedzieć co i jak działa, bez angażowania do wszystkiego developerów.

• Corsor umożliwia wybranie modelu z którym aktualnie chcesz pracować - ChatGPT, Gemini, Claude - możesz łatwo zmieniać co sesję.

Staram się dzięki temu stworzyć swój mały ProductOS z coraz bardzie zaawansowanymi workflow: od analizy researchu po automatyczne generowanie ticketów, czy release notes przez protokoły MCP do odpowiednich narzędzi.

Jeśli chcesz poznać postawy mojego workflow pracy z Corsorem - wpadaj na LIVE → https://luma.com/ja09y0v

Claude (od Anthropic)

Głównie wersja desktop, za którą uwielbiam Calude. Świetny projekty z pamięcią kontekstu, proste integracje z narzędziami przez MCP (Model Context Protocol), Claude Skills (custom workflows) inteligenie włączające się w rozmowę, i w ogóle działanie rozmowy w formie agenta.

Aplikacja Claude’a IMHO najlepiej wspiera workflow PM-a, nawet jeśli sam model czasem przegrywa z konkurencją w czystej logice.

Gemini (od Google):

Od wersji 3 to dla mnie najlepszy model do wielu zastosowań. Fatalna aplikacja niestety (Google, naprawcie to!), ale przez to jak dobrze dla mnie działa sam model - bajka do wielu zastosowań.

• Bardzo często używam Gemini jako thinking partner do rozkminić różnego rodzaju.

• Świetny Deep Research, który pozwala głęboko znaleść info na temat konkurencji, trendów rynkowych, case studies, moich danych.

• Bardzo duża zaleta - natywna współpraca z Google Drive. Mam wszystkie dokumenty w jednym miejscu i AI może do nich sięgać bezpośrednio.

No i mam Gemini w pakiecie Google Workspace, więc finansowo to po prostu ma sens.

3️⃣ Wpływ na szybkość pracy

Według ankiety: 63% PM-ów oszczędza 4+ godzin tygodniowo. To pół dnia pracy. Tylko 1-5% respondentów mówi, że AI “nie jest szybsze niż robota ręczna.”

IMHO te liczby to raczej odczucie prywatne niż coś zmierzonego.

Jak to widzę u siebie? Szczerze? Te oszczędności czasu na razie bywają złudne.

• Trzeba się nauczyć. Każdy nowy workflow wymaga eksperymentowania. Zanim nauczysz się efektywnie używać Cursora, spędzisz kilka godzin na próbach i błędach. Zanim znajdziesz właściwy prompt do syntezy research, przetestujesz kilkanaście wersji.

• Wiele to nieudane eksperymenty. AI halucynuje. Generuje generic outputs. Czasem produkuje rzeczy, które wyglądają dobrze, ale są fundamentalnie błędne. Trzeba to wyłapać i poprawić.

Ale finalnie IMHO na razie wcale nie poświęcamy często mniej czasu, ale rzeczy które wychodzą są dużo lepsze, głębsze i lepiej przemyślane.

4️⃣ Które narzędzie ma Product-Market Fit?

W badaniu zadano klasyczne pytanie Seana Ellisa: „Jak bardzo byłbyś rozczarowany, gdybyś stracił dostęp do tego narzędzia?”.

Dla większości PM-ów to ChatGPT (50.2%) ma największy PMF.

👨‍💻 Co ma największy PMF u mnie?

Zdecydowanie Claude.

Choć Cursora używam chyba najwięcej, to jednak łatwo go zastąpić. Google Antigravity, natywny VS Code z rozszerzeniami AI, Windsurf - alternatyw jest sporo i wszystkie w miarę podobnie.

Claude przez swoje natywne funkcje ułatwiające workflow pracy w Claude Desktop są naprawdę wygodne do użycia. Pojawia się tam coraz więcej rzeczy, które są trudno przenaszalne do innych agentów (pamięć projektów, skill). Trudno go „wyjąć” z mojego procesu bez bolesnego spadku jakości.

5️⃣ Jaki jest Twój stack AI?

Daj znać w komentarzu jaki jest Twój stack AI do pracy produktowej. Może coś nieoczywistego Ci się wybitnie sprawdziło spoza listy?

Leave a comment

🔗 Pełne wyniki ankiety

Wyniki ankiety u Lennego zawierają oczywiście dużo więcej danych - wykresy dla wszystkich ról, szczegółowe breakdown narzędzi, sekcje o agentach, downsides AI, i więcej:

Lenny's Newsletter

AI tools are overdelivering: results from our large-scale AI productivity survey

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

Read more

5 months ago · 343 likes · 14 comments · Noam Segal and 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)

2024 był najlepszym rokiem mojego życia - rozwój własnej firmy (Product Academy), kilkanaście wyjazdów (w tym miesiąc spędzony na Bali), zaręczyny w Nowym Jorku. Trudno to przebić.

Dlatego do 2025 podchodziłem z rezerwą. Wiedziałem, że to będzie rok trudnych wyzwań i dużych decyzji odnośnie mojej produktowej kariery.

Ale zrobiłem sobie plan projektów na 2025 rok. I teraz, pod koniec roku, chcę się z Tobą podzielić osobistym podsumowaniem.👇

25 projektów w 2025 roku

Większość była zaplanowana, niektóre wyszły w trakcie. Część zakończyła się sukcesem - część to porażki, z których mogę wyciągnąć wnioski. Fajnie spojrzeć na nie z dłuższej perspektywy - bo na co dzień trudno docenić, gdzie się jest i co udało się zrealizować.

Podsumowanie podzieliłem na 5 obszarów:

• 1️⃣ Rozwój w AI - powrót do hands-on, bootcamp, nowe narzędzia pracy

• 2️⃣ Product Craft - Marty Cagan w podcaście, meetupy, nowe formaty

• 3️⃣ Product Academy - eksperymenty (też te nieudane)

• 4️⃣ Osobiste - najważniejsze wydarzenie w moim życiu

• 5️⃣ Sport - maraton, kryzysy i życiówki

Większość tych projektów nie udałoby się bez Was - ludzi, z którymi współpracuję i tych, którzy “subskrybują” moje inicjatywy. Dla Was wszystkich wielkie:

✨ Na koniec newslettera jeszcze przygotowałem krótkie wnioski z perspektywy 12 miesięcy oraz Sneak peek projektów na 2026 rok.

Subscribe now

1️⃣ Rozwój w AI

To był rok, w którym przestałem obserwować rewolucję AI z boku. Świadomie wskoczyłem w sam środek - i to na kilku frontach jednocześnie. Czy było warto? Zdecydowanie. Czy było łatwo? Absolutnie nie.

• Projekt 1: Powrót do pracy hands-on przy produkcie AI

• Projekt 2: AI Product Bootcamp - pierwsza edycja

• Projekt 3: Cursor + Claude jako główne narzędzia pracy

Projekt 1: Powrót do pracy hands-on przy produkcie AI

W sierpniu podjąłem najtrudniejszą decyzję w tym roku. Mam firmę, która generuje przyzwoite przychody i daje mi wolność. Po co wracać do etatu? Po co znowu być w biurze, na spotkaniach, w codziennym operacyjnym młynie?

Bo inaczej za 2 lata nie będę rozumiał, na czym polega tworzenie produktów.

Mój bet był prosty - kto teraz nie wsiądzie do pociągu budowy produktów hands-on z AI, za 2 lata nie będzie rozumiał co się dzieje. Nigdy nie chciałem uczyć teorii z książek i cudzych case studies. Zawsze bazowałem na własnym “skin in the game”. Ta decyzja to potwierdza.

• Cel: Wrócić do pracy operacyjnej przy produkcie, żeby nie zostać “konsultantem-teoretykiem”.

• Kiedy? sierpień - grudzień

• Co zrobiłem: W wakacje rozpocząłem poszukiwania. Odrzucono mnie w 2 rekrutacjach. Od sierpnia pracuję jako Head of Product w BrainBits.AI.

• Efekt: AI jako core produktu (Conversational AI, LLM), miliony generacji miesięcznie, realne problemy z prompt engineeringiem, halucynacjami, latencją. Mały zespół, ~30-40% growth w ostatnich miesiącach. Dawno tak szybko i tak mocno się nie uczyłem i nie rozwijałem.

Więcej o mojej decyzji pisałem tutaj ⤵️

Projekt 2: AI Product Bootcamp - pierwsza edycja

Przez lata uczyłem „klasycznego” product managementu. Dalej głęboko wierzę, że te fundamenty są niezwykle ważne. Ale wierzę też, że AI jest katalizatorem zmian i idzie nowe. Najlepsze zespoły produktowe pracują 10x szybciej, mądrzej i z większym impaktem.

Dlatego razem z Jakub Uniejewskim zrobiliśmy pilotażowy program - AI Product Bootcamp, który pomaga PM-om nie zostać w tyle. Minimum teorii, całość oparta o “learning by doing”. Stresowałem się, czy to w ogóle zadziała.

• Cel: Stworzyć praktyczny program, który pomoże PM-om wdrożyć AI w swoją pracę.

• Kiedy? sierpień

• Co zrobiłem: Pierwsza edycja AI Product Bootcamp, w której wzięło udział 100 uczestników.

• Efekt: 80 zgłoszonych projektów AI usprawniających pracę PMa, 50 zrealizowanych. Kilkanaście inspiracji od PMów podrzuconych uczestnikom.

Mega fajnie widzieć jak komuś to naprawdę pomogło w pracy i karierze 🖤. Nie teoria, a PRAKTYKA. Bootcamp pchał nas wszystkich do eksperymentowania - mnie też 💪.

Projekt 3: Cursor + Claude jako główne narzędzia pracy

Zawsze raczej byłem na froncie różnych technicznych nowinek. Już 2 lata temu ChatGPT stał się moim asystentem HoP w SentiOne na 30 dni. Ale… od początku tego roku czułem, że zaczynam być w tyle - zacząłem dostrzegać te 5 % PMów, których styl pracy totalnie się zmienił przez AI. Nie używali go jako dodatku, tylko transformował on ich pracę. I ja nie byłem w tych 5%.

Dlatego od sierpnia postawiłem sobie jasny cel:

• Cel: Przestać używać AI jako dodatku, ale jako główne narzędzie w pracy. Nawet jeśli to będzie bolało.

• Kiedy? sierpień - grudzień

• Co zrobiłem: Od września intensywnie używam Cursor + Claude do produktowych rozkmin, pisania dokumentów produktowych, analiz, strategii, komunikacji, automatyzacji pracy.

• Efekt: Czuję się jakbym miał supermoce - jakbym zaczął pracować w stylu 10x. ;).

Zrobiłem nawet pierwszy COMMIT do repo dużego produktu od 15 lat 🥺 MAŁA zmiana dla produktu, WIELKA zmiana dla product managera ;)

To był zdecydowanie rok nauki nowego sposobu pracy. I punkt bez powrotu. Swoimi doświadczeniami miałem okazję już się podzielić podczas kilku wydarzeń.

Będę o tym będę pisał więcej w przyszłym roku.

Co z tego wynoszę dla siebie?

1️⃣ Teoria bez praktyki = ślepa uliczka. Mogłem dalej uczyć z książek i cudzych case studies. Ale wtedy za 2 lata byłbym ekspertem od świata, który już nie istnieje.

2️⃣ Dyskomfort = wzrost. Powrót do hands-on to był dyskomfort. Nowy zespół, nowe wyzwania, mniej wolności. Ale to właśnie tam jest rozwój.

3️⃣ AI zmienia sposób pracy w produkcie. Mi to fundamentalnie zmieniło sposób w jaki pracuję jako PM.

Subscribe now

2️⃣ Product Craft

Moja “content creatorska” działalność. Brzmi górnolotnie, ale w praktyce to po prostu dzielenie się tym, czego sam się uczę. Newsletter, podcasty, meetupy. W 2025 sporo się tu działo - w tym jedno spełnione marzenie, które jeszcze rok temu wydawało mi się nierealne.

• Projekt 4: Podcast z Marty Caganem

• Projekt 5: 37 książek na 37 urodziny

• Projekt 6: Product Leadership Meetup (5 edycji)

• Projekt 7: Podcast „Dodane do Backlogu” - 12 odcinków

• Projekt 8: Praktyczny przewodnik po 20 pryncypiach Product Operating Model

• Projekt 9: Raport “Stan product managementu w Polsce 2025”

• Projekt 10: Wyjazd na ProductCamp Berlin

• Projekt 11: Product Discovery Academy

Projekt 4: Podcast z Marty Caganem

Gdyby ktoś mi 5 lat temu powiedział, że będę rozmawiał w moim podcaście ze światowym guru product managementu - Marty Cagenem - nie uwierzyłbym. Dalej trochę nie wierzę. Stresowałem się cały dzień przed nagraniem.

• Czy zadałem jakieś uber-mądre pytanie? Nie sądzę.

• Czy Marty kilka razy przekazał nam “tough love” feedback? Tak.

• Czy jaram się tym jak dziecko? ZDECYDOWANIE :D!

• Cel: Nagrać rozmowę z Martym Caganem dla polskiej społeczności PM-ów.

• Kiedy? styczeń

• Co zrobiłem: Nagraliśmy w Dodane do Backlogu godzinny podcast z Martym. Potem powstał też wywiad w newsletterze.

• Efekt: Niby nic odkrywczego nie usłyszeliśmy w tym podcaście, ale mam nadzieję, że to kolejna (chociaż mała) kropla drążąca skałę zmiany mindsetu na polskim produktowym podwórku.

Projekt 5: 37 książek na 37 urodziny

Moja ulubiona urodzinowa inicjatywa ;). Zamiast dostawać prezenty - rozdaję (tyle książek produktowych ile mam lat). Jest w tym coś fajnego - celebrujesz swój dzień, ale jednocześnie dajesz coś od siebie społeczności. To moja próba odwdzięczenia się mojej społeczności.

• Cel: Podzielić się wiedzą i zrobić coś fajnego dla społeczności Product Craft.

• Co zrobiłem: Rozdałem 37 produktowych książek dla czytelników newslettera. Zrobiliśmy nawet produktowy, mini turniej szachowy.

• Efekt: Mega pozytywny odzew. I sygnały, że wiedza niesie się dalej ⤵️

Część książek udało się nawet wręczyć osobiście :)

Projekt 6: Product Leadership Meetup (5 edycji)

Eksperyment, który zaskoczył mnie samego. Chcieliśmy zrobić razem z Mariuszem Witkowskim coś dla Product Leadershipu w Polsce. Wpadłem na pomysł, żebyśmy stworzyli… “Meetup online”. Nie webinar, a właśnie meetup, podczas którego skupimy się głównie na wymianie doświadczeń.

„To nie zadziała, ludzie nie będą zaangażowani online.”

Taki dostałem feedback na początku. Postanowiliśmy sprawdzić czy da się zrobić inaczej.

• Cel: Stworzyć przestrzeń dla liderów produktu do wymiany doświadczeń - online, ale angażująco.

• Co zrobiłem: Razem z Mariuszem Witkowskim i shoshin.pm wystartowaliśmy z Product Leadership Meetupem. Selekcja uczestników, brak nagrań, brak AI-notatek, lightning talks + dyskusje w małych grupach.

• Efekt: 4 edycje w 2025. Feedback typu “najlepszą opinią będzie to, że czuję niedosyt” i “w końcu safe space do wymiany doświadczeń”.

Wychodzi na to, że da się zrobić angażujący meetup online 🤩

Projekt 7: Podcast „Dodane do Backlogu” - 12 odcinków

Podcast “Dodane do Backlogu”, który wyrósł z naszych nieformalnych cotygodniowych rozmów.

Czterech senior PM-ów z globalnych produktów gada o zarządzaniu produktami - o swoich realnych doświadczenia w luźny sposób, zderzając nasze różne punkty widzenia.

• Cel: Przekształcić nasze prywatne mastermindy w wartość dla szerszej społeczności.

• Co zrobiliśmy: 12 odcinków w 2025. Gościliśmy m.in. Davida Pereirę (CPO MailerLite), Todda Romana (SVP Zendesk) i wspomnianego wcześniej Marty’ego.

• Efekt: Każdy odcinek słucha kilkaset osób. Poza wartością dla słuchaczy, dla mnie to niesamowita okazja odbić myśli z innymi doświadczonymi PMami.

Marcin Jędrzejczak, Wojtek Smajda, Jakub Tutaj - brawo. Dzięki chłopaki z ten podcast 🙌.

Nie każdy projekt chcę szczegółowo rozpisywać, ale nie chcę pominąć bardzo fajnych inicjatyw:

• Projekt 8: Praktyczny przewodnik po 20 pryncypiach Product Operating Model - seria w newsletterze rozkładająca “Transformed” Cagana na czynniki pierwsze

• Projekt 9: Raport “Stan product managementu w Polsce 2025” - pierwsza taka analiza polskiego rynku. Przeczytana kilka tysięcy razy, odbiła się szerokiem echem w środowisku.

• Projekt 10: Wyjazd na ProductCamp Berlin - wyjazd, poznanie PM-ów z całej Europy + moje podsumowanie z tego wyjazdu. Mocno otworzyło głowę i wpłynęło na moje strategiczne bety.

• Projekt 11: Product Discovery Academy - pierwsza edycja akademii Product Discovery prowadzona z Krzysztofem Miotkiem

Co z tego wynoszę dla siebie?

• ⚡️ Marzenia się spełniają, ale trzeba działać. Rozmowa z Caganem nie spadła z nieba. To efekt lat budowania społeczności, świetnej ekipy “Dodane do Backlogu” i odwagi, żeby poprosić.

• ⚡️ “To nie zadziała” to często zły doradca. Meetup online? “Nie zadziała”. Podcast w 4 osoby? “Będzie chaotyczny”. A jednak działa - bo ludzie szukają autentyczności i szczerego praktycznego doświadczenia (przynajmniej taka jest moja hipoteza ;)).

• ⚡️ Dysplina > wielkie akcje. 12 odcinków podcastu, 5 meetupów, regularne newslettery. Żadna z tych rzeczy pojedynczo nie jest spektakularna. Ale suma buduje coś większego.

Subscribe now

3️⃣ Product Academy

Moja firma, którą budowałem od kilku lat i która daje mi niezależność finansową. W 2025 roku Product Academy przeszło transformację - od szkoleń dla początkujących PM-ów w stronę pracy z bardziej doświadczonymi liderami i całymi organizacjami. Ale nie wszystko poszło zgodnie z planem.

• Projekt 12: Strategia produktowa dla Tutlo.com

• Projekt 13: Nowe warsztaty dla doświadczonych PM-ów

• Project 14: Accountability Group - porażka ❌

• Projekt 15: Największa edycja Product Management Academy

Projekt 12: Strategia produktowa dla Tutlo.com

Jeśli 2024 to był dla mnie rok product discovery, to 2025 to był rok strategii produktowej B2C. Kilka miesięcy spędziłem in-site w firmie - nie jako zewnętrzny konsultant, który przyjeżdża na warsztat i znika, ale jako ktoś realnie zanurzony w organizacji.

• Cel: Pomóc liderowi nowoczesnej edukacji językowej w Polsce przygotować i wdrożyć strategię produktową oraz odpowiedź na wyzwania związane z AI.

• Co zrobiłem: Kilka miesięcy pracy z Zarządem i Head of Product. Strategia produktowa oraz Strategia AI w oparciu o Product Operating Model.

• Efekt: Wdrożona strategia, która żyje w organizacji - nie leży w szufladzie. Świetna współpraca z zespołem, który naprawdę chciał się zmieniać.

Pięknie zobaczyć jak strategia produktowa żyje w organizacji i wpływ na decyzje biznesowe i produktowe.

Projekt 13: Nowe warsztaty dla doświadczonych PM-ów

Przez lata większość szkoleń produktowych w Polsce była skierowana do pracujących po prostu głownie z zespołami developerskimi. Ale najlepsi Product Managerowie coraz więcej pracują poza zespołem developerskim w części “business viablity & go-to-market” produktu. To coś czego mi bardzo brakowało 5 łat temu, gdy miałem już trochę doświadczenia w rozwoju produktów.

• Cel: Stworzyć warsztaty, które sam chciałbym dostać 5 lat temu.

• Co zrobiłem: Opracowałem i przeprowadziłem warsztaty na tematy:

  • Feature Launch

  • Go-To-Market

  • Estymacja wartości ficzera

  • Rollout Strategy

  • Ewaluacja ficzerów po wdrożeniu

  • Pricing produktów

  • Strategia produktowa

• Efekt: Pierwsze edycje - nieperfekcyjne, jest sporo do poprawy. Ale fundamenty są mocne. Feedback: “w końcu coś dla nas, nie dla product ownerów”.

To tematy, których brakuje w układance wielu PM-ów. Wdrażanie funkcji bez solidnego planu na launch, GTM i pomiar efektów to prosta droga do feature factory. Będę to rozwijał.

Project 14: Accountability Group - porażka ❌

Ten projekt muszę opisać szczerze - bo to była porażka. Miałem hipotezę: większość ludzi ma problem nie z wiedzą, tylko z wdrożeniem. Rozwiązania - moderowane Accountability Group. Stworzyłem grupę z publicznym zobowiązaniem i cotygodniowymi check-inami.

• Cel: Sprawdzić czy accountability group pomaga PM-om realizować cele.

• Co zrobiłem: Wystartowałem grupę. Publiczne zobowiązania, cotygodniowe check-iny.

• Efekt: Do końca dotrwały 3 z 10 osób. Aktywność szybko wygasła, bardzo mało osób wrzucało update’y. Inicjatywa nie dowiozła wartości, którą chciałem stworzyć.

Czasem pomysły, które w mojej głowie wydają się super, nie działają w zderzeniu z rzeczywistością. Accountability wymaga więcej struktury i “przymusu” niż zakładałem. Cenna lekcja produktowa - w końcu w Product Academy uczymy się na eksperymentach, również tych nieudanych 😉

Projekt 15: Największa edycja Product Management Academy

Gdy zaczynaliśmy z Olgą Product Management Academy 2.0 kilka lat temu, marzyliśmy, żeby co roku skorzystało z niej kilkadziesiąt osób. W tym roku - w samej jesienniej edycji - wzięło udział ponad 60 osób.

I to w momencie, który był dla mnie osobiście najtrudniejszym - nowa praca w BrainBits, wyzwania życiowe, kalendarz pękający w szwach. A mimo to - największa edycja w historii 🙌

• Cel: Przeprowadzić jubileuszową 10. edycję PMA na najwyższym poziomie.

• Co zrobiliśmy: 6 tygodni intensywnego programu. 5 warsztatów w grupach, 5 spotkań LIVE, 84 lekcje online, 100+ rozwiązań do indywidualnych zadań. Mentorzy-praktycy: Karol Kłaczyński (HoP Brand24), Mateusz Miodek (PM w Atlassian).

• Efekt: 60+ uczestników ukończyło program, ocena satysfakcji: 94% 🤯. Feedback typu: “Nie znam drugiej takiej przestrzeni, gdzie po szkoleniu pozostaje nie tyle certyfikat, co RELACJE.”

To, co wyróżnia PMA, to nie certyfikat - to społeczność. Ludzie wracają, polecają znajomym, zostają w kontakcie. Wiedzę znajdziesz wszędzie. Przestrzeń do budowania relacji z innymi PM-ami - to rzadkość :).

Co z tego wynoszę dla siebie?

• ⚡️Głęboko > szeroko. Kilka miesięcy z jednym klientem dało więcej wartości (i satysfakcji) niż dziesiątki jednodniowych warsztatów. Przynajmniej dla mnie.

• ⚡️ Porażki są częścią gry. Accountability Group nie wypaliło. Niby smutno, ale teraz wiem, że ten format w takiej formie nie działa. Lepiej wiedzieć niż gdybać i się jarać jaki to ma się super pomysł.

• ⚡️ Rynek dla seniorów istnieje. Doświadczeni PM-owie są głodni rozwoju. Tylko nikt dla nich nie tworzy treści. To nisza, którą będę eksplorował.

Subscribe now

4️⃣ Osobiste

Ta sekcja będzie krótka, ale… za to to najważniejsza część mojego 2025 roku. Bo można mieć świetne projekty, rosnącą firmę i spełnione zawodowe marzenia. Ale bez fundamentu w życiu osobistym - to wszystko traci sens.

• Projekt 16: Ślub 🤵‍♂️👰‍♀️

• Projekt 17: Obgryzanie paznokci

• Projekt 18: XYZ

Projekt 16: Ślub 🤵‍♂️👰‍♀️

11 miesięcy. Dokładnie tyle minęło od zaręczyn w Nowym Jorku do momentu, gdy powiedzieliśmy sobie “tak”.

Kto organizował ślub, ten wie - to projekt jak każdy inny. Budżet, harmonogram, dostawcy, zarządzanie stakeholderami (czytaj: rodzina 😅). Wszystko się udało dzięki mojej wspaniałej żonie 🖤

Projekt 17: Obgryzanie paznokci

Po jakichś 20 latach… przestałem obgryzać paznokcie :P. Ślub, wizyta u kosmetyczki i szczere postanowienie poprawy. Efekt: od 3 miesięcy muszę znowu obcinać sobie paznokcie ;)

Projekt 18: XYZ

Jeden osobisty projekt zostawiam tylko dla siebie 😉

5️⃣ Sport

Dla niektórych to dziwne - po co w podsumowaniu roku zawodowego pisać o sporcie? Ale dla mnie to nieodłączna część życia i… osobiście uważam, że w naszych technicznych zawodach - przyspawani do biurka i komputera potrzebujemy czegoś, co nas od tego oderwie.

Sport doskonale uczy dyscypliny, samozaparcia, ciężkiej pracy i wychodzenia ze strefy komfortu, radzenia sobie z bólem. Wiem jak to brzmi… ale na mnie tak to po prostu działa.

• Projekt 19: Maraton <4h

• Projekt 20: Półmaraton Gdynia - pierwszy prawdziwy kryzys sportowy

• Projekt 21: PR na 10km

• Projekt 22: Wyjazdy rowerowe - Malaga i Girona

• Projekt 23: Nocny Duathlon na Lotnisku w Gdańsku

• Projekt 24: Gran Fondo Gdynia

• Projekt 25: 4000 km na rowerze + 1000 km biegiem

Projekt 19: Maraton <4h

Pierwszy maraton biegłem w 30-stopniowym upale w Lizbonie 2 lata temu. Drugi? 0 stopni, wiatr i śnieżyca w Gdańsku ;). To był mój start docelowy w tym roku - 1800+ osób na starcie, arktyczne warunki i jeden cel, do którego się przygotowywałem od wielu miesięcy.

• Cel: Minimum - pobić PR (4:12). Maksimum - złamać 4h.

• Co zrobiłem: Mój drugi maraton w życiu. 42 km, w tym ostatnie 10 km w śnieżycy.

• Efekt: 3:52. Cel maksimum zrealizowany. Uczucie, gdy finiszujesz na stadionie i w końcu wychodzi słońce - bezcenne 😅.

Gdyby 3 lata temu ktoś mi powiedział, że tak wkręcę się w bieganie - nie uwierzyłbym. Dużo to zabiera (czasu, energii, czasem nerwów), ale jeszcze więcej oddaje.

Projekt 20: Półmaraton Gdynia - pierwszy prawdziwy kryzys sportowy

To był najtrudniejszy bieg w moim życiu. Wystartowałem świetnie. Wymarzone tempo 4:30-4:40 min/km. I nagle na 7. kilometrze - ściana. Nie mogę złapać oddechu, zaczyna boleć noga, totalny kryzys. Miała być zdecydowana życiówka, a zapowiada się najgorszy bieg w życiu.

• Cel: Życiówka na półmaratonie.

• Co zrobiłem: Finalnie zagryzłem zęby i nie poddałem się. Uspokoiłem rytm, zmieniłem cel - “odpuść trochę Tomek i ukończ po prostu ten bieg”. Po kilku spokojniejszych kilometrach złapałem się grupy biegnącej 5:00/km.

• Efekt: Nie, nie pobiłem swoje życiówki. To nie ta historia ;) Ale pokazałem sobie, że potrafię się podnieść, zmienić cel i mimo wszystko czerpać z tego przyjemność.

Gdy przychodzi kryzys - odpuść chwilę, zweryfikuj cel i lecimy dalej.

Projekt 21: PR na 10km

Bieg Niepodległości 🇵🇱 - uwielbiam te zawody. Śpiewać hymn jako uczestnik, nie jako kibic - niesamowite doświadczenie. A w tym roku dodatkowo - jak co roku - przygotowywałem się przez kilka miesięcy do życiówki.

Pierwszy raz, gdy… przygotowywałem się do zawodów z AI Coachem ;) AI Coach z Garmina mówił, żeby celować w czas 45:10. Czułem się dobrze, posłucham swojego organizmu i zignorowałem AI.

Efekt: 44:18 (4:26/km). Życiówka. Człowiek wygrał z maszyną 😉

Projekt 22: Wyjazdy rowerowe - Malaga i Girona

Jedno z moich małych marzeń z czasów bycia dzieciakiem z małego Chełmna - pojeździć szosą po górach w Hiszpanii/Włoszech lub Francji. W tym roku udało się zrealizować. Dwa razy.

• Cel: Zrealizować marzenie o jeździe po hiszpańskich podjazdach.

• Co zrobiłem: Dwa grupowe wyjazdy po 5-7 dni. Każdego dnia kilka 10-20 km podjazdów o średnim nachyleniu 5-8%. Jest zabawa.

• Efekt: Girona, Malaga - miejsca, gdzie trenują najlepsi kolarze świata. Teraz wiem dlaczego :)

Marzenia czasami się spełniają. Trzeba je tylko zaplanować, wrzucić do kalendarza i po prostu zacząć robić.

W sporcie też zrealizowałem kilka dodatkowych ważnych projektów:

• Projekt 23: Nocny Duathlon na Lotnisku w Gdańsku - PR, niesamowita atmosfera biegu i jazdy rowerem po lotnisku w nocy:)

• Projekt 24: Gran Fondo Gdynia - moje pierwsze zawody kolarskie, kolejne małe marzenie z dzieciństwa spełnione

• Projekt 25: 4000 km na rowerze + 1000 km biegiem - cele roczne zrealizowane ✅

Co z tego obszaru wynoszę dla siebie?

• ⚡️ Aktywność fizyczna to dla mnie MUST HAVE. Szczególnie dla nas - przyklejonych do ekranów. Jeśli się nie ruszam - źle się czuje. Bieganie, rower, zwykły spacer. Cokolwiek. Mózg potrzebuje ruchu, żeby dobrze pracować.

• ⚡️ Kryzysy są częścią gry. Na półmaratonie serio chciałem się poddać, gdy wiedziałem już, że celu nie osiągnę. W pracy też czasem mam takie momenty. Lekcja jest ta sama - uspokój się, dostosuj cel, leć dalej.

• ⚡️ Cele roczne działają, jeśli możesz widzieć systematycznie postęp. 4000 km rowerem + 1000 km biegi brzmiało ambitnie w styczniu, ale po roku okazało się, że nie było to wielkie wyzwanie - bo było zapisane, mierzone i realizowane z dyscypliną.

Z perspektywy 12 miesięcy

Patrząc z perspektywy grudnia na cały rok:

• To był rok powrotu do fundamentów. Hands-on przy produkcie zamiast teorii z boku. Sport zamiast kolejnych godzin przy biurku. Relacje zamiast certyfikatów.

• Jednocześnie to był dla mnie rok zmiany paradygmatu w pracy - Cursor, Claude, AI w codziennej pracy, m.in. dzięki temu udało się zrobić te 25 projektów, prowadzić firmę, wrócić do hands-on i nie zwariować.

• To był też rok eksperymentów. Accountability Group? Nie wypaliło. AI Product Bootcamp? Wyszło nieźle. Meetup online? Wbrew wszystkim opiniom - strzał w 10. Nie da się wiedzieć z góry co zadziała. Trzeba próbować.

• I najważniejsze → dyscyplina. W sporcie to były regularne treningi (4000 km na rowerze, 1000 km biegiem), które przyniosły wyniki. W produkcie/biznesie - regularne newslettery, podcasty, coroczne akcje. Dyscyplina > motywacja. Motywacja przychodzi i odchodzi.

Subscribe now

Co w 2026? Sneak peek 👀

Nie lubię zapowiadać wielkich rzeczy. Wolę je zrealizować i potem opowiedzieć, jak poszło. Ale skoro właśnie przeczytałeś 25 projektów z mojego 2025 - należy Ci się mały sneak peek tego, co planuję.

1️⃣ Double down na 10x Product Management I AI

Tak jak pisałem - mocno wierzę, że budowa produktów przechodzi właśnie fundamentalną zmianę. Dlatego w 2026 jeszcze bardziej stawiam na dwie rzeczy: eksperymentowanie z nowymi workflow przy budowie produktów oraz hands-on budowanie produktów AI opartych o LLM-y. Czyli jeszcze więcej "skin in the game". Mamy ambitne plany na wzrost w produkcie i zmierzamy je zrealizować.

2️⃣ Projekt “Strategiczne Nie”

Mniej inicjatyw, ale z większym skupieniem. I mam nadzieję - z większym impactem. Mam problem z angażowaniem się w zbyt wiele tematów. W 2026 chcę być bardziej bezwzględny w mówieniu “nie”. Chcę uporządkować moje portfolio - z części aktualnych inicjatyw prawdopodobnie zrezygnuję.

3️⃣ Cursor / Claude (Code) dla Product Managera

Cały czas wypracowuję swój workflow pracy z AI. Teraz chcę się więcej nim dzielić - nie jako teoria “jak mogłoby być”, ale z placu boju, na bazie moich eksperymentów. Co działa, co nie działa, jak to wygląda w praktyce.

4️⃣ Prototypowanie z AI

To coś, co już trochę robię prywatnie. Teraz buduję buduję Conversational AI - mało tam interfejsu użytkownika do prototypowania. Ale niedługo czeka mnie większy panel do zaprojektowania. Idealne środowisko do eksperymentowania z AI-assisted prototypowaniem.

5️⃣ 3 maratony w 40 dni: Rzym, Praga, Gdańsk 🏃

Po ślubie zbieram rodziców i teściów na małe wycieczki po europejskich stolicach. A przy okazji... będą mogli mi pokibicować na trasie 😉. Trzy maratony, trzy piękne miasta, 40 dni. Zobaczymy, czy nogi wytrzymają, przygotowania trwają.

Tyle na teraz.

Dziękuję Wam wszystkim - tym, którzy czytają newsletter, słuchają podcastów, przychodzą na szkolenia i meetupy. Bez Was te listy wyglądałaby zupełnie inaczej 🖤

Do zobaczenia w 2026!

Tydzień temu napisałem szczerą spowiedź po 2 latach prowadzenia Product Academy i o mojej strategicznej decyzji… powrotu do hands-on pracy przy produkcie AI.

„Dlaczego gość, który właśnie pochwalił się milionem przychodu i wolnością, dobrowolnie wraca do biura? Dlaczego wraca na front?”.

Krótka odpowiedź: bo inaczej za 2 lata nie będę rozumiał na czym polega tworzenie produktów. Dłuższa - bo tak wynika z mojej strategicznej diagnozy i „betu”, które znajdziesz w tym newsletterze.👇

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.

W dzisiejszym wydaniu:

1. Diagnoza: co się dzieje z product managementem?

   1. Zmiana 1: Budowanie produktów AI to „inna gra”

   2. Zmiana 2: Zmienia się sposób budowania produktów i rola PM-a

2. Trzy scenariusze przyszłości PM-a

   1. Kierunek 1: Product Builder / Maker

   2. Kierunek 2: Market-Focused PM

   3. Kierunek 3: Małe elitarne „super IC”

3. Mój strategiczny „BET”

Subscribe now

Mam ostatnio silne poczucie déjà vu w kontekście technologii i rozwoju produktów cyfrowych. Mam głębokie poczucie i intuicję, że świat wokół mnie właśnie się zmienia. Fundamentalnie.

Podobnie czułem się dwa razy w życiu:

1️⃣ Po raz pierwszy, gdy jako nastolatek zobaczyłem i doświadczyłem internetu. Pamiętam to uczucie, gdy zrozumiałem, że mam prawie wszystko na wyciągniecie ręki, że mogę stworzyć „stronę WWW” i pokazać ją światu. Że nie potrzebuję niczyjej zgody, żeby budować.

To pchnęło mnie w tworzenie stron internetowych, studia informatyczne, a potem w świat startupów i produktów cyfrowych.

2️⃣ Po raz drugi w 2017 roku, gdy zacząłem działać z AI - deep learning, sieci neuronowe, modele, które "uczą się" na danych. Zafascynowałem się tym, jak bardzo ta technologia zmienia możliwości, które możemy mieć w produkcie. I wiedziałem, że chcę być jej częścią.

Dlatego poświęciłem pół roku na naukę podstaw ML i w 2018 dołączyłem do SentiOne jako R&D Product Manager. Budowaliśmy Conversational AI, zanim to było modne. NLU, NLP, F1 score, accuracy - to była moja codzienność.

W obu tych momentach byłem pewny jednego:

Stąd moje duże decyzje o tym czym zająłem się w kolejnych latach. Czułem, że tylko tak mogę naprawdę zrozumieć, co się dzieje i dalej tę przyszłość współtworzyć.

Teraz, w erze LLM-ów, czuję tę ekscytację po raz trzeci 3️⃣:

• Z jednej strony - gigantyczne możliwości, które dają LLMy.

• Z drugiej - kompletna niewiadoma, gdzie nas to wszystko zaprowadzi.

Widzę, że budowanie produktów przechodzi właśnie fundamentalną zmianę i muszę na nią strategicznie zareagować. Dlatego, tak jak przy budowie strategii produktowej:

1. Zacząłem od diagnozy sytuacji - co moim zdaniem dzieje się w świecie produktu

2. Zdefiniowałem trzy potencjalne scenariusze przyszłości produktowej PMów,

3. A na końcu postawiłem na swój “strategiczny bet”.

Zaczynamy.

1. Diagnoza: co się dzieje z product managementem?

Moja diagnoza oparta jest na 2 źródłach:

• Staram się śledzić wypowiedzi liderów produktowych mających wpływ na product management (Marty’ego Cagana, Teresy Torres, Lenny’ego Rachitsky’ego, Shreyasa Doshiego, Claire Vo, Petera Yanga) jaki liderów zespołów produktowych z topowych firm takich jak FAANG, OpenAI czy Anthropic.

• Z racji mojego działania jako edukator i konsultant widzę co się dzieje od środka w różnych firmach, produktach, rozmawiam z wieloma PMami pracującymi na froncie rozwoju produktów.

Od dłuższego czasu obserwuję dwie fundamentalne zmiany, których katalizatorem są AI i LLMy.

Zmiana 1: Budowanie produktów opartych o AI to „inna gra”

Doświadczyłem tego już w 2018 roku w SentiOne. Wtedy zaczynał królować Deep Learning i Sieci Neuronowe. I pamiętam szok, gdy po pół roku nauki podstaw ML stanąłem twarzą w twarz z zespołem R&D dla którego byłem PO i z którym rozwijałem produkt Conversational AI - SentiOne Automate.

Mimo że byłem doświadczonym PM-em (około 8 lat), to było bolesne zderzenie. Połowę tego co wiedziałem o rozwoju produktów musiałem uczyć się od nowa.

Niedeterministyczne produkty

Dlaczego? Bo w AI probabilistyka zastępuje deterministyczny kod, a zespoły Data Scientist i ML Enginerów pracują inaczej niż typowe zespołem developerskie. Przygotowanie i jakość danych na których uczą się modele, szybko może się okazać ważniejsza niż jakość kodu. F1 score, model accuracy, etykietowanie danych - to była wtedy moja nowa codzienność.

• Przez dekady budowaliśmy deterministyczne produkty rozwiązując tzw. problemy obliczeniowe („computational problems”). Schemat jest prosty: masz dane wejściowe, piszesz reguły w kodzie, dostajesz wynik. Przykład: zapłacenie za produkt w e-commerce (user wybiera produkt, system stosuje ceny, rabaty, podatki - i dostaje rachunek)

• Teraz, dzięki probabilistycznym rozwiązaniam, możemy rozwiązywać tzw. problemy wymagające uczenia się („learning problem”). I tu schemat jest odwrócony: zamiast pisać reguły, dajesz modelowi tysiące przykładów. Model sam “uczy się” reguł, których nie potrafisz wyrazić. Przykład: rozpoznanie co jest na obrazku, albo “namalowanie” obrazka.

Te dwa światy w kontekście budowy produktów działają inaczej:

Teraz, z LLM-ami, jest podobnie. Tylko jeszcze intensywniej.

Wtedy modele AI wspierały poszczególne funkcje produktu. Teraz LLM-y często SĄ produktem lub jego corową cześcią. Pozwalają tworzyć, a nie głownie rozpoznawać. Ogromne znaczenie maja dane wejściowe (context). Zmieniają całkowicie flow pracy użytkowników. Ich wpływ jest fundamentalny.

Nowe kompetencje, bez których nie zbudujesz dobrego produktu z LLMem

Teraz z przy pracy z modelami LLM, dochodzą kolejne aspekty, które są kluczowe dla tworzenia dobrych produktów. Tu wymienię tylko najważniejsze z nich:

• Zarządzanie niepewnością - wyniki modelu mogą nie odpowiedzieć na Twoją hipotezę. I to nie jest bug - to norma. Musisz mieć umiejętność komunikowania stakeholderom, że "model działa w 87% przypadków" i dlaczego to może być świetny wynik. Musisz bardzo mocno zajmować się edukacją leadershipu i wspólnie pracować z innymi działami - jaki to będzie miało na nie wpływ na Customer Service, Marketing itp.

• Context Engineering - bardzo szybko okazuje się, ze zaczynasz pracować nie z devloperami nad kodem, tylko nad „Promptami” - bo to INPUT do LLMa ma zasadnicze znaczenie w kontekście tego jak działa produkt. Mała zmiana promptu - może mieć gigantyczne znaczenie w kontekście tego jak działa produkt. Oczywiście temat jest szerzy - to cały sposób budowania, tworzenia, pracy z INPUTEM który dostarczamy LLMowi - czyli tzw. Context Engineering.

• AI Evals – zupełnie inaczej zaczynasz podchodzić do ewaluacji produktu. Nie testujesz "czy feature działa", tylko "jak często model daje akceptowalną odpowiedź" i "jakie są edge case'y, które go łamią".

• Technical fluency na nowym poziomie - nie chodzi mi tutaj o pisanie kodu produkcyjnego. Jeśli modele mają gigantyczne znaczenie dla sukcesu produktu, to musisz jednak rozumieć ich zachowanie, ograniczenia kontekstu, jakość danych, trade-offy między latencją a jakością. Bez tego nie będziesz w stanie prowadzić sensownych rozmów z zespołem technicznym.

• Panowanie nad kosztami LLMów - w tradycyjnym rozwoju produktu, zwykle najważniejszym kosztem była praca ludzka. W LLM każde wywołanie kosztuje (czy tokeny w zewnętrznym model, czy też duże koszty sprzętowe we własnych modelach). To powoduje, że dużo bardziej musisz myśleć nad trade-ofami z tymi związanymi.

Do tego dochodzi choćby często brak kontroli nad “silnikiem” (W LLM-ach często używasz modelu zewnętrznego np. GPT), inne podejście do cenników, znaczenie latency (czas odpowiadania LLMów), znaczenie “Context window”, halucynacje itp.

To nie znaczy, że fundamenty product managementu się nie liczą

Wręcz przeciwnie.

“When building becomes easy, deciding what to build becomes everything.” - Teresa Torres

Discovery, empatia do użytkownika, product sense - to wszystko staje się WAŻNIEJSZE, nie mniej ważne. Bo jeśli AI umożliwia zbudowanie czegokolwiek szybko i tanio (o tym w drugiej części diagnozy), przewagą jest wiedzieć, co warto zbudować.

Ale sam fundament nie wystarczy. Potrzebujesz fundamentu PLUS nowych kompetencji specyficznych dla AI.

To trochę jak kiedyś przejście z produktów fizycznych na cyfrowe. Z jednej strony – fundamenty budowy produktów są te same. Z drugiej - PM produktu cyfrowego potrzebował innych kompetencji niż PM produktu fizycznego. Dlatego tak trudno było “starym” PM-om przeskoczyć w nowe środowisko.

Historia się powtarza.

Zmiana 2: Zmienia się sposób budowania produktów i rola PM-a

Przez ostatnią dekadę żyliśmy w świecie, gdzie sukces produktu = więcej ludzi. Wielkie zespoły, wąskie specjalizacje. PM, Designer, kilku inżynierów, UX Researcher, PMM, Content, Analityk danych...

Firmy AI-native – OpenAI, Anthropic, Cursor – celowo opóźniają zatrudniają PMów i finalnie zatrudniają ich mniej. Nie dlatego, że nie stać ich na więcej. Ale dlatego, że wierzą w inny model.

Talent density > headcount - te firmy wolą mały zespół świetnych ludzi niż armię średniaków. Chcą małych, elitarnych zespołów.

Doskonale to widziałem na Product Camp Berlin kilka miesięcy temu: Dwie prędkości PM-ów.

• Z jednej strony – masa ludzi, dla których AI to “fajny dodatek”. Napisze im może user story. Czasem przyspieszy research. Ale sposób ich pracy? Ten sam co 5 lat temu. Scrum, Jira, PRD-y, spotkania, spotkania, spotkania.

• Z drugiej strony – garstka osób, które na prezentacjach o “podstawach AI w pracy PM-a” miały szeroko otwarte oczy. Ale nie dlatego, że się czegoś nowego uczyły. Dlatego, że dla nich to już był obcy świat.

Małymi zespołami robili rzeczy, które dużym firmom zajmują miesiące. Szybki research, szybka walidacja i szybka iteracja pomysłów. Mają swoich agentów do różnych produktowych tematów. Pracują ramie w ramie z zespołami, a nie “zarządzają taskami”. Bez wymówek, że potrzebujemy 15 kompetencji i ludzi, żeby coś zweryfikować i finalnie zbudować.

To był zupełnie inny poziom i sposób pracy.

Dawno coś tak bardzo mnie nie zainspirowało i było różne od tego co wiedziałem w tradycyjnych zespołach produktowych. I było dużym wkładem do moich rozkmin o przyszłości roli PMa ⤵️

2. Trzy scenariusze przyszłości PM-a

Zebrałem więc swoje doświadczenia + przeanalizowałem dziesiątki wypowiedzi produktowych liderów i widzę trzy wyraźne, choć różniące się od siebie scenariusze w którą stronę idzie product management. Każdy ma swoich zwolenników. Każdy ma sens w określonym kontekście. I nie wykluczam, że wszystkie trzy będą współistnieć.

Kierunek 1: Product Builder / Maker

To najbardziej radykalna wizja - rola product managera przestanie istnieć:

• Tradycyjny podział PM / Designer / Engineer się rozpada. Powstaje nowy typ: "Product Builder / Maker" - jedna osoba, która dzięki AI robi robotę całego Product Trio / Zespołu produktowego.

• Dzięki AI oraz narzędziom takim jak Cursor czy Lovable/v0, Product Maker jest w stanie samodzielnie przejść z pomysłem cały proces od idei, przez research, po stworzenie działajacego rozwiązania.

• "I can build the MVP solo in a week" - to jest value proposition tego archetypu PMa.

Główną zwolenniczką tego kierunku jest Claire Vo (CPO LaunchDarkly, autorka How I AI). Twierdzi ona wprost, że “product management as we know it is over” i jednoosobowa hybryda mogąca pracować nad strategią, discovery, kodować - będzie zajmować się budową produktów.

Kierunek 2: Market-Focused PM

Jeśli “budowanie” staje się towarem dostępnym dla każdego dzięki AI, to co staje się wyróżnikiem? Narracja, Brand i Go-to-Market.

• W tym scenariuszu PM oddziela od Product Trio i łączy się kompetencyjnie z Product Marketing Managerem. Zajmuje się rynkową narracja produktu, spójnością, monetyzacją i market fit, a nie za rozwiązywanie konkretnych problemów użytkowników.

• Brian Chesky zrestrukturyzował Airbnb właśnie w tym kierunku - eliminując klasycznego PM-a pracującego z zespołem DEV na rzecz hybrydy z Product Marketerem.

• "I can ensure the market understands and buys what we build" – to jest value proposition tego archetypu PMa.

Kierunek 3: Małe elitarne zespoły produktowe

To wizja bliższa tradycyjnemu modelowi, ale z AI jako supermocą, która pozwala małemu elitarnemu zespołowi (jakaś formą Product Trio) robić cały product management.

• Narzędzia przejmują 50-70% operacyjnej “bieżączki” dla każdej z ról Product Trio, a członkowie zespołu produktowego stają się “super IC” (Individual Contributor), czasem też nazywanych “T-shaped builders” - ludzi z głęboką ekspertyzą w jednym obszarze i wystarczającą szerokością, żeby kontrybuować w wielu innych.

• Dzięki temu razem, małym zespołem, są w stanie samodzielnie i ekspresowo przejść z pomysłem cały proces od idei, przez research, po stworzenie działajacego rozwiązania.

• PM w tym modelu skupia się na strategii, discovery, i decyzjach “co NIE budować”.

• Każdy z Product Trio ma swoje specjalizacje, jednak role mocno się przenikają i nikt nie chowa się za procesem. PM nie boi się tworzyć prototypu i spojrzeć w kod, Product Engineer nie boi się ewaluować pomysłów i zajmować się discovery.

• Marty Cagan i Teresa Torres są głównymi zwolennikami tej wizji.

3. Mój strategiczny „BET”

Który scenariusz wygra? Szczera odpowiedź: Nie wiem.

I nikt nie wie. Nawet Cagan, Torres czy Vo. Te zmiany się dzieją teraz, w czasie rzeczywistym i efekty są różne w różnych firmach.

Ale wiem jedno: żeby mieć własne zdanie, muszę to poczuć na własnej skórze:

• Jak wygląda praca przy produkcie AI z milionami generacji LLMa miesięcznie?

• Jak strategia, discovery i ewaluacja działają, gdy model jest probabilistyczny a nie deterministyczny?

• Jaką wartość wnoszę do zespołu w świecie AI? Czy moje kompetencje są jeszcze potrzebne? A jeśli tak - to jakie?

Tego nie dowiem się z artykułów, podcastów, książek.

Tylko z praktyki w produkcie, który generuje miliony requestów do LLM-ów miesięcznie. Gdzie są realni użytkownicy, realne problemy i realne konsekwencje podejmowanych decyzji.

Mój bet jest prosty:

Sposób budowania produktów zmienia się tak szybko, że nie da się tego obserwować z boku. Muszę być w środku tej fali.

Kto teraz nie wsiądzie do pociągu budowy produktów hands-on z AI, za 2 lata nie będzie rozumiał co się dzieje i dlaczego (poza książkową teorią).

Nigdy nie chciałem być “konsultantem-szkoleniowce”, który uczy teorii z książek i cudzych case studies. Nie wierzę w taką drogę. Zawsze bazowałem na własnych doświadczeniach, własnych porażkach i sukcesach, własnej “skin in the game” (uwielbiam to określenie).

Dlatego w połowie roku podjąłem strategiczną decyzję:

Wracam do pracy operacyjnej przy produkcie

Od sierpnia pracuję jako Head of Product w BrainBits.AI w którym:

• AI jest corem działania - Conversational AI, LLM jest sercem produktu, a nie tylko SaaSem z dodatkiem AI. Mnóstwo generacji miesięcznie, prawdziwe problemy z prompt engineeringiem, doborem modeli, halucynacjami, latencją, AI Evals.

• Mały zespół złożony z “super” IC - nie ma rozbudowanej struktury. Nie ma „PM który tylko pisze tickety,". Każdy musi być fullstackowy. Każdy musi rozumieć produkt end-to-end.

• Realny wzrost i skala: ~30-40% growth w ostatnich 3 miesiącach. Produkt z użytkownikami, przychodami i ciśnieniem, żeby dowozić wartość.

Wierzę, ze jest to setup w którym mogę weryfikować swoje hipotezy o tym, jak wygląda dobry product management w erze AI - zarówno od strony budowy produktów AI, jaki i pracy samego PMa.

Zapraszam na relację z frontu

A co to wszystko znaczy dla newslettera i działalności Product Academy?

Nie znikam. Dalej będę pisał. Dalej będę prowadził szkolenia.

Ale aktualizuję źródło wiedzy - zamiast „wspomnień weterana" będzie więcej "relacji z frontu" o tym jak budować produkty - jak teoria zderza się z rzeczywistością budowania produktów AI w 2025 roku.

Zapraszam Cię do obserwowania tej drogi. Pierwsze wnioski po 4 miesiącach już w następnym wydaniu ;)

Subscribe now

Dwa lata temu pracowałem jako Head of Product w SentiOne. Miałem zespół. Miałem budżet. Robiłem AI, zanim stało się to modne.

A jednak we wrześniu 2023 r. rzuciłem to wszystko, by budować Product Academy.

Przejście z bezpiecznego fotela Head of Product na “swoje” to marzenie wielu PM-ów, ale też ogromne ryzyko. Po 2 latach robię podsumowanie pracy na swój własny rachunek, by dać Ci realistyczny obraz tego jak to wygląda.

Bez bullshitu. Z liczbami. I decyzją czy wracam na etat. 👇

W dzisiejszym wydaniu:

1. Dlaczego rzuciłem „pracę marzeń” w 2023 roku?

2. Era walki z „backlog product managementem” - moja misja i fundament PA

3. Zderzenie z rynkiem - jak wyglądały początki i te 2 lata

4. ZWYCIĘSTWA z których jestem dumny

5. PORAŻKI, czyli co nie wyszło?

6. Ile zarobiłem na swoim? Wyniki PA

7. Co dalej? Czy wracam na etat?

Subscribe now

1. Dlaczego rzuciłem „pracę marzeń”?

Zacznijmy od kontekstu. SentiOne to była moja najdłuższa praca w karierze. I najbardziej satysfakcjonująca.

Przez lata zbudowałem tam coś, z czego byłem naprawdę dumny - od zera stworzyliśmy platformę Conversational AI, obsługującą setki tysięcy rozmów miesięcznie w największych content center. Dodatkowo SentiOne Listen - używany przez firmy na cały świecie.

Prowadziłem zespół produktowy jako Head of Product. Miałem realny wpływ na kierunek rozwoju. Pracowaliśmy nad AI i NLP, zanim “sztuczna inteligencja” stała się buzzwordem na każdej konferencji.

Dlaczego więc to zostawiłem? Rynek pracy dla Product Managerów nie wyglądał w 2023 roku przecież kolorowo.

Ostatecznie jednak wszystko sprowadza się do Twojego osobistego kompasu wartości. Polecam każdemu co jakiś czas do tego wracać - właściwie decyzje okazują się wtedy prostsze i bardzo oczywiste.

Mój kompas wskazał mi dwa powody, dla których musiałem odejść:

1️⃣ Rozjazd wartości

• Pracowałem z wieloma świetnymi ludźmi. Ale z czasem w firmie zaczęło pojawiać się coraz więcej osób, z którymi po prostu nie było mi po drodze. Ludzie z zupełnie odwrotnymi WARTOŚCIAMI do moich w kontekście współpracy, budowy zespołu, budowania produktu.

• Nie chodzi o to, że wszyscy musimy być tacy sami. Ale są pewne dla mnie fundamentalne wartości, których nie mam zamiaru łamać we współpracy. I coraz częściej czułem, że muszę iść na kompromisy, na które nie chciałem się godzić.

2️⃣ Dusza przedsiębiorcy

Drugi powód był dużo bardziej osobisty. Kto mnie zna dłużej, ten wie, że nigdy nie byłem typowym pracownikiem etatowym.

• Moja droga do Product Managementu nie wiodła przez managerskie szczeble, ale przez fascynację i budowę… własnych (głownie nieudanych) startupów. Zaczynałem jeszcze na studiach. Właśnie ta chęć budowania i przedsiębiorczy mindset ostatecznie zaprowadziły mnie do roli PM-a.

• Ale bycie „CEO produktu” na etacie to jednak nie to samo, co budowanie swojego produktu. Zawsze miałem z tyłu głowy chęć powrotu na swoje. Chęć budowania czegoś od zera, na własny rachunek i brania za to pełnej odpowiedzialności.

• Do tego doszła pasja do edukacji, dzielenia się widzą i rozwoju innych. Product Vision budowałem po godzinach już od 2016 roku. Prowadziłem warsztaty, pisałem, nagrywałem. Czułem ogromną satysfakcję, widząc, jak inni rosną dzięki moim wskazówkom.

• Sprawiało mi to ogromną frajdę, ale doba nie jest z gumy.

Traktowanie tego jako side-project przestało wystarczać. Wiedziałem, że jeśli chcę to zrobić na poważnie, muszę postawić wszystko na jedną kartę i wejść w to na 100%.

2. Era walki z „backlog product managementem” - moja misja i fundament PA

Dla mnie była to wtedy era walki z backlog product managementem.

Przez poprzednie 12 lat pracowałem na pierwszej linii frontu jako Product Manager, potem Head of Product. Współpracowałem z dziesiątkami zespołów produktowych. I widziałem jeden powtarzający się wzorzec:

Wielu Product Ownerów świetnie zarządza backlogiem. Wspierają zespół w codziennej pracy. Pilnują sprintów. Ale to za mało, żeby współtworzyć produkty, które naprawdę robią różnicę.

• Sam przeszedłem tę drogę - od typowego Scrum PO do Product Managera i Head of Product. Wiem, jak trudne jest przekroczenie granicy między “zarządzaniem backlogiem” a realnym product managementem.

• Wiem też, że większość PM-ów NIE pracuje w “idealnych firmach produktowych” z case studies. Nie pracujemy w idealnych firmach „product-led”. Nie mamy idealnych zespołów. Sami też nie jesteśmy idealni.

I właśnie dla nich chciałem stworzyć Product Academy.

Miejsce, gdzie produktowcy mogą zrobić kolejny krok - nie w oparciu o abstrakcyjne frameworki z książek, ale o to, co realnie może zadziałać w ich nieidealnych środowiskach. Nie od konsultantów i influencerów, ale od praktyków, którzy sami przez to przeszli, którzy też mają ubrudzone ręce w codziennej pracy operacyjnej.

Zdefiniowałem nawet swoją małą Misję:

Pomóc 1000+ produktowcom przekroczyć granicę między „zarządzaniem backlogiem” a prawdziwym product managementem.

Wystartowanie Product Academy miało być fundamentem tej mojej walki z backlog product managementem.

Misja była jasna. Wizja była piękna. A potem przyszedł rynek i powiedział: „Sprawdzam”.

3. Zderzenie z rynkiem

Widziałem już dlaczego, wiedziałem już co chcę robić. Decyzja zapadła:

Żeby było jasne - to nie jest tak, że “rzuciłem wszystko i zacząłem od zera z laptopem w kawiarni”.

Product Vision, side-project edukacyjny prowadzony z Olgą Springer, budowałem po godzinach od 2016 roku. Siedem lat zbierania doświadczeń, budowania marki osobistej. Razem z Olgą realizowaliśmy już wcześniej Product Management Academy - wiedziałem, że będą pierwsi klienci na 1-2 duże szkolenia w roku.

To dawało jakąś poduszkę na start.

Wydawało się, że będzie z górki. Że przejście z “po godzinach” na “full-time” to tylko kwestia zwiększenia tempa. W końcu będę mógł poświęcić temu 100% uwagi i efekty przyjdą same.

2023: Bolesna weryfikacja

Moja logika była prosta: na etacie miałem może 15-20 godzin tygodniowo na Product Academy. Teraz będę miał 40+. Czyli 2-3x więcej czasu, który przyspieszy tempo wzrostu i monetyzacji.

Proste, prawda? No to już Wam piszę, jak to realnie wyglądało 👇

1️⃣ Więcej czasu ≠ więcej pieniędzy. Przynajmniej nie od razu.

Szybko okazało się, że nagły wzrost dostępnego czasu nie przekłada się magicznie na powtarzalne, zarabiające na siebie produkty. Mogłem pracować 12 godzin dziennie nad nowym programem szkoleniowym - ale to nie znaczyło, że ktoś go zaraz kupi.

Bo klienci B2B nie zaczęli nagle walić drzwiami do Product Academy. Firmy nie wiedzą, że istniejesz, tylko dlatego że rzuciłeś etat. Nawet jeśli chcą kupić Twoje usługi to ten cykl trwa.

Potencjalni uczestnicy kursów też nie budzą się rano z myślą “o, Tomek poszedł na swoje, to się zapiszę”. Dlatego piszesz posty, nagrywasz podcasty, budujesz newsletter... To wszystko to duża inwestycja czasowa.

2️⃣ Trudne (psychicznie) pierwsze miesiące bez przelewu

Przez lata, do 10 dnia miesiąca na konto wpływała stała pensja. Nagle cisza. Widzisz, że jeśli nie chcesz, by oszczędności zaczęły topnieć, musisz zarobić. I to szybko.

To uczucie, na które trudno się przygotować, nawet jak masz poduszkę finansową. Racjonalnie wiedziałem, że tak będzie - miałem oszczędności, plan, świadomość tej sytuacji. A mimo to - to było trudne uczucie. Każdy wydatek to nie “wydaję z tego, co zarobiłem”, tylko “wydaję z tego, co odłożyłem”. I jeśli nic się nie zmieni, to za X miesięcy będzie zero.

A w edukacji cykl zwrotu jest długi. Zbudowanie porządnego programu szkoleniowego to miesiące pracy, które zwrócą się (o ile w ogóle) dopiero po kolejnych kilku miesiącach sprzedaży.

Na etacie to nie problem, bo to był po prostu “dodatek” do pensji. Z pensji można było zawsze pokryć koszty trenerów, nawet jeśli coś nie wyjdzie. Teraz jest trochę inaczej.

3️⃣ Wzrost kosztów

Przejście na „swoje” to nie tylko brak pensji, to nagły wzrost kosztów. Żeby budować profesjonalną akademię, potrzebowałem infrastruktury. Oto moje realne koszty na start (netto), żebyście mieli obraz skali:

• Platforma kursowa: ~4 000 zł

• Narzędzia do newslettera, email marketingu, strony: ~4 000 zł

• Google Workspace: ~1 000 zł

• Inne narzędzia i software: ~4 000 zł

Nagle robi się z tego konkretna suma kosztów stałych, które musisz pokryć, zanim w ogóle zarobisz pierwszą złotówkę na czysto.

4️⃣ Kuszące strzały

Moim zarabiającym na siebie MVP na start były szkolenia dedykowane dla firm. Złapałem pierwsze zlecenia w 2023 roku - MIG Group, STATSCORE (dziękuję Wam bardzo :)). Nie było tego dużo, ale wystarczyło, żeby oszczędności przestały tak szybko topnieć.

Tylko, że to rozwiązanie ma swoją ciemną stronę: szybszy cash flow vs czas na budowę skalowalnych produktów.

Szkolenie dedykowane to też kilka(naście) dni intensywnych przygotowań, potem follow-up. Dostajesz za to konkretną kwotę na konto - fajnie. Ale ten czas nie wraca. A Ty zamiast budować skalowalny produkt, sprzedajesz swoje godziny.

2024-25: Rozwój biznesu

Po trudnym starcie przyszedł czas na stabilizację i skalowanie. Tak jak w produkcie - po fazie MVP i „gaszenia pożarów”, musisz zacząć budować trwałe fundamenty.

Oto skondensowana historia 2024 i 2025 - przelot przez najważniejsze wydarzenia, żebyśmy mogli przejść do najważniejszych wniosków.

Rok 2024: Product Discovery i Metryki produktowe

To był rok, w którym postawiłem na to co kluczowe dla każdego PMa: Product Discovery i ewaluację wprowadzonych zmian za pomocą analityki produktowej. Chciałem skupić się na tym, co realnie boli zespoły - jak przestać zgadywać, a zacząć podejmować lepsze decyzje.

Najważniejsze momenty:

• Start Product Discovery Academy z Krzyśkiem Miotkiem

• Nowa wersja Akademii Analityki Produktowej z Olgą Springer i Łukaszem Podgajnym

• Mentoring dla 4 product managerów i leaderów zespołów produktowych

• Seria szkoleń zamkniętych dla ok. 10 firm z product discovery i metryk produktowych

• 2 kolejne edycje Product Management Academy

Całość roku pięknie zakończyła się… nagraniem podcastu z Marty Caganem!

Gdyby ktoś mi kiedyś powiedział, że będę miał okazje porozmawiać w podcaście z autorem mojej ulubionej produktowej książki i guru product managementu na świecie - nie uwierzyłbym. Dalej trochę nie wierzę.

2025: Strategia produktowa

Jeśli 2024 było o discovery i metrykach, to 2025 jest o strategii produktowej.

Co się wydarzyło:

• Strategia Produktowa dla Tutlo - praca nad przygotowaniem i wdrożeniem strategii produktowej (+strategii produktowej AI) w jednej z najciekawszych polskich firm edtech. Łącznie kilka miesięcy ciężkiej pracy hands-on.

• Start Product Strategy Meetup z Mariuszem Witkowskim - wirtualnego spotkania dla liderów produktowych

• Wszedłem w głębszy consulting i mentoring strategiczny

• Największa edycja Product Management Academy, kolejne edycja pozostałych programów szkoleniowych

• Pierwszy AI Product Bootcamp z Jakubem Uniejewskim – nowy format, nowy temat, nowe wyzwanie

Tyle historii. Przejdźmy do tego, co tygrysy lubią najbardziej - czyli mięsa. Czego nauczyły mnie te dwa lata i co z tego możesz wyciągnąć dla siebie? Czas na szczerą retrospektywę.

Subscribe now

4. ZWYCIĘSTWA z których jestem dumny

Zaczniemy od rzeczy, z których jestem naprawdę dumny w trakcie tych 2 lat.

4.1. 1000+ przeszkolonych produktowców

Pamiętasz mój cel z początku? Pomóc 1000+ produktowcom wyjść z roli “backlog managera”. Nie jestem w stanie tego wprost policzyć, ale mogę zobaczyć ile mamy absolwentów szkoleń Product Academy.

Słownie: Ponad TYSIĄC ABSOLWENTÓW 🤯

I mówię tu tylko o płatnych szkoleniach z warsztatami. Nie wliczam w to tysięcy osób na darmowych webinarach, live’ach, newsletterach, kursach online czy wystąpieniach/warsztatach na konferencjach. Brzmi to niesamowicie.

Liczba uczestników to jedno. Ważniejsze jest, jak zadowoleni absolwenci za nią stoją:

• Satysfakcja (CSAT): oscyluje na poziomie 5,5 / 6.

• NPS (Net Promoter Score): osiąga u nas astronomiczny poziom 80-90 / 100. Widzę to też w praktyce - ile osób trafia na szkolenia z poleceń.

• Retencja: Zdecydowana większość uczestników (70-80%) dociera do końca naszych wymagających, kilkutygodniowych programów.

4.2. 400 000 zł dla produktowych praktyków 💰

To kwota, z której jestem chyba najbardziej dumny.

Ponad 400 000 zł netto - taką łączną kwotę wypłaciłem przez ostatnie 2,5 roku partnerom i mentorom - produktowym praktykom współpracującym z Product Academy.

Płacenie partnerom szkoleniowym to raczej standard na rynku. Ale mentorzy-praktycy przygotowujący prezentacje, case study, inspiracje? Rzadko kiedy są wynagradzani - nawet w “premium” produktach edukacyjnych.

Dla mnie to zawsze było oczywiste: występujesz u mnie, dzielisz się swoim doświadczeniem i wiedzą, poświęcasz swój czas w mojej inicjatywie, na której zarabiam → należy Ci się za to wynagrodzenie.

I tego chcę się trzymać.

Tym bardziej cieszę się, że taka kwota mogła trafić do kieszeni innych doświadczonych product managerów, których wiedzę szanuję.

4.3. Wartość przede wszystkim (wartość > zysk)

Przejście z side-projectu na full-time oznacza większą presję na kasę. Nie ma już pensji, która ratuje miesiąc bez sprzedaży. Pojawia się ciśnienie, żeby monetyzować wszystko, co się da.

Mega się cieszę, że mimo tego ciśnienia udało mi się utrzymać moje fundamenty:

• 1️⃣ Po pierwsze: wartość

  • Moim kryterium udanego szkolenia nie jest to, ile z niego zarobiłem. Nawet w sumie nie to, ile osób da wysoką ocenę. Ale ile osób zastosuje przynajmniej 1 rzecz ze szkolenia w swojej realnej pracy.

  • To nie jest łatwe do zmierzenia. Ale jeśli projektuję szkolenie z myślą przede wszystkim o tym - to naturalne stają się ciągłe usprawnianie, dostosowywanie do uczestników, obsesyjne myślenie “jak to jeszcze ulepszyć” i sprawić żeby było łatwiej aplikowalne.

  • Koszt czasowy tego jest duży, ale nie potrafię chyba inaczej.

• 2️⃣ Dostępność cenowa:

  • Bilety na niektóre programy wyprzedają się w ciągu kilkunastu godzin. W feedbacku słyszę co jakiś czas: “Tomek, nauczyłem się tu więcej niż na studiach podyplomowych za 7 tysięcy”. Logika biznesowa podpowiada - podnieś drastycznie cenę. Dużo więcej zarobisz. Korpo zapłacą.

  • Ale dla mnie priorytetem zawsze było tworzenie edukacji dostępnej. Dostępnej także dla tych, którym korpo nie postawi szkolenia. Dla PM-ów, którzy płacą z własnej kieszeni, bo chcą się rozwijać.

  • Ceny oczywiście rosną - bo koszty rosną, bo wartość rośnie. Ale moim celem jest taki format, żeby przeciętny PM mógł sobie na niego pozwolić.

• 3️⃣ Realna praktyka

  • Uczę tylko tego, co sam stosuję. Metod, które sam wykorzystywałem i wiem, z czym się realnie wiążą - jakie plusy i minusy. Nie sprzedaję teorii z książek czy warsztatów, której nie zweryfikowałem “hands on” w produkcie.

  • To samo dotyczy partnerów i mentorów, których zapraszam do szkoleń. Hands-on praktycy, nie konsultanci i influencerzy. Ludzie, którzy realnie doświadczają pracy produktowej (i konsekwencji z tym związanych).

4.5. “Szalone” projekty, które nie mają sensu biznesowego

Praca na swoim daje mi przestrzeń na rzeczy, które w normalnej firmie nastawionej na zysk nie miałyby racji bytu. Dzięki temu mogę realizować swoje, czasem szalone i trochę kontrowersyjne, pomysły.

Co zrobiłem przez te 2 lata:

• 100+ rozdanych książek - coroczna akcja urodzinowa + dodatkowe akcje rozdawania książek. Z własnej kieszeni, bo chcę się odwdzięczyć społeczności za wsparcie.

• Product Discovery Challenge - letnie praktyki, gdzie kilkaset osób mogło za darmo ćwiczyć prowadzenie wywiadów z użytkownikami. Wywiadów, które przydały się fundacji ratującej zwierzaki.

• 10 000+ zł zebrane na cele charytatywne – poprzez różne akcje społeczności produktowej

• Coroczne produktowe... wyzwanie szachowe - Lubie szachy i product management, to… dlaczego tego nie połączyć?

• Product Leadership Meetup - pierwszy w Polsce meetup online dla doświadczonych liderów produktów

Żaden z tych projektów nie zarabia, każdy kosztuje czas, niektóre wręcz pieniądze. Wbrew pozorom, nie przynoszą one realnych “leadów”. Ale to jest właśnie ta wolność, która daje mi praca na “swoim”. Nikt mnie z ROI nie będzie tu rozliczał, więc mogę robić rzeczy, które mają sens dla mnie i dla społeczności.

5. PORAŻKI, czyli co nie wyszło?

Transparentność to nie tylko chwalenie się sukcesami. Jako PM-owie wiemy, że “lessons learned” z porażek są często cenniejsze niż te z sukcesów. Dlatego w duchu mojego ukochanego radical candor - oto lista rzeczy, które koncertowo mi nie wyszły (lub po prostu uznaje je za błędne decyzje).

• 1️⃣ Budowanie społeczności (kampus Product Academy)

  • Miałem piękną wizję: stworzyć zamkniętą przestrzeń, gdzie kursanci będą się wymieniać wiedzą, networkować i pomagać sobie nawzajem.

  • Rzeczywistość: Zbudowanie zaangażowanej społeczności jet bardzo trudne. Mimo że dyskusje się toczą, nie czuję, by wnosiło to wystarczającą wartość dla uczestników. Ludzie są zmęczeni kolejnymi Slackami i Discordami.

  • To pomysł, której wciąż daleki jest od dostarczenia realnej wartości.

• 2️⃣ Rozdrobnienie

  • To mój największy grzech. Ciężko o głębokie myślenie strategiczne, gdy skaczesz między tematami. Szczególnie gdy jesteś soloprenurem i nie stoi za tobą wielki operacyjny zespół.

  • Mam miliony pomysłów i inspiracji, jak jeszcze można wnieść wartość społeczności produktowej. Nowy program, nowy cykl, kolejne wyzwanie, kolejny podcast itd.

  • Brzmi to fajnie, ale ciągłe wchodzenie w nowe tematy utrudnia skalowanie tego, co już działa.

• 3️⃣ Horyzontalne skalowanie przez duże programy

  • Uruchomienie kilku dużych programów szkoleniowych (PMA, Analityka, Discovery), duże szkolenia dedykowane i konsulting - to wszystko było niesamowitym wyzwaniem, podczas których wiele się nauczyłem.

  • Ale… dla solopreneura już czuję że to był krok za daleko. Każdy z tych programów wymaga ciągłej atencji, marketingu i operacyjnego wsparcie. Ostatecznie IMHO utrzymanie takiej “szerokiej półki” angażujących produktów bez rozbudowanego zespołu jest na dłuższą metę niemożliwe.

• 4️⃣ Brak płatnej reklamy

  • Z jednej strony brzmi dumnie: “Cała sprzedaż oparta na poleceniach i organicznej sprzedaży. 0 zł wydanych na reklamy”.

  • Ale z perspektywy biznesowej to zabranie sobie jednego z silników wzrostu. Organiczny wzrost jest świetny, ale do szybszego skalowania zabrakło mi odwagi, by odpalić ten trzeci silnik wzrostu - płatną akwizycję. Kilka razy się przymierzałem, ale nigdy nie dowiozłem tego tematu do końca.

6. Własny solo-biznes - na co trzeba być gotowym?

Często romantyzujemy startowanie nowego biznesu. W internecie bycie „na swoim” wygląda jak bajka przepełniona sukcesami.

Po ponad 2 latach wydaje mi się, że mam już trochę doświadczeń i mogę powiedzieć z czym się to realnie wiąże (a przynajmniej wiązało dla mnie).

Dlatego zanim rzucisz etat, muszę Ci opowiedzieć o kilku rzeczach, które dla mnie były trudne i na które warto być gotowym:

• Samotność - to chyba najtrudniejsze dla mnie. Na etacie narzekałem na spotkania. Na “swoim” tęsknię za biurem i pogadaniem z kimś przy kawie. W biurze, gdy masz problem, idziesz na kawę z kumplem z zespołu, robisz burzę mózgów, narzekasz na management. Jako solopreneur? Jesteś sam. Jesteś sam ze swoimi decyzjami, wątpliwościami i porażkami. Musisz sam być dla siebie szefem, mentorem i motywatorem.

• Zmienność - są miesiące, gdy wszystko się kręci, nie wiesz w co włożyć ręce, klienci sami się do Ciebie odzywają. A potem przychodzi miesiąc ciszy i brak kolejnego kontraktu. Ta sinusoida potrafi bardzo męczyć psychicznie. Stabilizacja to luksus, za którym czasem się tęskni. W dobrych miesiącach czujesz się “królem świata”. W złych, kładziesz się spać i myślisz o powrocie na etat.

• Multitasking na sterydach. Jesteś CEO, Head of Product, Salesem, Marketingiem, Finance i Office Managerem w jednym. Codziennie milion małych problemów. Zostawiasz pracę nad nowym kursem, żeby wystawić fakturę. Przerywasz pisanie artykułu, żeby naprawić komuś dostęp do platformy.

• Urlop i choroba to fikcja - na etacie bierzesz L4 i świat się nie wali. Na swoim? Masz zaplanowane szkolenie dla 20 osób i czujesz, że zaczyna Cie rozkładać choroba. Spinasz się i (poza hardocorwymi sytuacjami) zrobisz to szkolenie. Jesteś na wakacjach i pada platforma kursowa albo klient ma problem z fakturą? Wyciągasz laptopa i naprawiasz. Nie ma dni w 100% wolnych od odpowiedzialności.

• Syndrom oszusta - to pytanie wracało do mnie jak bumerang: „Czy ja naprawdę mogę mówić innym, jak mają pracować, skoro sam nie pracuje już "hands-on?” Nie jestem już aktywnym PM-em wewnątrz organizacji. Czy nie zamieniam się w „szkoleniowca-teoretyka”, który opowiada o frameworkach, a nie czuje już codziennego bólu ich wdrażania? To ciągła walka o to, by pozostać blisko praktyki i nie odlecieć w świat teorii.

Nie mówię, że każdego to musi dotknąć. Tak po prostu było w moim przypadku i chce Cie po prostu na te tematy uczulić jeśli myślisz o startowaniu czegoś „solo”.

6. Ile zarobiłem na swoim? Wyniki PA

Kto mnie zna - ten wie, że finanse nie są dla mnie najważniejsze.

Ale można pisać o misji i wartościach, to jednak na koniec dnia finanse w biznesie muszą się spinać. Czy decyzja o porzuceniu bezpiecznej pensji Head of Product miała sens?

No to poniżej konkret. Kwoty netto, czarno na białym:

Kilka ważnych zastrzeżeń:

• Przychód to nie jest czysty zarobek - poza trenerami, są jeszcze koszty stałe, narzędzia, małe dodatkowe usługi, współprace. Ale jest to niewielka cześć, bo…

• …0 zł wydałem na płatne reklamy. Zero Facebook Ads, zero Google Ads, zero sponsorowanych postów. A to zwykle drugi duży koszt w biznesie.

Czy to dużo? Czy mało? Każdy może ocenić sam, przykładając to do własnych standardów czy oczekiwań ile według niego powinien zarabiać solo-biznes.

Ja jaram się jednym faktem: w ciągu 2 lat ludzie powierzyli mi ponad 1 milion złotych. Bez grosza wydanego na promocję.

To dla mnie niesamowite wyróżnienie i odpowiedzialność.

Sam oceniam to jako coś wręcz abstrakcyjnego. 15 lat temu, dla zwykłego nieśmiałego chłopaka z 20-tysięcznego Chełmna, operowanie takimi kwotami było nie do wyobrażenia.

Perspektywa, że kiedyś ludzie zapłacą mi milion złotych za dzielenie się wiedzą? Brzmiałoby to jak science fiction.

Subscribe now

7. Co dalej? Czy wracam na etat?

Patrząc na wykresy powyżej, odpowiedź wydaje się oczywista. Biznes się spina, przychody rosną, perspektywy na 2026 są świetne. Nic, tylko skalować, prawda?

Otóż nie. Czas na plot twist 💣.

A właściwie... wróciłem już w sierpniu. Mały zespół, Conversational AI, LLMy i już ponad 2 miliony wysyłanych przez AI wiadomości miesięcznie, ~30-40% growth w ostatnich 3 miesiącach.

„Dlaczego gość, który właśnie pochwalił się milionem przychodu i wolnością, dobrowolnie wraca do biura? Dlaczego wraca na front?”.

Myślę, że to wyjaśnią 2 kolejne newslettery.

Czy to koniec Product Academy? Nie, ale oczywiście czekają nas zmiany.

Do usłyszenia w kolejnym wydaniu ;)

Wtedy nie było jeszcze oficjalnego MCP dla Jiry. Pomyślałem: “Hmm, w sumie czemu nie spróbować tego obejść?”. Jak stworzyć własną integrację z narzędziem, które (jeszcze) nie ma oficjalnego wsparcia dla AI.

I tak poznałem i zacząłem stosować Custom Actions w ChatGPT.

Nie potrzebowałem akurat integracji z Jirą, ale pomyślałem o moim własnym podwórku - stworzenie integracji z moją społecznością Product Academy.

W tym newsletterze pokażę Ci jak to zrobiłem:

1. Co to są Custom Actions i po co Ci to?

2. [DEMO] Co-pilot kampusu PA z custom actions

3. Jak to zrobiłem w praktyce krok po kroku?

4. Custom Actions vs. MCP - kiedy co wybrać?

5. Dlaczego warto się pomęczyć?

Zaczynamy ⤵️

1. Co to są Custom Actions i po co Ci to?

W dużym uproszczeniu: to mechanizm, który pozwala Twojemu GPT komunikować się z zewnętrznym oprogramowaniem za pomocą API (Application Programming Interface). Dzięki temu GPT wie, jakie komendy może wysłać do innego systemu i jakich odpowiedzi się spodziewać.

W praktyce:

• tworzysz sobie asystenta (Custom GPT),

• definiujesz jakie akcje może wykonywać przez dostępne API narzędzia (np. “pobierz zadania”, “utwórz ticket”, “zaktualizuj status”).

W moim przypadku GPT przestał tylko “rozmawiać” o kampusie Product Academy, a zaczął fizycznie wywoływać jego API, żeby pobierać wiadomości lub publikować posty.

2. [DEMO] Co-pilot kampusu PA z custom actions

Nagrałem krótki demo jak stworzyłem swojego wykorzystałem pierwsze Custom Actions w praktyce. Zbudowałem asystenta, który integruje się z Circle (platformą, na której stoi Kampus Product Academy).

Celem było stworzenie bota, który potrafi wchodzić do kampusu i przez API pobierać dane albo w nim publikować.

Zobacz demo (3 min)

Co zobaczysz na nagraniu?

1. Pobieranie danych: Proszę asystenta: “Pobierz ostatnich 5 postów”. On łączy się z API Circle i wyciąga konkretne wiadomości z ogłoszeń.

2. Publikowanie treści: Proszę go opublikować odpowiedniego posta w społeczności.

3. Efekt: Asystent nie tylko generuje treść, ale fizycznie wrzuca ją na platformę. Po chwili wchodzę na Kampus i... post tam jest.

Mówiąc szczerze - trochę się z tym męczyłem. API Circla nie jest super dokładnie udokumentowane, więc trochę debugowania było w pakiecie.

Ale efekt? Bardzo fajne i przydatne narzędzie.

3. Jak to zrobiłem w praktyce?

Jeśli chcesz stworzyć własny Custom Action, oto jak to robię krok po kroku:

Krok 1: Znajdź dokumentację API

Musisz wiedzieć, jak Twoje narzędzie “rozmawia”. Ja po prostu znalazłem dokumentację API Circle (zwykle wystarczy wpisać w Google “[Nazwa narzędzia] API docs”). Większość nowoczesnych SaaS-ów to ma.

Krok 2: Stwórz OpenAPI schema

Custom Actions w ChatGPT potrzebują schematu API w formacie którego chce OpenAPI. To JSON/YAML opisujący jakie endpointy są dostępne, jakie parametry przyjmują, co zwracają.

Dobra wiadomość: Nie musisz pisać tego ręcznie.

Ja po prostu poprosiłem samego ChatGPT o pomoc. Wkleiłem mu fragment dokumentacji i napisałem prompt w stylu: “Przygotuj mi Schema do Custom Action, która pozwoli na pobieranie postów i publikowanie wiadomości”. Prowadził mnie krok po kroku.

Oczywiście nie wyszło od razu - musiałem poprawiać schema, debugować błędy, testować różne konfiguracje. Ale miałem solidny punkt startowy.

Krok 3: Skonfiguruj Custom Action w GPT

W interfejsie Custom GPT:

1. Wejdź w “Configure” → “Actions”

2. Kliknij “Create new action”

3. Wklej swoje OpenAPI schema

4. Skonfiguruj autentykację (API key, OAuth, itp.)

5. Przetestuj pierwszą akcję

Krok 4: Testuj i debuguj (bo nie wyjdzie od razu)

Tutaj poświęciłem najwięcej czasu. Typowe problemy:

• Autentykacja nie działa → Sprawdź czy API key jest w odpowiednim miejscu (header vs. query param)

• Schema jest niepoprawne → GPT podpowie błędy, czytaj je uważnie

• API zwraca błędy → Użyj “View details” w GPT, żeby zobaczyć raw response

To rzadko działa za pierwszym kliknięciem. Ja też musiałem trochę “poprawiać” kod i debugować, żeby autoryzacja zadziałała poprawnie. GPT często wypluwa błędy, ale... też pomaga je naprawić. Wklejasz błąd z powrotem do czatu i pytasz: “Co jest nie tak?”.

Nie zniechęcaj się. To normalne, że pierwsza wersja nie działa. Ja spędziłem kilka godzin na debugowaniu, zanim wszystko zadziałało jak należy.

4. Custom Actions vs. MCP - kiedy co wybrać?

Zanim rzucisz się w wir tworzenia Custom Actions, sprawdź najpierw czy nie ma lepszego rozwiązania.

MCP (Model Context Protocol) to nowy standard od Anthropic, który pozwala AI asystentom (Claude, ale też innym, od jakiegoś czasu też ChatGPT) łączyć się z różnymi narzędziami w sposób ustandaryzowany.

W praktyce: ktoś (często twórcy narzędzia) tworzy serwer MCP, a ty możesz z niego korzystać bez budowania własnej integracji.

ChatGPT podpowiedział mi coś takiego, co całkiem nieźle oddaje różnicę:

Custom Actions = Budujesz most między ChatGPT a API sam. Kontrolujesz wszystko, ale też odpowiadasz za wszystko (autentykację, update’y, maintenance).

MCP = Korzystasz z gotowego mostu, który ktoś już zbudował. Szybsze wdrożenie, lepsze wsparcie, mniej pracy.

Kiedy masz możliwość, lepiej zwykle wybrać korzystanie MCP.

5. Dlaczego warto się pomęczyć?

Bo kiedy to zadziała, magia dzieje się sama ✨. Mój asystent teraz na jedno polecenie “Pobierz ostatnie posty” sam łączy się z kampusem i wyciąga dane, zamiast kazać mi tam wchodzić i szukać ręcznie.

Mogę z tego szybko zrobić np. podsumowanie ostatnich dyskusji w społeczności. Oszczędność czasu i satysfakcja z „zatrudnienia” robota do niewdzięczniej roboty - bezcenne.

P.S. Jeśli uda Ci się spiąć coś ciekawego, koniecznie daj znać – chętnie zobaczę Wasze use-case’y!

Miesiąc później: użyłem go... zero razy.

Znasz to uczucie? Ja aż za dobrze. Na LinkedIn co chwilę widzisz kolejny “game-changing AI workflow”, który “przyspieszy Twoją pracę 10x”. A potem jak próbujesz tego użyć - rozczarowanie.

Problem jest prosty: mamy ocean możliwości AI, czujemy FOMO. I problemem jest z tym na czym się w ogóle skupić.

Przez ostatnie 5 lata testowałem dziesiątki pomysłów na AI w swojej pracy jako PM. Większość z nich to były niewypały. Ale nauczyłem się rozpoznawać co zadziała zanim stracę tydzień na budowanie.

Osobiście rozbijam to na 2 tematy:

• 1️⃣ Produktywność PMa - gdzie warto usprawnić swoją pracę dzięki AI

• 2️⃣ Feature AI w produkcie - gdzie warto budować AI dla userów

To IMHO 2 różne sytuacje. Pierwszy możesz sobie sam potestować w weekend, drugi wymaga strategii i budżetu zespołu. Ale obie ważne. Dzisiaj zajmę się tą pierwszą częścią.

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.

Subscribe now

CZĘŚĆ 1: Produktywność PMa - gdzie warto usprawnić swoją pracę dzięki AI?

Jako że jestem raczej early adapterem - łatwo wpaść mi w pułapkę “robienia AI dla robienia AI”. Dlatego musiałem trochę nad tym popracować. Dzisiaj zamiast rzucać się na każde nowe zastosowanie AI, przepuszczam każdy pomysł przez 3 filtry decyzyjne:

• 1. Filtr #1: Inspiracja od innych PMów

• 2. Filtr #2: Powtarzalne czynności (ROI twojego czasu)

• 3. Filtr #3: Zabawa i eksperymentowanie (gdzie uczysz się AI)

Jeśli temat nie pasuje do żadnego z tych filtrów - raczej odpuszczam.

1. Filtr #1: Inspiracja od innych PMów

Pierwsza zasada: nie wymyślam koła na nowo.

Jeśli widzę, że senior PM-owie stosują coś w podobnym kontekście co ja - to jest dla mnie zielone światło do eksperymentowania. Kluczowe słowo: podobnym kontekście.

1.1. Jak to wygląda w praktyce?

Nie chodzi o to żeby brać WSZYSTKIE super inspiracje z LinkedIn-a, czy pięknych webinarów. To często bullsh*t. Chodzi o to żeby znaleźć ludzi:

• Którzy mają podobne wyzwania co ty (np. podoba skala organizacji) - “influencer AI” nie ma takich wyzwań, bo pracuje solo.

• Którzy faktycznie pracują hands-on przy produktach (a nie tylko piszą o tym)

• Którzy pokazują rezultaty w swojej pracy (z plusami i MINUSAMI), nie tylko screeny

1.2. Mój przykład z życia:

Niedawno byłem na Product Campie w Berlinie. Było tam mnóstwo teoretycznych wystąpień, ale jeden gość z widowni pokazał coś nieoczywistego czego używa na codzień. Zamiast trzymać wiedzę produktową w Jirze czy Docsach, pracuję trochę jak developer

• wszystkie produktowe informacje (wywiady, insighty, strategię, decyzje) trzyma w w ustrukturyzowanych plikach Markdown na GitHubie.

• do pracy i myślenia używa Claudy Code - dzięki temu może dynamicznie dołączać konkretne, relevantne źródła do promptów, tworząc precyzyjny kontekst dla AI.

• opowiadała jak te produktowe repo napędzę agentów kodowania (dla zespołu DEV) + mógł budować własnych, wyspecjalizowanych agentów AI, które automatyzują analizę i wyciągają automatycznie insighty z… automatycznie zbieranych informacji od uzytkowników, oszczędzając dziesiątki godzin pracy.

Widać było, że żyje tym na codzień, pokazywał nam swoje zastosowania. Mówił co jest w tym fajne, a co nie do końca, jakie problemy napotyka.

Było ciekawie, inspirująco, PRAKTYCZNIE… więc spróbowałem i teraz sam od kilku miesięcy pracuje dużo w ten sposób.

1.3. Czerwone flagi (na co uważam):

• ❌ Wielkie workflow’y z LinkedIn - jeśli wygląda jak dzieło sztuki, prawdopodobnie nikt tego nie używa

• ❌ “AI influencerzy”, którzy nie pracują hands-on przy rozwoju produktów - oni budują content, nie rozwiązania które stosują w pracy produktowej. Większości tych zastosowań sami nie wykorzystują, albo też nie zastosujesz ich w swojej pracy przez to, że pracujesz w zespole.

• ❌ Mocnych stwierdzeń typu “AI przyspiesza moją pracę 10x w 10 min” - nie spotkałem się z czymś takim. Przyspieszenie owszem, ale raczej po wielu tygodniach eksperymentów w zastosowaniu tego u siebie.

1.4. U kogo szukam inspiracji?

• ✅ Hands-on PMowie, early adopterzy AI - ale raczej posty od ludzi którzy mają “Product Manager / Head of Product” w bio, najlepiej cały czas hands-on rozwijają produkty i piszą o konkretnych case’ach, swoich doświadczeniach.

• ✅ Podcasty, Wystąpienia PM-ów pokazujący jak stosują AI w pracy - wiele z nich znajdziesz w podcaście Claire Vo.

• ✅ Konsultanci / Coachowie, ale pracujący realnie przy produkcie - mają zwykle więcej czasu na różne eksperymenty, ale nie robią tego w próżni i sowim biznesie dla 10 osób. Świetnie to podejście oddaje to co robi teraz Teresa Torres.

  • Jest teraz głownie konsultantką i coachem product discovery. Można by wręcz powiedzieć, że discovery influencerm. Nie pracuje wprost hands-on.

  • Ale specjalnie dlatego zaczęła budować swój pierwszy produkt z wykorzystaniem AI - żeby zobaczyć jak AI wpływa na jej pracę (discovery) oraz jak się buduje takie produkty.

  • Sama, na swoim przykładzie pokazuje jak gigantyczna to zmiana.

1.5. Kluczowy insight:

Jeśli 2-3 PM-ów których szanujesz zaczyna używać czegoś niezależnie od siebie - to jest mocny sygnał, że warto przetestować. Jeśli tylko jedna osoba krzyczy jak to jest rewolucyjne - prawdopodobnie próbuje budować swój personal brand, nie dzielić się realnym rozwiązaniem.

2. Filtr #2: Powtarzalne czynności (ROI twojego czasu)

Drugi filtr to najprostszy: AI ma sens tam gdzie masz powtarzalną czynność.

Szukam zadań, które są powtarzalne i nudne, żeby je zrzucić na AI. Przygotowanie scenariusza wywiadu, analiza setek wpisów feedbacku, generowanie podsumowań.

Ale nie chodzi tylko o mechaniczne zadania. Dzięki LLM-om teraz możesz automatyzować też kreatywną robotę. To jest nowe i tutaj jest największy potencjał dla PM-ów.

2.1. Jak identyfikuję potencjalne taski (co u mnie działa):

Krok 1: Audyt czasu

Przez tydzień zapisuj w Notion/Excel co robię wielokrotnie. Nie musisz tego robić co 15 minut - wystarczy że wieczorem poświęcisz 5 minut na zapis, albo po prostu przejrzysz kalendarz i zrobione zadania z ostatniego tygodnia.

Krok 2: Pytanie o “Częstotliwość” i “Czas”

• Czy to robię częściej niż 2-3x w tygodniu? Jeśli nie - odpuść, nie warto automatyzować.

• Ile to zajmuje każdorazowo? Jeśli <15-20 min tygodniowo łącznie - też raczej nie warto. Setup AI zajmie ci więcej niż zaoszczędzisz.

2.2. Jak to wygląda konkretnie? (przykład)

Case: Przygotowanie scenariusza do wywiadu z użytkownikiem

Przed AI:

1. Przeglądanie poprzednich wywiadów i kontekstu - 30 min

2. Pisanie scenariusz i pytań - 60 min

3. Review i iteracja - 30-90 min

4. Łączenie 2,5h

Po AI (używam Claude/ChatGPT):

1. Przygotowanie - 5 min

   1. Wrzucam kontekst o inicjatywie (który mam już gotowy) + pytania badawcze

   2. Daję framework: “Użyj Jobs-to-be-Done framework”

   3. AI generuje skrypt i 15-20 pytań

2. Przeglądam, dostosowuję, dodaję moje, AI jest moim sparing partnerem - 25 min

3. Łączenie: 30 min

Różnica: 1.5h zaoszczędzone. I co ważne - jakość jest lepsza.

2.3. Bolesne oduczanie się (opóźnione ROI)

Z tym szukanie ROI jest jednak haczyk. Nie traktuje tego tak, że ROI chcę mieć natychmiast. Zwykle tak nie jest, bo po pierwsze musisz najpierw zainwestować swój czas, by metodą prób i błędów, dojść do tego co skraca finalnie ten czas

Musisz też przejść tzw. proces… “oduczaniu się” (Unlearning). Bo musisz się oduczyć starych nawyków. I to oduczanie się trwa bardzo długi i jest bardzo bolesne.

Jest coś takiego jak “odwrócony rower” (kiedy skręcasz kierownicę w lewo, koło idzie w prawo). Jeśli umiałeś jeździć na zwykłym rowerze, przesiadka na odwrócony rower to dramat. Twój mózg walczy z pamięcią mięśniową, nauka trwa bardzo długo. Ale jeśli uczysz się od 0 - czas potrzebny na naukę jest porównywalny do nauki jazdy na “zwykłym” rowerze.

Tak samo jest z AI. Jeśli całe życie pisałeś maile ręcznie albo analizowałeś dane w Excelu, przejście na promptowanie jest nienaturalne i na początku trwa 3 razy dłużej. Musisz zainwestować czas w naukę (i oduczanie się), żeby potem zebrać owoce.

2.4. AI teraz pomaga też w kreatywnej robocie

Wcześniej automatyzowało się głownie mechanikę: podsumowania, wysyłanie maili, przepisywanie danych.

Teraz możesz przyspieszyć:

• Generowanie hipotez do testów

• Tworzenie pytań do wywiadów

• Strukturyzację chaotycznych notatek

• Drafty dokumentów (PRD, one-pagers)

• Analizę feedbacku jakościowego

Kluczowe: AI nie robi tego za ciebie.

• AI daje ci pierwszą wersję, którą ty ulepszasz swoją ekspertyzą. To jak mieć juniora PM-a, który bardzo szybko robi research i drafty, ale ty musisz to review’ować i dopieszczać.

• AI może być Twoim sparing partnerem, kiedy dopracowujesz już swój pomysł. Wskaże Ci luki, co warto poprawić, o czym warto pomyśleć.\

Ale za efekt finalny odpowiadasz TY i jest to efekt Twojej pracy.

2.5. Czerwone flagi (na co uważam)

• ❌ Robisz to raz na kwartał - setup zajmie więcej niż zaoszczędzisz

• ❌ Każda sytuacja jest unikalna i wymaga głębokiego kontekstu - AI nie pomoże

• ❌ Czynność zajmuje 5 minut ale musisz “pomyśleć” przez 2h - tutaj potrzebujesz czasu na myślenie, nie automatyzacji

• ❌ Robienie wielkich i skomplikowanych automatyzacji - może coś Ci przyspieszą, ale jak z każdym rozwiązaniem - wymagają one utrzymania, poprawiania błędów, rozwiązywania kolejnych edge case’ów. Nie mówię, że zawsze to nie ma sensu - ale tu warto się 3x zastanowić.

Subscribe now

3. Filtr #3: Zabawa i eksperymentowanie (gdzie uczysz się AI)

Trzeci filtr może brzmieć mało profesjonalnie, ale dla mnie jest kluczowy. Czasem eksperymentuję z AI nie dlatego, że muszę, ale dlatego, że coś wydaje mi się po prostu ciekawe i mnie “jara”.

Traktuję to jako “piaskownicę”. Często te eksperymenty nie przynoszą żadnego natychmiastowego rezultatu biznesowego. Ale pozwalają mi się uczyć.

W tej fazie Twoim ROI (zwrotem z inwestycji) nie są pieniądze czy zaoszczędzone godziny. Twoim ROI jest nauka. Uczysz się, jak te modele “myślą”, gdzie hallucynują, a gdzie są genialne. Bez tej zabawy, kiedy przyjdzie czas na poważny projekt, nie będziesz miał intuicji.

• Uczysz się jak AI faktycznie działa (nie teoretycznie)

• Odkrywasz use case’y których byś nie wymyślił “od problemu”

• Nawet jak nie wyjdzie - zyskujesz intuicję na przyszłość

• A czasem wyjdzie - i masz super zastosowanie

3.1. Przykład z życia: Wirtualny Tom

Kilka lat temu zbudowałem w SentiOne “Wirtualnego Toma” - AI agenta który zastępował mnie na moim firmowym czacie w czasie urlopu. Potem rozwinął się on w stałe wirtualne wsparcie produktowe dostępne na czacie.

Czy to oszczędza mi masę czasu? Niekoniecznie.

Czy nauczyłem się przy tym jak może działać taki agent? Absolutnie. Dowiedziałem się

• Jak go zbudować i podłączyć do naszego czata

• Jakie są limity autonomicznych agentów

• Gdzie to się przydało ludziom w firmie, a gdzie nie.

Czy wyszły z tego inne pomysły? Tak. Na tej podstawie zrobiłem swój następny challenge - zatrudniłem ChatGPT jako mojego asystenta product managera na miesiąc.

• w każdej możliwej sytuacji wykorzystywałem ChatGPT w swojej pracy produktowej

• zlecałem ChatGPT jak najwięcej zadań, które sam robiłem - gdzie było to tylko możliwe próbowałem wesprzeć się jego działaniem i podpowiedziami.

• dzięki temu dowiedziałem “hands-on” gdzie AI mi się sprawdza, a gdzie nie

Tu masz wnioski z tego eksperymentu:

https://www.productcraft.pro/p/chat-gpt-product-mager-jak-wykorzystac

3.2. Jak rozpoznaję, że coś warto testować “dla fun-u”?

Pytam siebie:

• “Czy mnie to jara?” - Czy myślę o tym pod prysznicem? Czy ciągnie mnie żeby to sprawdzić?

• “Czy nauczę się czegoś?” - Nawet jak nie wyjdzie, czy zyskam jakąś wiedzę/intuicję?

• “Czy mogę to przetestować szybko?” - nie rzucam się od razu na miesięczne projekty. Chciałem przetestować Cursor w pracy PMa? Dałem sobie na to na start 2 wieczory. I potem zdecydowałem, czy chce w to brnąc bardziej.

• “Czy jestem OK z tym że nie zadziała?” - Większość eksperymentów to niewypały. Czy jest dla mnie OK, że to może kompletnie mi (albo u mnie w firmie) nie zadziałać.

3.3. Mój obecny eksperyment: Product Manager jak „Developer”?

Próbuję przestawić się na pracę w tryb Cursor First w mojej pracy Product Managera.

• Zamiast trzymać opisy inicjatyw, persony i notatki w rozproszonych narzędziach, trzymam je w plikach w formacie Markdown.

• Do pisania, tworzenia dokumentów używam Obsidiana (format Markdown), ale do pracy produktowej (czego efektem zwykle jest jakaś forma dokumentu) używam Cursora. To teraz moje główne środowisko pracy.

To jest moje środowisko pracy:

• Dzięki temu mogę łatwo zarządzać całym kontekstem produktowej wiedzy i używać agentów AI do rożnych produktowych prac np.: “Biorąc pod uwagę nasze persony (plik A) i cele na ten kwartał (plik B), zanalizuj ten feedback (plik C)”.

• Czy to jest łatwe? Nie. Jest to dla mnie wciąż nienaturalne i czasem walczę z tym systemem. Oduczam się cały czas jazdy rowerem. Ale bez tego eksperymentu i pracy hands-on - nigdy bym tego nie doświadczył.

Czy się sprawdzi? Nie wiem. Widzę potencjał – to budowanie naturalnego środowiska dla agentów AI, którzy w przyszłości będą naszymi “wirtualnymi asystentami” w zespole produktowym.

3.4. Przykład “niewypału” (żeby było uczciwie)

Zbudowałem Teda - wirtualnego Product Coacha, który analizował profil na LinkedIn / CV i dawał feedback jak je ulepszyć pod kątem roli PM-a.

Brzmi sensownie, prawda? Product managerowie przysyłają CV, Ted (oparty o Custom GPT) daje konkretne wskazówki co poprawić, jakich słów kluczowych użyć, jak lepiej opisać swój profil.

Wydawało się super. Setup zajął mi kilka dni - przygotowanie promptów, testowanie różnych podejść, budowanie “interfejsu” rozmowy.

• Przez pierwszy tydzień dostał ok. 30 CV do analizy. Fajnie! Ludzie korzystają!

• ❌ Potem przyszła jednak rzeczywistość:

  • Jak przyjdą userzy, trzeba to utrzymywać i rozwijać - pytania, feature requesty, bugi

  • Pojawiły się wyspecjalizowane narzędzia, które robiły to 10x lepiej

  • Mało kto faktycznie skorzystał regularnie - 30 userów w tydzień 1, potem 5, potem 0

  • Ludzie potrzebują pomocy z CV raz na rok, nie co tydzień

• ✅ Czy żałuję? Nie. Kilka dni pracy, dużo nauki o buildowaniu custom GPT. Dobry przykład eksperymentu, który nie przyniosł “rezultatu biznesowego”, ale był i tak wartościowy jako nauka.

4. Co dalej?

4.1. Co możesz z tym zrobić dzisiaj?

Nie musisz od razu wywracać swojego życia do góry nogami.

1. Wybierz jedną, powtarzalną czynność, której nienawidzisz (np. pisanie podsumowań po spotkaniach).

2. Zaakceptuj, że przez pierwszy tydzień zrobisz to wolniej z AI niż ręcznie. To jest ta faza “odwrotnego roweru”.

3. Baw się. Daj sobie przyzwolenie na eksperymenty, które wylądują w koszu. To najtańsza forma edukacji.

➡️ W drugiej części

W tym newsletterze pokazałem jak decyduję co usprawnić AI-em w swojej pracy. To jest relatywnie łatwe - niskie ryzyko, możesz iterować szybko, testować w weekend.

Ale co z AI w produkcie? To ryzyko jest zdecydowanie wyższe - stawiasz budżet firmy, czas zespołu, reputację produktu. Nie możesz sobie pozwolić na “spróbujmy bo czemu nie”.

W drugiej części pokażę jak sam podchodzę do tego gdzie wdrażać AI do produktu, a gdzie nie ma to sensu.