Skip to main content

De specifieke rol van een productmanager verschilt van bedrijf tot bedrijf. Toch moeten alle productmanagers veel aspecten van hun werk in balans houden, waaronder de behoeften van klanten, een visie voor nieuwe producten en het projectteam. Dus welke hulpmiddelen en strategieën zijn nodig om een succesvolle carrière als productmanager op te bouwen? Wat zijn de “5 dingen die je nodig hebt om een succesvolle carrière als productmanager op te bouwen”? In deze interviewreeks praten we met productmanagers, oprichters en auteurs die deze vragen kunnen beantwoorden met verhalen en inzichten uit hun ervaringen. In het kader van deze serie hadden we het genoegen om te spreken met Diego Schmunis.

Photo of Diego Schmunis

Diego Schmunis

Diego is eenveteraan in de technologie- en productsector met 20 jaar ervaring bij uiteenlopende start-ups. Hij werkt graag samen met managementteams om te helpen bij het creëren en realiseren van de productvisie, -strategie en -uitvoering. Momenteel is hij productmanager bij een start-up in stealth-modus, gesteund door Redesign Health.

Hartelijk dank dat je met ons wilt deelnemen aan deze interviewreeks! Onze lezers vinden het fascinerend om de ontwikkeling van iemands carrière te volgen. Kun je een kort overzicht geven van je carrière, vanaf je allereerste baan tot de functie die je nu bekleedt?

Oké, dit kan een lang verhaal worden, maar ik zal proberen het samen te vatten.

Want more from The CPO Club?

Sign up for a free membership to complete reading this article:

Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.

Toen ik naar de universiteit ging om mijn diploma Politicologie te behalen, werkte ik ook als dj in verschillende nachtclubs in San Francisco en draaide ik op privéfeesten. Dat was halverwege de jaren 90, toen desktoppublishing net in opkomst kwam. Elke avond, nadat we de club hadden verlaten, gingen mijn partner en ik naar Kinkos om flyers te ontwerpen voor ons volgende feest. Toen leerde ik voor het eerst met een computer en desktoppublishingsoftware werken. Niet lang daarna zag mijn moeder, heel verstandig, in dat computers en computervaardigheden belangrijke vaardigheden zouden zijn om te hebben. Ze kocht mijn eerste computer voor me (een Apple Quadra 650). Daarna besteedde ik elke vrije minuut aan het leren gebruiken ervan en aan het leren kennen van zoveel mogelijk programma’s.

Ongeveer twee jaar later sprak mijn beste vriend me aan en zei: “Diego, ik zie hoeveel plezier je beleeft aan het werken met computers en het leren gebruiken van verschillende software. Zou je bij een softwarebedrijf willen werken—een kijkje achter de schermen willen nemen en willen leren wat ervoor nodig is om ze te maken? Ik heb een vriend die leiding geeft aan een QA-team en testers zoekt.” Hij zei dat ze me drie maaltijden per dag zouden geven EN me zouden betalen! Wauw! Echt? Jullie gaan me voeren EN betalen om videogames te spelen? Schrijf me in! (Dit bleek een baan te zijn bij Imagination Networks, dat was voortgekomen uit Sierra Online en waarschijnlijk het eerste echt onlinevideogamebedrijf was. Uiteindelijk werden we overgenomen door AOL.)

De meeste productleiders met wie ik heb gesproken, zijn min of meer “in” productmanagement gerold en gepassioneerd geraakt door het vak. Wat was de belangrijkste gebeurtenis in je leven die je op dit pad bracht?

Na mijn werk bij Imagination Networks en AOL ging ik tijdens de dotcomhausse (vóór de zeepbel barstte) bij een paar andere start-ups werken, terwijl ik opklom binnen QA.

Rond 2009 begon dezelfde vriend die me aan de baan bij Imagination Networks had geholpen, een nieuwe afdeling binnen een bekend en gevestigd zoekmachinebedrijf. Hij zocht nog een paar mensen voor het QA-team en bood me een functie aan. Tegen die tijd was ik bij mijn vorige start-up opgeklommen tot QA-directeur en begon ik het gevoel te krijgen dat ik op een punt in mijn carrière was beland waarop ik een stap moest zetten als ik wilde blijven leren en groeien.

Voor mij waren er twee opties: technischer worden en ontwikkelaar worden, of naar productmanagement gaan. Ik koos voor productmanagement.

Daar waren twee redenen voor. Ten eerste had ik een paar jaar eerder een tweejarige opleiding grafisch ontwerp en multimedia gevolgd. Hoewel ik geen ontwerper wilde worden, beschouwde ik mezelf altijd als iemand die visueel en creatief denkt, en wilde ik een rol waarin ik die creativiteit kon inzetten in combinatie met kritisch denken. De tweede reden was dat ik vanuit QA-perspectief altijd het gevoel had dat we in die rol aan het einde van de lijn stonden. Tenzij we een reden konden vinden en overtuigend konden onderbouwen waarom het product nog niet klaar was voor de release, ging het rechtstreeks naar productie. Ik had sterke ideeën over gebruiksvriendelijkheid en ontwerp en over hoe producten beter geïmplementeerd konden worden. Dus waarom zou ik niet van het einde van de lijn naar het allerbegin springen?

Ik ben dus niet zozeer “in” productmanagement gerold. Het was eerder een bewuste, geplande en weloverwogen beslissing, waarvoor veel hard werk en gedrevenheid nodig waren. Ik ben de mensen die me een kans gaven en me mijn eerste rol als PM bezorgden, erg dankbaar.

Ik heb vaak gehoord van mensen die als productmanager werken dat het lastig is om aan familie en vrienden uit te leggen wat ze doen. Wat zeg je wanneer iemand vraagt: “Wat doe je eigenlijk voor werk?”

Mag ik een zin van Liam Neeson uit de film Taken gebruiken? “Wat ik heb, is een heel specifieke reeks vaardigheden. Vaardigheden die ik gedurende een zeer lange carrière heb verworven. Vaardigheden die mij voor mensen zoals jij tot een droom-PM maken.” Oké, laten we nu serieus worden!

Op de een of andere manier leek het voor mij nooit zo moeilijk om uit te leggen wat ik voor de kost doe (misschien heb ik gewoon heel aardige, ondersteunende en liegende vrienden en familie die dachten dat het mijn gevoelens zou kwetsen als ze het niet begrepen?).

De uitleg die ik geef, is in de loop der jaren zeker geëvolueerd naarmate mijn baan en carrière zijn gegroeid en veranderd.

In het begin zei ik meestal iets in de trant van: “Ik vertel ontwerpers en programmeurs hoe het softwareproduct eruit moet zien en werken.” (Merk op dat er nog geen bewustzijn is van de gebruiker of van de noodzaak tot samenwerking). Na een paar jaar en wat meer ervaring begon ik mijn werk als volgt te beschrijven: “Het is mijn taak om de behoeften en visie van het bedrijf te begrijpen en ideeën te bedenken over hoe ik het bedrijf kan helpen zijn doelen te bereiken en omzet te genereren. Ik schrijf de vereisten en bespreek die vervolgens met ontwerpers en engineers om ervoor te zorgen dat voor hen duidelijk is wat er wordt verwacht.”

Oké, mijn begrip van mijn rol begint zich in de juiste richting te ontwikkelen. Ik ben me ervan bewust dat ik niet zomaar elk product kan bouwen. Dat ik moet helpen bouwen aan een waardevolle uitkomst. Ik begon ook te begrijpen dat productontwikkeling een teamsport is en dat ik andere teams nodig heb om de doelstellingen te bereiken. Toch is er nog zoveel ruimte voor groei en verbetering.

Op een gegeven moment drong het tot me door dat het niet uitmaakte hoe goed mijn team en ik het product vonden: als niemand het kocht, faalden we nog steeds. Vanuit dat perspectief begon ik het ongeveer zo te zeggen: “Het is mijn taak om de behoeften (niet per se de wensen) van onze gebruikers te begrijpen en te bepalen hoe we daar met onze producten het beste op kunnen inspelen, op een manier waarbij we door het oplossen van het probleem van een gebruiker het bedrijf ook dichter bij zijn visie en doelen brengen. Ik werk samen met een brede groep teams, van ontwerp en engineering tot sales en marketing; ik verzamel input uit verschillende bronnen, zoek naar overeenstemming en help vervolgens de productteams bij het plannen van onze uitvoering om deze oplossingen op de markt te brengen.” Nu beginnen de zaken beter op hun plaats te vallen. Er is bewustzijn van en empathie voor de gebruiker, het besef dat de doelstellingen van het bedrijf in het proces moeten worden behaald en het inzicht dat productontwikkeling een hands-on teamsport is waarbij mensen direct met elkaar samenwerken, en dat ik alleen dingen kan bereiken via en dankzij alle andere teams in de organisatie.

Nu ik wat meer ervaring heb opgedaan, wat wijzer ben geworden en behoorlijk wat meer grijze haren heb, heb ik wat ik doe als volgt samengevat: “Ik ben een probleemmanager en probleemoplosser. Ik help problemen voor onze gebruikers en ons bedrijf op te lossen. Ik bereik dit door samen te werken met en voor verschillende teams en belanghebbenden in mijn organisatie. Ik ben de facilitator en ondersteuner die de teams die het product daadwerkelijk bouwen in staat stelt effectief en met volledige focus te werken, zodat we onze gezamenlijke resultaten en doelen kunnen bereiken.”

Gelukkig heb ik mijn andere “set vaardigheden” nooit hoeven gebruiken.

Laten we doen alsof geld en sociale status niet bestaan — wat is voor jou het belangrijkste aan je werk? Wat is de Noordster in je carrière?

Makelaars hebben een gezegde dat ongeveer zo gaat: “Locatie, locatie, LOCATIE!”

Voor mij is het: “team, Team, TEAM!”

Ik geloof niet dat producten slagen of mislukken. Ik geloof dat teams dat doen. En iets wat eraan bijdraagt dat teams succesvol kunnen zijn, is de cultuur en het leiderschap van de hele organisatie.

Een ander gezegde van durfkapitalisten bij het beoordelen van investeringsmogelijkheden is: “We investeren liever in een A-team met een B-idee dan in een A-idee met een B-team.” 

Het mislukken van een product is meestal een uiting van hoe goed een groep individuen erin slaagt samen te komen om samen te werken, van mening te verschillen, zich te committeren, overeenstemming te bereiken en samen in één richting te bewegen.

Om een zin uit een van mijn favoriete films te gebruiken: “De echte magie zit in het samen laten werken van vier sterke soloacts.” (Ik geef je een hint om de film te raden: ik bestudeer close-upgoochelen).

Sterke individuele medewerkers zijn zeker een essentieel ingrediënt, maar zelfs de sterkste en slimste individuen ter wereld zijn van geen nut voor jou, je gebruikers of je bedrijf als ze niet goed kunnen samenwerken.

Voor mij begint en eindigt het dus allemaal met sterke teams die daadwerkelijk in staat worden gesteld en de macht krijgen van een sterke cultuur en een ondersteunend, zorgzaam en betrokken leiderschapsteam.

Kun je me een verhaal uit je professionele ervaring vertellen dat je een beetje emotioneel maakt — een moment waarop je wist dat je in het juiste vakgebied zat?

Wacht! Is dit niet zo’n moment met een verborgen camera waarop je me in het openbaar aan het huilen probeert te krijgen?

Ik heb niet echt één ervaring die meteen in me opkomt als het bepalende moment waarop ik wist dat ik de juiste carrière had gekozen. Maar ik moet zeggen dat wanneer ik de kans krijg om tijd met mijn klanten door te brengen en hun gezichten te zien oplichten wanneer we hun ons product laten zien — en je ziet dat ze beginnen te begrijpen hoe het hun leven zal verbeteren of een specifiek probleem kan oplossen waar ze mee kampten — ik dat warme, voldane gevoel krijg dat ik waarde toevoeg aan de wereld en iemands leven een beetje beter help te maken!

Welke eigenschappen maken volgens jou iemand geschikt voor productmanagement? En omgekeerd: welke eigenschappen zouden je doen aarzelen om dit beroep aan te raden?

Voortbordurend op de vorige vraag en het vorige antwoord, heb ik de behoefte om nogmaals te benadrukken dat er geen universele set eigenschappen bestaat die iemand wel of niet geschikt maakt als productmanager. Het hangt af van het ervaringsniveau van de kandidaat en van wat een bedrijf met de rol wil doen en hoe het die wil inzetten. 

Dat gezegd hebbende, volgen hier enkele algemene eigenschappen die kunnen aangeven of iemand al dan niet goed geschikt zou zijn voor een algemene rol als PM.

Laten we beginnen met enkele beschrijvingen:

  • Het typische venndiagram dat wordt gebruikt om productmanagers weer te geven, plaatst ons op het snijvlak van gebruikerservaring, technologie en bedrijfsvoering, maar ik vind echt dat dit een oversimplificatie is. 
  • Productmanagement is in de kern de kunst en wetenschap van het beheren en oplossen van problemen.
  • Een veelgehoorde uitspraak is: “We hebben alle verantwoordelijkheid, maar geen enkele macht.”
  • Hier is mijn beschrijving van hoe het voelt om productmanager te zijn: “Het is alsof je midden in een orkaan van categorie 5 staat terwijl je als een bezetene peddelt.”

Je hebt dus eigenlijk voortdurend duizend dingen met grote snelheid en kracht om je heen vliegen, krachtig genoeg om je hoofd er zo af te rukken. Hoe overleef je dat?

Ten eerste moet je je comfortabel voelen bij chaos en ambiguïteit. Vooral bij start-ups die zich nog in een zeer vroeg stadium bevinden. Hier kom je niet omheen. Maar hoewel je je comfortabel moet voelen bij chaos en ambiguïteit, moet je in staat zijn om beste praktijken en processen voor productontwikkeling te implementeren om enige methodiek in de chaos aan te brengen. Omdat je je ook comfortabel moet voelen bij ambiguïteit, moet je er altijd naar streven om de ambiguïteit op te lossen en antwoorden te vinden. Ambiguïteit leidt tot het bouwen van slechte producten. Punt uit. Je moet veel tijd besteden aan het begrijpen van problemen, het zoeken naar duidelijkheid en het vinden van manieren om inzichten, behoeften en vereisten rechtstreeks en duidelijk met andere teams binnen de organisatie te communiceren. En dit is uitdagend, want zoals het gezegde luidt, heeft een productmanager “alle verantwoordelijkheid en geen enkele macht.” Je moet dus het vertrouwen van anderen in jou en in je beslissingen kunnen winnen, zodat ze met je mee willen gaan op een reis en hard willen werken om het hele team succesvol te maken.

Ik gebruik meestal drie analogieën om de kernfuncties van een PM te beschrijven:

  • Je bent een architect: je moet kunnen visualiseren hoe het resultaat eruit moet zien en moet werken, en de visie (het WAT en het WAAROM) heel duidelijk kunnen verwoorden aan je bouwploeg (ontwerp en techniek), die het product mag bouwen dat jij alleen kunt visualiseren.
  • Je bent een luchtverkeersleider: een deel van je werk bestaat uit het beheren van voortdurend concurrerende prioriteiten, veranderende vereisten, een gebrek aan middelen en alle andere uitdagingen die zich doorgaans voordoen tijdens het bouwen van producten, en ervoor zorgen dat iedereen een duidelijk pad voor zich heeft zodat ze veilig kunnen landen.
  • Je bent een orkestdirigent: PM's bouwen zelf eigenlijk geen producten. Dat doen ontwerp en techniek. Maar het is onze taak om ervoor te zorgen dat elk onderdeel van het orkest (d.w.z. elk team) optimaal klinkt en presteert, en dat ze vervolgens als een geheel goed klinken en samenwerken. Als je je werk goed hebt gedaan, zou je team geen slag mogen missen als je op de avond van de première door de spreekwoordelijke bus wordt overreden. De voorstelling moet doorgaan!

Samengevat: een PM moet van problemen houden en zich comfortabel voelen bij ambiguïteit. In staat zijn om methodiek in de chaos aan te brengen. Een geweldige communicator en facilitator zijn. Nederig zijn en empathie hebben voor je gebruikers en je teams. Een geweldige dienende leider zijn. Alles doen wat je kunt om de mensen om je heen succesvol te maken. We slagen dankzij onze teams, niet dankzij ÉÉN persoon.

Aan de andere kant zijn de weinige eigenschappen waarvan ik vind dat ze niet bijdragen aan een sterke productmanager een gebrek aan nederigheid en empathie (bijvoorbeeld arrogantie en de behoefte om altijd gelijk te hebben). Meer geïnteresseerd zijn in het bouwen van oplossingen dan in het eerst begrijpen van het probleem (dit zie ik vrij vaak: teams die vijf minuten over het probleem praten en vervolgens meteen aan oplossingen beginnen — om Einstein te citeren: “Als ik een uur had om een probleem op te lossen, zou ik 55 minuten besteden aan nadenken over het probleem en vijf minuten aan nadenken over oplossingen.”). Geloven dat je altijd alle antwoorden moet hebben en altijd gelijk moet hebben. Dat zal niet zo zijn. En succesvol producten bouwen is een teamsport met veel direct contact — denk aan rugby, niet aan golf!

Als je denkt aan het sterkste team waarmee je ooit hebt gewerkt, waarom denk je dan dat het team zo goed samenwerkte, en kun je je een anekdote herinneren die de dynamiek illustreert?

Dit is hetzelfde als aan een vader met meerdere kinderen vragen welke zijn favoriet is! Gelukkig heb ik maar één kind.

Ik heb met veel teams gewerkt en ik heb echt van elk team genoten. De reden waarom ik er niet één boven alle andere kan verkiezen, is dat elk team uniek was, onder unieke omstandigheden werkte en mij een unieke reeks ervaringen, inzichten en groeimogelijkheden heeft geboden. Ik heb van elk van hen zoveel geleerd dat het volkomen oneerlijk zou zijn om ze met elkaar te vergelijken en te zeggen dat het ene beter was dan het andere.

Natuurlijk hadden sommige teams wat meer hoogte- en dieptepunten, kronkels en wendingen dan andere. Bij sommige was een stevigere aanpak van het leiderschap nodig en sommige waren wat volwassener en werkten beter samen.

Er zijn veel dingen die teams wel of niet succesvol maken, en dat zou op zichzelf al een boek of een heel ander interview kunnen vullen. Nu we het toch over boeken hebben: als ik zou moeten samenvatten wat volgens mij de beste teams kenmerkt, dan sluit ik me aan bij wat auteur Patrick Lencioni schreef in zijn boek: De vijf frustraties van teamwork (ik kan dit boek niet genoeg aanbevelen. Mijn moeder kocht in 2013 een exemplaar voor me en sindsdien lees ik het elk jaar):

·   Gebrek aan vertrouwen

·   Angst voor conflicten

·   Gebrek aan betrokkenheid

·   Het ontlopen van verantwoordelijkheid

·   Geen aandacht voor resultaten

De beste teams waarmee ik heb gewerkt, bestonden uit mensen met een hoge emotionele intelligentie. We pasten allemaal gezamenlijk psychologische veiligheid toe en streefden ernaar ons bewust te zijn van deze disfuncties, evenals van onze toewijding aan het team en aan elkaar om hard te werken aan verbetering daarvan.

Veel theorie over projectmanagement richt zich op frameworks en methodologieën. Kun je een situatie beschrijven waarin je hiermee te maken hebt gehad en deze zaken terzijde moest schuiven om met een unieke oplossing voor een probleem te komen?

Bij elk bedrijf waar ik als productmanager heb gewerkt! Hoewel het misschien lijkt alsof twee bedrijven die in dezelfde sector actief zijn, zich op dezelfde klant richten en zeer vergelijkbare oplossingen bieden hetzelfde zijn, realiseer je je bij nadere beschouwing dat dit niet zo is. Ze kunnen zich op enigszins verschillende punten in hun groeitraject en ontwikkeling bevinden. Ze kunnen verschillende bedrijfsmodellen hebben en natuurlijk hebben ze zeer verschillende teams, culturen en leiders. Wat voor het ene bedrijf werkt, zal hoogstwaarschijnlijk niet voor het andere werken. Als het om frameworks en methodologieën gaat, bestaat er geen universele oplossing. Kijk maar naar alle bedrijven die probeerden het model van Spotify met gildes en squads te implementeren en daar volledig in faalden. Waarom faalden ze? Omdat ze Spotify niet waren.

Ik geloof sterk in processen. Ik geloof dat processen een groep individuen helpen om effectief samen te werken (Teams! Weet je nog?) om een gemeenschappelijk doel te bereiken. Een proces is de manier waarop we dingen voor elkaar krijgen. Bureaucratie is een proces dat het voor elkaar krijgen van dingen in de weg staat.

Maar je moet de processen, frameworks en methodologieën aanpassen aan het team. Niet andersom. Als je een team probeert te dwingen een methodologie over te nemen, kun je op korte termijn enige vooruitgang boeken, maar uiteindelijk eindig je net als die bedrijven die het model van Spotify probeerden te kopiëren.

Je bedrijf, je producten en je mensen zijn uniek, en ze verdienen het om deel te nemen aan het bedenken, definiëren en implementeren van de processen waarbinnen ze moeten werken. En ze moeten de vrijheid en flexibiliteit krijgen om deze processen te blijven aanpassen, wijzigen en verbeteren wanneer ze niet meer werken. Of ze allemaal overboord te gooien en opnieuw te beginnen.

Wat zijn volgens jou de “5 dingen die je nodig hebt om een succesvolle carrière als productmanager op te bouwen” en waarom?

1 . Nederigheid: De beste producten worden niet door één persoon gebouwd. Hoe visionair of geniaal je als ondernemer ook bent (waarschijnlijk denk je dat zelf ook), geweldige producten worden gebouwd door geweldige teams. Zelfs bij de meest individuele sporten (zoals ultramarathonlopen of golf) is er altijd een team van getalenteerde en ondersteunende mensen dat met hun liefde, zweet en tranen bijdraagt aan een succesvol resultaat. De beste productmanagers weten en begrijpen dat productontwikkeling een praktische teamsport is, en ze weten dat de beste manier om de beste producten te bouwen is om samen te werken met een team dat uiteenlopende ideeën en perspectieven inbrengt, zodat groepsbias wordt voorkomen en uiteindelijk het beste idee wordt uitgevoerd, niet het idee dat de productmanager zelf bedacht. De beste en meest invloedrijke productmanagers laten hun ego bij de deur achter en verwachten hetzelfde van iedereen in hun teams.

2 . Empathie: Klanten willen ons niet per se betalen om oplossingen te bouwen die wij leuk vinden of waarvan wij denken dat ze het beste zijn (er is een oud gezegde: “word verliefd op het probleem, niet op de oplossing”). Klanten betalen ons om hun problemen op te lossen. Probeer een potentiële klant te vragen je geld te geven voor “jouw” ideeën of oplossingen en kijk hoe snel die klant met zijn geld vertrekt. Vertel een klant nu eens, of nog beter, laat hem of haar zien hoe jouw oplossing zijn of haar probleem direct, eenvoudig en effectief oplost tegen een aantrekkelijke prijs. Waarschijnlijk zul je, als je andere klanten zoals deze kunt vinden, moeite hebben om de binnenkomende bestellingen bij te houden. Net als bij het bovenstaande punt over de noodzaak om nederig te zijn tegenover je team, moet je ook een sterk gevoel van empathie hebben voor je toekomstige gebruikers. Geef oprecht en diep om hen en om de uitdagingen en moeilijkheden die ze in hun dagelijks leven tegenkomen. Net zoals de beste acteurs hun personages worden om hen nauwkeurig te vertolken, moet je ernaar streven dingen vanuit het perspectief van je klant te zien en te voelen.

3 . Openheid: Een van de meest voorkomende fouten die ik productmanagers zie maken, evenals andere teams die samenwerken aan productontwikkeling, is dat ze te snel en te vroeg naar oplossingen springen, een veelbelovend idee tegenkomen en vervolgens voluit gaan bij het definiëren van de vereisten en alle details ervan, zonder voldoende tijd, moeite en aandacht te besteden aan andere alternatieven en de bijbehorende afwegingen. Zoals het gezegde luidt: “Er is meer dan één manier om een kat te villen”, maar als je je beslissing al hebt genomen en als het ware oogkleppen hebt opgezet, mis je alle andere manieren waarop je het probleem zou kunnen benaderen. Open-minded zijn hangt ook nauw samen met de eerste waarde, nederigheid, en met het besef dat het feit dat je de productmanager bent niet betekent dat alle ideeën (goede en/of slechte) van jou moeten komen. Geweldige ideeën kunnen, net als leiderschap, overal en van iedereen komen. Alleen een open en nederige geest kan dit mogelijk maken.

4 . Liefde voor problemen: Zeg het hardop: IK HOU VAN PROBLEMEN, IK HOU VAN PROBLEMEN, IK HOU VAN PROBLEMEN! Onze functietitel is misschien productmanager, maar in de kern is productmanagement de kunst en wetenschap van probleembeheer en probleemoplossing. Als het je niets kan schelen om diep in de problemen te duiken waarmee je klanten worden geconfronteerd, verwacht dan niet dat je klanten van je producten en oplossingen zullen houden — laat staan ervoor zullen betalen. Onlangs hoorde ik tijdens een TED-talk het volgende citaat van keynote-spreker en goochelaar Vinh Giang: “Magie is gewoon een probleem dat je niet kunt oplossen.” Ik denk dat dit volledig van toepassing is op productmanagement. Een van onze doelstellingen zou moeten zijn om magische ervaringen te creëren voor de mensen die onze producten en oplossingen gebruiken. Om dat te doen, moeten we beginnen met het volledig omarmen van en plezier beleven aan het probleemgebied.

5. Stel geweldige vragen: “We hebben twee oren en één mond, zodat we twee keer zoveel kunnen luisteren als we spreken.” Dit citaat van de beroemde stoïcijnse filosoof Epictetus wijst ons op het belang van luisteren naar anderen wanneer zij over hun problemen en moeilijkheden praten, zodat we empathie voor hen kunnen ontwikkelen. Dat zal ons er, dankzij onze gezamenlijke teamnederigheid, ruimdenkendheid en liefde voor de problemen van klanten, toe brengen magische oplossingen te creëren. De uitdaging is dat klanten soms niet precies weten wat ze nodig hebben (een belangrijke vaardigheid voor een productmanager is het kunnen onderscheiden en scheiden van, en klanten soms kunnen bijbrengen over, hun wensen en behoeften, en zich eerst richten op het vervullen van de behoeften).

Zoals Steve Jobs ooit zei: “Mensen weten niet wat ze willen totdat je het hun laat zien.” De weg die we moeten bewandelen om te ontdekken wat klanten nodig hebben, loopt dus via het leren stellen van geweldige vragen. Wat is een geweldige vraag? Dat is op zichzelf al een geweldige vraag. Maar ik zal dit zeggen: over het algemeen is een geweldige vraag er een die ten eerste open is. Een vraag die twee of meer mensen in staat stelt een open, eerlijk en ruimdenkend gesprek te voeren. Het is ook een vraag die bij elk antwoord dat zij oplevert, 3–5 vervolgvragen en enkele zijpaden oproept om te verkennen. Geweldige vragen helpen ons niet alleen de problemen van onze klanten tot in detail beter te begrijpen, maar vormen ook het zaadje waaruit een diepgaand begrip ontstaat, wat leidt tot betere ideeën en oplossingen.

Als je een beweging zou kunnen inspireren die de grootste hoeveelheid goeds voor het grootst mogelijke aantal mensen zou brengen, wat zou dat dan zijn? Je weet nooit wat jouw idee in gang kan zetten.

Ik citeer een van mijn favoriete stoïcijnse figuren, Marcus Aurelius: “Verspil geen tijd meer aan het beargumenteren wat een goed mens zou moeten zijn. Wees er een.” Wees een goed mens. Wees nederig en empathisch. Zorg voor anderen, je gebruikers en je team.

Denk aan degenen die vóór jou kwamen, degenen die in je geloofden en je kansen gaven om te leren en te groeien, en die je vergaven wanneer je fouten maakte, zodat je iemand kunt helpen wanneer je iemand tegenkomt die net aan het begin van het leven of een carrière staat. Geef het goede door.

Abonneer je op de nieuwsbrief van The CPO Club voor meer interviews zoals deze.