Produktleder i OpenAI forteller oss hvordan kunstig intelligens endrer produktledelse på høyeste nivå

Kathy Korevec er en bygger som har jobbet som produktsjef i Google Labs AI, visepresident for produkt og design i Vercel og senior produktsjef i GitHub, for å nevne noen. Nå jobber hun med Codex i OpenAI. Den røde tråden er å skape utviklerverktøy med et kompromissløst fokus på brukersentrering og detaljer.

Vi satte oss ned med Kathy for å lære hvordan kunstig intelligens endrer produktledelse i verdens fremste teknologiselskaper. Her er det hun hadde å si.

Å være en «kokk som lager mat for kokker»

Jeg har alltid vært bygger først og produktsjef deretter.

Jeg vokste opp med utviklerverktøy hos selskaper som Heroku, GitHub og Vercel, noe som er en svært spesifikk form for produktledelse. Du lanserer ikke bare funksjoner; du bygger for mennesker som umiddelbart vet når du har tatt en snarvei. Det er som å være en kokk som lager mat for kokker. Kravene er høye, og de vil definitivt merke det hvis sausen din ikke sitter.

Noen av favorittøyeblikkene mine som PM var ikke tradisjonelt «PM-arbeid» i det hele tatt. I GitHub skrev jeg om deler av dokumentasjonen og redesignet til og med nettstedet for å gjenspeile tilnærmingen min til DX-prinsippene. Jeg har brukt helger på å refaktorere mitt eget nettsted for å spare inn et par hundre millisekunder fordi ytelsen plaget meg. Jeg bidro til å drive et prosjekt kalt Papercuts, der vi løste hundrevis av små irritasjonsmomenter, fordi disse detaljene til sammen avgjør om folk elsker eller tolererer produktet ditt.

Det har på en måte vært den røde tråden for meg. Jeg ser ikke på PM-er som noen som bare identifiserer mangler og fyller dem, eller som «administrerende direktør for produktet ditt». Jeg ser på det som å komme ubehagelig tett på detaljene. Nært nok til at du begynner å bry deg om ting som ikke dukker opp på et veikart.

Og nå er vi inne i dette KI-øyeblikket, som helt ærlig føles litt som å gi alle en jetpack og håpe at de ikke flyr inn i et tre.

Jeg bruker mye tid på intuisjonskoding på kvelder og i helger, og bygger enkle små verktøy med KI-agenter. Du kan gå fra idé til fungerende produkt på en ettermiddag, noe som er utrolig. Samtidig er grunnprinsippene viktigere enn noen gang. Det å forstå systemer, avveininger og hvordan ting faktisk fungerer under panseret, er det som skiller noe som blir lansert, fra noe som varer.

Ellers ender du opp med en gravplass full av uferdige prosjekter og mystiske feil.

Så reisen min inn i dette øyeblikket har egentlig ikke handlet om å endre hvordan jeg jobber. Den har handlet om å satse enda mer på det. Holde meg tett på håndverket. Og bygge ting selv.

Å bygge bro mellom idé og validering

Helt frem til nylig ledet jeg produktarbeidet for et team i Google Labs som het AIDA, som sto for AI-utviklerassistanse.

Vi jobbet ganske dypt i stakken. Tidlige kodemodeller, treningsdata for kode som ble brukt i Gemini, og deretter oppover i abstraksjonslaget til produkter som Colab Composer og Jules. Skiftet gikk fra «Kan vi generere kode?» til «Kan vi faktisk hjelpe folk med å bygge ekte programvare fra ende til annen?»

Organisasjonen jeg ledet, var derfor i høy grad en hybrid. Litt forskning, litt produkt og litt «Vi lanserer noe enkelt denne uken og ser om noen bruker det». Brukerne våre varierte fra profesjonelle utviklere til mennesker som aldri hadde skrevet kode før, noe som er en ydmykende målgruppe fordi du må ivareta både dybde og tilgjengelighet samtidig.

Leveransemodellen gjenspeilte dette. Mye rask iterasjon, tette sløyfer mellom modellens funksjonalitet og produktopplevelsen, og en vilje til å forkaste ting hvis de ikke fungerte. Det er mindre veikart og mer utforskning med hensikt.

Nå er jeg i OpenAI, der jeg jobber med Codex, noe som på en måte er et øyeblikk der sirkelen sluttes. Codex startet som en modell, og utvikler seg nå til en agent og et applikasjonslag inne i ChatGPT som hjelper folk med faktisk å få arbeidet gjort. Skrive kode, automatisere arbeidsflyter og koble sammen systemer.

I begge tilfeller er den røde tråden derfor den samme. Å bygge verktøy som reduserer avstanden mellom en idé og noe som kjører i den virkelige verden.

Hvorfor PM-er bør fokusere på prototypedrevet produktutvikling

Jeg har sluttet å behandle spesifikasjoner som det viktigste arbeidsproduktet i produktarbeid. Det er en endring jeg allerede hadde begynt på, men KI satte fart på den.

Tidlig i karrieren, særlig hos GitHub og Heroku, innså jeg hvor mye fremdrift betyr. Faktisk bruk betyr noe. Du lærer mer av noe som er i produksjon enn du noen gang vil lære av et perfekt skrevet dokument.

Det KI har gjort, er å ta denne filosofien og komprimere den enda mer.

Nå bygger jeg, i stedet for å skrive en lang spesifikasjon og diskutere den i en uke, en grov versjon av produktet selv. Eller lager en prototype ved hjelp av stemningskoding på en dag eller to. Noe du kan klikke på, ødelegge og reagere på. Det endrer alt.

Du går fra «Hva tror vi kommer til å skje?» til «Hva skjer faktisk når du bruker dette?» Det gjør mye av den abstrakte diskusjonen konkret.

Det endrer også rollen til produktlederen. Du former ikke bare ideer; du setter dem direkte på prøve. Du er tettere på implementeringen, så du oppdager dårlige antakelser tidligere.

Resultatet er selvfølgelig høyere tempo. Vi lanserer raskere, forkaster ideer raskere og videreutvikler gode ideer raskere.

Den viktigste endringen er likevel at beslutningene våre er mer ærlige.

Hvorfor ulempene ved KI er subtile, men viktige

Men det finnes definitivt ulemper.

Én av dem er det jeg vil kalle «falsk fremdrift». Du føler at du beveger deg utrolig raskt fordi du produserer mye. Kode, prototyper, dokumentasjon. Men ikke alt er faktisk bra eller brukbart. Du kan skape et stort overflateareal uten reell dybde.

Et annet problem er kvalitet og tillit. KI-generert kode kan være overraskende god og samtidig selvsikkert feil. Hvis du ikke forstår hva som skjer under panseret, kan du ende opp med å lansere ting som er skjøre, usikre eller vanskelige å vedlikeholde.

Og så er det en mer subtil utfordring. Det har aldri vært enklere å starte ting. Det er ikke nødvendigvis blitt enklere å fullføre dem på en god måte. Vi kommer til å se langt flere halvbygde produkter, forlatte prototyper og systemer som fungerer sånn passe helt til de ikke gjør det lenger. Jeg har bygget noen slike selv.

Så det samlede resultatet er litt av et paradoks. Vi har aldri vært raskere til å komme frem til noe. Men vi har ikke automatisk blitt bedre til å gjøre det om til noe som varer.

Kathys tanker

Det har aldri vært enklere å starte ting. Det er ikke nødvendigvis blitt enklere å fullføre dem på en god måte. Vi kommer til å se langt flere halvbygde produkter, forlatte prototyper og systemer som fungerer sånn passe helt til de ikke gjør det lenger. Jeg har bygget noen slike selv.

Hvorfor fire prinsipper gjør produkter tillitsverdige i stedet for bare imponerende

Jeg vil si litt mer om tillit, fordi jeg tror produktledere undervurderer risikoen ved usynlig programvare av lav kvalitet.

KI gjør det utrolig enkelt å bygge ting. Du kan sette opp verktøy, funksjoner og til og med hele apper på en brøkdel av tiden det tidligere tok. Det høres ut som en ren fordel, men resultatet er at du får langt mer programvare som fungerer sånn passe.

Halvferdige funksjoner, skjøre systemer og ting som ble bygget raskt og aldri gjort robuste. De feiler ikke høylytt. De forringes bare over tid. De slutter å fungere på subtile måter, skaper forvirring eller undergraver tilliten i det stille.

Risikoen handler ikke bare om teknisk gjeld i tradisjonell forstand. Det handler om tillitsgjeld.

Her er fire prinsipper jeg har hatt nytte av:

1. Gjør systemet forståelig. Brukerne bør kunne forstå hva KI-en gjør og hvorfor, i det minste på et overordnet nivå. Ikke full teknisk åpenhet, men nok til at det ikke føles som en svart boks som tar vilkårlige beslutninger. Det kan være så enkelt som å vise trinn, synliggjøre antakelser eller la brukerne se hva som er endret.
2. Utform systemet for korrigering. Systemet kommer til å ta feil iblant. Det er gitt. Det som betyr noe, er hvor enkelt det er for en bruker å gripe inn, rette det opp og gå videre. Hvis det er smertefullt å korrigere systemet, faller tilliten raskt. Hvis det er enkelt, vil folk fortsette å bruke det selv om det ikke er perfekt.
3. Bygg for jevn kvalitet, ikke blaff. Mange KI-produkter optimaliserer for «wow»-øyeblikket. Én virkelig imponerende interaksjon. Tillit kommer fra det motsatte – at systemet gjør det forventede, igjen og igjen, uten overraskelser. Særlig i utviklerverktøy er forutsigbarhet viktigere enn magi.
4. Vis måtehold. Bare fordi systemet kan gjøre noe, betyr ikke det at det bør gjøre det. Hvis du automatiserer for mye eller tar for mye kontroll, merker brukerne det. De mister følelsen av å ha kontroll. De beste produktene gir deg større handlingsrom uten å ta deg ut av loopen.

Hvorfor KI ikke kan håndtere produktdifferensiering eller ende-til-ende-automatisering

Her er et par andre områder der AI ikke strekker til.

Det snakkes mye om agenter som bare kan ta en oppgave og gjennomføre den fra ende til ende. I praksis krever de fleste systemene jeg har sett, fortsatt mye oppfølging. Du veileder, korrigerer og gir nye instrukser. Det ligner mer på å lede en ivrig praktikant enn å delegere til en helt selvstendig kollega.

Det er fortsatt nyttig, men det er noe annet enn forventningen.

Og så har vi produktdifferensiering.

Mange AI-funksjoner føles like i dag. Du kan legge til et chatgrensesnitt, generere kode og oppsummere noe. Det er minimumskrav nå.

Det som har vært vanskeligere, er å omdanne disse mulighetene til noe som føles unikt verdifullt og dypt integrert i en arbeidsflyt. Noe folk faktisk ville savnet hvis du fjernet det.

Jeg tror det er her mange produkter ikke strekker til.

Hvorfor menneskelig dømmekraft fortsatt er avgjørende i produktbeslutninger med AI

Produktledere må spørre seg selv: «Hvor har AI faktisk god dømmekraft? Og hvor har den ikke det?»

Det finnes deler av produktarbeidet der AI nå er utrolig nyttig for meg – alt som drar nytte av bredde, hastighet eller iterasjon, støtter jeg meg tungt på det til. Tidlig utforskning, utforsking av løsningsrom, utarbeiding av ulike tilnærminger og til og med generering av foreløpige UX-retninger eller flyter. Det er fantastisk til å hjelpe deg med å komme deg videre eller se flere alternativer enn du ville gjort på egen hånd.

Jeg bruker det også mye til prototyping, som jeg nevnte. Muligheten til å gå fra en idé til noe interaktivt på kort tid har fullstendig endret hvordan jeg jobber.

Og så har vi alt arbeidet «imellom». Å oppsummere tilbakemeldinger fra brukere, finne mønstre i data og utarbeide dokumenter. Ting som tidligere tok mye tid og krevde hyppig kontekstbytte.

Det jeg ikke stoler på AI til, er der dømmekraft virkelig betyr noe. Prioritering er et viktig eksempel. AI kan hjelpe deg med å liste opp alternativer, men den forstår ikke de faktiske avveiningene i virksomheten, teamet eller begrensningene dine. Den kjenner ikke kostnaden ved å ta feil.

Det samme gjelder beslutninger om veikartet. De handler om overbevisning, timing og noen ganger om å satse på noe som ikke ser rasjonelt ut i et regneark.

UX er et annet interessant område. AI kan generere mye brukergrensesnitt raskt, men den har ikke god smak. Den kjenner ikke hva som er frustrerende eller herlig etter gjentatt bruk. Særlig når man utvikler for utviklere, er forskjellen mellom noe som fungerer og noe som føles bra, helt avgjørende.

Og så har vi tekniske avveininger. AI kan foreslå arkitekturer, men den tar ikke ansvar for de langsiktige konsekvensene av disse beslutningene. Det gjør teamet ditt.

Hvordan AI utfordrer tradisjonelle produktantakelser

Jeg tror den største antakelsen jeg har måttet gi slipp på, er at grunnen du står på, er stabil.

I lang tid kunne man i produktarbeid anta at enkelte ting var relativt faste. Grensesnittet, arbeidsflyten, til og med hva produktet er. Man itererte innenfor dette. AI bryter med det.

Modellen blir bedre, og plutselig er produktflaten din feil. Et nytt interaksjonsparadigme dukker opp, og det som føltes som et solid veikart, blir irrelevant. Ting du trodde var begrensninger, forsvinner, og nye begrensninger dukker opp som du ikke hadde planlagt for.

Så du bygger ikke bare på grunn i stadig endring. Du stiller hele tiden spørsmål ved om grunnen i det hele tatt bør finnes. Det har vært en stor endring i tankesettet mitt.

Den andre antakelsen jeg har gitt slipp på, er at de beste produktene er de mest veldefinerte. Tidligere la man stor vekt på klarhet tidlig i prosessen. Definer problemet, definer løsningen, og gjennomfør på en ryddig måte.

Nå kommer mye av verdien fra å forbli i utforskingsfasen lenger enn det som føles komfortabelt. Å la produktet være litt udefinert mens de underliggende mulighetene fortsatt utvikler seg.

Og den siste handler om hvor verdien ligger. Jeg pleide å tro at mye av produktverdien lå i grensesnittet. Brukergrensesnittet, flyten, pikslene. Nå ligger mye av verdien i atferden. Hvordan systemet reagerer, tilpasser seg og samarbeider. Grensesnittet er fortsatt viktig, særlig for utviklere, men det er ikke lenger tyngdepunktet.

Slik flyter rollene sammen med AI

Rollene flyter sammen. Grensene mellom produktleder, utvikler og designer blir mye mindre tydelige.

Med AI kan du lage prototyper, skrive kode, utforske brukeropplevelser og stressteste ideer mye mer direkte. Det betyr at flere kan jobbe på tvers av det som tidligere var svært tydelig avgrensede roller. Og det endrer teamets sammensetning.

Du trenger færre overleveringer. Flere som kan ta en idé og drive den fremover på egen hånd, i det minste til et meningsfullt detaljnivå.

Jeg har følt dette ganske personlig. Jeg gikk nylig tilbake til å være IC-produktleder, og det har vært utrolig givende. Jeg er mye nærmere arbeidet igjen. Jeg bygger ting, tester ideer og går inn i detaljene. Det minner meg på at mye av produktforståelsen kommer av faktisk å lage ting, ikke bare av å koordinere dem.

Det betyr ikke at ledere eller spesialisering forsvinner. Du trenger fortsatt dyp ekspertise, særlig innen områder som systemdesign eller brukeropplevelser av høy kvalitet. Men du trenger også flere «helhetlige produktutviklere» som kan bevege seg smidig på tvers av hele produktstakken og bruke AI som en kraftforsterker.

Hvorfor AI har endret brukernes forventninger

AI forbedrer ikke bare produktet ditt. Det endrer hva brukerne forventer av alle produkter. Så du konkurrerer ikke lenger bare med de direkte konkurrentene dine. Du konkurrerer med den beste AI-opplevelsen noen hadde noe sted den uken.

Jeg tror jeg undervurderte hvor raskt denne forventningsendringen ville skje.

I praksis betyr det at periodene der «godt nok» holder, er mye kortere. Noe kan føles magisk på mandag og utdatert på fredag. Hvis jeg hadde visst det, ville jeg ha optimalisert mer for tilpasningsevne og mindre for finpussing.

Kathys tanker

Jeg tror jeg undervurderte hvor raskt denne forventningsendringen ville skje…I praksis betyr det at periodene der «godt nok» holder, er mye kortere.

Hvorfor produktledere må se på AI som et faglig skifte

Mitt råd er å se på dette øyeblikket mindre som et verktøyskifte og mer som et faglig skifte.

Den viktigste ferdigheten akkurat nå er evnen til å se klart. AI genererer mye innhold. Ideer, kode og retninger. Risikoen er at du begynner å forveksle dette innholdet med sannheten. Som produktleder er jobben din derfor å holde fast ved det som faktisk skjer. Hva brukerne gjør, hvor ting bryter sammen, og hva som holder over tid.

Det andre er å bygge det du selv er avhengig av. Hvis du jobber med AI-produkter, bør du bruke dem grundig. Ikke bare i demoer eller gjennomganger, men i dine egne arbeidsprosesser. Du vil umiddelbart kjenne hvor hullene er. Hvor ting går sakte, hvor de er forvirrende, og hvor de nesten fungerer, men ikke helt. Førstehåndserfaring av den typen er vanskelig å erstatte, og den endrer kvaliteten på beslutningene dine.

Det tredje er å bli komfortabel med spenninger. Akkurat nå finnes det en reell dragkamp mellom hastighet og kvalitet, utforskning og disiplin, det som er mulig og det som faktisk er nyttig. Denne spenningen er ikke noe som skal løses. Den er selve arbeidet. De beste teamene jeg har sett, prøver ikke å eliminere den. De navigerer i den på en bevisst måte. De beveger seg raskt når de lærer, og sakker ned når noe må bli riktig.

Og til slutt: Ikke la AI gjøre deg til en leder for leveranser. Det er svært lett å lene seg tilbake og orkestrere, skrive instruksjoner, gjennomgå resultatene og gå videre. Men de beste produktlederne akkurat nå er fortsatt svært tett på faget. De bygger, tester og fikser ting som plager dem.

For til syvende og sist har ikke jobben endret seg. Du har fortsatt ansvaret for å lage noe som fungerer, som folk stoler på, og som passer inn i livene deres. AI endrer bare hvordan du kommer dit.

Følg med videre

Du kan lære mer av Kathy på bloggen hennes om produktutvikling eller på hennes personlige nettsted. Du kan også følge henne på X.

Flere ekspertintervjuer kommer på The CPO Club!