Jeszcze niedawno standardem był 7-osobowy zespół Dev i magiczne Product Trio, o którym wszyscy mówili na konferencjach. A potem przyszedł AI i…

No właśnie, w kolejnym odcinku Dodane do Backlogu pogadaliśmy o tym jak aktualnie wyglada struktura i sposób pracy naszych zespołów i jak wpłynęła na nie rewolucja AI.

Jak zawsze z perspektywy naszych 4 różnych produktowych światów - od korpo po szybko rosnące scalę-upy.

Słuchaj na Spotify

lub Apple Podcast.

Czy “product trio” (PM + designer + inżynier) jeszcze istnieje
Ile osób realnie potrzeba dziś, żeby coś dowieźć - liczby z czterech firm
Presja “buy or build” - dlaczego enterprise musi teraz customować szybciej
Samotność w pracy z AI - cena małych, AI-native zespołów
Czy struktura organizacji będzie się zmieniać co kwartał?
🎁 Rundka na koniec: gdzie każdy z nas robi różnicę, której nie zrobi AI

Po więcej produktowych treści → sprawdź najnowsze wpisy, najpopularniejsze wśród czytelników, posłuchaj podcastu Dodane do Backlogu, albo skorzystaj z moich szkoleń.

Moje najważniejsze insighty z tej rozmowy:

1️⃣ Product trio się nie zmieniło, ale…
2️⃣ Presja “Buy or build” w SaaS
3️⃣ Product Pods po 1-3 osób - nowy standard w scale-upach
4️⃣ Samotność w pracy z AI
5️⃣ Gdzie PM jeszcze robi różnicę?

1️⃣ Product trio się nie zmieniło, ale…

Marcin (Celonis, 40 zespołów produktowych w firmie) zaczął od czegoś co mnie mocno zaskoczyło - u niego współpraca PM - inżynier - designer w ostatnich dwóch latach nie zmieniła się jakoś drastycznie.

Zmieniło się natomiast coś innego - sposób, w jaki AI jest wpleciona w tę współpracę.

“Na początku były takie zespoły, które u nas się tylko zajmowały AI. Mieliśmy wyodrębniony zespół projektowy, wyodrębniony inżynierski i oni byli doczepiani do innych zespołów jako eksperci. To się zupełnie zmieniło. Każdy ma już teraz w zespole specjalistów, którzy muszą rozumieć, czym jest AI.”

Celonis jako biznes platformowy (w tej samej kategorii co Palantir czy Microsoft) ma zespoły skupione wokół jednego North Stara: więcej, lepiej i szybciej zagregowanych danych dla klienta i to DYKTUJE strukturę organizacyjną firmy

Co się realnie zmieniło to moment podejmowania decyzji.

Kiedyś proces był liniowy: discovery → backlog → refinement- > wdrożenie.

Teraz prototypy (czasem robione przez samych inżynierów) powstają na bardzo wczesnym etapie, więc rozmowa przesuwa się z “czy to robić” na “kiedy to wypuścić”. A to “kiedy” bywa pod presją - Marcin ma w Slacku CEO, który śledzi każdy z 40 zespołów produktowych w stylu founder mode:

“no to dobra, to kiedy to w końcu wypuścimy?””

A jednak trzeba ten moment wybrać odpowiednio, mimo że mamy taką możliwość już zobaczenia tego dużo wcześniej.

Co ciekawe u Wojtka (też duże korpo → IMB) tempo wypuszczania feature’ów nie przyspieszyło drastycznie (duzi klienci on-prem i tak aktualizują się kwartalnie), ale mocno przyspieszyły developer toole - testowanie API, budowanie nowych integracji. To, co było wcześniej “upierdliwe”, teraz jest szybsze i przyjemniejsze, co zwalnia cykle myślowe na bardziej sensowne myślenie o produkcie, nie o mechanice.

2️⃣ Presja „Buy or build” w SaaS

Druga rzecz, którą Marcin wskazywał mocno, to zmiana reguł gry w enterprise SaaS.

Klienci korporacyjni Celonisa (ok. tysiąca, w tym część z największych firm na świecie) co roku na nowo liczą, czy taniej będzie przedłużyć licencję, czy zbudować podobny software wewnętrznie - teraz, kiedy AI obniża koszt budowania, ta kalkulacja robi się dla nich dużo bardziej atrakcyjna.

“To jest nieustanna walka w stylu buy or build. I to się kaskaduje na zespoły produktowe w niesamowitym tempie.”

Dawniej dobry PM w takim środowisku to taki PM co dużo MÓWIŁ NIE na różne pomysły - bo enterprise software musi być uniwersalny, żeby skalować się na wielu klientów.

Teraz presja idzie w drugą stronę: więcej customizacji, obrona konkretnych, sześciocyfrowych dealów, dopasowywanie się pod jednego klienta.

Marcin sam przyznaje, że jako firma “zachłystujemy się tym” i w sumie wciąż nie wiedzą, gdzie jest granica między tym, co da się zrobić wewnętrznie, a tym, co nadal lepiej kupić.

3️⃣ Product Pods po 1-3 osób - nowy standard w scale-upach

Pogadaliśmy tez o jednym bardzo konkretnym i dość obrazowym wskaźniku: ilu inżynierów przypada na jednego PM-a w naszych firmach:

Celonis (korpo, 40 zespołów): po ok. 6 osób każdy
IBM: ok. 1:21
Mixmax, Brainbits (sacleupy, poniżej 50 osób w całej firmie): od 0 do 3 inżynierów na inicjatywę, bez stałego designera w zespole

Kuba (Mixmax) opisał, jak bardzo to się zmieniło u niego w ciągu ostatnich dwóch latach:

od klasycznych zespołów po 8 inżynierów i stałego designera do płynnych, szybko zmieniających się grupek.
liczba PM-ów u niego w firmie wzrosła z 2 do 4, ale nie dlatego, że przybyło pracy - dlatego, że prototypy powstają teraz dużo wcześniej, a granica PM/designer się zatarła:

“PM na podstawie storybooków jest w stanie wygenerować prototyp, który jest w 80 procentach wizualnie poprawny. Inżynierowie przyspieszyli wielokrotnie, jeśli tylko specyfikacja czy prototyp są na odpowiednim poziomie precyzyjności dostarczone.
Więc teraz chyba wraca to, że my stajemy się bottleneckiem, a nie już koszt budowania czy czas budowania.”

U mnie ten trend wygląda podobnie, tylko poszedł jeszcze dalej - pracujemy w “podach” 1-3 osób, rzadko więcej. Świadomie zaczynam unikać nazwy “product manager” - bliżej mi do “product buildera”.

Kwartalnie wybieramy bety, co 1-2 tygodnie definiujemy opportunities pod te bety, a nad każdą pracuje od jednej do trzech osób - czasem bez mojego udziału wcale, jeśli inżynier ma mindset produktowy i poprowadzi temat end-to-end.
Efekt: firma urosła przychodowo i klientowo czterokrotnie w ostatnim roku bez zatrudniania nowych osób.
Cel jest wprost odwrotny do klasycznego scalowania zespołu - ograniczać headcount, a nie go zwiększać.

4️⃣ Samotność w pracy z AI

To był dla mnie najbardziej nieoczywisty insight tej rozmowy. Kuba przyznał się do czegoś, czego wcześniej nie doświadczał:

“Takie poczucie samotności podczas pracy w tych małych podach.
Właściwie całymi dniami gadamy z maszynami i to jest wystarczające, żeby wyprodukować coś end to end. Inne osoby uczestniczą, ale bardziej na zasadzie, że są satelitami w całej tej inicjatywie, niż że działamy wspólnie, ramię w ramię.”

Widziałem ten problem też u siebie - i opisałem, jak z nim walczę. Gdy dołączałem do ostatniego scaelupu, widziałem że tam praca solo poszła… za daleko - każdy pracował nad swoimi pomysłami, bez wspólnego kierunku.

Dwie rzeczy, które mi pomagają:

Wspólne wybieranie strategicznych betów (my wybieramy na kwartał) zamiast luźna realizacja pomysłów, bo przecież “wszystko da się zbudować”
Kanał dla każdej inicjatywy, żeby inne osoby miały wgląd i mogły dać feedback - druga para oczu wyłapuje rzeczy, o których osoba pracująca samotnie z AI po prostu nie pomyślała (np. wpływ na customer service).
Praca w tych małych podach (a nie tylko solo) i… więcej human in the loop - przynajmniej raz w tygodniu wspólny “refinement” inciajtywy nad która pracujemy

Mój kalendarz to dobrze pokazuje - dwa, trzy spotkania w tygodniu na moje “pody”, a reszta to deep work.

5️⃣ Gdzie PM jeszcze robi różnicę?

Na koniec zadałem pytanie, które moim zdaniem jest teraz kluczowe dla każdego PM-a: gdzie dokładnie robisz różnicę, której nie zrobi ktoś, kto po prostu lepiej rozmawia z AI?

[Kuba] Szybsza walidacja hipotez dzięki produktowemu warsztatowi:
- „Jeśli wiesz, co robisz, to szybciej walidujesz hipotezy. Do tej pory bottleneckiem była szybkość budowania i walidowania hipotez. Jeśli nadal używasz swojego judgmentu do tego, jakie hipotezy stawiać, a możesz zrobić tego więcej, to zwiększasz swoje szanse, że w końcu trafisz.”
[Ja] stawianie i pilnowanie strategicznych betów:
- „Ludzie pracujący z AI widzą problem i chcą go jak najszybciej rozwiązać - nie zastanawiają się, który problem w ogóle warto rozwiązać.”
[Wojtek] Kontekst biznesowy:
- “Implementując coś do Tableau czy Databricksa, niekoniecznie rozumieją, po co to jest klientowi, czy to w ogóle jest właściwy problem. To wnoszę do stołu, jednocześnie wchodząc z nimi w techniczną polemikę.”
[Marcin] Osąd przedsiębiorcy (z doświadczenia dwóch własnych, nieudanych startupów) i znajomość produktu
- Umiejętność dostrzeżenia, czego brakuje: w procesie, komunikacji, jakości materiałów.
- Plus jedna rzecz, która go szczerze irytuje: PM-owie, którzy nie znają swojego produktu poza własnym feature’em. “Jeśli jedną rzecz ktoś może zrobić, żeby się wyróżnić - naprawdę rozumieć cały produkt, wiedzieć, na czym inni pracują.”

Słuchaj na Spotify

🎧 Posłuchaj pełnej rozmowy (bonusy):

W pełnej rozmowie jest dużo więcej niż to, co zmieściłem tutaj w tym wydaniu. Znajdziesz tam między innymi:

Dlaczego reorganizacje w dużych firmach (Marcin: czwarty manager w trzy lata) dzieją się co roku niezależnie od AI - i co z tym ma wspólnego CFO
Czy magiczna “siedmioosobowa” struktura agile’owa w ogóle ma dziś sens, czy to tylko relikt czasów, kiedy budowanie było drogie
Halloweenowe żarty Marcina (ostrzegam - jest poziom Karola S 😅)
Więcej o tym, jak Wojtek pracował bez stałego “trio” przez całą swoją karierę w Zendesku i IBM

Na koniec odcinka zapytaliśmy Was: gdzie Wy czujecie, że robicie różnicę, której nie zrobi AI?

Napiszcie w komentarzu - bo jak powiedziałem w odcinku, jeśli komentarze będą puste, to będzie to znaczyć, że nikt nie robi żadnej różnicy 😏 ⤵️

Zostaw komentarz

Product Craft

Jak AI zmieniło nasze zespoły produktowe?