Moeten er helden zijn in productmanagement?

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot is niet altijd 100% correct.

Hannah Clark: Voordat we erin duiken, wil ik precies verduidelijken wat ik bedoel met helden in productmanagement. Ik heb het niet over opinieleiders zoals Marty Cagan of Lenny Rachitski, ik heb het over JOU. Ik heb het over de persoon op wie je productteam leunt om de dag te redden wanneer er iets misgaat. Ik heb het over de held die vele petten draagt, maar nooit een cape. Ik heb het over de reden waarom je blijkbaar niet minder dan 50 uur per week kunt werken en nog steeds het gevoel hebt dat je niet verder bent dan de week ervoor.

En als dat bekend klinkt, is er goed nieuws: de gast van vandaag is Clement Kao, oprichter van Product Teacher. Als coach van productmanagers in allerlei omgevingen, van start-ups in een vroeg stadium tot Fortune 500-bedrijven, heeft hij veel productteamdynamiek gezien, waaronder genoeg situaties die serieus gered moesten worden.

We gaan bespreken waarom de held van een productteam zijn op zichzelf al een gevaar is. En als dat herkenbaar klinkt, blijf dan tot het einde luisteren om te ontdekken hoe je de bovenmenselijke kracht kunt krijgen om eindelijk dingen om te draaien. Laten we beginnen.

Welkom terug bij de Product Manager Podcast. Vandaag zit ik samen met Clement Kao. Hij is de oprichter van Product Teacher.

Clement, ontzettend bedankt dat je vandaag bij ons bent.

Clement Kao: Ja. Bedankt dat je me hebt uitgenodigd.

Hannah Clark: We beginnen zoals altijd. Kun je ons iets vertellen over je achtergrond en wat je ertoe bracht Product Teacher op te richten?

Clement Kao: Ja, fantastische vraag. Toen ik afstudeerde aan de universiteit ben ik oorspronkelijk niet meteen in productmanagement begonnen.

Ik begon eigenlijk als managementconsultant. Daarna werd ik als managementconsultant per ongeluk UX-onderzoeker. Vervolgens werd ik per ongeluk data-analist. En daarna werd ik per ongeluk productmanager. Ik heb dus een zeer niet-traditionele achtergrond. Terwijl ik verderging in mijn loopbaan als productmanager, begon ik als associate productmanager onderaan de ladder, waarna ik doorgroeide naar productmanager, senior PM, group productmanager en principal productmanager.

Een van de dingen die me opviel, was dat veel andere mensen op dezelfde manier worstelden als ik. Ze beschikten niet altijd over de juiste hulpmiddelen. Hoe pak je een bepaald probleem aan? Hoe werk je een specifieke fout weg? Wat betekenen al die verschillende termen en waarom zijn deze zaken belangrijk?

Daarom begon ik mezelf, naarmate ik seniorer werd in mijn loopbaan als individuele productmanager, af te vragen: hoe kan ik de grootst mogelijke impact maken? Ik begon te beseffen dat mijn grootste impact niet noodzakelijk lag in doorgaan met productmanagement binnen één bedrijf. Het lag eerder in het helpen van honderden, zo niet duizenden andere productmanagers om succesvol te zijn wanneer ze voor het eerst productmanager worden.

Dat kan namelijk een zeer verwarrende overgang zijn. Daarna kun je hen helpen om hogerop te komen. Daarom besloot ik Product Teacher op te richten. Product Teacher heeft meer dan 7.000 productmanagers geholpen om succesvol te zijn in hun werk: of ze nu voor het eerst de overstap naar product maken, promotie krijgen of als hoofd product een productstrategie opzetten en ervoor zorgen dat we echt duidelijke processen hebben voor al onze teamleden, enzovoort.

Het is dus een ongelooflijk bevredigende reis geweest.

Hannah Clark: Mooi. En het klinkt alsof dit het meest doelbewuste onderdeel van je loopbaantraject was, en niet het...

Clement Kao: Ja. Het was het enige wat ik niet per ongeluk heb gedaan. Ja, ja.

Hannah Clark: Vandaag gaan we het idee van heldhaftigheid in productmanagement onderzoeken, waar je je enigszins tegen hebt uitgesproken. Om het duidelijk te maken: wat betekent dat in deze context en hoe zie je dit tot uiting komen binnen organisaties waarmee je hebt gewerkt?

Clement Kao: Ja, fantastische vraag. Laat me eerst iets verduidelijken. Ik zeg niet dat heldhaftigheid per definitie slecht is. Een van de kernzaken van productmanager zijn, is dat de verantwoordelijkheid bij jou ligt.

Het is jouw verantwoordelijkheid om ervoor te zorgen dat het product succesvol is en je bent bereid de handen uit de mouwen te steken voor wat er ook nodig is. Misschien hebben we geen QA-medewerker en moeten we er plots voor zorgen dat alles goed wordt getest voordat het naar productie gaat. Misschien is onze ontwerper ziek en moeten we echt vaart maken om onze engineers vrij te spelen.

Of misschien hebben onze klanten moeite om dit deel van het product te begrijpen en moet je de rol van product operations opnemen om het uit te rollen en ervoor te zorgen dat mensen succesvol zijn. Wat het ook is, de productmanager moet kunnen inspringen. Het kernprobleem dat ik vaak zie bij een soort heldhaftigheid in productmanagement, is wanneer dit wordt gebruikt als iets wat je voortdurend hoort te doen, in plaats van alleen wanneer er een echte uitzondering optreedt.

Een productmanager moet dus inderdaad kunnen inspringen en dingen voor elkaar krijgen wanneer dat nodig is, maar hij of zij hoort niet altijd alles te doen. Wanneer mensen zeggen: ‘Deze productmanager is zo’n held’, nemen ze in feite veel taken van andere collega’s over om het product te laten werken. Daardoor verzwakt de rest van de organisatie.

Mensen doen dan niet noodzakelijk wat nodig is vanuit bijvoorbeeld productmarketing, productanalyse, klantensucces of verkoop. Al die verschillende onderdelen worden minder sterk en minder herhaalbaar wanneer je erop vertrouwt dat één persoon alles doet. Ik heb dit om me heen gezien. Wanneer die productmanager ziek wordt, op vakantie gaat of de organisatie verlaat, zit iedereen met een groot probleem.

Productmanagers moeten dus natuurlijk bereid zijn om op te staan wanneer dat nodig is. Maar als die behoefte dagelijks of wekelijks ontstaat, is er waarschijnlijk een dieperliggend probleem dat moet worden aangepakt.

Hannah Clark: Ja, en ik denk dat we ons enkele logische gevolgen kunnen voorstellen van een PM die voortdurend in zo’n positie zit. Maar waarom denk je dat er nog steeds zoveel productmanagers in deze positie zitten?

Clement Kao: Ja, fantastische vraag. Ik denk dat productmanagers vaak in deze positie blijven omdat de manier waarop werk in de loop der tijd is veranderd, betekent dat iedereen allerlei verschillende zaken tegelijk moet kunnen afhandelen.

Vroeger had je bijvoorbeeld één UX-ontwerper die zich volledig op één initiatief richtte. Nu ondersteunt die persoon misschien vijf productteams. Misschien had je iemand die als businessanalist één centrale reeks initiatieven moest ondersteunen. Nu ondersteunt die persoon zeven verschillende teams.

Door al die gedeelde verantwoordelijkheden is het veel minder duidelijk wie de taak moet oppakken. Wanneer er iets misgaat, is het niet duidelijk wie moet inspringen. En omdat dat niet duidelijk is, moet de productmanager dat standaard doen.

Als er meer duidelijkheid is over wie welke zaken moet uitvoeren, hoeft de productmanager niet in te springen. Maar door de opkomst van technologie-start-ups en veel kleinere, autonome teams zijn er soms geen duidelijke richtlijnen over wie wat moet doen.

Wanneer we zeggen: ‘We weten niet wie dit moet doen’, wordt het dus de taak van de productmanager. Zodra die het één keer doet en het goed doet, ontstaat er bijna een zichzelf versterkende lus: de productmanager heeft het eerder gedaan en deed het beter dan wij dat hadden gekund, dus laten we die persoon het de volgende keer weer doen.

Ik heb productmanagers daardoor alle analyses zien overnemen, al het marktonderzoek en alle klantgesprekken zien doen, of alle verkoopgesprekken zien voeren en de verkoop zien sluiten. Ze hadden het immers beter gedaan dan anderen. Daarom laten we hen het opnieuw doen, terwijl de rest zich op andere initiatieven richt.

Dat is dus ongeveer waarom ik deze situatie de afgelopen tien jaar steeds vaker zie.

Hannah Clark: Zijn er vroege signalen waaraan je kunt zien dat een organisatie onvoldoende werk heeft gemaakt van het beschermen van productmanagers tegen het voortdurend moeten optreden als held, of dat de organisatie zich procesmatig niet goed heeft voorbereid?

Clement Kao: Ja, fantastische vraag. Ik denk dat het iets is wat je herkent zodra je het ziet. Eén keer inspringen is prima en volledig te verwachten. Maar als je merkt dat je dit heel regelmatig doet — bijna maandelijks, bij elke lancering of elke bug — dan is er een patroon.

Als hetzelfde soort probleem twee keer achter elkaar voorkomt, moet je waarschijnlijk het diepere gesprek voeren. Als je organisatie retrospectieven waardeert, gebruik ze dan. Als ze die niet heeft, breng ze dan in door te bespreken waarom dit probleem ontstond.

Als je dit de eerste keer doet, zou het probleem idealiter de tweede keer niet meer voorkomen. Als het wel opnieuw gebeurt, moet de retrospectieve ook onderzoeken waarom er een patroon ontstaat. Zo kun je ontdekken dat productmensen regelmatig dingen doen die buiten hun verantwoordelijkheidsgebied vallen, en dat is niet wat we willen.

Hannah Clark: Bij het uitvoeren van deze retrospectieven klinkt dit dus als de weinig sexy oplossing voor zo’n probleem.

Clement Kao: Het is heel weinig sexy. Ja.

Hannah Clark: Helaas. Welk proces moet een productmanager gebruiken om een goede retrospectieve uit te voeren die iedereen meekrijgt in het doorvoeren van de noodzakelijke veranderingen om zo’n situatie op te lossen?

Clement Kao: Een van de belangrijkste dingen is dat de retrospectieve vrij van schuld moet zijn en dat we het systeem bespreken, niet de mensen. We willen niet zeggen: ‘Deze engineer had het zo druk dat hij het niet kon doen, dus daarom heb ik het gedaan.’

In plaats daarvan moeten we vragen waarom een klant die zes maanden geleden een probleem meldde niet eerder onze aandacht kreeg. Waarom wachtten we tot de klant zo gefrustreerd was dat hij het contract bijna opzegde voordat de productmanager ingreep?

We moeten een stap terug doen en naar het systeem kijken. Niet: ‘Deze persoon heeft het probleem op dit moment niet gemeld’, maar: ‘Als dit opnieuw gebeurt, wat hadden we dan als systeem of proces beter kunnen doen?’

Denk bijvoorbeeld aan luchtverkeersleiding. Een luchtverkeersleider zorgt ervoor dat vliegtuigen opstijgen en landen en dat er geen botsingen plaatsvinden. Wanneer er een crash gebeurt, was die luchtverkeersleider daar inderdaad bij, maar het is niet automatisch voor honderd procent zijn schuld. Er zijn allerlei andere opeenvolgende factoren die van iemand een enkel storingspunt kunnen maken.

We willen niet opnieuw één storingspunt creëren. We willen meerdere plaatsen hebben waar we een fout eerder kunnen voorkomen. Het mag dus niet alleen afhangen van de ene persoon met de titel productmanager.

Dat is de manier waarop een retrospectieve moet worden uitgevoerd. Er bestaan allerlei handleidingen met best practices en vragen die je kunt stellen, en die zijn nuttig. Maar de belangrijkste houding is de basis van elke retrospectieve: we doorlopen dit samen. We wijzen niet met de vinger en zeggen niet dat een specifiek persoon schuldig is en dat diens loopbaan op het spel staat. We controleren het systeem. Wat ging er mis in het systeem?

En hoe kunnen we dat systeem de volgende keer voor ons allemaal iets beter maken? Dat kan enorm krachtig zijn om ervoor te zorgen dat we de juiste ondersteunende rollen en processen hebben, zodat het niet elke keer aan de productmanager is om code samen te voegen of te voorkomen dat een klant vertrekt.

Als een klant op het punt staat te vertrekken en de productmanager één keer inspringt, is dat prima. Maar als voor elk klantgesprek een productmanager in de kamer nodig is en steeds dezelfde persoon moet optreden, moeten we waarschijnlijk opnieuw bekijken hoe dit proces is ingericht.

Hannah Clark: Dat is logisch. Je moet het probleem als het ware reverse-engineeren en vervolgens vanuit dat startpunt de oplossing vinden. Heb je in je werk met productteams organisaties persoonlijk een probleem als dit succesvol zien oplossen? En zo ja, kun je ons dan, zonder namen te noemen, vertellen wat er gebeurde?

Clement Kao: Zeker. Ik zal eerst een verhaal over mezelf vertellen. Op een bepaald moment was ik degene die alle product-operationszaken deed, terwijl dat niet mijn taak had moeten zijn. Voor een van de producten waarvoor ik verantwoordelijk was binnen B2B SaaS lanceerden we een volledig nieuw product dat aansloot op ons bestaande product.

Omdat ik al het klantonderzoek had gedaan, begreep ik de pijnpunten van klanten. Ik zorgde voor de juiste release notes, hield alle opnames bij en deed er alles aan om ervoor te zorgen dat klanten succesvol konden worden bij het instellen en gebruiken van het product.

Dat werkte toen er slechts drie klanten waren. Maar toen we bij klant nummer zeventig kwamen, besefte ik dat ik eerder mijn hand had moeten opsteken. Rond klant tien of vijftien had ik moeten zeggen: ‘Het is niet mijn taak om elke demo en elke training voor al mijn klanten te verzorgen. Iemand anders hoort daar eigenaar van te zijn.’

Ik dacht destijds: het is mijn taak. Ik ben productmanager en moet ervoor zorgen dat het product succesvol is, koste wat kost. Ik zag niet dat ik daarmee anderen binnen klantensucces of productmarketing de kans ontnam om een volledig beeld te krijgen van wat klanten ervaren.

Ik sprong steeds in wanneer dat nodig was en ondermijnde daarmee, ondanks mijn goede bedoelingen, mijn teamgenoten. Ik gaf hun niet de kans om iets van begin tot einde te beheren.

Mijn directeur product merkte dat ik steeds meer onder water kwam te staan en zei: ‘Je doet allerlei dingen die technisch gezien niet van jou zijn.’ Ik antwoordde: ‘Maar de verantwoordelijkheid ligt bij mij.’ Hij zei: ‘Dat klopt, maar je voorkomt dat we een robuust systeem kunnen opbouwen om onze klanten op lange termijn te ondersteunen. Je kon ons van één tot tien klanten helpen, maar nu zit je aan je grens bij zeventig. We willen volgend jaar verdubbelen naar 140. Hoe ga je dat doen?’

Dat was een terecht punt. We brachten alle betrokken partijen samen en bespraken wie waarvoor eigenaar moest zijn. Waar eigenaarschap eerst als een last werd gezien, bleek het juist een mogelijkheid: we gaven mensen nieuwe verantwoordelijkheden en nieuwe superkrachten.

Twee zaken waren hierbij bijzonder belangrijk. Ten eerste was er steun van de productleiders. Als de productleiding zegt dat je het gewoon moet doen, is het moeilijk om taken door te schuiven naar de mensen bij wie ze beter thuishoren.

Ten tweede ging het om de manier waarop we deze verantwoordelijkheden presenteerden. Het ging niet om meer werk dat niet leuk was. Het ging om meer eigenaarschap en de mogelijkheid om iets volledig van begin tot einde te beheren. We hadden dat onterecht van hen afgenomen.

Daarna moesten we regelmatig controleren hoe het ging. In het begin kwamen we wekelijks of tweewekelijks samen om informatie over te dragen en de overgang soepel te laten verlopen. Je kunt niet zomaar iets over de muur gooien en zeggen: ‘Vanaf nu is het van jou.’ We zijn teamgenoten en moeten samen de overgang maken.

Hannah Clark: Heb je nog een recenter voorbeeld dat dit concept vanuit een ander perspectief illustreert?

Clement Kao: Ja, een heel recent voorbeeld. Ik werk momenteel met een grote organisatie waar het productteam nog relatief nieuw is. Veel teamleden werkten eerder als solution architect. De organisatie bouwde vroeger voor iedere klant maatwerkoplossingen. Dat was geen schaalbaar product.

De leiding besloot een productteam op te richten, omdat veel van die oplossingen overeenkomsten vertoonden in de klantgebruikssituaties die ze wilden ondersteunen. Ze wilden robuuste, schaalbare producten bouwen in plaats van telkens eenmalige oplossingen.

Omdat de leden van het nieuwe productteam vroeger solution architects waren, bleven ze solution-architectuurwerk doen. Ze bepaalden niet alleen hoe het product moest worden gebouwd, maar ook hoe elke klant het moest implementeren en gebruiken. De solution architects die verantwoordelijk waren voor die initiatieven vroegen zich daardoor af wat hun rol nog was.

Het productteam wilde ervoor zorgen dat het product goed werd gebruikt, maar de solution architect hoort te onderzoeken welke andere systemen de klant gebruikt en hoe alles met elkaar wordt verbonden. Het productteam moet op schaal kunnen werken en zich richten op het bouwen van een robuust platform.

Zo verschuif je van één productmanager voor één klant naar één productmanager voor meerdere klanten. De productmanager beheert de kern en iedere solution architect kan vervolgens de specifieke klantoplossing verzorgen.

Het kostte meerdere gesprekken met het hele team om dit duidelijk te maken. Ik begrijp dat je goed werk wilt leveren als productmanager, maar als je solution architects de mogelijkheid ontneemt om oplossingen voor klanten te ontwerpen, kun je op lange termijn geen technische kern bouwen. Dan word je tegelijk PM en solution architect en heb je geen tijd om de volgende bouwsteen te ontwikkelen die alle andere solution architects sneller maakt.

We moeten dus duidelijk nee zeggen en uitleggen waarom, en het eigenaarschap teruggeven aan de solution architect. Zo voelt die persoon zich niet buitengesloten. Het team was zeer ontvankelijk voor feedback en kon de verantwoordelijkheden snel opnieuw inrichten.

Het mooie was dat we dit vroeg ontdekten: het productteam bestond nog geen jaar. Ze konden de relatie nu opnieuw definiëren, in plaats van drie jaar te wachten tot alles was vastgeroest en dan te moeten vaststellen dat ze het verkeerd hadden aangepakt.

De productmanager is dus niet de held bij iedere klantimplementatie die alle bijkomende taken moet uitvoeren. De productmanager beheert het product en de solution architects beheren de oplossing.

Hannah Clark: Ik wil nog wat verder ingaan op het idee van denkwijzen, maar ook op de volwassenheid van een organisatie en hoe dat beïnvloedt hoe dingen werken. Naarmate een organisatie volwassener wordt, groeien de regels en processen mee, worden ze ingewikkelder en neemt de overweldiging het over. Je raakt vast in een sleur waarin je weet dat het niet duurzaam is, maar het toch als de enige mogelijke manier voelt.

Als iemand al onbedoeld organisatorische verzwakking heeft veroorzaakt en overweldigd is door verantwoordelijkheden die technisch gezien niet van hem of haar zijn, welk licht aan het einde van de tunnel kan die persoon verwachten wanneer hij of zij echt werk maakt van het loskomen uit die situatie? En hoe kom je voor jezelf op in een organisatie die zich in zo’n fase bevindt?

Clement Kao: Ik wil dit bijna van onderaf benaderen. Het begint met erkennen dat je op een manier onder water staat waarvoor je niet bewust hebt gekozen. Die realisatie vindt vaak niet eens plaats omdat je zo diep onder water zit. Je werkt misschien zeventig of tachtig uur per week en hebt geen tijd om na te denken: wacht eens, dit lijkt niet op productmanagement.

Neem aan het begin of einde van de week tien minuten om te reflecteren. Hoe voel ik me bij het werk dat ik doe? Is wat ik doe werkelijk productwerk? Beweeg ik de juiste metrics? Doe ik dingen die weinig waarde opleveren, maar die ik om de een of andere reden toch moet doen?

Zo kun je herkennen wat er gebeurt. Misschien dacht je dat je taak was om het klantprobleem te begrijpen, met design en engineering samen te werken aan een oplossing en vervolgens met het bedrijf samen te werken aan de uitrol. Als je nu allerlei andere dingen doet die niet tot die kerntaak behoren, moet je je afvragen wat er aan de hand is.

Daarna heb je de steun van je manager nodig. Managers weten vaak niet dat je al die extra zaken doet. Ze hebben hun eigen metrics en beheren veel andere mensen. Wanneer je zegt dat je tien uur per week aan iets besteedt, kunnen ze vragen waarom je dat niet eerder hebt verteld, omdat het niet bij jou hoort.

Als jouw metrics ook de metrics van je manager zijn, help je je manager effectiever te worden door te laten zien dat je tijd besteedt aan zaken die niet aansluiten bij jouw of diens doelen. Breng dus in kaart wat je doet, hoeveel tijd het kost en waarom je denkt dat je het doet.

Vervolgens kun je met andere teams bespreken welke taken beter bij hen passen. Misschien maak je alle UX-ontwerpen en wireframes terwijl er een ontwerper is. Misschien schrijf je allerlei ad-hoc SQL-query’s terwijl er een analyseteam is. Dat team kan misschien een dashboard bouwen dat het werk permanent automatiseert, zodat de hele klantensuccesorganisatie ervan profiteert.

Door zelf de held te spelen help je je organisatie dus niet om op te schalen. Bespreek wat je doet, waarom je denkt dat het bij een ander team hoort en hoe dat team meer schaalbaarheid, zichtbaarheid en aansluiting op bestaande processen kan creëren.

Controleer in het begin regelmatig of de overdracht goed verloopt en bouw die controles later af. Zorg ervoor dat het andere team zich comfortabel voelt, de context kent en succesvol kan worden.

Aan het einde van de tunnel heb je veel meer tijd — de tijd die je oorspronkelijk al had moeten hebben — om echt productwerk te doen: klanten begrijpen, creatief samenwerken met design en engineering, schaalbare producten bouwen die klanten blij maken en op lange termijn winst opleveren.

Je kunt ook nauwer samenwerken met het bedrijf aan de marktbenadering en positioneringsstrategie: hoe wil je je onderscheiden, hoe zorg je dat klanten succesvol zijn en in welke nieuwe segmenten wil je doordringen? Je hoofd voelt veel helderder en je kunt je beter richten op de kern van productmanagement.

Ik weet dat het moeilijk is, want ik heb dit zelf meegemaakt en het duurde lang. Maar het was uiteindelijk zeer waardevol. Ik kon producten met veel meer impact maken en mijn klanten veel dieper begrijpen.

Een aanvullende tip is dat productmanagers vaak willen dat anderen succesvol zijn en zichzelf daarom steeds onderaan de prioriteitenlijst zetten. Je besteedt die tien minuten dan liever aan een uitrolplan, documentatie of het opschonen van tickets.

Wat mij hielp, was mezelf in tweeën te splitsen. Er is Clement de productmanager, de persoon die het werk uitvoert. Maar er is ook een afzonderlijke productleider die eist dat er volgende week een plan ligt om duurzaam te werken.

Mijn tweede naam is Richard. Daarom zei ik tegen mezelf: ‘Richard, de productdirecteur, verwacht dat je volgende week een plan hebt om schaalbaarder te werken.’ Richard eiste dat van mij. Ik kon niet afhaken.

Dat hielp enorm. Ik maakte tijd om met Richard het plan voor schaalbaarheid te bespreken. Als ik geen vooruitgang boekte, zou Richard teleurgesteld zijn. Zo kon ik mezelf losmaken van de voortdurende uitvoering en erkennen dat ik ook eigenaar ben van de strategie.

Productmanagers vergeten vaak dat zij zelf een kritieke belanghebbende zijn. Ze mogen die belanghebbende niet verwaarlozen terwijl ze het product uitvoeren. Dat helpt niet alleen bij het herverdelen van verantwoordelijkheden, maar ook bij allerlei andere vormen van groei in productmanagement waarvoor je tijd voor jezelf moet vrijmaken.

Hannah Clark: Ik hou van onconventionele tactieken, vooral wanneer je daarmee je eigen waarde en bijdrage aan het team echt buiten jezelf kunt plaatsen. Het is bijzonder dat het meest heldhaftige wat je in een organisatie kunt doen, is andere mensen — en daarmee indirect jezelf — sterker maken.

Clement, ontzettend bedankt dat je bij ons was. Dit was fantastisch. Ik waardeer je inzichten altijd. Ik denk dat je dit vakgebied zoveel te bieden hebt. Waar kunnen mensen je online volgen?

Clement Kao: Goede vraag. Je kunt me altijd vinden op LinkedIn. Volgens mij ben ik waarschijnlijk de enige Clement Kao. Zoek dus op Clement Kao. Je kunt me ook vinden op productteacher.com, zonder spaties of streepjes. Daar ben ik meestal te vinden om andere productmensen te helpen succesvol te zijn.

Hannah Clark: Geweldig. We zien je daar.

Clement Kao: Geweldig. Bedankt voor de uitnodiging.

Hannah Clark: Bedankt voor het luisteren. Voor meer geweldige inzichten, praktische handleidingen en toolreviews kun je je abonneren op onze nieuwsbrief via theproductmanager.com/subscribe. Je kunt meer gesprekken zoals dit beluisteren door je overal waar je podcasts vindt te abonneren op The CPO Club.