Z tego podcastu dowiesz się:

• Kim jest product owner i jakie ma kompetencje
• Kim jest product manager i jaka jest jego odpowiedzialność
• Dlaczego o product managerze mawia się „tygiel komunikacyjny”
• Jakie analizy prowadzi product manager
• Które metryki najbardziej interesują product managera
• Kto podejmuje decyzje: product owner czy product manager
• Na czym polega research PMa
• Czym dla PMa jest business model canvas
• Co to jest roadmapa i kto ją tworzy
• Dlaczego wizja produktowa jest taka ważna
• Kto zarządza backlogiem
• Kto ustala priorytety w projekcie
• Jak product owner nadzoruje prace programistów
• Czym jest zwiększanie wartości produktu (inkrementacja)
• Jakie są różnice pomiędzy product ownerem i product managerem

Podcastu wysłuchasz także na:

• Spotify
• YouTube
• Google Podcasts
• Apple Podcasts

---

Transkrypcja podcastu

Być Jak Manager Podcast, epizod drugi.

Dzień dobry.

Bardzo jest mi przyjemnie gościć zwłaszcza tych słuchaczy i widzów, którzy mieli okazję wysłuchania lub obejrzenia pierwszego epizodu. Jeśli nie, to serdecznie was do tego zachęcam. Odnośniki do poprzednich epizodów znajdziecie w opisie do tego podcastu.

Dla tych, którzy są tutaj po raz pierwszy, wyjaśnię, że ten cykl podcastów związany jest z szeroko pojętą branżą kierowniczą w IT. Chodzi mi ogólnie o kadrę zarządzającą w firmach technologicznych.

Tematyka poruszana w tym cyklu, przedstawiona jest być może w nieco spłaszczony sposób, ale kieruje swój podcast do ludzi, którzy jeszcze nie zaczęli lub dopiero zaczną swoją przygodę z branżą informatyczną. A także do osób, które zaczęły tę przygodę, ale są tak zwanymi „świeżakami”, do czego nie boją się przyznać.

Także osoby bardziej doświadczone mogą się delikatnie nudzić. Aczkolwiek wydaje mi się, że dzisiejszy temat jest ostatnio dość popularny nie tylko w kręgach juniorskich, ale także midów, tudzież seniorów mniejszych i większych organizacji.

Widzę pewną tendencję do opisywania stanowisk product managera i product ownera w jednakowy sposób. Jeśli rozejrzysz się po rynku pracy, to opis tych ról, ich kompetencji i zakresu obowiązków jest bardzo często niemalże identyczny.

Są delikatne różnice pomiędzy tymi dwiema rolami. Ja dzisiaj o nich opowiem, ale nie oznacza to wcale, że jestem ogromnym fanem tego, żeby zawsze te stanowiska rozdzielać lub na przykład budując zespoły technologiczne, na siłę wciskać zarówno jedną, jak i drugą rolę.

Ja chcę wam tylko wyłożyć, jakie widzimy różnice. A to, czy obie te role, czy tylko jedna z nich jest potrzebna w organizacji, tę decyzję chyba będą już podejmowały poszczególne firmy. Bo punkt widzenia i punkt zapotrzebowania na konkretne role zależy zawsze od punktu siedzenia i punktu projektowania. To wydaje mi się jasne.

Dziś postaram się bardzo szybko, zwięźle i na temat. Jeśli na pewne kwestie nie odpowiem lub nie rozjaśnię waszych wątpliwości i chcielibyście o coś dopytać, to sekcja komentarzy zawsze jest dla was.

Także moje media społecznościowe. Jeśli nie chcecie pytać na forum, nie wahajcie się, aby wysłać mi wiadomość prywatną na Instagramie, LinkedInie, tudzież Facebooku. Chociaż tam zaglądam najrzadziej ostatnio.

Porozmawiajmy więc o kompetencjach i obszarach tych obu ról.

Zacznijmy może od product managera, chociaż tutaj ta kolejność jest randomowa. Nie mam żadnej podkładki ani argumentu na to, dlaczego chcę zacząć od product managera. Był to wybór zupełnie losowy.

Główna kompetencja product managera.

Jeśli chcielibyśmy jednym zdaniem określić, czym tak naprawdę zajmuje się product manager, to spotkalibyśmy wiele różnych opisów. Wydaje mi się, że ile managerów poznacie, tyle definicji usłyszycie. Definicja, która do mnie najbardziej trafia, zawiera się w tej konkretnej sentencji:

Product manager to osoba, która identyfikuje problemy rynkowe warte rozwiązania, a następnie prowadzi grupę, która te problemy rozwiąże.

Tyle, jeśli chodzi o definicję ogólną i ja się z nią zgadzam. Jeśli jakaś inna definicja bardziej do was trafia, podzielcie się nią w komentarzu z innymi słuchaczami odcinka.

Jakie są tak naprawdę kompetencje product managera?

Te kompetencje, jak dowiecie się już niedługo, różnią się w niektórych miejscach nawet diametralnie od kompetencji product ownera. Pierwszą taką grupą dwóch kompetencji nazwałbym:

Connecting and communicating — tak po angielsku, żeby było ładniej, takie smooth — łączenie i komunikowanie.

Product manager, każdy, niezależnie od szerokości geograficznej lub projektowej to tygiel komunikacyjny.

Pewien węzeł komunikacyjny, który musi być mostem pomiędzy różnymi grupami specjalistów wewnątrz organizacji. I to należy do głównych kompetencji product managera, wydawałoby się kompetencji łatwych. Ktoś mógłby powiedzieć miękkich, chociaż miękkie to nie zawsze łatwe, zazwyczaj trudne.

Z kompetencji miękkich możemy wymienić:

Hostowanie regularnych spotkań, na przykład z działem supportu, sprzedaży, klientami, użytkownikami, marketingiem czy zespołem deweloperskim.

Spotkania, które hostuje w ramach swoich kompetencji product menedżer, zawsze mają jeden ogólny, fundamentalny kontekst. Są to spotkania dotyczące rozwoju konkretnego serwisu lub usługi, które nazywamy produktem jakiejś organizacji.

Po co on hostuje te spotkania?

Przede wszystkim po to, żeby komunikować wszystkim grupą specjalistów w firmie strategię tego produktu. Mówiąc dokładniej kierunek, w którym chcemy rozwijać produkt i dlaczego?

Hostuje te spotkania także po to, żeby uzyskać informacje i potrzebną wiedzę domenową z poszczególnych obszarów, żeby mógł tę strategię budować.

I wydawałoby się, że ktoś, kto spojrzałby na te role z zewnątrz, powiedziałby, że product manager to taki gość, który od rana do wieczora siedzi na spotkaniach.

Oczywiście bywają spotkania mniej lub bardziej produktywne. Koniec końców jednak outcomem hostowania tych spotkań dla product managera jest to, aby upewniać się, że produkt, który te wszystkie grupy specjalistów rozwijają wspólnie, idzie w dobrym kierunku.

Wyobraźmy sobie, że naszym produktem jest statek. Product manager w tym wypadku — cholera powiem to — jest kapitanem.

Ja wiem, że firmy mają jeszcze swoich CEO, których to często nazywa się kapitanami. Jeżeli więc mamy też CEO na pokładzie, no to product manager będzie takim zastępcą kapitana.

Kolejną grupę, też dwóch kompetencji, nazwałbym:

Learning and analyzing, czyli uczenie i analizowanie. Lub inaczej metryki i analiza.

Analizowanie produktu to jest rzecz absolutnie fundamentalna dla product managera. Chyba że pomagają mu na przykład analitycy biznesowi, którzy są zazwyczaj jeszcze bardziej wyspecjalizowani w różnego typu metrykach.

Produkt można analizować pod kątem sprzedaży i pod kątem marketingu, ale przede wszystkim (być może powinienem na początku o tym wspomnieć) pod kątem funkcjonalności. Czyli między innymi tego:

Czy produkt, nad którym pracujemy, rozwiązuje pewne problemy rynkowe? Czy produkt realizuje KPI, jakie sobie założyliśmy?

Lub czy produkt i rozwój tego produktu wypełni nam i podbije pewne metryki, które wspólnie w organizacji zgodziliśmy się monitorować. Może to być, chociażby metryka dotycząca tego, aby nasi użytkownicy spędzali w aplikacji więcej czasu niż dotychczas.

Mamy na przykład aplikację zakupową i nasi użytkownicy spędzają w niej średnio 1 minutę 40 sekund. Product manager może zbudować taki KPI, który w ciągu pół roku pozwoli wprowadzić funkcjonalności, dzięki którym użytkownicy z 1 minuty 40 sekund, będą spędzali w aplikacji średnio 2 minuty 15 sekund.

To jest temat rzeka. Ja temat metryk na pewno będę rozwijał w przyszłych podcastach. Także śledźcie mnie, subskrybujcie, followujcie.

A jeszcze do metryki analizy dodałbym, że na pewno studiowanie różnych raportów analitycznych i sprzedażowych, śledzenie trendów rynkowych, bycie permanentnie up-to-date są kluczowe dla product managera. 

Aktualizowanie swojej wiedzy na temat tego, jakie są zmiany na rynku i czego możemy spodziewać się za X miesięcy, tudzież lat, a w ramach tego przyglądanie się zmianom na rynku. Oczywiście product manager jest pierwszym, który obserwuje ruchy konkurencji.

Kolejne dwie kompetencje (jedną z nich lubię bardziej, drugą lubię mniej):

Deciding and documenting — gdybym z angielskiego miał tak zalecieć — decyzja i dokumentacja.

Robienie dokumentacji, zdawać by się mogło, jest troszkę nudnym zajęciem. Aczkolwiek ostatnio sprawia mi dość dużo funu, bo dokumentuje różne ciekawe rzeczy, budowane na nowych frameworkach, ale nie będę Was zanudzał.

Natomiast decyzyjność, to jest taka kompetencja, do której należy dorosnąć, należy dojrzeć i do której należy wypracować sobie odpowiedni charakter.

Ja przez wiele… chciałem powiedzieć wiele lat, ale to by zabrzmiało, jakbym miał 70 kilka lat i był w branży od ponad 40. No to powiem przez wiele miesięcy.

Przez wiele miesięcy negowałem stanowisko juniorskie, w przypadku product managera. W sensie próbowałem sobie wyobrazić, kim tak naprawdę byłby junior product menedżer. W niektórych organizacjach takie stanowiska bywają.

Ja uważam — juniorzy nie obraźcie się, jako że dopiero część z was zdobywa to doświadczenie — że raczej nie wpuściłbym w pole decyzyjności człowieka na poziomie juniorskim. Ponieważ product manager, tak się przyjęło, taka jest specyfika tej roli, podejmuje bardzo często kluczowe decyzje.

Poza tym, że musi tę decyzję podjąć, to musi też udokumentować pewne wnioski, podjęte razem z zespołem. Opisać pewne problemy, które wyciąga ze spotkań, o których wspominałem wcześniej.

Musi także te problemy i wnioski zaadresować do odpowiednich osób, tak, żeby wciąż podtrzymywać, zwiększać i zdynamizować rozwój produktu. Musi być pewny, że produkt naprawdę się rozwija i nadąża za zmianami rynkowymi.

Definiowanie hipotez, które są dystrybuowane do interesariuszy. Jeśli nie wiecie, kim są interesariusze, to dokładniej wyjaśnię to w przyszłości. Natomiast teraz dodam, że są to osoby zaangażowane w budowanie produktu, że tak powiem, na bardzo wysokim poziomie.

Tyle, jeżeli chodzi o kompetencje product managera.

Ja tutaj trochę spłycam, ale nie dlatego, że tak trzeba tylko dlatego, że dzisiejszym tematem jest opowiedzieć o kilku różnicach, a nie rozkładać aż tak bardzo na czynniki pierwsze każdą z tych ról.

Jakie są obszary pracy product managera?

Rozmawialiśmy o kompetencjach, pogadajmy o tym, w jakich obszarach on wykorzystuje te kompetencje? I pierwszym takim obszarem, który mi przychodzi na myśl, jest research. 

Analizowanie, definiowanie konkurencji i poszukiwanie problemów rynkowych. Sprawdzanie, jakich produktów rynek potrzebuje? Z jakimi produktami możemy być zawsze o krok przed naszą potencjalną konkurencją?

Business Model Canvas — do tego również będę wracał w przyszłości. Natomiast na dziś powiem, że product manager jest najwłaściwszą osobą w organizacji, która powinna zbudować model biznesowy dla produktu.

Kilka istotnych czynników dotyczących modelu biznesowego:

Jakie problemy rozwiąże produkt? Jaka będzie grupa odbiorców? Jaki jest nasz target? — powiedzieliby marketingowcy, tudzież sprzedażowcy. Jaki jest lub jakie są lejki sprzedażowe, czyli jak będziemy monetyzować dany produkt? Jak on będzie zarabiał na nas i na organizację lub na naszych użytkowników? Przede wszystkim, jakie są potencjalne sposoby rozwiązania określonych problemów rynkowych? Jakie są koszty, które musimy ponieść, rozwijając, ale także utrzymując dany produkt oraz w jaki sposób te koszty można na przykład redukować? Jaka jest wartość danego produktu? Unikalna? Niespotykana w innych produktach dostępnych na rynku? Business Model Canvas należy do rodziny podstawowych narzędzi pracy product managera.

Trzecim istotnym obszarem jest analiza produktowa.

To o czym wspominałem, czyli definiowanie, analizowanie różnych metryk produktowych. Podam może jeszcze jeden przykład z życia.

2 lata temu pracowałem nad aplikacją, z której korzystało kilkuset tysięcy aktywnych i unikalnych użytkowników miesięcznie. Pojawił się jednak problem, ponieważ użytkownicy po jakimś czasie porzucali aplikację i już do niej nie wracali. Zbudowałem wtedy zestaw cech, aby mierzyć, a przynajmniej próbować mierzyć, dlaczego mamy taką retencję użytkowników?

Na podstawie obserwacji tych metryk i na podstawie wyników obserwacji mogliśmy budować funkcjonalności, które sprawiły, że użytkownicy nie porzucali naszej aplikacji. I to była moja rola jako product managera, żeby taką analizę produktową zrobić. I to jest stały element pracy product managera, więc jeżeli pretendujecie do tego miana, nastawcie się.

Roadmapa. W moim osobistym rankingu najprzyjemniejsza forma dokumentowania planów i strategii rozwoju produktu. Roadmapa to rodzaj drogowskazu, który pokaże wszystkim w całej organizacji, w którą stronę chcemy rozwijać produkt.

O roadmapach mogę mówić naprawdę długimi godzinami. Już mam wstępnie przygotowany skrypt do podcastu, gdzie rozłożę wam ten temat na czynniki pierwsze i opowiem o rodzajach roadmap. Więc stay tuned.

Natomiast na dziś pamiętajcie, że roadmapa to również narzędzie stricte product managerskie.

Potrzeby klientów.

Obszar wydawałoby się związany głównie z obsługą klienta, z supportem albo może marketingiem i sprzedażą. Natomiast product manager również musi być blisko klientów, czyli tych końcowych użytkowników.

Czy klienci są biznesowi, czy są to klienci-konsumenci nie biznesowi, to nie ma większego znaczenia. Chodzi tutaj o grupę osób, o target, który koniec końców ma korzystać z Twojego produktu i Ty musisz wiedzieć, jakie potrzeby ma Twój użytkownik.

Niezależnie od tego, czy to jest klient biznesowy, czy konsument, musisz znać odbiorców swojej produkt menedżerskiej twórczości.

Wizja.

To jest chyba coś, co kojarzy się CEO, z prezesami wielkich firm. Steve Jobs, Elon Musk, Jeff Bezos, ci goście na pewno mają wizję. Wyobraźcie sobie jednak, że są tysiące innych prezesów, którzy mają na przykład po kilka biznesów i nie każdy CEO ma wizję. Nie każdy zarząd ma wizję.

Oczekuje się od product managera bardzo często budowania tej wizji. Komunikowania jej do zespołu i ściągnięcia jej z barków prezesa. Oczekuje się często od product managerów, że to oni stworzą wizje.

To product manager ma wiedzieć, co się dzieje na rynku. To on ma te 8 godzin dziennie, za które zapłaci mu organizacja sprawdzać, czego potrzebuje rynek i czego oczekują ludzie? Znaleźć na to argumenty, analizy, raporty i wrócić do zarządu i powiedzieć:

Słuchajcie! Wizja produktu jest taka i taka, uderzamy na taki i taki rynek, w takim i takim czasie, ponieważ tam i tam mamy największy procent szans, że nam się po prostu uda.

Więc jeśli czujecie w sobie taką smykałkę, czujecie, że macie potencjał do generowania i tworzenia wizji, że złapaliście kiedyś bakcyla wymyślania różnych ciekawych produktów i tego, jak byście zawojowali rynek za pomocą tych produktów, to ta rola być może jest naprawdę idealna dla Was.

Tyle o product managerze teraz porozmawiajmy chwilę o product ownerze, tak żebyśmy na końcu mogli sobie podsumować, jakie są różnice między tymi rolami.

Jeśli spróbowalibyśmy opisać główną kompetencję product ownera, to podobnie jak w przypadku product managera, znajdziemy ich bardzo wiele. Mnie, po nieco dłuższym researchu, najbardziej przemawia do serca następująca definicja:

Product owner maksymalizuje wartość produktu w rezultacie prac z zespołem deweloperskim.

Zauważcie, że nie ma tutaj mowy o grupie osób, jest to bardziej doprecyzowane. To jest rezultat prac product ownera z zespołem deweloperskim.

Zagłębmy się trochę w szczegóły.

Kompetencje product ownera to między innymi zarządzanie backlogiem.

Tu pojawi się trochę terminologii stricte branżowej. Jeżeli czegoś nie rozumiecie, nie przerażajcie się. Zachęcam, aby zajrzeć na mój blog, bycjakmanager.pl. Tam część tej terminologii jest już wyjaśnionej, więc nie zrażajcie się. Wszystko krok po kroku.

Zarządzanie backlogiem — główna kompetencja product ownera.

Backlog, czyli pewien koszyk wirtualny naszych zadań deweloperskich, tudzież opisanych funkcjonalności, jakie powinniśmy dostarczyć lub wykonać.

My to wszystko mamy spisane i przekazujemy dalej. Product owner opisuje te funkcjonalności i przenosi je do tak zwanego backlogu. Następnie układa (zaraz będę mówił zresztą o priorytetach) wszystkie opisane funkcjonalności i potrzeby użytkowników, które musimy rozwiązać. On to wrzuca do backlogu i pilnuje. Jest takim strażnikiem backlogu, w którym to odbywa się bardzo wiele ciekawych rzeczy, ale o tym zaraz.

Drugi taki skill, który musi posiadać product owner, to umiejętność ewaluowania postępu prac.

Za słowem ewaluacja kryje się oczywiście szacowanie, tudzież, mówiąc inaczej wycenianie zakresu prac deweloperów. Product owner więc prowadzi odpowiednie spotkania i zespół deweloperski, tak, żeby był on w stanie omówić określone funkcjonalności, które biznes chciałby wdrożyć do produktu, do aplikacji.

I zespół deweloperski przy pomocy product ownera jest w stanie wycenić, ile czasu, ile wysiłku potrzeba na to, żeby wykonać te funkcjonalności i je zaimplementować. Więc rola product ownera jest tutaj kluczowa, jeśli chodzi o dostarczanie pewnych wycen czasowych do przedstawicieli biznesu.

Bycie mostem komunikacyjnym jest kompetencją, która pokrywa się z kompetencją product managera, ponieważ product owner również tłumaczy pewne wymagania biznesowe i techniczne. A tłumaczy je komu? Otóż wymagania biznesowe, czyli czego chce biznes, musi wytłumaczyć deweloperom. Przychodzi do deweloperów i mówi:

Słuchajcie! Mamy w aplikacji czerwony przycisk.

To jest bardzo głupi, wręcz płytki przykład, więc zapomnijcie o nim zaraz po tym, jak go powiem, ale muszę tutaj jakiś przykład, taki łopatologiczny wyciągnąć na wierzch.

A więc przychodzi product owner do zespołu deweloperskiego i mówi:

Mamy w aplikacji przycisk, button, który jest różowy i okrągły, ale nasz biznes chciałby, żeby ten przycisk był sześciokątem i był purpurowy.

No i teraz pierwsze pytanie od deweloperów, prawdopodobnie programistów byłoby: ale po co my mamy robić z trójkąta czy tam kółka sześcian? I dlaczego mamy zmienić kolor?

Teraz product owner musi wyjaśnić deweloperom, że przykładowo, z badań tudzież analiz zespołu marketingowego i product managera dowiedzieliśmy się, że ludzie, aby częściej klikali w dany przycisk, to przycisk ten musi mieć inny kształt i inny kolor. Dlatego my go chcemy zmienić w aplikacji, żeby podbić konwersję, czyli liczbę kliknięć w ten konkretny przycisk.

I teraz product owner musi wiedzieć, co kryje się za daną potrzebą biznesową, jakie są argumenty, żeby móc wytłumaczyć temu ciału technicznemu, dlaczego coś robimy. Aby programiści mieli poczucie, że nie robią czegoś bez sensu.

To jest jeden z przykładów tego, jak można być wprawnie mostem komunikacyjnym. Tych przykładów jest znacznie więcej, ale nie o nich dzisiaj.

Priorytetyzacja potrzeb.

To jest taka kompetencja pożądana, więc product owner musi sobie siąść przed takim backlogiem, który stworzył i spriorytetyzować funkcjonalności. Od najważniejszej (tej najbardziej krytycznej) do tych najmniej istotnych, które mogą jeszcze trochę poczekać, albo zostać zaimplementowane w tak zwanym międzyczasie.

Podobnie z błędami. Bardzo często, jeżeli w aplikacji, w produkcie lub w serwisie coś się wysypie to pytanie, na które musi odpowiedzieć product owner, jest tak ważne, jak krytyczny jest dany błąd w systemie. Tak, żeby programiści wiedzieli, za co się zabrać w pierwszej kolejności.

Obszarem stricte product ownerskim jest nadzorowanie prac zespołu deweloperskiego, zespołu programistów. Ja nie lubię słowa nadzorowanie, bo mi się to kojarzy z kimś, kto chodzi z bacikiem nad ludźmi. Chociaż trochę ta rola też musi przybierać taki kształt czy tego chcemy, czy nie, czy to lubimy, czy nie.

Natomiast to product owner musi przypilnować czy roadmapa, na przykład stworzona przez product managera, jest implementowana we właściwy sposób. Czyli czy tam nie ma żadnych rozjazdów pomiędzy tym, co ustaliliśmy z biznesem, a tym, co mamy realnie w aplikacji.

Czy tam nie są po drodze implementowane jakieś funkcjonalności, na które w ogóle nikt nie czeka, które zgłosił ktoś tam z supportu tak naprawdę, a ich w ogóle nie było na roadmapie.

Więc product owner musi trzymać pieczę nad tym wszystkim i doglądać roadmapy, na zmianę z doglądaniem zespołu deweloperskiego i samego produktu. Sprawdzać i monitorować, czy to, co my robimy, pokrywa się z planami biznesu.

Przewidywanie to jest słowo, które warto zapamiętać, jeżeli chcielibyście spróbować zostać product ownerem. Wierzę, że tak, skoro dotarliście do tego momentu. Przewidywanie to jest coś, co nie każdy product owner w sobie wypracował, a mnie się wydaje, że to jest bardzo ważna cecha.

Product owner musi wyłapywać zagrożenia na wczesnym etapie ich rozwoju, jeżeli zagrożenia mogą się rozwijać. No mogą się rozwijać w pewien sposób. Chodzi więc o to, że jeśli potencjalnie wdrażamy jakąś funkcjonalność, to tam może być fakap. Powiem teraz bardzo brzydko, ale tak, żebyście zapamiętali.

Product owner musi być pierwszą osobą, która oflaguje tą lub inną funkcjonalność, która potencjalnie może nam coś wypierdolić w systemie. I to jest bardzo istotna część pracy product ownera. Im bardziej doświadczony product owner, tym lepiej będzie prognozował to, czy coś nam się wysypie, czy nie.

Oczywiście on nie robi tego sam. To nie jest człowiek, który siedzi w kodzie. On musi analizować i słuchać bardzo uważnie członków zespołu deweloperskiego, którzy najczęściej sygnalizują mu takie rzeczy już dużo wcześniej. Aczkolwiek warto tutaj mieć zawsze zapaloną czerwoną lampkę nad głową, czy przypadkiem nic nam się nie wysypie po drodze.

Przejdźmy do obszarów.

Ja sobie zanotowałem cztery obszary product ownera, w których on wykorzystuje wcześniej wymienione kompetencje. Jest coś takiego jak Program Increment, inni to nazywają PI Planning. Product owner jest odpowiedzialny za przygotowanie i prowadzenie planningu.

Planning to regularne, cykliczne spotkania z zespołem deweloperskim, gdzie ustalamy, jakie są finalne wymagania.

W sensie przeglądamy wymagania biznesowe. Sprawdzamy, jakie funkcjonalności mamy na liście, które chcielibyśmy zaimplementować i planujemy kolejne dwa lub trzy tygodnie. W zależności od tego, jakie mamy iteracje, planujemy kolejne tygodnie naszej pracy, pracy deweloperów, pracy programistów.

To product owner jest właśnie tą osobą, która jest odpowiedzialna i zaangażowana w organizację i prowadzenie takich planningów. To jest człowiek, który planuje już na niższym poziomie z deweloperami pracę.

Realizacja programu. Jeżeli zaplanujemy coś i się dogadamy na coś, no to product owner, fajnie jakby dbał o to, żeby dostarczenie tego finalnego produktu, tej wartości zostało w jakiś sposób zaprezentowane w formie demo, w formie prezentacji dla interesariuszy.

Jako że drugi raz już pojawia się słowo interesariusz, to dopowiem więcej. Są to najczęściej przedstawiciele strony biznesowej lub przedstawiciele innych działów w firmie, którzy korzystają z tego lub innego produktu, jakie rozwijamy. Są to osoby, które najczęściej reprezentują grupę innych ludzi, którzy czekają na daną funkcjonalność.

Tak więc jest tak, że mamy sprint dwu, trzy czy jednotygodniowy. Zamykamy ten sprint (o sprintach też będę więcej opowiadał lub możecie przeczytać na moim blogu), dowieźliśmy pewną funkcjonalność i warto by było, aby ktoś tę funkcjonalność pokazał wszystkim przedstawicielom strony biznesowej. A dokładnie jak to tak naprawdę działa i jak my to zrobiliśmy technicznie?

I po to jest project owner. Bardzo często prowadzi dema dla klientów, wyjaśniając:

„Słuchajcie! Wiemy, że była taka potrzeba. My tę potrzebę chcemy zaspokoić i zrobiliśmy taką i taką funkcjonalność. Ona działa tak i tak. Powiedzcie czy to rozwiązuje wasze dotychczasowe problemy”.

Od tego jest właśnie product owner, żeby przeprowadzić takie demo.

Inspekcja i adaptacja.

Tak nazwałem obszar, który także mieści się w kompetencjach product ownera, ponieważ to product owner prowadzi różnego rodzaju warsztaty inspekcji i adaptacji ze stroną biznesową. Oczywiście, żeby zwiększać jakość danego produktu i komunikować na przykład krytyczne zależności.

Załóżmy, że mamy dużą platformę, nad którą czuwa jakiś tam product menadżer, ale są też inni product ownerzy. Jest to rozbudowany system do zarządzania, na przykład czesnymi studentów, tudzież danymi różnych osób. Product owner powinien potrafić łączyć kropki w taki sposób, aby przewidzieć, że jak programiści wdrożą w jednym miejscu w systemie jakąś funkcjonalność, to może się coś wywalić w innym miejscu w systemie. To jest trochę takie prognozowanie rzeczy, które mogą się wywalić.

Za słowami inspekcja i adaptacja kryje się tutaj pewien cykl warsztatów, które też warto po stronie product ownera organizować dla strony biznesowej, żeby spotykać się i rozmawiać o produkcie. Zastanowić się, co jeszcze możemy zrobić technicznie i biznesowo, żeby zwiększać wartość tego, co robimy.

Realizacja i iteracja to są obszary, wydaje mi się najbardziej eksponowane w różnych opisach tego stanowiska.

O tym już mówiłem.

Chodzi tu o zarządzanie backlogiem i zespołem programistów. O planowaniu iteracji, czyli w jakich cyklach będziemy wydawać kolejne udoskonalenia oprogramowania. Elaborowanie scenariuszy, jeżeli są scenariusze (o scenariuszach też na innej lekcji, na innym wykładzie), wspieranie przy podejmowaniu różnych decyzji technicznych. To wszystko zawiera się w realizacji i iteracyjności, nad którą pieczę sprawuje właśnie product owner.

Przejdźmy do podsumowania.

Teraz gdy opowiedzieliśmy sobie więcej o product managerze i product ownerze, myślę, że trochę światła rzuciłem na różnice, jakie są pomiędzy tymi dwiema rolami. Nie ma nic złego w tym, że występują bardzo często pod jedną postacią. Możemy też często spotkać się z ogłoszeniami o pracę zatytułowanymi Product Manager/Product Owner i widać, że jest to funkcja łączona.

Product manager ma ogólny focus. Jego skupienie jest wysoce strategiczne. Ta, jakby wielka i efektowna wizja produktu, powinna wychodzić właśnie od product managera. Wizja, która jest zakrojona na działania długoterminowe.

Natomiast product owner, jego skupienie skoncentrowane jest bardziej na planowaniu średnioterminowym. Na tym, jak wizję idącą od product managera rozbić na trochę mniejsze klocki, żeby udźwignąć ją technicznie.

Jeśli chodzi o obszary odpowiedzialności, to product manager ma wizję produktową, ma customer discovery, czyli odkrywanie potrzeb klienta. Ma między zespołową współpracę i komunikację. Product manager również ma priorytetyzację funkcjonalności. Natomiast najczęściej chodzi o duże funkcjonalności, a nie te rozdrobnione już na poziomie backlogu.

Jakie obszary ma product owner w takim razie?

W tym wypadku jest to na przykład optymalizacja procesu wytwarzania oprogramowania, developmentu. Co zrobić? Jakie narzędzia wprowadzić? Jak poskładać proces deweloperski, tak żeby programiści mogli zwiększać tę wartość produktu. Co należy zrobić, żeby praca programistów była, jak najbardziej zoptymalizowana, żebyśmy nie przypalali godzin niepotrzebnie.

Product owner przekształca wizję product managera w backlog. Ktoś te zadania musi spisać, ktoś to musi udokumentować, ktoś musi tym jakoś zarządzać. Product owner jest najczęściej adwokatem potrzeb klienta i stoi na czele zespołu deweloperskiego.

Jeżeli product manager przyjdzie i pewne funkcjonalności wydadzą się głupie najzwyczajniej, no to product owner będzie tym, który powie:

„Słuchaj Panie product managerze, ale my znamy potrzeby naszych klientów i my jesteśmy zgodni z zespołem deweloperskim, że ta funkcjonalność jest po prostu idiotyczna”. Bardzo upraszczam, tak się raczej nie rozmawia na profesjonalnym poziomie, ale chcę, żebyście złapali kontekst.

Product menedżer jest właścicielem roadmapy produktu i MVP (Minimum Viable Product).

Natomiast product owner jest właścicielem backlogu i właścicielem User Stories (o których też będziemy wkrótce mówić, aczkolwiek zakładam, że część z was już wie, o czym mówię).

Najważniejsze metryki dla product managera.

I to jest ostatnia rzecz, którą chciałbym podkreślić. Najważniejszymi metrykami jest Net Promoter Score, czyli słynny NPS. Wskaźnik, który mówi o tym, jak lojalny jest użytkownik wobec danego produktu, aplikacji, oprogramowania.

Konwersja to też jest metryka stricte produktowa. Zapamiętajcie, że product manager sprawdza konwersję i jest to metryka, która go mocno interesuje. 

Kolejną istotną metryką jest przychód. Jest to metryka biznesowa, już mniej produktowa, czyli ile po prostu zarabiamy.Product manager robi produkty, które mają zarabiać. To jest biznes. 

Podobnie jak metryka Churn, czyli tak zwana retencja. Jak dużo tracimy użytkowników, tudzież klientów? To też nas bardzo interesuje. Jest to tak zwany odpływ użytkowników.

Natomiast dla product ownera metryką jest to, ile User Stories — w dużym takim uproszczeniu — ile zadań zrobili deweloperzy. W tym również pozostałe metryki związane z wydajnością zespołu deweloperskiego. Czyli ile Story Pointów przepalił zespół, ale o story pointach też, jeśli chcecie wiedzieć więcej, to odsyłam do bycjakmanager.pl. Znajdziecie tam przygotowany przeze mnie artykuł, o tym, czy powinno się wyceniać pracę deweloperów w czasie, w jednostkach czasu czy Story Pointach.

Ja jestem fanem Story Pointów, wyjaśniam to na blogu. Polecam!

Jeśli zadajecie sobie pytanie na wczesnym etapie swojej kariery, kim warto być, product managerem czy product ownerem, to jedyną, ale bardzo subiektywną radą, którą mógłbym wam dać. Chociaż drugą moją radą jest to, żeby nie słuchać rad, więc nazwę to rekomendacją.

Moją rekomendacją jest to, aby iść od dołu, od tej najbardziej roboczej, najbardziej fundamentalnej płaszczyzny. Czyli najpierw być na przykład analitykiem, a później product ownerem, a później product managerem, tak żebyście mogli zobaczyć cały ten proces, doświadczyć cały ten proces deweloperski od początku do samego końca. Wydaje mi się, że to nie są role, które stoją na tym samym etapie, czy tam poziomie rozwojowym.

Bardzo często spotykam się z tym, że product ownerzy, jako dalszą część swojej kariery podejmują pracę jako product managerowie. Tego bym się trzymał. Spróbujcie być product ownerami, ponieważ jeśli z tym pójdzie wam ciężko, to chyba nie ma opcji, żeby być dobrym product managerem.

OK! Rozgadałem się, a nie chcę tutaj formą przerastać treści.

Wielkie dzięki, że dotarłeś lub dotarłaś razem ze mną do tego momentu.

Zachęcam, żeby mnie śledzić, czy na Youtubie, czy na Spotify, czy zapisać się na newsletter na bycjakmanager.pl

Ja nigdy nie spamuje. Zawsze wysyłam informacje tylko i wyłącznie o nowych artykułach, a także różne pro-tipy, porady, które można wykorzystać w praktyce.

Już teraz zapraszam Cię na kolejny podcast. Staram się publikować podcasty w tygodniowych iteracjach, co weekend. Trzymaj kciuki, żebym konsekwentnie utrzymał tę tendencję.

Wszystkiego dobrego. Dbaj o siebie i innych!

Do usłyszenia