W czasie wielu lat pracy przy produkcie, spotykłem wielu Product Ownerów, którzy wykonują swoją pracę nieskutecznie. Sam nie raz też takim PO byłem.

Nie chodzi o brak umiejętności, ale o pewne schematy działania, które przynoszą więcej szkody niż pożytku. Antywzorce roli Product Ownera.

Antywzorce, jak sama nazwa wskazuje, to negatywne (anty) wzorce zachowań - nieskuteczne rozwiązanie, które wydaje się dobre, ale w praktyce generuje więcej problemów niż rozwiązuje.

W kontekście roli Product Ownera, antywzorce (ang. antypatterny) to zachowania lub praktyki, które utrudniają skuteczne zarządzanie produktem i współpracę z zespołem.

W tym artykule rozłożyłem na czynniki pierwsze 9 najczęściej przez mnie widzianych schematów, które przenosiły negatywne skutki dla produktu. Unikając tych błędów, możesz znacząco zwiększyć swoją efektywność i realnie wpłynąć na sukces produktu.

• 1. PO jako "pan i władca" backlogu

• 2. PO jako "właściciel" zespołu

• 3. PO jako architekt techniczny

• 4. PO jako zbieracz zamówień

• 5. PO niedostępny dla zespołu

• 6. Reaktywny PO, który nieustannie gasi pożary

• 7. PO, który nie rozumie użytkowników

• 8. PO skupiony na outputach zamiast outcome'ach

• 9. PO per Dev Team zamiast PO per Produkt

• Inne popularne antypatterny Product Ownera

1. PO jako "pan i władca" backlogu

Często spotykany problem: PO, który uważa, że Product Backlog jest TYLKO jego własnością i nikt poza nim nie ma prawa się zbliżyć🙅‍♂️. Uważają, że tylko oni mogą edytować i zarządzać backlogiem.

Takie podejście nie sprzyja zaangażowaniu Scrum Teamu - trudno czuć się współodpowiedzialnym za produkt, jeśli moja rola sprowadza się do wykonawcy zadań i nie ma się wpływu na to co się robi.

Jak to wygląda w praktyce?

• PO zawsze samodzielnie dodaje i usuwa elementy z backlogu, nie konsultując tego z zespołem.

• Zespół nie ma wpływu na priorytety i zawartość backlogu.

• PO niechętnie dzieli się informacjami o backlogu z zespołem i interesariuszami.

Jak to naprawić?

• Współpraca przede wszystkim! Pamiętaj, że Product Backlog to narzędzie dla całego zespołu. Wszyscy powinni mieć możliwość wnosić do niego swoje pomysły i sugestie.

• Transparentność to klucz. Dziel się informacjami o backlogu z zespołem i interesariuszami. Im więcej osób rozumie cel i priorytety produktu, tym większe zaangażowanie.

• Planowanie i estymacje? Robimy to razem! Zespół powinien brać aktywny udział w planowaniu i szacowaniu pracochłonności zadań. To zwiększa poczucie odpowiedzialności i zaangażowanie.

2. PO jako "właściciel" zespołu

Kolejny antypattern, który często obserwuję, to PO, który zaczyna zachowywać się jak menedżer zespołu. Tacy PO zapominają, że zespół Scrum jest samoorganizujący się i zamiast skupić się na celach produktu, próbują zarządzać pracą deweloperów.

Jak to wygląda w praktyce?

• PO przydziela zadania konkretnym członkom zespołu, zamiast wyjaśniać cel elementu Product Backlogu.  

• PO czuje się „ownerem" czasu deweloperów.  

• PO wydaje polecenia na Daily Scrum i innych wydarzeniach scrumowych, zamiast słuchać i pomagać zespołowi w identyfikacji i usuwaniu przeszkód.  

Takie zachowanie zabija inicjatywę i kreatywność zespołu 🪦. Zespół staje się mniej zaangażowany i czeka na instrukcje, zamiast aktywnie szukać najlepszych rozwiązań.

Jak to naprawić?

• Zaufanie to podstawa. Zaufaj swojemu zespołowi i daj mu swobodę w organizacji pracy. Pamiętaj, że to oni są ekspertami w swojej dziedzinie.

• Skup się na celach, nie na zadaniach. Zamiast mówić zespołowi, co dokładnie ma robić, wyjaśnij cel elementu Product Backlogu (zadania) i pozwól im zdecydować, jak go zrealizować.

• Bądź liderem, nie szefem. Twoją rolą jest inspirowanie zespołu i pomaganie mu w osiągnięciu celu, a nie kontrolowanie każdego jego ruchu.

• Daily Scrum to czas dla zespołu. Twoja rola na Daily Scrum to słuchanie i oferowanie pomocy, a nie wydawanie poleceń.

3. PO jako architekt techniczny

Ten antypattern pojawia się często, gdy Product Ownerem zostaje osoba z wykształceniem technicznym, np. były programista 👨‍💻. Tacy PO mają tendencję do narzucania zespołowi konkretnych rozwiązań technicznych, zamiast skupić się na celach produktu i wyjaśnianiu "dlaczego" dany element backlogu jest ważny.

Jak to wygląda w praktyce?

• PO definiuje konkretne technologie i frameworki, które zespół ma wykorzystać.

• PO narzuca architekturę systemu.

• PO koncentruje się na szczegółach implementacji, zamiast na wartości biznesowej dostarczanej przez produkt.

Dlaczego to problem?

• Blokuje kreatywność zespołu. Deweloperzy czują się mniej zmotywowani, gdy nie mają wpływu na to, jak realizują zadania.

• Ogranicza innowacyjność. Zespół może mieć lepsze pomysły na rozwiązanie problemu, ale nie ma możliwości ich wykorzystania.

• Zmniejsza odpowiedzialność zespołu. Jeśli PO narzuca rozwiązania, zespół czuje się mniej odpowiedzialny za ich jakość.

Jak to naprawić?

• Skup się na "dlaczego", a nie na "jak". Twoim zadaniem jest wyjaśnienie zespołowi celu elementu backlogu i wartości, jaką ma on dostarczyć użytkownikowi. Sposób realizacji pozostaw zespołowi.

• Wykorzystaj wiedzę i doświadczenie zespołu. Deweloperzy często mają cenne spostrzeżenia dotyczące technologii i architektury. Wysłuchaj ich opinii i weź je pod uwagę.

• Współpraca to klucz. Organizujcie regularne spotkania, na których zespół będzie mógł przedstawić różne opcje techniczne i wspólnie wybierzcie najlepsze rozwiązanie.

4. PO jako zbieracz zamówień

W tym antypatternie Product Owner staje się niejako kelnerem, przyjmującym zamówienia od interesariuszy 🫴. Zamiast aktywnie kształtować wizję produktu i priorytetyzować zadania na podstawie wartości dla użytkownika i celów biznesowych, PO skupia się na realizowaniu życzeń "góry".

Jak to wygląda w praktyce?

• PO bezkrytycznie przyjmuje wszystkie sugestie od interesariuszy, nie analizując ich wpływu na produkt.

• PO ma trudności z odmową interesariuszom, nawet jeśli ich żądania są sprzeczne z wizją produktu.

• PO nie potrafi jasno argumentować decyzji i wyjaśniać, dlaczego pewne elementy backlogu są ważniejsze od innych.

Dlaczego to problem?

• Prowadzi do niespójności produktu. Produkt staje się zbiorem przypadkowych funkcji, które nie tworzą spójnej całości.

• Zmniejsza wartość produktu. Realizowanie wszystkich życzeń interesariuszy niekoniecznie przekłada się na zadowolenie użytkowników.

• Demotywuje zespół. Zespół traci poczucie sensu pracy, gdy widzi, że produkt rozwija się w przypadkowym kierunku.

Jak to naprawić?

• Zrozumienie potrzeb użytkowników i celów biznesowych to podstawa. Musisz wiedzieć, dla kogo tworzysz produkt i jakie cele ma on realizować.

• Priorytetyzacja to Twoje supermoc. Naucz się efektywnie priorytetyzować zadania na podstawie wartości dla użytkownika i celów biznesowych.

• Argumentuj swoje decyzje. Bądź w stanie jasno wyjaśnić interesariuszom, dlaczego pewne elementy backlogu są ważniejsze od innych. Używaj danych, analiz i feedbacku od użytkowników.

• Nie bój się mówić "nie". Nie wszystkie sugestie interesariuszy muszą być zrealizowane. Twoim zadaniem jest dbanie o spójność i wartość produktu.

5. PO niedostępny dla zespołu

Ten antypattern to koszmar każdego zespołu deweloperskiego. PO, który jest niedostępny, nie odpowiada na pytania, nie uczestniczy w spotkaniach, staje się wąskim gardłem i blokuje pracę zespołu.

Jak to wygląda w praktyce?

• PO nie uczestniczy w Refinementach, Sprint Retro, Review, Planningu i innych kluczowych spotkaniach.

• PO nie odpowiada na pytania zespołu lub robi to z dużym opóźnieniem.

• PO nie jest w stanie szybko podjąć decyzji, co wstrzymuje pracę zespołu.

Dlaczego to problem?

• Opóźnienia w pracy zespołu. Zespół nie może realizować zadań, jeśli nie ma jasnych wytycznych i odpowiedzi na pytania.

• Frustracja zespołu. Deweloperzy czują się ignorowani i niedoceniani, gdy nie mogą skomunikować się z PO.

• Spadek jakości produktu. Brak komunikacji i opóźnienia w podejmowaniu decyzji mogą prowadzić do błędów i niedociągnięć w produkcie.

Jak to naprawić?

• Komunikacja to klucz! Bądź dostępny dla swojego zespołu. Uczestnicz w spotkaniach, odpowiadaj na pytania, bądź proaktywny w komunikacji.

• Ustal jasne zasady komunikacji. Zespół powinien wiedzieć, w jaki sposób i kiedy może się z Tobą skontaktować.

• Szybkie podejmowanie decyzji. Nie zwlekaj z podejmowaniem decyzji. Im szybciej odpowiesz zespołowi, tym szybciej będą mogli kontynuować pracę.

• Bądź proaktywny. Nie czekaj, aż zespół przyjdzie do Ciebie z pytaniami. Sam inicjuj rozmowy i pytaj, czy czegoś nie potrzebują.

6. Reaktywny PO, który nieustannie gasi pożary

Ten antypattern charakteryzuje się brakiem strategicznego podejścia i planowania. PO skupia się na rozwiązywaniu bieżących problemów, "gaszeniu pożarów" i małych usprawnieniach, zamiast na planowaniu długoterminowego rozwoju i osiąganiu celów produktu.

Jak to wygląda w praktyce?

• PO reaguje na bieżące problemy i kryzysy, zamiast planować rozwój produktu.

• PO ma trudności z ustalaniem priorytetów i skupianiem się na najważniejszych zadaniach.

• PO nie ma czasu na rozmowy z użytkownikami i analizę rynku.

Dlaczego to problem?

• Chaos i brak kontroli. Zespół pracuje w trybie ciągłego reagowania na problemy, co prowadzi do chaosu i braku kontroli nad rozwojem produktu.

• Brak strategicznego kierunku. Produkt rozwija się w sposób przypadkowy, bez jasnej wizji i celów.

• Wypalenie zespołu. Zespół jest zmęczony ciągłym "gaszeniem pożarów" i brakiem poczucia sensu pracy.

Jak to naprawić?

• Planowanie strategiczne to podstawa. Musisz mieć jasną wizję i strategię produktu.

• Priorytetyzacja zadań. Naucz się efektywnie priorytetyzować zadania pod konkretny cel. To wymusi zastanowienie się, co tak naprawdę chcemy osiągnąć.

• Proaktywne podejście. Nie czekaj na problemy, przewiduj je i planuj działania, które pozwolą ich uniknąć.

• Skup się na długoterminowych celach. Pamiętaj, że Twoim zadaniem jest budowanie wartościowego produktu, a nie tylko rozwiązywanie bieżących problemów.

7. PO, który nie rozumie użytkowników

Ten antypattern polega na tym, że użytkownik nie zna i nie interesuje się potrzebami i problemami użytkowników. Taki PO skupia często albo na rozwiązaniach, albo tylko na celach biznesowych. Jednak bez zrozumienia użytkowników, zespół finalnie będzie tworzył funkcje, które nie są im potrzebne i nie rozwiązują problemów.

Jak to wygląda w praktyce?

• PO nie rozmawia z użytkownikami i nie zbiera od nich feedbacku.

• PO nie analizuje danych dotyczących zachowań użytkowników.

• PO tworzy funkcje na podstawie własnych przekonań lub sugestii interesariuszy, zamiast na podstawie potrzeb użytkowników.

Dlaczego to problem?

• Tworzenie niepotrzebnych funkcji. Produkt jest przeładowany funkcjami, których użytkownicy nie używają.

• Niezadowolenie użytkowników. Użytkownicy są sfrustrowani produktem, który nie spełnia ich oczekiwań.

• Marnowanie zasobów. Zespół traci czas i energię na tworzenie funkcji, które nie przynoszą wartości.

• Nieosiąganie celów biznesowych - jeśli zapominamy o użytkownikach, który są bezpośrednimi odbiorcami produktu, zwykle nie uda nam się osiągąć celów biznesowych.

Jak to naprawić?

• Regularne rozmowy z użytkownikami. Prowadź regularne wywiady i dowiedz się, kim są Twoi użytkownicy, jakie mają potrzeby i problemy.

• Analiza danych. Analizuj dane dotyczące zachowań użytkowników, aby zrozumieć, jak korzystają z produktu. Pomocna może się tu okazać analityka produktowa.

• Empatia i zrozumienie. Wczuj się w sytuację użytkowników i spróbuj zrozumieć ich punkt widzenia.

• Testowanie z użytkownikami np. przez testy użyteczności. Testuj nowe funkcje z użytkownikami, aby upewnić się, że są dla nich wartościowe.

8. PO skupiony na outputach zamiast outcome'ach

Ten antypattern polega na skupianiu się na budowanie rozwiązania (outputach), zamiast na wartości, jaką te elementy przynoszą użytkownikom (outcomach). Product Owner, który skupia się na outputach, mierzy sukces produktu ilością zrealizowanych zadań, velocity zespoły, zamiast zadowoleniem użytkowników i osiągniętymi celami biznesowymi.

Jak to wygląda w praktyce?

• PO mierzy sukces zespołu ilością zrealizowanych historyjek użytkownika albo velocity zespołu.

• PO skupia się na dostarczaniu jak największej liczby funkcji, zamiast na dostarczaniu realnej wartości i pozytywnej zmienia zachowania użytkowników.

• PO nie analizuje wpływu dostarczonych funkcji na zachowania użytkowników i cele biznesowe.

Dlaczego to problem?

• Brak koncentracji na wartości. Zespół skupia się na realizacji zadań, zamiast na dostarczaniu wartości użytkownikom.

• Nieskuteczny produkt. Produkt może mieć wiele funkcji, ale nie przynosić oczekiwanych rezultatów.

• Demotywacja zespołu. Zespół traci poczucie sensu pracy, gdy nie widzi, czy ich praca przekłada się na realną wartość.

Jak to naprawić?

• Definiowanie celów opartych na wartości (dla użytkownika lub naszego biznesu). Ustalaj cele oparte na tym, jaką wartość chcesz dostarczyć użytkownikom i jakie cele biznesowe chcesz osiągnąć.

• Ewaluacja wpływu dostarczonych funkcji. Analizuj, jak dostarczone funkcje wpływają na zachowania użytkowników i czy pomagają w osiągnięciu celów biznesowych.

• Zbieraj feedback, dzięki iteracyjnemu podejściu. Dostarczaj małe partie funkcjonalności i zbieraj feedback od użytkowników, aby upewnić się, że idziesz w dobrym kierunku.

• Skupienie się na outcome'ach, a nie outputach. Mierz sukces produktu pozytywną zmiana zachowania użytkowników, zadowoleniem użytkowników, osiągniętymi celami biznesowymi i realną wartością, jaką dostarcza produkt.

9. PO per Dev Team zamiast PO per Produkt

Ten antypattern pojawia się, gdy organizacja patrzy z perspektywy “zespół potrzebuje PO”, zamiast to produkt potrzebuje PO, który pracuje razem z zespołem lub zespołami nad jego rozwojem.

Jak to wygląda w praktyce?

• W organizacji jest wielu PO, z których każdy przypisany jest do konkretnego zespołu deweloperskiego.

• PO skupiają się na optymalizacji pracy "swojego" zespołu, zamiast na strategicznym rozwoju produktu.

• W przypadku, gdy nad jednym produktem pracuje kilka zespołów, pojawiają się problemy z koordynacją i spójnością wizji.  

Dlaczego to problem?

• Brak spójnej wizji produktu. Każdy zespół może rozwijać produkt w innym kierunku, co prowadzi do niespójności i braku synergii.

• Konflikty i brak koordynacji. Zespoły mogą mieć trudności z komunikacją i współpracą, co prowadzi do konfliktów i opóźnień.

• Nieefektywne wykorzystanie zasobów. PO skupieni na "swoich" zespołach mogą nie dostrzegać szerszych możliwości optymalizacji i efektywnego wykorzystania zasobów.  

Jak to naprawić?

• Jeden PO na produkt. Zamiast przypisywać PO do zespołów, organizacja powinna myślec z perspektywy produktowej. PO powinien współpracować z jednym lub kilkoma zespołami nad rozwojem PRODUKTU.

• Jednak wizja produktu. Jeden produkt = jedna wizja produktu. Nawet jeśli praca podzielona jest na kilka zespołów, powinien być jeden PO odpowiedzialny za cały produkt, który ma jasną wizję produktu i dba o to, aby wszystkie zespoły rozwijały go w spójnym kierunku.

• Efektywna komunikacja i współpraca. PO powinien dbać o to, aby zespoły efektywnie komunikowały się i współpracowały ze sobą.

Inne popularne antypatterny Product Ownera

Oprócz wymienionych wcześniej antywzorców, istnieje wiele innych, które mogą negatywnie wpływać na pracę Product Ownera i efektywność zespołu. Warto być ich świadomym, aby aktywnie unikać tych pułapek.

Oto kilka dodatkowych przykładów:

• PO nieposiadający wystarczających uprawnień - PO musi mieć odpowiednie uprawnienia do podejmowania decyzji dotyczących produktu. Brak decyzyjności prowadzi do frustracji zespołu i opóźnień.

• PO, który nie ma wiedzy dziedzinowej - Brak wiedzy domenowej utrudnia PO podejmowanie trafnych decyzji produktowych.  

• "Product Owner" jako komitet, a nie jedna osoba - Odpowiedzialność za Product Backlog powinna leżeć po stronie jednej osoby, a nie grupy osób.

• PO skupiający się na project managemencie - PO skupia się na produkcie, a nie na projektach.

• PO z zewnątrz firmy - PO powinien być blisko zespołu i rozumieć kontekst biznesowy. Trudno to realnie osiągnąć będąc spoza firmy/organizacji.

• PO niepotrafiący skutecznie komunikować wizji produktu. PO musi umieć jasno i przekonująco przedstawić wizję produktu zespołowi i interesariuszom.

• PO, który był wcześniej Analitykiem lub PMem (lub w innej roli) i po zmianie stanowiska nic się nie zmieniło w jego pracy - rola Product Ownera wymaga produktowego mindsetu oraz sposobu pracy. Jeśli po zostaniu PO - nie w zakresie obowiązków i pracy danej osoby się nie zmienia, prawdopodobnie coś jest nie tak.

Oczywiście ta lista antywzorców nie jest ani kompletna, ani jedyna słuszna. Czasem też niektóre zachowania, które powszechnie nie działają - mają jakieś zastosowanie w tej konkretnej sytuacji i w tej konkretnej firmie. Do takich “dobrych praktyk” zawsze podchodź świadomie.

Możesz wykorzystać tę listę do tego, by sprawdzić które z tych zachowań mogą dotyczyć Ciebie lub Twojego zespołu i jakie to ma dla Ciebie konsekwencje. Unikanie tych anywzorców zwykle pozwoli Ci stać się lepszym Product Ownerem, który buduje wartościowe produkty i skutecznie współpracuje z zespołem.