Tego nie było w moim bingo na 2026 rok → NAGRALIŚMY PODCAST z Ravi Mehta (Tinder, Facebook, Reforge) oraz Michelle Parsons (Spotify, Netflix i Hinge) 🤯

Zapraszam się na kolejny mocny odcinek specjalny 🇬🇧 podcastu „Dodane do Backlogu” (nagrany wspólnie z Productlab Conf). Nasi goście opowiedzieli insiderskie f*ck-upy z ich pracy przy globalnych produktach. Tak, im też zdarzają się błędy ;).

Zaczynamy 👇

Słuchaj na Spotify

lub Apple Podcast.

• 1️⃣ TripAdvisor - redesign, który kosztował miliony (Ravi Mehta)

• 2️⃣ TripAdvisor - kiedy lepszy algorytm to za mało (Ravi Mehta)

• 3️⃣ Netflix - jak presja Disney+ prowadziła do “solutioningu” (Michelle Parsons)

• 4️⃣ BaseCRM - rok pracy nad feature’em, którego nikt nie policzył (Jakub Tutaj)

• 5️⃣ Hinge - feature, który userzy nauczyli się hackować (Michelle Parson)

• Gamifikacja, która zamieniła apkę randkową w narzędzie dla influencerów

• Lightning round z naszymi gośćmi: “Nigdy więcej nie zrobię...”

Jeśli wolisz czytać → poniżej znajdziesz też CASE STUDIES najważniejszych F*CK UPów z tej rozmowy ⤵️

1️⃣ TripAdvisor - redesign, który kosztował miliony (Ravi Mehta)

TripAdvisor w 2013 roku miał 300 milionów użytkowników miesięcznie i wyglądał jak strona z 2001 roku. Bo... był stroną z 2001 roku. Checkboxy, radio buttony, zero designu.

Ravi i jego zespół zdecydowali się na coś, co jest antytezą tego, jak zwykle pracował TripAdvisor - firma, która testowała A/B praktycznie każdą zmianę (ponad tysiąc eksperymentów rocznie) poszła w “zamknij się w pokoju na 9-12 miesięcy, zrób idealny redesign, wypuść wszystko naraz z wielką kampanią marketingową”.

Efekt? Kilka tygodni po launchu revenue zaczęło spadać.

• Winowajcą okazał się nowy, super panel filtrów do wyszukiwania hoteli - “personalization bar”, który zastąpił stare, brzydkie, ale znajome checkboxy.

• Liczba osób filtrujących listę hoteli spadła o 20%. Rezerwacje spadły proporcjonalnie.

• Cały biznes stracił X% revenue 🫢

Musieli odtworzyć starą logikę filtrów - tylko w nowej oprawie wizualnej. Zajęło to kilka miesięcy i kosztowało miliony dolarów utraconego przychodu.

2️⃣ TripAdvisor - kiedy lepszy algorytm to za mało (Ravi Mehta)

Druga historia od Raviego, też z TripAdvisor.

Tym razem zespół pracował nad personalizacją rankingu hoteli - bo domyślne sortowanie “od najlepiej ocenianych” pokazywało głównie drogie hotele, które przeciętny użytkownik i tak nie zarezerwuje.

Brzmi jak sensowne strategiczne Opportunity. Podeszli do tego metodycznie:

1. Najpierw ukryty test na 5-20% ruchu - bez pokazywania userowi, że coś się zmieniło, po prostu inna kolejność hoteli w tle.

   1. Wynik: 10% wzrost revenue. Sygnał był jasny - idziemy z tym dalej.

2. Kolejny krok - pełny launch “Just for You” jako domyślnej opcji dla wszystkich, z widoczną komunikacją, że lista jest spersonalizowana.

   1. I tu niespodzianka: revenue spadło.

Co się stało? Odpowiedź znaleźli w feedbacku od użytkowników:

Ludzie nie chcieli, żeby TripAdvisor “wiedział, co jest dla nich najlepsze” - mieli wtedy poczucie FOMO, że ukrywa się przed nimi dobre opcje, które mogłyby pasować. Chcieli ZDECYDOWAĆ SAMI.

3️⃣ Netflix - jak presja konkurencji prowadzi do „solutioningu” (Michelle Parsons)

Michelle prowadziła w Netflixie dział Kids & Family - unikalny obszar z własnym contentem, własnym marketingiem i dwoma typami userów (opiekun i dziecko).

Rok przed premierą Disney+ zespół wiedział, że nadchodzi wojna o rynek streamingu dla dzieci, a Disney już wtedy zaczynał dominować tę kategorię.

• Zamiast zacząć od discovery - jakie realne problemy mają rodziny korzystające z Netflixa - zespół poszedł prosto w szukanie rozwiązań i skopiowania ich od kolnkrencjie.

• Pomysłem było zbudowanie “family profile”, który pozwoli oglądać razem treści z dziećmi i będzie odpowiedzią na na podobna funkcję Disney+. Zespół ruszył pełną parą i zbudował rozwiązanie.

• Problem pojawił się później - metryki produktowe nie potwierdzały, że to faktycznie kierunek, który rozwiązuje jakikolwiek realny problem użytkowników.

• Zamiast przyznać to na głos, Michelle - chcąca udowodnić swoją wartość w orgnizacji - próbowała zadowolić wszystkich i brnęła dalej w to rozwiąznie i szukała dowodów że ma to sens. W końcu Marketing, Zespół Contentowy, Biznesowy chciał tej funkcji i była ogromna presja żeby dowieźć.

4️⃣ BaseCRM - rok pracy nad feature'em, którego nikt nie policzył (Jakub Tutaj)

10 lat temu Kuba pracował jako PM w firmie budującej CRM, która obsługiwała raczej małe organizacji. Aby jeszcze szybciej poznać firma postanowiła ruszyć w górę rynku - w stronę managerów i VP sprzedaży, konkurując z większymi graczami.

Zespół od razy zakochał się w pomyśle:

• Założyli że większe firmy potrzebują więcej danych i lepsze raporty oparte na machine learningu (10 lat temu to był jeszcze świeży temat), z korelacjami konwersji i porównaniami parametrów na ścieżce od leada → do klienta.

• Przeszli od razu do budowania, miało to zając kilka miesięcy.

• Presja rosła - po 6-8 miesięcach w projekcie zespół produktowy czuł, że “nie idzie to wystarczająco szybko”, ale budował dalej, zamiast się zatrzymać.

• Pilotaż u jednego z większych klientów wyglądał dobrze, więc sygnał zdawał się potwierdzać kierunek. Finalnie budowanie tego zajęło niemal rok.

• Przełomowy moment nastąpił pod koniec pracy:

  • ktoś podczas strategicznego spotkania w końcu zadał wprost jedno pytanie: Ilu klientów w naszej obecnej bazie w ogóle pasuje do tego segmentu, żeby to się mogło zwrócić - i kiedy zobaczymy z tego ROI?

  • Odpowiedź brzmiała: prawie żadnych, i nie szybko. Projekt niemal zatopił firmę.

5️⃣ Hinge - feature, który userzy nauczyli się hackować (Michelle Parson)

Hinge to appka randkowa, która od lat pozycjonuje się inaczej niż konkurencja (np. Tinder). Hasło reklamowe Hinge brzmi wprost: „designed to be deleted: - appka, która ma Ci pomóc znaleźć relację, a nie utrzymać Cię w nieskończonym swipe'owaniu.

Na tym tle Hinge zbudował feature “Standouts” - codzienną sekcję z profilami osób spoza Twojej standardowej strefy rekomendacji, do których mogłeś wysłać płatną “różę” (ograniczoną liczbę miesięcznie, albo dokupioną).

Pomysł wydawał się sensowny:

• osoby spoza Twojego naturalnego dopasowania algorytmicznego mają statystycznie niższą szansę na wzajemny match

• dlatego traktujemy ich jako “premium opcję”, mnie oczywiste osoby, na które warto “wydać różę”

• Miało w teorii to służyć też całemu ekosystemowi, czyli sprawiać że poznajesz mniej oczywiste osobami (w końcu dostał_ś od tej osoby wyjątkową różę) - w przeciwieństwie do appek, w których za pieniądze pokazują Ci najbardziej “oczywiste i algorytmiczne” dopasowania, żeby tylko zwiększyć konwersję zakupu.

Problem w tym, że tej logiki praktycznie nie da się wytłumaczyć zwykłemu użytkownikowi w dwóch zdaniach onboardingu.

Ludzie, przyzwyczajeni do mechaniki Tindera, zaczęli odbierać Standouts jako celowe blokowanie dostępu do “atrakcyjnych” osób za opłatą - mimo że to nie była intencja zespołu. Feature wywołał realny, głośny bunt userów (także medialny), z którym Hinge jako organizacja mierzył się przez długi czas.

Do tego doszło coś, czego nikt nie przewidział:

• Użytkownicy zaczęli wierzyć (i rozpowszechniać to jako "hack" w social media), że jeśli X-ują (odrzucają) wszystkie osoby pokazane w danym dniu w sekcji Standouts, to Hinge pokaże im tych samych ludzi ponownie - tym razem w normalnych rekomendacjach.

• W rzeczywistości X pod danym profilem to jednoznaczny sygnał "nie jestem zainteresowany", niezależnie od tego, w jakiej sekcji appki go kliknąłeś.

• Efekt był odwrotny do zamierzonego: ludzie masowo odrzucali profile, którymi w Standouts akurat mogli być zainteresowani,

🎧 Posłuchaj pełnej rozmowy:

Jest tam dużo więcej niż to, co zmieściło się w tym wydaniu - między innymi:

• Jak przygotować się do meetingu z zarządem albo inwestorami, żeby nie wyjść z niego z niczym - konkretne rady Raviego

• WeRoad - historia gościa z publiczności, który zmienił model biznesowy i wszedł na 5 rynków jednocześnie. Spoiler: to się nie skończyło dobrze ;)

• “What got you here won’t get you there” - Michelle o tym, dlaczego umiejętności, które zrobiły z Ciebie dobrego PM-a, mogą zacząć Cię ograniczać, kiedy awansujesz na leadera

• Jak mówić “nie” bez wypalenia się - Michelle o transparentności wobec zespołu w kwestii priorytetów i o tym, dlaczego zgadzanie się na wszystko to prosta droga do burnoutu

• Lightning round - na koniec odcinka każdy z uczestników dokończył jedno zdanie: "Jako product leader, nigdy więcej...".

→ Posłuchaj odcinka

Słowo „MCP” słyszałeś już nieraz - w Cursorze, w Claude, na LinkedInie. Definicję pewnie znasz: standard, który łączy AI z narzędziami i danymi. Często pada porównanie, że to takie API dla AI. Ale jak to właściwie działa?

No to spróbujmy rozłożyć MCP na czynniki pierwsze:

• CZĘŚĆ 1: Jak MCP działa pod spodem i czym naprawdę różni się od zwykłego API. Na konkretnym przykładzie 👈

• CZĘŚĆ 2: Zastosowanie MCP w pracy produktowej - miejsca, w których to dla PM-a ma znaczenie.

Pierwsza część dzisiaj, kolejna za tydzień.

W dzisiejszym wydaniu:

1. Czym właściwie jest (serwer) MCP?

2. Jak serwer MCP wygląda w środka?

3. Co się dzieje krok po kroku?

4. Dlaczego nie skorzystać po prostu z API?

5. W drugiej części…

Subscribe now

1. Czym właściwie jest (serwer) MCP?

Zacznijmy od początku:

MCP to protokół, czyli umowa o tym, jak dwie strony mają ze sobą rozmawiać.

MCP to nie jest system/program. Nikt nie „instaluje MCP” - dokładnie tak samo, jak nikt nie instaluje HTTP. Instalujesz przeglądarkę i stawiasz stronę, a HTTP jest tylko protokołem - ustaleniem, w jakim formacie mają ze sobą gadać.

Z MCP jest identycznie - to protokół do komunikacji. Rzeczy, które realnie widzisz, gdy “używasz MCP” mają swoje osobne nazwy

• Host to aplikacja, w której siedzisz i która korzystać z serwera MCP (np. Cursor, ChatGPT, Twój produkt / agent). To ona rozmawia z modelem i faktycznie wykonuje wywołania. Tu też znajduje się zwykle model LLM (albo przynajmniej połączenie z jego chmurowym API)

• Serwer MCP to tłumacz postawiony przy konkretnym systemie - np. Jirze, PostHogu, czy Waszej bazie danych SQL. Mówi „oto co potrafię”, a potem zamienia prośby modelu na realne operacje w tym systemie..

• Klasyczne API / Dane systemu - realny dostęp do danych, czy akcji systemu.

W praktyce warstwowo wygląda to tak:

1.1. Zobaczmy to na konkretnym przykładzie

Jesteś PMem, wyobraź sobie sytuację, że chcesz sprawdzić, dlaczego użytkownicy narzekają na płatności w Twoim produkcie.

Dziś robisz to mniej więcej tak:

• Wchodzisz do Intercoma, filtrujesz zgłoszenia z ostatniego miesiąca i eksportujesz najciekawsze do analizy

• Potem Jira - sprawdzasz, czy ktoś już tego nie zgłaszał problemów, przeklejasz treści zadań.

• Na końcu wrzucasz to wszystko do Claude’a i prosisz o syntezę.

A teraz wyobraź sobie, że Wasz zespół stawia jeden skrypt - nazwijmy go „Product Insights” - który ma dostęp do Intercoma i do Jiry, i który potrafi się przedstawić Twojej aplikacji AI: „umiem przeszukać zgłoszenia klientów i umiem przeszukać backlog”.

To jest właśnie serwer MCP:

1.2. Serwer? Brzmi jak coś dużego

Kiedy PM słyszy „musimy wystawić serwer MCP”, w głowie zapala się czerwona lampka: infrastruktura, deployment, rozmowa z zespołem platformowym. Potrzebujemy na to kwartał ;).

Tymczasem serwer MCP to najczęściej jeden niewielki plik ze skryptem. Kilkadziesiąt linijek w Pythonie (albo TypeScripcie), uruchamiane lokalnie na Twoim laptopie, albo jako mała usługa w chmurze.

Co taki skrypt zawiera? Definicje tego, co serwer udostępnia modelowi. Protokół przewiduje trzy rodzaje rzeczy:

• Narzędzia (“tools”) - akcje, o których wywołaniu decyduje model. W „Product Insights” są dwie: szukaj_zgloszen_intercom i szukaj_zadan_jira. To model w trakcie rozmowy uznaje, że czas po którąś sięgnąć.

• Zasoby (resources) - dane, o których dołączeniu decyduje aplikacja, nie model. Plik, obrazek, log. Tutaj byłby to na przykład słownik tagów używanych w Intercomie.

• Prompty (prompts) - gotowe szablony - polecenia, które świadomie odpalasz. Tutaj mogłoby to być /analiza-skarg: jedno polecenie robiące za każdym razem ten sam przegląd - zbierz zgłoszenia z ostatniego miesiąca, zestaw je z backlogiem, pokaż to, czego w Jirze jeszcze nie ma.

W praktyce 90% tego, o czym się mówi, to narzędzia.

2. Jak serwer MCP wygląda od środka?

Cały kod „Product Insights” to mniej więcej tyle:

mcp = FastMCP("Product Insights")

@mcp.tool()
def szukaj_zgloszen_intercom(fraza: str) -> str:
    """Przeszukuje zgłoszenia klientów w Intercomie po słowie kluczowym."""
    # tu leci zwykłe wywołanie API Intercoma
    ...

@mcp.tool()
def szukaj_zadan_jira(fraza: str) -> str:
    """Szuka otwartych zadań w Jirze po słowie kluczowym."""
    # tu leci zwykłe wywołanie API Jiry
    response = requests.get(
        f"https://twoja-firma.atlassian.net/rest/api/3/issue/{issue_key}",
        headers={"Authorization": "Bearer TWÓJ_TOKEN"}
    )
    data = response.json()
    return f"Tytuł: {data['fields']['summary']}, Status: {data['fields']['status']['name']}"

# Uruchomienie serwera
if __name__ == "__main__":
    mcp.run()
```

Spójrz na zdania w cudzysłowach ("""). Wyglądają jak komentarze porgramistów, ale to jest dokładnie ten tekst, który trafia do modelu i na którego podstawie model decyduje, czy w ogóle sięgnąć po to narzędzie.

I tu pomału zaczyna się praca produktowca - precyzyjne nazwanie, co dane narzędzie robi, kiedy się go używa, a kiedy nie. To bardziej nasza robota, niż inżnierska. Jeśli w Waszej firmie powstaje serwer MCP, a opisy narzędzi pisze ktoś, kto nigdy nie rozmawiał z użytkownikiem, to wróci do Was w postaci agenta AI, który sięga nie tam, gdzie trzeba.

2.1. Jak podłączać serwer MCP to swojej aplikacji AI?

Podłączenie serwera MCP do Twojej aplikacji AI to zwykle kilka linijek w pliku konfiguracyjnym w formacie JSON. Dzięki temu Twoja aplikacja AI (host) wie o istnieniu tego serwera, gdzie leży skrypt i jakie klucze API ma użyć.

{
  "mcpServers": {
    "product-insights": {
      "command": "python",
      "args": ["/Users/jan/scripts/product_mcp_server.py"],
      "env": {
        "JIRA_API_KEY": "tajny_token_jira",
        "INTERCOM_API_KEY": "tajny_token_intercom"
      }
    }
  }
}

• command i args: mówią aplikacji AI, jak uruchomić Twój skrypt.

• env: przechowuje bezpiecznie klucze dostępowe (API keys), dzięki czemu nie trzeba ich wpisywać w chacie ani zaszywać na stałe w kodzie.

Od tego momentu model sam decyduje, kiedy po które narzędzie sięgnąć.

3. Co się dzieje krok po kroku?

Wróćmy do pytania o błędach w płatności i zobaczmy jak by to działało krok po kroku.

Piszesz do swojego agenta (np. w Cursorze / Claude Code):

„Zbierz zgłoszenia z Intercoma o błędach przy płatnościach z ostatnich 30 dni i sprawdź, czy mamy już na to otwarte zadania w Jirze.”

Na początku, przy podłączeniu serwera MCP:

1. Host (Cursor / Claude Code) pyta serwer „co potrafisz?” - to się nazywa capability discovery.

2. Serwer odsyła listę narzędzi wraz z opisami. Od tej pory host wie, czym dysponuje. Nie musi już o to pytać.

A potem przy każdym pytaniu, od nowa:

1. Zadajesz pytanie. Host pakuje je razem z opisami wszystkich dostępnych narzędzi i wysyła do modelu. Tak, przy każdym pytaniu od nowa - model nie pamięta niczego między zapytaniami, więc za każdym razem musi dostać listę tego, czym dysponuje.

2. Model wybiera narzędzie na podstawie opisu. Widzi, że szukaj_zgloszen_intercom pasuje do pierwszej połowy pytania, i odsyła hostowi: „użyj tego, z takim argumentem”.

3. Host prosi Cię o zgodę, jeśli tak to skonfigurowano - krótkie okno „czy mogę wykonać tę akcję?”.

4. Host wywołuje narzędzie na serwerze, a serwer tłumaczy to na zwykłe zapytanie do API Intercoma i je wykonuje. To tutaj żyje cała logika i faktyczny kod.

5. Wynik wraca do hosta, a host dokłada go jako dane do rozmowy z modelem. I tu pętla kręci się od nowa: model widzi wynik z Intercoma i stwierdza, że potrzebuje jeszcze Jiry, więc kroki 4-7 powtarzają się dla drugiego narzędzia.

6. Model składa odpowiedź z obu źródeł: tyle zgłoszeń o płatnościach, z czego na tyle jest już zadanie w Jirze, a te nie mają pokrycia w backlogu.

Zwróć uwagę, że sam model nigdy nie rozmawia z serwerem MCP. Model po prostu dostaje tekst i zwraca tekst. Nie ma dostępu do sieci, nie potrafi niczego uruchomić. Jedyne, co może zrobić, to napisać: „chcę użyć szukaj_zgloszen_intercom z frazą »płatności«”.

Całą resztę robi host. To on czyta tę prośbę, on ją wykonuje i on wkleja wynik z powrotem do rozmowy. Model widzi w całym tym procesie dokładnie dwie rzeczy: opisy narzędzi, którymi dysponuje, i wyniki tego, co host wywołał w jego imieniu. Samego MCP nigdy nie dotyka.

Z takich ważnych, a mniej oczywistych momentów:

• w kroku 2 model wybiera narzędzie na podstawie jego opisu - to znaczy, że jakość tych opisów decyduje o tym, czy agent w ogóle trafi we właściwe narzędzie.

• w krok 4 - tam masz realną kontrola nad tym, co agent robi bez pytania. Większości hostów można to ustawić raz na „zawsze pozwalaj”, co bywa wygodne i jednocześnie jest najczęstszym sposobem, w jaki ludzie przypadkiem tę kontrolę tracą.

4. Dlaczego nie skorzystać po prostu z API?

Skoro serwer MCP w środku i tak woła zwykłe API Intercoma i Jiry - to po co mi w ogóle ten osobny standard? To pytanie pewnie samo Ci się nasunęło po przeczytaniu poprzedniej sekcji…

Zacznę od odpowiedzi, której się raczej nie spodziewasz: bardzo często rzeczywiście nie warto ;)

• Jeśli macie jedno API i jednego agenta, możesz opisać modelowi funkcje API wprost, bez żadnego MCP.

• Samo to, że model wybiera narzędzie w locie, nie jest wynalazkiem MCP - piszę to wprost, bo w wielu tekstach jedno bywa podawane za drugie.

Problem zaczyna się gdy mamy więcej aplikacji AI (hostów) chcących korzystać z większej liczby dostępnych API.

4.1. I tu pojawia nam się problem N × M.

Masz trzy aplikacje AI (np. Cursor, Claude Desktop, własny agent) i cztery usługi, z którymi mają się łączyć (baza danych, GitHub, Jira, Google Drive). Bez wspólnego standardu to 3 × 4 = 12 osobnych integracji, każda pisana i utrzymywana z osobna.

Z MCP twórca bazy danych pisze jeden serwer, twórca GitHuba pisze jeden serwer - i każda z trzech aplikacji od razu wie, jak z nich korzystać, bez dopisania choćby linijki kodu. Z 12 integracji robi się 3 + 4 = 7 połączeń.

I to jest właściwa odpowiedź na pytanie z nagłówka. MCP nie daje Ci niczego, czego nie dałoby się napisać samemu. Daje to, że nie musisz pisać tego samego po raz piąty - i że ktoś inny nie musi pisać tego pod Was.

Najkrócej: MCP nie zastępuje API. Stoi na nim.

4.2. MCP daje wartość dodaną (bo jest pisany pod LLMy)

Jest i drugi, mniej oczywisty powód: warstwa narzędzi w MCP to nie musi być 1:1 z endpointami API.

I często to nie jest. A wynika to z tego, że serwer MCP jest pisany “pod użycie przez LLM”, a API raczej “pod programistów”. Jak to w produkcie - inny odbiorca, inne potrzeby:

• Typowe API jest atomowe. Najpierw GET /projects, potem GET /projects/{id}/tasks, potem jeszcze filtr, paginacja, obsługa błędów.

• Programista ogarnia i programuje tę sekwencję, bo ma dokumentację, czas i che żeby kod był deterministyczny. Decyzja zapada raz, zanim ktokolwiek uruchomi aplikację.

• Model - niekoniecznie. Każde kolejne wywołanie to osobna decyzja, osobne tokeny i osobna okazja, żeby wybrać źle.

Dawanie modelowi czystego API to trochę jak dawanie komuś dokumentacji zamiast aplikacji. Przy małym API da radę. Przy skomplikowanym API najwięcej czasu zjada samo zastanawianie się, co wybrać.

5. W drugiej części…

W kolejnej części zobaczymy gdzie produktowo warto używać MCP, dwa konkretne zastosowania oraz wyzwania związane z MCP.

Ostatnie tygodnie na LinkedInie i w podcastach wyglądają tak, że co druga osoba budująca coś z AI mówi jakiś wariant zdania: „budujemy teraz harness dla naszego AI / agenta”.

Brzmi jak kolejne słowo-wytrych. Ale akurat to może być przydatne, bo nazywa rzecz, o którą w produktach AI toczy się teraz cała gra. Rozłóżmy je na części.

W dzisiejszym wydaniu:

1. Skąd się wzięło całe to “harness”?

2. Z czego składa się harness?

3. Czyli mój agent w Cursorze to już harness?

   1. Budowanie na cudzym harness: analiza zachowania użytkowników w Cursorze

   2. Własny harness: agent konwersacyjny w produkcie

   3. Model się zmienia, harness zostaje

4. Pułapka w budowaniu harnessu

Subscribe now

1. Skąd się wzięło całe to “harness”?

Harness to po angielsku uprząż/rusztowanie. W tworzeniu software’u słowo funkcjonuje od dekad w zbitce test harness - rusztowanie, które uruchamia Twój kod, podaje mu dane wejściowe i sprawdza, co wyszło. Sam kod nic nie robi, dopóki ktoś go nie odpali w odpowiednim otoczeniu.

Przy modelach AI słowo pojawiło się najpierw przy testowaniu:

• Żeby sprawdzić, ile model potrafi, ktoś musi mu podać zadania, dać dostęp do narzędzi, pozwolić popracować przez kilka kroków i policzyć wyniki. Cała ta obudowa wokół testu to właśnie harness.

• Szybko wyszło, że ten sam model w lepszej obudowie rozwiązuje wyraźnie więcej zadań. Firmy zaczęły więc przy wynikach dopisywać, w jakim harnessie testowały - bo bez tego liczba nic nie znaczy. I stąd słowo przeszło z testów do prawdziwych produktów.

Bo mechanizm jest ten sam. Model sam w sobie to funkcja: wchodzi tekst, wychodzi tekst. Nie ma pamięci, nie ma dostępu do Twojego CRM-a, nie wie, czy zadanie zostało skończine

Harness to wszystko, co dokładasz wokół modelu, żeby z tej funkcji zrobić coś, co wykonuje pracę.

2. Z czego składa się harness?

W praktyce modele AI zwykle opakowujemy w podobne warstwy:

• Pętla - model wybiera narzędzie, narzędzie się wykonuje, wynik wraca do kontekstu, model decyduje co dalej. Powtórz, aż zadanie jest zrobione. To pętla, a nie model, sprawia, że coś zachowuje się jak agent.

• Instrukcje - kim agent jest, jaki proces ma wykonać, jakie zna reguły Twojego biznesu i czego nie robi nigdy. Piszesz je Ty / Zespół, świadomie, i możesz je przejrzeć jak zwykły dokument. Z całej listy to warstwa, którą product manager najczęściej robi własnymi rękami.

• Kontekst - wszystko, co agent dostaje do jednego konkretnego zadania: treść zgłoszenia, dane klienta, wyniki wyszukiwania, efekty własnych kroków sprzed chwili.

  • Gdy kontekst się zapełni, harness musi część sprzątnąć i zostawić streszczenie zamiast oryginałów, a agent od tego momentu pracuje na tym streszczeniu.

  • Co trafia do kontekstu i co przetrwa sprzątanie - to dziś główny problem inżynierski w agentach i powód, dla którego mówi się o „context engineering” zamiast o promptach.

• Narzędzia - czytanie plików, wywołanie API, zapytanie do bazy, wysłanie maila.

• Środowisko i uprawnienia - gdzie ta pętla się w ogóle wykonuje. Na czyimś laptopie, w kontenerze, na osobnej maszynie w chmurze. Czy agent ma dostęp do internetu, do jakich plików, i co zostaje po zakończeniu zadania. Co agent może zrobić sam, co wymaga kliknięcia człowieka, co jest zablokowane, i jak to cofnąć. To decyduje o tym, jakie akcje są fizycznie możliwe, i o tym, co się stanie, gdy agent zrobi coś głupiego.

• Weryfikacja - skąd agent (i Ty) wiecie, że zadanie zostało wykonane dobrze. Testy, walidacja, drugi model jako recenzent, sprawdzenie stanu w systemie.

• Limity i obsługa błędów - limit kroków, limit tokenów, timeout, retry, co się dzieje, gdy narzędzie zwróci błąd.

3. „Czyli mój agent w Cursorze to już harness?”

W sumie Tak.

Cursor, Claude Code i Claude Cowork to gotowe harnessy, w dodatku jedne z najlepszych, jakie w tej chwili można dostać.

Wszystkie wspomniane warstwy już tam siedzą: pętla, która kręci się tak długo, aż zadanie jest zrobione, pliki z instrukcjami i regułami, zarządzanie kontekstem, narzędzia (terminal, edycja plików, wyszukiwanie, MCP), środowisko wykonania, pytanie o zgodę przed groźniejszymi akcjami, uruchamianie testów jako weryfikacja i limity, po których agent się zatrzymuje. Cześć z tych rzeczy sam dorzucasz do Cursora (np. pliki kontekstu, podłączasz narzędzia)

Ale warto rozdzielić dwie rzeczy, bo w rozmowach ciągle się mieszają.

• Rozbudowa cudzego harnessu - odpalasz Cursora, dopisujesz plik z instrukcjami, ustawiasz reguły, podpinasz MCP, dajesz dostęp do folderu z danymi. To jest praca nad harnessem - realna i sensowna - tylko na cudzym fundamencie. Ktoś zbudował pętlę, narzędzia, środowisko i uprawnienia, a Ty konfigurujesz to pod siebie.

• Budowanie własnego harnessu - Twój produkt, Twoi użytkownicy, Twoje narzędzia, Twoje reguły tego, co agent może zrobić bez pytania. Tutaj wszystkie osiem warstw jest na Twojej głowie.

Najłatwiej będzie to zobaczyć na przykładach, wiec dwa przykłady z mojej praktyki w pracy fractional PMa nad indem z produktów Conversational AI:

3.1. Budowanie na cudzym harness: analiza zachowania użytkowników w Cursorze

Harnessem, które używam na codzień jest np. mój zwykły projekt w Cursorze, który służy mi do rozumienia, co użytkownicy robią w moim produkcie oraz ilościowa ewaluacji zmian / problemów użytkowników:

• Moje instrukcje to pliki z opisem produktu i znaczeniem konkretnych metryk + skille odnośnie tego jak pracować z bazą danych.

• Narzędzia to dostęp do kodu oraz do bazy z możliwością puszczania zapytań SQL.

• Kontekst to pliki z poprzednimi analizami, więc agent nie startuje za każdym razem od zera.

• Guardrails - do weryfikacji procesu oraz wyników

• Finalną weryfikatorem jestem ja - czytam zapytanie, patrzę na wynik, mówię „nie tak” i lecimy dalej.

Zero linijek kodu. Cała robota to pliki tekstowe i przyznanie dostępów. A różnica wobec wklejenia pytania do zwykłego czatu jest gigantyczna, bo model w czacie nie wie, co w tym produkcie znaczy „aktywny użytkownik” ani w której tabeli tego szukać.

3.2. Własny harness: agent konwersacyjny w produkcie

Drugi przykład to już właśnie agent rozmawiający z użytkownikami produktu, którym zajmuję się jako PM. Tu trzeba było zbudować harness od zera. Jest tam m. in.:

• Agent, który pisze odpowiedzi do użytkowników

• Agent, który sprawdza odpowiedź zanim pójdzie do użytkownika

• Instrukcje nie są jednym wielkim promptem: jest baza plus skille, które doładowują się razem z potrzebnymi narzędziami dopiero wtedy, gdy sytuacja tego wymaga.

• Guardrails które opisują co bot może, a czego nie może robić

• Środowisko odpalające modele - część na lokalnych naszych, część przez dostęp po API

• Do tego automatyczne testy i narzędzie wyłapujące zakazane słowa oraz próby prompt injection - rozwiązany kodem zamiast nadzieją, że model sam się połapie.

• …

3.3. Model się zmienia, harness zostaje

Oba harnessy przeżyły już wiele zmian modelu:

• W moim harnessie do analiz w Cursorze - za każdym razem mogę wybrać inny model. W zależności od tego jak trudne jest zadanie to wybieram tańsze/droższe modele.

• W produkcie też finalnie sprowadza się do zmiany jednej linijki konfiguracji - reszta zostaje nietknięta i właśnie o to chodzi w całym tym rozróżnieniu.

Tylko że wyniki po takiej zamianie potrafią się zmienić i nie zawsze na plus. I w przypadku produktu może mieć mieć to kolosalne znaczenie - nowy model bywa lepszy w jednych rzeczach, a w innych nagle zaczyna ignorować instrukcję, którą poprzedni respektował, albo inaczej korzysta z narzędzi. Nie ma tu żadnej gwarancji, że „nowsze” znaczy „lepsze dla mojego zastosowania”.

I to jest moment, w którym AI evals do twojego produktu stają się krytycznym elementem. Bez zestawu zadań, na którym mierzysz jakość, po podmianie modelu masz dokładnie jedno źródło wiedzy o tym, czy było warto: własne wrażenie.

Praktyczny wniosek: Cursor czy Claude Code to najtańszy symulator, jaki masz. Zbuduj tam prototyp procesu, który chcesz zautomatyzować w produkcie, i policz, ile razy musiałeś ręcznie wejść i poprawić. Każde takie wejście to element, który w Twoim produkcie ktoś będzie musiał zaprogramować.

4. “Harness” to to czym wyróżnia się Twój produkt

Najciekawsza obserwacja z ostatniego roku: ten sam model w dwóch różnych harnessach daje radykalnie różne wyniki. Laby raportują na benchmarkach agentowych różnice liczone w kilkunastu punktach procentowych, przy dokładnie tej samej wadze modelu. Narzędzia, których codziennie używasz, siedzą na tych samych modelach od Anthropic czy OpenAI - a różnią się jakością bardzo mocno.

Dla PM-a wynikają z tego cztery rzeczy.

1. Wartość przesunęła się z wyboru modelu na projekt otoczenia - „Który model wybieramy” jest ważne, ale z czasem ta decyzja będzie mniej więcej tej wagi decyzją co wybór dostawcy hostingu. Ważna, odwracalna, nie różnicująca. Różnicujące jest to, jakie narzędzia dajesz agentowi, do jakich danych ma dostęp i jak sprawdzasz jego pracę. Tego konkurencja nie kupi w API.

2. Backlog wygląda inaczej - zamiast „dodajmy AI do modułu X” pytania brzmią: jakie narzędzia dostaje agent, jaki kontekst wchodzi do pętli, co robi sam, w którym momencie pyta człowieka, po czym poznajemy sukces. To są pytania produktowe, nie techniczne - i nikt ich za Ciebie nie zada.

3. AI Evals i metryki produktowe są krytycznie ważne - nie da się iterować po harnessie bez zestawu zadań, na których mierzysz, czy zmiana pomogła. Bez patrzenia jak to wpłynęło na zachowanie użytkowników.

4. Model biznesowy liczy się per zadanie, nie per użytkownik - pętla, która kręci się czterdzieści kroków, kosztuje czterdzieści razy więcej niż jedno zapytanie. Koszt i czas wykonania zadania stają się metrykami produktowymi, bo bezpośrednio decydują, czy model biznesowy się spina.

4. Pułapka w budowaniu harnessu

Część harnessu, którą budujesz dziś, za pół roku wchłonie model. Widać to za każdą generacją: rozbudowane systemy do planowania czy dekompozycji zadań dla agentów stają się mniej potrzebne, bo nowe modele robią to same coraz lepiej.

Prosta zasada podziału: buduj to, co specyficzne dla Twojej domeny - dostęp do danych, reguły biznesowe, uprawnienia, definicję sukcesu. Nie buduj protez do ogólnej inteligencji.

Jeśli Twój harness w większości łata to, czego model nie umie, następny release może go zaorać. Jeśli koduje wiedzę o Twoim biznesie - wiedzę dziedzinową, będzie żył dalej i przy okazji stanie się lepszy razem z modelem.

W tym roku akcja w nowej odsłonie - do rozdania mam kilkadziesiąt dostępów do narzędzi, z których sam korzystam na co dzień (PostHog, Claude Pro), plus online pass na świetną konfę (Product Lab). Łączna wartość wszystkich dostępów to ponad 15 000 zł.

To taka moja forma odwdzięczenia się Wam - subskrybentów, za to, że mi zaufaliście i wspieracie moją pracę. Dziękuję za kolejne 12 miesięcy 🙏.

W tegorocznym “dropie” mam dla Was:

• 📈 38x PostHog (kredyty premium o wartości $100) - moje główne narzędzie do analityki produktowej, pokazywałem

• 👩‍💻 5x Claude Pro - (miesięczna wersja premium o wartości 20€) - najlepszy do produktowej pracy agent / asystent AI którego używam codziennie

• 🎫 5x online pass na ProductLab Conf (bilet o wartości 30€) - jedna z najważniejszych konferencji produktowych w Europie

Łączna wartość wszystkich pakietów to ponad 15 000 zł.

🤝 Partnerem akcji w tym roku jest narzędzie analityczne PostHog, który przeznaczył dla Was pakiety o wartości, aż 3800$. Dzięki PostHog za współpracę :). Sam używam do analityki produktowej w swoich produktach i polecam!

🎁 Jak odebrać jeden z pakietów?

W tym roku zasady są proste. Klikasz przycisk poniżej, wybierasz jeden pakiet, podajesz swój adres email i… tyle. Kto pierwszy, ten lepszy - jak znikną kafelki, to znaczy że pakiety już poszły.

Odbierz prezent

Po zakończeniu akcji odezwę się do zapisanych osób z instrukcją jak odebrać pakiet.

📕 A co z książkami?!

W poprzednich edycjach zawsze rozdawałem książki produktowe.

I one w tym roku nie znikają. Tym razem jednak moje ulubione książki wysyłam indywidualnie do wybranych osób, które miały na mnie największy w wpływ w ostatnich 12 miesiącach. Czuję, że to lepsze forma.

To działamy 🙂. Mam nadzieję, że znowu będzie okazja zrobić trochę dobra 🖤.

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

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

Rozmawiamy o tym:

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

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

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

Zaczynamy 👇

Słuchaj na Spotify

lub Apple Podcast.

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

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

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

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

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

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

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

Moje notatki z podcastu

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

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

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

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

• 5️⃣ Podsumowanie

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

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

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

A takiego miejsca nie było.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3. Społeczność to… marketplace

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

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

W tym marketplace masz dwie strony:

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

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

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

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

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

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

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

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

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

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

Retencja - jak w produkcie

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

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

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

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

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

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

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

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

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

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

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

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

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

Samotność.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zasada 2: Najpierw chemia, potem szczerość

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

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

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

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

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

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

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

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

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

Zasada 4: Zbuduj sieć, zanim jej potrzebujesz

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

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

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

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

Ciekawostka: Ile… pije się na konferencjach produktowych?

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

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

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

5️⃣ Podsumowanie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

→ Posłuchaj odcinka

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

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

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

W dzisiejszym wydaniu:

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

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

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

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

Subscribe now

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3️⃣ Przeglądarka Comet i jej alternatywy

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

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

Alternatywy co przeglądarki Comet

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

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

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

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

• ChatGPT Agent Mode albo wtyczka Claude do Chrome

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

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

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

⚠️ Bezpieczeństwo

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

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

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

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

4️⃣ Gotowy prompt do skopiowania

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

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

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

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

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

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

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

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

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

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

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

🇬🇧 Wersja angielska promptu

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

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

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

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

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

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

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

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

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

Podsumowanie

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

Co zrobić po przeczytaniu:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 3️⃣ Dobrze jest być AI PMem

• 4️⃣ Praca zdalna - koniec wzrostów

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

• 🔗 Pełne wyniki ankiety

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

Subscribe now

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

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

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

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

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

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

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

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

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

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

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

3️⃣ Dobrze jest być AI PMem

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

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

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

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

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

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

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

4️⃣ Praca zdalna - koniec wzrostów

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🔗 Pełne wyniki

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

Lenny's Newsletter

State of the product job market in early 2026

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

Read more

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

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

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

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

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

W dzisiejszym wydaniu:

1. Czym jest Forward Deployed Engineer?

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

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

4. Co to oznacza dla produktu?

5. Pułapka we wdrożeniu FDE

Subscribe now

1. Czym jest Forward Deployed Engineer?

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

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

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

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

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

1. Solidne inżynierskie fundamenty

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

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

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

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

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

1.1. Co robi FDE?

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

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

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

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

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

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

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

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

1.2. Podejście ElevenLabs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• OpenAI buduje własne zespoły FDE.

• Anthropic robi to samo.

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

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

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

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

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

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

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

2.2. Produkty AI drastycznie przyspieszyły ten trend

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

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

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

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

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

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

2.3. Mid-market też w to wchodzi

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

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

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

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

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

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

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

3.1. Problemy wdrożeń produktów AI

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

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

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

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

3.2. Zrozumienie technologii i narodziny Double Loop

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

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

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

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

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

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

3.3. Skalowanie

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

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

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

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

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

4. Co to oznacza dla produktu?

Coraz bardziej “Shipped” nie znaczy “done”.

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

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

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

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

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

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

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

5. Pułapka we wdrożeniu FDE

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

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

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

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

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

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

6. Podsumowanie

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

Trzy rzeczy do zabrania z tego wydania 👇

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

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

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

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

Brzmi znajomo? No właśnie.

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

→ Słuchaj na Spotify

lub Apple Podcast.

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

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

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

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

Z odcinka dowiesz się:

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

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

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

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

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

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

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

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

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

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

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

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

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

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

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

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

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

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

Subscribe now

Co zobaczysz na nagraniu?

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

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

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

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

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

ℹ️ Czym są syntetyczni użytkownicy

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

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

Koncepcji zastosowania są co najmniej dwie:

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

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

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

1️⃣ Wywiady z syntetykami

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

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

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

I tu powiem wprost: jestem sceptyczny.

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

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

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

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

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

2️⃣ Testy użyteczności

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

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

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

W takim narzędziu definiujesz 3 rzeczy:

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

• eksplorację strony i przejrzenie oferty

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

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

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

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

Co dostałem w wynikach?

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

Z mojego testu Product Academy:

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

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

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

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

🔀 Alternatywa - przeglądarka AI

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

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

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

Podsumowanie

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

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

Moja praktyka w trzech zdaniach:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Subscribe now

Co zobaczysz na nagraniu?

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

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

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

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

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

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

Najważniejsze wnioski:

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

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

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

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

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

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

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

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

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

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

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

4. Zobacz, co dostajesz - i zadaj kolejne pytanie

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

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

Bo to są trudniejsze pytania.

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

→ Słuchaj na Spotify

lub Apple Podcast.

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

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

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

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

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

Z odcinka dowiesz się:

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

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

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

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

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

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

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

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

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

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

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

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

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

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

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

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

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

Brzmi znajomo? 😅

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

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

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

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

• 3️⃣ Zastosowanie 2: research do konkretnej inicjatywy

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

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

Subscribe now

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

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

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

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

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

Zasada działania jest prosta:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1. Kiedy to się przydaje

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

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

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

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

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

2.2. Co wrzucać (a czego nie)?

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

Konkretnie warto wrzucić:

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

• Wyniki ankiet z analizą

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

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

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

2.3. Jak organizować przy większej skali

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

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

3️⃣ Zastosowanie 2: notebook do researchu konkretnego tematu

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

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

• Transkrypcje wywiadów z użytkownikami

• Wyniki ankiet ewaluacyjnych

• Surowy feedback z formularzy i Intercom/Zendesk

• Nagrania rozmów sprzedażowych

3.1. Konkretny przykład z mojego workflow

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

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

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

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

3.2. Dlaczego to lepsze niż ChatGPT

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

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

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

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

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

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

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

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

• Infografika - szybka wizualizacja danych jako punkt startowy

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

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

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

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

Dwa zastosowania, które polecam:

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

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

Co możesz zrobić w tym tygodniu

1. Wejdź na notebooklm.google.com

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

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

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

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

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

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

→ Słuchaj na Spotify

lub Apple Podcast.

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

Z odcinka dowiesz się:

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

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

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

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

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

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

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

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

Słuchaj tego odcinka

Moje najważniejsze insighty z rozmowy:

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

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

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

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

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

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

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

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

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

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

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

Poniżej znajdziesz szczegóły tej zmiany:

1. Czym jest podcast “Dodane do Backlogu”?

2. Co opublikowaliśmy do tej pory?

3. Co to zmienia dla Ciebie? Subskrybent newslettera

4. Co dalej?

1. Czym jest podcast “Dodane do Backlogu”?

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

Subskrybuj na Spotify

Kim jesteśmy:

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

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

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

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

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

2. Co opublikowaliśmy do tej pory?

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

Marty Cagan (SVPG):

David Pereira (CPO MailerLite),

Todda Romana (SVP Zendesk).

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

3. Co to zmienia dla Ciebie?

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

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

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

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

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

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

4. Co dalej? Mocny odcinek

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

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

Zostawiam Was z tym - i do usłyszenia.

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

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

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

→ Słuchaj na Spotify

lub Apple Podcast.

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

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

• Wojtek Smajda (Senior Product Manager, IBM)

• Jakub Tutaj (Growth Product Manager, Mixmax)

• Marcin Jedrzejczak (Principal Product Manager, Celonis)

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

W odcinku usłyszysz:

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

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

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

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

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

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

Słuchaj odcinka

Moje najważniejsze insighty z rozmowy:

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

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

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

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

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

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

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

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

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

W dzisiejszym wydaniu:

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

2. Dlaczego koszty modeli mają gigantyczny znaczenie?

3. Jak podejść do wyboru modelu?

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

5. Podsumowanie

Subscribe now

Ogłoszenia:

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

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

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

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

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

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

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

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

Dlatego to co zrobiliśmy to…

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

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

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

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

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

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

Witamy w niedeterministycznym świecie rozwijania produktów AI.

2. Dlaczego koszty mają gigantyczne znaczenie?

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

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

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

To daje nam miesięcznie:

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

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

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

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

• Kimi K2.5 - model od firmy Moonshot AI

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

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

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

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

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

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

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

3. Jak podejść do wyboru modelu?

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

1️⃣ Zacznij od benchmarków

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

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

-

2️⃣ Przetestuj na SWOICH danych

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

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

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

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

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

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

-

3️⃣ Policz koszty w skali

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

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

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

-

4️⃣ Zdefiniuj trade-off

Tu wchodzisz w sedno decyzji produktowej:

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

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

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

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

-

5️⃣ Podejmij decyzję produktowa, nie techniczną

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

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

4. Czego unikać?

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

--

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

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

--

🔹 „Zmienimy model - to jest proste”

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

--

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

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

--

🔹 Ignorowanie kosztów cachingu

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

5. Podsumowanie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🔓 Odblokuj te Case Study

🎁 A gdzie to piąte case study?

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

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

🎦 Ocena funkcji produktu | SentiOne Listen (25 min)

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

Otwórz Case Study

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

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

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

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

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

• 1️⃣ Moja historia zarządzania promptami

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

• 3️⃣ Dwa poziomy komend - project vs user

• 4️⃣ Tworzenie własnej komendy w Curosorze

• 5️⃣ Mój konkretny use-case

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

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

• 👉 Co dalej?

Subscribe now

1. Moja historia zarządzania promptami

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

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

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

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

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

2. Czym są komendy (Commands)?

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

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

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

/napisz-taska - tworzy opis zadania w Twoim formacie

/podsumuj-spotkanie - przetwarza surowe notatki na czytelne podsumowanie

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

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

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

3. Dwa poziomy komend - project vs user

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

Project commands - komendy przypisane do konkretnego projektu/folderu:

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

• Widoczne tylko gdy masz ten projekt otwarty w Cursorze

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

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

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

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

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

3. Tworzenie własnej komendy w Curosorze

Krok 1: Tworzenie Commmand

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

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

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

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

Krok 2: Napisz komendę jako plik Markdown

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

Tu przykładowa komenda:

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

## Format opisu

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

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

## Kontekst Produktu

Kontekst produktu znajdziesz w [nazwa pliku]

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

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

Krok 3: Wywołaj komendę

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

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

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

4. Mój konkretny use-case

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

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

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

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

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

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

/jira-task [opcjonalnie dodatkowy opis taska]

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

Mój plik komendy wygląda tak:

# jira-task

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

## Task Structure

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

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

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

## Writing Rules

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

## Examples

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

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

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

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

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

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

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

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

## Language

Write in English. Use simple, direct sentences.

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

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

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

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

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

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

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

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

✅ Zadanie dla Ciebie:

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

👉 Co dalej?

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

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

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

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

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

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

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

🔹 10x Product Bootcamp (1.04 - 13.05)

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

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

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

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

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

Szczegóły i rezerwacja biletu

I jeszcze jedno fajne INFO:

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

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