Wat is een technisch productmanager eigenlijk?

wat betekent het werkelijk om een “technisch” productmanager te zijn? En hoe is het anders dan een productmanager? In deze post, ik deel het verschil tussen deze titels plus key Do ’s en Don’ t ‘ s om u te helpen slagen als een technische Product Manager.

u hebt wellicht veel variaties opgemerkt op de functie van Product Manager. Sommige bedrijven hebben strategische productmanagers, terwijl anderen productmanager-titels hebben die zijn gekoppeld aan specifieke brancheverticals, bijvoorbeeld E-commerce productmanagers en Energieproductmanagers. Onder software bedrijven, zie je vaak de titels Product Manager, Product Development Manager, en technische Product Manager. Maar wat is het verschil?

in werkelijkheid beschrijft de term Technical Product Manager een persoon, niet een rol. Specifiek beschrijft het een productmanager die een technische achtergrond heeft en werkt aan een technologieproduct. Het beschrijft niet een productmanager die daadwerkelijk technische taken moet uitvoeren, zoals softwarearchitecteren en coderen. Hetzelfde geldt voor een Product Development Manager. Ze zijn niet echt het product te ontwikkelen—ze zijn het uitvoeren van een Product Management rol in nauwe coördinatie met een Software Development Team.

kortom, wil een bedrijf de meeste waarde uit de rol halen, dan moeten productmanagers zich richten op productmanagement, niet op ontwikkeling. Maar sommige productmanagers moeten de technologie van het bedrijf op een diep niveau begrijpen en communiceren met het ontwikkelingsteam om de strategie voor het product succesvol te leiden. Bedrijven kunnen ervoor kiezen om deze mensen “technische productmanagers” te noemen om de juiste kandidaat aan te trekken.Naar mijn mening zijn technische vaardigheden een van de vier pijlers van productleiderschap. Een technologie-savvy Product Manager heeft enorme voordelen, zoals:

• verbeterde communicatie (en vertrouwen) van uw ontwikkelingsteam.
• het vermogen om technologische trends te begrijpen, te zien hoe ze uw roadmap beïnvloeden en hoe ze innovatie stimuleren.
• verbeterde communicatie met uw klanten, bijvoorbeeld bij het spreken met CIO ’s en CTO’ s.
• het vermogen om technische uitdagingen te begrijpen en opgeleide afwegingen te maken met uw team.

echter, maar al te vaak richten technische productmanagers die waardevolle vaardigheden op het proberen om de technische oplossing voor hun product te creëren, in plaats van het oplossen van de zakelijke en gebruikersbehoeften van hun doelklant.

vanuit dat perspectief, laten we eens kijken naar key Do ’s en Don’ t ‘ s voor technische productmanagers.

technische productmanager Do ‘ s:

1. Richt je op de zakelijke kant van de rol.

ongeacht de sector of de verticale, het hele idee achter productmanagement is om de visie en uitvoering van een product te stimuleren. Het is onze verantwoordelijkheid om producten op de markt te brengen die gebruikers willen, die een zakelijke behoefte oplossen en die winst genereren voor het bedrijf. Ik ben altijd gefascineerd om te zien dat technologen hun nieuwe bedrijf lanceren met een product dat een zeer slimme technische implementatie is, maar het lost geen echte behoefte van de klant op. Onnodig te zeggen, deze bedrijven zelden goed doen in de markt.

de focus van een productmanager (al dan niet technisch) moet zijn om te begrijpen wat de gebruikers nodig hebben en om samen te werken met alle afdelingen die nodig zijn om het product tot leven te brengen. In die zin is de Technical Product Manager een zakelijke rol met enige focus op technologie in tegenstelling tot een technoloog rol zonder verantwoordelijkheid voor het marktsucces van het product.

2. Gebruik uw technische vaardigheden om prioritering en planning te verbeteren.

als u een duidelijk begrip hebt van hoe uw product wordt gebouwd, kunt u het risico van bepaalde functies inschatten of een nauwkeuriger gevoel krijgen over de duur van verhalen of taken. Omdat je in staat bent om te communiceren met het ontwikkelingsteam in veel meer detail, kunt u de implicaties van bepaalde beslissingen te begrijpen en trade-offs in termen van complexiteit, diepte of zelfs tijdlijnen.

door technisch leiderschap aan te tonen, zult u in staat zijn om snel het vertrouwen van uw ontwikkelingsteam te winnen en zij zullen meer kans hebben om achter u te staan bij moeilijke beslissingen die riskante veranderingen vereisen, het prioriteren van bugs, of zelfs onderhandelen over de gevreesde “technische schuld.”

3. Gebruik uw technische vaardigheden om de communicatiekloof tussen engineering en de rest van de wereld te dichten.

mensen met een technische achtergrond vergeten meestal dat bijna niemand anders de technische details begrijpt (of er iets om geeft). Dit is een perfecte gelegenheid voor de Technical Product Manager om haar vaardigheden te gebruiken om te vertalen tussen Engineering en andere afdelingen, waaronder Sales, Product Marketing, en de klant.

ook worden Technische productmanagers vaak ingehuurd om producten aan te drijven die gericht zijn op een zeer technisch publiek, zoals API ‘ s, ontwikkeltools, IT-software, enz. In deze gevallen moeten de productfuncties, productpositionering en messaging resoneren met een zeer technisch publiek. Dit is een andere perfecte gelegenheid om uw technische vaardigheden te benutten om te communiceren met uw publiek, feedback te krijgen (in hun taal), en helpen een deal te sluiten door te spreken met de technische medewerkers van de klant.

Technical Product Manager Don ‘ s

1. Ontwerp / oplossing het product niet zelf.

dit is een belangrijke bron van verwarring binnen de rol van technisch productmanager. Veel productmanagers die afkomstig zijn van engineering hebben het moeilijk om hun comfortzone te verlaten en zich te realiseren dat hun waarde zich nu in een ander gebied bevindt. Ze richten zich op het definiëren van de technische oplossing voor een bepaalde functie in plaats van het definiëren van de verwachte user outcome of business value. Ze besteden meer tijd aan praten met hun architecten en kijken over de schouders van de ontwikkelaars, dan praten met klanten en verkoop.

dit veroorzaakt problemen op twee fronten:

1. het ontwikkelingsteam voelt zich gefrustreerd omdat de oplossingsdetails net door de Premier aan hen zijn doorgegeven. Ze krijgen geen kans om de oplossing te ontwerpen, wat een groot deel van hun werk is, niet die van jou.
2. het grootste deel van de tijd van de PM wordt besteed aan de technische details, dus er is geen tijd meer om de klant te plannen en te begrijpen.

In een notendop voegt deze aanpak geen waarde toe aan ontwikkelaars, ondernemers of het product zelf. Zelfs technische productmanagers moeten worden gekoppeld met sterke technische Leads of Development Managers die deze taken kunnen leiden. Mijn motto is: “het feit dat je het kunt, betekent niet dat je het moet doen.”

bij het schrijven van functies en verhalen, focus je op het probleem dat je wilt oplossen en op de persona waarop je je richt. De definitie moet een stroomdiagram bevatten van wat de oplossing zou moeten zijn (vanuit het oogpunt van de gebruiker), met inbegrip van acceptatiecriteria. Het zou geen gedetailleerde uitleg moeten zijn over de plaatsing van elke pixel, updates van het objectmodel of de vereiste wijzigingen in de databasetabellen.

2. Neem niet op non-Product Management deliverables.

veel bedrijven (vooral die met een minder volwassen productproces) zien de technische productmanager als een uitbreiding van het ontwikkelingsteam. Ik heb veel functiebeschrijvingen die een lijst van de reguliere verantwoordelijkheden (roadmap, visie, functie definitie, enz.), plus ontwikkelingsverantwoordelijkheden zoals het schrijven van daadwerkelijke code, het uitvoeren van QA-testen, het schrijven van documentatie, enz. Voor mij toont dit alleen maar een groot misverstand over de waarde van de rol, en die situaties moeten worden vermeden ten koste van alles.

3. Raak niet verstrikt in Agile, of welke methodologie je ook gebruikt.

ik ben altijd verbaasd over de hoeveelheid discussie die ik online zie over Agile en Product Management. Hoewel ik begrijp waarom-veel technische PMs komen uit de ontwikkeling, dus het blijven extreem betrokken bij de dag-tot-dag Agile flow voelt zeer comfortabel voor hen.

echter, de realiteit is dat Agile een zeer klein deel van de rol van de productmanager is. Te veel focussen op Agile kan eigenlijk een nadeel zijn wanneer het tijd weg te nemen van de kern PM verantwoordelijkheden, zoals interactie met klanten en verkoop en het definiëren van de roadmap.

om de werklast te verlichten, ben ik een groot voorstander van het hebben van verschillende mensen die de rol van productmanager en producteigenaar vervullen. Deze aanpak is controversieel, en het is misschien alleen mogelijk in bedrijven met een meer volwassen productproces. Hoe dan ook, ik denk dat er veel waarde in deze scheiding om ervoor te zorgen dat geen aspect van de productontwikkeling levenscyclus of product management valt door de scheuren, als gevolg van een overwerkte PM.

om een beter inzicht te krijgen in alle verantwoordelijkheden van een productmanager, stel ik voor om te kijken naar PM-kaders zoals die van pragmatische Marketing en Sirius-besluiten.

in het kort

verschillende bedrijven hebben verschillende titels en verantwoordelijkheden op het gebied van productbeheer, afhankelijk van hun soort product. Maar hoe dan ook, de kerntaak van een productmanager is om de visie van het product te bieden, de roadmap te maken en de uitvoering ervan te stimuleren.

het woord “technisch” toevoegen aan de titel is nuttig bij vacatures om de behoefte aan technische achtergrond te benadrukken. Maar eenmaal in het werk, de sleutels tot succes zijn hetzelfde als voor elke Product Manager-het houden van de klant focus, het sturen van een visie, en ervoor te zorgen dat het product voldoet aan de behoeften van de markt.

dit is een gastpost geschreven door Daniel Elizalde, auteur van Manager ‘ s Build: best practices & inspiration for Product Managers & Leaders.