Hoe het bouwen van AI-producten anders is — en waarom productteams moeten evolueren

Galen Low: Is er echt iets zo anders aan het proces van het ontwikkelen van een product met AI-native functionaliteit ten opzichte van andere producten die misschien toevallig bestaande AI-technologie gebruiken?

Jyothi Nookula: Ja. Wanneer je een AI-native product bouwt, heb je te maken met drie dingen die anders zijn. Ten eerste is AI fundamenteel onvoorspelbaar.

Galen Low: Wat is het eerste wat je als leider doet wanneer je merkt dat een team misschien niet allemaal op hetzelfde niveau zit als het gaat om het begrijpen, gebruiken en zelfs accepteren van opkomende technologieën zoals AI?

Jyothi Nookula: Ik splits het probleem op in twee afzonderlijke kwesties. De eerste kwestie is competentie. De tweede is houding. Als je een houdingsprobleem behandelt alsof het een competentieprobleem is, maak je het alleen maar erger.

Galen Low: Wat zijn volgens jou de belangrijkste dingen die een productmanager die geïnteresseerd is in het ontwikkelen van AI-producten op zijn cv of in zijn portfolio moet hebben om op te vallen?

Jyothi Nookula: Eén ding is bewijs dat je iets met AI hebt gebouwd, niet alleen dat je erover praat. Het tweede is...

Galen Low: Welkom bij de podcast van The Digital Project Manager — de show die deliveryleiders helpt slimmer te werken, sneller te leveren en beter leiding te geven in het tijdperk van AI. Ik ben Galen, en elke week duiken we in praktijkgerichte strategieën, nieuwe tools, bewezen raamwerken en af en toe een waargebeurd verhaal van de frontlinie van projecten. Of je nu enorme transformatieprojecten aanstuurt, AI-workflows beheert of gewoon probeert de chaos onder controle te houden, je bent hier aan het juiste adres. Laten we beginnen.

Vandaag praten we over de toekomst van de productmanager, wat ervoor nodig is om AI-producten te ontwikkelen, hoe AI wordt gebruikt om het productontwikkelings- en releaseproces te stroomlijnen, en wat teamleiders kunnen doen wanneer hun productteams ongelijke verdelingen van vaardigheden en houdingen hebben rond opkomende technologieën zoals AI.

Vandaag is Jyothi Nookula bij me in de studio. Jyothi heeft meer dan 13 jaar ervaring met het stimuleren van innovatie op het gebied van AI-producten en -platforms bij bedrijven als Netflix, Meta, Amazon AWS en Etsy. Ze heeft ook 12 patenten op het gebied van machine learning en heeft via haar onderwijsbedrijf Next Gen Product Manager meer dan 1500 productmanagers begeleid bij hun overstap naar AI-functies.

Jyothi, heel erg bedankt dat je vandaag bij me bent.

Jyothi Nookula: Hoi allemaal. Ik vind het geweldig om hier vandaag te zijn.

Galen Low: Ik ben ook enthousiast en ik kijk hier al weken naar uit. Toen jij en ik voor het eerst spraken, en ik eerst je profiel bekeek, dacht ik: wauw, Jyothi is een krachtpatser. Er staan zoveel merken en technologieën in je profiel waar je jaloers op kunt zijn.

En ik ben altijd een liefhebber van mensen die de volgende generatie van een vak willen helpen om zich verder te ontwikkelen in een steeds technologischer en nu ook meer op AI gericht tijdperk. En toen we spraken dacht ik: wauw, we hebben zoveel gemeen. Ik kom meer uit de projectkant, jij meer uit de productkant. Maar ik ben erg benieuwd om te onderzoeken hoe dingen veranderen en wat je onderweg hebt geleerd tijdens je reis door AI- en machinelearningproducten.

Ik weet dat jij en ik onderweg waarschijnlijk een paar interessante zijpaden zullen bewandelen die heel boeiend en waardevol zijn, dus ik hoop dat we dat doen. Maar de projectmanager in mij heeft voor vandaag een routekaart gemaakt. Om te beginnen wilde ik één grote, brandende vraag uit de weg ruimen, die ongemakkelijke maar dringende vraag waarvan ik denk dat iedereen het antwoord wil weten.

Daarna wil ik uitzoomen en drie dingen bespreken. Ten eerste wil ik het hebben over het identificeren en dichten van vaardigheidstekorten in je productteams. Wanneer je te maken hebt met producten die AI- en machinelearningfuncties gebruiken, wil ik vervolgens enkele voorbeelden onderzoeken van manieren waarop jouw teams AI-tools hebben ingezet in het productontwikkelingsproces, of dat nu bij onderzoek, data-analyse, ontwerp, engineering, gebruikerstesten of iets compleet anders was.

En tot slot wil ik onderzoeken hoe de toekomst van de rol van productmanagement eruitziet. Wat er op een cv of in een portfolio moet staan om überhaupt in aanmerking te komen voor functies bij bedrijven als Meta, AWS, Netflix, Etsy en andere toonaangevende merken die vooroplopen op het gebied van AI.

Jyothi Nookula: Ik vind het geweldig. Ik ben geïnteresseerd. Dat is het nieuwste hot topic. Ik ben er dol op.

Galen Low: Geweldig. Laten we beginnen met die grote vraag. Mijn grote vraag om dit allemaal te kaderen gaat natuurlijk over AI. Jij hebt veel ervaring met productteams om AI- en machinelearningoplossingen te ontwikkelen voor giganten als Meta, Amazon, Etsy en Netflix. Mijn vraag is: is er echt iets zo anders aan het proces van het ontwikkelen van een product met AI-native functionaliteit ten opzichte van andere producten die misschien toevallig bestaande AI-technologie gebruiken?

Jyothi Nookula: Dat is een geweldige vraag, omdat die echt raakt aan de kern van wat er momenteel verandert in productontwikkeling. En het eerlijke antwoord is fundamenteel: ja, maar niet op de manier waarop mensen erover denken. Dit bedoel ik. Wanneer je een AI-native product bouwt, heb je te maken met drie dingen die anders zijn dan bij traditionele software of zelfs producten die via een API alleen met AI integreren.

Ten eerste is AI fundamenteel onvoorspelbaar. Bij traditionele productontwikkeling schrijf je deterministische code: als dit gebeurt, doe dan dat. Of: als ik op deze knop klik, ga dan naar dit volgende scherm. Elke keer dat ik op die knop klik, gebeurt hetzelfde. Maar bij AI-native producten werk je met probabilistische systemen. Je AI-functie kan dus elke keer dat deze wordt uitgevoerd anders werken.

Dat betekent dat je volledige kwaliteitsborgingsproces, je omgang met randgevallen en al je betrouwbaarheidswaarborgen volledig opnieuw moeten worden doordacht. Je test niet alleen of iets werkt; je test of het goed genoeg werkt en of het elke keer consistent werkt binnen een verdeling van mogelijke uitkomsten.

Dat is het eerste fundamentele verschil: die onvoorspelbaarheid, het verschil tussen deterministisch en probabilistisch. Het tweede is dat we nu producten bouwen op verschuivende grond, omdat de onderliggende modellen zich ontwikkelen op manieren die je niet kunt of niet zelf beheerst. Een nieuw model kan bijvoorbeeld het gedrag veranderen.

Het hoeft geen verstorende wijziging te zijn, maar het kan het gedrag wel een beetje veranderen, mogelijkheden uitbreiden of nieuwe manieren waarop het kan mislukken introduceren. En dat gebeurt van de ene op de andere dag, in het tempo waarin alles tegenwoordig beweegt. In tegenstelling tot traditionele afhankelijkheden, waarbij je verstorende wijzigingen met versiebeheer kon volgen en updates kon documenteren.

Deze modelupdates gaan sneller dan wij ze überhaupt kunnen bijhouden. En het derde — en dit is een belangrijke — is dat je succesmetingen anders moeten zijn. Je kunt niet langer alleen meten of een functie succesvol werd uitgevoerd. Je moet nu dingen meten als: was de uitvoer nuttig? Het gaat niet alleen om de vraag of de functie werd uitgevoerd, maar of de uitvoer nuttig was.

Kwam de uitvoer overeen met de bedoeling van de gebruiker? Met de vraag die de gebruiker stelde? En hoe definieer je überhaupt wat goed is voor jouw gebruikssituatie? Daardoor heb je veel kortere feedbacklussen met je gebruikers nodig en moet je deze evaluatiemechanismen direct in de productontwikkeling inbouwen. Dat verschilt sterk van de manier waarop traditionele productontwikkeling wordt uitgevoerd.

Dat zijn dus de drie dingen die heel anders zijn. Producten die alleen bestaande AI aanspreken — bijvoorbeeld wanneer ik alleen een ChatGPT-integratie toevoeg — kunnen nog steeds als traditionele integraties worden behandeld. Je hebt nog altijd succesmetingen en zaken waar je naar moet kijken, en evaluaties die je moet bijhouden.

Maar daar is er ten minste een contract. Wanneer je je product vanaf de grond af aan als AI-native product bouwt, is dat totaal anders. En daar hebben deze drie dingen nog meer invloed op je productontwikkeling.

Galen Low: Het grappige is dat ik, toen ik deze vraag stelde, dacht: ik ga deze vraag stellen en zij zal waarschijnlijk zeggen: ja, het is ongeveer hetzelfde met een paar kleine verschillen. Maar dit verandert het spel absoluut.

Ik vind het geweldig wat je zei over het meten van intentie en de meetkant ervan. Ik kom uit de projectwereld, dus we hebben ons eisenoverzicht. Dat is binair. Het is ja of nee. Heeft het gedaan wat er in de functionele specificatie stond? Maar dan is er al die dubbelzinnigheid. Ten eerste omdat het probabilistisch is en de uitkomst niet elke keer hetzelfde zal zijn.

En ten tweede omdat de onderliggende architectuur in zekere zin een zwarte doos is die zichzelf elke dag sneller ontwikkelt dan mensen kunnen begrijpen. En ik denk: dat is eigenlijk heel anders dan de manier waarop de meeste digitale producten in de recente geschiedenis zijn gemaakt. Maar het is logisch. Dit is wat ik in mijn hoofd denk.

Je hebt meer dan tien jaar ervaring met machine learning en AI. Veel mensen zijn pas de afgelopen twee jaar begonnen. Voor hen is het pas sinds ongeveer twee jaar nieuw. ChatGPT heeft het deksel opgelicht van de manier waarop AI kan worden gebruikt, maar AI zit al een tijd in software en onze digitale producten.

En wat ik in mijn hoofd heb is: omdat je bij Netflix hebt gewerkt, denk ik: dat ziet er zo eenvoudig uit, maar dat is het waarschijnlijk niet. Dat algoritme, de machine learning, de gegevensverwerking aan de achterkant — niet alleen omdat alles op Netflix met een bepaalde taxonomie is gelabeld; het is niet hetzelfde als gerelateerde links op een website.

Het gaat daadwerkelijk om gedrag en intentie, en het is gemakkelijk om het verkeerd te doen. Je ontdekt misschien bijna nooit hoe fout het is totdat je die ene tweet krijgt. Zo van: o mijn god, mijn Netflix krijgt het nooit goed, want ik heb dit bekeken. Nu beveelt Netflix achttien seizoenen van Barney aan. Juist.

Jyothi Nookula: Hetzelfde gebeurt voortdurend met Instagram Reels en TikTok. Ik keek ooit één video van iemand die aan het skiën was en daarna werd ik overspoeld met skivideo’s. Ja.

Galen Low: En ik denk dat we het zo vanzelfsprekend vinden. Het zou gemakkelijk zijn voor mensen, mezelf inbegrepen, om te denken: ik weet het niet, dat ziet er nogal eenvoudig uit. Zelfde truc, dezelfde vaardigheden. Maar wanneer je het op deze manier uit elkaar haalt, is het dat eigenlijk niet. Ik vroeg me af of we vanaf daar misschien wat kunnen uitzoomen, want naast je indrukwekkende achtergrond in het leiden van digitale producten voor merken als Amazon, Meta, Netflix en Etsy, die ik al heb genoemd, ben je ook de oprichter van Next Gen Product Manager. Dat bedrijf biedt onder andere onderwijs aan, zoals een bootcamp van vijf weken om over te stappen van regulier, conventioneel productmanagement naar AI-productmanagement.

En eerlijk gezegd vertelt het feit dat je cursus überhaupt bestaat me dat niet alle conventionele vaardigheden op het gebied van productmanagement tegenwoordig nog volstaan. Er is een mentaliteit en vaardigheden nodig die meer op de volgende generatie zijn gericht. En hoewel je in je loopbaan misschien je teams zorgvuldig hebt kunnen samenstellen, is het logisch dat niet iedereen in je teams exact dezelfde competenties en houdingen had ten aanzien van AI en andere opkomende technologie. Mijn vraag is dus: wat is het eerste wat je als leider doet wanneer je merkt dat een team misschien niet allemaal op hetzelfde niveau zit als het gaat om het begrijpen, gebruiken en zelfs accepteren van opkomende technologieën zoals AI?

Jyothi Nookula: Ja, dit is een heel praktische, echte uitdaging en iets waar ik vaak mee te maken heb en steeds mee te maken blijf hebben. Ik ben een peoplemanager geweest die teams van verschillende omvang heeft geleid, van drie tot vijf tot tien tot twaalf mensen. Ik heb dat hele spectrum doorlopen. Het verschil in vaardigheden en comfort met AI is het grootste dat ik in mijn loopbaan bij welke technologie of verandering dan ook heb gezien.

Dit is iets wat ik als eerste doe wanneer ik met dit probleem te maken krijg: ik splits het op in twee afzonderlijke kwesties. De eerste kwestie is competentie, waarbij mensen niet weten hoe ze effectief met AI moeten werken. De tweede is houding, waarbij mensen sceptisch, terughoudend of zelfs angstig zijn.

Je moet vaststellen met welke van de twee je te maken hebt. Misschien is het een combinatie van beide. Maar het is belangrijk te erkennen welk probleem je probeert aan te pakken, want als je een houdingsprobleem behandelt alsof het een competentieprobleem is, maak je het alleen maar erger. Bij competentietekorten is mijn eerste stap het creëren van een gedeelde context door te doen, niet door te leren.

Dat is dezelfde filosofie die ik mijn studenten leer in mijn cursus AI-productmanagement van vijf weken: ze leren door te doen en niet alleen door theorie. Ik stuur mensen dus niet graag naar trainingen of vraag ze tutorials te bekijken. In plaats daarvan verwerk ik AI onmiddellijk in onze echte workflows, met concrete resultaten.

Het gaat om het integreren van Claude of GPT om sprintretrospectives te schrijven, thema’s samen te vatten, diepgaand onderzoek te doen of samenvattingen van gebruikersonderzoek te maken. Iets waarbij mensen de tool echt werk voor hen zien doen en deze niet noodzakelijk zien als iets dat hen binnen twee weken zal vervangen. Tijdens vergaderingen vraag ik mensen: vertel eens over iets waarbij AI je heeft geholpen sneller te werken, of vertel me een inzicht dat je zonder AI niet zou hebben ontdekt. Die gedeelde ervaringen worden vervolgens de basis voor het gezamenlijk opbouwen van competentie.

Voor houdingsproblemen, die meer met weerstand of angst te maken hebben, denk ik dat je het beste met nieuwsgierigheid kunt beginnen en niet met evangelisatie. Tijdens mijn één-op-één-gesprekken vraag ik meestal: wat is hier je echte zorg? En daarna houd ik mijn mond en luister ik. Want meestal komt er uit die gesprekken iets legitiems naar voren. Mensen zeggen bijvoorbeeld: ik heb het gevoel dat dit mijn vak minder waardevol zal maken.

Of: ik vertrouw de uitvoer niet, omdat ik die niet volledig kan controleren. Of: ik heb het gevoel dat ik achterop raak en dat het overweldigend is. Dat zijn echte zorgen. En ik heb geleerd dat je iemand niet door logisch redeneren van angst kunt afbrengen. Wat je wel kunt doen, is de angst erkennen, normaliseren en vervolgens een pad vooruit laten zien.

Bij iemand die bang is dat zijn vak minder waardevol wordt, laat ik zien hoe AI het voorbereidende werk kan afhandelen, zodat die persoon zich kan richten op genuanceerd werk waarvoor veel beoordelingsvermogen nodig is en waar hij eerder nooit tijd voor had. Bij iemand die zich zorgen maakt over verificatie zeg ik: goed, laten we samen evaluatiekaders opstellen.

Zo worden ze experts in kwaliteitsborging voor AI. Iets anders wat ik heel goed heb zien werken, is het snel identificeren van deze brugfiguren. In elk team zijn er mensen die van nature nieuwsgierig zijn naar AI. Ze experimenteren er voortdurend mee, zijn vernieuwend, praktisch ingesteld en behalen resultaten.

Ik geef deze mensen expliciet toestemming om te delen wat goed werkt. Op een laagdrempelige manier kun je bijvoorbeeld tijdens stand-ups korte kennissessies houden. Zo ontstaat leren van collega tot collega. Wanneer mensen zien dat een collega AI gebruikt en resultaten behaalt, staan ze meer open om het zelf te proberen dan wanneer een leider van bovenaf zegt: ga dit doen.

En de laatste stap kan misschien wat gevoelig liggen: ik maak snel duidelijk dat vaardigheid met AI een basiseis begint te worden. Ik heb begrip voor de leercurve en veel geduld met het proces, maar ik ben duidelijk over de richting: dit is niet optioneel. Net zoals we allemaal moesten leren werken met agileprocessen, analytics of bijvoorbeeld eerst ontwerpen, maakt dit nu deel uit van het werk.

Ik heb gemerkt dat de combinatie van veel ondersteuning en hoge standaarden — het stellen van een duidelijke verwachting — angst vermindert. De teams die ik het meest heb zien worstelen, zijn de teams waarin leiders onduidelijk zijn over de verwachtingen en ook geen echte ondersteuning bieden. Daar ontstaan wrok en veel machteloosheid.

Het doel is dus niet om iedereen onmiddellijk op hetzelfde niveau te krijgen. Het doel is om iedereen in dezelfde richting te laten bewegen, met psychologische veiligheid en praktische hulpmiddelen.

Galen Low: Dat vind ik geweldig. Ten eerste ben ik blij met het onderscheid tussen competentie en houding. En toen je dit beschreef, dacht ik: dit is bijna een combinatie van verandermanagement en teambuilding die zich in real time ontvouwt.

We hebben de neiging om verandermanagement te zien als iets wat je doet wanneer er een grote verandering wordt uitgerold. Bijna als een eenmalig initiatief. Maar dit lijkt meer op dagelijks verandermanagement met een team. Ondersteund, niet simpelweg: ga dit zelf leren omdat het moet. Die duidelijkheid bouwt het team daadwerkelijk op, evenals de gezamenlijke competentie en houding van het team, omdat het wat platter en meer vanuit de basis georganiseerd is. Er is meer duidelijkheid. Ik wil het geen groepsdruk noemen, maar het is wel steun van collega’s.

We delen kennis en informatie. En ik vind het geweldig wat je zei over de legitieme zorgen rond AI: het gevoel dat je achterop raakt, het gevoel dat er niet genoeg tijd is om dingen te doen, en het gevoel dat je vak minder waardevol wordt. Waarschijnlijk is er geen betere manier om daar een pad vooruit in te vinden dan door te zien hoe collega’s daar daadwerkelijk mee omgaan en het in hun dagelijkse werk toepassen, in plaats van alleen theoretische zaken te bespreken.

Je doet het samen. Dat vind ik echt geweldig. Ik ben trouwens een groot voorstander van leren door te doen, dus ik ben blij om te horen dat dit ook onderdeel is van de manier waarop je lesgeeft. En eerlijk gezegd sprak die duidelijkheid me erg aan. Je standaarden zijn hoog en je verwachtingen zijn hoog, maar de ondersteuning is er. Die duidelijkheid helpt ons vooruit.

Want de keuze tussen de vraag of dit slechts een voorbijgaande trend en hype is die je kunt negeren, of dat het net zo normaal wordt als typen, is eigenlijk al gemaakt. We zijn dat punt misschien al voorbij, of in elk geval is die beslissing organisatorisch al genomen door veel van de mensen met wie je hebt gewerkt. Je kunt AI niet negeren. Laten we er dus komen, maar we moeten wel samen vooruitgaan.

Jyothi Nookula: Ja.

Galen Low: Je noemde een paar dingen die bijna kleine experimenten of pilots zijn om mensen praktische ervaring met AI te geven en hun competentie en vertrouwen op te bouwen. Ik kan me voorstellen dat er veel manieren zijn waarop dit kan worden uitgebreid en waarop AI kan worden gebruikt bij de ontwikkeling van producten die zelf ook intrinsiek AI-producten zijn.

Kun je misschien enkele voorbeelden geven van andere manieren waarop jouw teams AI hebben gebruikt bij het ontwerpen en ontwikkelen van producten?

Jyothi Nookula: Ja. Ik kan je daar concrete voorbeelden van geven over de volledige productontwikkelingscyclus.

Galen Low: Geweldig.

Jyothi Nookula: Laten we beginnen met ontdekking en onderzoek. AI gebruiken om het genereren van inzichten drastisch te versnellen. Normaal gesproken doen we veel gebruikersonderzoek, bijvoorbeeld vijftien tot twintig gesprekken. In plaats van een week te besteden aan het identificeren van thema’s, voeren we de transcripten in Claude in en vragen we het om patronen, tegenstrijdigheden of randgevallen te identificeren.

Maar dit is belangrijk: je neemt de uitvoer niet zomaar over. We beoordelen die nog steeds samen met de onderzoeker, die de resultaten controleert, uitdaagt en verfijnt. Die mens in de lus is heel belangrijk. AI levert binnen een uur een zeer sterke eerste versie in plaats van binnen een week. De onderzoeker kan zijn tijd besteden aan werk waarvoor veel beoordelingsvermogen nodig is: bepalen welke inzichten er echt toe doen, welke inzichten onze aannames ter discussie stellen en waarin we ons vervolgens verder moeten verdiepen. De onderzoeker en de productmanager kunnen samenwerken om die patronen te identificeren.

Hetzelfde geldt voor supporttickets. Als je product al op de markt is, is het aantal supportvragen altijd enorm. In plaats van deze tickets handmatig te moeten beoordelen om patronen te ontdekken, analyseren we duizenden klantgesprekken om vast te stellen wat de pijnpunten zijn.

Hoe groot zijn die pijnpunten? Hoeveel gebruikers worden erdoor geraakt? AI brengt deze patronen naar boven op een manier die we handmatig niet zouden kunnen realiseren, simpelweg vanwege de enorme hoeveelheid informatie die via supportkanalen binnenkomt. Als productmanager zie je vervolgens zowel het gebruikersonderzoek als de patronen in het supportvolume.

Je bevindt je dan in een betere positie om te bepalen wat prioriteit heeft en moet worden opgelost. Welke functies moet je daadwerkelijk prioriteit geven op je routekaarten? Zelfs bij documentatie en communicatie elimineert AI bijvoorbeeld het routinematige werk. We hebben mensen AI zien gebruiken om PRD’s te schrijven, sprintreviews samen te vatten en updates voor belanghebbenden te maken.

Dat zijn allemaal zaken waarvoor AI sterke eerste versies kan maken. Een van mijn productmanagers zei: ik besteedde vroeger 30% van mijn tijd aan het schrijven van documentatie, en nu besteed ik 30% van mijn tijd aan het bewerken en verfijnen van die documentatie. Dat is veel waardevoller, omdat je nu een goed uitgangspunt hebt om op voort te bouwen.

We gebruiken AI ook om documentatie toegankelijker te maken. Iemand kan bijvoorbeeld vragen: wat hebben we besloten over het herontwerp van deze betaalstroom? Vervolgens krijgt die persoon een antwoord dat is samengesteld uit drie verschillende Slack-discussies, vergaderingen en een PRD. AI helpt dus ook om documentatie beter toegankelijk te maken.

Over de hele productontwikkelingscyclus heen — van experimenteren en documenteren tot de manier waarop we met engineering samenwerken — zien we veranderingen. Aanvankelijk waren wij als productmanagers eigenaar van PRD’s en schreven we die. PRD’s verdwijnen niet. Ze blijven bestaan. Maar er komt een nieuw onderdeel bij: een prototype. Waarom zou je alleen een lijst met user stories geven als je iets ook kunt uitproberen en prototypen? Je kunt een eenvoudig product maken, een eerste indruk krijgen van de product-marktfit en het prototype als idee aan engineering overdragen.

Een nieuwe vorm van een PRD bevat dus een document dat de visie vastlegt, de evaluaties, hoe het moet werken, wanneer het moet werken, hoe goed eruitziet en hoe slecht eruitziet. Daarnaast heb je een prototype dat de interactie beschrijft, de manier waarop gebruikers ermee kunnen werken en hoe het product moet worden voorgesteld. We zien dit dus in de hele productontwikkelingscyclus.

Galen Low: Ik vind het geweldig dat je het daarheen bracht, want ik sprak onlangs met een aantal productmensen en we debatteerden over de vraag of PRD’s — het productvereistendocument — dood zijn.

Een van hen zei nee, omdat je die gedachten nog steeds moet hebben en die gedachten nog steeds goed moeten zijn. Ze had een kleine app gebouwd die helpt om tot die goede gedachten te komen en de basis te leggen voor waarom je product bij de markt past, welke functies het moet hebben en wat prioriteit heeft.

Daarna koppelden we dat opnieuw aan prototyping. Je hebt nog steeds die visie nodig. AI komt niet vanzelf met alle creatieve antwoorden, en dat is dan genoeg. Je moet nog steeds een strategische visie hebben op wat het product doet, hoe het in de behoeften van gebruikers voorziet en hoe je het naar de markt brengt.

Maar ik vind het idee interessant dat het werk van iemand daardoor verschuift. Ik ken veel productmanagers en het is inderdaad zwaar op het gebied van documentatie. Dat is ook een superkracht geworden, want zoals je zegt besteden ze nu het grootste deel van hun tijd aan het bewerken ervan. Maar documentatie maakte al deel uit van het proces. Dat betekent dat je AI erop kunt trainen.

Dat is anders bij mensen die eerder niets opschreven. Zij moeten nu beginnen met documenteren om er daadwerkelijk voordeel uit te halen. Productmanagers lopen dus eigenlijk voorop. En ik vind het idee van machines voor eerste versies geweldig. Ik had wel een vraag, omdat je er in de projectwereld wat dieper op inging. Ik ken veel mensen die zeggen: ja, het is geweldig voor een eerste versie.

Gebruiken jouw teams alleen die bot voor de eerste versie en gaan ze daarna door naar de andere onderdelen van de keten? Of voeren ze het resultaat terug zodat de machine beter kan worden en steeds betere eerste versies kan maken door hun bewerkte versies terug te voeren?

Jyothi Nookula: Ja, we noemen dit eenmalige invoer. Mensen nemen aan dat AI iets eenmaligs is: je voert het iets aan, krijgt een rapport en kunt ermee verder. Dat is zelden het geval. Meestal krijg je een sterke eerste versie, maar vervolgens herhaal je het proces, voeg je je eigen gedachten toe en geef je die weer aan AI met de vraag om je standpunten te bekritiseren of aan te geven waar verbetering en verfijning mogelijk zijn.

Daarna geeft AI zijn gedachten en zeg je bijvoorbeeld: dit gedeelte klopt, maar met dat andere deel ben ik het niet eens. Het is alsof je een partner hebt met wie je voortdurend kunt verfijnen totdat je echt tevreden bent met het resultaat. Als je AI-systemen behandelt als een manier om iets in te voeren, één antwoord te krijgen en daar vervolgens blindelings mee verder te gaan, werkt dat zelden.

Wat ik de meeste waarde zie opleveren, is iteratief met AI werken en het resultaat verbeteren. Daarom zeggen we: het is gemakkelijk om te leren hoe je iets moet doen, maar het is heel moeilijk om smaak te leren. Smaak is nog steeds iets waarvan een productmanager eigenaar moet zijn.

Galen Low: Die smaak vind ik mooi. Merk je dat veel mensen denken: oké, nu bestaat 30% van mijn werk niet alleen uit het bewerken van documentatie, maar ook uit praten met een robot? Terwijl een groot deel van de rol van productmanager, zoals je zegt, heel menselijk is. Je voert gebruikersinterviews en onderzoek uit. Je krijgt een enorme hoeveelheid gegevens waar je geen individuele relatie mee hebt, en AI kan daar zeker bij helpen. Maar merk je dat er vanuit het perspectief van houding een verlies aan menselijkheid ontstaat in productmanagement?

Misschien is een van de zorgen: ik besteed het grootste deel van mijn tijd aan praten met een robot en het onderwijzen van een robot, en dat is gewoon niet hetzelfde als praten met een mens.

Jyothi Nookula: Ik weet niet of het zozeer gaat om praten met een robot. Zoals ik zei: als jij alleen met dat AI-systeem praat, is dat iets anders.

Maar je moet je belanghebbenden nog steeds overtuigen. Je moet met je engineeringteam praten. Productmanagers bevinden zich in een soort knooppunt waarin ze verschillende teams met elkaar moeten verbinden. In zekere zin is het dus meer alsof je een behulpzame assistent hebt met wie je kunt brainstormen. Ik heb mijn productmanagers, leiders en collega’s dat daadwerkelijk zien gebruiken.

Ze praten ermee om ideeën te brainstormen. Het is dus minder robotachtig en meer een manier om op gang te komen en dingen uit te zoeken. Je hebt altijd een metgezel die 24 uur per dag, zeven dagen per week beschikbaar is om mee te praten.

Galen Low: Om de advocaat van de duivel te spelen: je hebt bij bedrijven gewerkt waar ik er redelijk zeker van ben dat iemand naar je toe is gekomen met de vraag: Jyothi, waarom kunnen we dit proces niet gewoon automatiseren?

Waarom moet er een mens in de lus zitten? Kunnen we niet gewoon al die supporttickets verzamelen, ze door een agent laten verwerken, de prioriteiten voor nieuwe functies laten bepalen, de nieuwe functies laten ontwikkelen en ze uitbrengen zonder dat iemand erbij betrokken is? Je hoeft me niet te vertellen of dat is gebeurd, maar het mag wel.

Mijn vraag is misschien ook: hoe verzet je je tegen een technologie-eerstbenadering in plaats van een mens- of gebruiker-eerstbenadering, zeker op het niveau waarop jij hebt gewerkt? Bij sommige van deze grote technologiebedrijven is er druk om te zeggen: ja, maar kunnen we deze technologie niet gewoon gebruiken en later bepalen wat we ermee moeten doen?

Hoe pak je het aan om daartegenin te gaan en het belang van een mens in de lus te verdedigen?

Jyothi Nookula: Ja, dit kom ik vaak tegen, ook wanneer ik deze bedrijven adviseer en bij mijn studenten die zeggen: dit is de situatie waarin ik zit, hoe moet ik hiermee omgaan? Dit is momenteel bijna een ziekte: iedereen wil met AI beginnen. Ten goede of ten kwade heb ik het gevoel dat we gebruikers en hun problemen vergeten en met technologie beginnen. Dat is heel contra-intuïtief.

Het moeilijkste hieraan is dat het echt lastig is om weerstand te bieden, omdat de institutionele prikkels allemaal de verkeerde kant op wijzen. Je hebt bestuurders die dezelfde drie artikelen hebben gelezen over het existentiële belang van AI. Je hebt investeerders die tijdens elke kwartaalpresentatie vragen wat je AI-strategie is.

En engineers zijn oprecht enthousiast; je ziet dat tijdens hackathons. De druk om iets met AI te doen is enorm. Maar ik zeg altijd dat je moet teruggaan naar de eerste principes van productontwikkeling: begin bij de gebruiker en het probleem, niet bij het algoritme. Ik zeg dit ook in mijn lessen: gebruikers vóór algoritmen.

Wanneer iemand enthousiast naar je toe komt of een vicepresident zegt: hé, er is deze nieuwe AI-mogelijkheid, of het nu multimodaal, spraakgestuurd of iets anders is, kun je niet winnen door nee te zeggen. In plaats daarvan formuleer ik het anders: dat is een interessante technologie. Welk probleem proberen we hiermee op te lossen? Ik laat hen het werk doen om het probleem te formuleren, niet om hen erin te laten lopen, maar door te vragen: neem me mee door de dag van je gebruiker.

Waar past dit in? Wat proberen gebruikers vandaag te doen? En wat is het alternatief als dit niet bestaat? Meestal gebeurt dan een van drie dingen. Ten eerste realiseren ze zich dat het een oplossing voor een niet-bestaand probleem is. De energie dooft dan vanzelf uit, omdat ze geen overtuigende gebruikersbehoefte kunnen formuleren.

Er is dus geen confrontatie nodig. Of ze ontdekken dat het een echt probleem is, maar dat AI-technologie niet de beste oplossing is. Misschien kan het beter worden opgelost met een betere gebruikerservaring, betere onboarding of het herstellen van een ander kapot proces. Misschien is geen AI nodig, maar een eenvoudiger deterministische technologie. Ze realiseren zich dan dat AI waarschijnlijk overkill is.

De beste uitkomst is dat ze een echt probleem vinden waarvoor AI daadwerkelijk iets nieuws mogelijk maakt. Dat is goud, en daar ontstaat echte innovatie.

Bij Amazon doen we beroemd genoeg aan het proces van achteruit werken: we schrijven een persbericht. Ik laat mijn productmanagers of collega’s met wie ik werk daadwerkelijk een persbericht voor het product schrijven. Daarin moeten ze de impact van het product beschrijven en eventueel alvast een getuigenis van een gebruiker opnemen. Het is erg moeilijk om iets geweldigs te veinzen wanneer je die oefening doet. Dat helpt enorm bij het voeren van dit soort gesprekken.

Er zijn ook momenten waarop iets van bovenaf komt, bijvoorbeeld omdat de CTO een beslissing heeft genomen. Het is dan moeilijk om naar een CTO te gaan en daartegen te vechten. In zulke gevallen heb ik geleerd het anders te formuleren: goed, als we dit gaan doen, laten we het dan op zijn minst op een nuttige manier doen. Laten we een echt probleem vinden en oplossen, in plaats van tegen deze specifieke toepassing te vechten.

Ik verleg het gesprek dan naar een ander probleem waarvoor het echt nuttig zou kunnen zijn. We hebben de gegevens ervoor, we hebben er een gebruikssituatie voor en het rendement op de investering klopt. Ik werk al die voorstellen uit en zeg: ja, laten we het gebruiken, maar dit probleem is urgenter dan dat andere probleem.

Dit zijn enkele technieken die in het begin van mijn loopbaan voor mij hebben gewerkt. Vroeger dacht ik dat mijn taak was om de productvisie tegen afleidingen te beschermen. Nu begrijp ik dat mijn taak is om energie te kanaliseren: enthousiasme over nieuwe technologie in goede banen leiden en mensen helpen die technologie op de juiste manier te gebruiken voor resultaten die er echt toe doen.

Het probleem is niet het enthousiasme zelf, maar hoe we dat enthousiasme kunnen kanaliseren op een manier die onze gebruikers helpt. Daarom moeten we altijd teruggaan naar de eerste principes van productontwikkeling: denk aan de gebruiker en het probleem, in plaats van te beginnen bij de technologie. Je zou ook niet zeggen: ik heb vandaag een Word-document geopend, wat moet ik schrijven? Begin maar gewoon te schrijven.

Galen Low: Waar is Clippy als je hem nodig hebt? Dat was eerlijk gezegd een masterclass in het kort over het navigeren door productpolitiek. Ik vind jouw kijk op de rol heel nuttig. Ik ken veel productmensen en als projectpersoon herken ik het ook: je voelt je de poortwachter en beschermer. Je bent de verdediging.

En degene die weerstand biedt, degene die de lastige vragen stelt en mensen op hun plaats zet zodat we kunnen vasthouden aan wat we oorspronkelijk wilden doen. Maar ik vind het idee van energie kanaliseren erg goed, omdat het tot goede dingen kan leiden. Je derde punt interesseerde me: oké, we doen dit, laten we het op zijn minst nuttig maken.

Dat is geen perspectief dat ik vaak hoor, maar ik vind het verfrissend. Zo weet ik dat bedrijven werken, op elke schaal. Soms krijg je geen keuze. Het hoeft niet altijd te zijn: laat me die beslissing schriftelijk vastleggen zodat ik later kan zeggen dat ik gelijk had. Het kan ook constructief zijn.

De energie kan voordeel opleveren. Ik kom uit een mensgerichte ontwerpachtergrond, dus ik hoor altijd graag dat mensen gesprekken terugbrengen naar de gebruiker en het voordeel voor de gebruiker. Het is zo’n nuttige herformulering: welk probleem proberen we op te lossen? Daarmee laat je hen er ook over nadenken.

Het is zelfs samenwerkend. In plaats van defensief te zoeken naar een manier om nee te zeggen en politieke spelletjes te spelen, zeg je: goed, laten we dit samen doordenken en de beste uitkomst vinden. Over uitkomsten gesproken: dat idee van het persbericht ga ik stelen. Wij werken graag achteruit, maar niet zo ver dat we bij een persbericht uitkomen. Toch is dat het hoogtepunt van het beschrijven van wat je hebt gedaan, waarom je het hebt gedaan en wat de impact ervan is.

Wat een nuttig hulpmiddel om mensen te laten nadenken over de uitkomst, en niet alleen over het uitbrengen ervan. Niet alleen opdrachten aannemen en het werk uitvoeren, maar echt verbeelden naar welke uitkomst we toewerken. Wat gaat het voor mensen doen? Waar willen we trots op zijn wanneer we klaar zijn? Dat is geweldig. Ik vind het prachtig.

Jyothi Nookula: Ja, ik vind dat concept van het persbericht geweldig. Ik heb het altijd gebruikt, ook vele jaren nadat ik AWS had verlaten. Ik gebruik het nog steeds in mijn werk. Het brengt een bepaald perspectief.

Galen Low: Ik vind het geweldig. Het is zo nuttig.

Misschien kunnen we afronden door het een beetje over de toekomst te hebben. Volgens mij is tijdens dit gesprek duidelijk geworden dat productmanagement behoorlijk aan het verschuiven is. De producten zelf veranderen, de tools en methoden veranderen en de verwachtingen rond technisch begrip, zakelijk inzicht en leveringsstrategie veranderen ook.

Wat zijn de drie of vier belangrijkste dingen die een productmanager die geïnteresseerd is in het ontwikkelen van AI-producten op zijn cv of in zijn portfolio moet hebben om op te vallen?

Jyothi Nookula: Bedankt dat je deze vraag stelt, want het is een heel praktische vraag. Eerlijk gezegd is wat ik in een cv zoek de afgelopen twee jaar dramatisch veranderd.

Dit is wat iemand tegenwoordig echt onderscheidt. Ten eerste: bewijs dat iemand iets met AI heeft gebouwd, niet alleen dat diegene erover praat. Als hiringmanager of recruiter heb ik een vacature die ik moet invullen. Ik zoek geen ruimte voor onderzoek. Ik wil zien dat je daadwerkelijk een AI-native functie of een AI-native product hebt uitgebracht.

Niet alleen iets als: ik werkte in een team dat AI gebruikte, of ik droeg bij aan een strategie. Ik wil weten welk probleem je met dit AI-product oploste, wat AI precies deed, hoe je het hebt geëvalueerd en welke lessen je hebt geleerd die je verrasten. Voor mensen die AI-producten hebben uitgebracht, is dat logisch.

Maar veel mensen hebben nog geen AI-producten uitgebracht en vragen: hoe communiceer ik dit? Daarom zeg ik: bouw zelf iets. Bouw enkele zijprojecten. Dat is ook iets wat ik in mijn lessen zeg, en we doen veel praktijkprojecten. Tegen de tijd dat studenten klaar zijn, hebben ze daadwerkelijk een volledig portfoliopakket opgebouwd.

Ik zeg ook: begin ze niet als projecten, maar zet ze om in producten. Het is niet zo dat je iets afmaakt, je laptop dichtklapt en weggaat. Dat is een project. Je moet het omzetten in een product, het delen met je vrienden en gemeenschap en hen het product laten gebruiken.

Vraag hen om feedback en gebruik die feedback vervolgens om het product te verbeteren. Voeg bijvoorbeeld een Stripe-integratie toe en breng één dollar of vijftig cent in rekening. Het bedrag maakt niet uit, maar maak er een product van dat inkomsten genereert. Als dat past bij de manier waarop je product moet worden omgezet, maak het dan zo echt mogelijk. Dat heeft veel meer impact op je cv dan alleen vertellen dat je aan een AI-project hebt gewerkt.

Veel mensen kunnen projecten doen. Je moet producten bouwen, op je werk of daarbuiten. Het tweede belangrijke punt is aantonen dat je technisch vaardig bent. Daarmee bedoel ik niet dat je een machinelearningengineer moet zijn. Ik verwacht niet dat je kunt programmeren, maar ik wil wel bewijs zien dat je geloofwaardige gesprekken met engineers kunt voeren over de werking van deze systemen.

Op je cv kan dat bijvoorbeeld blijken uit evaluatiekaders die je hebt gebruikt of uit hoe je grootschaliger testen hebt uitgevoerd. Welke afwegingen heb je gemaakt? Ging het om snelheid tegenover kwaliteit, kosten tegenover mogelijkheden, of bepaalde modeltypen en architecturen waarmee je hebt gewerkt?

De taal die je gebruikt is belangrijk. Als je cv zegt: ik gebruik AI om de gebruikerservaring te verbeteren, vertelt dat me niets. Maar als je zegt: we hebben deze RAG-architectuur gebouwd om hallucinaties in reacties van de klantenservice te verminderen en de nauwkeurigheid van X naar Y verbeterd, dan weet ik wat je hebt gebouwd.

De test die ik meestal gebruik is: kun je aan een engineer uitleggen waarom we voor deze gebruikssituatie techniek A zouden moeten gebruiken in plaats van techniek B? En kun je aan een zakelijke belanghebbende uitleggen waarom die technische beslissing belangrijk is en welke invloed ze heeft op zakelijke resultaten?

Als productmanager bevind je je op dit kruispunt. Je belangrijkste rol is technische mogelijkheden vertalen naar zakelijke resultaten en zakelijke waarde, en dat vervolgens weer vertalen naar technische raamwerken. Dat is de AI-productmanager die het beste presteert.

Tot slot is ervaring met het navigeren door dubbelzinnigheid en snelle iteratie belangrijk. Zoals ik zei zijn AI-producten anders. Modellen worden bijgewerkt en mogelijkheden veranderen, dus je moet je comfortabel voelen bij dubbelzinnigheid. Dat moet ook op je cv zichtbaar zijn. Als je bijvoorbeeld vertelt dat je producten van nul naar één hebt gelanceerd of in snel bewegende omgevingen hebt gewerkt, zegt me dat je door die dubbelzinnigheid heen moest.

Ook een experimentele mentaliteit rond snel prototypen, testen en leren is belangrijk. Wanneer je zelfs je zijprojecten in producten omzet, beginnen al deze zaken samen te komen. Dit zijn enkele vaardigheden die iemand kunnen onderscheiden en sollicitanten kunnen helpen opvallen.

Waar ik niet naar op zoek ben, is absoluut geen soep van modewoorden. Je hoeft niet te zeggen: ik gebruik machine learning om synergieën te creëren en te optimaliseren. Dat vertelt me niets. Ook zes verschillende certificeringen op Coursera of zeggen dat je gepassioneerd bent door AI zullen je niet onderscheiden.

Als ik het patroon moet benoemen, is het leersnelheid. Hoe snel kun je bewegen? Hoe diep en technisch ga je? Begrijp je hoe deze systemen samenwerken? Als je probeert door te breken in AI-productmanagement en geen directe ervaring hebt, kun je die ervaring creëren. Je kunt iets bouwen. Niemand houdt je tegen.

Het is prima als je huidige werk geen AI-mogelijkheden biedt, maar niemand houdt je tegen om iets te bouwen. Je kunt ook schrijven over wat je leert terwijl je bouwt. Wanneer je begint te bouwen, kom je veel uitdagingen tegen. Lever een bijdrage, maak casestudy’s van AI-producten die je bewondert, analyseer ze grondig en bedenk vervolgens hoe je ze zou verbeteren.

De drempel om te beginnen is nu erg laag. Je hoeft geen groot team te hebben om je idee te bouwen. En in de sector hebben niet veel mensen tien jaar AI-ervaring of iets dergelijks. Iedereen is samen aan het uitzoeken hoe dit werkt. Het echte verschil wordt gemaakt door mensen die het werk daadwerkelijk doen om het uit te zoeken, tegenover mensen die wachten op toestemming.

Galen Low: Dat was zo’n goede beschrijving van die paradox.

Ik weet zeker dat je dit voortdurend van mensen hoort: maar ik ben productmanager, er kan toch niet van mij worden verwacht dat ik codeer? Maar er is een tussenlaag, en ik denk dat je die heel goed hebt uitgelegd. Misschien hoef je niet te coderen, maar je moet wel de woordenschat hebben om deze vertaling te maken en het zakelijke en gebruikersprobleem en de technische gevolgen te begrijpen.

Je moet ook een soort bouwersmentaliteit hebben, waarbij je genoeg van de technologie begrijpt om te weten waar frictiepunten kunnen ontstaan en wat er mis kan gaan. Het is niet alleen: ik deed wat me werd opgedragen bij groot technologiebedrijf X, dus ik ben een goede kandidaat. Zoals je zegt, weet je als hiringmanager dan niet of iemand door dubbelzinnigheid heen kan snijden, de gebruiker begrijpt of de taal spreekt van de multifunctionele teams waarmee die persoon werkt.

Het enige wat je weet, is dat iemand in een bepaalde functie bij een groot bedrijf X heeft gewerkt. Die persoon kan simpelweg iemand zijn geweest die de leiding van een ander volgde en niet noodzakelijkerwijs moedig of vooruitstrevend was, snel leerde of de snelheid en openheid had om ermee aan de slag te gaan en het vakmanschap te verbeteren, in plaats van te denken: dat is het probleem van iemand anders.

Jyothi Nookula: Daarom zeg ik: wacht niet op toestemming, doe het gewoon. De drempel om het nu te proberen is erg laag.

Galen Low: Jyothi, heel erg bedankt dat je vandaag tijd met me hebt doorgebracht. Het was erg leuk. Voordat ik je laat gaan: waar kunnen mensen meer over je leren?

Jyothi Nookula: Je kunt me vinden op LinkedIn onder Jyothi Nookula. Je kunt ook nextgenproductmanager.com bezoeken, waar je meer kunt leren over de cursussen die ik aanbied op het gebied van AI-productmanagement, agentische AI en de PM Accelerator.

Galen Low: Geweldig. Dat is fantastisch. Ik zet die links ook in de shownotes voor mensen die luisteren en in de beschrijving voor mensen die kijken. Jyothi, nogmaals heel erg bedankt.

Jyothi Nookula: Heel erg bedankt. Ik heb het enorm naar mijn zin gehad.

Galen Low: Goed mensen, dat was de aflevering van vandaag van de podcast van The Digital Project Manager. Als je dit gesprek interessant vond, abonneer je dan via het platform waarop je luistert. En als je nog meer praktische inzichten, casestudy’s en draaiboeken wilt, ga dan naar thedigitalprojectmanager.com. Tot de volgende keer, bedankt voor het luisteren.