TL;DR

Software ewoluuje: Przechodzimy od pisania kodu do „programowania w języku angielskim” przez prompty
AI produkty są probabilistyczne: W przeciwieństwie do deterministycznych produktów tradycyjnych wymagają innego podejścia
Dekompozycja jest kluczowa: Każdy złożony agent AI trzeba rozbić na mniejsze komponenty z oceną ryzyka
Nowe zespoły wymagają uwagi: Data engineers i legal team muszą być zaangażowani na początku procesu
Zawężanie zakresu przyspiesza sukces: MVP powinno skupiać się na konkretnym przypadku użycia zamiast uniwersalnego rozwiązania
Ekspercka wiedza domenowa: Szczególnie przy agentach wertykalnych jest niezbędna do właściwej ewaluacji
Myślenie poza automatyzacją: Inwestorzy szukają rozwiązań powiększających „tort” możliwości

Niniejszy artykuł stanowi zbiór notatek z webinaru prowadzonego przez doświadczonego praktyka AI, który pracował przy budowie agentów, frameworków i modeli w różnych fazach ewolucji oprogramowania. Wszystkie przedstawione przemyślenia, obserwacje i strategie pochodzą bezpośrednio od prowadzącego.

Nowa era oprogramowania wymaga nowego podejścia

Prowadzący rozpoczął prezentację od cytowania Andrew Karpathy’ego z OpenAI i Tesli. Według tej analizy najpierw pisaliśmy kod, następnie sieci neuronowe z pozytywnymi i negatywnymi przykładami, a obecnie programujemy w języku angielskim. Ta ewolucja oznacza fundamentalną zmianę w sposobie interakcji z maszynami.

Jeśli produkty stają się „Software 3.0”, gdzie komunikujemy się z maszynami przez prompty, Product Managerowie muszą w związku z tym dostosować swoje podejście do tej nowej rzeczywistości.

Kluczowe różnice między tradycyjnym PM a AI PM

Probabilistyczny charakter produktów

Według prowadzącego najważniejsza różnica to przejście od deterministycznych do probabilistycznych produktów. W systemach AI nie ma jednej poprawnej odpowiedzi, dlatego system może dawać różne wyniki przy tych samych danych wejściowych.

Produkty AI wymagają znacznie więcej iteracji i są bardziej hands-on dla PM-a. Zamiast pisać szczegółowe specyfikacje na początku, zaczynasz od jednej czy dwóch stron, a następnie walidują się kluczowe hipotezy. Kluczowa jest pętla: wdrożenie plus obserwacja w produkcji, która resetuje oczekiwania w górę lub w dół i wskazuje kierunek dalszego rozwoju.

Specyfika produktów agentowych

Prowadzący wyróżnił trzy kluczowe cechy produktów agentowych:

Przetwarzanie nieustrukturyzowanych danych
Złożone podejmowanie decyzji
Ewoluujące wymagania – reguły nie są ustalone raz na zawsze

Agenty mają narzędzia (tools), planner i pamięć (memory). Użytkownicy mogą nagle zmienić sposób korzystania z produktu, jednak im więcej swobody dajesz użytkownikom, tym większy sukces osiągniesz z produktami agentowymi.

Ważną decyzją na tym etapie jest wybór między systemem multi-agentowym a single-agentowym. To zależy od tego, na ile komponentów rozbijesz problem.

Cztery filary odpowiedzialności AI Product Managera

Jak podkreślił prowadzący, to właśnie te obszary są oceniane podczas wywiadów na pozycje AIPM. Pierwsze pytanie to zawsze „Dlaczego ty? Dlaczego teraz?” – czy rozumiesz przestrzeń AI. Drugie to „Jak?” – jak przeszedłeś od pomysłu do wykonania i jak ustaliłeś roadmapę.

Identyfikacja problemów i roadmapa

Pierwszym krokiem jest zawsze dekompozycja. Jak podkreślił prowadzący: „Każdy problem w AI nie przyjdzie jako prosty agent”. Musisz w związku z tym rozbić go na mniejsze komponenty.

Następnie tworzysz ocenę ryzyka. Jakie rodzaje ryzyk występują w AI?

Halucynacje – model generuje nieprawdziwe informacje
Problemy z pamięcią – niespójność w dłuższych interakcjach
Dokładność – nieprecyzyjne wyniki
Powtarzalność – różne odpowiedzi na te same zapytania
Kwestie prawne – zgodność z regulacjami
Bias – stronniczość w decyzjach modelu
Transparentność – brak możliwości wyjaśnienia decyzji

Każdy komponent profilujesz według poziomu ryzyka: niski, średni, wysoki. Prowadzący wspomniał, że w szczegółowej dokumentacji znajduje się około 12-15 typów ryzyka jako szablon do wykorzystania w analizie.

Zawężanie zakresu dla sukcesu

Według prowadzącego jeśli budujesz bardzo ogólne rozwiązanie, trudno osiągnąć wysoką dokładność i szybko iterować. Musisz zawęzić zakres.

W przykładzie z umowami zamiast obsługiwać wszystkie typy kontraktów, MVP skupia się tylko na master service agreements i integracji z HubSpot. Dlaczego? Klienci są gotowi za to płacić, waliduje to kilka założeń o niskim ryzyku, a także pozwala na iteracje z danymi od klientów.

Umiejętności techniczne i ograniczenia

Prowadzący jasno stwierdził: musisz być techniczny. Potrzebujesz podstawowej wiedzy o tym, jak działają modele i jak uczą się sieci neuronowe. Równie ważne jest jednak zrozumienie ograniczeń – to obszar, który większość ludzi pomija podczas rozmów kwalifikacyjnych.

Ekspercka wiedza domenowa dla agentów wertykalnych

Jeśli budujesz agenty dla konkretnych branż, wiedza domenowa jest niezbędna. Bez niej nie ustalisz właściwych ewaluacji, nie skonfigurujesz human-in-the-loop feedback i nie ustawisz odpowiednich oczekiwań. Pomaga też znaleźć return on investment oraz zidentyfikować problemy, które wcześniej nie były rozwiązywalne z AI.

Jak zauważył prowadzący, musisz myśleć poza automatyzacją. Rozmawiał z inwestorem z 76 VC, który powiedział: „W zeszłym roku inwestowaliśmy w automatyzację. W tym roku szukamy firm używających AI do powiększania tortu możliwości”.

Praktyczny framework: studium przypadku agenta kontraktowego

Dekompozycja problemu

Prowadzący przedstawił konkretny przykład: agent analizujący ryzyko w kontraktach. Na pierwszy rzut oka wygląda na prosty problem – dajesz kontrakt, dostajesz analizę ryzyka. W rzeczywistości to jednak kilka problemów:

Email processing – klasyfikatory rozpoznające kontrakty w emailach
Ekstrakcja dokumentów – czytanie PDF, podział na klauzule i sekcje
Analiza – wyciąganie kluczowych terminów, znajdowanie wartości i cytowań
Ranking i prezentacja – uporządkowanie ryzyk według ważności

Profilowanie ryzyka komponentów

Każdy komponent oceniasz według poziomu ryzyka:

Email processing: średnie ryzyko (rozwiązanie wielokrotnie implementowane)
Retrieval: niskie ryzyko (konwersja PDF na tekst działa skutecznie)
Analiza kluczowych terminów: wysokie ryzyko
Znajdowanie i ranking ryzyk: bardzo wysokie ryzyko

Roadmapa MVP do pełnego produktu

Etap 1 (MVP): Tylko master service agreements, tylko ekstrakcja kluczowych terminów do HubSpot. Klienci gotowi płacić, waliduje założenia o niskim ryzyku.

Etap 2: Automatyczne znajdowanie ryzyk, jednak użytkownik musi dostarczyć playbook reguł. Wciąż zawężone ryzyko, ale już dostarczasz wartość.

Etap 3: Pełny agent zachowujący się jak prawnik – komentuje dokumenty, sugeruje zmiany, automatycznie znajduje wszystkie ryzyka.

Etap 4: Q&A, raporty, alerty oraz zaawansowane funkcje na bazie zgromadzonych danych.

Współpraca z nowymi zespołami w erze AI

Kluczowa zasada: legal i data na początku

Największy takeaway prowadzącego: wymagania data engineering i legal muszą być na początku procesu. Ludzie robią to za późno, w konsekwencji opóźnia to program o 3-4 miesiące.

Zespoły legal nie czekają bezczynnie. Potrzebują czasu na sprawdzenie compliance i mogą zażądać certyfikacji. Jak tylko napiszesz dwustronicowy brief, pracuj z legal.

Podobnie z zespołami data – zdobycie właściwych danych do ewaluacji to nie jest łatwe zadanie i zajmuje 2-3 miesiące.

Konkretny przykład wymagań

Jak pokazał prowadzący na przykładzie: „Potrzebuję 10,000 labelowanych kontraktów jako data foundation”. Następnie określasz compliance: „Te konkretne regulacje muszą być spełnione”. Potem performance criteria: „Oczekuję 90% dokładności w identyfikacji ryzyk” z konkretnymi scores dla helpfulness, honesty i harmlessness.

Harmonogram zaangażowania zespołów

PRIORYTET 1 – Na początku projektu:

Legal team – compliance, certyfikacje, wymagania prawne
Data engineers – jakość danych, źródła danych do ewaluacji

PRIORYTET 2 – Po ustaleniu wymagań:

Data scientists – metryki sukcesu, dashboardy, monitoring
Researchers – konkretne cele badawcze i metryki

Oczekiwania poszczególnych zespołów

Data scientists oczekują jasno zdefiniowanych metryk sukcesu. North Star metryki, metryki latencji, ROI – oni znajdą te wartości w danych i stworzą dashboardy. Jeśli budujesz system multi-agentowy, pomogą Ci w rezultacie debugować, który komponent zawodzi najbardziej.

Data engineers dbają o jakość danych i dostarczają dane do ewaluacji. Nawet jeśli nie trenujesz modeli, potrzebujesz danych do ewaluacji. Zapewniają też, że dane nie wyciekają i spełniają wymagania compliance.

Researchers wymagają konkretnych celów. Nie mów „popraw ten model”. Musisz być bardzo konkretny: „Helpfulness zawodzi. Nasz model nie odpowiada zwięźle na pytania. Nasz ROUGE score to X, chcemy Y. Oto evaluation set.”

Jak podkreślił prowadzący z doświadczenia: jeśli nie ustawisz twardych wymagań (dokładność dziś 68%, chcemy 78% według konkretnych metryk precision/recall), researchers będą pracować 2-3 miesiące bez rezultatów odpowiadających oczekiwaniom klientów.

Kluczowe jest przekazanie customer experience w języku, który zespoły techniczne rozumieją. Czasami wystarczy powiedzieć „accuracy”, czasami musisz rozbić to na precision/recall, a czasami potrzebujesz BLEU czy ROUGE scores.

Praktyczne next steps

Ścieżka do zostania AI Product Managerem

Techniczne podstawy

Zrozum podstawy działania modeli ML
Poznaj główne ograniczenia AI (halucynacje, bias, transparentność)
Naucz się metryk technicznych (precision, recall, BLEU, ROUGE scores)

Responsible AI

Opanuj zasady implementacji guardrails
Zrozum wymagania transparentności algorytmów
Poznaj główne typy bias w systemach AI

Strategia cenowa

Zrozum ekonomię produktów AI (koszty inference, treningu)
Naucz się kalkulować ROI dla rozwiązań AI

Wiedza domenowa

Wybierz branżę/domenę specjalizacji (szczególnie dla agentów wertykalnych)
Zrozum specificzne przypadki użycia AI w tej branży

Jak zauważył prowadzący: „Jeśli zrobisz to wszystko, będziesz mógł bardzo szybko nauczyć się wszystkich konceptów potrzebnych do zostania AI PM”.

Kluczowy takeaway z całego procesu: musisz „wszystko trzymać na smyczy, zamiast wszystko pozostawiać luźne i nigdy nie wysłać”. Produkty AI wymagają jasnych ram i ograniczeń, żeby faktycznie dotrzeć do produkcji.

Kluczowy insight

Wąski zakres = szybsze przychody

Standardowo myślimy: Żeby osiągnąć sukces z produktem AI, musimy zbudować uniwersalne rozwiązanie, które obsłuży jak najwięcej przypadków użycia i dotrze do szerokiej grupy klientów.

W praktyce okazuje się, że: Zawężenie zakresu do bardzo konkretnego problemu zwiększa dokładność rozwiązania, przyspiesza iteracje z klientami oraz skraca czas do pierwszych przychodów. Im bardziej zawęzisz, tym szybciej zaczniesz zarabiać.

Dlaczego to jest istotne: Produkty AI są na tyle złożone, że próba rozwiązania wszystkiego na raz prowadzi do niskiej dokładności i długich cykli rozwoju. Zawężenie pozwala na szybkie uczenie się od prawdziwych użytkowników i budowanie na tym fundamencie.

Test na jutro: Następnym razem gdy planujesz produkt AI, zamiast zastanawiać się „jak obsłużyć wszystkie możliwe scenariusze” spróbuj zidentyfikować jeden bardzo konkretny przypadek użycia, za który klienci są gotowi płacić już dziś, i sprawdź jak szybko możesz dostarczyć działające rozwiązanie.

Ten wpis jest częścią kolekcji notatek z ciekawych webinarów i prezentacji, które stanowią wartościowy materiał referencyjny. Oryginalny materiał źródłowy znajdziesz tutaj: https://www.youtube.com/watch?v=JeFNpGbvxKI

Tag: Dekompozycja Problemow Ai

Jak przejść z Product Managera na AI Product Makera #EN165