żeby przestać udawać Product Managera i zacząć podejmować decyzje

Pamiętasz Truman Show? Bohater żyje tam w fikcyjnym świecie, którego nie dostrzegał latami, dopóki nie uderzył łódką w namalowaną ścianę horyzontu. Dla tysięcy product managerów tą ścianą jest Artificial Intelligence (AI), które w 20 minut wygeneruje dokument, który do tej pory zabierał tygodnie.

Czym jest teatr product managerów dlaczego AI go obnażyło?

Product Management Theater to termin ukuty przez Marty’ego Cagana, oznaczający wykonywanie czynności pozorowanych (dokumentacja, spotkania), które nie prowadzą do realnych wyników produktowych. Marty Cagan, współzałożyciel Silicon Valley Product Group (SVPG) i autor książki „Przetransformowani” (czy mojej ulubionej, „Zainspirowani”), postawił w 2024 roku tezę banalną i bolesną zarazem: większość ludzi noszących tytuł Product Managera wykonuje pracę kierownika projektów: koordynuje wydania, zarządza backlogiem, pisze wymagania. A ma to tyle wspólnego z zarządzaniem produktem co nazywanie gotowaniem odgrzewania mrożonki w mikrofalówce.

Piszę o tym, ponieważ sam tam byłem. Przez kilka lat robiłem rzeczy, które w y g l ą d a ł y jak praca PM-a: pisałem PRD, moderowałem sprint review, analizowałem efekty. Czułem się produktywny. Aż przyszedł czas w którym otworzyłem ChatGPT, wkleiłem kontekst produktu i dostałem… coś. Coś, co – przyznam – było porównywalne, a często lepsze niż mój 2-tygodniowym wysiłek. I w tej chwili poczułem to co Truman, kiedy odbił się od malowanej ściany: jeżeli komputer potrafi zrobić w minuty, to co ja w tygodnie, to czym ja się tak w ogóle zajmowałem?

Bynajmniej nie jest to pytanie retoryczne. Ani nowe. Cagan opublikował trzy artykuły jeden po drugim: „Product Management Theater”, „Product Leadership Theater” i „Transformation Theater”, a te razem tworzą najostrzejszą krytykę branży PM-owej od czasu, gdy Ben Horowitz napisał „Good Product Manager/Bad Product Manager” w 1998 roku. Ale prawdziwa bomba spadła w lutym 2026, kiedy Cagan opublikował „Product Coaching and AI” i napisał wprost: jeśli używasz AI do szybszego produkowania roadmapy i PRD, to nie podkreślasz swojej wartości, tylko obnażasz teatr.

Dlaczego Product Managerowie wolą pisać dokumenty niż podejmować decyzje?

Teatr product managerów nie jest lenistwem, lecz mechanizmem obronnym przed konfrontacją z rynkiem. Roadmapa i specyfikacja to alibi, które pozwala odroczyć moment weryfikacji błędnych założeń.

Analiza schematu

TL;DR: Schemat pokazuje, jak nadmierna dokumentacja („Ale muszę napisać specyfikację”) służy jako ucieczka przed lękiem przed porażką rynkową.

1. Impuls: Chęć podjęcia ryzykownej decyzji produktowej.
2. Lęk: Obawa przed negatywną oceną rynku/przełożonych (Kompleks niższości).
3. Ucieczka: Tworzenie bezpiecznego artefaktu (Dokument, Roadmapa, Spotkanie).
4. Rezultat: Poczucie pozornej produktywności („Teatr”).

Jak przerwać pętlę?

Poprzez działanie „pomimo lęku” – np. bezpośredni telefon do klienta zamiast pisania maila.

Idąc dalej: Alfred Adler opisał postawę „Tak, ale…”, gdy człowiek chce działać, ale od razu podaje powód dlaczego nie może tego zrobić. „Tak, chcę zarządzać produktem, ALE najpierw muszę zebrać feedback. Tak, chcę sprawdzić tę hipotezę, ALE najpierw trzeba napisać specyfikacje. Tak, chcę zadzwonić do klienta, ALE najpierw trzeba rozpisać backlog.”. Każde to „ale” to kolejna cegiełka muru za którym można się schować w razie porażki. Nie możemy się pomylić pisząc dokument, a dopiero wtedy, gdy zweryfikuje to rynek.

Oczywiście, nie jest to moja teoria, jestem na to za mały. To jedynie moja obserwacja, którą Cagan opisuje innymi słowami, nie znając ich psychologicznego źródła (lub go nie podając). Poczucie niższości w ujęciu adlerowskim nie jest słabością – jest siłą napędową. Zmusza nas do rozwoju, adaptacji, nauki. Ale kiedy przekształca się w kompleks niższości, czyli w paraliżujące przekonanie, że „nie jestem dość dobry”, to reakcją będzie nadkompensacja, czyli przegięciem w drugą stronę. I tu dochodzimy do sedna: Teatr PM jest nadkompensacją. PM, który nie wierzy, że potrafi podejmować odważne decyzje produktowe, przegina w drugą stronę produkując jeszcze więcej dokumentów, organizując jeszcze więcej spotkań, budując jeszcze bardziej szczegółowe roadmapy. Im większy lęk, tym grubszy mur papieru.

Dlaczego organizacje wymuszają ten teatr na swoich zespołach?

Najsilniejszy kontrargument wobec obserwacji Cagana pochodzi od Johna Cutlera i brzmi (mniej więcej) tak: zrzucanie problemu organizacji na jednego człowieka jest nieuczciwą formą teatru samą w sobie. Organizacje, które odbierają moc decydowania o produkcie zespołom produktowym, a później obwiniają product managerów za brak działania robią dokładnie to, co Cagan krytykuje, lecz na wyższym poziomie abstrakcji. Artykuł Cagana zaczyna się językiem empatii („chcę wierzyć”, „boli mnie to”), ale kończy się moralnym osądem.

Jak AI ujawniło, że artefakty product ownerów są trywialne do odtworzenia?

Artificial Intelligence nie przyszło zastąpić PM-ów. Przyszło im pokazać, czym tak naprawdę się zajmują, poprzez automatyzację zadań powtarzalnych. Mechanizm jest precyzyjny i działa na trzech poziomach:

1. Odebranie mocy dokumentom: Kiedy narzędzia typu ChatPRD tworzą PRD w 20 minut, pokazują, że te dokumenty to jedynie wzorce, które AI powiela. Jeżeli maszynę da się nauczyć Twojej pracy na podstawie wzorców, to zajmowałeś się formatowaniem, a nie myśleniem.
2. Odebranie mocy stanowiska: Jeżeli programista lub designer może poprosić LLM o wygenerowanie tych samych dokumentów, które robiłeś do tej pory, to rola pośrednika staje się zbędna.
3. Nadanie roli AI: Zamiast używać AI do przyspieszania starej pracy, AI może służyć jako Coach pomagający PM-om nauczyć się nowej pracy; skoncentrowanej na tworzeniu wartości (Value Creation).

Jak przestać tworzyć teatr product managerów? 3 kroki od poniedziałku

1. Zadzwoń do trzech klientów: Następnym razem, kiedy dostaniesz zadanie „napisz specyfikację nowej funkcji”, weź telefon zamiast otwierać Confluence. Porozmawiaj z trzema klientami, aby zebrać jakościowy Insight.
2. Podejmij jedną decyzję bez dokumentu: Wybierz najdrobniejszą decyzję produktową tego tygodnia i podejmij ją ustnie, na spotkaniu, biorąc za nią osobistą odpowiedzialność (Skin in the Game).
3. Mierz efekt, nie output: Przestań raportować „ile user stories napisałem”. Zacznij raportować „jaki problem klienta rozwiązaliśmy w tym sprincie”, używając metryk wynikowych (KPI).