In che modo la creazione di prodotti AI è diversa — e perché i team di prodotto devono evolversi

Galen Low: C'è davvero qualcosa di così diverso nel processo di sviluppo di un prodotto che ha funzionalità native AI rispetto ad altri prodotti che magari si limitano a integrare le tecnologie AI esistenti?

Jyothi Nookula: Sì. Quando costruisci un prodotto AI nativo, ti trovi ad affrontare tre cose che fanno la differenza. Prima di tutto, l'AI è fondamentalmente imprevedibile.

Galen Low: Qual è la prima cosa che fai come leader quando noti che un team non è tutto allo stesso livello riguardo la comprensione, l'utilizzo e perfino l'accettazione di tecnologie emergenti come l'AI?

Jyothi Nookula: Separo il problema in due questioni distinte. Il primo problema è la competenza. Il secondo è la predisposizione. Se tratti un problema di predisposizione come fosse un problema di competenza, finirai solo per peggiorarlo.

Galen Low: Quali sono le cose fondamentali che un product manager interessato a sviluppare prodotti AI dovrebbe avere nel CV o nel portfolio per distinguersi dagli altri?

Jyothi Nookula: Uno è la prova concreta di aver costruito qualcosa con l’AI, non solo parlarne. La seconda cosa è...

Galen Low: Benvenuti al podcast The Digital Project Manager — il programma che aiuta i leader della delivery a lavorare in modo più smart, consegnare più velocemente e guidare meglio nell’era dell’AI. Io sono Galen, e ogni settimana approfondiamo strategie reali, nuovi strumenti, framework collaudati e qualche aneddoto dal fronte dei progetti. Che tu stia gestendo trasformazioni su larga scala, orchestrando flussi AI o solo cercando di tenere sotto controllo il caos, sei nel posto giusto. Iniziamo.

Oggi parliamo del futuro del product manager, di cosa serve per sviluppare prodotti AI, di come l’AI viene utilizzata per semplificare lo sviluppo e il rilascio dei prodotti e di cosa possono fare i team lead quando le competenze e le attitudini all’interno dei loro team sono distribuite in modo irregolare rispetto alle nuove tecnologie come l’AI.

Con me in studio oggi c’è Jyothi Nookula. Jyothi vanta oltre 13 anni di esperienza nell’innovazione di prodotti e piattaforme AI per aziende come Netflix, Meta, Amazon AWS ed Etsy. Detiene 12 brevetti di machine learning e ha formato oltre 1500 product manager nel passaggio a ruoli AI tramite la sua società educativa, Next Gen Product Manager.

Jyothi, grazie mille per essere con me oggi.

Jyothi Nookula: Ciao a tutti. Sono entusiasta di essere qui oggi.

Galen Low: Anche io sono molto contento, e aspettavo questa chiacchierata da settimane. Quando ci siamo sentiti la prima volta e ho visto il tuo profilo sono rimasto davvero colpito: Jyothi è un vero peso massimo. Ci sono tanti brand e tecnologie nel tuo percorso davvero da invidiare.

Poi sono sempre affascinato dalle persone che cercano di aiutare la prossima generazione di qualsiasi mestiere a migliorare in un mondo sempre più tecnologico e ora orientato all’intelligenza artificiale. Quando abbiamo chiacchierato ho pensato: abbiamo così tanto in comune! Io mi occupo più di progetti, tu più di prodotto. Ma sono davvero curioso di approfondire come stanno cambiando le cose e alcune delle lezioni che hai imparato nel tuo percorso di prodotti AI e machine learning.

So che probabilmente faremo anche delle digressioni durante l’episodio, che saranno interessanti e di valore, quindi lo spero davvero. Però, da project manager quale sono, ho preparato una roadmap per oggi. Vorrei partire subito con una domanda scottante, scomoda ma centrale che credo tutti vorrebbero farti.

Poi però vorrei allargare lo sguardo su tre cose. Primo, discutere dell’identificazione e del colmare i gap di competenze nei team di prodotto, soprattutto quando si tratta di prodotti che sfruttano AI e machine learning. Poi esplorare alcuni esempi di come i tuoi team hanno utilizzato strumenti AI nel ciclo di sviluppo del prodotto, dalla ricerca all’analisi dati, al design, all’ingegneria, ai test utenti o altro ancora.

Infine, capire come si delineerà il futuro per chi si occupa di product management: cosa serve su un CV o portfolio per essere presi in considerazione da brand come Meta, AWS, Netflix, Etsy e altri pesi massimi che credono nell’AI.

Jyothi Nookula: Mi piace! Davvero. È il tema caldo del momento. Mi esalta.

Galen Low: Fantastico. Partiamo dalla grande domanda. Quindi, il mio quesito per inquadrare tutto è: parliamo di AI. Perché tu hai moltissima esperienza nel lavorare con team prodotto per sviluppare soluzioni AI e machine learning per giganti come Meta, Amazon, Etsy, Netflix. Quello che ti chiedo è: c’è davvero una differenza sostanziale tra il processo di sviluppo di un prodotto con funzionalità native AI e quello di un prodotto che integra semplicemente tecnologie AI esistenti?

Jyothi Nookula: Domanda ottima perché va al cuore di ciò che sta davvero cambiando nello sviluppo prodotto in questo momento. La risposta, onestamente, è sì, ma non nel modo in cui le persone pensano. Cosa intendo? Quando costruisci un prodotto AI nativo ti trovi davanti 3 fattori diversi sia rispetto al software tradizionale, sia rispetto a prodotti che integrano AI tramite API.

Prima di tutto, l’AI è imprevedibile. Nello sviluppo prodotto classico scrivi codice deterministico: se succede X, allora fai Y. O se clicchi su un tasto, vai sempre alla stessa schermata. Ogni volta che clicchi, succede la stessa cosa. Nei prodotti AI nativi, invece, hai sistemi probabilistici: la feature AI potrebbe comportarsi in modo diverso ad ogni esecuzione.

Questo significa che tutto il tuo processo di QA, la gestione dei casi limite, le garanzie di affidabilità, devono essere ripensati da zero. Non stai semplicemente testando che qualcosa funzioni, ma se funziona abbastanza bene, e se lo fa in modo coerente su una distribuzione di risultati.

Il primo vero elemento distintivo è questa imprevedibilità, questa differenza fra deterministico e probabilistico. Il secondo è che ora costruisci su fondamenta che si muovono: i modelli sottostanti evolvono senza che tu possa controllarli. Ad esempio, un nuovo modello può cambiare comportamento, magari non in modo drastico ma sufficientemente da cambiare le capacità o introdurre nuovi modi di fallimento. E questo può accadere di notte, alla velocità attuale.

Quindi, a differenza delle dipendenze tradizionali che potevi gestire versionando le breaking changes, e documentando gli update, qui i modelli si aggiornano più rapidamente di quanto tu riesca a seguirli. Il terzo punto (importante!) è che cambiano anche le metriche di successo. Non puoi più semplicemente chiederti: “La feature ha funzionato?”. Ora devi chiederti: “L’output è stato utile?”. Non basta che sia stato eseguito: serve utilità.

Ha rispettato l’intento dell’utente? Ha risposto davvero alla domanda che poneva? E come si definisce la qualità (“buono”) in questo contesto? Servono feedback loop molto più rapidi con gli utenti e devi integrare i meccanismi di validazione direttamente nello sviluppo. È una pratica profondamente diversa rispetto al prodotto classico.

Queste sono le tre differenze vere. I prodotti che si appoggiano a AI esterne, ad esempio integrando ChatGPT, possono rimanere sviluppi piuttosto tradizionali — hai comunque metriche di successo e controlli da eseguire, ma almeno esiste un contratto. Se invece crei da zero un prodotto AI nativo, la questione cambia profondamente. Ed è qui che le tre differenze incidono davvero nello sviluppo prodotto.

Galen Low: È divertente perché entrando in questa domanda pensavo mi avresti detto: “È quasi la stessa cosa, ci sono solo alcune differenze”. Invece cambia davvero tutto.

Quello che hai detto sulle metriche è illuminante. Io vengo dal mondo progetto: abbiamo i requisiti, è tutto binario. Sì o no: ha fatto quello che c’era scritto? Ma lì c’è ambiguità. Perché è probabilistico: l’esito non è sempre lo stesso. E poi c’è l’architettura di base, che è una sorta di black box che si evolve da sola, spesso più velocemente della nostra comprensione umana. Quindi è davvero qualcosa di diverso rispetto ai prodotti digitali degli ultimi anni.

Ci rifletto: hai oltre un decennio di esperienza in machine learning e AI. Molte persone hanno iniziato solo da poco più di due anni. ChatGPT ha spinto tutti a scoprire cosa può fare l’AI, ma questa tecnologia era già in tanti software e prodotti digitali.

La cosa a cui penso è questa: perché tu hai visto Netflix dal di dentro, io guardo Netflix e mi sembra tutto semplice. Ma immagino non lo sia. L’algoritmo, il machine learning e i dati, non basta che tutti i contenuti abbiano una tassonomia; non è come i “link correlati” su un sito. Conta il comportamento, l’intento, ed è facile sbagliare. Anzi, spesso nemmeno ci si rende conto di quanto si stia sbagliando, almeno fino a quando un utente non scrive il classico tweet: “Il mio Netflix non ci prende: ho guardato X e ora mi consiglia 18 stagioni di Barney”.

Jyothi Nookula: Sì, succede sempre, anche su Instagram reels e TikTok. Ti basta guardare un video sugli sci, ed ecco che sei invaso da video sugli sci. Sì.

Galen Low: È qualcosa che diamo talmente per scontato! Sarebbe facile per chiunque — anche per me — pensare: “Sembra facile, bastano le stesse competenze”. Ma, ragionandoci, non è così. Allora, allargherei la prospettiva perché oltre al tuo ruolo da protagonista in grandi prodotti digitali per Amazon, Meta, Netflix, Etsy, sei anche fondatrice di Next Gen Product Manager che, tra le altre offerte, comprende una sorta di bootcamp di 5 settimane per passare dal product management “classico” a quello AI — giusto?

Il solo fatto che il tuo corso esista mi dice che le competenze convenzionali del product management oggi non bastano più: serve una mentalità e una skillset più orientata al futuro. Può darsi che tu abbia potuto scegliere con cura chi lavorava nei team, ma è chiaro che non tutti i membri condividono le stesse competenze e attitudini riguardo AI e novità tecnologiche.

La domanda è: cosa fai per prima cosa, come leader, quando vedi che il team non è tutto sullo stesso livello di comprensione, utilizzo o perfino accettazione delle nuove tecnologie come AI?

Jyothi Nookula: Questa è una sfida concreta e molto reale, che affronto spesso. Ho guidato team di varie dimensioni, da 3-5 fino a 12 persone. In tutta la mia carriera non ho mai visto un divario di competenze e di comfort come quello attuale sull’AI.

La mia prima mossa quando affronto questo problema è distinguere tra due questioni: la prima è la competenza — chi non sa lavorare con l’AI in modo efficace. La seconda è la predisposizione — chi è scettico, resistente o anche ansioso rispetto all’AI.

Devi diagnosticare: ti trovi davanti a un problema di competenza, di attitudine o a entrambi? È importante riconoscere che problema stai risolvendo: se tratti una questione di predisposizione come fosse una mancanza di competenza, peggiori soltanto la situazione. Per i gap di competenza, la mia prima risposta è creare un contesto condiviso attraverso il fare, non imparare.

Lo stesso principio lo insegno anche ai miei studenti nel corso di 5 settimane in AI product management: si impara facendo e non solo ascoltando. Non manderò le persone a fare training o a guardare tutorial. Invece, inserisco subito l’AI nei flussi di lavoro esistenti, con attività a basso rischio.

Ad esempio, uso Claude o GPT per scrivere retrospettive di sprint, sintetizzare temi, svolgere ricerche approfondite o riassumere indagini utenti: qualcosa di concreto, che fa risparmiare tempo — senza che le persone percepiscano che lo strumento le stia sostituendo. Dopo circa due settimane, in una riunione chiedo: “Raccontatemi qualcosa che l’AI vi ha aiutato a fare più rapidamente” oppure “Quale insight non avreste avuto senza l’AI?”. Queste esperienze condivise diventano la base per costruire nuova competenza, insieme.

Quando invece si tratta di una questione di predisposizione, cioè resistenze o timori, la strada migliore è guidare con curiosità e non con evangelismo. Nei one-to-one chiedo: “Qual è la tua vera preoccupazione?” e poi ascolto davvero. Di solito emergono cose legittime: qualcuno dice che teme la svalutazione del proprio mestiere, altri non si fidano dei risultati perché non li possono verificare, altri ancora si sentono sopraffatti e temono di restare indietro.

Qui ho imparato che non puoi convincere qualcuno razionalmente a smettere di temere. Puoi solo riconoscerlo, normalizzarlo e mostrare una via d’uscita. A chi teme di perdere valore, mostro come l’AI può liberare tempo per attività di giudizio e valore aggiunto. A chi si preoccupa della verifica, suggerisco di costruire assieme i framework di valutazione: così diventano loro stessi esperti nel QA dell’AI.

Un altro elemento che funziona molto bene è identificare subito le persone “ponte”. In ogni team c’è chi è curioso e sperimenta, ottiene risultati e sperimenta innovazione. Do a queste persone il permesso esplicito di condividere ciò che funziona, magari in modo informale durante gli standup o in mini sessioni. Così si crea apprendimento peer-to-peer: vedere un collega adottare l’AI è molto più persuasivo che sentirsi dire cosa fare da un leader.

Infine, anche se può sembrare scomodo, arrivo velocemente a stabilire che la familiarità con l’AI sta ormai diventando un’aspettativa base. Sono empatica con la curva di apprendimento e paziente con il processo, ma chiara sulla direzione: non è più opzionale. Come quando tutti si sono trovati a dover imparare Agile o Analytics: fa parte del lavoro.

Ho visto che combinando supporto forte con aspettative chiare si riduce l’ansia: i team che soffrono di più sono quelli in cui i leader non danno direzione né vero supporto. È lì che crea frustrazione e senso di impotenza.

Lo scopo non è avere tutti subito allo stesso livello, ma far sì che tutti vadano nella stessa direzione, con sicurezza psicologica e strumenti pratici.

Galen Low: Mi piace davvero molto questa distinzione tra competenza e predisposizione. È una sorta di management del cambiamento e team building in tempo reale.

Abbiamo la tendenza a pensare al change management soltanto come a un’iniziativa che tiri fuori durante una grande trasformazione, quasi una tantum. Invece qui è una gestione del cambiamento continua con il team: supportato, non lasciato solo con l’obbligo di imparare. Così si costruisce sia la competenza collettiva che una disposizione positiva di squadra: più collaborazione dal basso, più chiarezza, e il sapere che stiamo spingendo tutti dalla stessa parte. Più “peer support” che “peer pressure”.

Si condividono conoscenze e si affrontano insieme le ansie legittime sull’AI. Vedere i colleghi gestire la situazione e portare davvero l’AI sul campo, nel quotidiano, è molto più efficace della pura teoria. E poi, imparare facendo è fondamentale: mi fa piacere che tu lo abbia incluso nel tuo metodo di insegnamento. E mi ha colpito molto la cosa della chiarezza: aspettative alte e supporto chiaro danno la spinta giusta.

Sul fatto che se l’AI è solo una moda passeggera ormai quasi nessuno ha più dubbi: questa decisione è presa e ora bisogna muoversi insieme.

Jyothi Nookula: Esatto.

Galen Low: Facevi riferimento a piccoli esperimenti e “pilota” per coinvolgere il team nell’AI e farli crescere in sicurezza e competenza. Immagino che le possibilità siano molte e che l’AI entri in ogni fase dello sviluppo prodotto. Puoi farci qualche esempio di altri modi in cui i tuoi team impiegano l’AI nella progettazione e sviluppo del prodotto?

Jyothi Nookula: Sì. Ti posso fare esempi concreti sull’intero ciclo di vita di sviluppo prodotto.

Galen Low: Fantastico.

Jyothi Nookula: A partire dalla discovery e dalla ricerca, usiamo l’AI per comprimere i tempi della generazione di insight. Per esempio: normalmente un team fa 15/20 interviste utenti e ci vuole una settimana solo per individuare i temi dominanti. Invece, carichiamo le trascrizioni su Claude e chiediamo di trovare pattern, contraddizioni, casi limite.

Ma il vero valore arriva dal confronto: poi il ricercatore umano rivede e mette in discussione l’output, lo affina. La presenza umana resta decisiva: l’AI dà una bozza forte in un’ora, risparmiando una settimana, e la persona umana investe il tempo a valutare quali insight sono davvero importanti o sfidano le nostre convinzioni.

Stesso discorso sui ticket di supporto (se il prodotto è già live): i volumi sono enormi. Piuttosto che smaltirli manualmente, li analizziamo in massa con l’AI per individuare i punti dolenti principali, la loro gravità e la portata. L’AI fa emergere pattern che a mano sarebbe impossibile scoprire.

Così come product manager, guardando sia user research che ticket di supporto, sei più in grado di stabilire la priorità su cosa correggere e quali feature inserire in roadmap.

Anche nella documentazione e comunicazione l’AI elimina tutte le attività ripetitive. Abbiamo chi usa l’AI per scrivere PRD, riassumere review degli sprint, creare report per i stakeholder. L’AI produce bozze solide: uno dei miei PM diceva che prima spendeva il 30% del tempo in documentazione, ora lo dedica ad affinare — attività ben più preziosa perché parte già da una base forte.

Stiamo usando l’AI anche per rendere la documentazione più accessibile. Qualcuno può chiedere: “Che abbiamo deciso sulla riprogettazione del flusso pagamento?” e ricevere una risposta sintetica da thread Slack, meeting, e PRD.

Quindi su tutto il ciclo di sviluppo, dall’esperimento alla documentazione fino al rapporto con l’ingegneria, il PM non scrive più solo la PRD — che ancora resta fondamentale — ma aggiunge anche un prototipo, perché è più efficace mostrare e testare qualcosa che elencare storie. Un semplice prodotto test per il market fit da consegnare al team di ingegneria.

La PRD descrive visione, come valutare la feature, quando e come dovrebbe funzionare, cosa è “buono” e cosa è “cattivo”, ma oggi il prototipo racconta l’interattività e come immaginare davvero il prodotto. Quindi vediamo l’AI in azione in tutte le fasi del ciclo di sviluppo.

Galen Low: Apprezzo molto che tu abbia toccato questo tema visto che di recente ho discusso con altri product manager se i PRD siano superati. Ne parlavo con una collega, sosteneva che non sono morti: servono riflessioni profonde che solo una mente umana può portare. Lei aveva anche sviluppato una piccola app che generava le buone domande strategiche per dare senso al prodotto. Serve sempre visione strategica, come rispondere agli utenti e portare il prodotto sul mercato.

Mi piace tantissimo l’idea della “macchina della prima bozza”. Però una domanda: nel mondo progetto molti usano la prima bozza AI e poi si fermano. I tuoi team continuano ad allenare l’AI fornendole versioni revisionate per migliorare il motore della bozza?

Jyothi Nookula: Noi lo chiamiamo “one shot”, cioè molti danno per scontato che basti una sola interazione con l’AI per ottenere un report valido, ma raramente è così. Di solito ottieni una bozza forte, poi iteri, inserisci input tuoi, chiedi di criticare e perfezionare, ricevi altri suggerimenti e scegli cosa integrare o meno. È come un partner con cui affini gradualmente il risultato finché non ti convince davvero.

Se tratti l’AI come una cosa a colpo unico, non funziona. Il valore cresce lavorandoci in modo iterativo, è facile imparare come si usa ma è difficile insegnare il gusto. Il “gusto” resta prerogativa del product manager.

Galen Low: Mi piace molto l’idea di “gusto”. Trovi che molte persone ora passino il 30% del tempo a revisionare documenti, oppure a dialogare con la “macchina” invece che con umani? Una parte importante del lavoro del PM è umana: interviste, research, relazione con i dati. L’AI offre dati con cui magari non hai un rapporto diretto. Pensi che qualcuno tema una perdita di umanità nel lavoro, passando tanto tempo a parlare con robot invece che con persone?

Jyothi Nookula: Non penso si tratti davvero di “parlare coi robot”, perché l’AI non sostituisce tutti i rapporti. Devi comunque convincere gli stakeholder, collaborare con il team engineering. Il PM resta al centro delle relazioni. L’AI è come un assistente utile con cui puoi fare brainstorming, e spesso i nostri PM la usano proprio per questo scopo, anche di corsa tra una riunione e l’altra. È più una compagnia costante che un vero robot distaccato.

Galen Low: Faccio l’avvocato del diavolo: tu hai lavorato in aziende dove sono certo qualcuno ti ha chiesto: “Jyothi, non potremmo semplicemente automatizzare il processo?” Non serve un umano; si analizzano i ticket, l’agente AI fa la prioritizzazione, sviluppa le nuove funzioni e le rilascia. A) Non dirmi se ti è successo… o sì, se vuoi… B) Come si risponde efficacemente a chi ti propone una soluzione tech-first (prima la tecnologia) invece di human-first o user-first, soprattutto quando lavori ad alti livelli in grandi tech company dove la pressione a sfruttare le nuove tecnologie è fortissima?

Jyothi Nookula: Mi capita spesso, sia quando faccio consulenze sia con i miei studenti: è una vera “malattia” ora, dove tutti vogliono partire dall’AI dimenticando i problemi dell’utente. Spingere in senso opposto è dura, anche perché gli incentivi istituzionali vanno nella direzione sbagliata: gli executive leggono gli stessi tre articoli sull’AI come scenario esistenziale, gli investitori chiedono la strategia AI in ogni call, gli ingegneri sono entusiasti e alle hackathon c’è la corsa all’AI. C’è quindi una pressione enorme.

Quello che faccio è sempre tornare ai primi principi del prodotto: partire dagli utenti e dai problemi prima che dagli algoritmi. Anche ai miei studenti ripeto: utenti prima degli algoritmi. Se qualcuno è gasato o se un VP viene a dire: “C’è questa nuova AI multimodale/voce/etc…”, io non dico no, ma rimando indietro la domanda: “Bella tecnologia, ma quale problema vogliamo risolvere? Raccontami il giorno tipo dell’utente, dove si inserisce questa soluzione? Cosa prova a fare ora il nostro utente? Cos’avviene se questa funzionalità non esistesse?”.

Di solito ci sono tre esiti: uno — capiscono che stavano cercando un problema per la soluzione e l’entusiasmo svanisce perché manca una vera esigenza; due — scoprono che il problema c’è ma la soluzione migliore potrebbe non essere l’AI, magari basterebbe una user experience migliore o una variante deterministica; tre — trovano un problema reale che l’AI può effettivamente risolvere, ed è qui che avviene innovazione vera.

Ad Amazon usiamo il processo “working backwards”: facciamo scrivere una press release per il nuovo prodotto, che ne illustra impatto, valore, testimonianze utenti. Difficile fingere che il risultato sia rivoluzionario, passando da quest’esercizio.

A volte però arriva la direttiva dall’alto (CTO), e sfidarlo direttamente è impossibile. In quei casi cambio registro: “Ok, se dobbiamo farlo, almeno cerchiamo di farlo in modo utile. Troviamo e risolviamo un problema reale invece di una use case forzata”, quindi oriento la proposta: “Sì, usiamola, ma questa esigenza è più urgente/qui abbiamo i dati/qui l’AI è davvero efficace”.

All’inizio della carriera pensavo che il mio compito fosse proteggere la visione di prodotto dalle distrazioni. Ora ho imparato che il vero lavoro è canalizzare l’entusiasmo tech per usarlo a vantaggio degli utenti e degli obiettivi chiave. Non bisogna “bloccare” l’entusiasmo, ma guidarlo verso i risultati utili. Quindi, sempre utenti e problemi, non tecnologia. Nessuno apre Word pensando “scrivo qualcosa a caso, vediamo che succede”…

Galen Low: Dove sei, Clippy, quando ci servi? Scherzi a parte, è stata una lezione magistrale su come navigare la politica interna del product management. Come project manager mi riconosco molto in questa figura del difensore, del guardiano delle fondamenta. Ma mi piace la tua idea di canalizzare l’energia invece che respingerla: è costruttiva e spesso porta risultati. La terza strada che citi (“almeno rendiamola utile”) non la sento spesso, ma nella pratica funziona. E siccome arrivo dal design centrato sull’utente, sono contento che si torni sempre al valore reale per gli utenti.

L’esercizio della press release lo userò: è davvero il modo migliore per arrivare al cuore del valore, non solo rilasciare nuove funzioni. Chiedersi: “Cos’avrà fatto per le persone? Di cosa saremo fieri quando sarà lanciato?”. Splendido.

Jyothi Nookula: Anch’io adoro la press release: la uso ancora oggi, anche dopo anni da AWS. Ti fa davvero cambiare prospettiva.

Galen Low: È utilissima.

Passiamo al futuro, perché da questa chiacchierata si coglie che lo scenario del product management sta cambiando rapidamente: i prodotti, gli strumenti, il modo di lavorare e anche le aspettative su competenze tecniche, business, strategia di rilascio.

Quali sono le 3-4 cose che ritieni fondamentali perché un PM che vuole lavorare su prodotti AI possa distinguersi?

Jyothi Nookula: Grazie per la domanda, davvero pratica, perché quello che cerco su un CV è cambiato radicalmente negli ultimi due anni.

Ecco cosa fa davvero la differenza: prima di tutto la prova concreta di aver costruito qualcosa con l’AI, non solo averne parlato. Come hiring manager, devo coprire una posizione reale, non sto facendo ricerca: voglio vedere che hai effettivamente rilasciato una funzionalità o un prodotto AI nativo. Non basta dire “Ho lavorato in un team che usava AI”, ma: che problema hai risolto con l’AI? Che faceva davvero? Come l’hai valutata? In cosa sei rimasto sorpreso?

Chi ha già rilasciato prodotti AI lo capisce. Chi non ci è ancora riuscito spesso si chiede: “Come faccio?”. E qui dico: forza, createvi un progetto laterale! Anche nel mio corso facciamo molti project hands-on e alla fine hanno un portfolio vero e proprio. E dico sempre: non basta iniziare un mini-progetto, va convertito in prodotto: condividilo con amici e community, raccogli feedback, miglioralo con le osservazioni ricevute. Integra Stripe per vendere anche solo a 1€, non conta il valore, ma rendilo revenue. Così il progetto diventa un prodotto vicino al mondo reale: molto più d’impatto sul CV che limitarsi a scrivere “AI project”. Tanti fanno progetti, pochi costruiscono prodotti veri: fatelo, anche fuori dal lavoro principale.

Secondo: serve mostrare padronanza tecnica, anche se non devi essere un ML engineer o saper programmare. Devi però saper parlare con gli ingegneri e capire bene come funzionano questi sistemi. Nel CV deve emergere: valuta i framework che hai usato, come test A/B, quali trade-off hai gestito (latenza vs qualità, costi vs capacità), che tipi di modelli/architetture conosci.

Il linguaggio conta. Se scrivi genericamente “Ho usato l’AI per migliorare l’esperienza utente”, non dice nulla. Se invece scrivi: “Abbiamo utilizzato un’architettura RAG per ridurre le allucinazioni nel supporto clienti con aumento dell’accuratezza dal X all’Y”, allora capisco che hai le mani in pasta. Il mio test è: sapresti spiegare a un ingegnere perché usare la tecnica A invece della B sul tuo caso, e sapresti spiegarlo anche a un responsabile di business mostrando l’impatto concreto? Il PM AI performante è un traduttore continuo tra tecnica e business.

Terzo elemento chiave: esperienza nella gestione dell’ambiguità e rapidità di iterazione. Nei prodotti AI i modelli cambiano, le capacità evolvono, bisogna essere flessibili e lavorare bene in contesti rapidi e incerti. Nel CV cerca di far emergere se hai lanciato prodotti “da zero a uno”, lavori in ambienti in rapido movimento o dimostri mindset sperimentale/prototipazione veloce, inclusi progetti personali convertiti in prodotto iterando sui feedback reali.

Cosa non cerco: fuffa da buzzword o “soup” di sigle (“Ho usato AI/ML per creare sinergie e ottimizzare...”) o mille certificazioni Coursera o “Sono appassionato di AI”. Sono pattern che non fanno la differenza.

Il vero segnale? La velocità di apprendimento, la profondità nello scontro pratico col problema, la capacità di legare tecnica e necessità utente/business. Se vuoi entrare nell’AI PM e non hai esperienza, puoi creartela. Nessuno te lo vieta. È ok se nel lavoro di tutti i giorni non hai occasioni, ma puoi sempre costruire qualcosa da solo. Puoi raccontare ciò che impari durante la costruzione. Fai case study, teardown di prodotti AI famosi e proponi come li miglioreresti. Oggi la barriera all’ingresso è bassissima, non devi programmare per costruire un’idea. E poi: in pochi hanno 10+ anni di esperienza AI — tutti stanno imparando “sul campo”. La vera differenza la fa chi si butta, non chi aspetta permessi.

Galen Low: Hai descritto benissimo il dilemma che sento spesso: come PM non devo per forza saper programmare, ma c’è un livello intermedio dove serve conoscere il vocabolario per dialogare con tutte le funzioni aziendali e possedere la giusta mentalità, la logica del costruttore e la capacità di vedere gli attriti e i rischi del digitale. Non basta “ho lavorato in tech company X in un certo ruolo” se dal CV non emerge la capacità di gestire ambiguità, capire utenti e fare da interprete tra business e tecnica. Solo così so che puoi essere audace, rapido a imparare, aperto al cambiamento positivo e determinato a migliorare il mestiere portando davvero valore.

Jyothi Nookula: Per questo dico: non aspettare permessi, buttati! Oggi non ci sono barriere per provare.

Galen Low: Jyothi, grazie davvero per il tempo che mi hai dedicato. È stata una chiacchierata bellissima. Prima di salutarti, dove possono trovarti le persone che vogliono conoscerti meglio?

Jyothi Nookula: Mi trovate su LinkedIn come Jyothi Nookula. Oppure su nextgenproductmanager.com, dove scoprirete i miei corsi su AI product management, agentic AI e PM Accelerator.

Galen Low: Fantastico. Metterò i link fra le note o nella descrizione. Jyothi, ancora mille grazie.

Jyothi Nookula: Grazie a te, è stato davvero un piacere.

Galen Low: Ed eccoci alla fine dell’episodio di oggi di The Digital Project Manager Podcast! Se questa conversazione ti è piaciuta, iscriviti dove ascolti i podcast. E se vuoi altri insight pratici, case study e playbook, vai su thedigitalprojectmanager.com. Alla prossima!