Mensgedreven productontwikkeling (met Sam Higham van Glean)

Michael Luchen

Als praktiserende of aspirant-productmanagers worden we voortdurend overspoeld met certificeringen en gespecialiseerde trainingen waarvan ons wordt verteld dat ze essentieel zijn voor ons vak. Het volgen van een afgestemd proces om producten te ontwikkelen is de sleutel tot succes, zo wordt ons verteld. Blijf luisteren, want vandaag duiken we diep in dit onderwerp. Zijn certificeringen en afgestemde processen echt zo noodzakelijk als ze lijken? Of is er iets beters?

Dit is de podcast van The CPO Club, de stemmen van een community die het handboek voor productmanagement, productontwikkeling en strategie schrijft. We worden gesponsord door Crema, een digitaal productbureau dat individuen en bedrijven helpt floreren door creativiteit, technologie en cultuur. Lees meer op crema.us. Blijf luisteren voor praktische, authentieke inzichten die je helpen succesvol te zijn in de wereld van productmanagement.

Het onderwerp van vandaag ligt mij en productmanagement na aan het hart. Ik ben dan ook vereerd om Sam Higham in de show te mogen verwelkomen om hierover te praten. Sam is een gebruikersgerichte productleider met een bewezen carrière in het ten goede veranderen van producten, processen en mensen. Hij gedijt zowel in de details als in de richtinggevende aspecten van het laten werken van producten, van hun functionele basis tot de commerciële verwachtingen die ze waarmaken.

Sam heeft een grenzeloze interesse in de manier waarop technologie en psychologie op elkaar inwerken tijdens klantreizen. Hij helpt teams manieren te vinden om die twee samen te brengen en te verfijnen, zodat de best mogelijke resultaten worden bereikt. Sam is vicepresident Product bij Glean, een oplossing voor notities maken ten behoeve van leren en productiviteit.

De oplossing van Glean voor het maken van notities neemt audio-opnamen op, zodat je informatie effectiever kunt vastleggen en ervan kunt leren. Sam werkt daarnaast parttime als productcoach en trainer in productmanagement voor Mind the Product, waar hij mensen helpt bij het uitstippelen van het loopbaanpad in productmanagement dat zij willen volgen.

Hoi Sam! Welkom bij de show.

Sam Higham

Hoi, bedankt voor de uitnodiging.

Michael Luchen

Fijn dat je er bent. Om te beginnen: kun je vertellen hoe je bent gekomen waar je vandaag bent?

Sam Higham

Ja, zeker. Kort gezegd: door veel vallen en opstaan. Ik denk dat ik, net als veel mensen in productmanagement, de afgelopen tien jaar min of meer in productmanagement ben gerold.

Ik denk dat ik vrijwel elke rol heb vervuld die je op het gebied van productontwikkeling kunt vervullen, behalve programmeren. En zelfs toen heb ik in het verleden mijn hand gewaagd aan behoorlijk slechte API's. Dus ja, ik ben ongeveer acht jaar geleden formeel in een centrum voor productmanagement gaan werken, hoewel dat niet de officiële functietitel was.

In die periode heb ik voortdurend geprobeerd te verfijnen wat het betekent om iemand in productmanagement te zijn en hoe je dagelijks beter kunt worden. Veel daarvan kwam neer op de vraag: wat is productmanagement eigenlijk? En eerlijk gezegd stel ik mezelf die vraag nog steeds elke dag.

Michael Luchen

Ja, wat is het? Het is inderdaad een behoorlijk grote vraag.

Sam Higham

Voor mij komt het erop neer dat je de beste manier probeert te vinden om waarde te creëren, gegeven de context waarin je je bevindt, de beperkingen die je hebt en de mensen met wie je werkt. Ik denk dat de zeer zuivere benadering van productmanagement fantastisch is, maar dat die niet altijd rekening houdt met de omstandigheden van de 95 procent of meer van de organisaties die niet alles hebben wat nodig is om het volgens het boekje te doen.

Daar komt een deel van de uitdaging vandaan. Er is veel geweldige, ambitieuze informatie die zegt: zo kun je productmanagement uitvoeren in een perfecte laboratoriumomgeving. Maar niemand van ons werkt echt in zo'n situatie. En maar heel weinig van ons hebben de financiering die nodig is om al deze end-to-endbenaderingen op de perfecte manier toe te passen.

Veel ervan draait daarom om iteratieve ontwikkeling. Daarbij gaat het niet alleen om iteratieve ontwikkeling in de softwarematige betekenis, maar ook om iteratie in het proces en in de manier waarop je samenwerkt. Alles wordt voortdurend heen en weer aangepast.

Michael Luchen

Interessant. Je zegt dus dat veel van de documentatie en opleiding rond productmanagement draait om: zorg dat je iteratief bent in productontwikkeling. Maar jij zegt ook dat je iteratief moet zijn in het proces en met de mensen, afhankelijk van de omgeving waarin je werkt.

Sam Higham

Ja, precies. Ik denk dat veel daarvan vergeet dat wij als mensen erg rommelig zijn.

We zijn geen perfect samengestelde individuen die alles tot op de letter kunnen volgen. We hebben ook niet allemaal dezelfde kennis. Daarom kan het lastig zijn wanneer je als productpersoon ergens blanco binnenkomt. Ik heb dat zelf ook gedaan. Ik ben in een rol begonnen en zei meteen: oké, we gaan productmanagement beoefenen, dit is het raamwerk dat we gaan gebruiken en alles gaat perfect werken.

Maar ik had nog niet eens rekening gehouden met de vraag of mijn collega's eigenlijk begrepen wat we hier probeerden te bereiken. Begrepen ze wel wat en waarom deze aanpak waardevol kon zijn? Hoe ver stonden we af van het spreken van dezelfde taal? Als je die eerste stap niet zet en niet samen bespreekt wat de beste manier is om dit te doen, mis je iets belangrijks.

Je kunt je eigen ervaringen en technieken meenemen die in het verleden hebben gewerkt en proberen die toe te passen. Maar verwacht niet dat ze zomaar zullen werken. Soms raak je verblind door de gedachte: het werkt bij Google, het werkt bij Amazon, het werkt overal. Zonder jezelf af te vragen: werkt het ook voor ons?

Michael Luchen

Ja. En wat ik echt fascinerend vind, is dat hoe meer ik leer over de interne werking van Google of Amazon, hoe duidelijker het wordt dat veel van de verhalen die we onszelf vertellen waarschijnlijk uit de beginperiode komen, toen zij nog het voorbeeld waren van startups en hoe die werkten.

Maar nu zijn het enorme ondernemingen met ontzettend veel verschillende teams en zelfs binnen die bedrijven veel verschillende manieren van werken.

Sam Higham

Zeker. Dat is een goed punt. Veel mensen praten over de beste ervaringen die ze op start-upniveau hadden. Dat komt volgens mij doordat iedereen daar begrijpt wat je probeert te doen en je het samen probeert uit te zoeken. Je spreekt dezelfde taal en bent bereid heel snel een open gesprek te voeren over wat je kunt doen.

En ik bedoel daarmee niet alleen de mensen in productontwikkeling, ontwerp en techniek. Ik heb het over sales, marketing, operations: iedereen bevindt zich in dezelfde ruimte. Daardoor heb je als organisatie een heel korte feedbacklus. De uitdaging, en het moment waarop processen en raamwerken hun intrede doen, ontstaat wanneer je steeds groter wordt. Dan verlies je dat, omdat iedereen een interne manier van praten over dingen ontwikkelt die het voor andere functies moeilijker maakt om effectief samen te werken.

Je aanpak loopt dan bijna zo ver vooruit op wat anderen van jouw functie begrijpen dat samenwerking moeilijk wordt. Als je niet voortdurend die feedbacklus in stand houdt van: dit proberen we te doen, dit is waarom we deze aanpak kiezen, dan verlies je iets. Plotseling werken sales en product niet meer goed samen, product en techniek niet meer goed samen, en praat iedereen over hoe geweldig zijn eigen functie is in plaats van over hoe geweldig de organisatie samen kan zijn.

Michael Luchen

Dat klinkt als veel werk.

Sam Higham

Dat is het ook. Precies.

Michael Luchen

Ik denk aan onze luisteraars, van wie velen misschien bij grotere organisaties werken die geen startup meer zijn. Hoe begeleid je mensen in zo'n omgeving, waar ze het proces echt moeten verdedigen, maar misschien het gevoel hebben dat daar geen ruimte voor is?

Sam Higham

Begin klein, zoals met alles. Veel goede basisprincipes uit bijvoorbeeld het Agile-manifest zijn volgens mij nog steeds geldig. Begin klein en bedenk wat het meest minimale experiment is dat je als groep binnen je eigen invloedssfeer kunt uitvoeren. Je moet je er ook prettig bij voelen wat wel en niet binnen je invloed ligt.

Soms raak je gefrustreerd wanneer je te veel en te snel probeert te veranderen. Dan kun je de strijd eigenlijk nooit winnen. Je zegt dan: ik heb deze persoon in een podcast horen zeggen dat we allemaal experimenten moeten uitvoeren en effectiever moeten samenwerken, dus dat gaan we doen. In plaats daarvan kun je beter zeggen: stel dat je met één ontwikkelteam werkt, hopelijk een mooi multidisciplinair team met ontwerpers, technici en productmensen. Welke experimenten kunnen we samen uitvoeren om effectiever te worden?

Hoe kunnen we vervolgens een andere functie bij die samenwerking betrekken? Laat door de aanpak te demonstreren zien dat die misschien niet werkt. Misschien werkt het inderdaad niet. Je moet begrijpen waarom het niet werkte en vervolgens die gesprekken aangaan.

Het kost veel moeite en het duurt langer dan je denkt voordat je bij de beste aanpak bent. Maar dat betekent niet dat je niet moet beginnen. De beste tijd om te beginnen is vandaag. Dat is het enige wat je kunt doen.

Michael Luchen

Ik vind de focus op klein beginnen geweldig. Ik heb dat zelf ook succesvol zien werken, vooral bij verschillende klanten die hun eigen producten bouwen. We bewegen voortdurend in en uit omgevingen waarin processen veranderen. We lopen dus steeds tegen dezelfde uitdaging aan. Wat goed werkt, is het probleem echt afbakenen en zeggen: we gaan dit twee weken proberen.

Je verkoopt dan geen manier van werken voor het komende jaar, maar plant er wel de zaadjes voor. Wat je werkelijk verkoopt, is dit experiment van twee weken. Vertrouw ons, laten we het proberen, laten we zien hoe het gaat. Zo kun je waarde aantonen en daarna andere dingen introduceren.

Een ander onderwerp waar we als productmensen veel over praten, is het dragen van een coachingspet. Speelt coaching een rol in het dagelijks succes hiervan?

Sam Higham

Zeker. Voor mij betekent coaching vooral dat je meer vragen stelt dan antwoorden geeft. Op het hoogste niveau gaat het erom hoe we samen antwoorden vinden. Dat doe je meestal door betere vragen te stellen.

Veel van wat ik dagelijks doe, of ik nu met individuen in een team werk of met iemand een echt coachingsgesprek voer, draait om vragen als: welke dingen heb je hier overwogen? Waarom overweeg je die dingen? Heb je andere opties overwogen? Zo ja, waarom heb je deze gekozen? Heb je nagedacht over hoe je andere mensen bij dit proces kunt betrekken? Je probeert mensen de gewoonte aan te leren om die vragen zelf te stellen, aan anderen te stellen en allemaal volgens die aanpak te werken.

Vanuit coaching moet je ook leren om meer de schaduw van succes te zijn dan het middelpunt van de aandacht. Je moet er bijna tevreden mee zijn dat anderen winnen omdat jij vanaf de zijlijn hebt geholpen, zonder zelf te erkennen dat je onderdeel was van het proces. Anders neem je iets weg van hun eigen ontwikkeling.

Als iemand zegt: eigenlijk was dat Sam op de achtergrond, die deze persoon of dit team coachte, dan moet het antwoord zijn: nee, het team heeft het probleem zelf opgelost en zelf die verbetering bereikt. Als het even kan, moet je je eigen bijdrage volledig bagatelliseren. Ik wil bijna niet dat mensen weten dat die gesprekken hebben plaatsgevonden of dat we urenlang verschillende manieren hebben onderzocht waarop een presentatie kon worden gegeven.

Die persoon was eigenaar van de presentatie. Die heeft de presentatie gemaakt en gewonnen. Dat ik misschien een paar vragen heb gesteld die hielpen om daar te komen, is niet relevant.

Michael Luchen

Mooi gezegd. Het werkt ook de andere kant op: mensen door coaching laten falen, zodat ze uit eerste hand leren. Dan denken ze: dat was een heel moeilijke situatie, maar nu weet ik hoe ik er de volgende keer zelfstandig doorheen kom.

Sam Higham

Zeker. Soms zijn we bang om te falen. In organisaties kan een onzichtbare cultuur bestaan waarin falen te hard wordt afgestraft.

Stel dat er een relatief kleine fout in een softwareonderdeel zit. Plotseling gaan er e-mails rond en zegt een van de machtigste leidinggevenden van de organisatie: wanneer wordt dit opgelost? Mijn god, dit is een ramp. Wat je niet beseft, is dat het directe gevolg daarvan is dat mensen bang worden voor elke fout en elke kleine verandering.

Daardoor zijn ze minder bereid risico's te nemen en minder bereid iets nieuws te proberen. Niemand wil degene zijn die publiekelijk wordt aangewezen. Hetzelfde geldt voor ontwerpkritieksessies. Er bestaat een goede praktijk waarbij je ontwerpen vroeg en open laat zien, zodat mensen kunnen samenwerken. Maar als de kritiek overdreven of persoonlijk wordt en rechtstreeks gericht is op de vaardigheden van ontwerpers, zullen zij hun werk minder vaak of minder vroeg laten zien. Dan verlies je de kracht van leren, falen en die manier van denken ontwikkelen.

Als leider moet je je daar zeer bewust van zijn en anderen helpen om dat gedrag te vermijden. Zulke onzichtbare signalen kunnen bijzonder schadelijk zijn wanneer je een positieve mentaliteit wilt creëren waarin mensen bereid zijn iets te proberen en het als een leermogelijkheid zien in plaats van als een mislukking.

Michael Luchen

Goed gezegd. Het zijn de leiders van organisaties die de structuren creëren waarin mensen veilig kunnen falen en van die fouten kunnen leren, in plaats van bang te zijn om te falen en daardoor niets te leren. Dat is waarschijnlijk een van de moeilijkste dingen om te doen. Als leider denk je immers: ik wil niet dat mijn organisatie faalt.

Wat is dan de waarde voor de resultaten van mijn organisatie wanneer ik mijn productmensen hun weg naar die resultaten laat vinden door te falen?

Sam Higham

Hopelijk worden de resultaten zichtbaar. Je ziet teams die zich comfortabel, zelfverzekerd en empowered voelen en proactief zijn. Ze kunnen zeggen: dit experiment hebben we uitgevoerd; het leverde geen duidelijke of het verkeerde resultaat op. Maar daardoor kunnen we nu dit andere doen. Ze zijn actief en uitgesproken over waarom ze deze risico's nemen en wat ze daarvan hebben geleerd.

Het gaat ook echt om snelheid. Wanneer mensen over snelheid praten, bedoelen ze vaak verhaalpunten. Dat bedoel ik niet. Ik bedoel het vermogen van mensen om comfortabel, zelfverzekerd en snel te werken, omdat ze niet bang zijn dat ze een extra goedkeuringslaag moeten doorlopen of drie keer moeten controleren of iedereen toestemming heeft gegeven voor een klein experiment.

Het tegenovergestelde is met je teams bespreken welk niveau van autonomie je wilt geven, wanneer je samen moet praten over doorgaan en wanneer jij nog de verantwoordelijkheid voor de besluitvorming moet dragen. Dat gaat over risico.

Je spreekt af wat de risicobereidheid van de organisatie is en op welk niveau je iets zelfstandig mag beslissen. Als iemand een ingrijpende wijziging in de hele database wil uitvoeren zonder de website af te sluiten, terwijl de kans op mislukken groot is, wil je misschien niet dat het productteam die beslissing zonder jou neemt. Maar als iemand een A/B-experiment met een knop wil uitvoeren voor tien procent van de gebruikers en het ergste dat kan gebeuren een daling van de conversie met 0,01 procent is, dan wil je waarschijnlijk dat het team gewoon doorgaat. De iteratieve verbetering weegt dan ruimschoots op tegen de mogelijke negatieve impact.

Michael Luchen

Bijna een werkafspraak tussen het productteam en de leiders dus.

Sam Higham

Ja. Zelfs dan is er ruimte voor coachingsgesprekken wanneer het risico te hoog of te laag werd ingeschat. Je wilt daar een actief gesprek over voeren en vanwege het risico afspreken dat je de volgende keer even samenkomt om het te bespreken. Het hoeft niet ingewikkelder te zijn dan dat.

Michael Luchen

Over ingewikkeld gesproken: een van de dingen die duidelijk naar voren komen, is hoe ingewikkeld, rommelig en ambigu productmanagement is. Ook uit jouw visie op productontwikkeling blijkt dat er niet één proces of raamwerk is dat alles beheerst.

Ik kan me voorstellen dat een beginnende productmanager denkt: waar moet ik beginnen? Begin ik met een proces, ga ik naar het team of naar de leiders? Wat is mijn kompas en hoe navigeer ik hierin?

Welk advies geef je die persoon?

Sam Higham

Ik kan mijn eigen traject delen. Het kan voor anderen werken, maar misschien ook niet. Zelf leer ik dingen op het laatste verantwoordelijke moment. Toen ik begon als productpersoon, leerde ik letterlijk wat ik moest doen op het moment dat ik het moest doen.

De eerste keer dat ik een presentatie moest geven, leerde ik hoe je een routekaart maakt, welke opties er zijn om die te presenteren en waarom de ene optie beter kan zijn dan de andere. De tweede keer dacht ik: wat heb ik de eerste keer geleerd? Hoe kun je een achterstand prioriteren? Ga vervolgens uitzoeken hoe je een achterstand kunt prioriteren.

Zo leer ik echt. Ik raak snel overweldigd door informatie op te nemen en die vervolgens allemaal te vergeten. Er is een verleiding om twintig boeken over productmanagement te lezen en dan aan te nemen dat je al die informatie op het juiste moment kunt herinneren en toepassen.

Als je dat kunt, geweldig. Doe dat dan vooral. Ik kan het niet. Ik heb geen directe herinnering; ik moet iets oefenen. Ik moet erover leren en uitzoeken of het voor mij werkt. Dat doe ik nog steeds.

Als ik iets nieuws wil proberen, leer ik er op dat moment over. Ik lees nog steeds veel en probeer inspiratie op te doen uit wat anderen doen, maar voor de daadwerkelijke toepassing leer ik het op het laatste verantwoordelijke moment.

Een andere aanpak is een cursus volgen. Daar is niets mis mee. Het is goed om basiskennis te hebben, zolang je niet verwacht dat iets precies zo zal verlopen als je hebt geleerd en je niet star vasthoudt aan wat je in één of twee dagen hebt geleerd.

Dat is een andere manier om te leren, maar het betekent niet dat je meteen weet hoe je het praktisch moet toepassen. We zijn allemaal mensen en werken aan ingewikkelde dingen. Een miljoen externe en interne factoren kunnen ervoor zorgen dat zelfs eenvoudig werk moeilijk wordt.

Michael Luchen

Dat is geweldig. Ik herken dat ook in mijn eigen traject en zie andere productmanagers om me heen floreren wanneer ze zeggen: ik spring er gewoon in en leer door te doen. In ons vak is er zoveel kennis. Als je bijvoorbeeld een routekaart wilt maken, kun je zoeken naar de beste aanpak, met de beschikbare tool gaan experimenteren en kijken wat voor het team werkt en wat niet.

Sam Higham

Zeker. Er is volgens mij geen juiste manier om een routekaart te maken. Sommige manieren zijn misschien iets beter, maar werken mogelijk niet in jouw context. Ik kan gemakkelijk zeggen: gebruik een routekaart met nu, daarna en later, zonder datums, zonder functies en alleen met resultaten. Maar ik wil niet verantwoordelijk zijn wanneer je leidinggevende je vervolgens uitscheldt omdat die zoiets nog nooit heeft gezien en het volledig buiten de gebruikelijke werkwijze valt.

Je moet dus stapsgewijs veranderen. Wat zou ik idealiter willen doen, wat werkt nu voor mij en hoe overbrug ik het gat tussen die twee?

Michael Luchen

Veel van wat we bespreken draait om mensen. Het klinkt alsof je het grotere geheel voor ogen moet houden: niet alleen de resultaten of statistieken die je met het product wilt bereiken, maar ook de langetermijnoptimalisatie van het team waarmee je samenwerkt.

Hoe kan een productmanager daar dagelijks rekening mee houden?

Sam Higham

Een eenvoudige manier, al is niets hiervan eenvoudig, is via retrospectives. Jezelf als team beoordelen is voor mij veel gezonder dan willekeurige cijfers uit een ticketsysteem of beoordelingen door anderen.

Ik heb ook retrospectives en workshops over de gezondheid van teams georganiseerd. Je spreekt dan bijvoorbeeld tien dingen af waarop je als team wilt focussen en bekijkt elk kwartaal of je daarop bent verbeterd of achteruitgegaan. Vervolgens bepaal je wat je gaat doen om dat te veranderen.

Een gewone retrospective richt zich meer op het hier en nu: wat proberen we te doen gezien dit specifieke werk of onze huidige situatie? De gezondheid van het team is breder, meer als een megaretrospective. Je kijkt naar bredere thema's en houdt bij welke richting het team opgaat.

Het team kan zelf bepalen welke onderwerpen in die bredere beoordeling komen en waaraan je kunt zien of het gezond is. Daarnaast draait veel om sociale vaardigheden. Als productpersoon moet je veranderingen in het gedrag van je team opmerken. Misschien krijg je plotseling veel minder interactie over hoe je een kortetermijnvisie voor het product kunt bereiken of een bepaald probleem kunt oplossen.

Denk dan bewust na over wat er veranderd kan zijn en ga met mensen praten. Ga niet alleen vanuit je stoel psychologie bedrijven en aannames doen. Vraag wat er is gebeurd. Misschien heeft iemand zonder dat jij het wist harde feedback gekregen, is er iets misgegaan of speelt er iets externs of intern.

We zijn mensen en communiceren om te overleven en als mensheid iets te creëren. Dat doen we door samen te werken en gemeenschappen te vormen. Ik zie een productteam als een kleine community die zich door de organisatie heen kan uitbreiden.

Michael Luchen

Een productteam als kleine community. Dat is bijzonder. Als ik productmanager ben en oefeningen rond teamgezondheid en retrospectives voorstel, maar mijn leidinggevende vraagt wat de waarde ervan is en zegt dat het tijdverspilling is, hoe ga ik daar dan mee om?

Sam Higham

Ook hier gaat het erom dat je dit openlijk doet. Leg uit waarom je het probeert en welke signalen volgens jullie laten zien of het experiment succesvol is.

Bij teamgezondheid kan behoud van medewerkers een goede indicator zijn. Je kunt mensen ook zelf hun tevredenheid laten beoordelen. Er bestaan veel hulpmiddelen waarmee je wekelijks kunt meten hoe tevreden iemand zich op het werk voelt.

Je kunt ook algemener bespreken hoe het team presteert en welke uitdagingen er zijn. Stel dat werk voortdurend wordt geblokkeerd omdat jullie niet op tijd contact krijgen met de juiste afdelingen. Dan kan de hypothese zijn dat jullie die afdeling vanaf het begin actiever bij de samenwerking betrekken.

Betrek hen bij het plannen van het werk en nodig hen uit voor de wekelijkse demonstraties. Hopelijk zie je dan niet meer op het laatste moment: jullie zijn dat vergeten en nu kunnen jullie de functie niet live zetten, omdat jullie ons niet hebben betrokken.

Open communicatie is altijd gezond. Je kunt de leiding ook vragen wat zij willen zien en hoe zij willen dat je dit meet. Dat kan verkeerd uitpakken als ze bijvoorbeeld willen dat snelheid en verhaalpunten voortdurend stijgen. In dat geval zou ik zeggen: ren de heuvels in. Maar hopelijk kun je een vertrouwelijk gesprek met de leiding voeren en hen dichter bij het probleem brengen.

Dat lijkt op leidinggevenden coachen. Je probeert te begrijpen wat ze willen of waar ze bang voor zijn als jullie dit doen, en hoe je de angst kunt verminderen dat jullie tijd verspillen.

Michael Luchen

Dat coachen naar boven is interessant. Je stelt gewoon die vragen. Soms blijkt dat iemand een fundamenteel misverstand heeft over de waarde van het bijhouden van verhaalpunten voor snelheid. Dan ontstaat er een gesprek.

Als iemand daarna nog steeds zegt dat de cijfers moeten stijgen, is het tijd om de heuvels in te rennen. Als productmanagers hebben we brede, algemene kennis van allerlei processen en hulpmiddelen. We mogen niet aannemen dat belanghebbenden dezelfde kennis hebben.

Sam Higham

Zeker. Begrip en taal vormen soms een groot deel van het probleem, zelfs bij termen als productgestuurd. Als je zegt dat je een productgestuurde cultuur hebt, begrijpen mensen dan dat iedereen samenwerkt om een geweldig product te bouwen dat zichzelf beter verkoopt? Of denken ze dat product de machtigste functie wordt en over alles gaat beslissen?

Zo kunnen mensen zich terugtrekken in hun eigen kastelen, bang worden en over alles gaan strijden. Taal is ontzettend krachtig. Wanneer je niet expliciet maakt wat iets betekent, vullen mensen dat zelf in. Voor je het weet zit je in een gesprek waarin je niet wilde belanden, omdat anderen hun conclusies al hebben getrokken.

Ik ben me er steeds bewuster van welke terminologie ik gebruik, of iedereen die begrijpt en hoe ik iets eenvoudiger kan maken of kan uitleggen wat belangrijk is. Mensen zijn namelijk terughoudend om te zeggen dat ze iets niet begrijpen. Alleen de meest zelfverzekerde mensen vragen in een vergadering: wat bedoel je met productgestuurd? De meesten blijven stil en denken dat ze wel zullen bedoelen wat zij aannemen. Dat kan gevaarlijk zijn.

Michael Luchen

We moeten dus een soort geduldige gids voor iedereen zijn.

Sam Higham

Ja.

Michael Luchen

Een laatste vraag voordat we afronden. Je hebt een prestigieuze rol en een mooie carrière, en daarnaast coach en train je mensen. Je hebt dus een zeer diepgaande kennis van onze sector. Waar gaat productmanagement volgens jou naartoe? Hoe ziet productmanagement er de komende drie jaar uit?

Sam Higham

Ik denk dat het zich wat meer gaat opsplitsen in specialisaties. Productmanagement begon heel breed en betekent voor verschillende mensen heel verschillende dingen. Ik denk dat het wordt verdeeld in meer specifieke soorten productmanagement.

Net zoals je in softwareontwikkeling specialisaties hebt, krijg je subcategorieën van productmensen. Dat kunnen bijvoorbeeld groei, B2B of B2C zijn. Die termen worden al gebruikt, maar we hebben nog niet echt uitgewerkt wat het beste werkt wanneer je een productpersoon voor groei, B2B, B2C, een marktplaats of een ander producttype bent.

Een deel van de bredere opleiding en inhoud die ik nu zie, beweegt in die richting. Ik verwacht dat het uiteindelijk een formele discipline wordt. We vormen inmiddels zo'n grote community van productmensen dat deze specialisaties vanzelf zullen ontstaan.

Michael Luchen

Geweldig.

Voordat we afronden, wil ik graag een paar persoonlijke vragen in een snel rondje stellen, als dat goed is.

Sam Higham

Ja.

Michael Luchen

Welke persoonlijke gewoonte heeft het meest bijgedragen aan je succes?

Sam Higham

Veerkracht. Veel van wat we vandaag hebben besproken gaat over falen. Mensen accepteren falen niet altijd even gemakkelijk en je kunt het zwaar te verduren krijgen wanneer dingen niet goed gaan en er geen veilige omgeving is. Dat staat dus zeker hoog op mijn lijst.

Aanpassingsvermogen is waarschijnlijk een andere eigenschap. Zo leer ik: ik pas me voortdurend aan aan de informatie die ik krijg.

En waarschijnlijk nederigheid. Ik zeg openlijk dat ik de helft van de dingen die ik zou moeten weten niet weet. Ik vertrouw op veel andere mensen die veel beter zijn in wat zij doen, zodat we samen succesvol kunnen zijn. Ik probeer nooit te doen alsof ik de expert ben en alles weet, want dat is niet zo en dat zal waarschijnlijk ook nooit zo zijn.

Michael Luchen

Ik herken de waarde van al die eigenschappen zeker.

Wat is je favoriete hulpmiddel dat je regelmatig gebruikt?

Sam Higham

Miro, of Myra? Ik weet niet hoe je het uitspreekt. Ik weet niet meer welke van de twee het is, maar het is het meest flexibele hulpmiddel. Zonder dat zou ik verloren zijn.

Ik gebruik het de hele dag, elke dag, voor alles. Bij het vorige bedrijf waar ik werkte gebruikten we het om in zes maanden een bedrijf van een miljard dollar te lanceren. Het was gewoon Miro; het voelde alsof het niets was. Het is een indrukwekkend hulpmiddel. Ik gebruik het ook voor al mijn inhoud en eigenlijk voor alles. Het is een geweldig hulpmiddel.

Michael Luchen

Ik ben het daar volledig mee eens. Mijn team en ik adopteerden het toen het nog een realtime whiteboard was. Het werd heel snel het meest gebruikte hulpmiddel in de geschiedenis van het bedrijf en bleek ontzettend waardevol.

En tot slot: welk advies geef je iemand die aan een loopbaan in productmanagement begint?

Sam Higham

Vraag om hulp. Er bestaat een aanname dat je als productpersoon alles moet weten, omdat je vaak op het kruispunt van alles staat. Toch kun je terughoudend zijn om hulp te vragen wanneer je iets niet weet, of dat nu aan andere productmensen, een geweldige technicus, een ontwerper of iemand anders in de organisatie is.

De beste mensen die ik ken in productmanagement zijn altijd actief op zoek naar hulp, omdat ze weten dat ze daardoor beter worden.

Er groeit ook een geweldige community op Twitter voor productmensen. De meeste mensen zijn daar omdat ze anderen willen helpen leren. Vraag dus om hulp. Dat is mijn belangrijkste advies. Eigenlijk niet alleen voor productmanagement, maar voor iedereen. Punt.

Michael Luchen

Dat is fantastisch. Daar ben ik het volledig mee eens. Zelfs als je denkt dat je het weet, moet je om hulp vragen, want een tweede mening kan op zichzelf al waardevol zijn.

Bedankt dat je vandaag bij de show was, Sam.

Sam Higham

Bedankt voor de uitnodiging.

Michael Luchen

Je kunt meer over Sams werk vinden op Twitter of LinkedIn. Nogmaals bedankt dat je erbij was, Sam. Bedankt allemaal voor het luisteren en laat vooral een beoordeling achter voor de podcast. Volg en sluit je ook aan bij onze community op theproductmanager.com als je dat nog niet hebt gedaan.

Nogmaals bedankt allemaal en tot de volgende keer. Tot ziens!