Poniższy tekst to notatki z odcinka podcastu „The Claude Code Analytics Workflow Top AI PMs Don’t Want You to Know” prowadzonego przez Akasha Guptę (kanał Akash G / Build). Wszystkie obserwacje, przemyślenia i wnioski opisane w głównych sekcjach artykułu pochodzą od Franka Lee, head of AI PM w Amplitude, który w tym odcinku przeprowadza demonstrację na żywo. Wyjątkiem są sekcje z checklistą, promptami i kluczowym insightem, które stanowią interpretację i opracowanie na podstawie treści rozmowy.

TL;DR

Claude Code połączony z MCP pozwala product managerom zautomatyzować analizę danych, tygodniowe raporty, syntezę feedbacku i tworzenie specyfikacji.
Analiza wykresu, która zajmowała analitykowi od jednej do trzech godzin, trwa teraz około 1,5 minuty.
Podstawą działającego systemu jest dobrze zorganizowane repozytorium produktowe w GitHubie z plikami markdown, szablonami PRD i notatkami ze spotkań.
Repozytorium w chmurze odblokowuje pracę mobilną: zadania można zlecać agentom asynchronicznie z telefonu.
Największy błąd przy MCP to podłączenie zbyt wielu narzędzi jednocześnie, co przeciąża kontekst modelu i obniża jakość odpowiedzi.
Skills w Claude Code rozwiązują problem przeciążenia kontekstem, ładując instrukcje tylko wtedy, gdy są potrzebne.
Cały workflow zamyka pętlę: od anomalii w danych, przez insight i PRD, aż po ticket w Linearze lub prototyp w kodzie.

Dlaczego product managerowie tracą niedziele na dashboardy

Zanim pojawiły się narzędzia agentyczne, cotygodniowe raportowanie wyglądało podobnie u większości product managerów. Jak opisuje Frank Lee, pracując w Amazonie spędzał każdą niedzielę na ręcznym przeglądaniu metryk, kopiowaniu danych z dashboardów Tableau i wyjaśnianiu, dlaczego poszczególne liczby się zmieniły.

Dziś ten sam proces uruchamia się automatycznie w poniedziałek rano. Agenci przeskanowały już pięć do sześciu dashboardów, wyciągnęły trzy do pięciu najważniejszych insightów i oznaczyły jeden pilny problem do omówienia z zespołem. W rezultacie Lee nie zaczyna tygodnia od analizy danych, lecz od szukania rozwiązań.

Jest to działający system, który Lee prezentuje na żywo podczas nagrania.

Co to jest Claude Code i MCP?

Claude Code to terminalowy agent kodujący z dostępem do modeli Anthropic. Działa bezpośrednio w terminalu, obsługuje tzw. Skills (instrukcje wyzwalane kontekstowo) i wykonuje złożone sekwencje poleceń bez ciągłego nadzoru użytkownika.

MCP (Model Context Protocol) to, jak wyjaśnia Lee, najłatwiejszy sposób na połączenie modeli AI z zewnętrznymi narzędziami, danymi i akcjami. Można go porównać do standaryzowanego gniazdka elektrycznego: każde narzędzie ma wtyk w tym samym formacie, dlatego podłączenie nowego systemu do agenta to kwestia jednej konfiguracji, a nie wielomiesięcznej pracy integracyjnej.

Narzędzia takie jak Claude, Cursor i ChatGPT zbiegły się już na tym samym standardzie. Oznacza to w praktyce, że dane z Amplitude, Lineara, Zendeska czy Slack można dziś podłączyć do agenta bez pisania własnych integracji.

Claude Code czy Cursor? Odpowiedź Franka Lee jest nieoczywista

Frank Lee używa obu narzędzi intensywnie i wyraźnie nie zgadza się z traktowaniem tego wyboru jako zero-jedynkowego.

Cursor oferuje dedykowane środowisko IDE: podgląd plików, szybkie modele, skrót Command+K do edycji zaznaczonego fragmentu kodu oraz Command+L do prowadzenia rozmowy w kontekście konkretnych linii. Claude Code z kolei działa w terminalu i według Lee daje marginalnie lepszą jakość odpowiedzi przy złożonych zadaniach agentycznych, jednak wymaga pracy bez wizualnego interfejsu.

W praktyce Lee sięga po Cursora przy iteracji na plikach i szybkich poprawkach, natomiast Claude Code stosuje do długich zadań analitycznych i workflowów wymagających pełnej kontroli przez terminal. Jak podkreśla: „Zawsze się waham, gdy słyszę, że to jedno albo drugie. Używam obu ekstremalnie intensywnie.”

Jak zorganizować repozytorium produktowe

Przed uruchomieniem jakiegokolwiek workflow Lee rekomenduje zbudowanie dobrze zorganizowanego repozytorium produktowego w GitHubie. Jego własne repo ma następującą strukturę:

Foldery per product line z plikami markdown opisującymi inicjatywy, plany kwartalne i roadmapy dla każdego obszaru (agents, AI feedback, MCP, enterprise).
Szablony PRD jako pliki markdown z instrukcjami formatowania, heurystykami decyzyjnymi i sekcją acceptance criteria.
Notatki ze spotkań importowane automatycznie z Granoli przez skrypt napisany w Claude Code (Granola nie posiada własnego MCP, więc Lee opracował własne obejście).

Cały kontekst jest dostępny przez komendę @ w Cursorze lub przez odwołanie do pliku w Claude Code. Każda nowa sesja zaczyna się ze świeżym oknem kontekstu, jednak pliki repozytorium są zawsze pod ręką.

Co do limitu kontekstu: przy podłączonym Amplitude i Linearze narzędzia MCP zajmują według Lee od 5 do 10% dostępnego kontekstu, co rzadko stanowi problem. Gdy kontekst zbliża się do 90%, zaleca on zapisanie do pliku markdown postępu pracy i otwarcie nowej sesji, zamiast polegać wyłącznie na automatycznej komendzie compact.

Lee formułuje przy tym nieoczywistą radę: nie warto nadmiernie optymalizować pod dzisiejsze limity kontekstu, ponieważ nowe modele, które pojawią się w ciągu kilku miesięcy, prawdopodobnie rozwiążą większość tych ograniczeń samodzielnie. Lepiej budować system z myślą o tym, co będzie możliwe.

Repozytorium w chmurze a praca mobilna

Trzymanie repozytorium w GitHubie w chmurze daje dodatkową korzyść, o której łatwo zapomnieć. Lee wspomina, że zadania można zlecać Claude Code bezpośrednio z aplikacji mobilnej Claude, odwołując się do repozytorium w chmurze. Nie jest potrzebny laptop, aby uruchomić agenta asynchronicznie w tle.

Pięć workflow, które Frank Lee stosuje regularnie

1. Analiza anomalii w wykresach

Gdy w metrykach pojawia się coś nieoczekiwanego, Lee podaje link do wykresu i wywołuje skill analyze chart. Agent łączy się przez MCP z Amplitude, parsuje URL, pobiera dane, przeszukuje powiązane wykresy, grupuje je według różnych właściwości i formułuje hipotezy o przyczynach zmiany.

Format odpowiedzi jest z góry zdefiniowany w skrypcie Skilla: co się wydarzyło i kiedy, dane bazowe, główna hipoteza, dowody, implikacje biznesowe. Lee stworzył ten format, inspirując się produktem Auto Insights w Amplitude, który automatycznie pobiera 20–30 podobnych wykresów na podstawie właściwości analizowanego wykresu, szuka anomalii i proponuje hipotezy.

W trakcie demo agent wykrył, że wzrost liczby wywołań narzędzi (do poziomu 8,1 tygodniowo) był powiązany ze zmianą w feature flagach. Cała analiza zajęła około 1,5 minuty. Ręcznie, przy znajomości taksonomii danych, zajęłaby od jednej do trzech godzin. Bez tej znajomości: pół dnia lub więcej.

2. Automatyczne raporty tygodniowe

Skill analyze dashboard instruuje agenta, jak interpretować różne typy wykresów: dla KPI szuka procentowych zmian, dla wykresów słupkowych szuka koncentracji i luk. Po przeanalizowaniu wykresów agent sięga po dane feedbackowe i weryfikuje, czy zawierają coś istotnego dla danego dashboardu.

Tygodniowe raporty dla poszczególnych zespołów w Amplitude są w rezultacie generowane automatycznie i trafiają do kanałów Slack przed poniedziałkowym spotkaniem. Żaden PM nie musi ręcznie skanować dashboardów: dostaje gotowe podsumowanie z wyróżnionymi odchyleniami i insightami.

3. Synteza jakościowego feedbacku klientów

Amplitude zbiera feedback z Zendeska, Intercomu, Salesforce, Gonga, publicznych kanałów, G2 i app store’ów. Wszystko trafia do jednego miejsca przez produkt AI Feedback, co Lee porównuje do zastąpienia arkuszy kalkulacyjnych i Zapierów jednym endpointem w MCP.

Skill analyze feedback pobiera zarówno przetworzone insighty, jak i surowe dane, a następnie generuje raport zawierający pilne problemy, bugi oraz jedną rzecz, którą użytkownicy w danym tygodniu cenią najbardziej. Zamiast śledzenia informacji w sześciu różnych kanałach, wystarczy jedno wywołanie agenta.

4. Konwersja insightów w specyfikacje PRD

Po zebraniu insightów z feedbacku lub analizy wykresów agent konwertuje je bezpośrednio w drafty PRD i umieszcza w odpowiednim folderze repozytorium. Lee korzysta przy tym z własnego szablonu PRD, który definiuje format, heurystyki projektowe i sekcję acceptance criteria.

Pierwsze drafty bywają według niego zbyt obszerne. Kilka iteracji w Cursorze (skrót Command+K na zaznaczonej sekcji) pozwala jednak szybko je skrócić i doprecyzować. Lee wskazuje model Opus jako szczególnie użyteczny przy generowaniu pomysłów produktowych i projektowych.

5. Routing do Lineara lub prototypowanie w kodzie

Ostatni krok to decyzja: czy problem jest na tyle prosty, żeby zaprototypować go samodzielnie, czy wymaga zaangażowania zespołu.

Dla prostych zmian Lee zleca stworzenie prototypu bezpośrednio w Claude Code lub Cursorze. Przy bardziej złożonych problemach używa MCP Lineara, gdzie przypisuje ticket do odpowiedniego zespołu i inżyniera. Ponieważ Slack posiada własny MCP, wiadomość można wysłać bezpośrednio z poziomu workflow agenta. Lee zaznacza, że coraz częściej pomija Linear i pisze wprost do inżyniera na Slacku, co eliminuje jeden zbędny krok w procesie.

Jak zbudować skill w Claude Code

Skill to, jak określa Lee, po prostu prompt z metadanymi. Każdy skill składa się z czterech elementów:

Nazwa (np. analyze chart, analyze feedback) używana do wywołania przez komendę slash.
Opis i warunek wywołania informujący model, kiedy powinien ten skill zastosować.
Zestaw heurystyk i kroków definiujący, co dokładnie agent ma robić i w jakiej kolejności.
Konfiguracja narzędzi MCP, z których skill korzysta do wykonania zadania.

Skills ładują się do kontekstu wyłącznie wtedy, gdy są potrzebne. Dzięki temu rozwiązują jeden z kluczowych problemów MCP, opisanych w następnej sekcji.

Największe błędy przy wdrażaniu MCP

Pierwszym błędem są zbyt wysokie oczekiwania. MCP to nie silnik do złożonych workflowów, lecz najłatwiejszy sposób na połączenie AI z zewnętrznymi systemami i pobieranie danych. Kto oczekuje, że sam protokół wykona całą pracę agentową, będzie rozczarowany.

Drugi błąd, rzadziej omawiany, polega na podłączeniu zbyt wielu narzędzi jednocześnie. Gdy agent ma dostęp do dziesiątek MCPs z setkami narzędzi, wszystkie ich nazwy, opisy i instrukcje formatowania ładują się do kontekstu przy każdym zapytaniu, nawet jeśli są całkowicie nieistotne dla danego zadania. W efekcie pojawia się wyższe opóźnienie, niespójne odpowiedzi i agent uwzględniający narzędzia, których w ogóle nie potrzebuje.

Rozwiązanie jest następujące: należy ukrywać lub usuwać narzędzia nieużywane w danym workflow, optymalizować ich nazwy tak, by model nie miał wątpliwości, które narzędzie do czego służy, oraz stosować Skills jako mechanizm kontrolujący, kiedy dane narzędzia są w ogóle brane pod uwagę.

Cztery zarzuty wobec MCP i odpowiedź na nie

Lee wymienia cztery najczęstsze krytyki protokołu i odnosi się do każdej z nich:

MCP jest przereklamowany – oczekiwania były nadmiernie wysokie, jednak jako standard łączenia AI z systemami zewnętrznymi MCP jest dziś powszechnie przyjęty.
MCP marnuje kontekst – problem ten rozwiązują Skills oraz dynamiczne wywoływanie narzędzi oparte na mechanizmie RAG, które wdrożyły już Cursor i Claude.
Konfiguracja i autoryzacja to koszmar – większość klientów AI oferuje dziś zarządzany przepływ konfiguracji: jedno kliknięcie, a autoryzacja jest obsługiwana automatycznie.
MCP jest zbyt skomplikowany – zarzut traci na aktualności, ponieważ narzędzia konwergują na jednym standardzie i upraszczają onboarding.

Według Lee: „Claude, ChatGPT, Cursor – wszyscy zbiegli się na tym samym standardzie. To już nie jest eksperyment, to jest norma.”

Kiedy potrzebujesz Conductora, a kiedy wystarczy terminal

Conductor to narzędzie do równoległego uruchamiania wielu agentów kodujących. Jego kluczowa innowacja opiera się na mechanizmie git work trees: repozytorium jest kopiowane do osobnych gałęzi, dzięki czemu 5–10 instancji Claude Code może działać jednocześnie bez wzajemnych konfliktów przy scalaniu zmian.

Dla product managerów realizujących jednorazowe zadania analityczne lub tworzących specyfikacje Conductor jest jednak zbędny. Konflikty gałęzi pojawiają się wyłącznie wtedy, gdy kilka agentów równolegle modyfikuje ten sam kod. W przypadku typowych zadań produktowych wystarczą osobne zakładki w terminalu. Conductor jest natomiast narzędziem pierwszego wyboru dla tych, którzy prowadzą intensywne prace kodujące z wieloma równoległymi zadaniami w tym samym repozytorium.

„Cursor moment” Amplitude: co to oznacza dla product managerów

Amplitude opisuje swój launch agentów jako swój odpowiednik „cursor moment” w analityce. Analogia jest precyzyjna: tak jak Cursor obniżył próg wejścia do programowania dla osób niebędących programistami, Amplitude dąży do tego samego w obszarze nawigacji i analizy danych produktowych.

W ramach launchu Amplitude udostępnia globalnego agenta osadzonego w całej platformie, cztery wyspecjalizowane subagenty (dashboard, session replay, feedback, website optimization), zewnętrzne MCP dla zaawansowanych użytkowników tworzących własne workflow oraz agenta dostępnego bezpośrednio w Slacku. Ten ostatni odpowiada na pytania o dane w kilka minut i zwraca pełną analizę wraz z linkami do wykresów.

Efekt jest, jak zaznacza Lee, dwukierunkowy. Z jednej strony podnosi się podłoga: osoby nieznające taksonomii danych mogą teraz poruszać się po narzędziu za pomocą naturalnego języka. Z drugiej strony rośnie sufit: zaawansowani użytkownicy realizują zadania, które wcześniej wymagały wsparcia analityka.

Jak zacząć: minimalny setup według Lee

Lee wskazuje logiczną kolejność wdrożenia, która pozwala wejść w ten workflow krok po kroku:

Stwórz repozytorium produktowe na GitHubie z plikami markdown dla każdego obszaru, którym zarządzasz.
Dodaj co najmniej jeden szablon PRD jako plik markdown.
Podłącz jeden MCP, najlepiej narzędzie analityczne lub do zarządzania zadaniami.
Rozważ Context7 jako MCP umożliwiający pobieranie dokumentacji z zewnętrznych repozytoriów (Lee regularnie z niego korzysta).
Napisz pierwszy skill dla zadania, które wykonujesz najczęściej.
Obserwuj, gdzie nadal spędzasz czas ręcznie, i od tego miejsca kontynuuj automatyzację.

MCP to, jak podsumowuje Lee, punkt wejścia do bardziej zaawansowanych workflowów dla product managerów. Zaczyna się od jednego podłączonego narzędzia.

Prompty stosowane przez Franka Lee (i kiedy je używać)

Poniższe prompty i struktury zostały odtworzone na podstawie demo i opisów Lee z tego odcinka. Część z nich to wywołania Skillów, część to komendy wpisywane bezpośrednio w Claude Code lub Cursorze. Prompty do Skillów Lee opisuje na poziomie struktury i heurystyk, nie są więc dosłownymi kopiami jego plików.

Analiza anomalii w wykresie

Kiedy używać: gdy zauważasz nieoczekiwaną zmianę w metryce i chcesz szybko zrozumieć jej przyczynę bez ręcznego tworzenia dziesiątek wykresów.

Struktura Skilla:

Przeanalizuj ten wykres. Szukaj skoków, sezonowości i anomalii.
Sprawdź powiązane wykresy i właściwości.
Sięgnij po dane z feedbacku, releases i annotations.
Odpowiedz w formacie:
1. Co się wydarzyło i kiedy
2. Główna hipoteza
3. Możliwe wyjaśnienia
4. Dowody
5. Co to oznacza dla biznesu

Analiza dashboardu (raport tygodniowy)

Kiedy używać: przed tygodniowym spotkaniem, zamiast ręcznego przeglądania wszystkich dashboardów.

Struktura Skilla:

Pobierz wykresy z tego dashboardu po trzy naraz.
Dla wykresów KPI szukaj procentowych zmian.
Dla wykresów słupkowych szukaj koncentracji i luk.
Po analizie sprawdź powiązane dane feedbackowe.
Podsumuj 3-5 najważniejszych insightów i wskaż jeden pilny problem.

Analiza feedbacku klientów

Kiedy używać: regularnie (np. w poniedziałek rano) lub przed planowaniem sprintu, gdy chcesz zebrać perspektywę użytkowników dotyczącą konkretnego obszaru produktu.

Prompt:

Pobierz feedback dotyczący [nazwa obszaru, np. agents, MCP].
Przygotuj TL;DR z: pilnymi problemami, bugami
oraz jedną najważniejszą rzeczą, którą użytkownicy chwalą w tym tygodniu.

Konwersja feedbacku lub insightów w drafty PRD

Kiedy używać: gdy dysponujesz już analizą feedbacku lub insightami z wykresów i chcesz przejść bezpośrednio do specyfikacji.

Prompt:

Przekształć te rekomendacje w specyfikacje
i umieść je w folderze [nazwa folderu, np. agents].

Dla lepszych wyników: przed wywołaniem komendy wskaż szablon PRD przez @, aby agent wiedział, jakiego formatu użyć.

Draft PRD z szablonu

Kiedy używać: przy tworzeniu nowej specyfikacji od podstaw, gdy kontekst problemu jest już dostępny w repozytorium lub bieżącej sesji.

Prompt:

Przygotuj PRD korzystając z @[nazwa szablonu PRD].
Skoncentruj się na [temat lub problem].
Użyj kontekstu z @[plik z planem lub inicjatywą].

Transfer kontekstu przy przepełnieniu okna

Kiedy używać: gdy kontekst sesji zbliża się do 90% i istnieje ryzyko, że compact zawiedzie lub agent straci ważny wątek.

Prompt:

Zapisz do pliku markdown: swój proces, postęp pracy
oraz to, co pozostało do zrobienia.

Zapisz ten plik w repozytorium. W nowej sesji wczytaj go przez @ jako punkt startowy.

Import notatek ze spotkań

Kiedy używać: po serii spotkań, gdy chcesz mieć notatki z Granoli lub innego narzędzia bez własnego MCP dostępne w kontekście agenta.

Prompt:

Pobierz moje ostatnie notatki z Granoli
korzystając ze skryptu [nazwa skryptu].

Wymaga wcześniejszego przygotowania skryptu importującego w Claude Code, co Lee opisuje jako zadanie jednorazowe.

Podsumowanie

Pełna pętla workflow wygląda następująco: anomalia w danych, analiza wykresu przez agenta, automatyczny raport tygodniowy, synteza feedbacku klientów, konwersja insightów w PRD, routing do Lineara lub prototypowanie w kodzie. Każdy z tych kroków, który wcześniej zajmował godziny, trwa dziś kilka minut.

Najważniejsza zmiana nie jest techniczna. To zmiana w tym, od czego product manager zaczyna każdy tydzień: nie od przeglądania danych, lecz od podejmowania decyzji.

Kluczowy insight

Zaawansowany workflow AI kończy się DM-em

Standardowo myślimy: im bardziej zaawansowany workflow AI, tym więcej formalnego procesu: automatyczne tickety, PRD-y w Jirze, sprinty, dokumentacja. Narzędzia agentyczne mają dodawać kolejne warstwy do istniejącej machiny produktowej.

W praktyce okazuje się, że: Lee coraz częściej pomija Lineara i cały aparat ticketowy. Jego najbardziej rozbudowany workflow, oparty na Claude Code, MCP, Amplitude i GitHubie, kończy się wiadomością bezpośrednią do konkretnego inżyniera na Slacku. Jeden krok, bez pośredników.

Dlaczego to jest istotne: AI nie dokłada warstw do procesu, lecz je odejmuje. Im lepszy kontekst jest dostępny w systemie, tym mniej formalnego procesu potrzeba, by przekazać właściwą informację właściwej osobie we właściwym momencie. Cały aparat ticketowy był substytutem braku dobrego kontekstu, nie wartością samą w sobie.

Test na jutro: Następnym razem, gdy zakończysz analizę lub masz gotowy insight, zamiast otwierać Jirę i tworzyć ticket, napisz bezpośrednio do inżyniera lub PM-a na Slacku z jednym zdaniem kontekstu i jednym konkretnym pytaniem. Sprawdź, czy w tej wymianie czegokolwiek brakowało w porównaniu z formalnym ticketem.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: The Claude Code Analytics Workflow Top AI PMs Don’t Want You to Know, podcast Akash G / Build.

Tag: Analiza Danych Product Manager

Claude Code + MCP: jak product managerowie automatyzują analizę, raporty i PRD-y #EN380