Technical Product Manager – marketingowy wybieg, czy rzeczywista potrzeba?

W artykule postaram się odpowiedzieć na te pytania oraz wskazać najczęstsze błędy, jakie nowo mianowany Technical Product Manager popełnia.

Zarządzanie produktem składa się z trzech głównych filarów:

Strategicznego, który wymaga ścisłej współpracy z działem sprzedaży, oraz wiedzy w tym zakresie.

Marketingowego, co implikuje działanie w zgodzie ze specjalistami od reklamy, promocji, etc. – innego rodzaju doświadczenie jest wymagane do działania w tym obszarze.

Technicznego, oczekującego bliskiego kontaktu z wytwórcami produktu – ważne jest zrozumienie programistycznego punktu widzenia.

Znalezienie osoby, która będzie miała równie głęboką wiedzę i doświadczenie we wszystkich 3 filarach jest bardzo trudne, a w przypadku dużych międzynarodowych organizacji wręcz niemożliwe. Lepiej jest zebrać grupę osób, z której każda charakteryzuje się doświadczeniem w innym obszarze, połączyć je w jeden zespół i stworzyć bardzo wartościowy dla Organizacji Product Management Office. Jak już zapewne się domyślacie Technical Product Manager posiada największą wiedzę o tym, co zostało zakreślone fioletowym okręgiem.

I tutaj pierwsza pułapka. Powtórzmy: Technical Product Manager to osoba posiadająca specjalistyczną wiedzę w zakresie techniczno-technologicznym. Nie oznacza to jednak, że taki Product Manager będzie faktycznie wykonywał techniczne zadania, takie jak tworzenie architektury, czy pisanie kodu. Wręcz przeciwnie. Jego wartość dla firmy stanowią zadania związane z wizją, kreowaniem produktu, a nie umiejętności wytwarzania oprogramowania. To bardzo często popełniany błąd w rozumowaniu zarówno po stronie organizacji, jak i młodych niedoświadczonych Technical Product Managerów, wywodzących się z developmentu. Patrząc jednak z nieco innej perspektywy, zdobyta wcześniej techniczna wiedza daje sporą przewagę podczas:

1. Rozmowy z zespołem deweloperskim – dużo lepsze zrozumienie obu stron dzięki doświadczeniu
2. Zarządzania ryzykiem – wewnętrzna świadomość skomplikowania nowych funkcjonalności pomaga uniknąć niespodzianek w postaci przeciągających się terminów oddania,
3. Prezentowania produktu klientom z dużą wiedzą techniczną takim jak np. administratorzy.
4. Wyznaczania roadmapy produktu – znajomość i zrozumienie trendów, które charakteryzują rynek w danej chwili.

Skoro wiadomo już, jakie zalety i niebezpieczeństwa niesie ze sobą wiedza techniczna, spróbujmy je przekuć na reguły mówiące o tym, co dobry Technical Product Manager powinien robić, a czego powinien się wystrzegać:

Zalecane:

1. Wykorzystywanie swoich umiejętności technicznych do planowania i priorytetyzowania zadań. Wiedza programistyczna pozwala ulepszyć ten proces poprzez zadawanie rzeczowych pytań zespołowi deweloperskiemu i zrozumieniu ich odpowiedzi. To z kolei pozwoli uniknąć opóźnień i wytworzyć produkt maksymalnie funkcjonalny, przy optymalnym wykorzystaniu zasobów.
2. Wykorzystywanie swojego doświadczenia w kontaktach z programistami i architektami tłumacząc techniczny język innym działom, np. sprzedaży. Inne działy zazwyczaj nie rozumieją (a często nawet nie chcą zrozumieć) jak ważna jest współpraca pomiędzy nimi  a wytwórcami oprogramowania. Tutaj Technical Product Manager ma prawdziwe pole do popisu, jako osoba otwarta i komunikatywna, powinna pełnić rolę facylitatora i zdecydowanie poprawić zrozumienie między działami w firmie.
3. Skupianie się na modelu biznesowym i na rozwoju produktu. To najważniejsza zasada dla niedoświadczonych Product Managerów. Pamiętajcie wasza rola w firmie się zmieniła – należy się skupić na strategii rozwoju produktu, a nie na rozwiązywaniu technicznych problemów podczas jego wytwarzania.

Niezalecane:

1. Wykorzystywanie swoich umiejętności do budowania architektury systemu.
   Tworzenie architektury zostawmy architektom lub zespołowi deweloperskiemu. To jedno z ich zadań. Jeśli Cię to nie przekonuje to wiedz, że jakiekolwiek twarde propozycje mogą się później odbić czkawką, gdy zespół zrzuci niepowodzenie na pomysł Product Managera.
2. Wykorzystywanie swojej wiedzy do proponowania rozwiązań stricte technicznych problemów.
   Jak wyżej- wytwarzanie oprogramowania zostawmy developerom.
3. Aktywny udział w procesie wytwarzania produktów (development). Nawet proste poprawki, czy ulepszenia nie są wskazane.
4. Osoby mające wiedzę techniczną często kusi szybkie poprawienie błędu w oprogramowaniu (w końcu wiedzą jak to zrobić). Dodatkowym atutem mógłby się wydawać zaoszczędzony czas – zamiast zgłaszać błąd i czekać aż zostanie zdiagnozowany i poprawiony, samemu można to zrobić w kilkadziesiąt minut – jednak szybko okaże się, że wszyscy traktują Technical Product Managera jako programistę, a tak zdecydowanie nie może być.
5. Przyjmowanie technicznych zadań od kierownictwa organizacji. To bardzo ważne, by jasno dać do zrozumienia, że Twoja wartość wnoszona dla firmy wynika z wykonywania zadań Product Managerskich. Bardzo często jest tak, że organizacje traktują Technical Product Managera jako rozszerzenie zespołu deweloperskiego, co prowadzi do frustracji zarówno po stronie osoby piastującej to stanowisko jak i kierownictwa.

Podsumowując

Technical Product Manager to bardziej definicja określająca osobę posiadającą techniczną wiedzę ułatwiającą zarządzanie produktem, a nie osobna rola w firmie. Taka osoba wykonuje tę samą pracę co „zwykły” PM wykorzystując swoje doświadczenie jako swojego rodzaju katalizator przyspieszający i poprawiający tworzenie / ulepszanie produktu.

Kamil Bednarczyk – niepoprawny optymista uwielbiający współpracę z klientem. Aktualnie programista aplikacji typu APM (Aplications Performance Management) i aspirujący Technical Product Manager. Od 3 lat działa w obszarze zarządzania produktami. Prywatnie fan spędzania czasu w towarzystwie znajomych oraz miłośnik samochodów.