Nota od autora: Poniższy tekst to moje notatki z wystąpienia Marty’ego Cagana podczas ProductTank Sydney w siedzibie Atlassian. Wszystkie prezentowane przemyślenia, obserwacje i rekomendacje pochodzą bezpośrednio od Cagana oraz Malte Scholza, który moderował rozmowę. Staram się jak najdokładniej oddać ich słowa i intencje.

TL;DR:

Rola product ownera jest zagrożona przez AI i automatyzację – Cagan radzi jak najszybszy upskilling
Twórcy produktów (product creators) mają najlepszy czas w historii zawodu: wyższe zarobki, większy popyt, lepsze narzędzia
Empowerment (wzmocnienie zespołów) to nie delegacja – zespoły potrzebują coachingu od liderów i strategicznego kontekstu
Nowe narzędzia (Lovable, Cursor) zrewolucjonizowały prototypowanie, ale nie zastąpią seniorskich inżynierów
AI zmienia wszystko: jako narzędzie do budowy produktów i jako zupełnie nowy typ produktów probabilistycznych
Zespoły będą mniejsze, ale z większym zakresem odpowiedzialności – struktura zespołów ważniejsza niż liczba osób
85% funkcji z mapy drogowej nie dostarcza wartości biznesowej – dlatego odkrywanie rozwiązań jest kluczowe

Dlaczego Marty Cagan przyleciał do Sydney ostrzec product ownerów

Marty Cagan nie przebierał w słowach podczas swojego wystąpienia w siedzibie Atlassian w Sydney. W pomieszczeniu zaprojektowanym dla znacznie mniejszej grupy zmieściło się kilkaset osób, które chciały usłyszeć, dokąd zmierza product management.

Wiadomość była jasna: świat zarządzania produktem przechodzi fundamentalną transformację. Niektóre role zyskują na znaczeniu, inne zaś stopniowo zanikają.

Trzy typy product managerów i ich przyszłość

Cagan podzielił świat zarządzania produktem na trzy kategorie. Każda ma zupełnie inną przyszłość.

Product owner: rola w zaniku

Product ownerzy w ścisłym tego słowa znaczeniu spędzają większość dnia w JIRA, zarządzając listą zadań (backlog). Według Cagana to rola procesowa, związana z metodologiami dostarczania produktów jak Scrum czy Kanban.

Problem w tym, że te procesy stają się coraz mniej istotne w erze AI.

Cagan przyznał otwarcie, że ma setki znajomych w tej roli. Martwi się o ich kariery, szczególnie w Europie widać już pierwsze zakłócenia. Nie będzie łez po tej roli, ale jest dużo empatii dla ludzi, którzy muszą się przekwalifikować.

Rada jest jedna: przekwalifikuj się tak szybko jak tylko możesz.

Feature team product manager: project manager w przebraniu

Drugi typ to product managerzy w organizacjach z bardzo odgórną kulturą. Często spotykani w bankach, gdzie wysoko opłacani ludzie decydują, co trafia na mapę drogową. Następnie ktoś z tytułem „product manager” musi to zdefiniować, zaprojektować i dostarczyć do Sprinta.

Cagan podkreśla, że to ważna praca, jednak nie jest to zarządzanie produktem w jego rozumieniu. To bardziej zarządzanie projektami. Różnica jest fundamentalna: ci ludzie nie decydują, co budować – są wykonawcami cudzych wizji.

Product creator: złoty czas

Trzeci typ to ludzie, którzy mają najlepszy moment w karierze.

Twórcy produktów (product creators) biorą odpowiedzialność za odkrywanie rozwiązań i dostarczanie rzeczywistych efektów biznesowych (outcome). Ich średnie zarobki rosną, podczas gdy pozostałe dwie grupy tracą pracę.

Nie chodzi tylko o produkty oparte na AI. Każdy zespół, nawet budujący konwencjonalne produkty, używa już narzędzi AI, co oznacza jedno: trzeba umieć odkrywać, co warto zbudować.

Jak zauważa Cagan, kilka lat temu CEOs pytali, czy product managerowie są w ogóle potrzebni. Dziś ci sami CEOs zwiększają procent product managerów w organizacji, ponieważ zrozumieli, że firma to wyścig o odkrywanie wygrywających produktów.

Różnica między wynikiem a efektem biznesowym

Malte Scholz zwrócił uwagę na kluczową różnicę: zespoły funkcjonalne (feature teams) mogą zobowiązać się do wyniku (output), natomiast zespoły produktowe zobowiązują się do efektu biznesowego (outcome).

To nie jest gra słów.

Cagan przywołał dane z Harvard Business Review, gdzie Microsoft był studium przypadku. 85% rzeczy z mapy drogowej nie dostarcza wartości biznesowej – okropny wskaźnik dla każdej definicji sukcesu.

Problem tkwi w samym podejściu. Firmy od zawsze używały map drogowych opartych na funkcjonalnościach, a większość przyznaje, że wiele z tego, co budują, nie przynosi rezultatów. Pytanie tylko brzmi: jak bardzo źle to wygląda i czy jest coś lepszego?

Jest – podejście oparte na efektach biznesowych.

W firmie produktowej liczą się tylko efekty biznesowe. Nikt nie dostaje punktów za wypuszczanie funkcjonalności do klientów, punkty są za rozwiązywanie problemów klientów lub firmy.

Odkrywanie rozwiązań: przed czy po?

Christian Idiodi, partner Cagana, sformułował cytat, który podsumowuje całą filozofię: „Wszyscy robią odkrywanie produktowe (product discovery). Albo robisz to przed budową, albo po.”

Jego punkt jest prosty: firmy z mapami drogowymi opartymi na funkcjonalnościach robią odkrywanie po wypuszczeniu. Wtedy dowiadują się, że to nie był taki świetny pomysł, jednak do tego czasu kadra kierownicza już zmieniła zdanie i przeszła dalej.

Czego naprawdę potrzebują wzmocnione zespoły

Cagan spotkał się z kadrą kierowniczą podczas lunchu i powiedział im wprost: wzmocnione zespoły (empowered teams) nie wymagają mniej przywództwa – wymagają lepszego przywództwa.

Presja od zarządów na CEOs

Warto zrozumieć kontekst. Zarządy obecnie wywierają presję na CEOs, pytając: co robicie wokół AI? Czy macie w ogóle wewnętrzne możliwości, żeby to robić? Czy wiecie, jak dobre firmy tworzące te produkty pracują? Jeśli nie, to dlaczego?

Te pytania zmieniają dynamikę. Więcej kadry kierowniczej niż kiedykolwiek interesuje się tym, jak naprawdę działa zarządzanie produktem.

Dwa ekstrema (i oba są złe)

Mikromanagement to znana patologia – szef mówi: zrób to, wyślij tamto. Nie ma miejsca na innowację, bo wszystko jest z góry zdecydowane.

Drugie ekstremum to niedostateczne zarządzanie. Lider mówi: wiem, że mikromanagement jest zły, więc dam wam przestrzeń do dobrej pracy. Brzmi świetnie, w praktyce jednak to niewiele lepsze.

Czego naprawdę potrzebują zespoły od liderów

Uczenia się zawodu

Większość ludzi uczy się, jak być dobrym product managerem, tech leadem czy designerem od swojego managera. Cagan nauczył się tak, prawie wszyscy, którzy opanowali warsztat, mieli dobrego mentora.

Problem pojawia się, gdy manager sam tego nigdy nie robił. Dla rozwijających się ekosystemów jak Sydney to błędne koło – jest więcej zainteresowania nowym sposobem pracy niż managerów, którzy to potrafią.

Rozwiązania są dwa: CEO sprowadza nowych liderów z doświadczeniem albo obecni liderzy dostają coacha do zarządzania produktem. Cagan znalazł już kilku dobrych coachów w Sydney podczas swojej poprzedniej wizyty.

Strategicznego kontekstu

W startupie każdy wie, co się dzieje – firma to zespół. W Atlassian jest 400 product managerów. Jak każdy z tych 400 ludzi ma podejmować dobre decyzje bez zrozumienia większego obrazu?

Liderzy muszą nieustannie dzielić się kontekstem strategicznym: wizja produktowa, strategia produktowa, struktura zespołów – co robią wszystkie zespoły. Każdy zespół musi wiedzieć, jak jego część wpływa na całość, inaczej setki decyzji tygodniowo będą podejmowane w próżni.

Wizja produktowa: muzyka vs Spotify

Malte Scholz podzielił się przydatną analogią dla firm, które nie rozumieją jeszcze, czym jest ich produkt.

Zapytaj kogokolwiek o ulubiony produkt technologiczny – jeśli nie pierwsza, to druga lub trzecia odpowiedź to Spotify. Nigdy jednak nie dlatego, że Spotify ma muzykę.

Muzyka jest taka sama w Spotify, Apple Music i Tidalu. Ludzie kochają Spotify za:

Odkrywanie nowej muzyki
Playlisty współdzielone z dziećmi
Możliwość odtwarzania na każdym urządzeniu

Ta sama logika działa w bankach. Nikt nie chwali banku za to, że ma konto bankowe – konto jest wszędzie takie samo. Ludzie wyróżniają banki za digitalne doświadczenie.

Gdy to wytłumaczysz liderom biznesowym, nagle rozumieją: migracja platformy nie jest produktem, digitalne doświadczenie jest produktem. Wizja produktowa może w końcu zaistnieć.

Rewolucja w prototypowaniu (i gdzie kończy się magia)

Cagan jest podekscytowany nowymi narzędziami, jednocześnie widzi jednak, jak wiele osób się myli co do ich możliwości.

Cztery typy ryzyka, cztery typy prototypów

Odkrywanie produktowe (product discovery) zawsze było o prototypowaniu. Istnieją cztery główne typy prototypów, odpowiadające czterem typom ryzyka:

Ryzyko wartości (value risk) – czy klienci to kupią lub wybiorą? Ryzyko użyteczności (usability risk) – czy użytkownicy potrafią to odkryć i użyć? Ryzyko wykonalności (feasibility risk) – czy możemy to zbudować z naszymi umiejętnościami, czasem i technologią? Ryzyko biznesowe (viability risk) – czy to działa dla naszego biznesu (prawnie, w sprzedaży, marketingu, finansowo)?

Dla każdego typu ryzyka mamy odpowiedni typ prototypu. Wszystkie nadal istnieją, różnica tkwi w łatwości tworzenia.

Prototypy z prawdziwymi danymi stały się tanie

Prototypy z prawdziwymi danymi (live data prototypes) były najbardziej potężne, jednocześnie najbardziej kosztowne. Teraz są często najtańsze – przełomowa zmiana.

Wcześniej potrzebowałeś czasu developerów, co stanowiło wąskie gardło dla zespołów. Teraz większość prototypów, włącznie z tymi wykorzystującymi prawdziwe dane, nie wymaga czasu developerów. Dlatego Cagan nazywa to erą twórcy produktu.

Lovable vs Cursor: różne narzędzia, różne cele

Wielu ludzi myśli, że AI zbuduje zarówno prototyp, jak i cały kod produkcyjny – engineering będzie niepotrzebny.

Cagan spędził czas na LinkedIn (określa to jako przyjmowanie lekarstwa – musi, choć nie lubi) i widzi tam wielu ludzi wierzących w ten mit. Różnica między prototypowaniem a budową produktu o jakości produkcyjnej jest ogromna.

Lovable (prototypowanie):

Świetne do szybkiego odkrywania, każdy może użyć języka naturalnego
Problem: po stworzeniu podstawowego przepływu zaczyna się zabawa w kotka i myszkę (poprawiasz jedną rzecz, psuje się inna)
Język naturalny nie jest dobry do jednoznacznej specyfikacji setek/tysięcy przypadków użycia
Nie widzisz i nie rozumiesz kodu – zgadywanka

Cursor i Claude Code (dostarczanie produktu):

Narzędzia dla poważnych inżynierów rozumiejących architekturę
Inżynierowie jak dyrygenci orkiestry z 50 agentami
Imponujące i skalowalne dla kodu produkcyjnego
Wymagają głębokiej wiedzy technicznej o niezawodności, dokładności, wydajności, skalowalności, odporności na błędy

Obie kategorie narzędzi będą się rozwijać, pozostaną jednak oddzielne. Odkrywanie (discovery) to odkrywanie, co warto zbudować, dostarczanie (delivery) to przekształcanie tego w produkty.

Forward Deployed Engineers: lekcja od Palantir

Cagan opublikował artykuł tuż przed wystąpieniem o technice spopularyzowanej przez Palantir – Forward Deployed Engineers (inżynierowie rozmieszczeni u klienta).

Palantir robi produkty dla trudnych środowisk: zaczynali od wojska i wywiadu, potem przeszli do ochrony zdrowia. Nie robią list zadań – robią bardzo skomplikowane systemy.

Nie budują tego, co klient im każe (to robi Accenture). Palantir buduje to, co według nich klient potrzebuje, żeby osiągnąć efekt biznesowy. Zgodzą się pracować tylko, jeśli dostają prawdziwe wzmocnienie (empowerment).

Żeby to zrobić, wysyłają inżynierów i product managerów do środowiska klienta – nie na godzinę czy dzień, często na miesiące. Cel jest prosty: poznać użytkowników, dane, ograniczenia interesariuszy, przestrzeń problemu. Odkryć rozwiązanie, które dostarczy efekt biznesowy, przy czym prototypują jak szaleni.

Żeby to było sensowne przy dużych, złożonych systemach, nie zaczynają od zera – startują od platformy. Robią dostosowania potrzebne w środowisku klienta, następnie zespół platformowy wydobywa to, co musieli zrobić, i ulepsza platformę dla przyszłych projektów.

Przewaga konkurencyjna przez głęboką znajomość klienta

Jeden z powodów sukcesu Palantir to ich przewaga konkurencyjna: wiedzą więcej o swoich klientach niż ktokolwiek na zewnątrz, bo faktycznie spędzili miesiące wewnątrz tych organizacji, zdobywając ich zaufanie.

Ta głęboka znajomość klientów jest bardziej trwała niż prawie cokolwiek można sobie wyobrazić. Klienci rzadko odchodzą z powodu konkurencji – odchodzą, bo przestajemy się nimi opiekować.

Liczby mówią same

Accenture jest warte około 150 miliardów dolarów i istnieje od dawna. Palantir jest warte 400 miliardów dolarów jako stosunkowo młoda firma.

To różnica między zespołem funkcjonalnym a podejściem produktowym. Klient mówi Accenture, co budować, negocjują cenę, budują. Palantir natomiast bierze model produktowy i mówi: nie, chodzi o osiągnięcie efektu biznesowego – pozwólcie nam odkryć rozwiązanie.

Pułapka parytetu funkcjonalności: dlaczego kopiowanie nie działa

Malte Scholz nie ma problemu z kopiowaniem rzeczy – jeśli coś czyni produkt lepszym, zrób to. Połowa produktów na telefonie ma kanał aktualności: jedna firma to wymyśliła, potem wiele skopiowało. Ta sama firma, która to wymyśliła, skopiowała mnóstwo rzeczy od innych.

To nie będzie jedyna rzecz, którą robisz, jeśli odnosisz sukces.

Niebezpieczeństwo strategii parytetu funkcjonalności

Cagan śmieje się, gdy firma kopiuje coś od konkurencji, szczególnie gdy zna tę konkurencję i wie, że ich dane pokazują, iż ta funkcja nie jest nawet używana.

Konkurencja nie ma dostępu do danych. To zdumiewające – realna strategia produktowa zwana strategią parytetu funkcjonalności (feature parity strategy). Mówimy: musimy skopiować funkcje, które oni mają. Efekt? Kiepski produkt dziedziczący wszystkie rzeczy, które nie działają nawet dla tamtej firmy.

Lekcja od Apple: pierwsze iPhone bez kopiowania i wklejania

Cagan przypomina: pierwsze iPhone nie miało nawet funkcji kopiowania i wklejania. Niektórzy nie są wystarczająco starzy, żeby to pamiętać, ale to prawda.

Apple nigdy nie używa tego jako powodu do zrobienia czegoś – nie ma parytetu funkcjonalności jako argumentu. Czasami funkcjonalność jest po prostu oczywista: wiemy, że jej potrzebujemy, nie trzeba robić odkrywania, po prostu to zbuduj.

Powinieneś to robić tylko jeśli masz jakieś dowody, że to konieczne. Nie zakładaj, bo konkurent to ma, zdecydowanie nie zakładaj, bo jakiś klient mówi, że chce tego, bo konkurent to ma. Musisz być przekonany.

Jak zmienią się zespoły produktowe

Sharif z Atlassian wspomniał, że firma ma 400 product managerów – duża organizacja. Cagan widzi dwa główne trendy.

Mniejsze zespoły, większy zakres odpowiedzialności

Przeciętna wielkość zespołu spadnie. Jeśli dziś zespół ma product managera, tech leada i pięciu inżynierów, jutro prawdopodobnie będzie trzech lub czterech inżynierów – to będzie się pogłębiać.

Struktura pozostanie: product manager, tech lead, inżynierowie. W niektórych przypadkach designer, w innych nie.

Względne znaczenie różnych umiejętności

Cagan przestrzega przed nadmiernym upraszczaniem ról. W różnych firmach różne ryzyka są różnie ważne, więc pewne umiejętności stają się super ważne.

Apple: design był zawsze niewiarygodnie ceniony – spójrz jak integralny jest design dla ich produktów. Design i engineering są tam niewiarygodnie cenione.

Instagram i Airbnb: produkt ma pewne złożoności po stronie zarządzania, ale design jest bardzo duży. I oczywiście skalowalność, engineering jest duży.

Większość firm B2B: najtrudniejszą umiejętnością jest faktycznie zrozumienie wszystkich różnych wymiarów biznesu, co jest rolą product managera.

Firmy konsumenckie: często design, bo chodzi o doświadczenie użytkownika.

To nie znaczy, że nie mają tych umiejętności – tylko względne znaczenie tych umiejętności się różni.

Struktura zespołów ważniejsza niż wielkość

Bardziej znaczący wpływ będzie miała zmiana struktury zespołów. W startupie wszyscy wiedzą, co się dzieje – firma to zespół. Problem zaczyna się przy skali.

Załóżmy, że 100 zespołów kontrybuuje do Jira: jeden produkt, jedna jednostka rozliczeniowa. Łatwo poczuć się jak mały tryb w gigantycznym mechanizmie. Największa skarga: nie możemy nic zrobić bez 20 innych zespołów – zero samodzielności.

Samodzielność vs wzmocnienie: kluczowe rozróżnienie

Cagan robi tu ważne rozróżnienie – samodzielność (autonomy) to nie to samo co wzmocnienie (empowerment).

Wzmocnienie oznacza, że możesz odkryć rozwiązanie. Większość dobrych zespołów to ma.

Samodzielność oznacza, że nie zależysz od wszystkich innych zespołów, żeby zrobić to, co chcesz zrobić. Tego większość zespołów NIE ma i czują się przez to sparaliżowani.

Zespoły chcą odpowiedzialności od początku do końca. Niekoniecznie 100 do 1, ale 100 do 20 jest bardzo prawdopodobne w czasie. To będzie dużo bardziej satysfakcjonujące: większy wpływ, więcej zmian, odpowiedzialność za całe przepływy.

Produkty AI: nowy poziom trudności

Większość ludzi pracuje nad konwencjonalnymi, deterministycznymi produktami – będzie tak jeszcze długo. Cagan szacuje, że może 10% to produkty AI, prawdopodobnie bliżej 1-2%.

Nawet jeśli budujesz konwencjonalny produkt, używasz narzędzi AI. Budowanie produktu AI to jednak inna liga.

Waymo jako przykład

Cagan zachęca: jeśli masz służbową podróż do USA, do miasta gdzie jest Waymo, pobierz aplikację i jedź samochodem bez kierowcy – oszałamiające doświadczenie.

Jeden z najbardziej wyrafinowanych, inteligentnych produktów. Ciągle ma człowieka w pętli, choć nie wszyscy o tym wiedzą. Około 10 milionów mil zautomatyzowanych testów działa non-stop.

Gdy samochód napotka coś dziwnego (wandalizm, ludzie blokujący drogę), wysyła obraz przez Internet do biura – ludzie decydują: dzwonić na policję czy co robić? Człowiek w pętli nadal istnieje, ale to pokazuje, co można osiągnąć.

Kluczowe różnice w pracy z produktami AI

Ewaluacja zamiast testów akceptacyjnych

W produkcie deterministycznym masz testy akceptacyjne: product manager sprawdza, czy rzecz jest okej. Gdy raz to zrobisz i produkt się nie zmienia, możesz być pewny, że jutro, w weekend, na Boże Narodzenie będzie działać tak samo.

Z produktem probabilistycznym to nieprawda. Proces nazywa się ewaluacją – sposób na upewnienie się, że system konsekwentnie robi właściwe rzeczy albo przynajmniej nie robi złych rzeczy (nie niebezpiecznych, nie niepoprawnych). Zabezpieczenia są konieczne.

Uczenie się jak robić ewaluację to duża część pracy dla produktów AI.

Ciągłe doskonalenie

Cagan zawsze podkreślał: w dobrym zespole odkrywanie i dostarczanie są ciągłe. Odkrywanie nie jest fazą, dostarczanie nie jest fazą – toczą się równolegle, odkrywanie zawsze trochę przed.

To jest szczególnie prawdziwe dla produktów AI. Jeśli decydujesz się na produkty probabilistyczne, podpisujesz się pod ciągłe doskonalenie na stałe.

Koszt jako nowe ograniczenie

Cagan wspomina coś, o czym ludzie nie zawsze myślą: koszty są szaleńczo drogie dla wielu rzeczy, które chcemy zrobić z AI.

Inżynier odgrywa ogromną rolę w próbie wymyślenia sposobu, który jest jednocześnie dokładny, szybki i przystępny cenowo. To bardzo trudne kompromisy, których nie musieliśmy robić przez długi czas.

Protokół MCP i agentowe AI

Cagan jest bardzo optymistyczny co do protokołu MCP – myśli, że to brakujący element od długiego czasu, nawet sprzed AI.

Powiedziano mu, żeby obniżył oczekiwania (nie będzie takie świetne), ale jest bardzo optymistyczny. Myśli, że to odpowiada na potrzebę, która istniała znacznie wcześniej.

Agentowe AI to kolejna warstwa na dyskusji: mowa o tym, jak produkty są zaprojektowane, żeby były dostępne. To dość duża zmiana, co do której Cagan jest optymistyczny.

Teresa Torres i myślenie zamiast delegacji

Partner Cagana, Teresa Torres, miała poważny wypadek na lodzie podczas gry w hokeja – trzy miesiące bez obciążania nogi na kanapie. Mogła zwariować albo zrobić coś użytecznego.

Zdecydowała się nauczyć budować produkt AI. Wybrała narzędzie do coachingu rozmów z użytkownikami, przeszła cały proces (głównie system ewaluacji), potem podzieliła się wszystkim, czego się nauczyła.

Cagan powiedział jej, że pokazała najważniejszą rzecz dla ludzi produktu: myślenie. Najczęstszy błąd: ludzie delegują myślenie narzędziom. Widzisz to z ChatGPT cały czas – niektóre odpowiedzi są absurdalne, a ludzie im ufają.

Torres używała narzędzi jako partnerów do myślenia, nigdy jako delegacji. Ten poziom sprawczości był imponujący.

Sydney jak Nowy Jork: mit o byciu w tyle

Cagan spotkał wielu ludzi w Australii, którzy wierzą, że zostali w tyle – że w San Francisco wszyscy robią to dobrze. To nieprawda.

Ten sam problem jest w San Francisco, Londynie, Berlinie, wszędzie. Zawsze był mix firm, które są dobre w produktach, i reszty. Atlassian to świetny przykład firmy produktowej, Canva tuż obok to kolejny świetny przykład. Obie trzymają poziom z kimkolwiek na świecie.

W Sydney największym pracodawcą są banki. W Nowym Jorku też – to dość nietypowe. Przez lata w Nowym Jorku była frustracja w społeczności produktowej: Boston robił rzeczy, Austin, San Francisco, Seattle, a Nowy Jork nic.

Pytanie: gdzie był talent? Był zatrudniony przez banki. Banki płacą dobrze, jednak nie używają inżynierów tak, jak firmy produktowe. Podejście najemnicze vs misyjne.

Kryzys finansowy zmusił banki do zwolnień, w końcu uwolnił tych utalentowanych ludzi. Wielu powiedziało: szukałem wymówki, żeby założyć firmę albo dołączyć do Etsy. Wystartowało – dziś Nowy Jork jest nie do odróżnienia od San Francisco.

Sydney ma podobną sytuację: dużo talentu przykutego złotymi kajdankami w bankach. Cagan spodziewa się zobaczyć więcej ludzi decydujących się na ryzyko – Atlassian, Canva, własny startup.

Ścieżki kariery: nie musisz być managerem

Pod koniec panelu ktoś zapytał o rozwój kariery – czy im wyżej, tym dalej od pracy twórczej?

Principal PM: ścieżka dla twórców produktów

Cagan przywołał Shriyasha Doshiego, jednego z jego ulubionych myślicieli produktowych. Znany od 20 lat, zaczynał jako inżynier, został jednym z oryginalnych ludzi produktu w Stripe, wcześniej w Google, w Twitterze – bardzo, bardzo silny specjalista od produktów.

Doshi lubi mówić: każdy problem produktowy to problem przywództwa produktowego. Ma trochę racji.

Jest jednak też przykładem czegoś innego. Bracia Collison, założyciele Stripe, ciągle próbowali go przenieść na rolę liderską. On odpowiadał: ale ja uwielbiam budować produkty.

Oni na to: okej, będziemy ci dawać najtrudniejsze produkty, więc możesz się rozwijać. To nazywa się podwójna ścieżka kariery. Principal product manager (główny product manager) to świetna praca – jesteś normalnie twórcą, ale naprawdę wpływowym twórcą.

Wiele firm wierzy w podwójną ścieżkę kariery, bo nie chcą, żeby ludzie zostawali managerami tylko dla pieniędzy. Powinieneś zostać managerem, jeśli chcesz rozwijać innych ludzi, wpływać na strategię produktową, wizję produktową.

Innowacje przychodzą z zespołów, nie od liderów

Cagan podkreśla coś fundamentalnego: jedna z rzeczy, które kocha w tej branży – indywidualni twórcy są tak bardzo cenieni.

Spójrz na to. Skąd myślisz, że przychodzą innowacje? Nie przychodzą naprawdę od liderów – przychodzą z zespołów.

Praktyczne rady: jak się rozwijać

Pod koniec panelu padło wiele pytań o konkretne kroki.

Sprawczość jako superumiejętność

Cagan wrócił kilka razy do tego tematu: sprawczość (agency) to zdolność do robienia więcej, niż myślisz, że możesz. Wszyscy cierpimy przez ograniczenia firm i osobowości ludzi. Ludzie o wysokiej sprawczości mówią: oczywiście będą przeszkody – co możemy zrobić?

Możesz zazwyczaj rozmawiać z klientami, możesz zazwyczaj patrzeć na dane produktowe, możesz zazwyczaj po prostu poinformować się o problemach klientów.

Pokaż, nie opowiadaj

Jedno z najlepszych rzeczy, jakie możesz zrobić: stwórz prototyp. Zawsze mogłeś, teraz możesz to zrobić narzędziami jak Lovable w kilka godzin.

Szczególnie dobre: przed pokazaniem liderom przetestuj na użytkownikach, przetestuj na deweloperach, sprawdź, czy mogliby to zbudować na serio. Przetestuj na kluczowych interesariuszach – może prawnik się martwi, może sprzedaż.

Upewnij się, że masz prototyp czegoś, co wszystkie te grupy mogą poprzeć, potem idź do leadera. Bardzo możliwe, że liderzy, którzy do tej pory mówili „nie” na wszystko, powiedzą: zbudujmy to.

Od product ownera do twórcy: strategia oddolna

Malte Scholz obserwował: nawet w zespołach funkcjonalnych możesz zacząć od dołu. Pracował z firmą e-commerce – to oczywiste: optymalizujesz przepływ finalizacji zakupu. Product manager dumnie powiedział: wbudowaliśmy Apple Pay. Świetnie. Co to zmieniło? Osoba nie wiedziała.

To bardzo podstawowe – mają narzędzia pomiarowe, każdy by zrozumiał: patrzysz na wskaźniki finalizacji zakupu i porzucania koszyka.

Minimum: patrz, co to zrobiło, potem masz o czym rozmawiać w firmie. Możesz powoli zmieniać sposób myślenia oddolnie. Twój szef może chcieć więcej rzeczy, które mają wpływ, jeśli właśnie rozmawiałeś o wpływie ostatniej rzeczy. Możesz pracować w górę hierarchii w sytuacjach, gdzie nie masz wsparcia odgórnego.

Eksperyment jako pierwszy krok

Nawet w firmie, gdzie żaden lider nie wie o tym wszystkim lub nie dba, możesz iść do managera i powiedzieć: co jeśli zrobimy eksperyment?

Nie cała firma, nie wiele zespołów – nasz zespół. Eksperyment: spróbować osiągnąć efekt biznesowy. Cagan nie widział firmy, która by na to powiedziała nie. Zazwyczaj widzą jakąś inicjatywę – może działa, może nie. Jeśli nie działa, wracają do starego, jeśli działa, może jest tu realna wartość.

Minimum: możesz to zrobić.

Zobowiązania wysokiej wiarygodności: kiedy MUSISZ dać datę

Przez większość czasu pracujemy na efektach biznesowych, jednak każda firma produktowa ma sytuacje, gdzie musisz też dać datę – i to musi być data, której organizacja może zaufać.

Cały model produktowy jest zbudowany na zaufaniu. Co robisz?

Dajesz datę tylko jeśli zrobiłeś odkrywanie produktowe. I nie byle kto – inżynierowie, którzy będą musieli to dostarczyć, robią odkrywanie. Technicznie to oznacza prototyp wykonalności, który jest jednym z czterech typów prototypów.

Jeśli inżynierowie zrobią prototyp wykonalności, wtedy mogą dać datę, której możemy zaufać – i to właśnie robimy.

Etyka jako część ryzyka biznesowego

Podczas Q&A ktoś z Google Photos zapytał o odpowiedzialność za etyczne zabezpieczenia – czy to wymaga nowej roli?

Cagan odpowiedział, że technicznie etyka to część ryzyka biznesowego (viability), zawsze było częścią ryzyka biznesowego. Jeśli robisz rzeczy, które nie są świetne, to ryzyko biznesowe – minimum: ryzyko prawne.

To część odpowiedzialności product managera.

Problem nie w tym. Problem jest w tym, że musisz zdać sobie sprawę: produkt jest zazwyczaj na ostrzu noża, bo robisz odkrywanie nowych możliwości. Jeśli jest nowa kwestia etyczna, prawdopodobnie jako pierwszy ją zauważysz.

Pytanie brzmi: co z tym zrobić? To jest delikatne – nie chcesz iść do CEO i mówić: próbujesz zmusić mnie do robienia nieetycznej rzeczy. Dla nich to prawdopodobnie zupełnie nowa informacja.

Czego szukają: wskazania tego ryzyka. To twoja normalna praca z wzmocnionym zespołem. Kiedy znajdziesz coś, co nie jest wykonalne biznesowo (może nie da się tego opłacalnie wprowadzić na rynek), podejmujemy inne podejście. Jeśli znajdziemy coś, co może zaszkodzić dzieciom lub jest dostępne dla złych aktorów, szukamy sposobu żeby nie mieć tej podatności.

Czasami jest jak: co robimy? To dokładnie to, czego chce klient, ale widzimy ten problem. Wtedy twoją pracą jest przekazać to wyżej do managera. Powiedz: bardzo przyda mi się wskazówka, oto co znaleźliśmy, oto czym się martwimy. Powiedz czy myślisz, że nadmiernie się martwimy, czy może powinieneś to zanieść do leadera lub prawnika.

Przekaż wyżej, nie ryzykuj kariery.

Jednocześnie: są niektóre firmy, które są naprawdę paskudne. Cagan był zszokowany co niektórzy CEOs chcą robić. Radził ludziom pracującym tam: po prostu wyjdź, nie chcesz być częścią tego, nie chcesz być z tym kojarzony.

Jak myśleć o pracy z AI: lekcje od Cagana i Torres

Podczas rozmowy pojawiło się kilka kluczowych wskazówek dotyczących pracy z narzędziami AI – nie są to konkretne prompty, ale zasady myślenia o AI w odkrywaniu i dostarczaniu produktów.

AI jako partner do myślenia, nie delegacja myślenia

Teresa Torres, która spędziła trzy miesiące ucząc się budować produkt AI, pokazała najważniejszą zasadę według Cagana: myślenie, nie delegacja.

Najczęstszy błąd: ludzie delegują myślenie narzędziom. Widzisz to z ChatGPT cały czas – niektóre odpowiedzi są absurdalne, a ludzie im ufają.

Torres nie jest typem osoby, która zaufa wyjściu z systemu – chce wszystko rozumieć. Używała narzędzi jako partnerów do myślenia, nigdy jako delegacji. Ten poziom sprawczości był imponujący.

Prompt engineering: nowa umiejętność podstawowa

Podczas Q&A ktoś zapytał czy inżynieria promptów będzie ważna. Cagan odpowiedział porównaniem: czy umiesz używać Google? Tak. Czy umiesz tworzyć prompty? Tak. To będzie tak oczywiste bardzo szybko dla każdego w tej przestrzeni.

Innymi słowy: inżynieria promptów stanie się umiejętnością podstawową, jak używanie wyszukiwarki – nie będzie to przewaga konkurencyjna.

Przewaga konkurencyjna będzie:

Myślenie i osąd
Zrozumienie kontekstu biznesowego
Głęboka znajomość klienta i jego problemów
Umiejętność zadawania właściwych pytań

Kiedy używać prostych promptów w języku naturalnym

Idealne na etapie odkrywania (product discovery):

Szybkie tworzenie prototypów do testowania hipotez
Przyspieszenie iteracji w odkrywaniu
Generowanie wariantów do testowania z użytkownikami
Eksplorowanie różnych rozwiązań tego samego problemu

Narzędzia typu Lovable pozwalają w języku naturalnym szybko opisać ideę i wygenerować pierwszy, działający prototyp. Ich celem jest szybka eksploracja i wizualizacja pomysłu.

Kiedy proste prompty to za mało

Cagan podkreśla, że język naturalny jest z natury niejednoznaczny. Próba opisania w ten sposób wszystkich przypadków użycia w gotowym produkcie przypomina „grę w kotka i myszkę” – poprawiasz jedną rzecz, psuje się inna.

Na etapie dostarczania (delivery) potrzebne są:

Precyzyjne narzędzia dla doświadczonych inżynierów (Cursor, Claude Code)
Głęboka wiedza techniczna o architekturze, niezawodności, skalowalności
Nie możesz tylko „lepiej promptować” – musisz myśleć o architekturze
Automatyzacja powtarzalnych zadań w wytwarzaniu

Czego NIE delegować AI

Decyzji o tym CO budować (wymaga zrozumienia klienta i kontekstu biznesowego)
Oceny wartości i użyteczności (wymaga testów z rzeczywistymi użytkownikami)
Strategicznych decyzji biznesowych (wymaga głębokiego kontekstu)
Ostatecznej oceny wykonalności (doświadczony inżynier musi to zatwierdzić)
Etycznych rozważań (to twoja osobista odpowiedzialność jako PM)
Decyzji o kompromisach między kosztem, dokładnością i wydajnością

Złota zasada od Torres: AI jako narzędzie do myślenia

Używaj AI jako narzędzia do myślenia, nie jako zamiennika myślenia. Każde wyjście z AI powinno przejść przez twój krytyczny osąd.

Pytania które zawsze zadawaj:

Dlaczego AI zasugerował to rozwiązanie?
Czy to ma sens w kontekście moich użytkowników?
Jakie są założenia tego rozwiązania?
Co może pójść nie tak?
Czy AI ma wystarczający kontekst żeby to ocenić?

Jeśli nie potrafisz odpowiedzieć na te pytania, prawdopodobnie delegowałeś myślenie zamiast używać AI jako partnera do myślenia.

Różnica w kosztach: nowe ograniczenie dla produktów AI

Cagan wspomniał coś kluczowego: koszty AI są szaleńczo drogie dla wielu rzeczy, które chcemy zrobić. To nowy typ ograniczenia, którego nie mieliśmy przez długi czas w oprogramowaniu.

W praktyce to oznacza:

Każde wywołanie modelu kosztuje
Musisz myśleć o kompromisach: dokładność vs koszt vs szybkość
Inżynier odgrywa kluczową rolę w optymalizacji
Nie możesz tylko „lepiej promptować” – musisz myśleć o architekturze

To kolejny powód dlaczego doświadczeni inżynierowie będą nadal potrzebni i cenni – rozumieją jak zbudować coś, co jest jednocześnie dokładne, szybkie i przystępne cenowo.

Szybki start: jak stać się agentem zmiany

Nawet jeśli twoja organizacja wciąż tkwi w starym modelu, pojedyncza osoba może być iskrą zapalną zmiany. Poniższe kroki oparte są na praktycznych radach Cagana.

Mierz wpływ swojej pracy

Cagan podaje przykład product managera, który wdrożył Apple Pay, ale nie wiedział, jaki miało to wpływ na konwersję. Kluczowe jest mierzenie efektów wszystkiego, co wdrażasz, aby rozmawiać językiem danych. Sprawdź wskaźniki finalizacji zakupu i porzucania koszyka – to bardzo podstawowe, ale fundamentalne.

Stosuj zasadę „pokaż, nie opowiadaj”

Zamiast pisać dokumenty, stwórz interaktywny prototyp w narzędziach jak Lovable. Następnie przetestuj go z użytkownikami i deweloperami, zanim pójdziesz do decydentów. Działający dowód jest wart więcej niż tysiąc slajdów. Zbierz feedback adresujący wszystkie 4 typy ryzyka: wartości, użyteczności, wykonalności, biznesowe.

Inicjuj eksperymenty

Zamiast walczyć z systemem, zaproponuj managerowi mały, kontrolowany eksperyment. Poproś o możliwość pracy nad jednym celem w modelu opartym na efektach biznesowych (outcome). Cagan nie widział firmy, która by na to powiedziała nie – zazwyczaj widzą inicjatywę, dają szansę.

Używaj swojej sprawczości (agency)

Pamiętaj, że masz więcej wpływu, niż sądzisz. Mimo ograniczeń możesz rozmawiać z klientami, analizować dane produktowe i proaktywnie szukać problemów do rozwiązania. Nie czekaj na pozwolenie – zbierz dane, zbuduj prototyp, przetestuj, potem pokaż.

Listy kontrolne praktyczne

Od product ownera do twórcy produktu w 90 dni

Natychmiast (tydzień 1-2): □ Zacznij mierzyć efekt biznesowy każdej wypuszczonej funkcji (nie tylko że wyszła, ale co zmieniła) □ Przygotuj 2-3 przykłady gdzie możesz pokazać wpływ swoich decyzji □ Zarezerwuj 2-4 godziny dziennie na tworzenie produktu (nie tylko zarządzanie listą zadań)

W ciągu miesiąca: □ Porozmawiaj z 5 użytkownikami o ich problemach (nie o funkcjach które chcą) □ Naucz się podstaw jednego narzędzia do prototypowania (Lovable, Bolt) □ Stwórz pierwszy prototyp czegoś co rozwiązuje problem □ Przetestuj prototyp adresując wszystkie 4 typy ryzyka (wartości, użyteczności, wykonalności, biznesowe) □ Zaproponuj managerowi eksperyment: jeden efekt biznesowy zamiast wyniku

W ciągu kwartału: □ Znajdź coacha do zarządzania produktem lub mentora □ Przeczytaj „Inspired” i „Empowered” Marty’ego Cagana □ Zbuduj portfolio 3-5 przykładów gdzie dostarczyłeś efekt biznesowy (nie tylko funkcję) □ Rozważ ścieżkę głównego product managera jeśli chcesz zostać twórcą produktu długoterminowo

Jak pokazać prototyp bez pozwolenia

Przygotowanie: □ Zidentyfikuj problem który możesz rozwiązać w zakresie swojego zespołu □ Stwórz prototyp w narzędziu typu Lovable (kilka godzin pracy) □ Upewnij się że prototyp jest samowyjaśniający się

Weryfikacja przed pokazaniem (4 typy ryzyka): □ Ryzyko wartości: przetestuj z 3-5 użytkownikami – czy to rozwiązuje ich problem? □ Ryzyko użyteczności: przetestuj z użytkownikami – czy potrafią to odkryć i użyć? □ Ryzyko wykonalności: przetestuj z deweloperami – czy możemy to zbudować? □ Ryzyko biznesowe: przetestuj z prawnikiem/compliance/sprzedażą – czy to działa dla biznesu? □ Zbierz opinie i popraw prototyp

Prezentacja: □ Pokaż liderom działający prototyp (nie slajdy!) □ Pokaż wyniki testów adresujące wszystkie 4 typy ryzyka □ Poproś o decyzję: budujemy czy nie?

Ramy 4 typów ryzyka w odkrywaniu

Dla każdego pomysłu/prototypu zadaj pytania: □ Ryzyko wartości: Czy klienci/użytkownicy to kupią lub wybiorą? (test z użytkownikami) □ Ryzyko użyteczności: Czy użytkownicy potrafią to odkryć i użyć? (test z użytkownikami) □ Ryzyko wykonalności: Czy możemy to zbudować? (test z inżynierami, prototyp wykonalności) □ Ryzyko biznesowe: Czy to działa dla biznesu? (test z prawnikiem, sprzedażą, marketingiem, finansami, etyką)

Praca z AI: lista kontrolna myślenia nie delegacji

Przed użyciem AI: □ Czy jasno rozumiem problem który próbuję rozwiązać? □ Czy mam wystarczający kontekst żeby ocenić odpowiedź AI? □ Czy to zadanie które wymaga mojego myślenia czy może być zautomatyzowane?

Podczas pracy z AI: □ Używam AI jako partnera do myślenia w eksploracji opcji □ Zadaję AI pytania „dlaczego” i „jakie są założenia” □ Testuję wiele wariantów zamiast brać pierwsze wyjście □ Łączę wyjście z AI z moją wiedzą o kliencie i biznesie

Po otrzymaniu wyjścia z AI: □ Czy rozumiem dlaczego AI zasugerował to rozwiązanie? □ Czy to ma sens w kontekście moich użytkowników i biznesu? □ Jakie są potencjalne problemy tego rozwiązania? □ Czy potrzebuję przetestować to z prawdziwymi użytkownikami? □ Czy powinienem skonsultować to z inżynierami/designerami/interesariuszami?

Kluczowy insight

Pułapka mapy drogowej konkurencji

Standardowo myślimy: Jeśli nasz główny konkurent ma daną funkcję, my też musimy ją mieć, aby nie zostać w tyle. To priorytet.

W praktyce okazuje się, że: Ślepe kopiowanie funkcji to prosta droga do budowania produktu, którego nikt nie chce. Nie mamy dostępu do danych konkurencji, dlatego nie wiemy, czy ta funkcja jest u nich sukcesem. Możemy nieświadomie kopiować ich porażki. Cagan śmieje się, gdy firma kopiuje coś od konkurencji, którą zna – wie, że ich dane pokazują, iż ta funkcja nie jest nawet używana. To zdumiewające, jak często się to zdarza.

Dlaczego to jest istotne: Takie podejście prowadzi do marnowania zasobów na nieistotne dodatki, podczas gdy prawdziwa przewaga leży w głębszym zrozumieniu i rozwiązywaniu problemów naszych klientów. Apple wypuściło pierwsze iPhone bez funkcji kopiowania i wklejania – nie używali parytetu funkcjonalności jako argumentu. Czasami funkcjonalność jest po prostu oczywista i potrzebna, ale powinieneś to robić tylko jeśli masz jakieś dowody, że to konieczne.

Test na jutro: Następnym razem gdy ktoś w zespole powie „Musimy to zrobić, bo ma to konkurencja”, zamiast dodawać zadanie do listy zadań, spróbuj zadać pytanie: „Jaki fundamentalny problem klienta ta funkcja rozwiązuje i czy mamy dowody, że to jest problem również dla naszych użytkowników?” Zobacz, jak zmienia się dyskusja.

Polecane zasoby

Podczas rozmowy pojawiły się odniesienia do kilku wartościowych materiałów:

„Inspired” oraz „Empowered” – kluczowe książki Marty’ego Cagana o zarządzaniu produktem
„Continuous Discovery Habits” – Teresa Torres
Artykuł „AI Product Management„ – Marty Cagan i Marilee Nika (dla tych budujących produkty AI)
Artykuł „Forward Deployed Engineers„ – Marty Cagan (o modelu Palantir)
Materiały od Shriyasha Doshiego – myśliciel produktowy, były Stripe/Google/Twitter, przykład ścieżki głównego product managera
Kursy Teresy Torres – szczególnie jej studium przypadku o budowaniu produktu AI dla coachingu rozmów z użytkownikami

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ć. To notatki z wystąpienia Marty’ego Cagana podczas ProductTank Sydney w Atlassian, moderowanego przez Malte Scholza. Jeśli chcesz sprawdzić oryginalne źródło (pełny transkrypt z panelu), znajdziesz je w materiałach z tego wydarzenia.

Tag: Palantir Forward Deployed Engineers

Przyszłość product managementu według Marty’ego Cagana: era twórców produktów #EN304