Productmanagers zijn een absolute noodzaak om elk product te schalen naarmate uw bedrijf groeit. Om dat te herformuleren, goede productmanagers zijn een noodzaak. Ze kunnen een enorme impact hebben op uw bedrijf, positief of negatief.

Productmanagers zijn ook zeer moeilijk te vinden. Echter, ik geloof eigenlijk dat je iemand kunt aannemen voor een rol als productmanager, zelfs als ze het nog nooit eerder hebben gedaan.

Veel van mijn advies hier gaat over hoe je interactie hebt met je ontwikkelteam. Er zijn andere gebieden waarin je goed moet zijn, maar dit is de enige zekere manier om falen te garanderen als je geen geweldige en vertrouwensrelatie hebt met je ontwikkelteam. Tenslotte is er een ongeschreven contract waar alle PM's en hun ontwikkelteam zich aan houden: "Ik zal de roadmap voor het product aansturen. Je zult vertrouwen dat ik het juiste proces heb om de juiste functies te kiezen om me op te concentreren, en dat klanten zullen houden van wat je bouwt. Ik zal vertrouwen dat je mijn functies zult opleveren wanneer je zegt dat je dat zult."

Dus wanneer ik op zoek ga naar iemand voor deze rol, is dit mijn overzicht van de focusgebieden die ik cruciaal vind voor een productmanager om succesvol te zijn.

Klantgericht zijn

De meeste goede productmanagers kwamen uit een klantgerichte rol. Misschien waren ze een verkoopingenieur, een oplossingarchitect, een ondersteuningspersoon, een dienstenpersoon, enzovoort. Wat het ook is, ze waren bezig met het oplossen van problemen voor klanten. Ze leerden hoe ze een probleem voor een klant konden oplossen en waren daarin van begin tot eind betrokken. Het is een essentiële vaardigheid.

Patroonextractie

Als je de klantgerichte ervaring hebt, EN je begrijpt hoe je naar patronen in de feedback die je krijgt moet zoeken, dan zou je een dodelijke PM kunnen zijn. Je kunt de een niet zonder de ander hebben. Een klantgerichte persoon die klantproblemen op een eenmalige, zeer aangepaste manier oplost, moet erkennen dat deze aanpak niet zal werken. Naar welk type bedrijf verkopen we? Wie in dat bedrijf koopt, beveelt aan of gebruikt ons product? Welke feedback geven die mensen ons over het product? Na 10 gesprekken met het juiste type klant, wat zijn de top terugkerende thema's?

Begrip van trade-offs, vermogen om goede beslissingen te nemen

PM's denken voortdurend na over 10 functies die ze echt nodig hebben, en kunnen waarschijnlijk op 3 daarvan uitvoeren. Welke 3? Waarom die 3? Deze analyse en denkwijze is cruciaal om ervoor te zorgen dat je team altijd aan de meest impactvolle dingen werkt.

Mouwen altijd opgerold

Als PM, vooral in de beginperiode, kun je websitecommunicatie, content voor verkoopondersteuning schrijven, je in supporttickets storten, productdemonstraties doen, klanten bezoeken, wat dan ook. Goede PM's springen hier graag in, omdat het hen alleen maar effectiever maakt in hun werk, omdat ze zien hoe de frontlinie-interactie met hun product daadwerkelijk werkt.

Ken je gebied goed

Je moet je markt beter kennen dan wie dan ook. Stel Feedly, Google Alerts of welk systeem je ook gebruikt in en zorg ervoor dat je je relevante blogs/publicaties leest. Als je ooit een PM bent geweest en werd gevraagd naar een concurrent van je product waarvan je nog nooit had gehoord, dan is die steek in het hart waarschijnlijk genoeg les om ervoor te zorgen dat dat niet nog eens gebeurt. Ik zeg niet dat je je obsessief moet richten op je concurrenten, maar ken ze. Ken de 3 redenen waarom je anders en beter bent.

Ken je product goed

Dit kan je verwarren, maar ik heb het echt gezien. Als je je product niet met vertrouwen kunt demonstreren en gebruiken, ga dan onmiddellijk naar je productbootcamp. Dit geldt ook voor "feature-PM's" - waarbij je een segment van je product bezit, meestal als bedrijven groter worden. Probeer hoe dan ook zoveel mogelijk van het product te weten. Hoe jouw functies de rest van het product beïnvloeden, moet altijd overwogen worden.

Begrijp de kosten van wat je vraagt

Ik gruwel altijd namens het ontwikkelteam wanneer ik reacties hoor als, "nou, we zouden of X kunnen doen, of, we zouden Y kunnen doen" gevolgd door een uitleg van elk. Het probleem is dat X $10 aan engineeringtijd kost en Y $10.000.000. Als je ze in dezelfde zin plaatst, creëer je een reputatie dat je de implicaties van jouw verzoeken niet begrijpt.

Aan de andere kant betekent samenwerken met je ontwikkelteam om die kostenanalyse te maken voordat je iets presenteert, of zelfs diezelfde zin herformuleren naar "hé, ik heb na het praten met XYZ-klanten over enkele concepten nagedacht. Kan ik ze aan je voorleggen om te zien wat het betekent vanuit een ontwikkelperspectief?" Perfect. Nu krijg je in ieder geval een schatting van de implicaties van wat je vraagt, en je kunt dat gebruiken in je beschrijving van de functie: "Ik weet dat dit een dure vraag zal zijn, maar ik denk dat we het nodig hebben om deze redenen...".

Krijg je ontwikkelteams terug

Je klantgerichte teams zullen voor altijd een lijst met verzoeken voor het product hebben. Soms zijn ze geweldig, omdat ze goed doordacht zijn en reflectief van jouw ICP, en soms is het verzoek iets dat ze gewoon een keer eerder die ochtend hebben gehoord :).

Wil je beste vrienden worden met je ontwikkelteam? Zeg dit: "hé, vertel alsjeblieft aan onze verkoop- en ondersteunings- en dienstenteams dat ze alle productfeedbackverzoeken via mij moeten doorsturen. Ik ga ze catalogiseren en volgen welke klanten om welke dingen vragen, zodat we een duidelijk begrip hebben van wat onze prioriteiten zouden moeten zijn." Je doet hier een paar dingen. (1) afhankelijk van het bedrijf, je hebt misschien een aanzienlijke hoeveelheid tijd van je ontwikkelaars vrijgemaakt, en ze kunnen je bier kopen, en (2) je laat zien dat je een proces hebt voor het prioriteren van productfuncties.

Verdien geloofwaardigheid bij het ontwikkelteam

Niets haalt een PM sneller naar beneden dan wanneer het ontwikkelteam denkt dat ze niet weten wat ze doen. Tenslotte, als PM ben jij verantwoordelijk voor de roadmap van je product en ben je verantwoordelijk voor het prioriteren van wat eraan wordt gewerkt.

Bekijk deze lijst hierboven. Doe deze dingen, en je ontwikkelteam zal je respecteren. Wanneer je de volgende set functies met hen beoordeelt, zullen ze je uitdagen, zoals je zou moeten. Als je antwoorden allemaal zijn onderbouwd met klantgesprekken, marktonderzoek, en een doordachte uitleg van trade-offs om de beslissing die je hebt genomen te krijgen, ontvang je instemmende knikken en een gemotiveerd team dat klaar is om uit te voeren. Als je antwoorden meningen zijn onderbouwd door een artikel dat je gisteravond hebt gelezen, veel geluk :).

In het begin van je bedrijf zal een van de oprichters de Productmanager zijn. Hun mede-oprichter zal vaak de CTO zijn. Alles wat ik net heb uiteengezet is dezelfde manier waarop oprichters ook over hun product denken. Ik heb mensen ooit zien beschrijven dat PM's de "CEO van hun product" zijn en ik denk dat dat klopt. Naarmate je bedrijf groeit, zul je uiteindelijk PM's aannemen. Dit is een belangrijke overdracht, en het volgen van deze richtlijnen zal je helpen succesvol te zijn, zowel met je mede-oprichter als met je ontwikkelteam.