Dzisiaj spróbujemy odczarować pracę produktową w software housach i popularną tam rolę Proxy Product Ownera. Dla wielu z nas jest to opcja na rozwój kariery lub miejsce gdzie możemy rozpocząć naszą produktową karierę. Jak taka praca wygląda w praktyce?

O swoich doświadczeniach opowie nam praktyk - Jan Michalewski, Product Owner w Xebia Poland (wcześniej PGS Software). Zobaczymy, czym różni się praca w tej roli w software house i firmie produktowej, jakich kompetencji potrzeba, jak wygląda rozwój kariery i… wnioski po kilku latach pracy w software house ;).

• 1️⃣ Najważniejsze różnice

• 2️⃣ Kompetencje

• 3️⃣ Kariera jako PO w Software House

  • 3.2. Możliwości rozwoju

  • 3.3. Przyszłość PO w Software Housach

• 4️⃣ Moje doświadczenia w roli Proxy PO

  • 4.1. Nad czym pracowałem?

  • 4.2. Mój typowy dzień jako PO w Software House

  • 4.3. Co dała mi praca w SH? Najwięsze plusy

• 5️⃣ Komu polecam rolę Proxy PO?

• 👉 Jakie kolejne tematy poruszyć?

Product Owner to stosunkowo nowa rola w software housach. Do niedawna funkcja ta kojarzona była tylko z firmami produktowymi - jednak w ostatnich latach mocno się to zmieniło i wiele SH zaczęło zatrudniać PO.

Przyczyny takiego stanu rzeczy to:

• Wzrost zapotrzebowania na usługi Product Ownerów i Product Managerów, po okresie pandemii - wiele organizacji, mierząc się z problemem rekrutacji, zaczęło szukać kompleksowych rozwiązań, oczekując od software house'ów dostarczenia zarówno zespołów deweloperskich, jak i Product Ownerów.

• Wiele SH pracuje w agile i scrumie - naturalne więc stało się wprowadzenie roli PO

• Przeciążenie pracą i niedostępność Product Managerów po stronie klientów - w związku z czym zaczęli oczekiwać od software house spojrzenia wykraczającego poza ramy projektu, rozumienia biznesu i produktu.

• Chęć delegowania całości odpowiedzialności za dostarczenie konkretnego produktu bądź jego części na software house

Jako że Właściciel Produktu jest po stronie klienta, w software housach wytworzyła się naturalnie rola Proxy Product Ownera, który jest niejako pośrednikiem między zespołem developerskim dostawcy, a klientem. Klient oczywiście podejmuje finalne decyzje, ale zespół ma dostępnego Proxy PO reprezentującego klienta. Oznacza to, że w jakimś zakresie przejmuje on część obowiązków Product Ownera, szczególnie tych związanych z pracą na rzecz zespołu.

Ja zdecydowałem się na pracę w software house z dwóch powodów:

• Pierwszy był taki, że mając doświadczenie pracy w platformach e-commerce, chciałem spróbować sił w sklepie internetowym.

• Drugi powód to chęć pracy w języku angielskim, żeby otworzyć się na globalny rynek pracy.

Ofertę, która spełniała oba te kryteria dostałem w software house.

Poniżej zebrałem moje 6-letnie doświadczenia z tej roli, tak by pokazać Ci jak wyglądają realia, a nie tylko książkowa teoria.

1️⃣ Najważniejsze różnice

Pewnie najbardziej trafna i jednocześnie najmniej lubiana odpowiedź na pytanie o różnice brzmi: “to zależy”. Role PO zarówno w firmach produktowych jak i SH są interpretowane bardzo różnorodnie: silny wpływ ma na to zarówno specyfika firmy, jej wielkość czy branża.

Można jednak pokusić się o pewne uogólnienia, choć zaznaczam, że przedstawione powyżej wnioski bazują przede wszystkim na moich doświadczeniach, nie muszą więc być adekwatne w każdym kontekście każdej organizacji.

Główna różnica bazuje na fakcie, że PO w software house działa nie tyle w swoim imieniu ile, jako pełnomocnik zespołu dla klienta, jest więc de facto Proxy PO. Stąd biorą się kolejne różnice.

1.1. Odpowiedzialność i decyzyjność

Tak to działa w dużym uproszczeniu, ale dużo zależy też od intencji, z jaką klient przychodzi do software house. Jeśli przychodzi po tzw. „team enhancement”, czyli konkretne role, o które zwiększa swój team, raczej będzie szukał osoby do sprawnej realizacji już określonych zadań.

• W praktyce taka współpraca wyglądać może w ten sposób, że ostateczny głos co do rezultatów pracy (outcomów) należy do klienta, podobnie jak kamienie milowe i horyzont czasowy ich realizacji.

• Większą autonomię PO ma co do konkretnych outputów, które są dostarczane, ich finalnego wyglądu, przyjętych metod pracy i organizacji zespołu.

• Praktyka pokazuje, że nawet jeśli początkowo klient zatrudnia w modelu Proxy PO, z czasem i wraz z rozwojem wzajemnego zaufania PO zyskuje coraz więcej zaufania i decyzyjności.

• Wynika to z obciążenia Product Managerów po stronie klienta - delegowanie coraz większej odpowiedzialności jest po prostu pragmatyczne.

Jeśli klient przychodzi z “problemem” do rozwiązania i decyduje się na wspólną fazę discovery, wtedy Product Owner od początku będzie miał duży impact na zdefiniowanie oczekiwanych rezultatów prac czy wypracowanie roadmapy produktu.

1.2. Horyzont czasowy i głębokość wiedzy

1.3. Relacje z interesariuszami

Zazwyczaj na początku drzwi do klienta są tylko częściowo uchylone, a kontakt Product Ownera ogranicza się do wybranych przedstawicieli klienta. Doświadczenie pokazuje jednak, że z czasem i wraz ze wzrostem wzajemnego zaufania, zyskujemy też bezpośredni kontakt do wewnętrznych interesariuszy.

1.4. Priorytety i mierzenie sukcesu

1.5. Podejście do researchu

Choć trzeba zaznaczyć, że jeśli product design jest także kompetencją software house PO prowadzi cykliczne badania u klientów wspólnie z designerami. W jednym z projektów, w których brałem udział taka sytuacja miała miejsce i klient niejako delegował customer research na PO i software house.

1.6. Wpływ umowy i modelu współpracy z klientem

Dużo różnic w pracy Product Ownera w software house, wynika z tego, że firmę wiąże umowa z klientem i formalne uzgodnienia co do charakteru współpracy. Może to determinować zakres obowiązków, podejmowanie decyzji i codzienną pracę PO.

• Zakres obowiązków i decyzyjność - będzie mocno zdeterminowana charakterem współpracy. Inaczej będzie sytuacja wyglądała przy projektach typu „team enhancement” a inaczej, gdy umowa będzie zawierana na fazę discovery.

• Rodzaj umowy i model rozliczeń ma również duży wpływ na działania PO:

  • Fixed Price - przy ustalonym budżecie istotne zmiany zakresu wymagają każdorazowo renegocjacji, co ogranicza elastyczność.

  • Sam pracowałem w ramach modelu Time & Material, który z kolei pozwala na dużo większą elastyczność i zwinność.

• Relacja klient-dostawca - chociaż staramy się budować partnerskie relacje, to jednak zawsze ten element w jakimś stopniu występuje. Wynika to też z zakresu odpowiedzialności, która jeśli chodzi o produkt finalnie obciąża klienta. To Product Managerowie po stronie klienta są odpowiedzialni za ROI z inwestycji w produkt więc ich siła nacisku może być większa niż PO z software house. Dlatego tak ważna w tej roli jest umiejętność przekonywania i zarządzania oczekiwaniami.

2️⃣ Kompetencje

W software house od produktowca nie oczekuje się zwykle budowania długofalowej wizji czy strategii produktu. Proxy PO nie będzie zazwyczaj zanurzony w procesach sprzedażowych i marketingowych.

To na co kładziony będzie nacisk, to umiejętności w obszarze współpracy, zarówno w ramach samej organizacji klienta, jak i zespołu deweloperskiego, szeroko rozumianego delivery oraz kompetencje w zakresie identyfikowania potrzeb i dostarczania optymalnej wartości.

2.1. Kluczowe kompetencje

• Szybkie zrozumienie produktu klienta, wartości, które daje użytkownikom i kluczowych person (w zakresie tego bardzo ważna jest umiejętność facylitacji warsztatów typu discovery);

• Budowanie roadmapy i delivery planu w oparciu o informacje od klienta, praca na outcomach;

• Kompetencje w zakresie delivery, wytwarzania oprogramowania, project managementu, zarządzania Backlogiem produktu;

• Umiejętności łatwego budowania porozumienia z interesariuszami po stronie klienta. Umiejętności znajdowania kompromisów i facylitacja spotkań;

• Budowanie wspólnego rozumienia celów z klientem i zespołem po stronie software house;

• Rozumienie różnic kulturowych i ich znaczenia w komunikacji i codziennej pracy

• Zarządzanie oczekiwaniami klienta i jego stakeholderów;

• “Consulting mindset”: umiejętność szybkiego odkrywania potrzeb i problemów klienta na wielu poziomach i proponowanie rozwiązań;

2.2. Kompetencje przydatne w zależności od projektu

• W obszarze customer research - umiejętność docierania do potrzeb użytkowników, prowadzenia wywiadów z użytkownikami, zbieranie feedbacku

• Metryki i analiza danych - budowanie rozwiązań i wyciąganie wniosków produktowych, definiowanie kryteriów sukcesu.

• Kompetencje techniczne (integracje, API, bazy danych, itp.). Rozumienie technologii chmurowych i ich wpływu na rozwój produktów cyfrowych.

2.3. Kompetencje o mniejszym znaczeniu

• Budowanie strategii i wizji produktu

• Go to market strategy - pozycjonowanie, segmentacja produktu, strategie cenowe. Kompetencje w zakresie marketingu i rozumienia procesów sprzedażowych

• Odnajdywanie się w meandrach polityki firmowej i korporacyjnej

3️⃣ Kariera jako PO w Software House

3.1. Zarobki

Nie ma raportów płacowych skupionych głównie na roli Proxy Product Ownera w software hause. Dużym przybliżeniem będą jednak role w product, project managemencie i analityce biznesowej.

Z ostatniego raportu „Rynek pracy IT 2024/2025” w No Fluff Jobs, wynika, że widełki w tych rolach na poziomie regular to 15 - 22 tys. zł netto na umowie B2B.

W raporcie „Zarobki produktowców 2021/2022” zarobki product ownerów były o ok. 10-15% niższe niż osób na stanowisku product managera (dotyczy to także wszystkich product ownerów, a nie tylko pracujacych w software hause). Wydaje się to też dobrym przybliżeniem - w takiej sytuacji widełki na poziomie regular byłyby najbardziej zbliżone do roli project managera: 14 - 18 tys. zł. netto na umowie B2B.

3.2. Możliwości rozwoju

Bazując na moich doświadczeniach mogę stwierdzić, że:

• W ramach struktur software house, rozwój zawodowy jest możliwy w ramach Seniority Levels. Jest też otwarta, dosyć naturalna droga z pozycji analityka biznesowego do roli Product Ownera, gdy ktoś zdecyduje się na taką ścieżkę.

• Niewątpliwą zaletą pracy w SH jest to dostęp do wysokiej jakości szkoleń jak i do wiedzy znajdującej się w organizacji.

• Szybka adopcja różnych trendów i nowinek takich jak np. zastosowanie generatywnej sztucznej inteligencji w różnych obszarach.

• To co może być problematyczne to brak możliwości awansu pionowego do roli Head of Product - taką rolę pełni przedstawiciel klienta.

• Także przejście do firmy produktowej może być utrudnione, wtedy gdy poszukiwany jest specjalista z dłuższym doświadczeniem w danej branży. Tutaj zmiany kontekstu mogą nie być atutem, choć z drugiej strony znajomość różnych branż i produktów może być postrzegana jako atut.

3.3. Przyszłość PO w Software Housach

Widzę dwa duże trendy w kontekście roli product ownera:

• Obecnie obserwujemy turbulencje na rynku IT i pewną tendencję powrotną do zatrudniania PO wewnętrznie w firmach.

• Z drugiej strony firmy poszukują coraz częściej nie tylko partnerów technologicznych, którzy wdrożą oczekiwane rozwiązania, ale również wsparcia biznesu i procesów.

Duże znaczenie zyskują w tej sytuacji osoby z doświadczeniem w zarządzaniu produktem, które wesprą w zakresie tych kompetencji, które są mniej rozwinięte w organizacji. Jakich? To będzie zależeć od konkretnej organizacji: może to być product discovery, SEO, chmura czy metryki produktowe, a pewnie już wkrótce wykorzystanie AI.

Doświadczeni Product Ownerzy odnajdą się w mojej opinii również w projektach konsultingowych, gdzie klienci poszukują doradztwa, jak wdrożyć określoną technologię z korzyścią biznesową.

4️⃣ Moje doświadczenia w roli Proxy PO

Przygotowałem jeszcze trochę moich praktycznych spostrzeżeń i doswiadczeń na bazie kilkuletniej kariery jako PO w software hause.

4.1. Nad czym pracowałem?

Na start chciałbym Ci pokazać nad czym miałem okazję pracować w ostatnich latach. Powinno to dać Ci dobry pogląd na to, czym taki Proxy PO się może zajmować. U mnie była to praca dla klientów z różnych branż, gdzie jako Product Owner byłem odpowiedzialny m.in. za następujące obszary:

Dla klientów z branży e-commerce (B2C i B2B):

• Wdrożenie MVP globalnego sklepu:

  • przygotowanie roadmapy produktowej

  • zarządzanie backlogiem produktu, priorytetyzacja backlogu, refinement, UX we współpracy z design teamem.

• Integracje z zewnętrznymi systemami:

  • ERP w celu zapewnienia ciągłości operacyjnej

  • wspierającymi marketing i promocje

• tworzenie rozwiązań analitycznych i metryk do analizy produktu.

• szkolenie i wdrażanie nowych funkcjonalności w organizacji

Dla klienta z branży task management and productivity:

• Migracja aplikacji do chmury:

  • Identyfikacja potrzeb stakeholderów, budowanie klarowności co do celów i ich realizacji

• Rozwój aplikacji webowej: 

  • product discovery, prowadzenie wywiadów z użytkownikami, identyfikacja potrzeb klientów

  • testowanie prototypów UX, zbieranie feedbacku na etapie projektowania rozwiązań.

4.2. Mój typowy dzień jako PO w Software House

• Daily i codzienna współpraca z zespołem deweloperskim

• Spotkania z interesariuszami po stronie klienta

• Przygotowywanie do refinementu: konsultacje z designerem, architektami

• Refinement zadań wspólnie z zespołem deweloperskim

• Zarządzanie backlogiem produktu, tworzenie wymagań

• Praca nad roadmapą produktu

• Analiza metryk produktowych

4.3. Co dała mi praca w SH? Najwięsze plusy

• Możliwość pracy w różnych kulturach organizacyjnych, poznanie ludzi z innych narodowości czy nawet kręgów kulturowych. Jest to doświadczenie, które poszerza perspektywę.

• Doświadczenie pracy z produktami w różnych modelach biznesowych: B2B, B2C, aplikacjami różnego typu: webowymi, mobilnymi, desktopowymi i styczność z technologiami w nich stosowanymi.

• Uczestniczenie w projektach o charakterze konsultingowym, dających możliwość wykorzystania swojej wiedzy eksperckiej w doradztwie biznesowym.

• Dostęp do wiedzy osób pracujących w software house, duży nacisk kładziony na rozwój i poszerzanie własnych umiejętności poprzez szkolenia wewnętrzne i zewnętrzne oraz wymianę wiedzy.

5️⃣ Komu polecam rolę Proxy PO?

Rola Product Ownera w software house na pewno nie jest dla wszystkich. Dlatego zamiast podsumowania, na koniec kilka przemyśleń odnośnie tego komu polecam/odradzam taką karierę:

Komu polecam pracę jako PO w Software House:

• osobom, które chcą poznać szerokie spektrum branż i rozwiązań, lubią też przenosić doświadczenia z innych branż do nowego środowiska. Przykładowy problem: jak wykorzystać doświadczenia z analityki produktów webowych w aplikacjach desktopowych,

• osobom, które lubią pracę przy delivery, przy tworzeniu i wdrażaniu oprogramowania,

• które dobrze czują się w pracy w języku angielskim i są na tyle elastyczne, że odnajdą się w różnych kontekstach kulturowych

• chcą pracować zdalnie i odnajdują się w metodach i narzędziach takiej pracy

Odradzam tę rolę osobom, które:

• specjalizują się w określonej, wąskiej dziedzinie albo chcą związać swoją karierę z tylko jedną branżą (choć pojawia się w SH tendencja do specjalizacji, niektóre z nich koncentrują się też na pozyskiwaniu klientów z określonych branż, więc nie musi to być regułą w każdym przypadku)

• chcą pracować na wizji i mieć duży wpływ na kształtowanie strategii produktu

• wolą być związane z danym produktem w dłuższym, kilkuletnim horyzoncie czasowym

• chcą uczestniczyć i mieć wpływ na procesy go-to-market, sprzedażowe i marketingowe produktów

👉 Czego jeszcze chcesz się dowiedzieć od doświadczonego PO w Software House?

Myślimy o kontynujacji tematu, tak by w kilku częściach powstał poradnik dla PO w Software House. Oczywiście praktycznie, na podstawie mojego i Tomka doświadczenia. Daj nam znać w komentarzu czy temat jest dla Ciebie interesujący i jakie wyzwania w tej roli powinniśmy zaadresować w kolejnych częściach.