Omdat ik een cursus over productmanagement geef aan de Harvard Business School, krijg ik regelmatig de vraag: “Wat is de rol van een productmanager?” De rol van productmanager (PM) wordt vaak aangeduid als de “CEO van het product”. Ik ben het daar niet mee eens, omdat, zoals Martin Eriksson opmerkt, “productmanagers gewoon geen directe zeggenschap hebben over de meeste dingen die nodig zijn om hun producten succesvol te maken – van gebruikers- en gegevensonderzoek via ontwerp en ontwikkeling tot marketing, verkoop en ondersteuning.” PM’s zijn niet de CEO van het product, en hun rol varieert sterk, afhankelijk van een aantal factoren. Dus, waar moet je rekening mee houden als je overweegt een PM rol te ambiëren?
Aspirerende PM’s moeten drie primaire factoren in overweging nemen bij het evalueren van een rol: kerncompetenties, emotionele intelligentie (EQ), en bedrijfsfitheid. De beste PM’s waar ik mee heb gewerkt beheersen de kerncompetenties, hebben een hoog EQ, en werken voor het bedrijf dat bij hen past. Naast het verschepen van nieuwe functies op een regelmatige cadans en het bewaren van de vrede tussen engineering en het design team, creëren de beste PM’s producten met een sterke gebruikersadoptie die een exponentiële omzetgroei hebben en misschien zelfs een industrie ontwrichten.
Kerncompetenties
Er zijn kerncompetenties die elke PM moet hebben – veel daarvan kunnen beginnen in het klaslokaal – maar de meeste worden ontwikkeld door ervaring, goede rolmodellen, en mentoring. Enkele voorbeelden van deze competenties zijn:
- het uitvoeren van klantinterviews en gebruikerstesten
- het leiden van ontwerpsprints
- prioritering van functionaliteiten en roadmap-planning
- de kunst van het toewijzen van middelen (het is geen wetenschap!
- het uitvoeren van marktanalyses
- het vertalen van business-naar-technische requirements, en vice versa
- prijsstelling en omzetmodellering
- het definiëren en bijhouden van succes metrics
Deze kerncompetenties zijn de basis voor elke PM, en de beste PM’s schaven deze vaardigheden bij gedurende jaren van definiëren, verschepen, en itereren op producten. Deze PM’s blinken uit in het reflecteren op waar elk van deze competenties heeft bijgedragen aan het succes of falen van hun producten en het continu aanpassen van hun aanpak op basis van feedback van klanten.
Emotionele intelligentie
Een goede PM kan de do’s en don’ts van een klantinterview kennen, maar de beste PM’s hebben het vermogen om zich in te leven in klanten tijdens dat interview, zijn afgestemd op hun lichaamstaal en emoties, en kunnen op een slimme manier de pijnpunten achterhalen die het product of de feature zal verhelpen. Een PM met een hoog EQ heeft sterke relaties binnen zijn organisatie en een scherp gevoel voor hoe hij zowel interne als externe hindernissen moet nemen om een geweldig product op de markt te brengen. Hier is een diepere blik op hoe de vier belangrijkste eigenschappen van EQ, zoals gedefinieerd door Daniel Goleman, betrekking hebben op de PM rol:
Relatie management. Waarschijnlijk een van de belangrijkste kenmerken van een goede PM is zijn of haar relatie management vaardigheden. Door het vormen van authentieke en betrouwbare verbindingen met zowel interne als externe belanghebbenden, inspireren de beste PM’s mensen en helpen hen hun volledige potentieel te bereiken. Relatiebeheer is ook van vitaal belang in succesvolle onderhandelingen, het oplossen van conflicten, en het samenwerken met anderen naar een gezamenlijk doel, wat vooral een uitdaging is wanneer een PM de taak heeft om de behoeften van klanten, resource-beperkte engineering teams, en de omzetdoelstellingen van het bedrijf in evenwicht te brengen. Authentieke en vertrouwensvolle relaties binnen een organisatie kunnen leiden tot meer steun wanneer extra financiering nodig is voor een product of wanneer een ingenieur moet worden overgehaald om een snelle bug fix in de volgende sprint op te nemen. Buiten een organisatie kunnen deze vaardigheden bestaande klanten aanmoedigen om een nieuwe functie in beta te testen voor vroegtijdige feedback of om een beoogde klant te overtuigen om de MVP te proberen van een product dat nog in stealth modus is. Deze relatievaardigheden kunnen ook het verschil maken tussen boze klanten vanwege een bug in het product en klanten die zeggen: “Geen zorgen, we weten dat jullie dit oplossen!”
Zelfbewustzijn. PM’s moeten zelfbewust zijn om objectief te blijven en te voorkomen dat ze hun eigen voorkeuren projecteren op de gebruikers van hun producten. Als een PM verliefd is op een feature omdat het zijn eigen pijnpunten verhelpt – PM’s zijn vaak super-gebruikers van de producten waar ze verantwoordelijk voor zijn – dan kan het zijn dat een gebruiker zegt dat hij er ook van houdt, alleen maar om de PM een plezier te doen (“false positive feature validation”). Indien niet zelfbewust, kan een PM aandringen op het prioriteren van een feature die hij zelf bedacht heeft, zelfs wanneer alle klanten interviews en bewijzen ertegen zijn. Dit gebrek aan zelfbewustzijn kan belangrijkere prioriteiten doen ontsporen of de relatie tussen de PM en de engineers schaden, die hun vertrouwen in de PM kunnen verliezen wanneer de feature niet snel door gebruikers wordt geaccepteerd.
Zelf-management. Een PM zijn kan ongelooflijk stressvol zijn. De CEO wil het ene, het engineering team het andere, en klanten hebben hun eigen mening over de prioriteiten van features. Het managen van strakke deadlines, omzetdoelstellingen, markteisen, prioriteitsconflicten en resource beperkingen is niet voor de zwakke van hart. Als een PM zijn emoties niet onder controle kan houden en het hoofd koel kan houden onder druk, kan hij snel het vertrouwen verliezen van al zijn kiezers. De beste PM’s weten hoe ze hard moeten duwen op de juiste prioriteiten, met urgentie maar zonder een gevoel van paniek of stress over te brengen. Deze PM’s weten ook wanneer ze op adem moeten komen en afstand moeten nemen om te hergroeperen.
Sociaal bewustzijn. Volgens Goleman, zijn de competenties die geassocieerd worden met sociaal bewustzijn empathie, organisatorisch bewustzijn, en service. PM’s moeten de emoties en zorgen van klanten over hun product net zo goed begrijpen als de zorgen van het verkoopteam over hoe ze dat product moeten verkopen, of het supportteam over hoe ze het moeten ondersteunen, of het engineeringteam over hoe ze het moeten bouwen. PM’s moeten een diep inzicht hebben in hoe de organisatie werkt en moeten sociaal kapitaal opbouwen om het succes van hun product te beïnvloeden, van het verkrijgen van budget en personeel tot het binnenhalen van een top ingenieur om aan hun product te werken. Tot slot zorgt sociaal bewustzijn ervoor dat de beste PM’s hun klanten bedienen met een product dat hun werk doet, wat uiteindelijk de product-markt fit is.
(Lees hier meer over wat Paul Jackson te zeggen heeft over EQ en PM’s. En hier is een interview met Sam Lessin, voormalig VP product management bij Facebook, die zegt dat hij “nooit met succes empathie heeft getraind.”)
Company Fit
Als de beste PM’s goed ontwikkelde kerncompetenties en een hoog EQ hebben, betekent dat dan dat ze voorbestemd zijn voor succes, waar ze ook werken? Niet noodzakelijk. In feite is het zo dat het toepassen van deze vaardigheden en persoonlijkheidskenmerken op het juiste bedrijf uiteindelijk succes zal garanderen.
Ik heb nog geen standaard functieomschrijving voor een productmanager gezien, omdat elke rol uiteindelijk wordt bepaald door de grootte, het type product, de fase, de industrie en zelfs de cultuur van het bedrijf. Als je de kerncompetenties en het hoge EQ bezit die nodig zijn om een succesvolle PM te zijn, is de volgende stap om uit te zoeken wie er inhuurt en waar ze echt naar op zoek zijn.
Hier zijn een paar van de belangrijkste gebieden waarop bedrijven verschillen in wat ze van een PM willen:
Technische vaardigheid. Het type product, wie het gebruikt, en het type bedrijf bepalen hoe technisch een PM moet zijn. Google eist bijvoorbeeld dat PM’s slagen voor een technische vaardigheidstest, ongeacht het product waar ze aan werken. Als het bedrijf een SaaS CRM aan het bouwen is, zijn er misschien meer vereisten rond ervaring met go-to-market en customer lifecycles dan rond hoe het product wordt gebouwd. Als het daarentegen gaat om een data science-product met algoritmes voor machinaal leren en API’s, kan de functie veel meer technische diepgang vereisen om niet alleen te begrijpen hoe het product moet worden gebouwd, maar ook hoe op een geloofwaardige manier kan worden gesproken met de klanten die het zullen gebruiken. Dat gezegd hebbende, een technisch basisbegrip van wat er onder de motorkap zit en beheersing van de tools die PM’s gebruiken is zeker belangrijk voor de rol, waar die ook is. Colin Lernell heeft hier meer te zeggen over deze noodzakelijke vaardigheden. Als je een aspirant PM’er bent en bezorgd bent dat je de technische basisvaardigheden voor de rol mist, zou je kunnen overwegen om online cursussen te volgen, zoals de gerenommeerde cursus Introduction to Computer Science (CS50) aangeboden door Harvard University of een van de vele intro en advanced technology cursussen aangeboden door The Flatiron School.
Bedrijfsfilosofie over PM. Elk bedrijf heeft een andere filosofie over het productontwikkelingsproces en waar PM’s in dat proces passen. Hieronder staan de drie meest voorkomende types, met voor- en nadelen:
- PM stuurt engineering. Dit is een “gooi het over de muur” aanpak, waar PM’s eisen verzamelen, schrijf de quintessentiële product eisen document, en geef het af aan engineering om de technische eisen te specificeren. Hedendaagse organisaties kunnen dit proces op een meer agile en collaboratieve manier doen, maar de verwachting is dat PM’s het beste weten wat klanten nodig hebben en engineering is er om te dienen.
- Pro: Engineering kan zich richten op coderen zonder veel afleiding; dit heeft de neiging om goed te werken voor Waterval-ontwikkelingswinkels met lange levenscycli.
- Con: Engineers verliezen het grote geheel uit het oog en ontwikkelen geen empathie voor klanten, wat kan leiden tot een slechte gebruikerservaring. Vaak zijn er ongezonde spanningen wanneer technische schuld en “loodgieterswerk” voorrang moeten krijgen boven de eisen van de klant.
- Engineering stuurt product. Meer technisch georiënteerde productbedrijven (cloud, big data, netwerken) hebben de neiging om engineering-gedreven te zijn, waar ingenieurs de wetenschap in hun domein vooruit helpen en PM’s oplossingen valideren of front-end toegangspunten creëren (UI’s, API’s) om deze nieuwe technologie aan te boren. Er kan een samenwerkingsrelatie en feedback loop tussen klanten, PM’s, en engineering, maar meestal PM’s dienen engineering in deze bedrijven.
- Pro: baanbrekende technologie kan klanten dingen bieden waarvan ze niet eens wisten dat ze die nodig hadden. VMotion bij VMware was hier een goed voorbeeld van. Een ingenieur dacht dat het cool zou zijn om te doen, een PM bedacht hoe het te gelde te maken, en het werd een miljard-dollar game changer voor het bedrijf.
- Con: Ingenieurs jagen op het glanzende nieuwe ding, over-architect de oplossing, of itereren eeuwig, op zoek naar perfectie voordat de klant feedback krijgt. PM input over prioriteiten wordt genegeerd, die soms de meest fundamentele behoeften van klanten omvat.
- Het PM-engineering partnerschap. In deze gevallen is er een sterke yin-yang tussen PM en engineering, met gezamenlijke ontdekking, besluitvorming, en gedeelde verantwoordelijkheid. Engineers vergezellen PMs in klantinterviews, en PMs zijn in sprint meetings om te helpen taken te deblokkeren of vereisten te verduidelijken. Maar de twee rollen respecteren de lijn waar de ene begint en de andere stopt. PM’s begrijpen wat er wordt gecodeerd, maar vertellen engineers niet hoe ze moeten coderen, en engineers hebben empathie voor de behoeften van de klant, maar laten de prioritering over aan de PM’s.
- Pro: Een gestroomlijnd prioriteringsproces dat technische schuld en loodgieterprojecten waardeert; betere ontwerpprocessen die leiden tot een positievere gebruikerservaring; beter presterende teams met verbeterde productsnelheid, kwaliteit, en, typisch, gelukkigere klanten.
- Con: baanbrekende innovatie krijgt misschien geen groen licht; time-to-market lijkt achter te lopen (hoewel ik zou willen stellen dat wat wordt vrijgegeven veel beter is afgestemd op de behoeften van de klant en meer kans heeft om succesvol te schalen).
Ik ben duidelijk bevooroordeeld in het voordeel van het derde type filosofie over PM (net als durfkapitalist Fred Wilson), omdat ik ze alle drie heb ervaren en de yin-yang het meest effectief vond. Maar dat wil niet zeggen dat de andere bijzonder slecht zijn – het hangt echt af van het type product dat je aan het bouwen bent, de fase van het bedrijf, en nog veel meer. Hoe dan ook, als je een PM rol overweegt, kan de filosofie van de PM in het bedrijf de beslissende factor zijn voor geschiktheid voor de rol.
Stadium van het bedrijf. De rol van de PM bij een startup is veel waarschijnlijker verantwoordelijk voor “alle dingen,” terwijl bij een volwassen bedrijf hun rol meer duidelijk omschreven zal zijn. (Het boek Product Leadership van Banfield, Eriksson, en Walkingshaw heeft een sectie die veel meer details over dit onderwerp bevat.)
- Startup. Naast de ontdekking, definitie en verzending, kunnen PM’s ook verantwoordelijk zijn voor de prijsstelling, marketing, ondersteuning, en mogelijk zelfs de verkoop van het product. Deze PM’s gedijen in een scrappy omgeving en zijn comfortabel met ambiguïteit en frequente veranderingen van richting als het bedrijf werkt aan product-markt fit en leert om te werken op schaal.
- Pro: PM’s zijn waarschijnlijk meer betrokken bij de strategie van het bedrijf, komen in contact met senior leiderschap en het bestuur, kunnen meer risico’s nemen en een grotere impact hebben. Ze hebben ook meer invloed en gezag over bedrijfsmiddelen.
- Con: er is meestal weinig tot geen mentorschap, rolmodellen, of best practices binnen het bedrijf. Budgetten zijn meestal krap, en PM’s hebben misschien niet de vereiste ervaring om te slagen in een aantal van de dingen die ze moeten doen.
- Volwassen bedrijf. De PM kan een beperktere scope hebben en collega’s hebben die zich bezighouden met prijsstelling, go-to-market-strategieën, enzovoort. En ze zullen waarschijnlijk deel uitmaken van een groter team van productmanagers.
- Pro: PM’s hebben meer kans op mentorschap en rolmodellen, evenals ontwikkelingsstandaarden en beste praktijken. Nauwe banden met een engineeringteam kunnen na verloop van tijd sterke relaties creëren, wat goed is voor de impact op de lange termijn en de groei van je carrière. En als het product geschikt is voor de markt, is er een gevestigde klantenbasis en prestatiebasis om vanuit te werken, in plaats van te gissen tot je het goed hebt.
- Con: PM’s hebben minder zicht op de bedrijfsstrategie en zijn slechts een van de vele stemmen van de klant. Ze kunnen “verloren” raken in het systeem en hebben te maken met meer politiek en krappe budgetten.
Oprichter/CTO/CEO relatie met PM. Vooral bij bedrijven in een vroeg stadium is het belangrijk om te weten hoe betrokken de oprichter/CEO/CTO is bij het productproces. Als ze zeer betrokken zijn, kan de PM meer een ondersteunende rol spelen, om hun ideeën uit te werken of concepten te valideren met klanten, in plaats van zelf ideeën te bedenken en aan te sturen. Dit kan heel leuk zijn voor sommige PM’s die graag samenwerken met oprichters en C-level executives en die graag meewerken aan de productevolutie. Maar voor andere PM’s kan het zeer frustrerend zijn als ze liever meer verantwoordelijkheid nemen voor de product richting. Het kan ook een uitdaging zijn als de meer technische oprichters of C-levels liever rechtstreeks met ingenieurs werken. Dit kan PM’s buiten de boot laten vallen of ondermijnen (soms onbedoeld), wat niet alleen persoonlijke frustraties maar ook vertragingen veroorzaakt. Als je een PM rol overweegt die nauw samenwerkt met het oprichtende leiderschapsteam, zorg er dan voor dat je hun verwachtingen van de PM functie te weten komt en beslis of dit de juiste match is met jouw interesses.
Er zijn natuurlijk veel andere factoren om te overwegen voor elke rol, zoals het type product dat je bouwt (B2B, B2C, industrie), de mensen met wie je zal werken, de algemene bedrijfscultuur (divers, inclusief, flexibele werktijden, cultuur op afstand), en, natuurlijk, de vergoeding en de voordelen. Er zijn ook heel wat artikels over het aanwerven van productmanagers om een idee te krijgen van wat de aanwervende managers zoeken – ik raad vooral het stuk “How to Hire a Product Manager” van mijn vriend Ken Norton aan. Maar als u ernaar streeft een geweldige productmanager te worden, overweeg dan al het bovenstaande voordat u uw handtekening zet onder uw volgende opdracht. Het ontwikkelen van kerncompetenties zal een voortdurende activiteit zijn gedurende je hele carrière, en gebruik maken van EQ zal zorgen voor een positievere ervaring. Maar waar je werkt, hoe ze werken, en met wie en voor wie je werkt, zal uiteindelijk je succes op de lange termijn bepalen.
Een versie van dit artikel verscheen voor het eerst op de website van de auteur.