Czym w ogóle jest menedżer produktu technicznego?

co tak naprawdę znaczy być „technicznym” Product Managerem? A czym różni się od menedżera produktu? W tym poście podzielam różnicę między tymi tytułami oraz kluczami Do I Don ’ t, aby pomóc ci odnieść sukces jako menedżer produktu technicznego.

być może zauważyłeś wiele odmian stanowiska Product Manager. Niektóre firmy mają strategicznych menedżerów produktów, podczas gdy inne mają tytuły menedżerów produktów związane z konkretnymi branżami, na przykład menedżerów produktów eCommerce i menedżerów produktów energetycznych. Wśród firm programistycznych często pojawiają się tytuły Product Manager, Product Development Manager i Technical Product Manager. Ale co za różnica?

w rzeczywistości termin Technical Product Manager opisuje osobę, a nie rolę. W szczególności opisuje menedżera produktu, który ma zaplecze techniczne i pracuje nad produktem technologicznym. Nie opisuje menedżera produktu, który musi faktycznie wykonywać zadania techniczne, takie jak projektowanie i kodowanie oprogramowania. To samo dotyczy menedżera ds. rozwoju produktu. W rzeczywistości nie opracowują produktu—pełnią rolę zarządzania produktem w ścisłej koordynacji z zespołem programistów.

krótko mówiąc, aby firma czerpała największą wartość z roli, menedżerowie produktu muszą skupić się na zarządzaniu produktem, a nie na rozwoju. Ale niektórzy menedżerowie produktu muszą zrozumieć technologię firmy na głębokim poziomie i współpracować z zespołem programistów, aby skutecznie prowadzić strategię dla produktu. Firmy mogą wybrać, aby nazwać tych ludzi „Technical Product Managers” w celu przyciągnięcia odpowiedniego kandydata.

moim zdaniem umiejętności techniczne są jednym z czterech filarów przywództwa produktowego. Doświadczony technologicznie menedżer produktu ma ogromne zalety, takie jak:

• Lepsza komunikacja (i zaufanie) ze strony zespołu programistów.
• umiejętność rozumienia trendów technologicznych, sprawdzania, jak wpływają one na plan działania i jak napędzają innowacje.
• Lepsza komunikacja z klientami, na przykład podczas rozmów z CIO i CTO.
• umiejętność rozumienia wyzwań technicznych i dokonywania wyedukowanych kompromisów ze swoim zespołem.

jednak zbyt często menedżerowie produktu technicznego koncentrują te cenne umiejętności na próbie stworzenia rozwiązania technicznego dla swojego produktu, a nie na rozwiązywaniu potrzeb biznesowych i użytkowników klienta docelowego.

z tej perspektywy przyjrzyjmy się kluczowym działom „zrób i nie rób” dla technicznych menedżerów produktów.

Technical Product Manager Do ’ s:

1. Skup się na biznesowej stronie roli.

niezależnie od branży czy pionu, cała idea zarządzania produktem polega na kierowaniu wizją i wykonaniem produktu. Naszym obowiązkiem jest wprowadzanie na rynek produktów, których użytkownicy chcą, które rozwiązują potrzeby biznesowe i generują zysk dla firmy. Zawsze jestem zafascynowany, widząc technologów, którzy wprowadzają swoją nową firmę z produktem, który jest bardzo sprytną techniczną implementacją, ale nie rozwiązuje rzeczywistych potrzeb klienta. Nie trzeba dodawać, że firmy te rzadko radzą sobie dobrze na rynku.

głównym celem menedżera produktu (technicznego lub nie) powinno być zrozumienie potrzeb użytkowników i współpraca ze wszystkimi działami niezbędnymi do ożywienia produktu. W tym sensie Technical Product Manager to rola biznesowa skupiająca się na technologii, w przeciwieństwie do roli technologa, który nie ponosi odpowiedzialności za sukces rynkowy produktu.

2. Wykorzystaj swoje umiejętności techniczne, aby poprawić ustalanie priorytetów i planowanie.

jeśli masz jasne zrozumienie, w jaki sposób twój produkt jest zbudowany, jesteś w stanie ocenić ryzyko pewnych funkcji lub uzyskać dokładniejsze przeczucie dotyczące czasu trwania historii lub zadań. Ponieważ jesteś w stanie komunikować się z zespołem programistów znacznie bardziej szczegółowo, możesz zrozumieć konsekwencje niektórych decyzji i dokonać kompromisów pod względem złożoności, głębi, a nawet osi czasu.

demonstrując przywództwo techniczne, będziesz w stanie szybko zdobyć zaufanie swojego zespołu programistów i będzie on bardziej skłonny stanąć za Tobą w trudnych decyzjach, które wymagają ryzykownych zmian, priorytetyzowania błędów, a nawet negocjowania przerażającego „długu technicznego.”

3. Wykorzystaj swoje umiejętności techniczne, aby wypełnić lukę komunikacyjną między inżynierią a resztą świata.

ludzie z wykształceniem technicznym zwykle zapominają, że mało kto inny rozumie (lub dba) o szczegóły techniczne. Jest to doskonała okazja dla Technical Product Manager, aby wykorzystać swoje umiejętności do tłumaczenia między inżynierią a innymi działami, w tym sprzedażą, marketingiem produktów i klientem.

również menedżerowie produktów technicznych są często zatrudniani do kierowania produktami skierowanymi do bardzo technicznej grupy odbiorców, takimi jak interfejsy API, narzędzia programistyczne, oprogramowanie IT itp. W takich przypadkach funkcje produktu, pozycjonowanie produktu i przesyłanie wiadomości muszą rezonować z bardzo techniczną publicznością. Jest to kolejna doskonała okazja, aby wykorzystać swoje umiejętności techniczne, aby komunikować się z odbiorcami, uzyskać informacje zwrotne (w ich języku) i pomóc w sfinalizowaniu transakcji, rozmawiając z personelem technicznym klienta.

Technical Product Manager

1. Nie projektuj / nie rozwiązuj produktu samodzielnie.

jest to kluczowe źródło zamieszania w roli menedżera produktu technicznego. Wielu menedżerów produktu, którzy pochodzą z inżynierii, ma trudności z opuszczeniem strefy komfortu i zdaniem sobie sprawy, że ich wartość jest teraz w innym obszarze. Koncentrują się one na definiowaniu rozwiązania technicznego dla konkretnej funkcji, zamiast definiowania oczekiwanego wyniku użytkownika lub wartości biznesowej. Więcej czasu spędzają na rozmowach z architektami i patrzeniu na barki deweloperów niż na rozmowach z klientami i sprzedawcami.

to powoduje problemy na dwóch frontach:

1. zespół programistów czuje się sfrustrowany, ponieważ szczegóły rozwiązania są po prostu przekazywane im przez premiera. Nie mają szansy na zaprojektowanie i zaprojektowanie rozwiązania, co jest dużą częścią ich pracy, nie Twojej.
2. większość czasu PM spędza w szczegółach technicznych, więc nie ma czasu na planowanie i zrozumienie klienta.

w skrócie, takie podejście nie dodaje wartości programistom, właścicielom firm ani samemu produktowi. Nawet menedżerowie produktu technicznego muszą być sparowani z silnymi potencjalnymi kierownikami technicznymi lub kierownikami ds. rozwoju, którzy mogą prowadzić te zadania. Moje motto brzmi: „fakt, że możesz, nie oznacza, że powinieneś.”

pisząc funkcje i historie, skup się na problemie, który chcesz rozwiązać, i na osobie, którą kierujesz. Definicja powinna zawierać schemat przepływu tego, jakie rozwiązanie powinno być (z perspektywy użytkownika), w tym kryteria akceptacji. Nie powinno to być szczegółowe wyjaśnienie rozmieszczenia każdego piksela, aktualizacji modelu obiektowego ani wymaganych zmian w tabelach bazy danych.

2. Nie przyjmuj produktów innych niż zarządzanie produktem.

wiele firm (szczególnie tych z mniej dojrzałym procesem produktowym) uważa Technical Product Manager za przedłużenie zespołu programistów. Widziałem wiele opisów stanowisk, które wymieniają regularne obowiązki (Mapa Drogowa, wizja, definicja funkcji itp.), a także obowiązki programistyczne, takie jak pisanie rzeczywistego kodu, testowanie jakości, pisanie dokumentacji itp. Dla mnie to po prostu pokazuje wielkie niezrozumienie wartości roli, a takich sytuacji należy unikać za wszelką cenę.

3. Nie daj się wciągnąć w Agile lub jakąkolwiek metodologię używasz.

zawsze jestem zdumiony ilością dyskusji, które widzę w Internecie na temat Agile i zarządzania produktem. Chociaż rozumiem, dlaczego-wiele technicznych PMs pochodzi z rozwoju, więc pozostawanie bardzo zaangażowanym w codzienny zwinny przepływ jest dla nich bardzo wygodne.

jednak w rzeczywistości Agile jest bardzo małą częścią roli menedżera produktu. Zbyt duża koncentracja na zwinności może być szkodliwa, gdy wymaga czasu od podstawowych obowiązków premiera, takich jak interakcja z klientami i sprzedażą oraz zdefiniowanie mapy drogowej.

aby zmniejszyć obciążenie pracą, jestem wielkim zwolennikiem różnych osób pełniących role menedżera produktu i Właściciela Produktu. Takie podejście jest kontrowersyjne i może być możliwe tylko w firmach o bardziej dojrzałym procesie produkcyjnym. Niezależnie od tego, uważam, że ta separacja ma dużą wartość, aby zapewnić, że żaden aspekt cyklu rozwoju produktu lub zarządzania produktem nie przejdzie przez pęknięcia z powodu przepracowanego premiera.

aby uzyskać lepszy obraz wszystkich obowiązków menedżera produktu, proponuję przyjrzeć się frameworkom PM, takim jak te z Pragmatic Marketing i SiriusDecisions.

Podsumowując

różne firmy mają różne tytuły zarządzania produktem i obowiązki w zależności od rodzaju produktu. Niezależnie od tego, głównym zadaniem menedżera produktu jest dostarczanie wizji produktu, tworzenie mapy drogowej i kierowanie jego realizacją.

dodanie słowa „techniczny” do tytułu jest przydatne w ofertach pracy, aby podkreślić potrzebę zaplecza technicznego. Jednak w pracy klucz do sukcesu jest taki sam, jak w przypadku każdego menedżera produktu—skupienie się na kliencie, kierowanie wizją i zapewnienie, że produkt spełnia potrzeby rynku.

jest to wpis gościnny napisany przez Daniela Elizalde, autora książki Manager ’ s Build: best practices & inspiracja dla menedżerów produktów & liderów.