Z tego podcastu dowiesz się:
- Kto to CEO i jakie są jego obowiązki
- Kto podejmuje najważniejsze decyzje w firmie
- Do kogo raportuje PM w mniejszych i większych organizacjach
- Z kim współpracuje rada nadzorcza
- Jakie pytania możesz usłyszeć od swojego prezesa
- Kto to CTO i dlaczego to ważne stanowisko
- Kto to CPO i jakie posiada kompetencje
- Czy product owner współpracuje na co dzień z CEO, CTO lub CPO
- Kto odpowiada za infrastrukturę w firmie
- Jak może Tobie pomóc architekt lub lider techniczny
- W jakich obszarach porusza się Head of Product
- Czy CPO to także mentor PMów
- Kiedy Head of Product tworzy roadmapę produktu
- Dlaczego relacja pomiędzy CPO a product managerem jak ważna
- Kto kogo powinien inspirować i motywować do pracy
Podcastu wysłuchasz także na:
Transkrypcja
„Być jak manager”. Podcast. Epizod 8. Dzień dobry.
Nie wiem dlaczego utarło się takie przekonanie, że branża IT to tylko i wyłącznie programiści. Oczywiście, broń Boże, nie neguję tego. Branża IT to zawsze była i będzie co najmniej w 80% zapełniona programistami, natomiast są pewne inne role, a bogactwo branży IT jest tak wielkie, że tych ról jest naprawdę sporo poza tymi rolami technicznymi. Ja pomyślałem, że stworzę dla ciebie, drogi słuchaczu, cykl kto jest kto – stanowiska kierownicze w branży IT. Rozbiję to na kilka krótkich epizodów i w każdym z epizodów opowiem ci o trzech rolach kierowniczych, z jakimi spotkasz się, spotkałeś się albo już spotykasz się w branży IT. Dziś na tapetę wezmę takie 3, wydaje mi się, kluczowe postaci w branży informatycznej, jeśli mówimy o wyższym menagemencie: CEO, czyli Chief Executive Officer, CTO, czyli Chief Technology Officer i CPO, czyli Chief Product Officer, zażywany czasem także Head of Product. Zanim zaczniemy, serdecznie dziękuję, że włączyłeś ten podcast. A jeżeli śledzisz mnie już od dłuższego czasu, to tym bardziej kłaniam się jeszcze niżej. Dziękuję też za każdy komentarz, każdą wiadomość po wysłuchaniu tego podcastu, która pomogłaby mi potencjalnie nagrywać coraz lepsze podcasty w niedalekiej przyszłości. Jestem też superwdzięczny za każdą inną konstruktywną krytykę, ponieważ ja tych podcastów nie robię dla siebie, robię dla ciebie, żeby móc przy całej swojej skromności podzielić się swoją wiedzą i doświadczeniem na temat zarządzania w branży informatycznej. Zapraszam na mój blog bycjakmenager.pl, zapraszam na social media, na YouTube, Facebook, Instagram. Lecimy z tym.
CEO – Chief Executive Officer – w Polsce powiedzielibyśmy „prezes”, a nawet „ pan prezes”. Inaczej mówiąc, to jest po prostu w dosłownym tłumaczeniu prezes zarządu. I to jest taka osoba, której nie można nie spotkać w branży IT, bo prezesi zarządu występują we wszystkich spółkach na całym globie, a przynajmniej nie znam takiego przypadku, gdzie spółka nie miałaby swojego prezesa, oczywiście z formalnego, takiego legitnego punktu widzenia, można powołać spółkę bez prezesa, spółkę bezosobową, ale takie przypadki raczej nie występują w dobrze prosperujących, a nawet w średnio funkcjonujących firmach.
Często taki prezes zarządu to także współwłaściciel firmy, najczęściej założył albo współzałożył firmę, której został prezesem. Natomiast jeżeli chodzi o duże firmy, zwłaszcza korporacje, no to tam już jest dużo mniej tych przypadków, gdzie CEO jest jednocześnie właścicielem albo współwłaścicielem firmy. Często jest to osoba, którą powołano, żeby piastowała takie stanowisko. Są to najczęściej menagerowie z wieloletnim doświadczeniem, którzy zostali powołani do tego, żeby prowadzić firmę w przód, żeby ją rozwijać, rozbudowywać, skalować. I mają ku temu set odpowiednich kompetencji, aby właśnie to robić. CEO podejmuje bez wątpienia najważniejsze decyzje strategiczne w firmie. Oczywiście nie robi tego sam. Może to prawdopodobnie zrobić sam autorytarnie, ale najczęściej takie decyzje podejmuje ze wspólnikami, czyli z resztą zarządów i spowiada się przed Radą Nadzorczą. Chief Executive Officer zarządza na bardzo wysokim poziomie operacyjnym lub też na tak zwanym poziomie korporacyjnym w zależności od tego, jakie są struktury organizacji, jaka jest wielkość tej organizacji. Tak jak wspomniałem, odpowiada bardzo często za skalowanie biznesu, ale także za skalowanie zasobów w firmie. On oczywiście nie robi tego sam, on deleguje zadania poszczególnym szefom albo dyrektorom obszarów w firmie. CEO bardzo często, jeżeli nie jest jedynym właściwym właścicielem firmy, to jest wybierany na to stanowisko przez tak zwanych interesariuszy. A poza tym, że musi mieć takie umiejętności twarde w zarządzaniu, to jest także twarzą firmy. To on, jako prezes zarządu, tworzy wizję i misję firmy. To on, jako głowa tego biznesu, analizuje wszystkie najważniejsze raporty, które dotyczą kondycji finansowej organizacji. Czyta także prognozy rynkowe, obiera kierunek rozwoju całej organizacji i wskazuje ten kierunek pozostałym zespołom. Jest kapitanem tego statku nazywanego firmą. Prezes zarządu decyduje też o inwestycjach, jakie podejmie organizacja, ale też o przejęciach innych firm. Bierze udział w przetargach, w bardzo twardych konsultacjach biznesowych z potencjalnymi kontrahentami i oczywiście ważny punkt, o którym nie powinniśmy zapominać – CEO współpracuje nie tylko z pozostałymi członkami zarządu, ale także ściśle współpracuje z tak zwaną Radą Nadzorczą. Nie czas i nie miejsce, żebyśmy teraz rozbijali na czynniki pierwsze, czym tak naprawdę zajmuje się Rada Nadzorcza i jakie są jej kompetencje, zakres nie tyle obowiązków, co pewnego doradztwa. Być może wrócę do Rady Nadzorczej w przyszłych podcastach, jeśli sobie tego życzysz. Jak coś, odsyłam do komentarzy, jeśli ten wątek cię ciekawi. Myślę, że moglibyśmy go rozwinąć.
Jaka jest relacja takiego CEO do Product Menagera? Ja pomyślałem, że opowiem o tej relacji przy każdym z tych stanowisk, ponieważ – jak już wiesz – jest to blog dla Product i Project Menagerów. Blog i podcast. Dlatego ta relacja mnie też zawsze najsilniej interesowała, dlatego że od lat spełniam się i realizuję jako szczęśliwy Product Menager, a wcześniej jeszcze Project Menager. Więc relacja CEO do Product Menagera, w zależności od tego, o jakiej skali mówimy. W mniejszych organizacjach PM często raportuje bezpośrednio do CEO, a Prezes Zarządu jest także jego bezpośrednim przełożonym. Natomiast, jeśli spojrzelibyśmy na większe organizacje, nawet korporacje, gdzie najczęściej Product Menager najczęściej raportuje do Heada produktu lub do dyrektora jednostki biznesowej, do Business Unit Director, tak się chyba mówi, pod którą podlega Product Menage, to wtedy dla CEO taki PM może, ale nie musi, pełnić rolę konsultanta. Pozwól, że wyjaśnię. W dużych organizacjach ta hierarchia, ta drabinka kompetencji i stanowisk jest troszkę wyższa niż w mniejszych organizacjach. I w dużych organizacjach za pewne obszary odpowiadają dyrektorzy albo właśnie headowie produktów, CPO może być w takiej dużej organizacji, i wtedy Product Menager nie raportuje bezpośrednio do Prezesa Zarządu, ponieważ takich Product Menagerów jest kilku albo kilkunastu. Tak że im większa organizacja, tym relacja na linii Product Menager – CEO będzie coraz słabsza, coraz mniejsza będzie ta relacyjność między tymi stanowiskami. Natomiast często Product Menager, nawet w dużej organizacji, może pełnić dla CEO orlę takiego konsultanta. Zwłaszcza w czasie różnych spotkań biznesowych, gdzie zaproszeni są także pozostali PM-owie, żeby wspólnie z Prezesem Zarządu, żeby pomóc Prezesowi Zarządu, wypracować jeszcze lepszą strategię produktową dla firmy. Takie konsultacje odbywają się w dużych organizacjach co jakiś czas. Nawet, gdy Product Menager nie raportuje bezpośrednio do CEO, to na pewno ich drogi w pewnym momencie pracy nad strategią produktową przecinają się na najważniejszych spotkaniach operacyjnych, jeśli te spotkania dotyczą oczywiście obszarów, w którym ten konkretny Product Menager działa.
Ta relacja CEO – PM wydaje się bardziej silna im mniejsza jest ta organizacja. To jest to, o czym wspomniałem poniekąd przed chwilą, że im większa organizacja, tym relacja słabsza, natomiast im mniejsza organizacja, to tym ta relacja będzie bardziej silna. Jest jeszcze jedna rzecz, o której warto pamiętać, to że najczęściej to CEO ustala albo po prostu akceptuje budżet na projekt lub produkt, któremu przyjdzie tobie, jako Porject Menagerowi albo Product Menagerowi, kierować. Jeżeli ty nie zajmujesz się budżetowaniem, jeżeli w firmie nie występuje Head, to właśnie wtedy bardzo często Prezes Zarzadu jest tym człowiekiem, który trzyma rękę na budżetowym pulsie. I to oznacza, że jeśli chcesz powalczyć o większy budżet na swój obszar w firmie, na swój produkt, to istnieje duża szansa w mniejszej firmie, że swoje argumenty będziesz konfrontował właśnie z opinią Prezesa Zarządu. Spodziewaj się także, że od CEO możesz usłyszeć jako Product Menager, następujące pytania: W jakim kierunku rozwijamy produkt, którym ty jako PM się opiekujesz? Czy mamy roadmapę produktową?
PM najczęściej tworzy roadmapę i wizję produktu lub konkretnego obszaru, tak że Prezes Zarządu na pewno będzie o to wypytywał, jeśli pomiędzy wami nie ma jakiegoś Heada. Jakie są przed nami, czyli organizacją, kamienie milowe do zrealizowania? Z takim pytaniem możesz się spotkać od Prezesa Zarządu. Podobnie jak z tym, jak wygląda motywacja zespołu i jakie są nastroje wśród pracowników. Oczywiście Product Menager nie zarządza ludźmi ani kapitałem ludzkim, zarządza produktem, natomiast Prezes Zarządu czasem, jako jednostka organizacyjna ustawiona wyżej w firmie, może z czystej ciekawości i wydaje mi się, że nawet powinien zapytać ciebie, jako menagera danego obszaru, jakie są motywacje w zespole, w zespole, który pracuje nad tym lub nad innym produktem. Kolejne pytanie, jakiego mógłbyś się spodziewać, to to, jakie prognozujemy wzrosty w najbliższym kwartale, półroczu lub roku. O jakich wzrostach mowa? Mowa na przykład o wzroście ruchu na stronie, którą się opiekujesz, o wzroście liczby użytkowników, klientów, w zależności od tego, nad jakim produktem pracujesz, jeśli produkt ma się rozwijać i ty masz w tym firmie pomóc, no to siłą rzeczy prezes od czasu do czas, a nawet częściej niż myślisz, odpyta o to: „no, to jak tam, panie Krzysztofie, Marku czy Januszu, z naszym produktem? Rosną nam te metryczki czy nie rosną?”. I ostatnie pytanie, które przychodzi mi na myśl to: Jak się kształtuje nasza konkurencja na rynku? Czy pojawił się na przykład nowy gracz i na czym skupiają się na przykład obecni konkurenci na rynku. I jako Product Menager na pewno będziesz monitorował konkurencję. Oczywiście, nie musisz tego robić sam, prawdopodobnie możesz oddelegować to zadanie innym osobom w firmie, natomiast musisz wiedzieć, jaka jest konkurencja na rynku, jak ona się rozwija, jakimi narzędziami się posługuje. Prezes Zarządu nie musi tego filtrować sam i monitorować samemu. Może oczekiwać od Product Menagera, że on robi tę robotę.
A teraz dwa słowa o tym, jaka jest relacja do Product Ownera, chociaż dużo różnic bym się tutaj nie spodziewał. Ta relacja byłaby identyczna jak w przypadku PM-a do CEO, jeśli PM jako taki nie występuje w organizacji, ponieważ część firm stawia na Product Ownerów, którzy łączą w sobie także kompetencje PM-a, więc jeżeli to jest taki Product Owner / Product Menager, no to ta relacja będzie identyczna. Natomiast jeżeli w strukturze firmy Product Owner raportuje do PM-a, do Product Menagera, to wtedy Product Menager dla Product Ownera staje się takim decyzyjnym CEO. W tym przypadku Product Owner raczej nie jest stroną w dyskusji z CEO, ale nie wyklucza to sytuacji, gdy Produkt Owner może być zapraszany, podobnie jak Product Menager, w roli pewnego konsultanta danego obszaru na spotkania, które dotyczą na przykład rozwoju i strategii firmy. Tyle, jeśli chodzi o CEO. Jeśli miałbyś jeszcze jakieś dodatkowe pytania, nie wahaj się zapytać o tym w komentarzu, na blogu lub na moich mediach społecznościowych.
Przejdźmy płynnie do CTO, Chief Technology Officer. Inaczej mówiąc – szef techniczny albo dyrektor techniczny. To jest bez wątpienia najwyższe stanowisko w firmie, za którym stoją najważniejsze decyzje, ale nie biznesowe, tylko techniczne. I te decyzje techniczne są najczęściej kluczowe dla organizacji, w której taki CTO występuje, bo są to chociażby wybór i zbudowanie odpowiedniej infrastruktury dla oprogramowania, które chcemy zbudować. Jest to też wybór kluczowych dostawców, którzy mają nam dostarczyć rozwiązania technologiczne. CTO bardzo często robi research, który gracz na rynku może nam dostarczyć taką lub inną usługę, z której prędzej czy później i tak będziemy musieli korzystać. I Chief Technology Officer analizuje potencjalnych dostawców, oczywiście pod kątem technicznym, ale także finansowym, czyli ile będzie nas kosztować korzystanie z tych lub innych usług danych dostawców. CTO skaluje zespół techniczny. To na jego barkach jest odpowiedzialność za to, aby zespół techniczny, czyli zespoły deweloperskie, rosły. Jeżeli firma inwestuje w wzrost zespołów technologicznych, w rozrost, można tak powiedzieć, no to CTO, można się spodziewać, dużo czasu spędzi na rekrutacjach. Oczywiście, im większa firma, tym CTO może więcej takich rekrutacyjnych wątków oddelegować do poszczególnych Team Leaderów technicznych, których posiada organizacja. Natomiast im mniejsza organizacja, tym więcej różnych kompetencji, z których musi korzystać CTO, będzie eksploatowanych w czasie dnia pracy. W zależności od tego, o jakiej skali mówimy, CTO może również odpowiadać za różne obszary, na przykład planowanie strategiczne, ale pod kątem technicznym, czyli jak w kontekście technicznym organizacja będzie się rozwijać w przyszłości. Także dbanie o relacje klienckie i współpracę z kluczowymi kontrahentami firmy. Na przykład w firmie, gdzie produkuje się hardware, przykładowo dyski twarde, no to taki CTO może być też człowiekiem, który dba o relacje z dostawcami różnych – nie wiem – komponentów, które są potrzebne do wyprodukowania tych dysków twardych, żeby dbać i pozyskiwać nowe relacje wśród dystrybutorów hardwaru.
Jaka jest relacja do Product Menagera? Otóż CTO dla każdego PM-a na pewno jest znakomitym źródłem wiedzy technicznej, której może ten produktowiec potrzebować i zapewne będzie potrzebował. Natomiast pamiętajmy, że tu znów podobny case, jeśli organizacja jest większa niż mniejsza, no to zanim to tego CTO pójdziemy i zapytamy o to, jak powinien wyglądać backend naszego oprogramowania, no to po drodze są jeszcze Team Leaderowie techniczni, z którymi śmiało możemy konsultować takie tematy. Są także programiści, z którymi możemy zrobić jakiś refainment lub burzę mózgów, tak że im większa organizacja, tym ten CTO będzie od nas bardziej oddalony, bo będzie zarządzał na nieco wyższym poziomie niż w mniejszych organizacjach. CTO może doradzać technicznie, nawet powinien doradzać technicznie, powinien podsuwać pomysły na optymalne rozwiązania systemowe. W czasie planowania średnio- i długoterminowego, także planowania takiego produktowego. Na pewno pomoże wycenić koszty zbudowania i utrzymania infrastruktury. Każdy produkt, każde oprogramowanie wymaga infrastruktury, a infrastruktura to są zawsze koszty. Jako produktowiec raczej nie będziesz nawet próbował zrobić podejścia do tego, żeby wyceniać koszty infrastruktury. Do tego trzeba być osobą techniczną i po prostu się na tym znać. Ale CTO z pewnością ci pomoże w wycenieniu takiej infrastruktury oraz czasu potrzebnego na wdrożenie takiej infrastruktury. W średnich i dużych organizacjach takim doradcą i partnerem technicznym PM-a może już nie być CTO, ale tak jak wcześniej wspomniałem, pewien lider techniczny albo nawet – byłoby super, gdyby taka rola istniała u ciebie w zespole – doświadczony architekt. Architekci to najczęściej byli deweloperzy, którzy zjedli zęby na budowaniu infrastruktur i śmiało mogą doradzać w tej kwestii.
Czego możesz się spodziewać od CTO, kiedy przyjdzie zadać ci pytanie natury biznesowej? Jakie pytania może zadać takiemu PM-owi CTO? Otóż te pytania mogą być rzeczywiście stricte biznesowe, przykładowo: Na jakie platformy – desktop, mobile czy web – chcemy rozwijać tą albo inną aplikację oraz dlaczego na te platformy? Ty, jako produktowiec, powinieneś z głowy i z miejsca odpowiedzieć na takie pytanie. Jaki jest dokładny zakres prac, czyli funkcjonalności, które chcemy dowieść. Tak zwany scope. Na przykład na najbliższe pół roku. I to się łączy z pytaniem, które również może usłyszeć, czyli które funkcjonalności znajdą się na roadmapie produktowej. Jako PM roadmapa jest jednym z twoich podstawowych narzędzi. Tak więc CTO śmiało może o to odpytać. Odpowiedzi na te pytania mogą być mu potrzebne po to, żeby właśnie rozplanować właściwą infrastrukturę i ją wycenić. CTO może cię także zapytać o to, które z tych funkcjonalności na roadmapie uznajemy za kluczowe, bez których na pewno się nie obejdziemy i które z tej roadmapy nie zostaną ściągnięte. Może także zapytać o to, czy planujemy integrację z zewnętrznymi narzędziami albo serwisami. Czy nasze oprogramowanie, nasz produkt, aplikacja, powinna się komunikować jeszcze z jakimiś usługami na rynku. CTO może także zapytać, kto jest naszym odbiorcą, użytkownikiem, klientem. Ja w przeszłości wielokrotnie odpowiadałem na pytanie CTO o to, kim jest nasz target i kim są nasi użytkownicy. Nigdy nie wnikałem po co ta wiedza CTO. Być może to, do kogo kierujemy nasz produkt lub usługę ma bezpośrednie powiązanie z technikaliami, którymi opiekuje się CTO. Natomiast spodziewaj się takich pytań. Być może chociażby z tego powodu, żeby CTO nabrał więcej kontekstu do tego, co tak naprawdę rozwijamy i dlaczego. CTO może także zapytać, jakie mamy Key PE, jakie mamy OKR-y lub po prostu cele biznesowe na kolejny kwartał lub półrocze. O Key PE i OKR-ach na pewno będę rozmawiał w przyszłych podcastach, więc tym bardziej zachęcam do zapisania się na mój newsletter, ponieważ tobie, drogi słuchaczu, ta wiedza na pewno przyda się w każdym projekcie, rzekłby. Key PE, OKR-y – bardzo ważny wątek. Nie mam czasu rozwinąć go dziś, ale wrócę w niedalekiej przyszłości, obiecuję. Tyle o CTO.
Przejdźmy teraz do mojej ulubionej roli, ulubionego stanowiska w wyższym menagemencie w branży IT. A dlaczego ulubione? Ponieważ jest bezpośrednio związane z zarządzaniem produktem i to jest także to stanowisko, które ja obecnie piastuję, kiedy nie nagrywam podcastu. A mowa o CPO – Chief Product Officer, który wymiennie figuruje także pod nazwą Head of Product. I to jest – mój drogi słuchaczu – najwyższe stanowisko w firmie, które jest związane z aktywnościami wokół produktu albo wielu produktów w firmie, bo może to być jeden główny produkt, a może to być całe portfolio produktowe, którym taki Head of Product, Chief Product Officer zarządza. To, co warto wiedzieć już na wstępie to to, że CPO zarządza produktem na wysokim poziomie. Rzadko, bardzo rzadko, jeżeli w ogóle, schodzi na poziom rozmów roboczych. Od tego są już PM-owie lub Product Ownerzy, lub analitycy biznesowi chociażby. Head of Product porusza się w kluczowych dla swojej roli obszarach. I to są takie obszary jak: wizja produktu, design produktu, development, zarządzanie produktem, marketing produktu, ale czasem na przykład w firmach hardwarowych, dystrybucja, manufaktura czy nawet zaopatrzenie. Oczywiście nie zajmuje się tym wszystkim sam, to nie jest multiinstrumentalista i człowiek, który gra jednocześnie na wielu frontach jako solista. Oczywiście gra na wielu frontach, ale ma do dyspozycji większość zespołów w firmie, które pomagają mu realizować wizję produktową. I kto mu pomaga? No, pomaga mu na pewno zespół IT w pierwszej kolejności. Pomaga mu marketing, pomaga mu dział sprzedaży, dział obsługi klienta, a także dział, na przykład, dystrybucji. I tutaj, podobnie jak przy poprzednich stanowiskach, warto sobie rozgraniczyć skalę, bo w mniejszych organizacjach CPO tworzy często średnio- i długoterminową roadmapę produktu. Natomiast w większych organizacjach roadmapy tworzą najczęściej Produkt Menagerowie na zlecenie CPO. Czyli on już nie musiałby, znaczy nie dałby rady, tworzyć roadmapy dla na przykład 5 czy 6 różnych serwisów w firmie, ale śmiało może oddelegować to i zlecić produktowcom, którzy są jego podopiecznymi w firmie. W wielu przypadkach takich Head of Product jest też bezpośrednim przełożonym PM-ów. No i z nimi wypracowuje takie roadmapy produktowe.
Tu też chcę wspomnieć, że o ile Product Menagerowie rzadziej zarządzają ludźmi, a jedynie produktami, to jednak na barkach CPO bardzo często jest też skalowanie zespołu oraz odpowiedni dobór tych kompetencji menagerskich w firmie. No bo kto ma tak naprawdę sprawdzić, czy Product Menager jest właściwą osobą na właściwym stanowisku? No, CPO, jako menager z dłuższym, większym, bardziej bogatym doświadczeniem menagerskim, jest w mocy do tego, aby wyfiltrować w czasie procesu rekrutacyjnego, odfiltrować dobrych menagerów od słabszych. Oczywiście później także, w zależności od tego, jak będzie kształtować się struktura firmy, może zlecić rekrutowanie kolejnych PM-ów obecnym PM-om, jeżeli w stu procentach ufa, że oni pozyskają bardzo fajnych, kompetentnych, łebskich gości. Natomiast wydaje mi się, że taka pewna przezorność i rozsądek biznesowy CPO nakazuje, żeby gdzieś na końcowym etapie rekrutacji takiego PM-a w firmie, nawet jeżeli to jest duża organizacja, spotkać się jednak z tym kandydatem, upewnić się, że twój zespół, zespół twoich managerów znalazł fajną, łebską, komunikacyjnie właściwą osobą do tego stanowiska productmenagerskiego. CPO często reprezentuje organizację na zewnątrz i jest twarzą firmy w czasie konferencji lub wystąpień publicznych. Oczywiście nie wszystkich, bo pamiętamy, że Prezes Zarządu, czyli CEO jest twarzą firmy. Natomiast jeżeli jakieś konkretne wydarzenie, event, dotyczy właśnie portfolia produktów tej organizacji, to taki Head of Product śmiało może siąść obok CEO i być uzupełnieniem tak naprawdę wypowiedzi Prezesa Zarządu w kontekście obszaru stricte produktowego. Wiecie, gdzie możecie to zobaczyć bardzo klarownie? Możecie zobaczyć to w czasie konferencji chociażby marki Apple. Słynne konferencje w Dolinie Krzemowej, kiedy firma Apple prezentuje nowe produkty, nowe iPhone’y, nowe MacBooki, nowy set tak naprawdę różnych narzędzi i produktów, które wejdą na rynek, to na tych konferencjach na scenę wychodzą często Head od Product konkretnego obszaru lub produktu, Head of Designe. Ci headzi stają się tak naprawdę reprezentatywną częścią, nie tylko kierowniczą, ale także reprezentatywną częścią firmy, która pracuje nad konkretnym produktem lub serwisem, lub usługą.
Jaka jest relacja – tutaj robi się ciekawie – Head of Product czy Chief Product Officer do Product Menagera? Poniekąd już wspomniałem o kilku wątkach. CPO, jeśli w ogóle występuje w organizacji, jednocześnie z PM-ami, to jest najczęściej bezpośrednim przełożonym PM-a – czy to Project Menagera, czy Product Menagera. I PM – Product Menager – raportuje bezpośrednio właśnie do CPO, do Head of Product. I jak przystało na wyższe stanowisko managerskie takiego CPO, on powinien motywować i w pewien sposób couchować menagerów młodszych stażem. Ja tutaj chcę zaznaczyć, że bardzo ostrożnie posługuję się słowem couching, ponieważ ono może się kojarzyć pejoratywnie – z tandetnym, tanim, podszytym brakiem realnego doświadczenia edukowaniem innych na wzór nadmuchanych pompatyzmem trenerów rozwoju osobistego. Nie o takim couchingu mowa. Chief Product Officer, prawdziwy, rasowy, powinien umieć inspirować, zapalać błysk pasji w oczach młodszych menagerów. Jeżeli na swojej drodze zawodowej spotkasz takiego CPO, takiego Head of Product, który będzie w stanie rozpalić w tobie jeszcze większą pasję do zarządzania produktem, w bardzo fajny, lekki, nienarzucający się sposób couchować cię i inspirować do pracy nad sobą, to uwierz mi, taki CPO będzie jak dar niebios. Współpraca z Head of Products, który potrafi cię naprawdę bardzo dużo fajnych rzeczy nauczyć, pozostaje nieoceniona. Taka współpraca i taka relacja będzie lepsza i lepiej zaprocentuje na twoją managerską przyszłość niż jakikolwiek kurs internetowy, online, o zarządzaniu, jaki kupisz.
Chcę jeszcze zaznaczyć już na koniec, że ta relacja miękka pomiędzy Headem a regularnym produktowcem jest niezwykle ważna dla obu stron. Nie tylko dla Project Managera, bo jeżeli między nimi coś zaiskrzy w sensie produktowym, to jest naprawdę OK. A jeżeli nie zaiskrzy, to ciężko będzie tym dwóm podmiotem wspólnie uspójniać wizję produktową w firmie. Tu musi być bardzo silna korelacja i bardzo fajna relacja. A jak jest relacja do Product Ownera? Tutaj się nie rozwinę jakoś merytorycznie, ponieważ jest niemalże identyczna, chyba że w organizacji występują obie role – Produkt Ownera i Product Managera. To często zachodzi scenariusz, że Product Owner raportuje do PM-a, a nie do Heada. I w takich przypadkach nie ma mocnej relacji pomiędzy Product Ownerem a CPO.
No i tym radosnym productmanagerskim akcentem zbliżyliśmy się do końca dzisiejszego podcastu. Ja już teraz dziękuję ci pięknie za wysłuchanie i w ogóle za kliknięcie w ten podcast, tą audycję i spędzienie tych kilkudziesięciu minut ze mną. Z góry dziękuję też za każdy komentarz i opinię, który pomoże mi usprawniać moje dalszego podcasty, bo tak jak wspominałem na wstępie, nie robię tego dla siebie, robię to dla ciebie, bo wiem, że w ten sposób sprawiamy razem, że ta branża productmanagerska, branża Project Menaderska staje się jeszcze lepsza, jeszcze fajniejsza i wspólnie zwiększamy standardy w branży, w której sami siedzimy. Zachęcam oczywiście do zapisania się na mój newsletter. Ja nie wysyłam żadnego spamu, nie wykorzystuję w żaden inny sposób twoich danych osobowych, czyli maila i imienia. A jednocześnie jest to najlepsze źródło informacji o moich nowych podcastach i dążeniach, w których będę brał udział. Jeżeli któryś wątek szczególnie cię zainteresował w dzisiejszym podcaście, daj mi znać w komentarzu lub na blogu, lub w mediach społecznościowych. Na pewno rozszerzę temat w osobnym podcaście. No i na koniec – klasycznie już, bym powiedział – wszystkiego dobrego, dbaj o siebie i innych. Cześć!
KONIEC