Product Manager

Product Manager vs. Project Manager?

Kilka lat pracowałem jako project manager. Od 2-3 lat pracuję także jako product manager. Jakie są różnice kompetencyjne tych stanowisk i jakie widzę plusy i minusy dla obu, w kontekście codziennej pracy?

Product manager „po projektach”

Po doświadczeniach z programowaniem serwisów internetowych przeskoczyłem na stanowisko – project manager IT. To taki gość, który tak zarządza zespołem programistycznym, aby wyprodukować dane oprogramowanie, tak żeby zmieścić się w zaplanowanych: zakresie, budżecie i czasie (więcej o trójkącie projektowym tutaj). Przynajmniej według metodologii (PMI).
Kiedy miałem już za sobą X projektów, pojawiła się oferta bycia CEO startupu. W sensie PM-owania, projektem było m.in. założenie samej spółki i organizacji wszystkiego co z nią związane. Kiedy jednak przeszliśmy do projektowania e-produktów, pojawiła się w moim CV nowa rola – „produktowca” 🙂
W zasadzie każdy CEO startupu to po troszę product manager. Chodzi o to aby zaprojektować taki produkt, które pomoże spełniać główne cele biznesowe firmy. Najczęściej chodzi o przychody ze sprzedaży.
Project vs Product Manager

Różnice w stanowiskach

W kilku wierszach przedstawiłem cechy obu stanowisk, według moich doświadczeń (dla obszaru IT).

Project Manager Product Manager
Cel Dostarczenie produktów projektu (np. działający system IT) mających na celu wspieranie celi biznesowych, za które to cele biznesowe project manager nie jest bezpośrednio odpowiedzialny. Bezpośrednie wspieranie celi biznesowych firmy poprzez kreowanie i wdrażanie produktów, na które istnieje zapotrzebowanie na rynku.
Obowiązki Zarządzanie: zespołem, zakresem, harmonogramem, budżetem, umowami (np. podwykonawców), ryzykami, jakością i integracją tych wszystkich obszarów. Projektowanie produktu i zarządzanie jego rozwojem. Mieści się w tym m.in. badanie rynków, prototypowanie, analiza statystyk produktu.
Codzienność Najczęściej usuwanie przeszkód w ciągłej pracy programistów, w kontekście realizacji zgłoszonych wymagań dla budowanego oprogramowania. Dla produktów internetowych – ciągła analiza zachowań grupy docelowej przy używaniu e-produktu (np. analiza statystyk). Takie dane determinują kierunek rozwoju produktu.
Bolączki Brak decyzyjności operacyjnej ze strony szefów oraz ciągłe szlifowanie komunikacji zespołu (różni ludzie). Rynek elektroniczny jako wielka niewiadoma w kontekście budowania produktów (poruszanie się w świecie hipotez).
Korzyści Najlepsza szkoła do nauki zarządzania komunikacją w zespole! Poza tym dobry PM potrafi pociągnąć każdy projekt, także własną firmę! Moja motywacja płynęła głównie z tworzenia rozwiązań, które pomagają innym ludziom. Potem zarabianie.
Czytaj również:  Project Manager Zarobki. Ile biorą udawacze i wymiatacze?

Wady i zalety bycia…

Oba stanowiska mają wspólną zaletę. Jako project czy product manager nigdy nie będziesz się nudzić! Każdy dzień to jedna wielka niewiadoma, np. jakiś problem realizacyjny (project), czy zaskakujące statystyki (product). Nie ukrywam jednak, że ta zaleta czasami mi już wychodzi bokiem i mam chęć popracować miesiąc „na taśmie” lub przy łopacie, żeby się zresetować.
Jeśli lubisz organizować pracę innych, ale nie masz mentalności sprzedawcy, to stanowisko kierownika projektu może być dla Ciebie. Jeśli natomiast lubisz pracę analityczną, lubisz wymyślać nowe rozwiązania, masz parcie na sprzedaż (ale nie jako akwizytor), to być może będziesz „produktowcem”.
Inna sprawa, że oba te stanowiska coraz częściej zlewają się w jedno. Głównie w małych zespołach, gdzie nie ma etatów na X managerów, albo w sytuacji kiedy PM, musi jednocześnie sprzedawać, np. projekt  w sensie zlecenia klienta w agencji interaktywnej.
Ja na razie śmigam jako project i product manager, ale już mózg mi paruje (co odbija się na jakości pracy) i niebawem chyba przyjdzie pora na zatrudnienie PM-a a ja skupie się na produkcie.
A czy wg Was warto łączyć te role?

28 thoughts on “Product Manager vs. Project Manager?

  1. Upraszczając, ale dla laików zawsze przedstawiam to w ten sposób:
    Product Manager odpowiada na pytanie: CO ma być zrobione w projekcie?
    Jest odpowiedzialny za cele projektu i jego zakres. Nie miesza się w to, w jaki sposób Project Manager te cele osiągnie. Im mniej czasu będzie poświęcał na zarządzanie projektem, tym więcej mu go zostanie na zarządzanie produktem.
    Project Manager odpowiada na pytanie:JAK projekt ma być zrobiony?
    Czyli odpowiada za całe zarządzanie projektem, ale nie kwestionuje na każdym kroku postawionych przed nim celów i zakresu. Im mniej czasu będzie poświęcał na zarządzanie produktem, tym więcej mu go zostanie na zarządzanie projektem.
    kiedyś nawet popełnił podobny artykuł: http://tomaszewski.it/2012/01/product-manager-vs-project-manager/

  2. A no tak nie do końca 🙂 Moim zdaniem bardzo mocno spłycone tu zostały cechy obydwu stanowisk i skupione mocno na zakresie który realizuje autor. Jestem wieloletnim kierownikiem projektów, jak i produktów, itd. w zależności od potrzeb zakładam odpowiednią czapeczkę 🙂 Rola PMa to nie tylko nadzór nad programistami bo jest ZNACZNIE WIĘKSZA i bardziej zróżnicowana (odsyłam do pmbok i zakresu działań objętego procesami ;)).
    Osobiście zaś z mojego doświadczenia wynika tyle, że jaki by PM nie był potrzebuje koniecznie kogoś jednak odpowiedzialnego za ten produkt (często tak zwanego lidera biznesowego) i tu moim zdaniem idealnie wygląda sytuacja kiedy jednak te role się łączą. Fakt pracy dużo, ale od czego mamy zespół projektowy…
    Nie do końca zgadzam się też z codzienną walką, fakt problemy są zawsze (ja osobiście mam już nawet swoje powiedzenie "jeśli nie masz żadnych problemów w projekcie to bardzo niedobrze bo znaczy to tylko tyle, że ciągle ich jeszcze nie zauważyłeś ;)") Moim zdaniem lepiej planować (prace, zdarzenia, ryzyka, itd.) – naprawdę wiele rzeczy da się uniknąć przez dobre planowanie.
    Komunikacja – tak, jest mega istotna w projektach (szczególnie dużych) – to jest chleb powszedni dobrego PMa.
    Decyzyjność też nie jest taka zła, oczywiście pewnie wygląda bardzo różnie w zależności od specyfiki warunków projektowych, jednak dobrze określona karta projektu (komunikacja itd.), oraz postawiony governance projektu potrafią nam bardzo ułatwić życie.
    Konkludując:
    wątek fajny, ale mocno spłycony, a z doświadczenia moim skromnym zdaniem aby realizować inicjatywy efektywnie rynkowo to albo funkcje muszą ze sobą bardzo dobrze współpracować, albo być zintegrowane w postaci jednej osoby. Wiem metodyki mówią inaczej, ale patrząc z perspektywy czasu na inicjatywy w których brałem udział czy też byłem ich blisko to właśnie to jest chyba najlepsze rozwiązanie.

  3. Postaram się krótko i na temat. PM zarządza cyklem życia projektu (procesem wytwórczym) i odpowiada za realizację celów projektu. PRM zarządza cyklem życia produktu (aż do jego wycofania) i odpowiada za realizację celów dotyczących produktu.

  4. Bingo! czysty scrum nie wyróżnia, ale wiele firm dostosowuje proces scrum i organizację stanowisk. ale sam Scrum ESPN mi się podoba, że wychodzi poza ustalone ramy i inaczej podchodzi do produkcji softu.

  5. blog ma swoje prawa i musi byc pigułka bo bym encyklopedię napisał. Celowo rozdzieliłem oba stanowiska aby było bardziej jasne dla laików. Poza tym nie lubię za dużo słów.
    Zaś co do PM-a w IT, również pracowałem w wielu środowiskach. Wiem, że jest masa obszarów za które PM (pomijając produkt w perspektywie biznesowej) odpowiada. Ale gdybym miał wybrać, który najważniejszy to moim zdaniem – Zarządzanie Komunikacją. Projekt to ludzie, którzy muszą dobrze współpracować poprzez dobrą komunikację aby wytworzyć co trzeba (także dobra komunikacja z klientem, gdzie medium komunikacji może być specyfikacja – zakres).
    A czy PM potrzebuje produktowca? Jeśli są etaty to moim zdaniem lepiej jak PM skupia się na produkcji a za produkt w ujęciu biznesowym odpowiada kto inny. A jak mały zespół to często PM ma dwie czapki (pisałem o tym). A że muszą współpracować to jasne. Ja piszę o tym aby mieć świadomość rozdziału procesu produkcyjnego od biznesowego, które oczywiście też się często pokrywają.
    Co do tego, że plan załatwi wszystko. No tu się zupełnie nie zgadzam (idea Lean Startup). widziałem juz takich co w planach pokładali wszystkie nadzieje. dlatego z pomocą przychodzi np. Agile/Scrum, gdzie planujemy krocząco (nie tylko produkcję ale i biznes), ale nawet krótki plan szczegółowy raz na 2 tygodnie nie zwolni PM-a z usuwania przeszkód w codziennej produkcji (+ koordynacja innych aspektów). Ja takich cudów nie widziałem 🙂
    Generalnie może mogłem wyjść od definicji projektu, bo głównie miałem na myśli że projekt dla PM-a w aspekcie produkcyjnym (wg PMI). O PM-ach jako produktowcach też pisałem.

  6. Najwięcej szans na powodzenie zawodowe mają osoby urodzone od 11 stycznia. Przybędzie Wam obowiązków i trzeba będzie się uczyć w pośpiechu nowych
    umiejętności, ale będzie warto, bowiem czeka Was podniesienie statutu zawodowego. Gorzej się powiedzie osobom urodzonym w grudniu. Coś może się zawalić,
    na nawet jest niebezpieczeństwo utraty pracy. Osoby prowadzące własną działalność będą narzekały na swoje dochody.

  7. Pamiętam, że gdy nk zaczynała nie było ani Project Manadżerów ani Product Manadżerów i (IMHO) było super, dopóki też programiści byli super (najlepsi ludzie z UWr). Im więcej programistów, im większa ich "różnorodność" tym bardziej ktoś na górze chyba czuł strach, że robi się bałagan i że trzeba koniecznie zacząć to układać w drzewko. Z perspektywy lat, sądzę, że lepiej by było użyć po prostu scruma i promować architektów na scrummasterów, no ale to też tylko hipoteza i już się nie dowiemy. Anyway: najpierw AFAIR byli tylko Project Mandżerowie i to tacy na całą firmę (bardziej jak CTO). Miało to swoje zalety i wady (głównie odzwierciedlające wady i zalety samych postaci). Potem pojawili się "Produktowcy". Powiem szczerze: źle to znosiłem, głównie dlatego, że były to sytuacje gdzie z powodu małej ich ilości pełnilini niekiedy role Project i Product Mandadżera jednocześnie. To jakby połączyć Prokuratora i Adwokata w jedną osobę z powodu kosztów. Są osoby i projekty przy których połączenie tych dwóch ról nie jest straszne — głównie startupy gdzie dana osoba jest bezpośrednio (udziałami) odpowiedzialna za to co robi i bezpośrednio (bo np. wymyśliła startup) wie dokąd on ma zmierzać. Są jednak ludzie i projekty (i tak było w nk) gdzie osoba nie bardzo wiedziała gdzie to wszystko zmierza i nie bardzo się przejmowała racjonalnością swoich decyzji. IMHO po części był to efekt strategii HR firmy — zatrudniano wielu młodych ludzi dając im szansę (sam na tym skorzystałem). Ale często rodziło to frustrację, gdy nad utalentowanymi programistami stawiano kogoś kto ledwo ogarniał i co gorsza miał w ręce oba baty: ustalał zakres, a jednocześnie egzekwował/wierzył w jego wykonanie — brakowało tej zdrowej dyskusji między "ja chcę" a "ależ tego się nie da". O ile to możliwe, jestem za rozdzieleniem tych dwóch ról w firmach gdzie odpowiedzialność (za porażki) jest rozmyta i ludzie realizują "nieswoje" wizje. Pamiętam, że całkiem nieźle zaczęło się to wszystko kręcić gdy rozdzielono role Project Manadżera i Product Manadżera. Potem zmieniono (drastycznie) strukturę jeszcze raz. Szczerze to obecna sytuacja (każdy zespół zarządza swoją pracą sam, a zespoły podlegają pod jedną osobę mającą jedną spójną wizję tego co robimy, ale szczegóły pozostawia zespołom) też jest super, pod warunkiem, że w każdym zespole jest chociaż jedna osoba której się chce, wie co chce robić i ma posłuch. Jeśli w danym zespole panuje marazm i brak kogoś kto wie po co i jak, to taka "płaska" struktura jest o kant dupy rozbić — marudzący ciągną w dół resztę teamu.

  8. nie wiem kto i kiedy wymyślił, zeby używać skrótu "PM" skoro istnieją dwa zupełnie różne stanowiska pasujące do niego. Nie wiem co myślała osoba wprowadzająca skrót "PRM" ale to też musiało być zabawne. Tak czy owak, z Twojego opisu tych dwóch stanowisk, udaje mi się rozszyfrować, że "PM" to (dla Ciebie) to Project Mandażer, zaś "PRM" to (dla Ciebie) Product Manadżer? zgadłem:)

  9. Ach, no i nie omieszkam z okazji by wspomnieć o http://www.avc.com/a_vc/2012/02/the-management-team-guest-post-from-joel-spolsky.html jak dla mnie zespół inteligentnych programistów nie potrzebuje rozkazywania im, tylko usługiwania im (co więcej informatycy z natury rysują drzewka do góry nogami, co być może pomaga zrozumieć, czemu tak łatwo im przyjąć, że project manadżer powinien być ich sekretarką a nie przełożonym) 🙂

  10. zamiast sekretarki wolę podejście partnerskie i dodatkowo PM ma jakiś background techniczny. Jednak tak jak m.in. piszesz w poprzednim komencie dużo zależy od rodzaju firmy (środowiska) w którym się pracuje. Czasem PM przeszkadza, czasem bez niego wszystko się rozlatuje.

  11. Maciek Ol chyba tak można powiedzieć, z tym że zakres kompetencji powinien być szeroki, właściwie jak najszerszy, myślę że wiele osób ma kompetencje i predyspozycje do roli growth hackera ale bardzo mało osób (ja znam może z 2) wykorzystuje swoją interdyscyplinarną wiedzę świadomie, zatrudniając się na coraz to nowych stanowiskach mając jednak na uwadze produkt i usługi, pogłębiamy w ten sposób swoją wiedzę i doświadczenie nie dając się złapać w pułapkę "etatu za wszelką cenę, byle dobić do pierwszego" co nie zapewnia stałego poziomu rozwoju 🙂

  12. Maciek Ol W sieci można znaleźć, że "Growth Hacker" to miks marketera i kodera, którego działania wyglądają tak:
    "1. Build tools that drive visits, leads and customers. 2. Dive into our data and find interesting trends and statistics. 3. Automate boring stuff so my coworkers have more time to focus on being awesome marketers."
    Design Manager myślę, oprócz tych 3 ma dodatkowych z 30 a gdy zajdzie potrzeba dobierze się kolejne narzędzia. Grunt to mieć świadomość celu do którego się zmierza i wykorzystać wszystko co tylko się da aby go zrealizować. Celem jest zawsze wzrost dochodów firmy oraz zadowolenie klientów, a branża jak dla mnie może być dowolna, nie ma to znaczenia raczej jest to kwestia preferencji. Ja akurat wykorzystuję wiedzę gównie z obszarów kreowania wizerunku, reklamy, marketingu, PR, IT i zarządzania projektami, dążę do wypracowywania rozwiązań innowacyjnych w duchu HCD itp. Słów i skrótów opisujących aktualne trendy jest cały worek ale nie o to chodzi 🙂
    Ostatnio natomiast widzę ogromną lukę w polskich firmach jeżeli chodzi o kadrę i modele zarządzania, wiele firm ma korzenie z początku lat 90 i są skostniałe od prezesa w dół, uważam że to właśnie hamuje rozwój gospodarczy w tym kraju i konkurencyjność firm i nawet najlepsze prowadzenie projektów czy worek kasy nie wygenerują nic nowego, zmiana i akceptacja działań musi iść od samej góry, a z tym w Polsce jest najgorzej.

  13. "utalentowany lider dostrzega jeden lub dwa najistotniejsze elementy całej sytuacji – punkty krytyczne, które są wstanie zwielokrotnić efekt podjętych działań a następnie koncentruje na nich wszystkie wysiłki i dostępne zasoby" – ot co, potrzebujemy LIDERÓW.

  14. Maciek Ol Tym razem zgadzam się z wieloma rzeczami 🙂 wcześniej bardzo mocno było oczami Kierownika Projektu IT (a to bardzo, ale to bardzo zawęża spojrzenie;)) z Lean Startup i piwotowaniem też się zgadzam, jednak wygląda to różnie w zależności od inicjatywy – dobieramy odpowiednią metodę do sytuacji.
    Chciałem aby rozszerzyć temat i patrzeć kontekstwo bo PM to nie tylko software development…

  15. Maciek Ol A i jeszcze jedno 🙂 cytując "PM nie zawsze ma wpływ na governance w firmie (nie tylko w projekcie). Masa uczestników projektu nie czyta karty. Dokumentami nie załatwisz wszystkiego."
    Na governance w projekcie powinien mieć wpływ zawsze, jeśli nie to jak ma ten projekt realizować? Co do dokumentów i karty – nie chodzi mi o czytanie papierów, ale wykonanie i zakomunikowanie pewnej pracy, a mianowicie właśnie ułożenia projektu w organizacji (karty projektu nie robi się przecież po to żeby dać do czytania), potwierdzenie planu komunikacji, szczebla decyzyjności zarządzania zmianą jak i ryzykiem, itd. – ustawienie tego na początku i zatwierdzenie w organizacji później skraca ścieżki i daje PMowi swobodę w wypracowanych ramach.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *