
Productleider bij OpenAI vertelt hoe AI productmanagement op het hoogste niveau verandert

Kathy Korevec
Codex bij OpenAI

Ontdek hoe een productleider bij OpenAI AI gebruikt om productontdekking en prototyping te versnellen, terwijl productinzicht, vertrouwen en vakmanschap nadrukkelijk door mensen worden aangestuurd.
Kathy Korevec
Codex bij OpenAI

Key Takeaways
AI-verschuiving: AI geeft productmanagement een nieuwe vorm, met nadruk op ontwikkelaarstools die gebruikers centraal stellen en snelle prototyping.
Snelheidsrisico's: AI verhoogt de snelheid, maar brengt het risico met zich mee van 'valse snelheid' en oppervlakkige voltooiing van projecten zonder blijvende impact.
Focus op prototypes: Prototyping boven documentatie zorgt voor meer vaart, wat leidt tot snellere iteraties en eerlijkere beslissingen.
Vertrouwensprincipes: Steun op transparantie, correctie, consistentie en terughoudendheid om het vertrouwen van gebruikers in AI-producten te behouden.
Roldynamiek: AI vervaagt de grenzen tussen productmanagement, engineering en design, waardoor veelzijdigere productdenkers nodig zijn die het volledige ontwikkeltraject overzien.
Kathy Korevec is een bouwer die onder andere heeft gewerkt als productdirecteur bij Google Labs AI, vicepresident voor product en ontwerp bij Vercel en senior directeur productmanagement bij GitHub. Momenteel werkt ze aan Codex bij OpenAI. De rode draad is het creëren van ontwikkelaarstools met een niet-aflatende focus op gebruikersgerichtheid en oog voor detail.
We spraken met Kathy om te leren hoe AI productmanagement verandert bij de toonaangevende technologiebedrijven ter wereld. Dit is wat ze te zeggen had.
Een ‘chef die voor chefs kookt’ zijn
Ik ben altijd in de eerste plaats een bouwer geweest en pas daarna een productmanager.
Ik ben opgegroeid in de wereld van ontwikkelaarstools bij bedrijven als Heroku, GitHub en Vercel, wat een heel specifieke vorm van productmanagement is. Je brengt niet zomaar functies uit; je bouwt voor mensen die het meteen merken wanneer je een bocht hebt afgesneden. Het is alsof je een chef bent die voor chefs kookt. De lat ligt hoog en ze zullen het absoluut merken als er iets mis is met je saus.
Enkele van mijn favoriete momenten als PM waren helemaal geen traditioneel ‘PM-werk’. Bij GitHub heb ik delen van de documentatie herschreven en zelfs de website opnieuw ontworpen volgens mijn aanpak van DX-principes. Ik heb weekenden besteed aan het refactoren van mijn eigen website om er een paar honderd milliseconden af te halen, omdat de prestaties me dwarszaten. Ik hielp bij een project genaamd Papercuts, waarbij we honderden kleine ergernissen oplosten, omdat die details samen bepalen of mensen van je product houden of het slechts tolereren.
Dat is voor mij eigenlijk de rode draad geweest. Ik zie PM’s niet alleen als mensen die hiaten identificeren en opvullen, of als de ‘CEO van je product’. Ik zie het als het ongemakkelijk dicht op de details zitten. Dicht genoeg om je zorgen te gaan maken over dingen die niet op een roadmap verschijnen.
En nu zitten we in dit AI-moment, dat eerlijk gezegd een beetje voelt alsof je iedereen een jetpack geeft en hoopt dat ze niet tegen een boom vliegen.
Ik besteed ’s avonds en in het weekend veel tijd aan programmeren op basis van intuïtie, waarbij ik met AI-agents eenvoudige kleine tools bouw. Je kunt in één middag van idee naar werkend product gaan, wat ongelooflijk is. Tegelijkertijd zijn de fundamenten belangrijker dan ooit. Begrijpen hoe systemen werken, welke afwegingen er zijn en hoe dingen daadwerkelijk onder de motorkap werken, is wat het verschil maakt tussen iets dat wordt uitgebracht en iets dat standhoudt.
Anders eindig je met een kerkhof vol onafgemaakte projecten en mysterieuze bugs.
Mijn reis naar dit moment draaide dus niet echt om het veranderen van hoe ik werk. Het ging erom daarop voort te bouwen. Dicht bij het vak blijven. En zelf dingen bouwen.
Ik zie PM’s niet alleen als mensen die hiaten identificeren en opvullen, of als de ‘CEO van je product’. Ik zie het als het ongemakkelijk dicht op de details zitten.

De afstand tussen idee en validatie verkleinen
Tot heel recent gaf ik leiding aan product voor een team bij Google Labs dat AIDA heette, wat stond voor AI-ontwikkelaarsondersteuning.
We werkten behoorlijk diep in de stack. Vroege codeermodellen, trainingsgegevens voor code die aan Gemini werden gevoerd, en vervolgens omhoog in de abstractielaag naar producten als Colab Composer en Jules. De verschuiving ging van ‘Kunnen we code genereren?’ naar ‘Kunnen we mensen daadwerkelijk helpen om van begin tot eind echte software te bouwen?’
De organisatie waaraan ik leiding gaf, was dus duidelijk hybride. Deels onderzoek, deels product en deels: ‘We gaan deze week iets eenvoudigs uitbrengen en kijken of iemand het gebruikt.’ Onze gebruikers varieerden van professionele ontwikkelaars tot mensen die nog nooit code hadden geschreven. Dat is een bescheiden makend publiek, omdat je tegelijkertijd zowel diepgang als toegankelijkheid moet bieden.
Het leveringsmodel weerspiegelde dat. Veel snelle iteratie, korte feedbackcycli tussen modelmogelijkheden en productervaring, en de bereidheid om dingen weg te gooien als ze niet aansloegen. Het is minder routekaart en meer doelgerichte verkenning.
Nu werk ik bij OpenAI aan Codex, wat een soort moment is waarop de cirkel rond is. Codex begon als een model en ontwikkelt zich nu tot een agent en een applicatielaag binnen ChatGPT die mensen helpt om daadwerkelijk werk gedaan te krijgen. Code schrijven, werkstromen automatiseren en systemen aan elkaar koppelen.
In beide gevallen is de rode draad dus hetzelfde. Tools bouwen die de afstand verkleinen tussen een idee en iets dat in de echte wereld draait.
Waarom PM’s zich moeten richten op prototypegestuurde productontwikkeling

Ik ben gestopt met het behandelen van specificaties als het belangrijkste werkproduct bij productontwikkeling. Het is een verschuiving waar ik al mee was begonnen, maar AI heeft dit versneld.
In het begin van mijn carrière, vooral bij GitHub en Heroku, realiseerde ik me hoeveel momentum ertoe doet. Echt gebruik doet ertoe. Je leert meer van iets in productie dan je ooit zult leren van een perfect geschreven document.
Wat AI heeft gedaan, is die filosofie nog verder comprimeren.
In plaats van nu een lange specificatie te schrijven en er een week over te discussiëren, bouw ik zelf een ruwe versie van het product. Of ik programmeer op gevoel een prototype in een dag of twee. Iets waarop je kunt klikken, dat je kunt laten mislukken en waarop je kunt reageren. Dat verandert alles.
Je gaat van “Wat denken we dat er zal gebeuren?” naar “Wat gebeurt er daadwerkelijk wanneer je dit gebruikt?” Het maakt van veel abstracte discussie iets concreets.
Het verandert ook de rol van de PM. Je geeft niet alleen vorm aan ideeën; je test ze rechtstreeks onder druk. Je staat dichter bij de implementatie, waardoor je verkeerde aannames eerder ontdekt.
Het resultaat is natuurlijk snelheid. We brengen dingen sneller uit, stoppen sneller met ideeën en verfijnen goede ideeën sneller.
De belangrijkste verandering is echter dat onze beslissingen eerlijker zijn.
Waarom de nadelen van AI subtiel, maar belangrijk zijn
Maar er zijn zeker ook nadelen.
Eén daarvan is wat ik "schijnsnelheid" zou noemen. Je hebt het gevoel dat je ongelooflijk snel vooruitgaat omdat je veel produceert. Code, prototypes, documentatie. Maar niet alles is daadwerkelijk goed of bruikbaar. Je kunt veel oppervlakte creëren zonder echte diepgang.
Een ander probleem is kwaliteit en vertrouwen. Door AI gegenereerde code kan verrassend goed en tegelijkertijd vol vertrouwen fout zijn. Als je niet begrijpt wat er onder de motorkap gebeurt, kun je uiteindelijk dingen uitbrengen die kwetsbaar, onveilig of moeilijk te onderhouden zijn.
En dan is er nog een subtiel punt. Het is gemakkelijker dan ooit om ergens aan te beginnen. Het is niet per se gemakkelijker om iets goed af te maken. We gaan veel meer halfafgebouwde producten, verlaten prototypes en systemen zien die min of meer werken totdat ze dat niet meer doen. Ik heb er zelf een paar gebouwd.
Het algemene resultaat is dus enigszins paradoxaal. We zijn sneller dan ooit bij iets aangekomen. We zijn niet automatisch beter geworden in het omzetten daarvan in iets dat standhoudt.

Gedachten van Kathy
Het is gemakkelijker dan ooit om ergens aan te beginnen. Het is niet per se gemakkelijker om iets goed af te maken. We gaan veel meer halfafgebouwde producten, verlaten prototypes en systemen zien die min of meer werken totdat ze dat niet meer doen. Ik heb er zelf een paar gebouwd.
Waarom vier principes producten van een flits naar vertrouwen brengen
Ik wil wat meer delen over vertrouwen, omdat ik denk dat productleiders het risico van onzichtbare software van lage kwaliteit onderschatten.
AI maakt het ongelooflijk gemakkelijk om dingen te bouwen. Je kunt hulpmiddelen, functies en zelfs volledige apps opzetten in een fractie van de tijd die dat vroeger kostte. Dat klinkt als alleen maar voordeel, maar het resultaat is veel meer software die min of meer werkt.
Halfafgebouwde functies, kwetsbare systemen, dingen die snel zijn gebouwd en nooit robuust zijn gemaakt. Ze falen niet luidruchtig. Ze gaan in de loop der tijd gewoon achteruit. Ze werken op subtiele manieren niet meer, zorgen voor verwarring of tasten stilletjes het vertrouwen aan.
Het risico is niet alleen technische schuld in de traditionele zin. Het is vertrouwensschuld.
Hier zijn vier principes die ik nuttig heb gevonden:
- Maak het systeem begrijpelijk. Gebruikers moeten kunnen begrijpen wat de AI doet en waarom, in elk geval op hoofdlijnen. Geen volledige technische transparantie, maar genoeg zodat het niet voelt als een zwarte doos die willekeurige beslissingen neemt. Dat kan zo eenvoudig zijn als het tonen van stappen, het zichtbaar maken van aannames of gebruikers laten bekijken wat er is veranderd.
- Ontwerp voor correctie. Het systeem zal soms fouten maken. Dat staat vast. Wat telt, is hoe gemakkelijk een gebruiker kan ingrijpen, de fout kan herstellen en verder kan gaan. Als het corrigeren van het systeem pijnlijk is, daalt het vertrouwen snel. Als het gemakkelijk is, blijven mensen het gebruiken, zelfs als het niet perfect is.
- Bouw voor consistentie in plaats van voor een wauw-effect. Veel AI-producten optimaliseren voor het “wauw”-moment. Eén echt indrukwekkende interactie. Vertrouwen komt juist van het tegenovergestelde —het systeem dat steeds opnieuw doet wat je verwacht, zonder verrassingen. Vooral bij hulpmiddelen voor ontwikkelaars is voorspelbaarheid belangrijker dan magie.
- Toon terughoudendheid. Alleen omdat het systeem iets kan doen, betekent dat niet dat het dat ook moet doen. Als je te veel automatiseert of te veel controle overneemt, voelen gebruikers dat. Ze verliezen hun gevoel van zeggenschap. De beste producten geven je meer slagkracht zonder je buiten de beslisketen te plaatsen.
Waarom AI productdifferentiatie of automatisering van begin tot eind niet aankan

Hier zijn nog een paar andere gebieden waarop AI tekortschiet.
Er wordt veel gesproken over agents die gewoon een taak kunnen oppakken en die van begin tot eind kunnen uitvoeren. In de praktijk vereisen de meeste systemen die ik heb gezien nog steeds veel toezicht. Je begeleidt, corrigeert en geeft opnieuw prompts. Het lijkt meer op het aansturen van een enthousiaste stagiair dan op het delegeren aan een volledig zelfstandige teamgenoot.
Dat is nog steeds nuttig, maar het verschilt van de verwachting.
En dan is er nog productdifferentiatie.
Veel AI-functies voelen tegenwoordig hetzelfde aan. Je kunt een chatinterface toevoegen, wat code genereren en iets samenvatten. Dat is nu basisfunctionaliteit.
Wat moeilijker is gebleken, is om die mogelijkheden om te zetten in iets dat uniek waardevol aanvoelt en diep in een workflow is geïntegreerd. Iets dat mensen daadwerkelijk zouden missen als je het wegnam.
Ik denk dat veel producten daar tekortschieten.
Waarom menselijk oordeel essentieel blijft bij productbeslissingen over AI
PM's moeten zichzelf afvragen: “Waar heeft AI daadwerkelijk een goede smaak voor? En waar niet?”
Er zijn onderdelen van productwerk waarvoor AI voor mij nu ongelooflijk nuttig is — alles wat baat heeft bij breedte, snelheid of iteratie, laat ik er intensief door ondersteunen. Vroege ontdekking, het verkennen van oplossingsruimten, het uitwerken van verschillende benaderingen en zelfs het genereren van ruwe UX-richtingen of flows. Het is geweldig om je te helpen niet vast te lopen of meer opties te zien dan je in je eentje zou bedenken.
Ik gebruik het ook veel voor prototyping, zoals ik al zei. De mogelijkheid om snel van een idee naar iets interactiefs te gaan, heeft de manier waarop ik werk volledig veranderd.
En dan is er al het werk “daartussenin”. Gebruikersfeedback samenvatten, patronen uit gegevens halen en documenten opstellen. Dingen die vroeger veel tijd en het voortdurend wisselen van context kostten.
Waar ik niet op AI vertrouw, is wanneer oordeel echt belangrijk is. Prioritering is een belangrijk voorbeeld. AI kan je helpen opties op een rij te zetten, maar begrijpt de afwegingen binnen je bedrijf, je team of je beperkingen niet echt. Het voelt niet wat het kost om ongelijk te hebben.
Hetzelfde geldt voor beslissingen over de roadmap. Die gaan over overtuiging, timing en soms over het aangaan van een risico dat in een spreadsheet niet rationeel lijkt.
UX is nog zo'n interessant gebied. AI kan snel veel UI genereren, maar heeft geen gevoel voor kwaliteit. Het ervaart niet wat bij herhaald gebruik frustrerend of juist plezierig is. Vooral bij het bouwen voor ontwikkelaars is het verschil tussen iets dat werkt en iets dat prettig aanvoelt allesbepalend.
En dan zijn er de technische afwegingen. AI kan architecturen voorstellen, maar draagt niet de verantwoordelijkheid voor de langetermijngevolgen van die beslissingen. Jouw team doet dat wel.
Hoe AI traditionele productaannames verstoort
Ik denk dat de grootste aanname die ik heb moeten loslaten, is dat de grond waarop je staat stabiel is.
In productontwikkeling kon je er lange tijd van uitgaan dat een paar dingen relatief onveranderlijk waren. De interface, de workflow en zelfs wat het product is. Daarbinnen voerde je iteraties uit. AI doorbreekt dat.
Ik denk dat de grootste aanname die ik heb moeten loslaten, is dat de grond waarop je staat stabiel is….Je bouwt niet alleen op verschuivende grond. Je vraagt je voortdurend af of die grond überhaupt zou moeten bestaan.

Het model verbetert en plotseling klopt het oppervlak van je product niet meer. Er dient zich een nieuw interactieparadigma aan en wat aanvoelde als een solide roadmap wordt irrelevant. Dingen waarvan je dacht dat het beperkingen waren, verdwijnen, en er duiken nieuwe op waarop je niet had gerekend.
Je bouwt dus niet alleen op verschuivende grond. Je vraagt je voortdurend af of die grond überhaupt zou moeten bestaan. Dat is voor mij een grote verandering in denkwijze geweest.
De tweede aanname die ik heb losgelaten, is dat de beste producten de meest nauwkeurig gedefinieerde zijn. In het verleden lag er vroeg in het proces veel nadruk op duidelijkheid. Definieer het probleem, definieer de oplossing en voer die vervolgens netjes uit.
Nu komt veel van de waarde voort uit langer in de verkenningsfase blijven dan comfortabel voelt. Het product een beetje ongedefinieerd laten terwijl de onderliggende mogelijkheden zich nog ontwikkelen.
En de laatste gaat over waar waarde zich bevindt. Vroeger dacht ik dat veel productwaarde in de interface zat. De UI, de flow, de pixels. Nu zit veel van de waarde in gedrag. Hoe het systeem reageert, zich aanpast en samenwerkt. De interface is nog steeds belangrijk, vooral voor ontwikkelaars, maar vormt niet langer het zwaartepunt.
Hoe AI functies laat samensmelten
Functies smelten samen. De grenzen tussen productmanager, engineer en designer worden een stuk vager.
Met AI kun je veel directer prototypes maken, code schrijven, UX verkennen en ideeën aan grondige tests onderwerpen. Dat betekent dat meer mensen kunnen werken over wat vroeger duidelijk onderscheiden functies waren. En dat verandert de vorm van het team.
Je hebt minder overdrachtsmomenten nodig. Meer mensen die een idee zelf kunnen oppakken en vooruitbrengen, ten minste tot een betekenisvol niveau van uitwerking.
Ik heb dit zelf behoorlijk sterk ervaren. Onlangs ben ik weer productmanager in een individuele bijdragerrol geworden, en dat is ongelooflijk bevredigend geweest. Ik sta weer veel dichter bij het werk. Dingen bouwen, ideeën testen, de details induiken. Het herinnert me eraan dat veel productinzicht voortkomt uit het daadwerkelijk maken van dingen, niet alleen uit het coördineren ervan.
Dat betekent niet dat managers of specialisatie verdwijnen. Je hebt nog steeds diepgaande expertise nodig, vooral op gebieden als systeemontwerp of hoogwaardige UX. Maar je hebt ook meer “full-stack-productdenkers” nodig die zich soepel door de hele stack kunnen bewegen en AI als hefboom kunnen gebruiken.
Waarom AI de verwachtingen van gebruikers heeft veranderd
AI verbetert niet alleen jouw product. Het stelt opnieuw vast wat gebruikers verwachten van alle producten. Je concurreert dus niet langer alleen met je directe concurrenten. Je concurreert met de beste AI-ervaring die iemand die week waar dan ook heeft gehad.
Ik denk dat ik heb onderschat hoe snel die verschuiving in verwachtingen zou plaatsvinden.
In de praktijk betekent dit dat de periodes waarin iets “goed genoeg” is, veel korter zijn. Iets kan op maandag magisch aanvoelen en op vrijdag alweer verouderd zijn. Als ik dat had geweten, zou ik meer hebben geoptimaliseerd voor aanpassingsvermogen en minder voor verfijning.

Kathy's gedachten
Ik denk dat ik heb onderschat hoe snel die verschuiving in verwachtingen zou plaatsvinden…In de praktijk betekent dit dat de periodes waarin iets “goed genoeg” is, veel korter zijn.
Waarom productleiders AI als een verschuiving in het vakgebied moeten zien
Mijn advies is om dit moment minder te zien als een verschuiving in hulpmiddelen en meer als een verschuiving in het vakgebied.
De belangrijkste vaardigheid op dit moment is het vermogen om helder te zien. AI genereert veel output. Ideeën, code, richtingen. Het risico is dat je die output voor de waarheid gaat aanzien. Als productleider is het dus jouw taak om gegrond te blijven in wat er daadwerkelijk gebeurt. Wat gebruikers doen, waar dingen stuklopen en wat op de lange termijn standhoudt.
Het tweede is dat je moet bouwen wat je nodig hebt. Als je aan AI-producten werkt, moet je ze intensief gebruiken. Niet alleen in demo's of beoordelingen, maar in je eigen werkprocessen. Je voelt de hiaten onmiddellijk. Waar dingen traag zijn, waar ze verwarrend zijn, waar ze bijna werken maar net niet. Dat soort ervaring uit de eerste hand is moeilijk te vervangen en verandert de kwaliteit van je beslissingen.
Het derde is dat je je op je gemak moet voelen met spanning. Er is momenteel een echte spanning tussen snelheid en kwaliteit, verkenning en discipline, wat mogelijk is en wat daadwerkelijk nuttig is. Die spanning is niet iets dat je moet oplossen. Dat is het werk. De beste teams die ik heb gezien proberen haar niet weg te nemen. Ze gaan er doelbewust mee om. Ze werken snel wanneer ze aan het leren zijn en vertragen wanneer iets goed moet zijn.
En tot slot: laat AI je niet veranderen in een manager van output. Het is heel gemakkelijk om achterover te leunen en te coördineren, prompts te geven, te beoordelen en verder te gaan. Maar de beste productleiders staan momenteel nog steeds heel dicht bij het vak. Ze bouwen, testen en lossen dingen op die hen storen.
Want uiteindelijk is de taak niet veranderd. Je bent nog steeds verantwoordelijk voor het maken van iets dat werkt, dat mensen vertrouwen en dat in hun leven past. AI verandert alleen hoe je daar komt.
Volg haar
Je kunt meer van Kathy leren op haar blog over productontwikkeling of haar persoonlijke website. Of volg haar op X.
Er volgen meer interviews met experts op The CPO Club!
