Jak zostać AI Product Managerem w 2 godziny – praktyczny przewodnik #EN147

TL;DR

• AI PM to ewolucja tradycyjnej roli – każdy PM stanie się „jakimś wariantem AI PM” w najbliższych latach
• 5 kluczowych umiejętności: prototypowanie (Cursor), obserwowalność, oceny, różnice RAG/fine-tuning/prompt engineering, współpraca z inżynierami AI
• Cursor > Bolt/Lovable dla zaawansowanego prototypowania – więcej kontroli, możliwość iteracji na konkretnych komponentach
• Oceny to nowe wymagania produktowe – PM powinien pisać oceny zamiast tradycyjnych PRD
• Prompt engineering ma najwyższy ROI – mały wysiłek, duży wpływ na jakość systemu
• Rynek pracy istnieje – ponad 1000 ofert „Product Manager, AI” tylko w NYC
• 2 godziny tygodniowo wystarczą – wypróbuj narzędzia, zrozum architekturę, buduj projekty poboczne

Definicja AI Product Managera według Khan

Aman Khan definiuje AI PM jako dwa główne typy ról. Pierwszy to AI-powered PM – osoba używająca AI w codziennej pracy do analizy, badań i automatyzacji workflow. Drugi to AI Product PM – manager budujący produkty z wbudowanymi funkcjami AI.

Khan podkreśla jednak, że AI to „akcelerator na istniejących przepływach pracy, które już masz” – nie zabiera pracy, lecz wzmacnia istniejące umiejętności.

Konkretne przykłady z różnych branż przedstawione przez Khan:

• Experimentation PM – używa LLM do konwersji różnych template PRD na jasne outputy (hypothesis, North Star metric, guardrail metrics)
• Financial industries – budowanie nowych modeli kredytowych opartych na AI
• Internal tools PM – standaryzacja procesów przez AI nawet w bardzo regulowanych branżach

Kluczowa obserwacja rynkowa Khan: Podczas gdy firmy zwalniają całe zespoły PM, zespoły AI PM rzadko podlegają redukcjom. Dlatego to strategiczna inwestycja w przyszłość kariery.

5 kluczowych umiejętności AI Product Managera

1. AI Prototyping – opanowanie Cursor

Khan rekomenduje Cursor jako podstawowe narzędzie prototypowania mimo alternatyw. Cursor to fork VS Code z wbudowanym agentem AI, który pozwala na precyzyjną iterację konkretnych komponentów kodu.

Konkretne komendy Cursor według Khan:

• Command T – otwiera terminal (można pisać instrukcje w języku naturalnym)
• Command L – uruchamia agenta do pisania kodu
• Claude 4 Sonnet – model rekomendowany przez Khan jako „ogromne ulepszenie”

Porównanie narzędzi prototypowania:

• Bolt/Lovable – łatwe wdrożenie, dobre na szybkie i proste prototypy
• Replit – potężne dla aplikacji Python z wbudowanymi agentami
• Vercel V0 – mocne w front-endzie
• Cursor – najlepsza kontrola i elastyczność dla iteracji

W praktycznym demo Khan buduje Trip Planner Agent używając LangGraph zamiast CrewAI, pokazując elastyczność w wyborze frameworków. Agent tworzy katalogi, instaluje pakiety, pisze kod Python i React, a nawet sam naprawia błędy.

Ważne ograniczenie wskazane przez Khan: Cursor świetnie sprawdza się w projektach od zera do pierwszej wersji, jednak nie warto używać go od razu w produkcyjnym kodzie z wieloma zależnościami.

Kluczowa umiejętność to komfort z faktem, że rzeczy się psują. Khan podkreśla: „Nie bój się, że coś się zepsuje. Ważne jest, jak współpracujesz z agentem przy naprawianiu problemów.”

2. Observability – widzenie agentów w akcji

Khan pokazuje jak tracing ujawnia rzeczywistą architekturę systemów AI używając Arise – firmy, którą współtworzy jako Director of Product. Na przykładzie Trip Planner widać graf z trzema agentami działającymi równolegle: research specialist, budget advisor i local curator.

Arise obsługuje czołowe firmy AI:

• Uber, Reddit, Instacart, Duolingo i inne top-tier firmy
• Wszystkie używają evalów do skalowania feedback na systemach AI
• To pokazuje zatem, jak ważne są te umiejętności w praktyce

Observability kończy zgadywanie i pozwala zobaczyć:

• Jakie agenty działają w systemie i jak się komunikują
• Ile czasu zajmuje każda operacja (optymalizacja wydajności)
• Jakie prompty dostaje każdy agent (wykrywanie błędów w promptach)
• Które narzędzia/API są wywoływane

Ważny wniosek Khan: Nawet proste systemy agentów wyglądają skomplikowanie wizualnie. To jednak normalne dla systemów agentów na poziomie MVP – nie oczekuj prostoty na początku.

3. Oceny – nowe wymagania produktowe

Khan ma radykalną propozycję: „A co gdyby oceny były twoimi wymaganiami zamiast tradycyjnego PRD?” Zamiast pisać dokumenty, PM dostarcza zbiór danych z etykietami „dobre/złe” i mówi zespołowi: „Poprawcie ten wynik.”

Od „vibe coding” do „three drive coding”: Khan żartuje, że większość pracy z AI to „vibe coding” – oceniasz na czucie czy rezultat jest dobry. Oceny pozwalają jednak przejść do „three drive coding” – podejmowania decyzji na podstawie danych.

Trzy typy ocen:

• Etykiety ludzkie – PM osobiście ocenia rezultaty jako dobre/złe
• Oceny oparte na kodzie – automatyczne sprawdzanie (np. czy wspomina konkurencję)
• LLM jako sędzia – jeden model ocenia jakość drugiego

Praktyczny przykład Khan: Eval sprawdzający „przyjazny ton” vs „robotyczny ton”. Jego oceny ludzkie kompletnie nie zgadzały się z oceną LLM (0% zgodności!) – to pokazało, że LLM jako sędzia potrzebował poprawy.

Wskazówka od Khan: Używaj opisów tekstowych zamiast etykiet liczbowych. LLM są nadal słabe w rozumieniu liczb, ale potrafią rozróżniać „dobry/świetny/doskonały” lepiej niż „1/2/3”.

Wkrótce dostępne: Khan wspomina, że Arise pracuje nad automatyczną optymalizacją promptów na podstawie ocen ludzkich. „Do czasu gdy to oglądasz, będziemy mieli przycisk, który mówi: weź oceny ludzkie i zoptymalizuj swoje prompty.” To pokazuje kierunek rozwoju narzędzi oceniających.

4. RAG vs Fine-tuning vs Prompt Engineering

Khan przedstawia hierarchię wpływu i wysiłku dla trzech kluczowych technik:

Technika	Wysiłek	Wpływ	Kiedy używać
Prompt Engineering	Bardzo niski	Bardzo wysoki	Dostrajanie tonu, instrukcji
RAG	Średni	Wysoki	Dostęp do konkretnych danych
Fine-tuning	Wysoki	Zależny	Specjalizacja, redukcja kosztów

Khan używa praktycznych analogii: prompt engineering to jasne instrukcje dla pracownika, RAG to dostęp do podręcznika, fine-tuning to przejście od studiów do specjalizacji zawodowej.

Kontrowersyjny wniosek Khan: „Halucynacje to funkcja, nie błąd” – halucynacje to właśnie generalizacyjna siła modeli. Gdy robisz fine-tuning, możesz stracić tę kreatywność, więc zastanów się czy tego chcesz.

5. Współpraca z AI Engineers

Według Khan oczekiwania wobec AI PM-ów się zmieniają. Inżynierowie AI czują frustrację z powodu PM-ów wysyłających Google Docs z PRD i mówiącymi „idź to zaimplementuj”. Oni chcą natomiast kogoś, kto rozumie system jako całość.

Nowe oczekiwania:

• Być w danych – personalnie oznaczać przykłady jako dobre/złe
• Rozumieć architekturę – wiedzieć, jakie agenty działają i dlaczego
• Używać tych samych narzędzi co zespół techniczny
• Komunikować się przez oceny zamiast dokumenty

Khan podkreśla: „Inżynierowie AI chcą kogoś, kto spojrzy na system jako całość i powie: to jest poprawne, to nie.”

Dodatkowy kontekst: Pamiętaj, że inżynierowie AI też się uczą. Sposób pracy z AI zmienia się dla wszystkich, więc to świetna okazja na zbudowanie wspólnego języka i procesów.

Najczęstsze błędy początkujących AI PM

❌ Błąd #1: Brak projektów pobocznych

„W rozmowach rekrutacyjnych pytam: co budujesz poza pracą?” To natychmiastowy interview hack – Khan od razu widzi poziom zaangażowania i ciekawości.

Prawdziwa historia sukcesu: Khan chwali Claire Vo i jej ChatPRD jako przykład konsekwentnej pracy. Dwa lata temu Khan testował wczesną wersję i myślał „to nie jest lepsze od ChatGPT”. Claire iterowała jednak każdy weekend, ucząc się stosu technologicznego. Gdy modele się poprawiły, jej produkt był gotowy na wykorzystanie ulepszeń.

❌ Błąd #2: Czekanie na lepsze modele

„Jeśli czekasz, aż modele się poprawią, zostaniesz w tyle.” Lepiej zacząć budować teraz z gorszymi modelami, żeby mieć gotową architekturę na przyszłe ulepszenia.

❌ Błąd #3: Nadmierna automatyzacja

Khan ostrzega przed próbami zautomatyzowania całej pracy od razu. Zamiast tego rekomenduje używanie AI jako „drugiego mózgu” do analizy i badań.

Przykładowe prompty Khan używa z reasoning models:

• „Daj mi 5 alternatywnych rozwiązań i uszereguj według ryzyka”
• „Symuluj pytania followup od klienta w branży, której nie znam”

O reasoning models: Khan wyjaśnia, że modele jak O3 czy Claude 4 „działają dłużej i myślą” o odpowiedzi zamiast od razu generować tekst. To pozwala na bardziej przemyślane analizy.

Konkretny przykład eksploracji: „Ten tydzień dla mnie to będzie VEO3, bo właśnie wyszedł. Chcę zrozumieć – jak dobre to jest naprawdę? Czy mogę zbudować coś wokół tego?”

Ekspresowa ścieżka: 2 godziny tygodniowo

Khan proponuje trzystopniowy plan dla zabieganych:

🎯 Krok 1: Wypróbuj narzędzia osobiście

Nie dla firmy, lecz dla własnych potrzeb. Khan budował generator bajek AI dla dziecka – przez to zrozumiał ograniczenia technologii.

🔍 Krok 2: Rozłóż produkty AI na czynniki pierwsze

Gdy widzisz „magiczny” produkt, spróbuj zrozumieć jak działa. Khan pokazał, że Bolt to głównie dobry prompt + renderowanie kodu.

🛠️ Krok 3: Zbuduj coś własnego

Mały projekt poboczny, który możesz rozwijać i testować nowe technologie.

Architektura produktów AI na przykładzie Bolt

Khan rozkłada Bolt na czynniki pierwsze, analizując rzeczywisty kod z GitHub. „Myślałem, że to będzie bardzo skomplikowane, ale zaskoczyło mnie jak prostą architekturę ma Bolt.”

Co znalazł Khan w kodzie Bolt:

• Prompt systemowy – „Jesteś Bolt, ekspert asystent AI i wyjątkowy senior software developer”
• Kontekst i ograniczenia – „działasz w środowisku zwanym kontener sieciowy”
• Niejawne wywoływanie narzędzi – narzędzia opisane w prompcie, nie wywoływane zewnętrznie
• Przykłady nielicznych prób – pokazują jak ma wyglądać dobry rezultat
• Priorytety – „ULTRA WAŻNE: Nie bądź rozwlekły”

Khan zauważa lukę: Bolt nie używa evalów w czasie rzeczywistym. To okazja do ulepszenia – system mógłby sprawdzać poprawność kodu przed pokazaniem użytkownikowi. „Bolt może się zepsuć bo robi błędy w kodzie. Mógłbyś mieć eval, który sprawdza: czy kod jest poprawny czy nie?”

Insight dla AI PM: Nawet „magiczne” produkty mają prostą architekturę. Potęga tkwi w dobrym prompt engineeringu, nie w skomplikowanych systemach.

Rynek pracy dla AI PM – fakty vs mity

Khan odpowiada na krytykę „gdzie są te joby AI PM?”. Przyznaje, że rekruterzy używają częściej „Product Manager, AI” zamiast dokładnej frazy „AI PM”.

Kluczowe obserwacje:

• AI PM teams są odporne na zwolnienia podczas redukcji
• Firmy inwestują strategicznie w AI PM headcount na przyszłość
• To nie „albo AI PM albo bust” – to przecięcie z istniejącymi specjalizacjami
• Konkretne liczby: Ponad 1000 ofert „Product Manager, AI” tylko w NYC

Analogia do surfingu Khan: „Jesteśmy trochę przed krzywą i to jest to miejsce, gdzie chcesz być z perspektywy technologicznej – przed falą. Gdy fala naprawdę przyjdzie, będziesz mógł na niej jechać. Nie chcesz być za falą – ją przegapisz.”

Model myślowy dla rynku: Pomyśl ile jest dziś stanowisk PM w Twoim mieście. Teraz pomyśl jaki będzie ten stosunek za 3 lata. Jaka część ról PM będzie wymagała umiejętności AI? Tu leży okazja.

📋 Praktyczne checklisty (na podstawie zaleceń Khan)

✅ AI PM – Ocena umiejętności

Oceń swój poziom (1-5) w każdej kategorii:

Prototyping:

• Potrafię używać Cursor do budowania prostych aplikacji
• Czuję się komfortowo z debugowaniem błędów w kodzie
• Umiem iterować na konkretnych komponentach

Obserwowalnść i oceny:

• Potrafię czytać grafy śledzenia agentów
• Umiem napisać podstawową ocenę (etykieta ludzka)
• Potrafię A/B testować różne prompty

Współpraca techniczna:

• Komunikuję się z zespołem przez dane, nie domysły
• Aktywnie oznaczam dane jako dobre/złe
• Używam tych samych narzędzi co programiści

✅ Plan rozwoju 2h/tydzień (według Khan)

Tydzień 1-4: Eksploracja i analiza

• Wypróbuj 3 narzędzia prototypowania
• Wybierz 2 „magiczne” produkty AI do analizy
• Spróbuj odtworzyć podstawową funkcjonalność

Tydzień 5-12: Budowanie i optymalizacja

• Zbuduj MVP rozwiązania osobistego problemu
• Dodaj observability do swojego projektu
• A/B testuj różne podejścia

Podsumowanie

Według Khan AI Product Management to nie rewolucja, ale ewolucja tradycyjnej roli PM. Kluczowe umiejętności to praktyczne prototypowanie, zrozumienie architektury systemów AI i umiejętność mierzenia ich jakości.

Najważniejsza rada Khan: „Nie czekaj na doskonałe narzędzia. Zacznij budować teraz, żeby być gotowym gdy technologia się poprawi.”

Kluczowy wniosek

Oceny zamiast PRD

Standardowo myślimy: PM pisze szczegółowy PRD opisujący co ma zrobić zespół, a potem engineers to implementują według specyfikacji z dokumentu.

W praktyce okazuje się, że: Według Khan znacznie skuteczniejsze jest dostarczenie zespołowi zbioru danych z przykładami oznaczonymi jako „dobre/złe” i powiedzenie „poprawcie ten wynik oceny”. Zamiast 20-stronnicowego PRD dajesz konkretną metrykę do zbicia.

Dlaczego to jest istotne: Programiści wiedzą wtedy dokładnie co mają optymalizować i mogą podejmować techniczne decyzje samodzielnie. PM przestaje być wąskim gardłem w szczegółach implementacji, a skupia się na definiowaniu mierników sukcesu.

Test na jutro: Następnym razem gdy planujesz nową funkcję AI, zamiast pisać tradycyjny PRD spróbuj stworzyć 10-15 przykładów „idealnego rezultatu” z etykietami i daj zespołowi zadanie „osiągnij 90% wyniku na tym zbiorze danych” i sprawdź jak zmieni się dynamika współpracy i szybkość iteracji.

---

Ten wpis to moje notatki z podcastu z Aman Khan. Wszystkie przemyślenia, analizy i rekomendacje pochodzą od niego – ja jedynie uporządkowałem i przetłumaczyłem jego słowa na język polski. Jeśli chcesz sprawdzić oryginalne źródło, pełny transkrypt znajdziesz w załączonym materiale.