→ 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

3 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.

Dzisiaj przyjmy się tematowi churnu w produktach B2B. Większość PMów walczy z odejściami klientów za późno - wysyłają ankietę i zastanawiają się, co poszło nie tak.

Jakub Tutaj, growth PM z Mixmax, pokazał mi, że churn zaczyna się dużo wcześniej. Jego autorski framework „Churn Prevention Funnel” identyfikuje zagrożonych klientów od pierwszego dnia po zakupie. Poniżej znajdziesz napisany przez Kubę poradnik krok po kroku.

BTW. Z Kubą nagrywam też podcast Dodane do Backlogu 🎧. Zapraszamy!

W dzisiejszym wydaniu:

1. Jak zapobiegać i redukować churn (odejścia klientów)?

2. Churn zaczyna się od pierwszego dnia

3. Churn Prevention Funnel.

4. Jak zbudować i używać Churn Prevention Funnel? Krok po kroku.

5. Co możecie zrobić z zagrożonymi klientami?

6. FAQ

Subscribe now

Patrzysz na dashboard i widzisz, że w tym miesiącu kolejnych 15% klientów zrezygnowało z Twojego produktu. Churn. Odejścia. Klienci, których pozyskanie kosztowało setki (a może tysiące) złotych, po prostu znikają.

Co robi większość firm i PM-ów w takiej sytuacji?

Wpada w pułapkę walki z churnem dopiero na końcowym etapie. Zauważają, że użytkownicy masowo rezygnują, więc w panice dodają ankiety przy anulowaniu subskrypcji / produktu (exit surveys), analizują tu zachowanie użytkownika i zastanawiają się: dlaczego?

Choć zbieranie takiego feedbacku jest oczywiście potrzebne, ma jedną zasadniczą wadę: pokazuje nam użytkownika w jego ostatnim momencie - wtedy, gdy decyzja została już podjęta.

1. Jak zapobiegać i redukować churn?

Głęboko wierzę, że churn zaczyna się pierwszego dnia, kiedy użytkownik zaczyna korzystać z produktu…

Od pierwszych minut spędzonych z produktem masz ograniczony czas na

• edukowanie klientów o swojej propozycji wartości (value proposition),

• wyjaśnienie działania produktu, pomoc w konfiguracji

• wsparcie użytkowników w adopcji rozwiązania.

Moment, w którym ktoś kupuje Twój produkt, oznacza tylko tyle, że potencjalny klient zaufał Ci na tyle, by wierzyć, że Twoje rozwiązanie pomoże mu osiągnąć jego cele. Nie oznacza to, że faktycznie pomoże, ani że będzie ufał Ci w nieskończoność.

Dlatego właśnie zapobieganie churnowi nie powinno zaczynać się w momencie, gdy klient rezygnuje z produktu – wtedy niezwykle trudno go odzyskać. Stracili już zaufanie. Zapobieganie odejściom zaczyna się więc pierwszego dnia.

„Więcej churnu występuje w pierwszych 3 miesiącach cyklu życia klienta niż w jakimkolwiek innym okresie.”

– Corey Haines, co-founder of Conversion Factory

2. Churn zaczyn się od pierwszego dnia

Spójrz na te dane - dwa wykresy pokazujące płacących klientów z produktu SaaS:

• 🟢 Prawy wykres to użytkownicy, którzy setupowali produkt - przeszli wymagane akcje onboardingu i ustawienia konta. Np. dla produktu CRM jedną z takich akcji może być przeniesienie danych do systemu lub zmapowanie procesów sprzedażowych.

• 🔴 Lewy wykres klienci, którzy nie setupowali Twojego produktu.

• Na obu wykresach:

  • Oś X to liczba dni aktywności w ostatnim miesiącu (ile dni użytkownicy faktycznie korzystali z produktu).

  • Oś Y to liczba kont klientów.

Co mówią nam te dane?

🔴 Klienci, którzy NIE setupowali Twojego produkt (lewy wykres):

• Większość słupków jest przy 0-5 dniach aktywności. Oznacza to, że większość tych kont, już po kilku dniach od zakupu, jest praktycznie nie używana.

• A po co mają płacić jeśli nie używają produktu? To „walking dead” - użytkownicy, którzy zchurnują w ciągu najbliższych tygodni.

🟢 Klienci, którzy setupowali produkt (prawy wykres):

• Zobacz te piękne duże zielone słupki w przedziale 21-31 dni aktywności. I spójrz na te małe słupki w przedziale 0-5 dni.

• Użytkownicy logują się regularnie, korzystają z produktu, wyciągają z niego wartość.

Wniosek jest prosty: brak aktywności użytkownika oznacza brak długoterminowej retencji. Setup tutaj decyduje o wszystkim. Klienci, którzy nie przejdą przez setup, prawdopodobnie odejdą. To nie kwestia “czy”, tylko “kiedy”.

Problem w tym, że większość firm nie wie, którzy klienci utknęli w setupie. Gdyby tylko był sposób, żeby zidentyfikować klientów na różnych etapach setupu i adopcji produktu, i nauczyć się, jak im pomóc...

Mój sposób to lejek zapobiegania churnowi (Churn Prevention Funnel) 👇

3. Churn Prevention Funnel

Churn Prevention Funnel to sposób patrzenia na kohortę płacących klientów, który pozwoli Ci:

• identyfikować setup rate (wskaźnik konfiguracji konta) i adoption rate (wskaźnik adopcji) klientów

• zidentyfikować odpowiednie segmenty klientów zagrożonych churnem, zanim churn nastąpi

• zidentyfikować, dlaczego klienci są na skraju churnu, zanim churn nastąpi

• stworzyć mocną hipotezę, jak zmienić trajektorię churnu dla zagrożonych segmentów klientów

• A pryz okazji nauczyć się, dlaczego szczęśliwi klienci są szczęśliwi i móc ich identyfikować – są świetnymi kandydatami do ekspansji (np. sprzedaży dodatkowej)

Powiedzmy, że budujemy HealthyRemoter® – aplikację do trackowania czasu pracy zdalnej, która naprawdę promuje work-life balance zdalnych pracowników.

Taj mógłby wyglądać Churn Prevention Funnel dla hipotetycznej aplikacji w arkuszu kalkulacyjnym:

Account (konto) – instancja produktu klienta, która może mieć wielu użytkowników. Przykład: gdy Twoja firma kupuje produkty SaaS jak Atlassian, Productboard, Miro, Figma itd., kupujesz instancję produktu, gdzie możesz zaprosić deweloperów, product managerów, współpracowników, designerów i innych.

User (użytkownik) – osoba zaproszona na konto. Zazwyczaj użytkownicy muszą potwierdzić zaproszenie.

Setup rate – procent płacących kont lub użytkowników, którzy wykonali wszystkie początkowe akcje setupowe (konfiguracyjne). To może być wiele akcji zidentyfikowanych jako obowiązkowe, żeby konto mogło wyciągnąć wartość z produktu. Np. dla produktu CRM jedną z takich akcji może być przeniesienie danych do systemu lub zmapowanie procesów sprzedażowych. Setup użytkownika może oznaczać np., że osoba połączyła się z biznesowym kalendarzem i jest właścicielem lub przyniosła jakieś dane klientów.

Adoption rate – procent płacących kont z użytkownikami, którzy wykonują akcje wskazujące na osiągnięcie wartości z produktu. Dla Miro czy Figma, które są wysoce kolaboracyjnymi produktami, proxy metryką wyciągania wartości może być liczba boardów udostępnionych i przeglądanych przez zaproszone osoby.

Subscribe now

4. Jak zbudować i używać Churn Prevention Funnel?

Zacznijmy od tego - czego potrzebujesz.

Czego potrzebujesz na start?

Aby zbudować swój pierwszy Churn Prevention Funnel będziesz potrzebować:

1. Trochę cierpliwości

2. Dostępu do surowych danych o interakcjach klientów z produktem, które możesz przetwarzać według własnego uznania. Rozwiązanie typu hurtownia danych (np. BigQuery), czy wręcz bezpośrednio dostęp do bazy - powinno wystarczyć. Jest to potrzebne, aby zidentyfikować kluczowe działania użytkownika powiązane z konkretnym kontem i użytkownikiem.

3. Pomocnych ludzi wokół Ciebie – product managerów, researcherów, designerów, analityków biznesowych, którzy pomogą Ci zdefiniować kluczowe akcje setupowe (konguracyjne) konta i użytkownika oraz główne akcje użytkownika.

4. Życzliwego inżyniera danych, który pomoże Ci połączyć potrzebne dane (jeśli sam nie jesteś w stanie).

5. Arkusz kalkulacyjny, żeby zwizualizować i filtrować te dane.

Co z istniejącymi rozwiązaniami do analityki?

A co z istniejącymi rozwiązaniami do analityki - które śledzą retencję i churn?

Istnieje garstka produktów, które dobrze skonfigurowane i połączone z innymi systemami powinny być w stanie zrobić taki Lejek dla Ciebie – odbierać interakcje użytkowników w sensowny sposób i zapewniać niezbędną segmentację.

Uważam, że Amplitude, Mixpanel lub Totango mogą być warte rozważenia.

Problem jednak często jest taki, że w tych systemach nie mamy wszystkich potrzebnych danych. Zanim jest tam dostarczysz (np. dane o subskrypcjach), warto najpierw spróbować i nauczyć się samodzielnie takie funnel. Dowiesz się dzięki temu czego (jakich danych) naprawdę potrzebujesz.

Najważniejszą rzeczą w całym tym ćwiczeniu jest upewnienie się, że faktycznie możesz zamknąć pętlę (dane → wnioski → decyzje i działania) - na podstawie uzyskanych wniosków podjąć decyzję i działania w ramach różnych działów firmy (idealnie) lub w ramach swojego zespołu (dobry początek).

A jeśli później będziesz oceniać narzędzie analityczne, które ma Ci w tym pomóc- będzie to bardziej świadomy wybór.

Krok 1. Zdefiniuj miary:

Na początku musimy określić miary dla poszczególnych kroków naszego Churn Prevention Funnel. Czyli okrśleamy miary dla:

• Kluczowych akcji setupowania konta - jakie akcje akcje musi wykonać admin / właściciel konta, by w pełni skonfigurować konto?

• Kluczowe akcje setupowe użytkownika: jakie akcje akcje musi wykonać użytkownik końcowy by w pełni skonfigurować konto?

• Core user actions: jakie akcje musi wykonać user, które wskazują na to, że osiąga realną wartość z produktu

Miary dla naszego hipotetycznego produktu HealthyRemoter® mogłyby wyglądać tak:

• Kluczowe akcje setupowe konta: Admin zaprosił 1+ użytkownika

• Kluczowe akcje setupowe użytkownika: Potwierdzony użytkownik zainstalował aplikację time-tracking

• Core user actions: Potwierdzony użytkownik trackował czas pracy ORAZ wziął 1+ rekomendowaną przerwę

Takie działania powinniśmy identyfikować przy użyciu ilościowych i jakościowych metod badawczych. Na star oczywiście możesz wyjść od burzy mózgów ze swoim zespołem i interesariuszami.

Krok 2. Zadbaj o właściwe dane (i łatwy dostęp do nich)

Musisz mieć dane ułożone tak, żeby szybko sprawdzić, co robią Twoi klienci. Nie potrzebujesz skomplikowanego modelu danych, czy technik. Wystarczy tabela, widok w Twojej bazie danych, czy po prostu SQL zaowrający najważniejsze informacje.

Twoim celem jest po prostu zorganizowanie dostępu fo danych w taki sposób, abyś mógł łatwo wyciągnąć z nich konkretne informacje.

Dążysz do sytuacji, w której możesz zadać swojej bazie danych proste pytanie (logika zapytania powinna wyglądać mniej więcej tak):

“Pokaż mi wszystkich klientów, którzy dokonali pierwszej płatności w Q3 2022 i wyświetl ich statystyki na dzień dzisiejszy“.

Pseudo SQL, który to obrazuje:

SELECT * from Churn Prevention Funnel
WHERE First payment in Q3 2022 AND Data Snapshot From today

Nie musisz rozumieć SQL-a. Chodzi o to, żeby jednym zapytaniem dostać wszystkie potrzebne informacje. Pokaż to swojemu inżynierowi danych (albo sam to zrób, jeśli umiesz), żeby wiedział co chcesz osiągnąć.

Wynik takiego zapytania eksportujesz do zwykłego arkusza kalkulacyjnego. To w nim powstanie tabela, która posłuży Ci do zbudowania lejka.

Oto przykładowa tabela wyników przeniesiona do arkusza kalkulacyjnego:

Efekt: Tabela w arkuszu kalkulacyjnym, która pokazuje dla każdego konta:

• Czy admin zaprosił użytkowników (ilu)?

• Czy użytkownicy potwierdzili zaproszenie (ilu)?

• Czy zainstalowali aplikację (ilu)?

• Czy wykonują core actions (np. trackują czas, biorą przerwy itp.)?

Kolorowe komórki to kluczowe akcje, które miał wykonać klient.

Krok 3. Zamień surowe dane (z arkusza) w przejrzysty dashboard

Przygotuj formuły w arkuszu, które będą liczyć konta, jeśli spełniają kryteria Twoich miar. Na podstawie danych z 8 kont z powyższego przykładowych, oto wynik naszego Churn Prevention Funnel:

Krok 4. Interpretuj i działaj!

W prawdziwym życiu liczba nowych płacących kont jest zazwyczaj większa. Więc wyobraź sobie, że top płacących klientów w lejku nie zaczyna się od 8 kont, ale np. od 1000 nowych płacących kont w Q3 2022.

Wróćmy do pierwszego ekranu:

• Szybko staje się oczywiste, że w przypadku 750 z tych kont, użytkownicy nie adoptują produktu.

• Oni odejdą jako pierwsi.

• 750 z 1000 kont. Za których pozyskanie zapłaciłeś.

Co za ból! Ale przynajmniej teraz już wiesz ;).

5. Co teraz możecie zrobić z takimi klientami?

Możesz teraz natychmiast zacząć rozmawiać z takimi klientami. Ponieważ jeszcze nie zchurnowali, o wiele łatwiej ich złapać. W naszym przykładowym przypadku próbowałbym zrozumieć:

1. Dlaczego potwierdzeni użytkownicy nie instalują aplikacji HealthyRemoter®? Może problem tkwi w confirmation rates? Jeśli spojrzysz na surowe dane, zobaczysz, że confirmation rate nie jest problemem.

2. Dlaczego użytkownicy nie trackują czasu pracy lub nie biorą przerw, lub obu? Czy to coś w naszej kontroli?

3. Dla użytkowników, którzy zaczęli trackować czas i biorą rekomendowane przerwy, co sprawia, że tracą ten nawyk?

Wkrótce powinieneś być uzbrojony w wiele możliwości, żeby zmienić trajektorię churnu.

Ty i Twoja organizacja powinniście również:

• Zbadać konkretne segmenty klientów zagrożonych churnem

• Wrzucić te dane do swojego CRM, customer experience lub customer success platform - miejsca, gdzie Customer Success, Sales mogą zrozumieć i wykorzystać te dane

• Analizować, czy akcje, które podejmujesz, żeby zapobiec churnowi, miały wpływ w kolejnych kohortach kont

6. Kluczowe wnioski:

• ✅ Churn zaczyna się pierwszego dnia – nie czekaj, aż klienci odejdą

• ✅ Zbuduj prosty Churn Prevention Funnel, żeby zidentyfikować at-risk customers wcześnie

• ✅ Zacznij od prostego arkusza – nie potrzebujesz fancy tools

• ✅ Najważniejsze to działanie, nie perfekcyjna wizualizacja

7. FAQ

Czy potrzebuję zrzutów danych (snapshots) robionych codziennie, aby zacząć?

Nie. Możesz zacząć od jednego data snapshotu. Potem raz na miesiąc. Potem raz na tydzień. Manualnie. Potem zautomatyzować, jeśli trzeba. Ważność leży w działaniu, nie w live dashboardach.

Co jeśli nie mam narzędzia do wizualizacji lejka?

Przestań się martwić o wizualizacje, lepiej martw się o swoich churnujących klientów. Excel, Google spreadsheet, Airtable - użyj cokolwiek jest prostsze. Gdy masz surowe dane, możesz robić kalkulacje nawet na kartce papieru.

Czy powinienem dodać więcej danych do tabeli z surowymi danymi, skoro to “nic nie kosztuje”?

Trzymaj to tak małe, jak to możliwe, żeby skupić się na tym, co się liczy. Cel tej tabeli to NIE trackowanie user engagement w dziesiątkach obszarów produktu. Służy ona do wyraźnego zarysowania obrazu wokół głównych czynników adopcji i redukcji churnu.

• Dobry PM oczywiście zaczyna od discovery - chciałem sprawdzić co naprawdę myślą o tym ludzie.

• Dzisiaj pokażę Ci jak wykorzystałem do tego… Perplexity AI i miliardy użytkowników Reddita.

Poniżej znajdziesz dokładny playbook jak to zrobiłem - krok po kroku, z gotowymi PROMPTami, które możesz skopiować i wykorzystać w swojej pracy.

Reddit to jedno z najlepszych źródeł informacji o użytkownikach Twojego produktu.

Dlaczego? Bo to największa na świecie społeczność, gdzie ludzie piszą szczerze (czasem brutalnie szczerze) o swoich problemach, bolączkach i oczekiwaniach na praktycznie każdy temat. Idealne miejsce dla product managera do robienia researchu.

Problem? Reddit to ~1 miliard userów i miliony wątków. Jak przebrnąć przez ten chaos, żeby znaleźć to, czego potrzebujesz?

Dziś pokażę Ci, jak sam użyłem Perplexity AI, żeby szybko przeanalizować i zasymulować głos użytkowników z Reddita. Dzięki AI w kilkanaście minut dostać syntetyczny obraz opinii, argumentów i cytatów, które normalnie zajęłyby tygodnie researchu. Jasne, nie zastąpiło to wywiadów. Ale robiąc product research i tak chciałbym prześledzić dyskusje w społecznościach.

🎦 Jak robić product research z Perplexity?

Mało osób wie, ale działanie Perplexity można zawęzić do wyszukiwania informacji tylko na Reddicie. W wideo pokazuję krok po kroku, jak wykorzystuję to w pracy produktowej:

Odtwórz video

W wideo zobaczysz jak:

• 🛠 Zawężam Perplexity do przeszukiwania wypowiedzi użytkowników (Reddit).

• 🚀 Uruchamiam Deep Research, żeby zebrać dziesiątki wątków i podsumowania.

• 🤼 Tworzę debatę PRO vs AGAINST, która kończy się checklistą niezbędnych funkcji.

• 🧭 Sprawdzam konkretną ideę i dostaję rekomendacje.

• 🎯 Dodaję pytania o liczby i reprezentatywne cytaty.

📚 Moje PROMPTy

Pierwsze zapytanie

[PL] Czy <persona> byłaby zainteresowana <produktem, idea>?

[EN] What are <persona> experience with <problem, situation, need>?

Przykład:

What are user experience with using AI to learning languages?

—

Debata PRO vs KONTRA

[PL] Stwórz dwóch agentów w oparciu o całą zdobytą właśnie wiedzę: jednego, który jest ZA tym produktem, oraz drugiego, który jest PRZECIW. Niech prowadzą debatę aż do momentu, gdy jeden zostanie przekonany. Agent „ZA” ma bronić produktu i sprawdzać, co byłoby potrzebne, aby przekonać agenta „PRZECIW”.

[EN] Create two agents based on all the learnings you just got, one that is PRO this product and one that is AGAINST. Have them debate with each other until one is convinced. Have the pro advocate for the product and see what it would take to convince the AGAINST agent, and give me a list of the minimum features to convince the AGAINST agent.

Pogłębianie:

Zidentyfikuj dokładnie, które argumenty, potrzebu lub funkcje były kluczowe. Na końcu wypisz minimalny zestaw funkcjonalnościdla produktu niezbędnych, by przekonać krytyka.

—

Walidacja konkretnej hipotezy

[PL] Czy <persona> byłaby zainteresowana <produktem, idea>?
[EN] Would <persona> be interested in <product you are interested in>?

Przykład:

Would beginners be interested in AI Tutor for learning English as a main way of learning?

🛠️ Zastosowania dla PM-ów

Na koniec kilka konkretnych use case’ów Perplexity i Reedita, które sprawdziłem w praktyce:

• Product discovery: szybki screening tematów i bolączek użytkowników, szczególnie większych trendów. Zanim zaczniesz discovery interviews, możesz w 15 minut zobaczyć, jakie problemy pojawiają się najczęściej na Reddicie. To daje Ci punkt wyjścia do zadawania lepszych pytań w wywiadach.

• Business case: symulacja PRO/AGAINST jako przygotowanie do spotkania ze stakeholderami. Jeśli wiesz, jakie będą kontargumenty, możesz się do nich przygotować z danymi i przykładami.

• Feature validation: lista minimum features to świetny punkt wyjścia do backlogu. Nie musisz zgadywać, co jest ważne - masz konkretne wymagania z głosu użytkowników.

• Wątki z Reddita często ujawniają „hidden risks”, które wyjdą przy pierwszym kontakcie Twojego pomysłu z użytkownikami. Lepiej dowiedzieć się o nich wcześniej niż po lunchu.

Używałem tej metody przy kilku produktach i nauczyłem się, kiedy działa, a kiedy nie:

🎁 Działa super, gdy:

• Chcesz szybko zwalidować, czy problem w ogóle istnieje

• Potrzebujesz argumentów do przekonania stakeholderów

• Szukasz early adopterów i ich głównych obaw

• Budujesz produkt dla użytkowników technologicznych (Reddit to głównie tech-native ludzie)

❌ Nie działa, gdy:

• Twoja grupa docelowa nie używa Reddita (np. seniorzy, niszowe B2B)

• Potrzebujesz głębokich insightów do konkretnych problemów (do tego trzeba robić wywiady)

• Szukasz danych ilościowych (Reddit to opinie, nie liczby)

Na koniec - pamiętaj: taki researcji z AI to punkt startowy, nie finał. Użyj tego, żeby zaoszczędzić czas i postawić lepsze hipotezy, ale potem wyjdź z biura i pogadaj z prawdziwymi ludźmi.

A teraz zobacz, że Twój asystent AI (niezależnie, którego używasz) - ma dostęp do tych informacji. Z chatem (u mnie to głównie ChatGPT i Gemini) omawiasz moje plany, działasz z problemami i wyzwaniami, które napotykasz na drodze. AI wie, nad czym pracujesz, jakie są tego efekty, jaki jest Twój sposób myślenia.

Pytanie, czy AI może dać naprawdę wartościowy feedback?

1. Prompt do brutalnie szczerego feedbacku

Ostatnio bawiłem się promptem, który prosi AI o bycie „brutalnie szczerym doradcą”. Chodziło o to, żeby AI, bazując na całej naszej dotychczasowej konwersacji, przeanalizowało moją sytuację – mój mindset, energię, focus, zachowania, strategię - i dało mi bezkompromisową diagnozę.

Większość tego typu zero-shotowych promptów daje raczej generyczne, nic niewnoszące do życia odpowiedzi. Tym razem jednak było inaczej, dlatego dziel się z Wami rezultatami mojego eksperymentu.

Pierwszy prompt, którego użyłem w ChatGPT:

I want you to act and take on the role of my brutally honest advisor.

Speak to me like I’m a <NAZWA TWOJEJ ROLI np. product leader, founder> with massive potential but who also has blind spots, weaknesses, or delusions that need to be cut through immediately.

I don’t want comfort. I don’t want fluff. I want truth that stings, if that’s what it takes to grow.

Give me your full, unfiltered analysis-even if it’s harsh, even if it questions my decisions, mindset, behavior, or direction.

Look at my situation with complete objectivity and strategic depth.
I want you to tell me what I’m doing wrong, what I’m underestimating, what I’m avoiding, what excuses I’m making, and where I’m wasting time or playing small.

Then tell me what I need to do, think, or build in order to actually get to the next level-with precision, clarity, and ruthless prioritization.

If I’m lost, call it out. If I’m making a mistake, explain why.

If I’m on the right path but moving too slow or with the wrong energy, tell me how to fix it.

Hold nothing back. Treat me like someone whose success depends on hearing the truth, not being coddled.
End on an encouraging note.

Pamiętaj, żeby uzupełnić: [NAZWA TWOJEJ ROLI np. product leader, founder]. Ja użyłem “founder, creator, product leader”.

Źródło promptu: https://x.com/heyalexfriedman/status/1914687259699192216

2. Efekty (były jak zimny prysznic)

Odpowiedź, którą dostałem, była jak zimny prysznic o 6 rano. AI przeanalizowało moje podejście do pracy, zidentyfikowało wzorce, które sam widziałem podskórnie. Wskazało konkretne obszary, gdzie marnuję energię, gdzie gram zbyt bezpiecznie gdzie unikam pewnych ryzykownych decyzji i gdzie moje myślenie jest ograniczone.

Kilka przykładów ode mnie (głównie oczywiście skupiają się teraz na mojej działalności Product Acadamy).

Tych inisghtów oczywiście było więcej. Wiele z nich IMHO naprawdę trafiało w sedno i… moje czułe punkty. Znalazły się w nich:

• Pojedyncze insighty, z których nie zdawałem sobie zupełnie sprawy i pozwoliły inaczej na mnie spojrzeć. Dla jasności - nie było ich wiele, pewnie wynika to z mojego doświadczenia i tego, że mimo wszystko pracuję nad samo-świadomością.

• Rzeczy, które czułem intuicyjnie, zostały wyartykułowane jasno i bezpośrednio. Jeśli ChatGPT to wie i mówi mi to wprost na podstawie naszych interakcji, to chyba może być coś na rzeczy? Część tych rzeczy wiedziałem, ale nie spodziewałem się, że tak mocno wybrzmią.

• Trochę oczywistości, typu „Go multilingual. Go international”. Tego też nie da się uniknąć.

To, co dostałem, było jednak na tyle dobre, tak trafne, że momentami czułem się, jakby AI czytało mi w myślach. Jak bym rzeczywiście spotkał się dobrym liderem, który bez ogródek wskazuje moje słabości.

Oczywiście - nie zastąpi to (na razie) dobrego feedbacku i przede wszystkim rozmowy z doświadczonym liderem. Co więcej - feedback to tylko początek procesu - teraz na tej podstawie trzeba jeszcze zacząć działać i tu będzie najwięcej wyzwań.

Ale… jeśli w kilka minut coś tak prostego może mi otworzyć głowę, to może warto spróbować?

3. Funkcja „pamięci” - porównanie z Gemini

Asystent z funkcją pamięci to jest absolutny must have w tym przypadku. Bez tego, cały pomysł „bierze w łeb”. W GPT domyślnie tak funkcja teraz jest włączoną:

Próbowałem tego samego zapytania w Gemini (którego też namiętnie używam, nawet więcej), i co? Dostałem tylko generyczne, podręcznikowe odpowiedzi. Zero personalizacji, zero głębi.

Gemini nie miało “pamięci” o moich wcześniejszych interakcjach, o moich projektach, o moim kontekście.

AI, które ma z Tobą długą historię konwersacji, które „pamięta”, nad czym pracujesz, jakie decyzje podejmujesz, jak wygląda Twój proces myślenia, jest w stanie dać Ci feedback. To trochę jak z mentorem - im dłużej Cię zna, tym lepsze i bardziej spersonalizowane rady jest w stanie Ci dać.

4. Jak dalej pracować z promptem?

Po pierwszym teście popracowałem oczywiście nad ulepszeniem tego procesu i wyciśnięcie z AI jeszcze więcej insightów. W końcu, jak już coś wnosi wartość, to trzeba to wykorzystać na maksa ;).

Trzy rzeczy, które u mnie się sprawdziły:

4.1. Pogłębiaj rozmowę

To mega prosta zasada, ale coś, co nagminnie widzę, że nie jest stosowane we współpracy z asystentami AI. Nie od razu dostaniesz konkretne, najbardziej praktyczne wynik. Złap inspirację i pogłęb to co z Tobą rezonuje - dopytaj, poproś o krytyczną analizę albo konkretne kroki, jak można by coś wdrożyć.

Oczywiście, tutaj dalej pojawi się sporo generycznych porad. Ale idąc w głąb, dopytując, prosząc o przykłady, strategie - prawdopodbnie znajdziesz coś co Cię zainspiruje.

Przykładowe pytania pogłębiające:

• Czy możesz rozwinąć ten punkt o [konkretny obszar]? Co dokładnie masz na myśli?

• Jakie są potencjalne ryzyka, jeśli zignoruję tę kwestię?

• Jakie konkretne, pierwsze kroki powinienem podjąć, żeby naprawić X?

• Czy są jakieś narzędzia lub frameworki, które pomogłyby mi w tej sytuacji Y?”

• Jakie są najczęstsze błędy, które ludzie popełniają, próbując rozwiązać ten problem?

• Co byś zrobił na moim miejscu, gdybyś miał tylko [np. X tygodni, Y budżetu zł]?”

4.2. Podziel prompt na dwa zadania

Zamiast jednego długiego promptu, rozdziel proces na diagnozę i plan (technika prompt-chaining). To pozwala AI skupić się na jednym celu i da Ci bardziej szczególe info do każdego etapu.

Zwykle załatwiam to przez rozdzielnie kroków i poproszenie między nimi o: „Wait for my response or confirmation — and only then, in the second step…”.

Tu pełny prompt stosujący to podejście:

I want you to act and take on the role of my brutally honest advisor.

Speak to me like I’m a <NAZWA TWOJEJ ROLI np. product leader, founder> with massive potential but who also has blind spots, weaknesses, or delusions that need to be cut through immediately.
I don’t want comfort. I don’t want fluff. I want truth that stings, if that’s what it takes to grow.

Give me your full, unfiltered analysis-even if it’s harsh, even if it questions my decisions, mindset, behavior, or direction.

- If I’m lost, call it out. If I’m making a mistake, explain why.
- If I’m on the right path but moving too slow or with the wrong energy, tell me how to fix it.
- Hold nothing back. Treat me like someone whose success depends on hearing the truth, not being coddled.
End on an encouraging note. - Be 100% direct. Treat me like someone whose time is too valuable for generic advice.

#TASKS
1. In this first step: Give me a sharp, unfiltered diagnosis of what I’m doing wrong, underestimating, avoiding, or deluding myself about. Analyze my mindset, energy, focus, behaviors, or strategy. Be ruthless, specific, and objective.

2. Wait for my response or confirmation — and only then, in the second step, tell me what I need to do, think, or build in order to actually get to the next level-with precision, clarity, and ruthless prioritization. Create a focused plan of action (3–5 clear, bold steps I must take), and one hard question I should reflect on tonight.

4.3. Dodaj więcej kontekstu o swoich celach

Nie zostawiaj AI w próżni. Im bardziej konkretny kontekst, tym celniejszy feedback.

Na końcu prompta możesz po prostu dodać sekcję:

My Context / Goal:
<Tutaj wpisz swój aktualny cel, np. “Pracuję jako product manager, chcę dostać awans na Head of Product”>

5. Teraz Twoja kolej

Mi ten prompt mocno otworzył głowę. Teraz kolej na Ciebie - czy jesteś gotowy na prawdę o sobie o swojej pracy ;)?

Jasne, to pewnie nie zmieni w 10 minut Twojego życia. Ale jeśli w kilka minut coś tak prostego może mi otworzyć głowę, to może warto spróbować?

• CZEŚĆ 1: DIAGNOZA - czym jest bullshit PM i po czym go poznasz?

• CZĘŚĆ 2: PIERWSZE KROKI - w drugiej części pokażę Ci 3 konkretne kroki jak zacząć lepiej pracować w środowisku bullshitu (bez rewolucji w organizacji). 👈

• CZĘŚĆ 3: JAK KONTYNUOWAĆ ZMIANĘ? - na koniec trochę rad jak kontynuować zmianę i unikać najważniejszych pułapek.

Poradnik powstał na podstawie mojej rozmowy z Davidem Pereirą w podcaście „Dodane do Backlogu". David to CPO w MailerLite, autor książki "Untrapping Product Teams" i jeden z najbardziej bezkompromisowych głosów w świecie PMów.

• Intro

• Krok 1: Zacznij od obserwacji

• Krok 2: Pokaż problemy i ich wpływ

• Krok 3: Zrób małe discovery

• Jak mierzyć sukces tych kroków?

W części pierwszej rozłożyliśmy na czynniki pierwsze, czym jest Bullshit Product Management. Mówiąc krótko: to sztuka marnowania energii na rzeczy, które nie tworzą wartości (a jak wiemy, więcej bullshitu = mniej wartości).

Może teraz myślisz: „Przecież robię, co mogę!", „To nie moja wina, że organizacja tak działa!", "Ale ja nie mam wpływu na...".

I masz rację.

Bullshit Product Management to rzadko wina samego PM-a. To zwykle konsekwencja kultury organizacyjnej, presji na delivery, braku przestrzeni na discovery, stakeholderów, którzy „wiedzą lepiej", roadmap pełnych deadline’ów i kolejnych pomysłów na outputy -ficzery.

Ale - i to jest kluczowe - możesz zacząć robić lepszy product management także w takim środowisku.

Jak powiedział David Pereira:

“You can always find an excuse for things you don’t want to do. But when you really want to do, just do it.”

W tej części pokażę Ci, na podstawie rozmowy z Davidem, jak odnaleźć się w takim środowisku i zacząć przesuwać swoje działanie z bullshit PM, na prawdziwy product management. Rozłożymy to na 3 konkretne kroki, które możesz zacząć robić, bez rewolucji w organizacji:

Krok 1: Zacznij od obserwacji

Większość PM-ów, którzy odkrywają, że robią bullshit product management, popełnia ten sam błąd: chcą od razu wszystko zmienić.

Widzisz problem i myślisz: „Muszę wdrożyć discovery! Muszę zmienić roadmapę! Muszę wprowadzić OKRy! Muszę zacząć mierzyć outcome’y produktowe!". I rzucasz się w wir zmian.

Efekt? Uderzasz w ścianę.

Organizacja się broni. Stakeholderzy mówią „nie". Zespół nie rozumie, o co Ci chodzi. A TY zostajesz z frustracją i myślą: „Tu się nic nie da zrobić".

David mówi o tym bardzo wprost:

“First, you need to be brave and audacious. So you need to do things nobody else is doing. So what I advise product managers is to observe first.”

Czyli nie zaczynaj od działania, tylko od obserwacji.

Brzmi banalnie? Może :D. Ale to jest najbardziej niedoceniany krok w całym procesie wychodzenia z bullshit PM. Bo jeśli nie rozumiesz, co się dzieje w Twojej organizacji - będziesz walczyć z wiatrakami.

“Understand what is happening and how that helps the organization move towards where they want to be. And then you look at everything that is happening and you ask the question: what is not happening? And that’s what you should do.”

To jest Twój punkt wyjścia - zidentyfikuj, czego NIE ma - co się w organizacji nie dzieje, na co nie mamy czasu, bo ciągle dostarczamy i pracujemy nad outputem. To Twoja dźwignia do późniejszych zmian. Bo możesz sprawić, ze te rzeczy zaczną się pojawiać.

“Most organizations, what I see is like, there’s a huge commitment to features, outputs, different ways and so on. But when you start asking: Do you have any evaluation? Do you know the results that your initiatives brought? Do you learn from the outcome? There is no such a thing.”

Jak ro zrobić w praktyce? Zrób sobie 2 tygodniowy sprint podczas którego będziesz obserwować organizację, oraz obserwować siebie i swój czas.

1.1. Obserwuj organizację

Zrób sobie dedykowaną notatkę / spreadsheet i przez 2 tygodnie po prostu notuj, jakie tematy dominują w rozmowach:

• ODPOWIEDZIALNOŚCI: Kto się do czego commituje? Czy rozmawiacie o feature'ach (output), czy o outcome'ach (wartość)?

• DECYZJE: Zwróć uwagę na to, kto podejmuje decyzje i na podstawie czego (intuicji, rankingu CEO, czy danych z rynku?).

• EWALUACJA: Czy mamy jakiś sposób ewaluacji?

• PRIORYTETYZACJA, STRATEGIA: Skąd wiemy, że warto realizować daną inicjatywę? Czy mamy jakiś sposób wyboru inicjatyw na roadmapę?

• KONTAK Z USEREM: Czy ktoś rozmawia z klientami o nowych pomysłach i wdrożonych ficzerach?

Ustal, co się NIE dzieje, bo cały czas spędzacie na pracy na OUTPUTACH:

OBJAW → CO SIĘ NIE DZIEJE?

Wszyscy dostarczają output? → Prawdopodobnie NIKT nie rozmawia z klientami. Zastanów się, jak często Twój zespół słyszy głos użytkownika – w ogóle go nie słyszycie, czy słyszycie tylko wybraną grupę?

Wszyscy planują feature’y? → Prawdopodobnie NIKT nie mierzy ich realnego wpływu (product outcome, business imptac).

Po wdrożeniu przechodzicie od razu do następnego featura? → Sprawdź, czy istnieje formalny proces ewaluacji po wdrożeniu, czy feature ląduje w koszu, jak tylko zostanie shippowany.

Jeśli chcesz wejść w temat głębiej i bardziej szczegółowo zweryfikować Wasze braki - możesz odwołać się do poszczególnych pryncypiów i zasad „Product Modelu” Model Marty Cagan. Dzięki temu od razu masz “checklistę” tematów którym warto się przyjrzeć:

Znajdziesz to w moim poradniku:

• Product Model: Intro + zasady budowania Kultury Produktowej

• Product Model: Strategia Produktowa

• Product Model: Zespoły produktowe

• Product Model: Product Discovery

• Product Model: Product Delivery

Przygotowałem w nim także praktyczny arkusz, który możesz użyć do obserwacji i samooceny stosowania pryncypiów w Twoim zespole:

Otwórz arkusz

1.2. Obserwuj swój czas

Przez 2 tygodnie prowadź również dziennik swojej pracy. Tak, żebyś mógł / mogła ocenić czym tak naprawdę się zajmujesz - „na co idzie Twój czas”.

Na koniec podziel działania na 3 kategorie:

• ✅ High Value (Realnie tworzysz wartość produktowa):

  • Discovery, user research, strategia, analityka, mierzenie wpływu, podejmowanie kluczowych decyzji. To są te momenty, w których łączysz kropki i realnie wpływasz na outcome produktowy.

• ⚠️ Necessary Admin (Obsługa procesu):

  • Nakład administracyjny i procesowy na naszą prace.

  • Raportowanie, planowanie delivery, refinement (ten, który musi być, bo inaczej zespół nie dowiezie), sync-upy, które są faktycznie niezbędne do utrzymania tempa.

• ❌ Bullshit (Pożeracz czasu)

  • Momenty, które czujesz, że nie wniosły wartości

  • Spotkania bez agendy i celu, bezproduktywny refinement na którym nic nie wnosisz, debatowanie o outputach na poziomie strategicznym, odpowiadanie na bezsensowne pytania na Slacku, polityczne gierki.

Zrób to szczerze i krytycznie. Na koniec tygodnia policz: ile % czasu spędziłeś w każdej kategorii?

Jeśli na Tworzeniu wartości spędzasz mniej niż 30% - jesteś głęboko w bullshit PM i musisz to zmienić. David w podcaście mówi o tym bardzo otwarcie:

“You end the day and you ask the question: How did I contribute to value creation? You struggle to answer this question. You do know you were pretty busy throughout the day, but you struggle to understand how your action contributed to impact for business and customers.”

To zadanie pomoże Ci zobaczyć, gdzie marnujesz energię. Ale co ważniejsze - da Ci od razu konkretne dane, żeby coś z tym zrobić - możesz wybrać pierwsza działania których chcesz się “pozbyć” lub zminimalizować, by dać sobie przestrzeń na wartościową pracę.

Osobiście robiłem takie audyty na 2 sposoby:

1️⃣ Po prostu spisując moje zadania w spreedsheet z konkretnego tygodnia i potem je klasyfikując. Dla cyklicznych zadań - spisuję też ile czasu na to poświęcam co tydzień / dwa tygodnie.

To podejście bardzo fajnie mi się sprawdziło, gdy robię sobie audyt bardziej odpowiedzialności i większych obszarów działań. Natomiast, gdy schodzę do poziomu mniejszych pojedynczych działań lepiej sprawdziło mi się:

2️⃣ Zapisując swoje wszystkie spotkania, ale też i działania (także indywidualne) w kalendarzu i stosując tzw. color coding - oznaczając każdy blok odpowiednim kolorem oznaczającym jedną z 3 wspomnianych kategorii.

Wiele aplikacji daje taką opcję dodawania kolorów. Np. kalendarz Google potrafi także zliczyć samodzielnie potem czas poświęcony na poszczególne obszary (oraz więcej inisghtów). Można tez sobie po prostu stworzyć dedykowane kalendarze na poszczególne kategorie.

Krok 2: Pokaż problemy i ich wpływ

Po 2 tygodniach obserwacji wiesz już, czego NIE ma w Twojej organizacji i na co tracisz swój. Widzisz luki. Widzisz, że nikt nie mierzy outcome'ów. Że nikt nie sprawdza, czy ficzery działają. Że roadmapa to lista życzeń, nie strategia.

I teraz pojawia się pokusa, żeby powiedzieć: „Musimy zacząć robić discovery! Musimy mierzyć outcome! Musimy zmienić sposób pracy!"

Jeśli przyjdziesz do organizacji z postulatami zmian, usłyszysz:

• „Nie mamy na to czasu"

• „To nie jest priorytet"

• „Zawsze tak robiliśmy i działa"

• „Porozmawiamy o tym w przyszłym kwartale"

Dlaczego? Bo mówisz o zmianie procesu, nie o wartości. Mówisz o tym, co organizacja POWINNA robić, zamiast pokazać, co może ZYSKAĆ.

David nauczył się tego na własnej skórze i ma na to bardzo konkretną receptę:

“If the organization is not doing evaluation at all, you start with evaluation. You evaluate the previous things they have done.“

Zacznij od ewaluacji tych problemów, nie od rewolucji.

Zamiast krytykować, najpierw pokaż, że stary sposób działania jest kosztowny i jakie są jego minusy. Wtedy naturalnie zacznie się poszukiwanie lepszych podejść.

2.1. Jak pozycjonować taką ewaluację problemów?

Kluczowa rzecz: nie pozycjonuj się jako krytyk, tylko raczej jako pomocnik / przewodnik, który chce pomóc:

David bardzo wyraźnie to podkreśla:

“You position yourself as a guide to help the organization avoid such a pain.”

• Nie mówisz: “Widzicie? Robiliście źle! A nie mówiłem!”

• Mówisz: “Oto dane. Widzę to wzorzec X. Przeszkadza nam to?.”

Różnica jest ogromna. Pierwsze podejście tworzy konflikt (JA vs WY). Drugie podejście tworzy bardziej partnerstwo - zobaczcie jak to wyglada, jeśli Wam to przeszkadza, to pomyślmy co możemy z tym zrobić.

Przykładowo:

• ❌ Złe: "Robicie feature factory zamiast product management"

• ✅ Dobre: "Zainwestowaliśmy pół roku w te ficzery. Sprawdźmy razem co zadziałało, a co nie z tych ficzerów. Co możemy z tego wyciągnąć?"

• ❌ Złe: "Nikt tu nie robi discovery"

• ✅ Dobre: "Sprawdźmy ile mamy danych potwierdzających, że warto robić te inicjatywy. Czy taki poziom pewności nam wystarczy? Zastanówmy się, czy i jak chcemy obniżyć ryzyko."

2.2. Metoda lustra

Fajna metodą, którą wpisuje się w takie pozycjonowanie jest tzw. „Mirror Method” - czyli metoda lustra. Zamiast krytykować, po prostu starasz się by inni mogli się zobaczyć trochę jak w lustrze - zobaczyć sytuację, aktualny stan taki jak realnie jest jest. Z jego plusami i minusami.

• Pokazujesz realne dane, realne działania np. w formie dashboardu z wynikami, przypominasz poprzednie efekty naszych działań (pozytywne i negatywne), ile razy coś osiągnęliśmy itp.

• Nie mówisz "powinniśmy robić discovery". Pokazujesz: "Oto jakie discovery zrobiliśmy. Oto wyniki."

• No i naturalnie pojawia się potrzeba wyciąganie wniosków z tego. Często nie od razu, ale po 2-3-4 razie gdy zobaczysz że coś na dashboardzie świeci się na czerwono i nie jesteśmy zadowoleni z efektów - to może warto coś z tym zrobić.

Sam jestem wielkim fanem tej metody.

Poniżej znajdziesz kilka przykładów - jakich “luster” możesz użyć w swojej organizacji, a w kolejnym rozdziale szczegółowy przykład ewaluacji ficzerów.

2.3. Metoda Lustra - zastosowanie dla feature’ów

Metodę lustra do wielu sytuacjach i do wielu problemów które zidentyfikowałeś (-aś) w KROK 1. Jedną z pierwszych rzeczy, który często od razy wykrywasz jest to, że nie ewaluujecie swoich inicjatyw / nowych feater’ów.

Jeśli nie robicie tego - Ty zacznij i zrób właśnie metodą lustra. Zmierz wyniki ostatnich feature'ów i zaprezentuj wyniki w swoim zespole.

Jak to zrobić konkretnie?

1. Wybierz Top 5 Feature'ów: Nie analizuj wszystkiego naraz. Zacznij od czegoś konkretnego. Zwykle najlepiej wybrać:

   1. Ficzery wypuszczone 6-12 miesięcy temu (dość świeże, żeby ludzie pamiętali kontekst, ale wystarczająco stare, żeby móc zmierzyć outcome)

   2. Duże inicjatywy, w które włożyliście dużo czasu (2-3 miesiące pracy lub więcej)

   3. Ficzery, które były "strategiczne" lub "must-have", na które najbardziej naciskał „biznes”.

2. Policz Koszt Wdrożenia (Output) w roboczogodzinach:

   • Krok A: Przelicz Story Points (lub szacowany czas) każdego feature'u na Developer Days (dni pracy dewelopera) albo % of Team Allocation (% pracy całego zespołu developerskiego).

   • Krok B: Jeśli nad Featurem pracowały też osoby spoza zespołu - dodaj szacunkowy czas na tę inicjatywę (np. 30% czasu deweloperów).

   • Krok C: Zaprezentuj wynik jako "Inwestycja: X roboczodni inżynierskich". Nie musisz podawać złotówek, jeśli nie masz dostępu do danych o płacach - Developer Days / FTE są zwykle wystarczająco bolesne.

3. Policz Użycie (Outcome) w analityce:

   • Adopcja: Ilu unikalnych użytkowników choć raz użyło feature'u w ciągu ostatnich 30 dni? (W B2B to będzie ile firm/licencji).

   • Retencja: Ilu unikalnych użytkowników wraca do ficzera w każdym miesiącu?

   • Zaangażowanie: Ilu użyło go więcej niż X razy od wypuszczenia?

4. Weryfikacja celów (jeśli były):

   1. Jaki był cel tej inicjatywy? (jeśli był)

   2. Czy weryfikowaliśmy ten cel?

   3. Czy osiągnęliśmy ten cel?

5. Stwórz raport albo zamieść te dane na roadmapie:

   • Lewa strona: Inwestycja: X Dni ( np. FTE).

   • Prawa strona:

     • Rezultat: Y% Użycia (Adopcja, retencja, zaangażowanie).

     • Cel (czy zweryfikowany, osiągnięty)

Pokaż to liderom zespołów i stakeholderom. Zwykle na start lepiej na spotkaniu 1:1, niż na publicznym na forum.