Fondatore tech ed ex-VP di Prodotto afferma che l’IA sta peggiorando i team di prodotto — non migliorandoli
Scopri perché uno sviluppo di prodotto più veloce non garantisce risultati migliori e come l’IA può migliorare le decisioni di prodotto se abbinata a flussi di lavoro solidi e una chiara convinzione.
Adam Root
Fondatore di Root Ventures
Impatto dell’IA: L’IA sta peggiorando i team di prodotto poiché elimina le protezioni contro decisioni errate.
Focus sui Sistemi: La leadership efficace di prodotto si concentra sui sistemi piuttosto che sui modelli o sulle funzionalità dell’IA.
Basato su Evidenze: Dare priorità a sistemi supportati da evidenze migliora l’esecuzione e riduce il rischio di diffondere rapidamente idee sbagliate.
Flussi di Lavoro: Flussi di lavoro integrati e potenziati dall’IA migliorano lo sviluppo del prodotto dall’aggregazione dei dati fino alla validazione delle decisioni.
Problemi di Fiducia: L’apparente accuratezza dell’IA comporta rischi; una vera responsabilità richiede la supervisione umana nelle decisioni.
Adam Root ha ricoperto ruoli di VP of Product in diverse aziende tecnologiche. Attualmente è il fondatore di Root Ventures, dove sviluppa prodotti SaaS basati su flussi di lavoro.
Abbiamo parlato con Adam per capire come l’IA stia cambiando il ciclo di vita del prodotto — e come, in realtà, stia peggiorando la situazione di alcuni team. Ecco cosa ci ha raccontato.
L’IA sta peggiorando i team di prodotto
L’IA sta peggiorando la maggior parte dei team di prodotto, non migliorandoli — perché elimina quella frizione che una volta proteggeva i team dalle decisioni sbagliate.
Vuoi di più da The CPO Club?
Iscriviti gratuitamente per completare la lettura di questo articolo:
Have an account? Log In
Negli ultimi oltre 17 anni, ho scalato piattaforme SaaS, guidato iniziative basate sull’IA e portato risultati misurabili, tra cui la crescita dei ricavi da $20k a $400k MRR e l’ottenimento di un impatto a livello enterprise. All’inizio della mia carriera credevo che la parte più difficile fosse costruire, rilasciare funzionalità, far crescere i team e portare avanti una roadmap. Quello che ho imparato, soprattutto negli ultimi anni, è che la vera sfida è trasformare l’ambiguità in convinzione. L’IA ha reso questa differenza impossibile da ignorare.
Oggi, chiunque può generare un prototipo o spedire rapidamente utilizzando strumenti IA, ma la maggior parte dei team fatica ancora a tradurre ciò in vero valore. Vedo ripetutamente team tecnici molto forti costruire più velocemente, ma senza una chiara tesi di prodotto. Integrano l’IA in flussi di lavoro che non erano mai stati pensati per avere successo. Il risultato è più output, ma non più impatto.
Questa consapevolezza ha cambiato radicalmente il mio approccio alla leadership di prodotto. Ora considero ogni prodotto come un sistema di verità, piuttosto che un insieme di funzionalità. Si parte da una profonda comprensione del problema, lo si valida con prove, e si sequenziano le decisioni in modo tale da creare leva. Solo allora l’IA diventa un vero moltiplicatore. Senza queste fondamenta, accelera solo il rumore.
Oggi quindi mi concentro meno sugli strumenti e più sulla creazione di chiarezza, sull’allineamento dei team attorno a ciò che conta, perché conta e su come genera risultati. Perché quando il sistema è giusto, l’esecuzione si moltiplica.
Costruire un portafoglio AI-native
In questo momento sto costruendo un piccolo portafoglio di prodotti SaaS AI-native e guidati dai flussi di lavoro, in diversi settori, ciascuno progettato per essere al centro dei reali comportamenti degli utenti, non solo per aggiungere funzionalità.
Sotia è un sistema di intelligenza costruito intorno ai dati comportamentali, a partire da Slack, che aiuta la leadership a comprendere lo stato di salute dell’esecuzione in tempo reale. Traduce i modelli di comunicazione in segnali relativi ad allineamento, velocità decisionale e rischio, creando di fatto un nuovo livello tra l’attività grezza e l’insight per il management.
In parallelo, sto costruendo VowVista, una piattaforma di marketplace nel settore delle location per matrimoni, focalizzata a dare fiducia decisionale agli acquirenti della Gen Z. Affronta un acquisto frammentato e ad alto impatto emotivo combinando trasparenza, dati strutturati e flussi di lavoro guidati, aiutando gli utenti a passare dall’esplorazione alla decisione.
Insieme a questi sto continuando a sviluppare piattaforme AI-native per le costruzioni e le operazioni in campo, dove raccogliamo input multimodali come voce, foto e video direttamente dal campo e li trasformiamo in intelligenza strutturata e azionabile per operatori e manager.
In tutto ciò, il filo conduttore è creare prodotti che funzionano come sistemi di record e di intelligenza, progettati per flussi di lavoro reali, con un modello di delivery che unisce iterazione rapida e affidabilità a livello produttivo.
Perché i leader di prodotto dovrebbero concentrarsi sul sistema, non sull’IA
L’IA non è il prodotto. È il sistema che la circonda a esserlo.
La maggior parte dei team parte concentrandosi sul modello, sulla funzione o sulla capacità. Ma nella pratica, il modello è la parte meno distintiva e spesso la più semplice. Il vero lavoro è tutto ciò che sta intorno: i dati, l’integrazione nel flusso di lavoro, l’esperienza utente, il modello di fiducia e il modo in cui il risultato guida una decisione o un’azione reale.
Se sbagli questo, l’IA renderà il tuo prodotto impressionante senza renderlo utile. Rilascerai funzionalità che hanno un bell’effetto nella demo ma che non vengono adottate, perché non sono integrate nel modo in cui gli utenti realmente lavorano o prendono decisioni.
Il vero lavoro è tutto ciò che circonda l’IA: i dati, l’integrazione nei flussi di lavoro, l’esperienza utente, il modello di fiducia e il modo in cui il risultato guida una decisione o un’azione reale. Se sbagli questo, l’IA renderà il tuo prodotto impressionante senza renderlo utile.
Se invece lo fai bene, l’IA diventa un moltiplicatore. Trasforma input disordinati in insight strutturati, riduce la frizione nei flussi di lavoro reali e crea leva sull’intero sistema.
Se lo avessi saputo prima, avrei evitato di investire eccessivamente nell’“intelligenza” prima di convalidare il flusso di lavoro. In alcuni casi, abbiamo creato capacità impressionanti che funzionavano tecnicamente ma non cambiavano il comportamento degli utenti perché non erano integrate nel modo reale di lavorare. Siamo dovuti tornare indietro e riprogettare sul flusso di lavoro, non sul modello.
Come i sistemi basati su evidenze possono migliorare l’esecuzione
Ho fatto un passaggio dalla costruzione di funzionalità alla realizzazione di sistemi basati su evidenze prima di scrivere codice — utilizzando l’IA come strato di sintesi e validazione già nelle prime fasi del processo.
In passato, anche i team più forti passavano dalla discovery alle specifiche relativamente in fretta. Quel modello si rompe in un mondo rafforzato dall’IA perché il costo della realizzazione si è abbassato tantissimo. Si possono generare e distribuire soluzioni più velocemente di quanto si possa validare se dovrebbero esistere. Questo crea un nuovo rischio di fallimento: i team scalano le idee sbagliate a una velocità incredibile.
La discovery ora deve diventare una funzione continua, guidata dal sistema, non una fase. Ciò significa:
- Aggregare segnali reali su larga scala, compreso il comportamento degli utenti, dati di supporto, analisi win-loss e input qualitativi
- Usare l’IA per sintetizzare pattern tra questi input, non solo per riassumerli
- Mappare esplicitamente i problemi sui flussi di lavoro e misurare se il prodotto li sta effettivamente affrontando
- Rivalidare costantemente le ipotesi all’arrivo di nuovi dati
Per esempio, io lancio prompt strutturati su diverse fonti dati per far emergere problemi ricorrenti, associarli ai flussi di lavoro e testare esplicitamente se il prodotto li sta davvero risolvendo. Questo processo spesso invalida le idee iniziali o le trasforma profondamente prima che arrivino a design o ingegneria.
Quello che cambia di conseguenza è la qualità della convinzione. Costruiamo meno cose, ma quelle che facciamo sono molto più strettamente allineate ai problemi reali. Cambia anche il modo in cui operano i team. Invece di discutere opinioni, reagiamo a evidenze sintetizzate. Per me, quindi, l’IA non serve solo a velocizzare l’esecuzione, ma soprattutto ad aumentare la precisione di ciò su cui scegliamo di investire ed eseguire.
Come l’IA sta condensando l’intero flusso dal segnale al rilascio
Ecco un flusso di lavoro potenziato dall’IA che utilizzo per andare dal segnale grezzo degli utenti fino a rilascio e validazione di un ciclo prodotto.
Si parte dall’aggregazione dei segnali. Raccolgo dati qualitativi e comportamentali, inclusi interviste a coppie, discussioni su Reddit, recensioni di location, punti di abbandono nel funnel e domande in entrata. Invece di analizzare ciascuna fonte manualmente, uso l’IA per sintetizzare tutto e identificare problemi ricorrenti, la loro frequenza e dove si inceppano gli utenti nel processo decisionale.
Da lì, passo alla strutturazione dei problemi. L’IA aiuta a raggruppare questi segnali in dichiarazioni di problema chiare, legate a momenti specifici del flusso di lavoro. Poi metto alla prova questi problemi chiedendomi: “È frequente, doloroso e risolvibile dal prodotto?”
La fase successiva è la definizione delle soluzioni. Uso l’IA per esplorare rapidamente diversi modi di risolvere il problema, non solo con funzionalità, ma con modifiche al workflow. La chiave è generare più approcci in tempi rapidi, poi selezionare quello che meglio si adatta al comportamento dell’utente.
Dopo, si passa allo sviluppo e all’strumentazione. Con strumenti di sviluppo assistiti da IA, passiamo rapidamente dal concetto a una versione funzionante, ma con la strumentazione già integrata. Monitoriamo se gli utenti interagiscono con il nuovo flusso, dove si interrompono, e se ciò migliora la fiducia decisionale o la progressione.
Dopo, il processo diventa un ciclo di apprendimento. L’IA analizza i pattern di utilizzo, il feedback qualitativo e i casi limite per identificare cosa funziona e cosa no. Verifichiamo se il cambiamento ha effettivamente modificato il comportamento, non solo se è stato utilizzato dagli utenti.
Infine, tutto rientra in iterazione o eliminazione. Se il workflow migliora i risultati, lo estendiamo. Se non funziona, lo perfezioniamo o lo rimuoviamo rapidamente.
Claude, collegato ai miei dati di prodotto e ai segnali degli utenti, gestisce quasi tutto questo flusso.
Come l’IA può creare una falsa sicurezza
Il miglior risultato che sto vedendo con l’IA è un enorme aumento nella velocità di raggiungere chiarezza. L’IA ha compresso attività che richiedevano giorni in poche ore, soprattutto nella discovery, sintesi e definizione preliminare del prodotto. Posso analizzare molti più input, individuare pattern più rapidamente e testare le idee prima che il team impegni risorse. Qualitativamente, questo ha portato a una migliore impostazione iniziale, meno idee deboli nelle discussioni sulla roadmap e una maggiore coerenza tra prodotto, design e ingegneria.
Ha anche migliorato il rendimento nella creazione del prodotto stesso. Nell’ultimo anno, ho usato workflow assistiti dall’IA per passare dal concetto a un prodotto funzionante molto più velocemente rispetto ai cicli tradizionali. Questo ha incluso il passaggio dall’inquadramento del problema all’architettura, ai PRD e al software utilizzabile in una frazione del tempo solito. Il vantaggio non è solo la velocità. È la possibilità di testare i veri workflow prima, migliorando così la velocità di apprendimento.
Non è tutto rose e fiori, però. L’AI può creare una falsa fiducia. I team possono scambiare un output ben presentato per qualità del prodotto. Un prototipo sembra convincente, la specifica sembra completa e tutti hanno la sensazione che ci sia progresso, anche quando il flusso di lavoro sottostante, il modello di fiducia o la necessità dell’utente non sono ancora stati risolti. Ho anche visto l’AI aumentare il rumore quando viene usata senza una forte visione di prodotto. Può generare più idee, più testi, più ticket e più artefatti di quanti un team possa realisticamente valutare, il che può addirittura peggiorare la priorità delle attività.
Dove l’AI non è all’altezza nei prodotti
L’AI non ha chiaramente prodotto i miglioramenti che mi aspettavo nelle capacità di giudizio di prodotto e nell’impatto sostenuto sul prodotto.
Inizialmente pensavo che l’AI avrebbe migliorato notevolmente la prioritizzazione e la qualità delle roadmap rendendo evidenti i pattern. Aiuta a far emergere i pattern, ma non risolve ciò che conta realmente. La parte difficile resta interpretare i compromessi, capire gli effetti secondari e impegnarsi su una direzione in condizioni di incertezza. L’AI contribuisce a questo processo, ma non lo sostituisce. Non l’ho mai vista produrre regolarmente decisioni di prodotto migliori da sola.
Si è anche dimostrata carente nel favorire l’adozione reale. Le funzionalità di AI spesso danno ottimi risultati in demo, ma ciò non si traduce in utilizzo ripetuto a meno che non siano integrate a fondo nei flussi di lavoro effettivi. Ho visto team lanciare capacità di AI impressionanti che gli utenti provano una volta e poi non tornano più, perché il prodotto non ha cambiato i comportamenti o non è diventato parte integrante delle attività lavorative.
Un’altra carenza riguarda la riduzione della complessità. Mi aspettavo che l’AI semplificasse la progettazione e la gestione dei prodotti, ma in molti casi introduce nuovi livelli di complessità, tra cui logica dei prompt, casi limite, difficoltà di valutazione e questioni di fiducia. Invece di eliminare lavoro, lo sposta in nuove aree che richiedono comunque una forte disciplina nel prodotto e nell’ingegneria.
Perché la responsabilità deve restare umana
Uso l’AI intensamente ovunque contino la scala e il riconoscimento dei pattern, mentre mantengo il coinvolgimento umano ovunque il giudizio, il rischio o il gusto incidano sull’esito.
Per quanto riguarda l’AI, la sfrutto soprattutto nella fase di discovery e sintesi. Inserisco trascrizioni, ticket di assistenza, dati di vittorie e sconfitte e segnali comportamentali per individuare problemi ricorrenti, quantificarne la frequenza e mappare tali problemi sui flussi di lavoro. È altrettanto utile nelle fasi iniziali di prioritizzazione, non per prendere decisioni, ma per mettere alla prova le ipotesi mostrando compromessi, effetti secondari e punti di vista alternativi a cui potrei non aver pensato. Nella sperimentazione, l’AI aiuta a generare ipotesi, scrivere varianti e analizzare rapidamente i risultati, specialmente quando si gestisce una grande quantità di feedback qualitativi.
Per quanto riguarda l’AI, la sfrutto soprattutto nella fase di discovery e sintesi. È altrettanto utile nelle fasi iniziali di prioritizzazione, non per prendere decisioni, ma per mettere alla prova le ipotesi mostrando compromessi, effetti secondari e punti di vista alternativi a cui potrei non aver pensato.
Dove mantengo esplicitamente l’elemento umano è nella determinazione e nell’impegno. Le decisioni finali di prioritizzazione, la sequenza della roadmap e ciò che scegliamo di non sviluppare restano comunque di competenza mia e del team di leadership. Lo stesso vale per le decisioni UX che richiedono gusto, fiducia e sensibilità emotiva. Anche i compromessi tecnici restano affidati agli esseri umani, poiché implicano una riflessione di lungo periodo sui sistemi, la tolleranza al rischio e vincoli organizzativi che l’AI non può assimilare completamente.
Il motivo è semplice: l’AI è eccellente nel comprimere informazioni ed espandere lo spazio delle soluzioni, ma non si assume le conseguenze. La leadership di prodotto, in ultima analisi, consiste nel prendere decisioni irreversibili o di alto costo in condizioni di incertezza. Questa responsabilità deve restare umana.
Perché i leader di prodotto devono vigilare sulla falsa fiducia su larga scala
I leader di prodotto spesso sottovalutano il rischio della falsa fiducia su larga scala.
I sistemi di AI sono molto bravi a produrre risultati che sembrano corretti, anche quando non lo sono. Il pericolo non è un fallimento ovvio. È la plausibile accuratezza. Qualcosa che appare giusto, suona convincente, ma è errato in modi non immediatamente rilevabili.
Su piccola scala, un utente potrebbe accorgersene. Su scala di prodotto, lo stesso errore si ripete in migliaia di interazioni, influenzando silenziosamente decisioni, flussi di lavoro e risultati.
L'ho visto accadere in ambiti come l'interpretazione di documenti, le raccomandazioni e l'automazione dei flussi di lavoro. Il sistema funziona abbastanza bene la maggior parte delle volte, tanto che gli utenti iniziano a fidarsi, ma sono i casi limite quelli in cui risiede il vero rischio. E proprio quei casi limite spesso comportano le conseguenze più gravi.
Ciò che rende questa situazione particolarmente pericolosa è che gli istinti tradizionali di chi sviluppa prodotti non la rilevano. Non si vede un calo o un crash. Si vede coinvolgimento. Il prodotto “funziona”. Fino a quando non lo fa più.
La mitigazione non consiste solo in modelli migliori. Si tratta di progettare per la fiducia e la verifica:
- Mostrare le prove, non solo le risposte
- Esporre sicurezza e incertezza
- Creare precisi punti di controllo in cui l'uomo è coinvolto
- Monitorare quando il sistema è in errore, non solo quando viene utilizzato
Il rischio sta nell'assumere che l'accuratezza cresca linearmente con l'uso. Nella realtà, il rischio si accumula più velocemente di quanto non aumenti l'accuratezza.
Come il giudizio dell’AI può diventare fragile
L’AI ha maggiori difficoltà quando il prodotto deve comprendere l’impatto umano, l’ambiguità e il costo dell’errore, non solo generare una risposta plausibile.
Un buon esempio è nei flussi di lavoro orientati alla conformità o che richiedono grande fiducia. Ho lavorato su concetti di prodotto in cui l’AI può estrarre informazioni dai documenti, segnalare problemi e raccomandare azioni successive. Sulla carta, sembra il caso d’uso perfetto per l’AI. In pratica, la vera difficoltà è che il modello può produrre una risposta con grande sicurezza, ma mancare il contesto importante, interpretare male una clausola o non comprendere perché una eccezione sia più rilevante di un’altra.
Si crea così immediatamente un problema di fiducia. L’utente non si chiede: “Questa uscita è impressionante?” Si chiede: “Posso farci affidamento senza creare rischi a valle?”
Quello che ho imparato è che l’AI spesso è debole nel giudizio quando:
- Il contesto è parziale
- Le conseguenze dell'errore sono asimmetriche
- L’utente ha bisogno di una spiegazione, non solo di un risultato
Come l’AI sta ristrutturando i team
L’AI ha cambiato la struttura dei miei team di prodotto: da silos basati sui ruoli a team più piccoli, integrati e orientati al sistema.
In passato, i team erano strutturati intorno a passaggi ben definiti: il prodotto definisce, il design progetta, l’ingegneria costruisce, i dati vengono analizzati. Questo modello non funziona più quando l’AI riduce il tempo di esecuzione e introduce sistemi probabilistici che richiedono cicli di feedback molto stretti.
Ora tendo verso meno persone in grado di operare oltre i confini dei ruoli. I product manager devono approfondire i dati, la progettazione dei prompt e la logica dei flussi. Gli ingegneri sono più vicini al problema e al contesto utente, non solo all’implementazione. Il design riguarda meno gli schermi statici e più i modelli di interazione, la fiducia e il comportamento del sistema in caso di incertezza o errore.
Ho anche visto emergere nuove responsabilità piuttosto che ruoli completamente nuovi. Ad esempio:
- Gestire il "comportamento del sistema" nei casi limite, non solo nel percorso ideale
- Definire soglie di confidenza e momenti in cui il fattore umano viene coinvolto
- Gestire la qualità dei dati e i cicli di feedback come priorità chiave del prodotto
Come i leader di prodotto dovrebbero utilizzare l’AI
Il mio consiglio è semplice: Non usate l’AI per andare più veloci. Usatela per sbagliare di meno.
Al momento, la maggior parte dei team è concentrata su velocità, più funzionalità, cicli rapidi, risultati più immediati. Questo è il beneficio più ovvio. Ma la velocità senza chiarezza non fa che moltiplicare gli errori.
Il vero cambiamento è che ormai il blocco non è più la capacità di costruire. È il giudizio.
Dunque, come leader di prodotto, il tuo ruolo diventa meno quello di guidare l’esecuzione e più quello di:
- Definire i problemi giusti
- Sequenziare le decisioni
- Assicurarsi che ciò che viene realizzato cambi davvero il comportamento degli utenti
Usa l’IA per ampliare il tuo modo di pensare, sintetizzare segnali e mettere alla prova le idee. Ma non delegare le decisioni difficili. È lì che sta il vero valore.
Inoltre, ripensa a come lavora il tuo team:
- Tratta la discovery come un processo continuo, non come una fase.
- Progetta per la fiducia, non solo per la funzionalità.
- Costruisci sistemi, non solo funzionalità.
E, soprattutto, resisti alla tentazione di saltare il pensiero più difficile.
Segui gli aggiornamenti
Puoi seguire Adam Root su LinkedIn mentre continua a costruire Sotia, VowVista e gli altri prodotti SaaS nel suo portfolio.
Presto altre interviste con esperti su The CPO Club!
