Jak jeden Product Owner może pracować z wieloma zespołami? Jak może monitorować wartość, gdy zespoły równocześnie tworzą dziesiątki małych zmian?
Krótka odpowiedź: nie może, jeśli jego backlog to wielka lista ficzerów.
W artykule opisuję, jak w G2A przeszliśmy z backlogu ficzerów na backlog problemów biznesowych, dlaczego monitorujemy wyniki i zachowania użytkowników zamiast dowozić ficzery, no i co to zmieniło w praktyce.
W większości firm, które odwiedzam, spotykam w product developmencie kilkunastu Product Ownerów. Każdy z nich zarządza backlogiem swojego zespołu. Priorytetyzuje zadania, pisze user stories, odpowiada na pytania deweloperów i… zarządza zależnościami między zespołami. Brzmi znajomo?
Problem w tym, że ta rola ma niewiele wspólnego z tym, czym Product Owner powinien się zajmować.
Michael James (LeSS Trainer z Seattle) celnie nazwał tych ludzi TOO - Team-Output Owners. Zarządzają outputem swojego zespołu. Nie mają wpływu na strategię produktu, nie mierzą wyników biznesowych, nie podejmują decyzji o tym, co naprawdę przynosi wartość. Są analitykami potrzeb, menedżerami listy zadań i koordynatorami i... nie jest to ich wina.
Powiedziałbym tu:
System organizacyjny, w którym pracują, nie pozwala im na nic więcej.
Rolą Product Ownera jest "Maksymalizacja Wartości Produktu".
Nie: zarządzanie listą zadań dla jednego zespołu.
Nie: koordynacja zależności i planów.
Nie: pisanie user stories.
Nie: priorytetyzowanie ficzerów / tasków.
Ktoś by zapytał:
"Ale Krzysiek, przecież 'Wartość' to też może być coś dostarczane dla drugiego działu, czy zespołu, prawda?".
A no nie prawda. Taka "Wartość" to nic innego jak pośredni artefakt na drodze do klienta, o którym klient nie wie i za który wcale nie chce płacić. W filozofii LEAN nazwalibyśmy ten pośredni artefakt jako WASTE.
Ciekawe jest to, że mnóstwo firm wytwarza WASTE, przerzucając pośrednie artefakty od zespołu do zespołu, nazywając to WARTOŚCIĄ. Ale to temat na inny artykuł. Wracając…
Problem w tym, że ludzie dziwnie definiują to, czym jest produkt. Ja lubię prostą definicję:
"Produkt dostarcza na rynek wartość (czyli do końcowego usera) i ma swój strumień zwrotu."
Oznacza to, że Właściciel Produktu powinien odpowiadać zarówno za dostarczaną wartość, jak i za strumień zwrotu (wyniki biznesowe).
Sytuację dramatycznie poprawia rozszerzenie definicji produktu na szerszą, biznesowo znaczącą całość, czyli dokładnie tak, jak proponuje podejście LeSS. W konsekwencji tworzymy jeden szeroko określony produkt z jednym prawdziwym Product Ownerem i wieloma zespołami pracującymi na wspólny, biznesowy sukces.
Uwaga: Jeśli nazwa Product Owner cię mierzi, kojarzy się źle, to zmień ją na inną: Product Manager / Head of Product / Business Owner etc. Nie ma to znaczenia. Niemniej, odpowiedzialność za wartość i strumień zwrotu pozostaje, tak samo jak to, że jeden, szeroko zdefiniowany Produkt będzie miał jednego tzw. Właściciela Produktu, bez potrzeby posiadania dodatkowych TOO. Jeśli potrzebujesz czynności analizowania, pisania user stories itp., którymi wcześniej zajmował się TOO, to po prostu dołącz go do zespołu z czapką "Współtwórca" (Developer). To zmieni dynamikę pracy zespołu, bo od teraz cały zespół będzie równy sobie.
W G2A produktem jest "marketplace for digital goods". Czyli nie "system płatności", nie "moduł wyszukiwania", nie "panel sprzedawcy". Jeden, szeroko określony produkt. Jeden Product Owner. 11 zespołów.
I tu pojawia się wątpliwość, którą słyszę za każdym razem:
"Jak jeden PO może ogarnąć backlog tych wszystkich zadań dla 11 zespołów i jeszcze odpowiadać za wyniki biznesowe?"
Krótka odpowiedź: nie może. I nie powinien.
To pytanie ujawnia głębszy problem. Jeśli Twój backlog to lista tasków i ficzerów, to jeden PO faktycznie tego nie ogarnie. Trzeba zmienić myślenie o tym, czym jest Product Backlog.
Scrumowcy powiedzieli by, że Scrum Guide mówi o Product Backlogu:
"The Product Backlog is an emergent, ordered list of what is needed to improve the product."
"What is needed to improve the product" to nie jest "lista ficzerów do zbudowania". A jednak w większości firm Product Backlog to właśnie ogromna lista ficzerów, tasków i zmian technicznych. Nawet roadmapy mają w formie rozpisanych ficzerów.
Zauważ, jak szerokość definicji produktu wpływa na to, co naturalnie trafia na backlog.
Wąska definicja produktu np. "system fakturowy" powoduje, że backlog takiego produktu będzie zawierał wszelkie taski związane z tym systemem, także techniczne. Backlog szybko staje się listą zadań do wykonania. Szeroka, biznesowa definicja produktu np. "marketplace for digital goods" powoduje, że backlog takiego produktu naturalnie przesunie się w stronę zmian przynoszących wartość biznesową, a nawet problemów i szans do zaadresowania.
Ale nawet przy szerokiej definicji produktu backlog ficzerów ma fundamentalny problem. Marty Cagan z SVPG diagnozuje go precyzyjnie, rozróżniając feature teams od empowered product teams. Feature teams (w rozumieniu SVPG) dostają ficzery do zbudowania, budują je, dostarczają i nikt nie sprawdza, czy to cokolwiek zmieniło. To jest model, który Cagan nazywa "delivery teams" w którym zespoły dostarczają output i nie są odpowiedzialne za outcome.
Product Owner w takim modelu staje się priorytetyzatorem ficzerów. Decyduje, który ficzerek zbudować następny, zamiast jaki problem rozwiązać. Im więcej zespołów, tym więcej ficzerów na backlogu, tym bardziej PO tonie w zarządzaniu listą zamiast myśleć o wynikach.
I tu tkwi pułapka: nie da się z niej wyjść dodając kolejnych proxy-PO. Każdy kolejny TOO tworzy kolejną lokalną optymalizację. Jego zespół dostarcza swoje ficzery, ale nikt nie patrzy, czy to, co robimy jako organizacja, naprawdę robi różnicę i czy faktycznie zespoły pracują nad tym co przyniesie organizacji maksymalne wyniki. Czy to nie była wcześniej rola Project Managera? Ma dowieźć, ale nie podważa zasadności samoego projektu i nie odpowiada za rezultaty biznesowe po wdrożeniu.
W G2A podjęliśmy decyzję, która zmieniła sposób, w jaki pracujemy: zamiast roadmapy ficzerów pracujemy z Opportunity Solution Tree (OST, Teresa Torres).
Product Backlog nie zawiera ficzerów wymyślonych pół roku temu gdzieś w zarządzie na spotkaniu strategicznym. Zawiera problemy biznesowe i szanse do zaadresowania. Oto jak to wygląda w praktyce:
Na szczycie jest cel biznesowy, czyli metryka, którą chcemy poprawić. Może to być North Star Metric lub metryka wspierająca. Na przykład: zwiększenie konwersji w konkretnym segmencie kupujących, poprawa retencji po pierwszym zakupie, wzrost wartości koszyka.
Pod celem są zidentyfikowane Opportunities. To są realne problemy lub szanse użytkowników, które wpływają na tę metrykę. Nie są wymyślone przy biurku - pochodzą z danych, z badań, z rozmów z klientami. Na przykład: "kupujący nie ufają ofertom z niską ceną", "nowi użytkownicy nie rozumieją jak działa marketplace", "sprzedawcy nie wiedzą jak wycenić swoje produkty konkurencyjnie".
PO priorytetyzuje Opportunities, nie rozwiązania. Decyduje, który problem zaadresować następny. To fundamentalna zmiana: PO nie mówi zespołom "zbudujcie ten ficzerek", ale "ten problem jest teraz najważniejszy dla naszego biznesu".
Zespoły biorą priorytetowe Opportunity i samodzielnie iterują po rozwiązaniach. Generują pomysły, identyfikują ryzykowne założenia, projektują eksperymenty, testują co działa. Zespół nie "dowozi ficzerka", tylko zespół pracuje nad osiągnięciem wyniku, rozwiązaniem problemu lub udowadnia, że dane podejście nie działa, i pivotuje na inne rozwiązanie.
Pokażę to na przykładzie. Załóżmy, że PO priorytetyzuje Opportunity: "Kupujący porzucają koszyk, bo nie ufają ofertom z bardzo niską ceną." Zespół badający ten problem może wygenerować trzy rozwiązania:
Dodanie social proof - wyświetlenie liczby sprzedanych sztuk i ocen sprzedawcy przy ofercie.
Gwarancja platformy - wyraźny komunikat, że G2A gwarantuje zwrot pieniędzy w przypadku problemu.
Zmiana prezentacji ceny - pokazanie ceny referencyjnej (np. ceny na Steam po rabacie) obok ceny na G2A.
Zamiast budować wszystkie trzy, zespół testuje założenia. Może najpierw zrobi prosty A/B test z social proof, zmierzy wpływ na konwersję, i dopiero wtedy zdecyduje, czy kontynuować to rozwiązanie, czy pivotować na inne. Jeśli social proof podnosi konwersję o ustalony wskaźnik, np. 3%, to mamy sukces, Opportunity zaadresowane. Jeśli nie, to zespół testuje kolejne rozwiązanie.
Zamiast dowozić zmiany, monitorujemy wyniki. To jest kluczowa zmiana paradygmatu. W modelu ficzerowym sukces oznacza: "ficzerek jest na produkcji". W modelu outcome-driven sukces oznacza: "metryka się poprawiła". Zdeployowany ficzerek, który nie poprawił metryki, nie jest sukcesem, tylko jest informacją, że trzeba spróbować inaczej.
Teraz wróćmy do tego "niemożliwego" pytania: jak jeden PO może pracować z 11 zespołami?
Odpowiedź jest prosta, gdy zmienisz to, czym jest backlog. PO przestaje zarządzać ficzerami, a zarządza strategią. Ustala cele, priorytetyzuje kolejne problemy do zaadresowania przez zespoły biznesowo-techniczne. Nie musi wiedzieć, jaki ficzerek zespół buduje w danym Sprincie (choć akurat u nas wie :) ) - musi wiedzieć, nad jakim problemem pracują i jakie wyniki osiągają.
W praktyce wygląda to tak:
PO utrzymuje 3-5 priorytetowych Opportunities w danym momencie. Nie 400 ficzerów. Ma 3-5 problemów biznesowych, które teraz są najważniejsze dla produktu.
1-3 zespoły pracują nad jednym Opportunity. Zespoły same decydują, jakie rozwiązania testować. Mają pełną autonomię w "jak", ale cel ("jaki problem rozwiązujemy" i "jak zmierzymy sukces") ustala PO.
Zespoły monitorują metryki i iterują. Raportują wyniki, nie taski. Rozmowa na Sprint Review (btw. zmieniliśmy nazwę na Product Review) nie brzmi "zrobiliśmy 15 story pointów i zdeployowaliśmy 3 ficzery", ale "testowaliśmy dwa podejścia do problemu X, podejście A podniosło konwersję o 2%, podejście B nie dało efektu, w następnym Sprincie będziemy rozwijać podejście A".
Gdy dane Opportunity jest zaadresowane, zespoły pobierają kolejne z wierzchołka Product Backlogu. Metryka się poprawiła? Świetnie, przechodzimy do następnego problemu w kolejności priorytetów. To jest organiczny, ciągły przepływ pracy skupiony na wynikach.
Powiedziałbym:
Rola PO w tym modelu to rola stratega, nie menedżera backlogu.
PO spędza czas na zrozumieniu rynku, analizie danych, rozmowach ze stakeholderami i klientami, a nie na pisaniu user stories i priorytetyzowaniu setek ficzerów. To jest PO, o jakim mówi Scrum Guide: osoba odpowiedzialna za maksymalizację wartości produktu.
Chcę podkreślić coś, co może nie być oczywiste: przejście na outcome-driven backlog oznacza, że robimy dużo więcej eksperymentów niż kiedykolwiek wcześniej.
W modelu ficzerowym dynamika jest taka: ktoś (PM, stakeholder, PO) wymyśla rozwiązanie, wrzuca na backlog jako ficzerek, zespół je buduje, deploy, done. Nikt nie sprawdza, czy to zadziałało. Kolejny ficzerek.
W naszym modelu dynamika jest inna: zespół dostaje problem do rozwiązania, generuje kilka pomysłów na rozwiązanie, identyfikuje kluczowe założenia, projektuje eksperymenty. Zanim zbudujemy cokolwiek "na stałe", walidujemy, czy to podejście ma szansę zadziałać.
To nie jest "waterfall z dodatkowymi krokami". To jest fundamentalnie inny sposób myślenia o pracy produktowej. Zespoły uczą się szybciej, bo feedback loop jest krótszy. Nie czekamy miesiąc na deploy ficzera, żeby się przekonać (za koljene 3 m-ce), że użytkownicy go ignorują. Testujemy hipotezy, mierzymy wyniki, iterujemy.
I co ważne, w tym modelu "ficzerek, który nie zadziałał", to nie porażka, to informacja. Zespół, który przetestował trzy rozwiązania i wybrał to, które naprawdę poprawia metrykę, dostarczył ogromną wartość, choć "zbudował" jedną rzecz zamiast trzech. W starym modelu ten sam zespół zbudowałby trzy ficzery, wszystkie trafiłyby na produkcję i nikt by nie sprawdził, która z nich (jeśli w ogóle) cokolwiek zmieniła.
"To jest nieefektywne"
Tak, często słyszę to pytanie: "Zamiast trzech ficzerów mamy jeden. Straciliśmy sporo CAPACITY. Czy to nie jest nieefektywne?".
Zastanów się głębiej nad tym, czy naprawdę chcesz dostarczyć 3 ficzery, które nie wiadomo czy przynoszą jakąkolwiek realną wartość. Być może nawet spowodują obniżenie wyników. Weź pod uwagę, że 3 dodatkowe ficzery to 3x więcej kodu do utrzymania, testowania, rozwijania. Koszt w długim okresie będzie dramatycznie większy, a wartość… właśnie… nie wiadomo.
Zgadujemy, wdrażamy i uciekamy, zanim ktokolwiek nas powiąże z tym wygenerowanym WASTEm. Czy naprawdę uważasz, że to jest efektywne?
Transformacja G2A przyniosła wyniki, które mówią same za siebie:
Lead time: z 214 dni do 40 dni. Prawie pięciokrotne skrócenie czasu od pomysłu do wartości na produkcji. To oznacza, że organizacja uczy się 5x szybciej, bo feedback z rynku przychodzi 5x wcześniej.
Adaptacyjność organizacyjna: inicjatywy nieplanowane realizowane ad-hoc, 5x szybciej. Gdy pojawia się pilna okazja biznesowa lub problem do zaadresowania, organizacja potrafi na to zareagować natychmiast. Zespoły nie są "zablokowane" przez roadmapę ficzerów na następne 6 miesięcy.
Uproszczona struktura zarządzania. Eliminacja koordynatorów i pośredników. Wartość przepływa bezpośrednio od decyzji PO do zespołów i na produkcję. Mniej przekazywania, mniej czekania, mniej "gry w głuchy telefon".
Zmiana rozmowy. Być może najważniejszy wynik, choć najtrudniejszy do zmierzenia. Zamiast "kiedy będzie ten ficzerek?" słyszymy "jak idzie rozwiązywanie tego problemu? Czy metryka się rusza?" To fundamentalna zmiana kultury organizacyjnej - z kultury dostarczania na kulturę osiągania wyników.
Outcome-driven backlog nie jest punktem docelowym. Jest krokiem, który naturalnie otwiera drzwi do czegoś głębszego.
Gdy zespoły nie dostają gotowych rozwiązań, ale problemy do rozwiązania - muszą same odkrywać, co zadziała. To naturalnie prowadzi do praktyk Product Discovery: badań z użytkownikami, testowania hipotez, prototypowania, walidacji przed budowaniem. Zespoły nie budują ficzerów "bo tak zdecydował PO" - budują rozwiązania, bo mają dowody, że mogą one zadziałać.
W G2A eksperymentujemy teraz z tym, jak pogłębić Discovery: jak nie tylko dostarczać rozwiązania problemów, które znamy, ale odkrywać problemy, o których jeszcze nie wiemy. Jak tworzyć nowe zachowania użytkowników prowadzące do lepszych rezultatów biznesowych. To następny rozdział naszej podróży.
Ale fundamentem tego wszystkiego jest prosta zmiana: przestaliśmy zarządzać listą ficzerów. Zaczęliśmy zarządzać wynikami, które chcemy osiągnąć. I to zmieniło wszystko.
P.s. Oczywiście ten model pracy nie byłby możliwy bez zastosowania pryncypiów LeSS i bez przeprowadzonej transformacji systemu pracy. Nowy system, to nowy grunt na nowe, produktowe praktyki. I to w środowisku wielozespołowym. Więcej możesz przeczytać choćby w artykule Model Produktowy w starej strukturze = gra w szachy warcabami.
Artykuł oparty na doświadczeniach z transformacji w G2A, prezentowanych na 10th Global LeSS Conference w Amsterdamie (2025).