TL;DR

Product managerowie powinni aktywnie uczestniczyć w labelowaniu danych – jako domain experci mają najlepsze kompetencje do definiowania jakości produktu
Role w AI development się rozmywają – zamiast sztywnych podziałów potrzebne są nakładające się umiejętności i współpraca
Trzy kluczowe pytania dla każdego zespołu AI: ile labeli wystarczy, co robić przy rozbieżnościach eval vs feedback, jak reagować na spadek business metrics
Korelacja między eval metrics a wynikami biznesowymi jest kluczowa – bez tego evals są bezwartościowe
Skuteczne zespoły AI mają technical PM z inżynierskim backgroundem i dobrze zdefiniowany scope produktu
Inżynierowie powinni rozwijać product thinking poprzez bezpośredni kontakt z klientami
Potrzebny jest „benevolent dictator” do rozstrzygania konfliktów między evalami a human feedback

Trzy fazy rozwoju produktów AI

Aman, współpracując z takimi firmami jak Reddit, Roblox czy Booking.com, obserwuje charakterystyczny wzorzec ewolucji produktów AI:

Faza 0-1: „Vibe coding” – budowanie w weekend z Crewai czy Langgraph, szybkie „looks good to me” i ship. Jednak to działa tylko dla internal tools, gdzie nie martwisz się o brand reputation czy regulatory compliance. Mimo to nie jest realistyczne dla enterprise.

Faza 2: „Czy ufamy evalowi?” – zespół pisze pierwsze evals, ale pojawia się pytanie o ich wiarygodność. Ludzie często pytają o gotowe rozwiązania do toxicity czy hallucination detection – „czy macie gotowe evaluacje?”

Faza 3: Production-ready system – evals działają zarówno w development jak i production. Dlatego zespół mówi „tym samym językiem” i ma procesy na rozwiązywanie konfliktów.

Rozmywanie granic między rolami w AI

Tradycyjny podział na product management, engineering i design odchodzi do przeszłości. Jak zauważa Aman, współczesne role w AI development coraz bardziej się nakładają. Zamiast myśleć kategoriami „kto za co odpowiada”, zespoły powinny skupić się na umiejętnościach i obszarach ekspertyzy.

Aman opisuje tę zmianę używając analogii do kart baseballowych. Podobnie jak pitcher czasem musi odbijać, członkowie zespołu AI muszą być gotowi do wykonywania zadań poza swoją podstawową specjalizacją.

Ewolucja roli AI product managera

Według Amana istnieją trzy główne typy AI product managerów:

Core product PM – skupia się na tym, jak zapakować technologię AI w produkt końcowy. Myśli o form factorze i doświadczeniu użytkownika
Platform builders – koncentruje się na infrastrukturze, kosztach, niezawodności i wyborze odpowiednich modeli dla aplikacji
AI-powered PM – wykorzystuje AI w swojej codziennej pracy, zajmuje się promptingiem i prototypowaniem

Te role nie wykluczają się wzajemnie. Współczesny AI PM musi posiadać kompetencje we wszystkich trzech obszarach.

Jak zauważa Aman, podczas niedawnego AI Eng World Fair ludzie byli zaskoczeni, słysząc że PMs „piszą kod, piszą labele, piszą evals”. To pokazuje jednak, jak szybko ewoluują oczekiwania wobec tej roli.

Problem z labelowaniem – wszyscy uciekają od odpowiedzialności

Hamel Husain trafnie określa zjawisko unikania labelowania jako „przekazywanie labelowania jak gorącego ziemniaka”. Każdy chce przerzucić tę odpowiedzialność na kogoś innego.

Mimo to Aman argumentuje, że product managerowie są naturalnymi kandydatami do labelowania. Ponieważ mają najgłębszą wiedzę domenową, są odpowiedzialni za końcowe doświadczenie użytkownika i rozumieją, co oznacza „dobra jakość” w kontekście biznesowym.

Jak podkreśla Hamel, im bliżej ekspertów dziedzinowych umieścimy proces labelowania, tym lepsze będą rezultaty.

Współpraca przy tworzeniu eval prompts

Labelowanie i pisanie eval prompts to procesy ściśle powiązane. Aman wyjaśnia, że eval prompt zawiera definicje ról, kontekst, cele i terminologię – wszystko to wymaga jednak zrozumienia domeny biznesowej.

Eval system składa się z trzech elementów: eval prompt, LLM i data (input, output, expected output, label). Dlatego PM nie może skutecznie napisać eval promptu bez zaangażowania w dane. Podobnie inżynier AI nie może zoptymalizować systemu bez zrozumienia, co PM uważa za „dobre” wyniki.

Dodatkowym wyzwaniem są few-shot examples (przykłady treningowe) w eval prompts. Jednak decyzja o tym, jakie przykłady wybrać, wymaga głębokiej znajomości danych i domeny biznesowej.

Trzy fundamentalne pytania dla zespołów AI

Każdy zespół pracujący z AI musi odpowiedzieć sobie na kluczowe pytania:

Ile labeli wystarczy? Aman podkreśla, że to nie jest arbitrary liczba. Zespół musi określić, co jest statystycznie znaczące dla potwierdzenia jakości eval. Kluczowe pytanie: czy potrzebna jest zgodność między wszystkimi ekspertami dziedzinowymi, czy dopuszczalne są rozbieżności w human labels?

Co robimy przy rozbieżnościach? Sytuacje, gdzie eval mówi „dobrze”, a human feedback „źle”, będą się zdarzać regularnie. Według Hamela potrzebny jest „życzliwy dyktator” – osoba z największą wiedzą domenową, która podejmie ostateczną decyzję.

Jak reagować na spadek business metrics? Gdy eval pokazuje pozytywne wyniki, ale metryki biznesowe spadają, ktoś musi zanalizować przyczyny i wprowadzić poprawki.

Od evaluacji do wyników biznesowych

Prawdziwa wartość evals leży w ich korelacji z metrykami biznesowymi. Aman wskazuje na potrzebę narzędzi pokazujących „pojedynczą szybę” – jeden widok łączący eval metrics, human labels i business results.

Bez tej korelacji evals pozostają tylko technicznym ćwiczeniem. Kluczowe jest połączenie działań użytkownika z sesjami AI i śledzenie długoterminowych efektów. Jak pyta Aman: „Czy ma znaczenie, że twój chatbot jest przyjazny, jeśli nie wykonuje konwersji, której chcesz?”

Sygnały konwersji często przychodzą tygodnie lub dni później – trzeba je skorelować z konkretnymi sesjami. Dodatkowo, gdy zespół ma evals w development i production, ludzie zaczynają mówić „tym samym językiem” – wszyscy rozumieją te same metryki i definicje jakości.

To prowadzi do iteracyjnego procesu poprawy. Jak zauważa Aman, nigdy nie osiągniesz idealnego stanu – to „trochę jak pętla”. Ale im więcej przykładów, gdzie produkt nie działał dobrze, uda się „zmiażdżyć”, tym lepsze będą eval metrics i business results.

Charakterystyka skutecznych zespołów AI

Na podstawie obserwacji klientów, Aman identyfikuje kluczowe wzorce w najlepszych zespołach:

Technical product managerowie – często to inżynierowie, którzy przeszli do product managementu. Rozumieją kod i potrafią myśleć o korelacjach danych
Dobrze zdefiniowany scope produktu – im prostszy produkt AI, tym większe prawdopodobieństwo posiadania odpowiednich danych do analiz. Zamiast dodawać więcej agentów, lepiej skupić się na prostych rozwiązaniach

Jak inżynierowie mogą rozwijać product thinking

Hamel pyta o zasoby dla inżynierów chcących myśleć bardziej produktowo. Aman radzi praktyczne podejście: inżynierowie powinni brać na siebie część obowiązków PM – rozmawiać z klientami, analizować feedback, podejmować decyzje produktowe.

Aman przywołuje historię Briana, który jako tech lead robił wszystko sam – od 0 do 1, wdrażanie produktu końcowego. Sprawdzało się to do momentu, gdy miał za dużo klientów. „Powiedział: rozmawiam z za dużą liczbą klientów i nie mogę pisać kodu” – wtedy zespół musiał zdecydować o specjalizacji.

Z drugiej strony, jeśli PM jest odpowiedzialny za business metric, czasem musi „zakasać rękawy”. Jak mówi Aman, PM powinien być „bykiem w składzie porcelany, łamiącym rzeczy” żeby mieć odpowiednie dane do odpowiedzi na kluczowe pytania.

Aman poleca zasoby jak Lenny’s Podcast czy Akasha, ale podkreśla, że najważniejsze jest hands-on experience – faktyczne wykonywanie pracy produktowej.

Checklist implementacji dla zespołów AI

Poniższa checklist została utworzona na podstawie kluczowych punktów poruszonych przez Amana i Hamela podczas prezentacji:

Przed rozpoczęciem projektu:

☐ Określ scope produktu – zdefiniuj jasno, co produkt ma robić
☐ Wyznacz eksperta dziedzinowego – kto ma najgłębszą wiedzę o problemie biznesowym?
☐ Ustał role i odpowiedzialności – kto pisze labele, kto tworzy evals, kto podejmuje finalne decyzje?
☐ Zdefiniuj „życzliwego dyktatora” – osoba z największą wiedzą domenową do rozstrzygania

Podczas tworzenia evals:

☐ Określ wymaganą liczbę labeli – na podstawie statystycznej istotności
☐ Ustał proces labelowania – PM jako ekspert dziedzinowy powinien być aktywnie zaangażowany
☐ Napisz eval prompts wspólnie – PM definiuje jakość, engineer implementuje
☐ Przygotuj procedury na konflikty – co robimy gdy eval mówi „OK” a human feedback „źle”?

Po wdrożeniu:

☐ Skonfiguruj korelację z business metrics – eval bez połączenia z wynikami biznesowymi jest bezwartościowy
☐ Stwórz „pojedynczą szybę” – jeden dashboard łączący wszystkie metryki
☐ Ustanów iteracyjny proces poprawy – regularne analizy rozbieżności i aktualizacje evals
☐ Monitoruj długoterminowe efekty – konwersje, retention, satisfaction scores

Kluczowy insight

Kto labeluje, rządzi produktem

Standardowo myślimy: Labelowanie to techniczne zadanie które można delegować komuś juniorowi lub outsourcować – w końcu to „tylko” opisywanie danych.

W praktyce okazuje się, że: Osoba która pisze labele de facto definiuje czym jest „dobry” vs „zły” output – czyli decyduje o sukcesie całego produktu AI. Jak zauważa Hamel, wszyscy traktują labelowanie jak „gorący ziemniak”, ale to właśnie ta osoba ustala standardy jakości.

Dlaczego to jest istotne: Jeśli delegujesz labelowanie, delegujesz kontrolę nad definicją jakości swojego produktu. To jak oddanie komuś innemu decyzji o tym, co oznacza „sukces” w twoim biznesie.

Test na jutro: Następnym razem gdy planujesz eval, zamiast delegować labelowanie, sam napisz pierwsze 20-50 labeli i sprawdź czy twoja definicja „dobrego outputu” jest rzeczywiście taka jak myślałeś.

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, materiał pochodzi z https://www.youtube.com/watch?v=XueTa4qrMpg

Tag: Benevolent Dictator Ai

Kto powinien tworzyć labele do AI evals? Przewodnik po współpracy PM-engineer #EN143