Un responsabile di prodotto di OpenAI ci spiega come l’IA sta cambiando la gestione del prodotto ai massimi livelli
Scopri come una responsabile di prodotto di OpenAI utilizza l’IA per accelerare la scoperta del prodotto e la prototipazione, mantenendo però il giudizio sul prodotto, la fiducia e la cura artigianale saldamente sotto la guida umana.
Kathy Korevec
Codex presso OpenAI
Cambiamento dell’IA: L’IA sta trasformando la gestione del prodotto, dando priorità agli strumenti per sviluppatori incentrati sugli utenti e alla prototipazione rapida.
Rischi della velocità: L’IA aumenta la velocità, ma comporta il rischio di una «falsa velocità» e del completamento superficiale dei progetti senza un impatto duraturo.
Centralità dei prototipi: Dare priorità alla prototipazione rispetto alla documentazione aumenta lo slancio, portando a iterazioni più rapide e decisioni più oneste.
Principi della fiducia: Per mantenere la fiducia degli utenti nei prodotti basati sull’IA, è necessario fare affidamento su trasparenza, correzione, coerenza e moderazione.
Dinamiche dei ruoli: L’IA rende meno netti i confini tra gestione del prodotto, ingegneria e design, richiedendo professionisti del prodotto più versatili e capaci di operare a tutto campo.
Kathy Korevec è una creatrice che ha lavorato come Direttrice del prodotto presso Google Labs AI, Vicepresidente del prodotto e del design presso Vercel e Direttrice senior della gestione del prodotto presso GitHub, solo per citarne alcuni. Attualmente lavora su Codex presso OpenAI. Il filo conduttore è la creazione di strumenti per sviluppatori con un'attenzione costante all'utente e ai dettagli.
Abbiamo parlato con Kathy per scoprire come l'AI stia cambiando la gestione del prodotto nelle principali aziende tecnologiche del mondo. Ecco cosa ci ha raccontato.
Essere uno "chef che cucina per gli chef"
Sono sempre stata prima di tutto una creatrice e solo in secondo luogo una product manager.
Vuoi di più da The CPO Club?
Iscriviti gratuitamente per completare la lettura di questo articolo:
Have an account? Log In
Ho iniziato nel settore degli strumenti per sviluppatori in aziende come Heroku, GitHub e Vercel, un ambito molto particolare della gestione del prodotto. Non ti limiti a distribuire funzionalità: crei prodotti per persone che si accorgono immediatamente quando hai fatto le cose in modo superficiale. È come essere uno chef che cucina per altri chef. Il livello richiesto è elevato e si accorgeranno assolutamente se la tua salsa non è riuscita bene.
Alcuni dei miei momenti preferiti come PM non erano affatto attività tradizionali da "PM". In GitHub, ho riscritto parti della documentazione e ho persino riprogettato il sito per riflettere il mio approccio basato sui principi della DX. Ho trascorso interi fine settimana a rifattorizzare il mio sito web per risparmiare un paio di centinaia di millisecondi, perché le prestazioni mi infastidivano. Ho contribuito a gestire un progetto chiamato Papercuts, in cui abbiamo risolto centinaia di piccoli inconvenienti, perché sono questi dettagli, sommati, a determinare se le persone amano o tollerano il tuo prodotto.
Questo è stato, in un certo senso, il filo conduttore del mio percorso. Non considero i PM semplicemente come persone che individuano le lacune e le colmano, né come il "CEO del proprio prodotto". Per me significa avvicinarsi ai dettagli fino a sentirsi quasi a disagio. Abbastanza da iniziare a preoccuparsi di aspetti che non compaiono in una roadmap.
E ora ci troviamo in questo momento dell'AI, che sinceramente assomiglia un po' al dare a tutti un jetpack sperando che non finiscano contro un albero.
Trascorro molto tempo, la sera e nei fine settimana, a fare programmazione intuitiva assistita dall'AI, creando piccoli strumenti improvvisati con agenti di AI. Si può passare dall'idea a un prodotto funzionante in un pomeriggio, ed è incredibile. Allo stesso tempo, i fondamenti sono più importanti che mai. Comprendere i sistemi, i compromessi e il funzionamento effettivo delle cose sotto la superficie è ciò che distingue qualcosa che viene distribuito da qualcosa che dura nel tempo.
Altrimenti si finisce con un cimitero di progetti incompiuti e bug misteriosi.
Quindi il mio percorso verso questo momento non ha riguardato davvero un cambiamento del mio modo di lavorare. È consistito nel rafforzarlo. Nel rimanere vicina al mestiere. E nel costruire personalmente le cose.
Non considero i PM semplicemente come persone che individuano le lacune e le colmano, né come il “CEO del proprio prodotto”. Per me significa avvicinarsi ai dettagli fino a sentirsi quasi a disagio.
Ridurre la distanza tra idea e convalida
Fino a pochissimo tempo fa guidavo il prodotto per un team di Google Labs chiamato AIDA, acronimo di Assistenza agli sviluppatori tramite AI.
Lavoravamo a un livello piuttosto profondo dello stack. I primi modelli per la programmazione, i dati di addestramento per il codice che alimentavano Gemini e poi il passaggio a un livello di astrazione superiore, verso prodotti come Colab Composer e Jules. Il passaggio è stato da "Possiamo generare codice?" a "Possiamo davvero aiutare le persone a creare software reale dall'inizio alla fine?"
Quindi l'organizzazione che guidavo era decisamente ibrida. In parte ricerca, in parte prodotto, in parte "Questa settimana distribuiremo qualcosa di improvvisato e vedremo se qualcuno lo utilizzerà". I nostri utenti andavano dagli sviluppatori professionisti alle persone che non avevano mai scritto codice, un pubblico che induce all'umiltà perché bisogna soddisfare contemporaneamente esigenze di profondità e accessibilità.
Il modello di distribuzione rifletteva questa impostazione. Molte iterazioni rapide, cicli stretti tra le capacità del modello e l'esperienza del prodotto e la disponibilità a eliminare ciò che non funzionava. Meno roadmap e più esplorazione con uno scopo.
Ora lavoro presso OpenAI su Codex, in quello che è un po' un ritorno alle origini. Codex è nato come modello e ora si sta evolvendo in un agente e in un livello applicativo all'interno di ChatGPT, che aiuta le persone a portare a termine il lavoro. Scrivere codice, automatizzare flussi di lavoro, collegare sistemi.
In entrambi i casi, quindi, il filo conduttore è lo stesso: creare strumenti che riducano la distanza tra un'idea e qualcosa che funziona nel mondo reale.
Perché i PM dovrebbero concentrarsi sullo sviluppo del prodotto guidato dai prototipi
Ho smesso di considerare le specifiche come il principale prodotto del lavoro di sviluppo. È un cambiamento che avevo già iniziato, ma l’IA lo ha accelerato.
All’inizio della mia carriera, in particolare presso GitHub e Heroku, ho capito quanto sia importante il ritmo. L’utilizzo reale è importante. Si impara di più da qualcosa in produzione di quanto si imparerà mai da un documento scritto alla perfezione.
Ciò che ha fatto l’IA è stato prendere questa filosofia e comprimerla ulteriormente.
Ora, invece di scrivere una lunga specifica e discuterne per una settimana, costruisco personalmente una versione approssimativa del prodotto. Oppure scrivo seguendo l’ispirazione un prototipo in uno o due giorni. Qualcosa su cui si può fare clic, che si può rompere e su cui si può reagire. Questo cambia tutto.
Si passa da “Cosa pensiamo che succederà?” a “Cosa succede davvero quando si usa questo prodotto?”. Gran parte del dibattito astratto si concentra in qualcosa di concreto.
Cambia anche il ruolo del responsabile di prodotto. Non ci si limita a dare forma alle idee: le si mette direttamente alla prova. Si è più vicini all’implementazione e quindi si individuano prima le ipotesi sbagliate.
Il risultato è, naturalmente, la velocità. Distribuiamo più rapidamente, eliminiamo più velocemente le idee e perfezioniamo più rapidamente quelle valide.
Il cambiamento più importante, però, è che le nostre decisioni sono più oneste.
Perché gli svantaggi dell’IA sono sottili, ma importanti
Ma ci sono sicuramente degli svantaggi.
Uno è quello che definirei “velocità illusoria”. Si ha la sensazione di muoversi incredibilmente velocemente perché si producono molte cose. Codice, prototipi, documenti. Ma non tutto è realmente valido o utilizzabile. Si può generare un’ampia superficie senza una vera profondità.
Un altro problema riguarda la qualità e la fiducia. Il codice generato dall’IA può essere sorprendentemente valido e, allo stesso tempo, avere errori espressi con grande sicurezza. Se non si comprende cosa accade dietro le quinte, si rischia di distribuire prodotti fragili, insicuri o difficili da manutenere.
E poi ce n’è uno più sottile. Iniziare qualcosa è più facile che mai. Non è necessariamente più facile portarlo a termine bene. Vedremo molti più prodotti realizzati a metà, prototipi abbandonati e sistemi che funzionano più o meno finché non smettono di farlo. Ne ho costruiti personalmente alcuni.
Quindi il risultato complessivo è piuttosto paradossale. Non siamo mai stati così veloci nell’arrivare a qualcosa. Ma non siamo automaticamente più bravi a trasformarlo in qualcosa che duri.
Perché quattro principi trasformano i prodotti da fuochi d’artificio in strumenti affidabili
Voglio condividere qualche riflessione in più sulla fiducia, perché penso che i leader di prodotto sottovalutino il rischio rappresentato da software invisibile e di bassa qualità.
L’IA rende incredibilmente facile costruire qualcosa. Si possono creare strumenti, funzionalità e persino intere applicazioni in una frazione del tempo necessario in passato. Sembra un vantaggio assoluto, ma il risultato è una quantità molto maggiore di software che funziona più o meno.
Funzionalità incomplete, sistemi fragili, cose costruite rapidamente e mai rese solide. Non falliscono in modo evidente. Semplicemente peggiorano nel tempo. Si rompono in modi sottili, generano confusione o erodono silenziosamente la fiducia.
Il rischio non è soltanto il debito tecnico nel senso tradizionale. È debito di fiducia.
Ecco quattro principi che ho trovato utili:
- Rendete il sistema comprensibile. Gli utenti dovrebbero poter capire cosa sta facendo l’IA e perché, almeno a un livello generale. Non serve una trasparenza tecnica completa, ma quanto basta per evitare che sembri una scatola nera che prende decisioni arbitrarie. Può essere semplice come mostrare i passaggi, rendere visibili le ipotesi o consentire agli utenti di esaminare ciò che è cambiato.
- Progettate pensando alla correzione. A volte il sistema sbaglierà. È inevitabile. Ciò che conta è quanto sia facile per un utente intervenire, correggerlo e andare avanti. Se correggere il sistema è complicato, la fiducia diminuisce rapidamente. Se è facile, le persone continueranno a usarlo anche se non è perfetto.
- Costruite puntando sulla coerenza, non sull’effetto sorpresa. Molti prodotti basati sull’IA ottimizzano il momento “wow”. Un’interazione davvero impressionante. La fiducia nasce dall’opposto: il sistema fa ciò che ci si aspetta, ancora e ancora, senza sorprese. Soprattutto negli strumenti per sviluppatori, la prevedibilità conta più della magia.
- Mostrate moderazione. Il fatto che il sistema possa fare qualcosa non significa che debba farlo. Se automatizzate troppo o assumete un controllo eccessivo, gli utenti lo percepiscono. Perdono il senso della propria autonomia. I prodotti migliori offrono maggiore capacità d’azione senza escludervi dal processo.
Perché l’IA non può gestire la differenziazione del prodotto o l’automazione completa dall’inizio alla fine
Ecco un paio di altri ambiti in cui l'IA non è all'altezza.
Si parla molto di agenti che possono semplicemente ricevere un'attività e portarla a termine dall'inizio alla fine. In pratica, la maggior parte dei sistemi che ho visto richiede ancora molta supervisione. Devi guidarli, correggerli e fornire nuovamente istruzioni. È più simile a gestire uno stagista entusiasta che a delegare a un collega completamente indipendente.
È comunque utile, ma è diverso da quanto ci si aspetta.
E poi c'è la differenziazione del prodotto.
Molte funzionalità di IA oggi sembrano simili. Puoi aggiungere un'interfaccia di chat, generare del codice e riassumere qualcosa. Ormai sono requisiti di base.
La parte più difficile è stata trasformare queste capacità in qualcosa che sembri avere un valore unico e che sia profondamente integrato in un flusso di lavoro. Qualcosa che le persone rimpiangerebbero davvero se venisse rimosso.
Credo che sia questo il punto in cui molti prodotti non sono all'altezza.
Perché il giudizio umano resta essenziale nelle decisioni di prodotto basate sull'IA
I PM devono chiedersi: «Dove l'IA ha davvero buon gusto? E dove invece non ne ha?»
Oggi ci sono aspetti del lavoro di prodotto per i quali l'IA è incredibilmente utile — tutto ciò che trae beneficio dall'ampiezza, dalla velocità o dall'iterazione: mi affido molto a lei. La scoperta iniziale, l'esplorazione degli spazi delle soluzioni, la stesura di approcci diversi e persino la generazione di indicazioni o flussi UX preliminari. È ottima per aiutarti a superare un blocco o a vedere più opzioni di quante ne avresti considerate da solo.
La uso molto anche per la prototipazione, come ho detto. Poter passare rapidamente da un'idea a qualcosa di interattivo ha cambiato completamente il mio modo di lavorare.
E poi c'è tutto il lavoro «intermedio». Riassumere il feedback degli utenti, individuare schemi nei dati, redigere documenti. Attività che un tempo richiedevano molto tempo e continui cambi di contesto.
Non mi affido all'IA quando il giudizio conta davvero. La definizione delle priorità è un esempio importante. L'IA può aiutarti a elencare le opzioni, ma non comprende realmente i compromessi nella tua attività, nel tuo team o nei tuoi vincoli. Non percepisce il costo di sbagliare.
Lo stesso vale per le decisioni sulla roadmap. Riguardano la convinzione, le tempistiche e talvolta la scelta di fare una scommessa che non sembra razionale in un foglio di calcolo.
La UX è un altro aspetto interessante. L'IA può generare rapidamente molte interfacce, ma non ha gusto. Non percepisce ciò che è frustrante o piacevole dopo un uso ripetuto. Soprattutto quando si costruisce per gli sviluppatori, la differenza tra qualcosa che funziona e qualcosa che offre una buona esperienza è tutto.
E poi ci sono i compromessi tecnici. L'IA può suggerire architetture, ma non si assume le conseguenze a lungo termine di quelle decisioni. A farlo è il tuo team.
Come l'IA mette in discussione le ipotesi tradizionali sul prodotto
Credo che l'ipotesi più importante che ho dovuto abbandonare sia che il terreno su cui ti trovi sia stabile.
Per molto tempo, nel settore dei prodotti, si poteva presumere che alcune cose fossero relativamente fisse. L'interfaccia, il flusso di lavoro, persino ciò che il prodotto è. Si iterava all'interno di quella struttura. L'IA rompe questo schema.
Credo che l’ipotesi più importante che ho dovuto abbandonare sia che il terreno su cui ti trovi sia stabile….Non stai semplicemente costruendo su un terreno mutevole. Ti chiedi costantemente se quel terreno debba esistere affatto.
Il modello migliora e, all'improvviso, la superficie del tuo prodotto non è più adatta. Compare un nuovo paradigma di interazione e quella che sembrava una roadmap solida diventa irrilevante. Vincoli che pensavi fossero insormontabili scompaiono e ne emergono di nuovi, che non avevi previsto.
Quindi non stai semplicemente costruendo su un terreno mutevole. Ti chiedi costantemente se quel terreno debba esistere affatto. Per me è stato un grande cambiamento di mentalità.
La seconda ipotesi che ho abbandonato è che i prodotti migliori siano quelli più precisamente definiti. In passato, si attribuiva grande valore alla chiarezza fin dalle prime fasi. Definire il problema, definire la soluzione, eseguire tutto con precisione.
Ora, gran parte del valore deriva dal rimanere nella fase di esplorazione più a lungo di quanto ci faccia sentire a nostro agio. Lasciare che il prodotto rimanga un po' indefinito mentre le capacità sottostanti continuano a evolversi.
E l'ultima riguarda il luogo in cui risiede il valore. Un tempo pensavo che gran parte del valore di un prodotto fosse nell'interfaccia. L'interfaccia utente, il flusso, i pixel. Ora, gran parte del valore risiede nel comportamento. Nel modo in cui il sistema risponde, si adatta e collabora. L'interfaccia è ancora importante, soprattutto per gli sviluppatori, ma non è più il centro di gravità.
Come l'IA sta facendo convergere i ruoli
I ruoli stanno convergendo. I confini tra responsabile di prodotto, ingegnere e progettista si stanno assottigliando molto.
Con l'IA puoi creare prototipi, scrivere codice, esplorare l'esperienza utente e mettere alla prova le idee in modo molto più diretto. Questo significa che più persone possono operare in ambiti che un tempo corrispondevano a ruoli ben distinti. E questo cambia la struttura del team.
Servono meno passaggi di consegne. E più persone capaci di prendere un'idea e portarla avanti autonomamente, almeno fino a un livello significativo di fedeltà.
L'ho vissuto in prima persona. Di recente sono tornata a lavorare come responsabile di prodotto individuale e ne ho ricavato un'enorme soddisfazione. Sono di nuovo molto più vicina al lavoro. Costruire cose, testare idee, entrare nei dettagli. Mi ricorda che gran parte del giudizio sul prodotto nasce dal fare concretamente le cose, non solo dal coordinarle.
Questo non significa che i dirigenti o la specializzazione scompaiano. Serve ancora una competenza approfondita, soprattutto in aree come la progettazione dei sistemi o un'esperienza utente di alta qualità. Ma servono anche più “pensatori di prodotto a tutto campo”, capaci di muoversi con fluidità lungo l'intero insieme delle tecnologie e di usare l'IA come leva.
Perché l'IA ha cambiato le aspettative degli utenti
L'IA non migliora soltanto il tuo prodotto. Ridefinisce ciò che gli utenti si aspettano da tutti i prodotti. Quindi non competi più soltanto con i tuoi concorrenti diretti. Competi con la migliore esperienza di IA che qualcuno ha avuto in qualunque momento della settimana.
Credo di aver sottovalutato la velocità con cui sarebbe avvenuto questo cambiamento nelle aspettative.
In pratica, questo significa che le finestre in cui qualcosa è “abbastanza buono” sono molto più brevi. Qualcosa può sembrare magico lunedì e obsoleto venerdì. Se lo avessi saputo, avrei ottimizzato maggiormente per l'adattabilità e meno per la rifinitura.
Perché i leader di prodotto devono considerare l'IA come un cambiamento della disciplina
Il mio consiglio è di considerare questo momento meno come un cambiamento degli strumenti e più come un cambiamento della disciplina.
La competenza più importante in questo momento è la capacità di vedere con chiarezza. L'IA genera una grande quantità di risultati. Idee, codice, direzioni. Il rischio è iniziare a scambiare quei risultati per la verità. Quindi, in quanto leader di prodotto, il tuo compito è restare ancorato a ciò che sta realmente accadendo. A ciò che fanno gli utenti, ai punti in cui le cose si rompono e a ciò che regge nel tempo.
La seconda cosa è costruire ciò da cui dipendi. Se lavori su prodotti basati sull'IA, dovresti usarli in profondità. Non solo durante le dimostrazioni o le revisioni, ma anche nei tuoi flussi di lavoro. Sentirai immediatamente le lacune. Dove le cose sono lente, dove sono confuse, dove quasi funzionano ma non del tutto. Questo tipo di esperienza diretta è difficile da sostituire e cambia la qualità delle tue decisioni.
La terza è abituarsi alla tensione. In questo momento c'è una reale contrapposizione tra velocità e qualità, esplorazione e disciplina, ciò che è possibile e ciò che è davvero utile. Questa tensione non è qualcosa da risolvere. È il lavoro. I migliori team che ho visto non cercano di eliminarla. La gestiscono consapevolmente. Si muovono velocemente quando stanno imparando e rallentano quando qualcosa deve essere fatto bene.
Infine, non lasciare che l'IA ti trasformi in un coordinatore dei risultati. È molto facile restare in disparte e coordinare, impartire istruzioni, revisionare e passare oltre. Ma i migliori leader di prodotto, oggi, sono ancora molto vicini al lavoro concreto. Costruiscono, testano e sistemano le cose che li infastidiscono.
Perché, in fin dei conti, il lavoro non è cambiato. Sei ancora responsabile di realizzare qualcosa che funzioni, di cui le persone si fidino e che si integri nelle loro vite. L'IA cambia soltanto il modo in cui ci arrivi.
Segui gli aggiornamenti
Puoi saperne di più su Kathy nel suo blog sulla creazione di prodotti o sul suo sito personale. Oppure puoi seguirla su X.
Presto arriveranno altre interviste con esperti su The CPO Club!
