Pułapki odpowiedzialności Product Ownera

W poprzednim odcinku rozmawialiśmy o tym, skąd brać Product Ownerów. Pozostajemy w obszarze produktowym i rozmawiamy o pułapkach odpowiedzialności Product Ownera. W tym odcinku poznasz pięć pułapek, które dokładnie analizujemy. Do każdej pułapki dajemy Ci kilka porad, które pomagają radzić sobie z nimi. Całość jak zawsze na bazie naszej praktyki.

W tym artykule poruszymy temat pułapek związanych z pełnieniem roli Product Ownera. Jest to kontynuacja poprzedniego tematu, w którym omawialiśmy, skąd brać Product Ownerów. Omówimy konkretne i praktyczne rozwiązania, które można zastosować w celu uniknięcia tych problemów.

Z tego artykułu dowiesz się, jakie są najczęstsze wyzwania, z którymi borykają się Product Ownerzy oraz co zrobić, gdy Product Owner nie ma uprawnień do podejmowania decyzji czy jest zbyt daleko od swojego klienta.

Product Owner nie jest decyzyjny ( nie ma uprawnień)

Kiedy myślimy o roli Product Ownera, jedną z pierwszych rzeczy, która nam przychodzi do głowy, jest oczekiwanie, że będzie on w stanie podejmować decyzje dotyczące rozwoju produktu. Brak tej decyzyjności oznacza, że Product Owner nie otrzymał uprawnień ani umocowania od organizacji do podejmowania takich decyzji.

1. Ustalenie granic odpowiedzialności Product Ownera 

Jest to niestety bardzo popularna pułapka. Żeby temu zaradzić, zarówno z pozycji Product Ownera, jak i z perspektywy Scrum Mastera czy Agile Coacha, pierwszym krokiem jest uzgodnienie z zarządzającymi w organizacji wizji roli Product Ownera.

• Może to być rozmowa z Dyrektorem Produktu, członkiem zarządu odpowiedzialnym za rozwój produktów, czy inną osobą zarządzającą obszarem, w którym działa Product Owner. 
• Kluczowe jest ustalenie wspólnego zrozumienia roli Product Ownera. 

Problem z brakiem decyzyjności może wynikać z niezgodnych wyobrażeń co do tej roli. My, reprezentując podejście scrumowe, możemy myśleć o Product Ownerze jako osobie decyzyjnej, podczas gdy management może mieć inne wyobrażenie – widzieć go jako nowy rodzaj Project Managera, analityka, pośrednika. Ważne jest wyjaśnienie tych różnic i uzgodnienie, czym naprawdę jest rola Product Ownera w organizacji.

2. Zdefiniuj produkt i jego cel

Kolejną naszą rekomendacją jest dobre zdefiniowanie produktu. W jaki sposób? 

• Określ co jest produktem oraz co wchodzi w jego skład.
• Zdefiniuj ramy, czyli bazowe informacje i kontekst potrzebny do jasnego określenia produktu, oraz bardzo konkretnie ustal cel produktu.

Należy dać Product Ownerowi wycinek organizacji, za który odpowiada i w którym ma decyzyjność. To powinno wyjaśnić, jakie decyzje Product Owner może podejmować, a które należą do innych Product Ownerów lub są poza ich zakresem. Takie zdefiniowanie obszaru, na którym Product Owner ma decyzyjność, jest kluczowe, aby uzyskał pełne uprawnienia do podejmowania decyzji.

Często spotykamy się z niezrozumieniem roli Product Ownera jako osoby realizującej projekty, a nie opiekującej się produktem. Jest to postrzeganie roli jako realizowanie zleconych inicjatyw z portfela projektów, zamiast rozwoju i opieki nad pewnym obszarem produktowym. Jeśli management rozumie rolę Product Ownera jako kogoś, kto ma dowieźć projekt zgodnie z wytycznymi, mamy problem z decyzyjnością.

3. Popraw umocowanie z wyższym managementem

Mamy tu na myśli sytuację, gdzie Product Owner jest odpowiedzialny za produkt i jest akceptowany jako kluczowy element procesu scrumowego, ale jego ramy decyzyjności są ograniczone. Na przykład, może nie mieć swobody decydowania, musi uzyskać zgodę, drugi podpis, czy regularne korekty.

W organizacjach przechodzących transformację i budujących świadomość zwinnego rozwoju produktu, umocowanie Product Ownera może być takie, jakie było wcześniej – zawsze trzeba było uzyskać zgodę. Warto przedyskutować z wyższym managementem, czy te ograniczenia są naprawdę potrzebne i jakie są ich konsekwencje. Może warto przenieść decyzyjność na nowy poziom, rozliczając Product Ownera za osiągnięte rezultaty, a nie za realizację konkretnych funkcji zgodnie z wyobrażeniem dyrektora.

4. Zmień Product Ownera 

Jest to dość kontrowersyjna porada, jednak pozwól, że ją rozwiniemy. Może się zdarzyć, że mimo spełnienia wszystkich powyższych punktów, konkretna osoba w tej roli się nie odnajduje. Patrzymy na to w ten sposób – tak jak nie chcielibyśmy, aby firmą zarządzała osoba, która nie radzi sobie z tym stanowiskiem, tak samo ważne jest, aby Product Owner był odpowiedzialny i kompetentny w swoim obszarze.

Spotkaliśmy na swojej drodze osoby, które w roli Product Ownera nie błyszczały, mimo wsparcia, ram i zmian, jakie wprowadzono. Z drugiej strony, obserwowaliśmy, jak odżywa zespół, gdy współpracuje z osobą, która potrafi skutecznie zarządzać produktem. Zmiana Product Ownera nie musi oznaczać rozstania z firmą. Może się okazać, że ta rola nie jest odpowiednia dla danej osoby, ale może ona nadal funkcjonować w ramach organizacji, tylko w innej roli, która lepiej pasuje do jej umiejętności i predyspozycji.

Będąc w tym zakątku związanym ze zmienianiem Product Ownera, to pozostańmy ostrożni. Zmiana Product Ownera nie zawsze rozwiąże wszystkie problemy. Ważne jest, aby przeanalizować cały proces i strukturę, w jakiej działał Product Owner. Jakie dostawał wsparcie? Jakie miał umocowanie? Te wszystkie czynniki mają znaczenie. Nawet jeśli jesteśmy pewni decyzji o zmianie, powinniśmy przejrzeć cały proces i posłuchać osoby, która opuszcza tę rolę. Zrozumienie trudności, z jakimi się zmagała, może pomóc uniknąć tych samych problemów w przyszłości.

Wprowadzenie nowego Product Ownera powinno odbywać się na najlepszych możliwych zasadach, być może z nową kartą i trochę zmienionymi regułami współpracy. Ważne jest, aby nie wpaść z deszczu pod rynnę, kontynuując te same problemy.

Product Owner, nie potrafi decydować (ma uprawnienia, ale nie decyduje) 

Przejdźmy teraz do kolejnej pułapki związanej z rolą Product Ownera, czyli sytuacji, gdy Product Owner nie potrafi decydować. To nie jest przypadek, gdy ktoś mu nie pozwala decydować. Ta osoba ma decyzyjność i zespół do dyspozycji, ale z jakiegoś powodu decyzje się nie pojawiają, są opóźniane lub nie zapadają. Tutaj musimy poznać powody tego stanu rzeczy i mamy kilka pomysłów, jakie zagadnienia warto by było eksplorować.

1. Zbuduj solidną  wiedzę o produkcie

 Im lepiej rozumiemy produkt i całe otoczenie biznesowe, tym łatwiej jest podejmować decyzje. Trudno oczekiwać, że ktoś będzie podejmował decyzje, jeśli nie ma solidnych fundamentów, na których te decyzje można oprzeć. W takich sytuacjach można wpaść w pułapkę przeciągających się decyzji, ponieważ brak wiedzy powoduje strach przed ich podjęciem. Często ten strach wynika z braku merytorycznego podłoża dla decyzji.

2. Rozwijaj  wiedzę o produkcie. 

To proces, w który warto zainwestować, aby mieć pełen zestaw danych, informacji, faktów i badań na temat naszego produktu. To jest punkt startowy. Jeśli mimo posiadania takiej wiedzy nadal nie jesteśmy w stanie podejmować decyzji, warto zastanowić się, z czego konkretnie to wynika.

3. Stwórz wizję produktu 

Product Owner może nie znać technik związanych z zarządzaniem produktem, zwłaszcza technik priorytetyzacji. Może być tak, że Product Owner nie ma dostępu do odpowiednich narzędzi lub nie ma od kogo się uczyć. Tutaj z pomocą może przyjść Scrum Master, który może podpowiedzieć, pokazać, wytłumaczyć i dostarczyć potrzebne narzędzia. Nie będziemy wymieniać wszystkich możliwych narzędzi, ale jedno, które zawsze przychodzi do głowy, to wizja produktu. Można to osiągnąć poprzez zbudowanie Product Vision Board lub odpowiedzenie na podstawowe pytania, dlaczego w ogóle robimy dany produkt. To są proste techniki, które świetnie porządkują dyskusje o produkcie, wybieraniu priorytetów, skupianiu się na kluczowych aspektach i zrozumieniu, dla kogo ten produkt jest tworzony. Czasami w chaosie codzienności zapominamy o tych podstawach. Właśnie tutaj Scrum Master, lub ktoś z zespołu, może pomóc Product Ownerowi usystematyzować sposób myślenia, poukładać priorytety, zwizualizować pewne rzeczy i wesprzeć w podejmowaniu decyzji, selekcjonowaniu priorytetów oraz pokazywaniu alternatywnych scenariuszy. 

4. Zmniejsz konsekwencje podejmowania złych decyzji 

W tej poradzie chodzi o to, aby podzielić decyzje na mniejsze, bardziej zarządzalne części, co jest mocno powiązane z rozwojem produktu. Małe decyzje, które idealnie można cofnąć, są kluczowe. W szczególności polecamy podejmowanie drobnych eksperymentów, wprowadzanie małych kroków, iteracyjnych zmian oraz bazowanie na testach, hipotezach i badaniach. Takie podejście zwiększa pewność co do podejmowanych decyzji, ponieważ zbieramy dowody z rynku, że nasze decyzje mają sens.

Jeśli decyzje dotyczą małych obszarów produktu, a nie całego produktu czy dużych obszarów, łatwiej jest się z nich wycofać. Rekomendujemy iteracyjne i przyrostowe rozwijanie produktu, co pozwala na podobne podejście do podejmowania decyzji. Dzięki temu ryzyko złych decyzji jest mniejsze, a ich konsekwencje łatwiejsze do zarządzania.

5. Uzyskaj wsparcie 

W tym punkcie mam takie obrazowe porównanie: jeśli decyzja paraliżuje Product Ownera z powodu wielkich konsekwencji, nieodwracalnych skutków i braku możliwości cofnięcia się, to współczujemy Product Ownerom, którzy nie dostają odpowiedniego wsparcia. Wsparcie może przyjść w formie umocowania, odpowiednich narzędzi, środowiska czy systemowego rozwiązania, które zmniejsza wielkość i groźność decyzji.

Product Owner potrzebuje poczucia wsparcia, świadomości, że ktoś za nim stoi i wesprze go w jego działaniach. Zwłaszcza w przypadku rozwiązań innowacyjnych i rynkowych, gdzie błędy są nieodłącznym elementem procesu. Czasami zawodzi zespół, technologia, a konkurenci wpadną na coś lepszego.

Ważne jest, aby Product Owner otrzymywał sygnał od organizacji, zarządzających i partnerów biznesowych, że podejmowanie ryzyk i nauka na błędach jest częścią działania. Liderzy organizacji muszą wykazać się dojrzałością i panowaniem nad emocjami, zwłaszcza gdy coś nie wychodzi, coś się opóźnia, lub nie odnosimy sukcesów, na które liczyliśmy.

Pojedyncze negatywne przypadki mogą budować złą atmosferę i sytuację, w której Product Ownerzy boją się podejmować decyzje. Mogą obawiać się krytyki, przez co będą unikać podejmowania ryzykownych decyzji, przeciągać czas lub szukać kogoś, kto podejmie decyzję za nich. To niebezpieczne zjawisko, które spotykamy niestety w niektórych organizacjach.

Odległości Product Ownera od Klienta

Może być zaskakujące, że taka sytuacja ma miejsce, ponieważ Product Owner odpowiada za produkt, a częścią tej odpowiedzialności jest zrozumienie potrzeb Klienta. Często spotykamy się z sytuacją, w której Product Owner jest bardzo oddalony od Klienta.

Patrząc na Product Ownera w akcji, wszystko może wyglądać dobrze – jest wizja produktu, cel, Backlog Produktu, przyrosty, namacalny produkt. Jednak gdy przyjrzymy się bliżej, okazuje się, że odległość od końcowego Klienta jest ogromna. W skrajnych przypadkach Product Owner nigdy nie widział Klienta, nigdy się z nim nie spotkał. Klient jest gdzieś daleko, na orbicie, ale nigdy nie mają bezpośredniego kontaktu.

Co można tutaj zrobić? 

1. Zmiana dotychczasowego podejścia

Przede wszystkimi dostrzeżenie, że to, co dzieje się w środku firmy, może nie być najważniejszą wytyczną. Najważniejsza jest optyka, że zadowalamy Klienta, realizujemy to, co jest dla niego ważne, czujemy zmiany na rynku i potrzeby Klienta, a także obserwujemy konkurencję.

2. Wyjdź z pułapki korporacyjnej 

Oznacza to także wyjście z pułapki korporacyjnej, gdzie zakładamy, że wiemy, co się dzieje, rozwiązując potrzeby Klienta na podstawie narad, warsztatów i planów w biurze. Realne potrzeby Klienta są prawdopodobnie u Klienta, a nie w naszym biurze. Konkretnie mniej słuchania tego, co mówi przełożony, szef czy dyrektor, a więcej konfrontowania tych informacji z perspektywą rynku, odbiorcy i kupującego.

3. Przedstaw klientowi prototyp

Chcemy podzielić się również obserwacją, że często słyszymy obawy, gdy proponujemy zbliżenie się do użytkownika i rozmowę z nim. Pojawia się pytanie: Jak to miałoby wyglądać? Co to mogłoby być? Z naszej perspektywy bardzo dobrym sposobem na rozpoczęcie takiej rozmowy jest posiadanie czegoś namacalnego, co możemy pokazać użytkownikowi. To może być produkt w wersji prototypowej, niedoskonały jeszcze produkt, makiety lub koncepcje. Cokolwiek, co można pokazać użytkownikowi, aby mógł się do tego odnieść, skomentować, spróbować użyć i wyrazić swoją opinię.

Posiadanie czegoś namacalnego to bezpieczny sposób na rozpoczęcie dyskusji. Z jednej strony mamy gwarantowany temat rozmowy, a z drugiej strony, jakość feedbacku, jaką dostaniemy od użytkownika, jest znacznie wyższa, gdy może on poużywać produktu, niż gdybyśmy tylko rozmawiali o abstrakcyjnych koncepcjach. Dlatego im bardziej namacalne są te elementy, nad którymi pracujemy, tym lepsze będą efekty rozmowy z użytkownikami.

W tym punkcie bądź również czujny na to, aby pytać użytkownika o jego ogólną opinię lub zadawać otwarte pytania, a nie tylko dawać mu produkt i prosić o ocenę tego, co mu zaproponowaliśmy. Otrzymamy jakąś odpowiedź, ale możemy nie zauważyć lub nie usłyszeć ważnych informacji. Może użytkownik ma zupełnie inne pomysły, które nie pojawią się w zamkniętym formularzu ankietowym. Może zaznaczyć, że bardzo mu się podoba, ale w rzeczywistości nigdy tego nie użyje z powodu XYZ. Dlatego otwarte pytania i szeroka dyskusja są kluczowe, aby uzyskać pełny obraz i wartościowy feedback.

4. Zobacz w jaki sposób użytkownik korzysta z twojego produktu.

Ostatnia rada w temacie odległości od klienta, powiązana z naszym ostatnim zastrzeżeniem, to zwrócenie jak użytkownik korzysta z twojego produktu. 

• Pójdź do klienta, użytkownika, odbiorcy końcowego, wejdź w jego realne środowisko, w jego realny kontekst i rozmawiaj z nim jego językiem. 
• Obserwuj, jak funkcjonuje, jak wykonuje swoje codzienne czynności z twoją poprzednią wersją produktu, z twoim produktem, który próbuje użyć, lub z produktami konkurencji. 

Zwłaszcza w przypadku produktów bardziej złożonych niż strona WWW czy aplikacja, możesz uzyskać niesamowite rezultaty. Nagle okaże się, że użyteczność, łatwość wykorzystania, dodatkowe instrukcje czy materiały mają braki i trzeba coś jeszcze dopracować. Przegląd produktu, czy taki finalny odbiór produktu, koniecznie musi się dziać w kontekście odbiorcy docelowego i trzeba być bardzo czujnym na feedback. To wiąże się bardzo mocno z tematem projektowania interakcji z użytkownikiem czy z klientem. Z perspektywy Product Ownera, w kontekście pułapek, należy być na to strasznie wyczulonym i wręcz zachęcać zespół do kolejnych eksploracji, a nie zamykać się na to, że wie się wszystko, bo jest się wizjonerem, albo mój szef jest wizjonerem i powiedział mi, co mam myśleć.

Product Owner nie ma czasu 

Przedostatnia pułapka, którą chcemy poruszyć, to sytuacja, w której Product Owner nie ma czasu. Nie ma czasu dla zespołu, na produkt, dla użytkowników, na Backlog. Większość z naszych odbiorców widziała taką osobę w swojej organizacji – tzw. wieczny niedoczas. Wszystkie te historie typu „spójrz na mój kalendarz” wskazują na ogromną zajętość.

Czasem tak po prostu jest, że tej pracy jest dużo. Z naszych obserwacji, wynika to z predyspozycji do brania na siebie więcej, niż jesteśmy w stanie zrobić. Jednak mamy kilka porad na przypadki, gdy Product Owner naprawdę nie ma wystarczająco czasu, jakiego byśmy oczekiwali. Oto kilka sugestii, które mogą pomóc w takiej sytuacji.

1. Przedstaw konsekwencje braku inwestycji czasowej 

Warto przeanalizować te obowiązki i pokazać konsekwencje braku inwestycji czasowej w pełnienie odpowiedzialności Product Ownera. Konsekwencje te mogą być ewidentne, ponieważ niedoinwestowanie czasowe w proces Refinementu czy Backlog Produktu rzutuje na słabe cele sprintu, wykonanie, zaangażowanie i konieczność kilkukrotnego powtarzania wykonania danego elementu produktu. To może prowadzić do namacalnych strat i spowolnienia prac. Jeśli jest to wynik racjonalnych decyzji, oczekiwałbym od zespołu scrumowego wspólnej refleksji na temat odpowiedniej proporcji czasowej przeznaczonej na różne zadania oraz pokazania ciągu przyczynowo-skutkowego. Być może dzisiejsze niedomagania w poszczególnych obszarach, takich jak wykonanie prac przez developerów, udane lub nieudane Sprinty, a nawet zaangażowanie, wynikają z niewystarczającego zaangażowania czasowego Product Ownera.

To na co warto zwrócić uwagę to, nie zarządzamy czasem, tylko sobą w czasie. To pokazuje, że mamy wpływ na to, co robimy. Często mówimy, że nie mamy czasu na coś, ponieważ decydujemy się robić inne rzeczy. Czas jest ograniczony i każdy z nas ma go tyle samo. 

2. Uprość procesy, które zabierają czas Product Ownera

Kolejna porada, szczególnie istotna w większych organizacjach, to uproszczenie procesów, które zabierają czas Product Ownerowi. Może to obejmować różne aktywności i obowiązki, narzucone na Product Ownera z racji jego roli: dodatkowe spotkania statusowe, spotkania synchronizacyjne, uzupełnianie tabelek, dokumentów czy inne czynności, które trzeba wykonywać. Oczekiwanie, że Product Owner będzie uczestniczył we wszystkich tych czynnościach, może prowadzić do tego, że faktycznego czasu na pełnienie roli Właściciela Produktu pozostaje bardzo niewiele.

Podobna rzecz, tylko przesunięta do zespołu, to odciążenie Product Ownera z obowiązków, które mogą być realizowane przez pozostałych członków zespołu scrumowego. Często oczekuje się od Product Ownera, że będzie fizycznie pisał Product Backlog, osobiście uczestniczył we wszystkich warsztatach z Interesariuszami czy Użytkownikami, a nawet brał udział w testach lub czynnościach około wdrożeniowych. Te obowiązki mogą bardzo mocno konsumować czas, a nawet jeśli nie zajmują dużo czasu, są żmudne i męczące, co powoduje, że Product Owner ma mniej energii na wizję produktu, podejmowanie decyzji czy układanie większych spraw.

Pamiętajmy, że rola Product Ownera polega na odpowiedzialności, ale realizacja tej odpowiedzialności może być przekazana członkom zespołu scrumowego. Zwłaszcza gdy Product Owner jest zajęty czasowo, ma więcej niż jeden zespół, czy wielkie rzeczy do zrobienia. W takich przypadkach lepszym rozwiązaniem może być, aby zespół, zwłaszcza jeśli posiada kompetencje analityczne, architektoniczne, UX-owe, podjął część zadań. Mogą one pomóc Product Ownerowi, aby ten mógł skupić się na decydowaniu i kierowaniu wizją produktu. Zespół scrumowy, wszyscy Developerzy, powinni wychodzić poza swoje ścisłe specjalizacje i angażować się w rozwój produktu. Warto, aby zespół przejął część obowiązków, które można realizować grupowo lub indywidualnie przez poszczególnych Developerów.

 Product Owner nie zna Scruma

Ostatnia pułapka odnosi się do Product Ownera, który nie zna Scruma. Oczekujemy, że Product Owner będzie funkcjonował przy wykorzystaniu frameworka scrumowego, natomiast okazuje się, że nie ma doświadczenia ani w korzystaniu ze Scruma, ani w rozwijaniu produktów w sposób iteracyjno-przyrostowy. Każdy z tych przypadków może prowadzić do nieefektywnego rozwoju produktu lub do myślenia projektowego zamiast produktowego. Żadne z tych podejść nie są optymalne. Oczekuje się, że Product Owner będzie myślał w sposób przedsiębiorczy o produkcie jako całości, a nie tylko o dostarczaniu kawałków tego produktu do użytkowników. Znajomość Scruma, backgroundu oraz wiedzy o tym, jak wykorzystać zwinność do wytwarzania produktów, jest kluczowa.

Pokazujemy tutaj konsekwencje dosyć prostej pułapki, która wydaje się łatwa do rozwiązania.

1. Zainwestuj w czas na poznanie technik przez Product Ownera

 Najprostsze rozwiązanie to zainwestować czas w poznanie technik zwinnych, takich jak Scrum.Nie oczekujemy od Product Ownera dorównania poziomem pasji i fascynacji metodami zwinnymi, jakich bym się spodziewał od Scrum Mastera, Agile Coacha czy lidera transformacji. Minimalny poziom znajomości, jak przeczytanie Scrum Guide’a czy udział w szkoleniu z podstaw Scruma, jest konieczny. Taka inwestycja jednego do trzech dni na zrozumienie podstaw pozwoli na minimalnym poziomie wykorzystać tę metodę.

Jeśli jesteś liderem, Agile Coachem czy Scrum Masterem, który pomaga wdrożyć zwinność: 

• zadbaj o zrozumienie Scruma przez Product Ownerów, 
• bądź czujny nawet na takie sytuacje, gdy ktoś mówi: „Jestem Product Ownerem z doświadczeniem z poprzedniej firmy”. Może się okazać, że to zupełnie nie ma znaczenia, ponieważ rola ta może być różnie definiowana w różnych firmach, 
• przeprowadzając transformację czy reorganizację, wkładając odpowiedzialność Product Ownera w nowe ręce, warto wysłać tę osobę na szkolenie. Być może zaprosić ją do jakiegoś kursu rozwojowego i zadbać o podstawową wiedzę o Scrumie i zwinności.

2. Wsparcie Scrum Mastera

Nasza kolejna porada to uzyskanie dobrego wsparcia od Scrum Mastera. Twórcy Scruma nieprzypadkowo wprowadzili tę rolę. Oczekuję, że Product Owner ma dostęp do Scrum Mastera. Taki Scrum Master zna framework Scrum i potrafi doradzić, jak wykorzystać zwinne techniki do rozwoju produktu. Nawet jeśli Scrum Master nie pracuje na pełen etat, jakiekolwiek wsparcie z jego strony może zrobić znaczącą różnicę.

3. Zainwestuj czas w dalszy konsekwentny rozwój Product Ownera 

W większych organizacjach można to zrealizować poprzez wewnętrzne społeczności, wymianę wiedzy, mentoring czy shadowing. Współpraca Product Ownerów między sobą, nie tylko na poziomie produktu, ale także rozmowy o warsztacie, mogą przynieść cenne wskazówki. Jak radzić sobie z Interesariuszami? Jak zarządzać danymi? Takie kontekstowo dopasowane porady mogą być bardzo pomocne.

Jeśli w organizacji nie ma takich osób, warto zwrócić uwagę na zwinne społeczności zewnętrzne. W realiach pandemicznych większość z nich działa zdalnie, a wiele webinarów jest nagrywanych. Jest mnóstwo dostępnej wiedzy, którą można odnaleźć i zainwestować trochę czasu poza typowymi godzinami pracy. Nawet jeśli nie ma czasu na webinary czy długie spotkania, krótkie, inspirujące artykuły mogą dostarczyć wartościowych przemyśleń.

Dodaliśmy też kilka linków do materiałów produktowych, które mocno polecamy z własnej praktyki. Koniecznie sprawdź nasze rekomendowane źródła inspiracji związanych ze zwinnym zarządzaniem produktem.

Dodatkowe materiały

• Współpraca Scrum Mastera z Product Ownerem
• Blog Silicon Valley Product Group, na którym znaleźć można dużo artykułów na temat Product Discovery
• Blog Romana Pichlera, gdzie zamieszczone są m.in. poręczne szablony narzędzi Product Ownera – np. Product Vision Board
• Twitter Johna Cutlera, aktywnego produktowca i jednocześnie bardzo inspirującego twórcę merytorycznych treści o zarządzaniu produktami. Cenimy zwłaszcza jego krótkie wpisy prowokujące do myślenia
• Jak być dobrym Product Owenrem? – Ebook naszego współautorstwa, szczególnie polecamy wywiady z praktykującymi PO na temat wyzwań ich pracy

📄Transkrypcja podcastu „Pułapki odpowiedzialności Product Ownera”

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.

Jacek: W dzisiejszym odcinku porozmawiamy o pułapkach roli Product Ownera. Jest to kontynuacja odcinka poprzedniego, w którym mówiliśmy o tym, skąd brać Product Ownerów. Natomiast dzisiaj skupimy się na najpopularniejszych pułapkach roli Product Ownera. No i oczywiście zaproponujemy konkretne i praktyczne rozwiązania, które możecie w kontekście tych pułapek spróbować.

Kuba: Na początek, żeby dać Ci wyobrażenie, o jakich tematach szczegółowo będziemy mówić, wymienię te pułapki. Zdecydowaliśmy się na to, żeby opowiedzieć o przypadkach, gdy Product Owner nie jest decyzyjny, czyli nie ma uprawnień do decydowania. Nie umie decydować. Nie wie, jak to robić. Jest w odległości od Klienta lub kompletnym braku kontaktu z tym Klientem. Nie ma czasu na współpracę z zespołem i nie zna Scruma. W kolejnych częściach tego podcastu opowiemy o tych konkretnych pułapkach i zaproponujemy rozwiązanie. No to zaczniemy od pierwszej. Jacek, co rozumiemy pod hasłem Product Owner nie jest decyzyjny i dlaczego jest to pułapka?

Jacek: Tak. Kiedy myślę o roli Product Ownera, no to jedna z pierwszych rzeczy, która mi przychodzi do głowy, to jest takie oczekiwanie, że Product Owner będzie w stanie decydować, jeśli chodzi o rozwój produktu. Kiedy mówimy o braku tej decyzyjności, mamy tutaj na myśli coś takiego, że ten Product Owner nie dostał uprawnień, czy nie dostał mandatu od organizacji, żeby takie decyzje podejmować. To jest taki wariant, że, nawet gdyby chciał, no to tak naprawdę na koniec dnia nie jest w stanie tego zrobić.

Kuba: No jest dosyć nieprzyjemna pułapka. Niestety dosyć popularna. Ale gdybyśmy mieli temu tematowi zaradzić, zarówno, gdy jesteśmy z pozycji Product Ownera, którego dotyka ta sytuacja, albo, gdy jesteśmy z perspektywy Scrum Mastera albo Agile Coacha, który próbuje zmienić proces w zespole, czy po prostu jesteśmy zainteresowani tym, żeby tę sytuację naprawić. Pierwsza rzecz, która nam przychodzi do głowy, jako taka super najważniejsza. Jeśli spotykamy taką sytuację, gdzie Product Owner jest niedecyzyjny, no to zaczęlibyśmy od uzgodnienia z zarządzającymi w organizacji. Być może zarządzającymi tym Product Ownerem, jakieś osoby typu Dyrektor Produktu, może jakiś członek zarządu odpowiedzialny za rozwój produktów, czy po prostu osoba zarządzająca obszarem, w ramach którego funkcjonuje Product Owner w firmie. Zgodzić się z tą osobą, jaka jest wizja roli Product Ownera. Jaka jest granica tej odpowiedzialności tegoż właśnie Product Ownera? Czyli tutaj jest taki trochę dorozumiane, czy taki trop myślowy, że ten Product Owner, o którym myślimy, nie jest decyzyjny, ponieważ mamy niezgodne wyobrażenia, co do tej odpowiedzialności Product Ownerskiej po stronie naszej, gdzie my, powiedzmy reprezentujemy być może jakąś taką rolę czysto scrumową, a może ta osoba po stronie managementu ma wyobrażenie, że Product Owner to jest taki nowy rodzaj Project Managera, albo nowy rodzaj analityka. Może taka osoba na posyłki. Pośrednik. Jest cała masa możliwych tutaj, powiedzmy nazewnictw na to, że to nie jest Product Owner w naszym rozumieniu i jest oczekiwane przez management.

Jacek: Kolejna porada, to porada, w której rekomendujemy, żeby zdefiniować sobie dobrze produkt. Określić, co jest produktem, co wchodzi w skład produktu, co nie wchodzi w skład produktu. Jakie są ramy, czyli takie no powiedzmy bazowe informacje, czy kontekst, który jest nam potrzebny, żeby taki produkt sobie jasno zdefiniować, plus do tego określić sobie też bardzo konkretnie, jaki jest cel produktu. Czyli w tym kontekście chcielibyśmy dać Product Ownerowi, jakby tak z ramienia organizacji pewien taki wycinek organizacyjny, za który odpowiada. Jakby, w którego obszarze ma decyzyjność, tak żeby było jasne, jakie decyzje Product Owner może podejmować, a jakie decyzje, bądź leżą już w odpowiedzialności innych Product Ownerów, albo być może w ogóle są poza decyzją Product Ownerów. Tak więc takie zdefiniowanie – bym powiedział obszaru, na którym Product Owner tę decyzyjność, o której mówimy właśnie, że na ten moment jeszcze jej nie ma, żeby mógł uzyskać.

Kuba: I nieprzypadkowo Jacek mówi o obszarze produktu, definicji produktu, celu produktu, ponieważ coś, no co spotykamy regularnie, to zrozumienie roli Product Ownera, jako osoby, która realizuje projekt, zlecone inicjatywy. Ma dookreślone cele do osiągnięcia, właśnie takie bym powiedział, bardziej z portfela projektów, niż z rozwoju, czy opieki nad pewnym obszarem produktowym. I tu ponownie, jak w przypadku tej pierwszej porady z uzgodnieniem oczekiwań, no, to jeśli ktoś, kto ma na to wpływ, prawdopodobnie jakiś management w firmie, rozumie rolę Product Ownera, jako kogoś, kto opiekuje się projektami, albo ma za zadanie zrealizować te projekty zgodnie z jakimiś tam wytycznymi, na przykład żelaznym trójkątem projektowym, no to tutaj też możemy mieć kłopot i się nigdy nie spotkać i ta decyzyjność Product Ownera jest właśnie taka, jaka zdaniem tego zarządzającego powinna być. Czyli ma dowieść projekt. Nie zajmujemy się dowożeniem projektów z wykorzystaniem frameworka Scrum. Następną poradą, którą też byśmy w takiej sytuacji, gdy mamy do czynienia z niedecyzyjnym Product Ownerem, to zrewidować umocowanie decyzyjne z zarządzającymi. Rozumiem, tu mam na myśli taki przypadek, że nie następują te poprzednie problemy. Czyli Product Owner jest osobą odpowiedzialną za jakiś produkt. Jest w ogóle akceptowany, jako ważny fundament funkcjonowania procesu scrumowego, tylko po prostu ramy decyzyjności tej osoby są bardzo ograniczone. Czyli na przykład nie ma swobody decydowania, albo musi uzyskać zgodę, jakiś drugi podpis. Są jakieś korekty regularnie realizowane. No i tutaj często jest tak, że w organizacjach zwłaszcza takich, które dopiero przechodzą pewną transformację, dopiero budują tę świadomość zwinnego rozwoju produktu, to to umocowanie product ownerskie jest takie, jakie było zawsze. No zawsze trzeba było dostać zgodę, jakiś akcept, jakąś korektę. No i tutaj warto wyjść naprzeciw takiej ewolucyjnej ścieżce i przedyskutować z wyższym managementem, czy na pewno są potrzebne te osłabienia decyzyjności, jakie są konsekwencje tej słabej decyzyjności? Czy czasami nie da się tego przenieść na nowy poziom. Jak mówię nowy poziom, to mam na myśli przede wszystkim takie jasne powiedzenie sobie – rozliczajmy Product Ownera za rezultaty, za osiągnięte efekty, a niekoniecznie za to, czy realizuje ten, czy tamten ficzer zgodnie z wyobrażeniem, jakiegoś na przykład dyrektora powyżej tego Product Ownera.

Jacek: I ostatnia porada, którą mamy dla Ciebie, to jest porada, która brzmi kontrowersyjnie, natomiast rozwinę ją. To jest porada pod tytułem – zmienić Product Ownera. No i oczywiście, co tutaj mamy na myśli? Może być taka sytuacja, no, że po prostu, mimo spełnienia tych powyższych wszystkich punktów, jakaś konkretna osoba może w tej roli się nie odnajdywać. Ja na to patrzę w ten sposób, tak jak nie chcielibyśmy, żeby firmą, spółką, organizacją, zarządzała osoba, która nie radzi sobie z tym stanowiskiem. Tak samo dosyć tak agresywnie podchodzę do roli Product Ownera, że tam jest odpowiedzialność, nie za całą firmę, ale za pewien jej wycinek. No i po prostu spotkałem na swojej drodze osoby, które no akurat konkretnie w tej roli nie błyszczały. Powiedzmy sobie, jakieś działania, wsparcie, jakieś ramy, jakieś zmiany, po prostu nie przynosiły efektów. Natomiast fajnie było zobaczyć, jak odżywa zespół, kiedy dostaje do współpracy osobę, która faktycznie jest w stanie takim produktem zarządzać. Też, żeby tak trochę zmiękczyć tą taką dosyć wyraźną rekomendację, to nie musi oznaczać rozstania się. Takiego na zasadzie, że Product Owner opuszcza firmę. Być może po prostu ta rola nie jest odpowiednia, no i ta osoba może dalej sobie funkcjonować w ramach organizacji, tylko po prostu nie konkretnie w roli Product Ownera.

Kuba: No i jak jesteśmy w tym zakątku związanym ze zmienianiem Product Ownera, to bądźmy bardzo, bardzo ostrożni na takie podejście szukania kozła ofiarnego, że tutaj Product Owner się nie sprawdził, więc zmieniamy i będzie już wszystko tip-top. No to często będzie suma wielu czynników. Jakie dostawał wsparcie? Jakie dostał umocowanie? Czyli te wszystkie rzeczy, które już wymieniliśmy, ale też wszystkie rzeczy, które dopiero przed nami w tym odcinku. Więc nawet jesteśmy pewni tej decyzji o zmianie Product Ownera, to i tak przejrzyjmy cały ten proces, przejrzyjmy struktury, jak to jest być Product Ownerem. Być może posłuchajmy też tej osoby. Z czym miała trudności? Co sprawiało, że ta rola nie była wypełniana tak, jakby wszyscy tego chcieli. No i zwłaszcza nowy Product Owner, ważne, żebyśmy wprowadzili go najlepiej, jak tylko potrafimy. Być może z nową kartą, ale również na trochę nowych zasadach. Czasami już stylu współpracy z pewną osobą się nie poprawi, ale z rozpędu czasem nie wpadnijmy z deszczu pod rynnę. Dobra, to pójdźmy dalej. Kolejny przypadek, który może nas spotkać, kolejna pułapka pełnienia tej product ownerskiej odpowiedzialności, to jest Product Owner, który nie umie decydować. I tutaj wyraźnie odgraniczmy. To nie jest ten przypadek z poprzedniej puli, ktoś mu nie pozwala decydować. Ta osoba jest wręcz oczekiwanie, że ma decyzyjność, że ma do dyspozycji zespół. Tylko z jakiegoś powodu te decyzje się nie pojawiają, nie zapadają. Przedłużają się. Z tych nieznanych powodów prawdopodobnie trzeba coś zmienić i między innymi poznać te powody. Mamy tutaj kilka pomysłów, w którą stronę byśmy poszukali, jakie zagadnienia byśmy eksplorowali.

Jacek: Zdecydowanie pomocne w podejmowaniu decyzji, jest zbudowanie sobie wiedzy o produkcie. Czyli, im lepiej rozumiemy produkt i całe otoczenie biznesowe, w którym się poruszamy, tym łatwiej jest nam podejmować decyzje. Trudno oczekiwać, że ktoś będzie podejmował decyzje, jeżeli nie ma tak naprawdę żadnych fundamentów, żeby te decyzje podejmować. Wtedy możemy wpaść w taką pułapkę przeciągających się decyzji, których nie jesteśmy w stanie podjąć. Bardzo często ten strach przed podjęciem decyzji wynika z tego, że tak naprawdę nie czujemy tego, żeby ta decyzja miała jakieś sensowne podłoże merytoryczne. Stąd, celowo tutaj mówię o budowaniu wiedzy o produkcie. Jest to pewien proces ciągły, w który zdecydowanie warto zainwestować. No i po prostu mieć komplet, szereg najróżniejszych danych, informacji, faktów, badań, na temat naszego produktu, bo wtedy tak naprawdę, to jest generalnie punk startowy. Jeżeli to mamy i nadal nie jesteśmy w stanie podjąć konkretnych decyzji, no to możemy się zastanowić, z czego konkretnie to wynika.

Kuba: Jacka porada była na temat tego, co jest treścią decyzji. Natomiast kolejną poradę, którą bym dorzucił do możliwego rozwiązania problemu niedecyzyjności, no to może – Product Owner nie zna technik związanych z zarządzaniem produktem, czy konkretnie punktowo tutaj patrząc, techniki priorytetyzacji. No i tutaj jest całe pokłosie, być może nieuwagi na temat takiego powiedziałbym „narzędziownika” roli product ownerskiego. Być może nie ma od kogo się uczyć taki Product Owner. Być może w firmie nie przykłada się tak bardzo wagi do tego, jak wygląda proces pracy. Jak wyglądają narzędzia? Tu z pomocą może przyjść Scrum Master, który może podpowiedzieć, pokazać, wytłumaczyć, opowiedzieć, przynieść te wszystkie narzędzia, które mogą być bardzo potrzebne. W zależności od tego, co dokładnie jest kontekstem produktu, ja nie będę tutaj bardzo szczegółowo, tych możliwych przykładowych narzędzi wymieniał, ale pierwsza, która mi przychodzi do głowy, zawsze jest wizja produktu. Czy to poprzez zbudowanie Product Vision Board, czy poprzez odpowiedzi na pytanie jakieś takie podstawowe, dlaczego w ogóle robimy ten produkt? To są bardzo proste rzeczy, bardzo proste techniki, które świetnie układają całą resztę dyskusji o produkcie. O wybieraniu, co jest ważne. Na czym się skupiamy? Dla kogo to robimy? To w gruncie rzeczy nie są żadne kosmosy. Czasami, być może w jakimś takim chaosie codzienności zapominamy o tych rzeczach. Tu świetnie może się przydać właśnie Scrum Master, czy ktoś z zespołu, kto Product Ownerowi usystematyzuje pewien sposób myślenia. Może poukłada pewne priorytety, czy zwizualizuje pewne rzeczy i po prostu wesprze Product Ownera w podejmowaniu pewnych decyzji, selekcjonowaniu pewnych rzeczy, czy pokazaniu scenariuszy alternatywnych – co powinniśmy robić w pierwszej kolejności, co może czekać, co nie powinno być robione w ogóle.

Jacek: Kolejną poradą jest zmniejszenie konsekwencji podejmowania złych decyzji. I tutaj mamy na myśli, żeby podzielić sobie trochę te wszystkie decyzje, które mamy. Oczywiście to jest mocno powiązane z tym, jak rozwijamy nasz produkt. Taki szereg małych decyzji, idealnie, jeśli te decyzje jesteśmy w stanie cofnąć. Tak więc tutaj w szczególności takie rzeczy, jak drobne eksperymenty, małe kroki, iteracyjne zmiany. Czy też bazowanie na testach? Bazowanie na hipotezach, na badaniach. To są wszystko takie rzeczy, które z jednej strony pomagają nam zwiększyć pewność co do podejmowania decyzji. Czyli zbieramy dowód z rynku, że nasze decyzje mają sens. Z drugiej strony, jeżeli to są faktycznie małe decyzje, a nie zmiany, które dotyczą całego produktu, czy jakichś takich dużych obszarów produktowych. No to o wiele prościej jest nam się z takich zmian wycofać. Tak więc tak jak rekomendujemy, co do zasady – iteracyjne i przyrostowe rozwijanie produktu, tak samo można powiedzieć, że takie prowadzenie produktu implikuje to, że jesteśmy w stanie w podobny sposób podchodzić do podejmowania decyzji.

Kuba: W tym punkcie mam takie obrazowe porównanie, że, zwłaszcza jeśli ta decyzja paraliżuje, bo jest jakieś takie poczucie wielkich konsekwencji, nieodwracalnych skutków. Brak możliwości cofnięcia się. To czasem współczuję Product Ownerom, którzy nie dostają odpowiedniego wsparcia w takich momentach. Czasem to wsparcie jest w postaci umocowania. Czasem to wsparcie może być właśnie w całym narzędziu, środowisku, czy w systemowym rozwiązaniu, które powoduje, że ta wielkość tych decyzji nie jest aż tak kolosalna, czy tak groźna. Co nawiązuje do ostatniej porady z tej puli, czyli bezpieczeństwie psychologicznym. Product Owner potrzebuje dostać takie bezpieczeństwo. Posiadać poczucie wsparcia. Posiadać poczucie, że ktoś za nim stoi i go wesprze w tym, jak działa w swojej roli. Gdzie nieodłączne jest, zwłaszcza jeśli mówimy tutaj o rozwiązaniach innowacyjnych, o rozwiązaniach takich rynkowych. Nieodłączne jest to, że będziemy się od czasu do czasu mylić, że jednocześnie może zawieść może nas i zespół i technologia i być może nasi konkurenci wpadną jeszcze na coś jeszcze lepszego, niż nam przyszło do głowy. No to wszystko może powodować, że to nie będzie tylko pasmo sukcesów, że to nie będą tylko kolejna wspaniałe decyzje. No i tutaj fajnie, jeśli Product Owner dostaje sygnał od organizacji, od swoich zarządzających, od może partnerów biznesowych, że nieodłączną częścią naszego działania jest również podejmowanie pewnych ryzyk i posiadanie w związku z tym lekcji, takiej bym powiedział negatywnych. Chociaż, nie rozpatrujmy tego pozytyw-negatyw. No czasem się uczymy, czasem nam coś wychodzi, czasem nam nie wychodzi. No i tu jest wielka rola liderów organizacji. Wielka rola też dojrzałości, panowania nad emocjami w tych momentach, gdy na przykład coś nie wychodzi. Coś się opóźnia, gdy właśnie nie odnosimy tych sukcesów, na które liczyliśmy, gdy jakaś inicjatywa była uruchamiana lub dalej kontynuowana. No bo pojedyncze, dosłownie pojedyncze negatywne przypadki mogą budować taką pewną famę i taką pewną brzydką sytuację, która będzie w przyszłości już traktowana, jako taki punkt odniesienia. Nie podejmę tej decyzji, ponieważ poprzednio kolega, koleżanka dostali opieprz, to ja też nie chcę dostać opieprzu. To może przeczekam, może przeciągnę, może znajdę kogoś, kto za mnie podejmie tę decyzję? Bardzo i niebezpieczne i sączące się zjawisko, które spotykam niestety w niektórych organizacjach.

Jacek: Albo te decyzje będą takie bardzo, bardzo zachowawcze, co może kompletnie udusić wszelkiego rodzaju innowacje i eksperymenty. Trzecia pułapka, którą chcemy się z Tobą podzielić dotyczy odległości Product Ownera od Klienta. No, można by było być nieco zaskoczonym, że taka sytuacja może