Co się dzieje z Product Managementem?
Product Management właśnie się zmienia. Fundamentalnie. I dlatego wracam "na front".
Hej,
Tydzień temu napisałem szczerą spowiedź po 2 latach prowadzenia Product Academy i o mojej strategicznej decyzji… powrotu do hands-on pracy przy produkcie AI.
„Dlaczego gość, który właśnie pochwalił się milionem przychodu i wolnością, dobrowolnie wraca do biura? Dlaczego wraca na front?”.
Krótka odpowiedź: bo inaczej za 2 lata nie będę rozumiał na czym polega tworzenie produktów. Dłuższa - bo tak wynika z mojej strategicznej diagnozy i „betu”, które znajdziesz w tym newsletterze.👇
W dzisiejszym wydaniu:
Diagnoza: co się dzieje z product managementem?
Zmiana 1: Budowanie produktów AI to „inna gra”
Zmiana 2: Zmienia się sposób budowania produktów i rola PM-a
Trzy scenariusze przyszłości PM-a
Kierunek 1: Product Builder / Maker
Kierunek 2: Market-Focused PM
Kierunek 3: Małe elitarne „super IC”
Mój strategiczny „BET”
Mam ostatnio silne poczucie déjà vu w kontekście technologii i rozwoju produktów cyfrowych. Mam głębokie poczucie i intuicję, że świat wokół mnie właśnie się zmienia. Fundamentalnie.
Podobnie czułem się dwa razy w życiu:
1️⃣ Po raz pierwszy, gdy jako nastolatek zobaczyłem i doświadczyłem internetu. Pamiętam to uczucie, gdy zrozumiałem, że mam prawie wszystko na wyciągniecie ręki, że mogę stworzyć „stronę WWW” i pokazać ją światu. Że nie potrzebuję niczyjej zgody, żeby budować.
To pchnęło mnie w tworzenie stron internetowych, studia informatyczne, a potem w świat startupów i produktów cyfrowych.
2️⃣ Po raz drugi w 2017 roku, gdy zacząłem działać z AI - deep learning, sieci neuronowe, modele, które "uczą się" na danych. Zafascynowałem się tym, jak bardzo ta technologia zmienia możliwości, które możemy mieć w produkcie. I wiedziałem, że chcę być jej częścią.
Dlatego poświęciłem pół roku na naukę podstaw ML i w 2018 dołączyłem do SentiOne jako R&D Product Manager. Budowaliśmy Conversational AI, zanim to było modne. NLU, NLP, F1 score, accuracy - to była moja codzienność.
W obu tych momentach byłem pewny jednego:
Nie chcę tych zmian obserwować z boku. Chcę być ich częścią.
Stąd moje duże decyzje o tym czym zająłem się w kolejnych latach. Czułem, że tylko tak mogę naprawdę zrozumieć, co się dzieje i dalej tę przyszłość współtworzyć.
Teraz, w erze LLM-ów, czuję tę ekscytację po raz trzeci 3️⃣:
Z jednej strony - gigantyczne możliwości, które dają LLMy.
Z drugiej - kompletna niewiadoma, gdzie nas to wszystko zaprowadzi.
Widzę, że budowanie produktów przechodzi właśnie fundamentalną zmianę i muszę na nią strategicznie zareagować. Dlatego, tak jak przy budowie strategii produktowej:
Zacząłem od diagnozy sytuacji - co moim zdaniem dzieje się w świecie produktu
Zdefiniowałem trzy potencjalne scenariusze przyszłości produktowej PMów,
A na końcu postawiłem na swój “strategiczny bet”.
Zaczynamy.
1. Diagnoza: co się dzieje z product managementem?
Moja diagnoza oparta jest na 2 źródłach:
Staram się śledzić wypowiedzi liderów produktowych mających wpływ na product management (Marty’ego Cagana, Teresy Torres, Lenny’ego Rachitsky’ego, Shreyasa Doshiego, Claire Vo, Petera Yanga) jaki liderów zespołów produktowych z topowych firm takich jak FAANG, OpenAI czy Anthropic.
Z racji mojego działania jako edukator i konsultant widzę co się dzieje od środka w różnych firmach, produktach, rozmawiam z wieloma PMami pracującymi na froncie rozwoju produktów.
Od dłuższego czasu obserwuję dwie fundamentalne zmiany, których katalizatorem są AI i LLMy.
Zmiana 1: Budowanie produktów opartych o AI to „inna gra”
Doświadczyłem tego już w 2018 roku w SentiOne. Wtedy zaczynał królować Deep Learning i Sieci Neuronowe. I pamiętam szok, gdy po pół roku nauki podstaw ML stanąłem twarzą w twarz z zespołem R&D dla którego byłem PO i z którym rozwijałem produkt Conversational AI - SentiOne Automate.
Mimo że byłem doświadczonym PM-em (około 8 lat), to było bolesne zderzenie. Połowę tego co wiedziałem o rozwoju produktów musiałem uczyć się od nowa.
Niedeterministyczne produkty
Dlaczego? Bo w AI probabilistyka zastępuje deterministyczny kod, a zespoły Data Scientist i ML Enginerów pracują inaczej niż typowe zespołem developerskie. Przygotowanie i jakość danych na których uczą się modele, szybko może się okazać ważniejsza niż jakość kodu. F1 score, model accuracy, etykietowanie danych - to była wtedy moja nowa codzienność.
Przez dekady budowaliśmy deterministyczne produkty rozwiązując tzw. problemy obliczeniowe („computational problems”). Schemat jest prosty: masz dane wejściowe, piszesz reguły w kodzie, dostajesz wynik. Przykład: zapłacenie za produkt w e-commerce (user wybiera produkt, system stosuje ceny, rabaty, podatki - i dostaje rachunek)
Teraz, dzięki probabilistycznym rozwiązaniam, możemy rozwiązywać tzw. problemy wymagające uczenia się („learning problem”). I tu schemat jest odwrócony: zamiast pisać reguły, dajesz modelowi tysiące przykładów. Model sam “uczy się” reguł, których nie potrafisz wyrazić. Przykład: rozpoznanie co jest na obrazku, albo “namalowanie” obrazka.
Te dwa światy w kontekście budowy produktów działają inaczej:
Teraz, z LLM-ami, jest podobnie. Tylko jeszcze intensywniej.
Wtedy modele AI wspierały poszczególne funkcje produktu. Teraz LLM-y często SĄ produktem lub jego corową cześcią. Pozwalają tworzyć, a nie głownie rozpoznawać. Ogromne znaczenie maja dane wejściowe (context). Zmieniają całkowicie flow pracy użytkowników. Ich wpływ jest fundamentalny.
Nowe kompetencje, bez których nie zbudujesz dobrego produktu z LLMem
Teraz z przy pracy z modelami LLM, dochodzą kolejne aspekty, które są kluczowe dla tworzenia dobrych produktów. Tu wymienię tylko najważniejsze z nich:
Zarządzanie niepewnością - wyniki modelu mogą nie odpowiedzieć na Twoją hipotezę. I to nie jest bug - to norma. Musisz mieć umiejętność komunikowania stakeholderom, że "model działa w 87% przypadków" i dlaczego to może być świetny wynik. Musisz bardzo mocno zajmować się edukacją leadershipu i wspólnie pracować z innymi działami - jaki to będzie miało na nie wpływ na Customer Service, Marketing itp.
Context Engineering - bardzo szybko okazuje się, ze zaczynasz pracować nie z devloperami nad kodem, tylko nad „Promptami” - bo to INPUT do LLMa ma zasadnicze znaczenie w kontekście tego jak działa produkt. Mała zmiana promptu - może mieć gigantyczne znaczenie w kontekście tego jak działa produkt. Oczywiście temat jest szerzy - to cały sposób budowania, tworzenia, pracy z INPUTEM który dostarczamy LLMowi - czyli tzw. Context Engineering.
AI Evals – zupełnie inaczej zaczynasz podchodzić do ewaluacji produktu. Nie testujesz "czy feature działa", tylko "jak często model daje akceptowalną odpowiedź" i "jakie są edge case'y, które go łamią".
Technical fluency na nowym poziomie - nie chodzi mi tutaj o pisanie kodu produkcyjnego. Jeśli modele mają gigantyczne znaczenie dla sukcesu produktu, to musisz jednak rozumieć ich zachowanie, ograniczenia kontekstu, jakość danych, trade-offy między latencją a jakością. Bez tego nie będziesz w stanie prowadzić sensownych rozmów z zespołem technicznym.
Panowanie nad kosztami LLMów - w tradycyjnym rozwoju produktu, zwykle najważniejszym kosztem była praca ludzka. W LLM każde wywołanie kosztuje (czy tokeny w zewnętrznym model, czy też duże koszty sprzętowe we własnych modelach). To powoduje, że dużo bardziej musisz myśleć nad trade-ofami z tymi związanymi.
Do tego dochodzi choćby często brak kontroli nad “silnikiem” (W LLM-ach często używasz modelu zewnętrznego np. GPT), inne podejście do cenników, znaczenie latency (czas odpowiadania LLMów), znaczenie “Context window”, halucynacje itp.
To nie znaczy, że fundamenty product managementu się nie liczą
Wręcz przeciwnie.
“When building becomes easy, deciding what to build becomes everything.” - Teresa Torres
Discovery, empatia do użytkownika, product sense - to wszystko staje się WAŻNIEJSZE, nie mniej ważne. Bo jeśli AI umożliwia zbudowanie czegokolwiek szybko i tanio (o tym w drugiej części diagnozy), przewagą jest wiedzieć, co warto zbudować.
Ale sam fundament nie wystarczy. Potrzebujesz fundamentu PLUS nowych kompetencji specyficznych dla AI.
To trochę jak kiedyś przejście z produktów fizycznych na cyfrowe. Z jednej strony – fundamenty budowy produktów są te same. Z drugiej - PM produktu cyfrowego potrzebował innych kompetencji niż PM produktu fizycznego. Dlatego tak trudno było “starym” PM-om przeskoczyć w nowe środowisko.
Historia się powtarza.
Zmiana 2: Zmienia się sposób budowania produktów i rola PM-a
Przez ostatnią dekadę żyliśmy w świecie, gdzie sukces produktu = więcej ludzi. Wielkie zespoły, wąskie specjalizacje. PM, Designer, kilku inżynierów, UX Researcher, PMM, Content, Analityk danych...
Firmy AI-native – OpenAI, Anthropic, Cursor – celowo opóźniają zatrudniają PMów i finalnie zatrudniają ich mniej. Nie dlatego, że nie stać ich na więcej. Ale dlatego, że wierzą w inny model.
Talent density > headcount - te firmy wolą mały zespół świetnych ludzi niż armię średniaków. Chcą małych, elitarnych zespołów.
Doskonale to widziałem na Product Camp Berlin kilka miesięcy temu: Dwie prędkości PM-ów.
Z jednej strony – masa ludzi, dla których AI to “fajny dodatek”. Napisze im może user story. Czasem przyspieszy research. Ale sposób ich pracy? Ten sam co 5 lat temu. Scrum, Jira, PRD-y, spotkania, spotkania, spotkania.
Z drugiej strony – garstka osób, które na prezentacjach o “podstawach AI w pracy PM-a” miały szeroko otwarte oczy. Ale nie dlatego, że się czegoś nowego uczyły. Dlatego, że dla nich to już był obcy świat.
Małymi zespołami robili rzeczy, które dużym firmom zajmują miesiące. Szybki research, szybka walidacja i szybka iteracja pomysłów. Mają swoich agentów do różnych produktowych tematów. Pracują ramie w ramie z zespołami, a nie “zarządzają taskami”. Bez wymówek, że potrzebujemy 15 kompetencji i ludzi, żeby coś zweryfikować i finalnie zbudować.
To był zupełnie inny poziom i sposób pracy.
Dawno coś tak bardzo mnie nie zainspirowało i było różne od tego co wiedziałem w tradycyjnych zespołach produktowych. I było dużym wkładem do moich rozkmin o przyszłości roli PMa ⤵️
2. Trzy scenariusze przyszłości PM-a
Zebrałem więc swoje doświadczenia + przeanalizowałem dziesiątki wypowiedzi produktowych liderów i widzę trzy wyraźne, choć różniące się od siebie scenariusze w którą stronę idzie product management. Każdy ma swoich zwolenników. Każdy ma sens w określonym kontekście. I nie wykluczam, że wszystkie trzy będą współistnieć.
Kierunek 1: Product Builder / Maker
To najbardziej radykalna wizja - rola product managera przestanie istnieć:
Tradycyjny podział PM / Designer / Engineer się rozpada. Powstaje nowy typ: "Product Builder / Maker" - jedna osoba, która dzięki AI robi robotę całego Product Trio / Zespołu produktowego.
Dzięki AI oraz narzędziom takim jak Cursor czy Lovable/v0, Product Maker jest w stanie samodzielnie przejść z pomysłem cały proces od idei, przez research, po stworzenie działajacego rozwiązania.
"I can build the MVP solo in a week" - to jest value proposition tego archetypu PMa.
Główną zwolenniczką tego kierunku jest Claire Vo (CPO LaunchDarkly, autorka How I AI). Twierdzi ona wprost, że “product management as we know it is over” i jednoosobowa hybryda mogąca pracować nad strategią, discovery, kodować - będzie zajmować się budową produktów.
Kierunek 2: Market-Focused PM
Jeśli “budowanie” staje się towarem dostępnym dla każdego dzięki AI, to co staje się wyróżnikiem? Narracja, Brand i Go-to-Market.
W tym scenariuszu PM oddziela od Product Trio i łączy się kompetencyjnie z Product Marketing Managerem. Zajmuje się rynkową narracja produktu, spójnością, monetyzacją i market fit, a nie za rozwiązywanie konkretnych problemów użytkowników.
Brian Chesky zrestrukturyzował Airbnb właśnie w tym kierunku - eliminując klasycznego PM-a pracującego z zespołem DEV na rzecz hybrydy z Product Marketerem.
"I can ensure the market understands and buys what we build" – to jest value proposition tego archetypu PMa.
Kierunek 3: Małe elitarne zespoły produktowe
To wizja bliższa tradycyjnemu modelowi, ale z AI jako supermocą, która pozwala małemu elitarnemu zespołowi (jakaś formą Product Trio) robić cały product management.
Narzędzia przejmują 50-70% operacyjnej “bieżączki” dla każdej z ról Product Trio, a członkowie zespołu produktowego stają się “super IC” (Individual Contributor), czasem też nazywanych “T-shaped builders” - ludzi z głęboką ekspertyzą w jednym obszarze i wystarczającą szerokością, żeby kontrybuować w wielu innych.
Dzięki temu razem, małym zespołem, są w stanie samodzielnie i ekspresowo przejść z pomysłem cały proces od idei, przez research, po stworzenie działajacego rozwiązania.
PM w tym modelu skupia się na strategii, discovery, i decyzjach “co NIE budować”.
Każdy z Product Trio ma swoje specjalizacje, jednak role mocno się przenikają i nikt nie chowa się za procesem. PM nie boi się tworzyć prototypu i spojrzeć w kod, Product Engineer nie boi się ewaluować pomysłów i zajmować się discovery.
Marty Cagan i Teresa Torres są głównymi zwolennikami tej wizji.
3. Mój strategiczny „BET”
Który scenariusz wygra? Szczera odpowiedź: Nie wiem.
I nikt nie wie. Nawet Cagan, Torres czy Vo. Te zmiany się dzieją teraz, w czasie rzeczywistym i efekty są różne w różnych firmach.
Ale wiem jedno: żeby mieć własne zdanie, muszę to poczuć na własnej skórze:
Jak wygląda praca przy produkcie AI z milionami generacji LLMa miesięcznie?
Jak strategia, discovery i ewaluacja działają, gdy model jest probabilistyczny a nie deterministyczny?
Jaką wartość wnoszę do zespołu w świecie AI? Czy moje kompetencje są jeszcze potrzebne? A jeśli tak - to jakie?
Tego nie dowiem się z artykułów, podcastów, książek.
Tylko z praktyki w produkcie, który generuje miliony requestów do LLM-ów miesięcznie. Gdzie są realni użytkownicy, realne problemy i realne konsekwencje podejmowanych decyzji.
Mój bet jest prosty:
Sposób budowania produktów zmienia się tak szybko, że nie da się tego obserwować z boku. Muszę być w środku tej fali.
Kto teraz nie wsiądzie do pociągu budowy produktów hands-on z AI, za 2 lata nie będzie rozumiał co się dzieje i dlaczego (poza książkową teorią).
Nigdy nie chciałem być “konsultantem-szkoleniowce”, który uczy teorii z książek i cudzych case studies. Nie wierzę w taką drogę. Zawsze bazowałem na własnych doświadczeniach, własnych porażkach i sukcesach, własnej “skin in the game” (uwielbiam to określenie).
Dlatego w połowie roku podjąłem strategiczną decyzję:
Wracam do pracy operacyjnej przy produkcie
Od sierpnia pracuję jako Head of Product w BrainBits.AI w którym:
AI jest corem działania - Conversational AI, LLM jest sercem produktu, a nie tylko SaaSem z dodatkiem AI. Mnóstwo generacji miesięcznie, prawdziwe problemy z prompt engineeringiem, doborem modeli, halucynacjami, latencją, AI Evals.
Mały zespół złożony z “super” IC - nie ma rozbudowanej struktury. Nie ma „PM który tylko pisze tickety,". Każdy musi być fullstackowy. Każdy musi rozumieć produkt end-to-end.
Realny wzrost i skala: ~30-40% growth w ostatnich 3 miesiącach. Produkt z użytkownikami, przychodami i ciśnieniem, żeby dowozić wartość.
Wierzę, ze jest to setup w którym mogę weryfikować swoje hipotezy o tym, jak wygląda dobry product management w erze AI - zarówno od strony budowy produktów AI, jaki i pracy samego PMa.
Zapraszam na relację z frontu
A co to wszystko znaczy dla newslettera i działalności Product Academy?
Nie znikam. Dalej będę pisał. Dalej będę prowadził szkolenia.
Ale aktualizuję źródło wiedzy - zamiast „wspomnień weterana" będzie więcej "relacji z frontu" o tym jak budować produkty - jak teoria zderza się z rzeczywistością budowania produktów AI w 2025 roku.
Zapraszam Cię do obserwowania tej drogi. Pierwsze wnioski po 4 miesiącach już w następnym wydaniu ;)










Świetny tekst. Mam wrażenie, że masz obserwacje zbliżone do Wiktora: https://open.spotify.com/episode/1q42nfU57s57a0ABMW7i6W?si=dea1ecfc5da34152
Dodam, że zupełnie nieświadomie (niejako z konieczności) wszedłem w sam środek tej nowej rzeczywistości, nagle się okazało, że mogę eksperymentować ze swoim pomysłem biznesowym startując z poziomu prawie gotowego produktu zbudowanego w kilka godzin. Zamiast szukać jakichś dostępnych sposobów na szybką walidację pomysłu (typu post na Facebooku). Nagle mogę postawić rozbudowany serwis do sprzedaży usług w kilka-kilkanaście godzin. Bez zatrudniania grafika i programisty bez kijowych templatek z Wordpressa, bez spędzania X dni na nauce "PHP4 dla opornych" i "MySQL od podstaw" :D
Może nadszedł wreszcie czas ludzi, którym gorzej wychodzi praca w zespole i duża fragmentaryczność zadań, a lepiej się sprawdzają samodzielnie ogarniając większe kawałki rzeczywistości.
Pochwalę się -> olgajurewicz.com
I tuż za tym buduje się -> heartmade.pl
Świetny tekst, Tomasz! Firmy technologiczne są coraz bardziej zróżnicowane i działają na różnych prędkościach. Myślę, że organizacje, które mają uporządkowane fundamenty - dane, dynamiczne eksperymentowanie, CI/CD - mogą świadomie wybierać między scenariuszami, które opisałeś. Każdy z nich może się sprawdzić, w zależności od branży, etapu rozwoju i skali. Być może będą rozwijać się równolegle, może dojdą nowe scenariusze? Może na tym będzie polegała główna zmiana w product management - nie będzie jednego dominującego scenariusza?
Mam hipotezę, że PMowie z pierwszej prędkości w Twoim tekście działają w firmach bez tych podstaw. Przez jakiś czas będą koncentrować się na automatyzacji zadań tradycyjnego PM-a, zamiast spojrzeć szerzej na swój sposób działania - bo to po prostu łatwiejsze. W raporcie o polskim DevEx (https://www.networkperspective.io/devex-w-polskich-zespolach) widzimy, jak takie lokalne usprawnienia w delivery dają ułudę efektywności, a z czasem przynoszą więcej problemów niż korzyści. Myślę, że analogicznie będzie w product management. Bez zbudowania fundamentów organizacjom trudno będzie nadążyć za tempem firm, które je mają. Pociąg odjedzie. Jestem ciekawa, jak szybko taka polaryzacja firm pojawi się na rynku i jakie przyniesie skutki. Masz swoje hipotezy?
Z ciekawością będę śledzić Twoje przemyślenia - dzięki, że się nimi dzielisz!