Właścicielstwo produktowe – w Biznesie czy w IT?

Gdzie powinno znajdować się właścicielstwo produktowe w organizacji? W IT? W biznesie? A może to temat, który wymaga zupełnie innego podejścia? Poznaj różne modele umiejscowienia odpowiedzialności za produkt i analizę ich wpływu na współpracę zespołów, podejmowanie decyzji i skuteczność wdrażania strategii. Sprawdź, w którym miejscu na osi znajduje się Twój zespół i oceń, czy można w tej kwestii uzyskać usprawnienia.

Możliwe modele umiejscowienia właścicielstwa produktowego

Pisząc o właścicielstwie produktowym, mamy na myśli miejsce w strukturze organizacyjnej, w którym znajdują się osoby zarządzające produktem, a także ich podległość służbowa. W zależności od firmy, mogą to być Product Ownerzy, Product Managerowie lub specjaliści odpowiedzialni za rozwój funkcjonalności. Niektóre organizacje te stanowiska nazywają inaczej, jednak ich rola pozostaje zbliżona.

W niektórych organizacjach stanowiska te mogą mieć inne nazwy, na przykład specjaliści ds. rozwoju funkcjonalności lub podobne role. Nie będziemy tutaj szczegółowo wymieniać wszystkich możliwych wariantów, ale na potrzeby tego tekstu będziemy używać określeń Product Owner i Product Manager, mając na myśli także inne, podobne stanowiska.

W różnych organizacjach spotykamy różne modele umiejscowienia właścicielstwa produktowego. Czasami te osoby znajdują się po stronie IT lub technologii, co oznacza, że są częścią zespołu technologicznego i współpracują głównie z działem inżynieryjnym. W innych przypadkach są przypisane do działu biznesowego, gdzie ich rola koncentruje się na strategii i rozwoju produktu z perspektywy rynku. Istnieją też organizacje, w których właściciele produktu funkcjonują jako osobna struktura, często podlegająca bezpośrednio zarządowi.

Przeanalizujemy najczęściej spotykane modele i omówimy, jakie konsekwencje niesie za sobą każdy z nich. Nie chodzi o wskazanie, który układ jest najlepszy, ale o przedstawienie, z czym wiąże się każda z tych opcji.

Brak jasnego właścicielstwa 

Pierwszym punktem na tej osi, od którego warto zacząć, jest sytuacja, w której właścicielstwo produktowe nie jest wyraźnie zdefiniowane. Oznacza to, że trudno wskazać, w jakim konkretnym obszarze organizacji się znajduje – czy jest po stronie IT, czy po stronie biznesu.

Jak rozpoznać taki stan rzeczy? Najczęściej przejawia się to w braku spójnej odpowiedzialności za decyzje. Praca nad produktem odbywa się głównie poprzez realizację losowych zleceń, które przychodzą z różnych źródeł. W skrajnym przypadku taka sytuacja prowadzi do równoległego funkcjonowania wielu inicjatyw, projektów i zmian, które nie są ze sobą skoordynowane. Efektem tego jest ich wzajemna konkurencja, a nawet wykluczanie się nazwajem.

W rzeczywistości zawsze znajdzie się ktoś, kto podejmie decyzję, w jakim kierunku mają podążać zespoły wytwórcze. Problem pojawia się wtedy, gdy jest to osoba, która podejmuje decyzje z konieczności, a nie z faktycznej odpowiedzialności za produkt.

Często rolę tę przejmuje ktoś bez kontekstu biznesowego, kto skupia się wyłącznie na priorytetyzacji zadań w sposób reaktywny, na przykład minimalizując ryzyko niezadowolenia różnych interesariuszy. W praktyce oznacza to, że lider zespołu czy inna osoba pełniąca tę rolę nie kieruje się myśleniem produktowym, lecz stara się jedynie zbalansować różne zlecenia, projekty i zmiany, tak by uniknąć problemów.

Podkreślamy to, ponieważ model, w którym nie ma wyraźnego właścicielstwa produktowego, ma głównie wady. Rozumiemy, że niektóre organizacje mogą się w takim stanie znajdować, ale jest to sytuacja, którą warto zmienić. 

Zarządca Backlogu w IT

Jest to krok w dobrą stronę, ponieważ w organizacji pojawia się osoba, którą można wskazać jako odpowiedzialną za zarządzanie pracami zespołu. Może to być Product Owner, lider zespołu, a czasem nawet Product Manager, choć w tym przypadku nazewnictwo bywa różne. Taka osoba znajduje się po stronie IT, jest częścią konkretnego zespołu, albo funkcjonuje w niewielkiej strukturze w ramach działu technologii. Jej rola polega na zbieraniu inicjatyw i zleceń od interesariuszy biznesowych, organizowaniu projektów oraz przekazywaniu ich do zespołu.

Jednak w tym modelu kluczową kwestią jest to, że osoba zarządzająca Backlogiem nie tworzy produktu ani nie ma realnego wpływu na jego kształt. Jej rola sprowadza się do koordynowania przepływu zadań i dbania o ich realizację, ale bez faktycznej sprawczości produktowej.

Należy zaznaczyć, że w tym artykule, nawet gdy używamy określeń takich jak Backlog czy Product Owner, nie odnosimy się stricte do Scruma. Te pojęcia na tyle mocno przeniknęły do firm, że stały się naturalnym sposobem opisywania ról i procesów w organizacjach.

W przypadku modelu zarządcy Backlogu kluczowe jest to, że taka osoba nie podejmuje decyzji o tym, co zostanie zrealizowane. Jej rola sprowadza się raczej do biernego wykonywania oczekiwań interesariuszy, bez realnego wpływu na kształt produktu. 

Warto uczciwie przyznać, że rola zarządcy Backlogu w IT, mimo swoich ograniczeń, ma pewne zalety w porównaniu do modelu, w którym właścicielstwo produktowe w ogóle nie istnieje. Przede wszystkim daje szansę na ucywilizowanie strumienia prac, na uporządkowanie zgłaszanych inicjatyw, minimalną dyskusję z interesariuszami oraz ewentualne grupowanie lub dzielenie inicjatyw w bardziej sensowne części. 

Zarządzanie produktem po stronie IT

Trzeci model to zarządzanie produktem po stronie IT. W przeciwieństwie do wcześniejszego podejścia, w tym przypadku mamy już wyraźnie określoną rolę, którą można nazwać Product Ownerem. Nie jest to jedynie osoba pasywnie realizująca oczekiwania interesariuszy, lecz ktoś, kto rzeczywiście zarządza produktem. Może posiadać własną wizję, roadmapę, a nawet określone wskaźniki mierzące postęp.

Choć taka osoba nadal funkcjonuje w strukturach IT i musi uwzględniać potrzeby różnych interesariuszy, to jednak jej rola wykracza poza mechaniczne realizowanie napływających zadań. W tym modelu pojawia się już myślenie długofalowe, a decyzje dotyczące produktu zaczynają być bardziej świadome i strategiczne.

Jest to model, w którym zarządzanie produktem staje się aktywne i opiera się na realizacji konkretnej wizji. Osoba odpowiedzialna za produkt może mieć realny wpływ na kierunek jego rozwoju, a nawet prawo do odrzucania niektórych pomysłów czy oczekiwań poszczególnych interesariuszy. Dzięki temu możliwe jest skupienie się na priorytetach i konsekwentne podążanie za przyjętą strategią, zamiast realizowania przypadkowych zachcianek.

Po stronie korzyści znajduje się możliwość konsekwentnej realizacji spójnej wizji. W niektórych produktach ma to kluczowe znaczenie, ponieważ pozwala eliminować przypadkowe inicjatywy i skupić się na istotnych aspektach. Istnieje jednak ryzyko oddalenia się od kontekstu biznesowego, strategii firmy czy współpracy z działami takimi jak sprzedaż, marketing czy wsparcie klienta.

Dodatkowym zagrożeniem jest skłonność do preferowania rozwiązań technologicznych. Często pojawiają się zarzuty, że osoby zarządzające produktem od strony IT wybierają priorytety w postaci migracji systemu, aktualizacji technologii czy pełnej refaktoryzacji, zamiast dostarczenia nowych funkcji, które mogłyby przełożyć się na korzyści biznesowe.

Jednocześnie są produkty, w których taki model jest optymalny. W szczególności dotyczy to rozwiązań technologicznych, produktów infrastrukturalnych lub firm dostarczających wysoce zaawansowane technologie, gdzie naturalnym miejscem dla zarządzania produktem pozostaje struktura IT.

Podwójne właścicielstwo 

Model czwarty, umiejscowiony dokładnie na środku omawianej osi, to podwójne właścicielstwo. Niektóre organizacje, często pod wpływem doradców i firm konsultingowych, zdecydowały się na takie rozwiązanie, aby uniknąć dylematu dotyczącego umiejscowienia właścicielstwa produktowego.

W tym modelu funkcjonuje dwóch właścicieli produktu – jedna osoba po stronie biznesu i druga po stronie technologii. W założeniu ma to pozwolić na podział odpowiedzialności: osoba z biznesu wnosi perspektywę strategiczną i rynkową, natomiast właściciel techniczny dba o kwestie funkcjonalne, bezpieczeństwo, wydajność oraz długoterminowe koszty utrzymania systemu. Chodzi o to, aby uzupełnić kompetencje i zapewnić, że kluczowe aspekty produktu nie zostaną pominięte.

W praktyce oznacza to, że w tym modelu istnieje dwóch Product Ownerów, którzy muszą wspólnie podejmować decyzje dotyczące rozwoju produktu. Ich stanowiska mogą różnie się nazywać, jednak istotą rozwiązania jest konieczność uzgadniania priorytetów i współdecydowania o kierunku działań. To może prowadzić zarówno do lepszego bilansu interesów, jak i do potencjalnych wyzwań związanych z procesem decyzyjnym.

Gdybyśmy mieli wskazać największe zagrożenie lub ryzyko tego modelu, to na pewno byłby to dualizm decyzyjny. W skrajnym, negatywnym scenariuszu dwie osoby odpowiedzialne za produkt mogą nie współpracować, wysyłać zespołowi sprzeczne sygnały i ciągnąć produkt w różnych kierunkach.

Mocny przedstawiciel biznesu może ignorować potrzeby technologiczne, na przykład zaniedbywać spłatę długu technologicznego lub odkładać aktualizację bibliotek czy frameworków, które wymagają zmian ze względów bezpieczeństwa. Z kolei dominujący lider techniczny może skupić się wyłącznie na aspektach technologicznych, zaniedbując potrzeby biznesowe, co w efekcie może hamować rozwój produktu w kontekście rynkowym.

Zarządzanie produktem po stronie biznesowej 

Kolejny model, który przybliża nas do przeciwnego końca osi, to zarządzanie produktem po stronie biznesowej. W tym przypadku za produkt odpowiada osoba o silnym profilu biznesowym – może to być Product Manager lub Product Owner wywodzący się z biznesu. Taka osoba ma pełne zrozumienie produktu i patrzy na niego w szerszym kontekście – nie traktuje go jedynie jako aplikacji czy rozwiązania technologicznego, ale jako część większego ekosystemu.

Taki lider rozumie, po co istnieje produkt, jaki jest jego cel i jakie wartości ma dostarczać. Dzięki temu wnosi do zespołu głęboką perspektywę biznesową. Jeśli do tej pory zespołowi brakowało takiego kontekstu, to taka osoba potrafi w stosunkowo krótkim czasie przekazać go zespołowi, pokazując, dlaczego realizowane działania są istotne. Dzięki temu praca zespołu nabiera nowego sensu i głębszego znaczenia, co może pozytywnie wpłynąć na jego zaangażowanie i motywację.

Nadal istnieje wyraźne rozróżnienie – jest ktoś, kto posiada wiedzę, ma dostęp do strategii i zarządu, i to ta osoba przekazuje ją zespołowi. Oczywiście można to zrobić w odpowiedni sposób, z dbałością o współpracę, ale wciąż występuje dynamika, w której jedna strona ma pełne zrozumienie kontekstu i decyduje o kierunku działań, a druga strona te decyzje realizuje. Nadal można to ulepszyć, a poniżej wyjaśniamy w jaki sposób.

W wielu organizacjach ten model ma również swoje zalety, ponieważ wzmacnia mechanizm wspólnej odpowiedzialności zarówno struktur biznesowych, jak i technologicznych. Strona biznesowa decyduje o priorytetach, podczas gdy technologia zajmuje się sposobem realizacji, efektywnością i produktywnością zespołu. Wszyscy są w ten proces zaangażowani, a ewentualne korekty wymagają współpracy menedżerów ze wszystkich obszarów organizacji.

Umocowane zespoły produktowe

W porównaniu do wcześniejszych układów mamy tutaj interdyscyplinarny zespół, który łączy kompetencje produktowe, biznesowe, technologiczne oraz szeroko rozumiane wsparcie. Członkowie zespołu wspólnie tworzą rozwiązania, a ich role nie są wyraźnie rozgraniczone według pionów organizacyjnych – w praktyce trudno określić, kto reprezentuje którą część organizacji.

Wszyscy zaangażowani uczestniczą zarówno w fazie kreatywnej, jak i w realizacji. Nadal istnieje funkcja lidera produktu, jednak jego rola jest bardziej włączająca – nie przynosi on gotowych rozwiązań, lecz współpracuje z resztą zespołu i podejmuje ostateczne decyzje. W efekcie granica między biznesem a technologią zaciera się, a cały zespół działa wspólnie, dążąc do realizacji strategii i wizji produktu.

Gdyby wskazać ryzyka czy słabsze strony tego modelu, to największym problemem jest jego realna trudność w osiągnięciu. Wymaga on istotnych zmian na poziomie mentalnym organizacji. Wymaga też innego profilu kompetencyjnego u członków zespołu – najlepiej sprawdzają się osoby o profilu T, cechujące się dużą otwartością.

W takich zespołach trudno jednoznacznie określić, kto pochodzi z jakiego działu. Przykładowo, o użyteczności aplikacji może wypowiadać się zarówno tester, jak i developer, a niekoniecznie osoba dedykowana do obszaru UX. Jest to kosztowny model, a jeśli nie funkcjonował od samego początku istnienia firmy, to jego wdrożenie może być trudne i bolesne.

Dla organizacji, które znajdują się na wcześniejszych etapach naszej osi i nie mają jeszcze jasno określonego właścicielstwa produktowego, przejście na ten model może być zbyt dużym skokiem. Mogą pojawić się pytania i wątpliwości dotyczące odpowiedzialności, co wymaga dużych zmian mentalnych i kulturowych w organizacji.Jeśli chcesz pogłębić wiedzę jeszcze bardziej, możesz znaleźć nasze płatne materiały na stronie porzadnyagile.pl/sklep

Jak w praktyce podejść do zmiany właścicielstwa produktowego?

Zdefiniuj gdzie jesteś

Pierwsza porada jest dość prosta – określ, w jakim miejscu się znajdujesz. Sprawdź, gdzie na przedstawionej przez nas osi lub na własnej, jeśli masz inne podejście, plasuje się Twoja organizacja. Warto oprzeć się nie tylko na własnej intuicji, ale także zebrać opinie zespołów, interesariuszy biznesowych i managerów, aby uzyskać pełniejszy obraz sytuacji. Jednym z największych zagrożeń jest błędne postrzeganie własnej organizacji – gdy wydaje się, że jest się na poziomie 5 lub 6, podczas gdy w rzeczywistości firma dopiero osiągnęła poziom 2. Każdy model wymaga odrębnej strategii zmiany, dlatego kluczowe jest dokładne zrozumienie punktu wyjścia.

Ma to szczególne znaczenie w większych organizacjach, gdzie różne zespoły mogą znajdować się na różnych etapach dojrzałości produktowej. Często zdarza się, że w jednej firmie istnieją zespoły bardziej progresywne, funkcjonujące w sprzyjającym środowisku, podczas gdy inne obszary wciąż pozostają na wcześniejszym etapie rozwoju. Firmy obsługujące różne rynki czy posiadające wiele linii biznesowych mogą mieć odmienne potrzeby i poziom zaawansowania, co wymaga szczególnej uwagi przy planowaniu zmian.

Dlatego kluczowe jest właściwe określenie punktu startowego, aby nie narzucać zbyt ambitnych zmian, które w niektórych obszarach mogą okazać się nierealne – np. jeśli firma nigdy nie miała jasno określonego właścicielstwa produktowego, próba natychmiastowego wdrożenia zespołów produktowych może być zbyt dużym skokiem i zakończyć się fiaskiem.

W praktyce może to oznaczać, że wprowadzane zmiany nie obejmą całej organizacji, lecz będą dotyczyć wybranego fragmentu struktury. Może to być konkretny obszar, określony value stream lub inna jednostka organizacyjna funkcjonująca w Twojej firmie. W takiej sytuacji zmiana będzie miała bardziej ograniczony zasięg, niż początkowo można by zakładać.

Ustal jakich rezultatów oczekujesz po zmianie

Warto określić spodziewane efekty w sposób jak najbardziej konkretny i mierzalny. Im precyzyjniejsze wskaźniki, tym łatwiej będzie ocenić skuteczność przeprowadzanych działań. Przykładem takich mierników mogą być lead time lub cycle time, czyli – upraszczając – czas od pomysłu do realizacji lub czas od rozpoczęcia pracy do jej zakończenia. To aspekty, które można stosunkowo łatwo zmierzyć i śledzić w czasie.

Jednak oprócz mierzalnych parametrów warto uwzględnić również czynniki trudniejsze do ujęcia w liczbach, ale mające istotny wpływ na funkcjonowanie organizacji. Przykładem mogą być odczucia zespołów dotyczące sensu ich pracy czy subiektywna ocena realizacji potrzeb biznesowych. Choć trudno je wyrazić w konkretnych wartościach liczbowych, nadal stanowią istotne aspekty, które warto uwzględnić jeszcze przed rozpoczęciem procesu zmiany.

Istnieją organizacje, w których pomiary są na wysokim poziomie, co pozwala na wybór odpowiednich wskaźników do monitorowania oraz określenie poziomu aspiracji i oczekiwanych rezultatów po wprowadzeniu zmian. Jednak nie wszystkie firmy dysponują dobrze rozwiniętym systemem mierników, co może utrudniać ocenę efektów transformacji.

W takich przypadkach warto rozważyć wdrożenie nowych metod pomiaru jako element zmiany w zakresie umiejscowienia właścicielstwa produktowego czy funkcjonowania zespołów produktowych. Może to obejmować wykonanie pomiaru bazowego przed wprowadzeniem zmian, aby później, po ich wdrożeniu i ustabilizowaniu, możliwe było dokonanie rzetelnego porównania. Przykładem takiego podejścia może być mierzenie poziomu satysfakcji ze współpracy w zespołach – przeprowadzenie ankiety przed i po zmianie pozwoli określić, czy przyniosła ona oczekiwane rezultaty.

Aby móc realnie ocenić, czy sytuacja się poprawiła, warto z wyprzedzeniem określić, jakie aspekty będą mierzone, oraz przygotować odpowiednie narzędzia do ich monitorowania, zwłaszcza jeśli obecnie firma lub jej część strukturalna nie posiada rozwiniętego systemu pomiarowego.

Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy

Trzecia porada może wydawać się nieco przewrotna – określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy. Warto zastanowić się, co może powodować opór wobec zmiany, ponieważ każda transformacja – zwłaszcza strukturalna – spotka się z pewnym poziomem sprzeciwu. Dotyczy to szczególnie sytuacji, w której właścicielstwo produktowe przechodzi na stronę biznesową, ponieważ taki ruch niesie ze sobą całą pulę potencjalnych wyzwań.

Dobrze jest więc z góry przewidzieć możliwe źródła oporu, określić, jakie argumenty mogą się pojawić przeciwko zmianie i kto może je podnosić. Pozwoli to lepiej zaplanować proces komunikacji, zarówno pod kątem przedstawienia racjonalnych argumentów, jak i opracowania mechanizmów wspierających transformację. Dzięki temu możliwe będzie odpowiednie zarządzanie obawami oraz dostarczenie kontrargumentów lub wskazanie korzyści, które przewyższą potencjalne trudności. Kluczowe jest, aby każdy uczestnik zmiany dostrzegł w niej wartość i miał poczucie, że nowy model przynosi mu konkretne korzyści.

Cztery najczęściej spotykane powody oporu:

Biznes nie rozumie IT. To często pojawiająca się obawa, która prowadzi do utrzymania status quo – na zasadzie: „My zajmujemy się biznesem, a IT niech robi swoje, i lepiej nie wchodźmy sobie w drogę.”

W takiej sytuacji warto zainwestować w zwiększenie wzajemnego zrozumienia. Osoby rozwijające produkty w firmach technologicznych nie muszą być ekspertami ani umieć programować, ale powinny rozumieć podstawowe aspekty technologiczne i konsekwencje decyzji technicznych. W drugą stronę, osoby odpowiedzialne za technologię powinny znać kontekst biznesowy i rozumieć realne potrzeby użytkowników oraz strategię firmy.

Na rynku istnieją specjaliści, którzy łączą oba światy, ale takie kompetencje można też rozwijać wewnętrznie. Dobrym rozwiązaniem może być także zapewnienie wsparcia w postaci ról takich jak architekt czy Tech Lead, którzy będą partnerami dla osób biznesowych i pomogą im stopniowo lepiej rozumieć kwestie technologiczne.

Biznes i IT nie mówią tym samym językiem, więc musi być ktoś, kto będzie ich tłumaczem. W szczególności dotyczy to modeli, w których Product Owner pozostaje po stronie technologii i pełni funkcję pośrednika. Zwolennicy tego podejścia często argumentują, że tacy Product Ownerzy rozumieją zarówno biznes, jak i technologię, więc lepiej, aby to oni nadal pełnili tę rolę.

To argument, który można skutecznie podważyć. Fakt, że dzisiaj obie strony mogą mieć trudności w komunikacji, nie oznacza, że tak musi pozostać. Zbliżenie biznesu i IT, o którym pisaliśmy w odcinku 130, może w dużej mierze rozwiązać ten problem.

Kluczowe działania to:

• Integracja zespołów – zamiast działać osobno, zespoły biznesowe i technologiczne mogą pracować bliżej siebie.
• Stworzenie wspólnego słownika – określenie jednoznacznych definicji i terminologii, które będą zrozumiałe dla obu stron.
• Wypracowanie sposobu komunikacji – umiejętność zadawania pytań, zatrzymywania się, parafrazowania i doprecyzowywania, tak aby nie było miejsca na błędne interpretacje.

Oczywiście, przesunięcie właścicielstwa produktowego do biznesu może oznaczać pewien okres przejściowy, w którym pojawią się tarcia, nieporozumienia czy śmieszne sytuacje wynikające z różnic w interpretacji tych samych terminów. Jednak w dłuższej perspektywie zespół nauczy się efektywnej komunikacji i nie będzie potrzebował tłumacza między dwiema stronami.,

Trzecim często spotykanym argumentem przeciwko zmianie jest przekonanie, że Biznes nie ma czasu na angażowanie się w pracę z zespołami produktowymi. To podejście stanowi istotne ograniczenie. W jednej z firm, z którą mieliśmy styczność, prezes jasno zakomunikował: „Transformujmy się, zmieniajmy, ale osoby z biznesu nie będą pracować z zespołami – nie mają na to czasu”.

Ta decyzja spowodowała, że w rolę Product Ownerów biznesowych weszli Project Managerowie. Było to jakieś rozwiązanie – na pewno lepsze niż brak właścicielstwa produktowego. Jednak brak prawdziwego kontekstu biznesowego sprawił, że zespoły produktowe cierpiały. W praktyce rola Product Ownera została sprowadzona do przekazywania wymagań i pilnowania ich realizacji, a nie do faktycznego zarządzania produktem w sposób uwzględniający potrzeby rynku i strategię firmy.

Czwartym często podnoszonym argumentem przeciwko zmianie jest przekonanie, że tylko technologiczny Product Owner zagwarantuje, że aspekty technologiczne będą odpowiednio priorytetyzowane i zaopiekowane.W niektórych organizacjach towarzyszy temu obawa, że jeśli odpowiedzialność za priorytety zostanie przekazana stronie biznesowej, to wszystkie najważniejsze kwestie technologiczne,  takie jak migracje, automatyzacje czy spłata długu technicznego, zostaną natychmiast odrzucone.

Może pojawić się presja, aby dostarczać rozwiązania szybciej, kosztem jakości i długofalowego utrzymania systemów.Kluczową rolę odgrywa tutaj jasna umowa między liderami technologicznymi a liderami biznesowymi. Organizacja powinna wypracować mechanizmy zapewniające odpowiednią równowagę między potrzebami biznesowymi a koniecznością dbania o stabilność i rozwój technologiczny.Formalna alokacja części przepustowości zespołu na zadania technologiczne. W jednej z organizacji przyjęto zasadę, że 20% zasobów zespołu zawsze jest przeznaczane na kwestie technologiczne.

W takim układzie Product Owner z biznesu może decydować o priorytetach wewnątrz tej puli, ale nie może jej całkowicie wyeliminować. Warto zadbać o przejrzyste Definition of Done, które określa niepodlegający negocjacjom standard jakości. To chroni zespoły przed presją na przyspieszanie kosztem długoterminowej stabilności systemów i pozwala uniknąć scenariusza, w którym „zrobimy to szybko teraz, a poprawimy później” – bo w praktyce często to „później” nigdy nie następuje.

Istnieje wiele sposobów na zabezpieczenie równowagi między biznesem a technologią. Kluczowe jest, aby organizacja świadomie wypracowała model, który pozwoli zaopiekować obie te sfery, zamiast przyjmować założenie, że tylko technologiczny Product Owner może o nie zadbać.

Zachęcamy jednak do samodzielnego przeanalizowania sytuacji w swojej organizacji, ponieważ w Twojej firmie mogą występować inne powody lub dodatkowe obawy, które nie zostały tutaj wymienione.

Nie sposób wyczerpać wszystkich możliwych argumentów, dlatego warto świadomie pochylić się nad tą kwestią, aby zrozumieć, co może powodować opór wobec zmian i jak najlepiej na te obawy odpowiedzieć.

Narysuj mapę sojuszników i przeciwników zmiany 

Czwarta porada dotyczy sposobu na skuteczną zmianę właścicielstwa produktowego w organizacji. Zbudowanie mapy sojuszników i przeciwników zmiany pozwala lepiej zrozumieć układ sił i zaplanować działania tak, aby zmiana miała większe szanse powodzenia.

Zdefiniuj kluczowe osoby – zastanów się:

• Kto wesprze zmianę i będzie aktywnie pomagał w jej wdrożeniu?
• A może ktoś pozostanie neutralny – nie sprzeciwi się, ale też nie będzie inicjatorem działań?
• Kto może być przeciwnikiem – czy to z obawy przed zmianą, czy z powodów organizacyjnych?

Takie zmiany, zwłaszcza te dotyczące przesuwania odpowiedzialności w strukturze organizacyjnej, często budzą sprzeciw. Ważne jest, aby rozpoznać zależności i wpływy, a następnie budować krąg sojuszników, którzy pomogą przekonać osoby sceptyczne.

Jeśli mówimy o stworzeniu mapy, dosłownie warto ją narysować. Może tu pomóc technika Stakeholder Bottleneck Mapping opisana m.in. w materiale wideo Geoffa Watsa  https://www.youtube.com/watch?v=B_WfnnNUC6o, . To proste narzędzie, które często prowadzi do odkrycia złożonych zależności w organizacji.

Ciekawym wnioskiem może być to, że nawet przeciwnicy zmiany mają w swoim otoczeniu osoby, które na nich wpływają. Może to być przełożony wyższego szczebla, ale też ktoś, kogo opinię dana osoba ceni. Identyfikacja takich powiązań pozwala na bardziej strategiczne działanie – jeśli nie możesz przekonać kogoś bezpośrednio, możesz znaleźć osobę, która ma na niego wpływ.

Warto więc zaplanować sprytną, dyplomatyczną akcję, aby zbudować poparcie dla zmiany i przeprowadzić ją skutecznie.

Myśl o strukturze jak o żyjącym bycie, a nie finalnym ustawieniu

Przedostatnia porada dotyczy postrzegania struktury organizacyjnej jako dynamicznego, ewoluującego bytu, a nie finalnego, niezmiennego ustawienia.

Nie należy zakładać, że zmiana modelu właścicielstwa produktowego lub przesunięcie się po omawianej wcześniej osi to jednorazowy proces. W rzeczywistości organizacje stale ewoluują, a struktury zmieniają się w odpowiedzi na nowe potrzeby, wyzwania i możliwości.

Z doświadczenia wynika, że apetyt na usprawnienia rośnie. Organizacje, które odniosły sukces, nie przywiązują się zbyt mocno do aktualnego modelu, lecz iteracyjnie doskonalą sposób, w jaki produkty są rozwijane i zarządzane.

Warto przyjąć otwartość na przyszłe zmiany, bo w dobrze funkcjonujących organizacjach ciągła refleksja nad strukturą prowadzi do kolejnych usprawnień. Z czasem pojawiają się nowe pomysły na to, jak można zwiększyć efektywność, skrócić czas dostarczania wartości i lepiej organizować współpracę.

Dlatego zamiast traktować nowy model jako ostateczny, warto myśleć o nim jako o kolejnym kroku w kierunku doskonalenia organizacji.To, że struktura produktowa podlega zmianom, nie jest błędem – wręcz przeciwnie, to naturalna część planu.

Otoczenie rynkowe jest zmienne, strategia organizacji może ewoluować, a niektóre produkty mogą się rozwijać szybciej lub zmieniać swoje miejsce na rynku. Wszystkie te czynniki są racjonalnymi argumentami za tym, by nieustannie doskonalić i dostosowywać strukturę produktową – a czasami nawet cofać wprowadzone zmiany, jeśli okazują się one mniej efektywne, niż zakładano.

Dodatkowym aspektem, który ma kluczowe znaczenie, jest wyczucie właściwego momentu na wprowadzenie zmiany. Czasami pojawia się okienko możliwości – nowy lider w organizacji, wyraźna potrzeba korekty procesów lub inna okazja, którą można wykorzystać do usprawnienia modelu zarządzania produktem. W takich sytuacjach warto działać szybko i odpowiednio reagować na kontekst biznesowy.

Z drugiej strony, mogą zdarzyć się sytuacje, w których lepszym wyborem jest wstrzymanie zmian i przeczekanie do bardziej sprzyjających warunków. Najlepszym podejściem jest posiadanie wizji stanu docelowego, przemyślany plan kilku kroków naprzód, ale jednocześnie elastyczność w dostosowywaniu tempa zmian. Daty wdrożenia nie powinny być sztywne – może się okazać, że niespodziewane okoliczności wymagają zarówno przyspieszenia, jak i wstrzymania transformacji.

Przyjmij, że lepsze jakiekolwiek właścicielstwo niż jego brak

Choć każdy z modeli ma swoje plusy i minusy, a umiejscowienie właścicielstwa produktowego w organizacji może być mniej lub bardziej efektywne, to przejście z modelu całkowitego braku właścicielstwa na jakikolwiek model – nawet niedoskonały – jest krokiem naprzód.

Nawet jeśli organizacja jest na etapie, gdzie jedyną możliwą opcją jest zarządzanie Backlogiem po stronie IT, to nadal jest to lepsze rozwiązanie niż brak odpowiedzialności i funkcjonowanie w chaotycznym modelu bez jasno określonego kierunku.

Jeśli w Twojej firmie lub strukturze właścicielstwo produktowe praktycznie nie istnieje, warto zastanowić się, co stoi na przeszkodzie jego wprowadzeniu i spróbować pokonać te bariery. Nawet minimalne właścicielstwo może przynieść znaczną poprawę, niezależnie od tego, czy zostanie ono umiejscowione po stronie IT, czy po stronie biznesu. Najważniejsze jest, aby wykorzystać najlepsze możliwe rozwiązanie, na jakie organizacja jest gotowa w danym momencie.

Jeśli czujesz, że potrzebujesz pomocy we wdrożeniu takich zmian u siebie, wspieramy liderów technologicznych w skutecznych transformacjach konkretnie i praktycznie. Pomagamy dostosować modele do specyfiki Twojej organizacji i działamy razem z Tobą. Porozmawiamy. Napisz na adres [email protected]

FAQ: Właścicielstwo produktowe – w Biznesie czy w IT?

Gdzie powinno być umiejscowione właścicielstwo produktowe w organizacji?

Jeśli właściciel produktu jest za daleko od biznesu – decyzje mogą nie uwzględniać realnych potrzeb. Jeśli jest oderwany od technologii – może nie rozumieć ograniczeń i możliwości. Kluczem jest znalezienie równowagi, by produkt był skutecznie zarządzany i dostarczał realną wartość.

Co się dzieje, gdy w organizacji brakuje jasnego właścicielstwa produktowego?

Brak jasnej odpowiedzialności za produkt prowadzi do chaosu: konflikty priorytetów, przeciągające się decyzje i duża ilość „gaszenia pożarów”. Efekt? Wolniejsze dostarczanie wartości dla klienta i frustracja zespołów.

Jaka jest różnica między Product Ownerem a zarządcą Backlogu IT?

Zarządca Backlogu IT przekazuje zadania od biznesu do zespołu, ale nie ma realnego wpływu na produkt. Product Owner aktywnie kształtuje wizję, podejmuje decyzje i patrzy na zmiany z perspektywy wartości.

Czy podwójne właścicielstwo produktowe to dobry pomysł?

Brzmi to jak kompromis, ale w praktyce może oznaczać walkę o priorytety i sprzeczne decyzje. Dlatego lepszym rozwiązaniem jest jeden decydent, który holistycznie patrzy na produkt.

Jak sprawić, by właściciel produktu podejmował dobre decyzje?

Kluczowe jest osadzenie właściciela produktu w rzeczywistości biznesowej i technologicznej. Powinien rozumieć zarówno potrzeby klientów, jak i ograniczenia zespołu.

Jak przekonać organizację do zmiany modelu właścicielstwa produktowego?

Każda zmiana napotyka opór. Kluczem jest zrozumienie, kto może wspierać zmianę, kto jest obojętny, a kto się jej sprzeciwia. Stworzenie mapy sojuszników i przeciwników pozwala lepiej zaplanować komunikację i strategię wdrażania zmian.

Czy struktura produktowa powinna być ustalona raz na zawsze?

Zdecydowanie nie! Organizacja, rynek i potrzeby klientów stale się zmieniają, więc struktura produktowa też powinna ewoluować. Myśl o strukturze jak o żyjącym bycie – bądź gotów na adaptację i elastyczne decyzje.

Dlaczego lepsze jest jakiekolwiek właścicielstwo niż jego brak?

Brak właścicielstwa produktowego oznacza wolniejsze podejmowanie decyzji i zespoły działające „na oślep”. Nawet jeśli model, który wprowadzasz, nie jest idealny – już sama próba zdefiniowania odpowiedzialności to duży krok naprzód.

Jakie modele stosują organizacje?

• Brak właścicielstwa – chaos, brak priorytetów, konkurujące inicjatywy
• Zarządca Backlogu w IT – odbieranie zleceń, brak realnego wpływu
• Zarządzanie po stronie IT – większa decyzyjność, ale ryzyko izolacji od Biznesu
• Podwójne właścicielstwo – balans Biznesu i IT, ale też możliwe konflikty
• Produkt po stronie Biznesu – blisko klienta, ale czy IT ma głos?
• Umocowane zespoły produktowe – interdyscyplinarność i pełna odpowiedzialność

Jak w praktyce podejść do zmiany właścicielstwa produktowego? 

• Zdefiniuj sobie gdzie w ogóle jesteś
• Ustal jakich rezultatów oczekujesz po zmianie
• Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy
• Narysuj mapę sojuszników i przeciwników zmiany
• Myśl o strukturze jak o żyjącym bycie, a nie finalnym ustawieniu

Dodatkowe materiały

• Stakeholder battlemapping
• Jak zbliżyć do siebie biznes i IT
• Wątek na Quora eksplorujący temat umiejscowienia właściciela produktu
• Punkt widzenia twórców podcastu Your Daily Scrum na temat właścicielstwa produktu

📄 Transkrypcja podcastu „Właścicielstwo produktowe – w Biznesie czy w IT?”

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

Jacek: Rozmawiałem ostatnio z szefem produktu, który dołączył do nowej firmy. Chwilę rozmawialiśmy o tym, jak wygląda środowisko pracy. Wspomniał, że jest tam dosyć spory podział, taki klasyczny między IT i biznesem. I temat, któremu poświęciliśmy najwięcej uwagi, to była dyskusja o właścicielstwie produktowym. Gdzie to właścicielstwo produktowe powinno być umieszczone w organizacji oraz porozmawialiśmy o możliwych rozwiązaniach.

Kuba: I abstrahując od tej konkretnej Jacka rozmowy, postanowiliśmy wspólnie, że to jest dobry temat na szeroki, konkretny, pełnoskalowy odcinek. Więc poopowiadam o tym, gdzie umiejscowić właścicielstwo produktowe i ewentualnie jak je zmienić, jeśli w Twojej organizacji czujesz, że zmiana powinna nastąpić. I co mamy na myśli, gdy mówimy w ogóle o właścicielstwie produktowym?

Mamy tutaj na myśli umiejscowienie osób, a w zasadzie ich raportowanie w strukturze, konkretna podległość służbowa osób, które zarządzają produktem, jakkolwiek te osoby w Twojej firmie są nazwane. To mogą być Product Ownerzy, to mogą być Product Managerowie. W niektórych organizacjach z różnych przyczyn te stanowiska mogą się jeszcze jakoś inaczej nazywać. Nie będziemy tutaj świadomie za długo wyliczać tych możliwych kombinacji, ale powiedzmy w miarę możliwości zamiennie będziemy mówić właśnie Product Ownerzy, Product Managerowie i mamy na myśli również na przykład specjalisty rozwoju, funkcjonalności albo tego typu odmiany.

No i spotykamy różne organizacje, modele funkcjonują różne. Te osoby mogą być bardziej po stronie IT czy technologii, jakkolwiek to w firmie się nazywa, czasami są po stronie biznesu, czasami są osobną strukturą gdzieś zaczepioną pod zarządem. Zarysujemy tutaj te możliwe pozycje strukturalne według takich najpopularniejszych modeli, jakie spotykamy. Trochę też scharakteryzujemy te przypadki. Na pewno nie chcemy powiedzieć, że który jest lepszy lub gorszy, ale po prostu pokazujemy, co naszym zdaniem wiąże się z takim, a nie innym układem.

Jacek: I dlaczego w ogóle ten temat jest ważny? Jest to naszym zdaniem ważny kawałek układanki dotyczącej tego, jak blisko bądź jak daleko współpracuje ze sobą biznes i IT. No, mamy tutaj z Kubą wyraźną preferencję. Nasze doświadczenie pokazuje, że im bliżej te dwa byty funkcjonują, im bardziej to jest taka naturalna współpraca ponad granicami departamentów czy strukturalnych, tym po prostu jest lepiej.

Nie będziemy o samych korzyściach zbliżania biznesu i IT rozmawiać w tym odcinku, bo mamy cały odcinek nagrany tylko o tym temacie. Jeżeli jesteś zainteresowany tym tematem, to odsyłamy do odcinka „Jak zbliżyć do siebie biznes i IT”. Jest to odcinek numer 130.

Kuba: Do znalezienia pod adresem porzadnyagile.pl/130. Ale taka teza, która jest gdzieś z tyłu tego odcinka, to to, że odpowiednie umiejscowienie właścicielstwa produktowego może wpływać na zaangażowanie zespołu wspólną, odpowiedzialność czy takie poczucie odpowiedzialności, sprawność podejmowania decyzji i pewnie jeszcze parę innych kwestii. Więc jest to aspekt ważny i przejdźmy teraz do konkretnych. O czym opowiem w tym odcinku?

Jacek: Spis treści na dzisiaj. Opowiemy, jakie widzimy możliwe modele umiejscowienia właścicielstwa produktowego w organizacji. W drugiej części nagrania podzielimy się tym, jak w praktyce podejść do zmiany właścicielstwa produktowego.

Kuba: Ok, to zaczynając od pierwszego rozdziału, jakie są możliwe modele umiejscowienia właścicielstwa produktowego?

Jacek: Tak, no to pierwszym punktem na tej osi, takim punktem startowym, to jest brak jasnego właścicielstwa. Oznacza to, że ono nie jest wyraźnie zdefiniowane, czyli nie możemy powiedzieć, że jest w jakimś konkretnym obszarze organizacji. W szczególności nie możemy powiedzieć, czy jest bardziej po stronie IT, czy po stronie biznesu. Po czym poznać taką sytuację?

Jest to bardziej praca, która jest realizowana na losowych zlecaniach, na zasadzie one skądś przychodzą, pewnie jest jakaś osoba, której zależy, ale tak na koniec dnia nie ma pełnej jasności, gdzie leży odpowiedzialność za decyzje. W takim gorszym scenariuszu może to oznaczać, że w organizacji jednocześnie toczy się wiele inicjatyw, czy wiele projektów, czy wiele zmian, które mogą ze sobą bądź konkurować, a czasem w też przez brak koordynacji i takiego spojrzenia z lotu ptaka mogą się nawet wzajemnie wykluczać.

Kuba: Realnie pewnie ktoś istnieje, kto na końcu podejmie pewną decyzję, czym się zajmują zespoły wytwórcze, ale może być to ktoś, kto robi to z musu, robi to osoba, która na przykład nie ma żadnego kontekstu biznesowego, tylko po prostu zajmuje się priorytetyzacją zadań, na przykład na minimalizację krzyku. Czyli na przykład lider zespołu skupia swoją uwagę na tym, żeby jak najmniej podpaść i jakoś tam balansuje między zapytaniami, zleceniami, projektami, jakimiś zmianami, ale tak naprawdę tam nie ma żadnego myślenia produktowego, jest co najwyżej gdzieś tam kierowanie strumieniem prac.

Tak chcemy to może uwypuklić, bo jednak na początku trochę powiedzieliśmy, że będziemy oceniać, tak wydaje się, że ten model, w którym nie ma w ogóle żadnego właścicielstwa, od niego zaczynamy, on raczej głównie ma wady i ma mało zalet. Rozumiem organizacje, w których w takim stadium istnieją, funkcjonują, ale ten akurat stan na pewno warto zmienić, o czym będziemy mówili w drugim rozdziale.

Kuba: Drugi model to zarządca Backlogów IT. Tu już jest trochę lepiej, gdyby kogoś zapytać, kto tutaj zarządza produktem, to być może przynajmniej część członków zespołu i być może część reszty organizacji powiedziałaby: No jest taki ktoś, może to jest Product Owner, może to jest lider zespołu, może to jest nawet Product Manager, chociaż najczęściej takich akurat nazw na to bym nie dawał. Jest ktoś, kto siedzi po stronie IT, albo jest częścią konkretnego jednego zespołu, albo jest częścią jakiejś dodatkowej niewielkiej struktury w ramach struktury całego IT czy technologii.

Jest to osoba, która gromadzi zlecenia, zbiera inicjatywy od interesariuszy biznesowych, realizuje te projekty, odbiera i przekazuje do zespołu, tak chcę może to trochę wypuklić, realnie nie tworzy produktu. Realnie tylko jakby skupia się na tym, żeby wiedzieć, czego się oczekuje od zespołów w miarę sprawnie przekazać to do realizacji. Nie ma tam żadnej sprawczości produktowej.