Product manager versus wszyscy (PO vs PM vs PdM vs BA)
Miałem ostatnio przyjemność przechodzenia przez kilka procesów rekrutacji. Postanowiłem zaaplikować na różne stanowiska, zarówno na pełnienie roli product ownera (PO), project managera (PM), product managera (PdM) lub nawet analityka biznesowego (BA). Postanowiłem podzielić się swoimi praktycznymi doświadczeniami i spostrzeżeniami, jak ww. role są ze sobą powiązane, a w niektórych przypadkach mogą oznaczać to samo. Z drugiej strony, każda osoba oraz firma rozumie i definiuje te stanowiska inaczej. Tworzy to komunikacyjny chaos, a problem zaczyna się już w momencie, gdy musisz podjąć decyzję, czy zaaplikować, czy też nie. W wielu przypadkach pojawiają się pytania: o co w ogóle chodzi? Jaka jest rola? Co będę robił/a?
Przy wielu ofertach, nie wiadomo :). Zazwyczaj klaruje się to podczas pierwszej bezpośredniej rozmowy (nieoceniony jest porządny screening), dzięki czemu można sprawnie zweryfikować potrzeby i oczekiwania obu stron. Jednak nie dzieje się tak, gdy rekrutujący/a się i przedstawiciel/ka firmy używają tych samych słów (PO, PdM, PM, BA) dla określenia różnego rodzaju wymaganych kompetencji i stawianych zadań.
Postaram się to uporządkować. Od razu zaznaczę: to moje przemyślenia i nie aspiruję do wyznaczania uniwersalnych branżowych prawd.
Kilka lat temu miałem dokładnie ten sam problem i po pewnym czasie postanowiłem tak to podzielić:
- PM rozmawia z klientem
- PdM pracuje z zespołem
- BA komunikuje się z odbiorcami/rynkiem (np. robi analizę rynku, konsumentów)
Sprawdzało się to całkiem nieźle. Opowiedziałem to kilku osobom, które stwierdziły, że ma to sens. Ale to było wtedy. Teraz, naturalnie, rzeczy poszły do przodu i zrobiło się bardziej skomplikowanie — gdzie umieścić tego product ownera? I scrum mastera? A gdzie pracuje business developer? A project implementation manager? Jeszcze jest process manager! Ufff, dużo tego.
Próbując to poukładać, wyszedłem z nową hipotezą, która brzmiała mniej więcej tak:
- PdM widzi większe tło (ang. bigger background)
- PM budżetuje (dysponuje zasobami)
- PO estymuje
BA został z boku. Ma to sens? Może trochę ma, ale koncepcja raczej do wyrzucenia. Postanowiłem podejść do tego trochę inaczej, czyli od wyznaczenia granic i zależności pomiędzy projektem oraz produktem. Kolejne podejście brzmiało tak:
Każdy produkt jest projektem, ale nie każdy projekt jest produktem. Każdy projekt jest procesem.
Czym jest produkt? Artefaktem projektu.
Projekt ma większe tło — wewnętrzne, produkt — zewnętrzne (np. potrzeby rynkowe).
To również w zderzeniu z rzeczywistością, czyli wieloma spotkaniami z firmami i pracującymi PM/PdM/PO, dosyć szybko się posypało. Ważna uwaga: żadna osoba pełniąca rolę PM/PdM/PO nie podjęła się wyzwania jednoznacznego zdefiniowania ww. funkcji. Za to opowiadała, jak to u nich działa, więc z tego miejsca dziękuję za te niezliczone minuty wyjaśniania wewnętrznych struktur wszystkim rozmówcom i rozmówczyniom.
Dlaczego podejście w podziale na project/product/process management nie jest właściwe? Po pierwsze, to zbytne teoretyzowanie — jest to ważne, ale na późniejszym etapie (jest to także ciekawe samo w sobie). Po drugie, projekty i produkty są zarówno wewnętrzne i zewnętrzne, wszystko się przeplata, i nie jest łatwo rozdzielić ww. sfery. Jedynie stwierdzenie, że produkt jest artefaktem (rezultatem) projektu broni się— zwłaszcza jeśli próbujesz połączyć metodyki typu waterfall (bo to rozumieją i tak pracują twoi klienci) oraz agile (bo tak się lepiej robi wewnętrznie). To jednak temat na inną dyskusję.
Chciałbym jeszcze wiele napisać o zmieniających się rolach, zadaniach, wymaganiach i wyzwaniach, ale stwierdzam, że byłoby to zbyt… nudne, bo każdy/a liczy na konkret.
Po prostu przejdźmy do krótkich definicji. Na razie trzymam się ich i wytrzymują starcie z rzeczywistością. Kolejność zadań przy każdej roli nie jest przypadkowa.
Product manager — dwa podejścia (niezależnie od wielkości firmy):
- First product manager (One woman/man army) — moje top3, czyli wizja, workflow, delivery. I wszystko inne.
- Standardowy product manager: zbieranie wymagań od rynku/klientów/użytkowników, priorytetyzacja, współpraca z różnymi zespołami i poziomami np. design, data science, sprzedaż, marketing, C-management (CEO, CTO itd.), praca z własnym zespołem dev. Funkcje BA zostały tutaj wchłonięte.
Project manager— dwa podejścia:
- Korporacyjne — nadzór, komunikacja, budżetowanie;
- Startupowe, małe firmy IT, software house’y—komunikacja z klientem, tworzenie wymagań, scrumowanie jako praca z zespołem dev, zarządzanie zasobami, ~coaching. Ogólnie, zbliżona funkcja do PdM, ale mniej pracy wysokopoziomowej.
Product owner— estymacja zadań i budżetowanie, praca z zespołem dev (najczęściej razem ze scrum masterem), komunikacja (klient, C-management). W wielu miejscach może oznaczać to samo co startupowy PM.
Naturalnie, powiesz: Ale u mnie to zupełnie inaczej wygląda!. Prawdopodobnie masz rację. Starałem się wyciągnąć średnią, jeśli w ogóle coś takiego jest możliwe w tym przypadku. Plus, nie były to żadne zaplanowane badania — wyszedł z tego eksperyment naturalny, więc próba badanych czy struktura wywiadów mogła być nieadekwatna.
Na swoje potrzeby wypracowałem także obraz product managera, o którym opowiadam, jeśli zostanę zapytany. To funkcja, w której łączą się inne role, w tym BA czy PM. Potrafi pracować wysokopoziomowo z C-mng, innymi działami, rozmawiać z klientami czy użytkownikami, ale też siąść do roboty i ubrudzić się (ang. get your hands dirty). Nie musi być developerem, choć to pewna ścieżka, by z funkcji deva stać się PdM — inną jest BA -> PdM. Musi za to jednak ściśle współpracować z zespołem developerskim. W takim przypadku rola zbliża się do stanowiska PO.
Na koniec, w jednym z wywiadów Mind the product product manager został porównany do hedge fund managera (to rodzaj ryzykownego funduszu inwestycyjnego). Hedge your bets! Jako PdM nieustannie podejmujesz pewne założenia, które potem realizujesz i weryfikujesz. Jest to wg mnie jest z najlepszych kwintesencji wyzwania PdM, która równocześnie staje się granicą od BA, PO oraz PM.
