Il fondatore tecnologico ed ex VP di Prodotto afferma che l’IA sta peggiorando i team di prodotto — non migliorandoli
Scopri perché uno sviluppo prodotto più rapido non garantisce risultati migliori e come l’IA può migliorare le decisioni di prodotto solo se abbinata a workflow solidi e a una chiara convinzione.
Adam Root
Fondatore di Root Ventures
Impatto dell’IA: L’IA sta peggiorando i team di prodotto eliminando le salvaguardie contro le decisioni sbagliate.
Focus sui Sistemi: Una leadership di prodotto efficace si concentra sui sistemi piuttosto che sui modelli o sulle funzionalità di IA.
Supporto alle prove: Dare priorità a sistemi supportati da prove migliora l’esecuzione e riduce la rapida diffusione di idee scorrette.
Workflow: Workflow integrati e basati sull’IA migliorano lo sviluppo del prodotto dall’aggregazione dei dati alla validazione delle decisioni.
Preoccupazioni sulla fiducia: L’apparente accuratezza dell’IA comporta rischi; la vera responsabilità richiede la supervisione umana nelle decisioni.
Adam Root ha ricoperto ruoli come VP of Product in diverse aziende tecnologiche. Attualmente è il fondatore di Root Ventures, dove sviluppa prodotti SaaS guidati dai flussi di lavoro.
Ci siamo confrontati con Adam per comprendere come l’IA stia cambiando il ciclo di vita del prodotto — e come in realtà stia peggiorando alcuni team lungo il percorso. Ecco cosa ci ha raccontato.
L’IA sta peggiorando i team di prodotto
L’IA sta rendendo la maggior parte dei team di prodotto meno efficienti, non migliori — perché rimuove l’attrito che in passato proteggeva le squadre dalle cattive decisioni.
Vuoi di più da The CPO Club?
Iscriviti gratuitamente per completare la lettura di questo articolo:
Have an account? Log In
Negli ultimi 17+ anni, ho scalato piattaforme SaaS, guidato iniziative basate sull’IA e ottenuto risultati misurabili, come far crescere i ricavi da $20k a $400k MRR e generare impatti su scala enterprise. All’inizio della mia carriera, credevo che la parte più difficile fosse costruire, lanciare funzionalità, far crescere i team ed eseguire una roadmap. Quello che ho imparato, soprattutto negli ultimi anni, è che la vera sfida è trasformare l’ambiguità in convinzione. L’IA ha reso questa distinzione impossibile da ignorare.
Oggi chiunque può generare un prototipo o spedire velocemente usando strumenti IA, ma la maggior parte dei team ancora fatica a tradurre questi risultati in reale trazione. Vedo costantemente squadre tecniche solide che costruiscono più in fretta, ma senza una chiara tesi di prodotto. Integrano l’IA in flussi di lavoro che non erano stati progettati per avere successo. Il risultato è un incremento della produzione, ma non dell’impatto.
Questa consapevolezza ha cambiato radicalmente il mio modo di vivere la leadership di prodotto. Ora considero ogni prodotto come un sistema di verità, non solo come un insieme di funzionalità. Tutto parte da una profonda comprensione del problema, dalla sua validazione con prove concrete, e dal sequenziamento delle decisioni in modo da generare leva. Solo allora l’IA diventa davvero un moltiplicatore. Senza queste basi, accelera soltanto il rumore.
Quindi oggi, il mio focus è meno sugli strumenti e più sulla creazione di chiarezza, sull’allineare i team attorno a ciò che conta, al perché conta e a come produce risultati. Perché quando il sistema è quello giusto, l’execution si moltiplica.
Costruire un portafoglio nativo IA
Attualmente sto realizzando un piccolo portafoglio di prodotti SaaS nativi IA e guidati dal workflow in diversi settori, progettati per essere al centro del comportamento reale degli utenti, e non solo per aggiungere funzionalità sopra.
Sotia è un sistema di intelligenza costruito attorno ai dati comportamentali, a partire da Slack, che aiuta i leader a comprendere lo stato di esecuzione in tempo reale. Traduce i modelli di comunicazione in segnali su allineamento, velocità decisionale e rischio, creando di fatto un nuovo livello tra l’attività grezza e la visione strategica dei vertici.
Parallelamente, sto sviluppando VowVista, una piattaforma marketplace nel settore delle location per matrimoni che punta a risolvere la sicurezza delle decisioni per gli acquirenti della Gen Z. Affronta un acquisto frammentato e ad alto tasso emotivo attraverso trasparenza, dati strutturati e flussi di lavoro guidati per aiutare gli utenti a passare dall’esplorazione all’impegno.
Oltre a questi, proseguo nello sviluppo di piattaforme native IA per l’edilizia e le operazioni sul campo, dove raccogliamo input multimodali come voce, foto e video dal cantiere e li trasformiamo in intelligence strutturata e azionabile per operatori e dirigenti.
In tutto ciò, il filo conduttore è lo sviluppo di prodotti che funzionino come sistemi di archiviazione e sistemi di intelligenza, progettati per flussi di lavoro reali, con un modello di delivery che combina iterazione rapida e affidabilità di livello produttivo.
Perché i leader di prodotto dovrebbero concentrarsi sul sistema, non sull’IA
L’IA non è il prodotto. Il sistema che le sta intorno lo è.
La maggior parte dei team parte concentrandosi sul modello, sulla funzionalità o sulla capacità. Ma nella pratica, il modello è l’aspetto meno differenziante e spesso il più semplice da realizzare. Il vero lavoro è tutto ciò che lo circonda: i dati, l’integrazione nei processi, la UX, il modello di fiducia e il modo in cui il risultato produce una vera decisione o azione.
Se sbagli questo approccio, l’IA farà sembrare il tuo prodotto impressionante senza renderlo utile. Spedirai funzionalità che fanno bella figura nelle demo ma non vengono adottate, perché non sono integrate nel modo in cui gli utenti lavorano o prendono decisioni.
Il vero lavoro è tutto ciò che ruota attorno all’IA: i dati, l’integrazione dei workflow, la UX, il modello di fiducia e il modo in cui il risultato guida una decisione o un’azione reale. Se sbagli questo aspetto, l’IA farà sembrare il tuo prodotto impressionante senza renderlo utile.
Se invece lo fai correttamente, l’IA diventa un moltiplicatore. Trasforma input disordinati in insight strutturati, riduce l’attrito nei flussi di lavoro reali e crea leva sull’intero sistema.
Se lo avessi saputo prima, avrei evitato di investire troppo nell’“intelligenza” prima di convalidare il flusso di lavoro. In alcuni casi abbiamo realizzato capacità impressionanti che funzionavano tecnicamente, ma che non hanno cambiato il comportamento degli utenti perché non erano integrate nel modo in cui il lavoro veniva effettivamente svolto. Abbiamo dovuto tornare indietro e riprogettare tenendo conto del flusso di lavoro, non del modello.
Come i sistemi supportati da evidenze possono migliorare l’esecuzione
Ora sono passato dal costruire funzionalità al creare sistemi supportati da evidenze prima di scrivere codice — utilizzando l’IA come livello di sintesi e validazione fin dalle prime fasi del processo.
In passato, anche i team più forti passavano dalla fase di discovery alle specifiche relativamente in fretta. Quel modello non funziona più in un mondo aumentato dall’IA perché il costo di sviluppo si è abbassato moltissimo. È possibile generare e distribuire soluzioni più velocemente di quanto si possa validare se dovrebbero realmente esistere. Questo genera una nuova modalità di fallimento: i team scalano idee sbagliate a una velocità incredibile.
Ora la discovery deve diventare una funzione continua e guidata da sistema, non una fase. Questo significa:
- Aggregare segnali reali su vasta scala, compresi comportamento dell’utente, dati di supporto, win-loss e contributi qualitativi
- Usare l’IA per sintetizzare pattern tra questi input, non solo riassumerli
- Mappare esplicitamente i problemi sui flussi di lavoro e misurare se il prodotto li sta effettivamente risolvendo
- Rivalidare continuamente le ipotesi man mano che arrivano nuovi dati
Ad esempio, utilizzo prompt strutturati su più fonti di dati per mettere in luce problemi ricorrenti, mapparli sui flussi di lavoro e testare esplicitamente se il prodotto li sta realmente risolvendo. Questo processo spesso invalida le idee iniziali o le trasforma significativamente prima che arrivino al design o all’ingegneria.
Quello che è cambiato di conseguenza è la qualità della convinzione. Costruiamo meno cose, ma quelle che realizziamo sono molto più allineate a problemi reali. Cambia anche il modo in cui lavorano i team. Invece di discutere sulle opinioni, reagiamo a evidenze sintetizzate. Per me, quindi, l’IA serve meno ad accelerare l’esecuzione e più ad aumentare la precisione di ciò che scegliamo di realizzare.
Come l’IA sta condensando l’intero flusso dal segnale al rilascio
Ecco un flusso di lavoro abilitato dall’IA, end-to-end, che utilizzo per passare dal segnale grezzo dell’utente a un prodotto validato e rilasciato.
Si parte dall’aggregazione dei segnali. Raccolgo dati qualitativi e comportamentali, inclusi interviste di coppia, thread su Reddit, recensioni di location, punti di abbandono nel funnel e domande in entrata. Invece di analizzare tutto uno per uno, utilizzo l’IA per sintetizzare tutte le fonti, identificando problemi ricorrenti, quanto spesso si presentano e dove gli utenti si bloccano nel processo decisionale.
Da lì passo alla strutturazione dei problemi. L’IA aiuta a raggruppare questi segnali in enunciati di problema chiari, collegati a momenti specifici del flusso di lavoro. Metto poi alla prova questi problemi chiedendomi: “È frequente, doloroso e risolvibile dal prodotto?”
Si passa poi alla definizione delle soluzioni. Utilizzo l’IA per esplorare rapidamente diversi modi per risolvere il problema, non solo funzionalità ma anche cambiamenti nel workflow. La chiave è generare molteplici approcci in fretta e poi restringere la scelta su ciò che meglio si adatta al comportamento dell’utente.
Dopodiché si passa alla fase di sviluppo e strumentazione. Tramite strumenti di sviluppo supportati dall’IA, trasformiamo rapidamente il concetto in una versione funzionante, ma con la strumentazione integrata fin dall’inizio. Monitoriamo se gli utenti utilizzano il nuovo flusso di lavoro, dove si bloccano e se migliora la fiducia o l’avanzamento decisionale.
A quel punto, inizia il ciclo di apprendimento. L’IA analizza i pattern d’uso, i feedback qualitativi e i casi limite per identificare ciò che funziona e ciò che non funziona. Guardiamo se il cambiamento ha effettivamente modificato il comportamento, non solo se gli utenti ci hanno interagito.
Infine, il tutto confluisce in una nuova iterazione o in una rimozione. Se il flusso di lavoro migliora i risultati, lo ampliamo. Se non lo fa, lo perfezioniamo o lo togliamo rapidamente.
Claude, collegato ai miei dati di prodotto e ai segnali degli utenti, gestisce gran parte di questo workflow.
Come l’IA può generare falsa fiducia
Il miglior risultato che sto osservando con l’IA è un grande aumento nella velocità con cui si arriva alla chiarezza. L’IA ha compresso attività che una volta richiedevano giorni in poche ore, soprattutto nella discovery, sintesi e definizione iniziale del prodotto. Posso analizzare molti più input, individuare pattern più rapidamente e mettere alla prova le idee prima che il team investa risorse. Dal punto di vista qualitativo, ciò ha portato a un inquadramento iniziale migliore, meno idee deboli che finiscono nelle conversazioni sulla roadmap e un allineamento più forte tra prodotto, design e ingegneria.
Ha inoltre migliorato il throughput stesso della creazione di prodotti. Nell’ultimo anno, ho sfruttato workflow assistiti da IA per andare dal concetto al prodotto funzionante in modo molto più rapido rispetto ai cicli tradizionali. Ciò include il passaggio dall’inquadramento del problema all’architettura, PRD e software utilizzabile in una frazione del tempo abituale. Il vantaggio non è solo la velocità, ma la possibilità di testare i flussi di lavoro reali in anticipo, migliorando così la velocità di apprendimento.
Non è però tutto positivo. L’IA può generare falsa fiducia. I team possono confondere un output ben rifinito con la qualità del prodotto. Un prototipo sembra convincente, le specifiche sembrano complete e tutti hanno la sensazione che ci siano progressi, anche quando il flusso di lavoro sottostante, il modello di fiducia o il bisogno reale degli utenti non è stato ancora risolto. Ho anche visto che l’uso dell’IA, in assenza di una forte tesi di prodotto, può aumentare la confusione: genera più idee, più testi, più ticket e più artefatti di quanti un team riesca effettivamente a valutare, peggiorando di fatto la prioritizzazione.
Dove l’IA non arriva nei prodotti
È proprio nell’ambito in cui mi aspettavo miglioramenti radicali del giudizio e dell’impatto di prodotto che l’IA ha chiaramente mancato il bersaglio.
All’inizio pensavo che l’IA 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 davvero. Quello che resta difficile è sempre interpretare i compromessi, comprendere gli effetti indiretti e prendere una direzione nell’incertezza. L’IA supporta questo processo, ma non lo sostituisce. Non ho mai visto che, da sola, l’IA produca decisioni di prodotto migliori in modo costante.
Ha anche fallito nel favorire una reale adozione. Le funzionalità IA spesso si presentano benissimo nelle demo, ma questo non si traduce in uso ripetuto a meno che non siano profondamente integrate nei flussi di lavoro reali. Ho visto team rilasciare capacità IA impressionanti che gli utenti provano una volta ma a cui non tornano più, perché il prodotto non ha modificato il loro comportamento né è diventato parte integrante del modo di lavorare.
Un’altra lacuna riguarda la riduzione della complessità. Mi aspettavo che l’IA semplificasse il modo in cui vengono costruiti e gestiti i prodotti, ma spesso introduce nuovi livelli, tra cui logiche di prompt, casi limite, criticità di valutazione e considerazioni sulla fiducia. Invece di eliminare lavoro, lo sposta in nuove aree che comunque richiedono una forte disciplina di prodotto e ingegneristica.
Perché la responsabilità deve restare umana
Uso massicciamente l’IA ovunque l’importanza sia su scala e riconoscimento di pattern, e mantengo la supervisione umana ovunque contino giudizio, rischio o sensibilità.
Dal lato IA, la sfrutto soprattutto nelle fasi di discovery e sintesi. Immetto trascrizioni, ticket di supporto, dati win-loss e segnali comportamentali per identificare problemi ricorrenti, quantificare la frequenza e mappare questi problemi sui flussi di lavoro. È utile anche nelle prime fasi di prioritizzazione, non per prendere decisioni, ma per mettere alla prova le ipotesi mostrando compromessi, effetti indiretti e alternative che potrei non aver considerato. Nell’ambito della sperimentazione, l’IA aiuta a generare ipotesi, abbozzare varianti e analizzare rapidamente i risultati, soprattutto quando si gestiscono grandi volumi di feedback qualitativi.
Dal lato IA, la sfrutto soprattutto nelle fasi di discovery e sintesi. È utile anche nelle prime fasi di prioritizzazione, non per prendere decisioni, ma per mettere alla prova le ipotesi mostrando compromessi, effetti indiretti e alternative che potrei non aver considerato.
Dove invece lascio esplicitamente la gestione agli esseri umani è nella convinzione e nell’impegno. Le decisioni finali di prioritizzazione, la sequenza nella roadmap e ciò che decidiamo di non costruire restano a carico della leadership e mia. Lo stesso vale per le decisioni di UX che richiedono sensibilità, fiducia e contesto emotivo. Anche i compromessi tecnici sono guidati da persone, perché implicano riflessione di sistema a lungo termine, tolleranza al rischio e vincoli organizzativi che l’IA non può cogliere completamente.
Il motivo è semplice: l’IA è 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 costose nell’incertezza. Questa responsabilità deve restare umana.
Perché i leader di prodotto devono stare attenti alla falsa fiducia su larga scala
I leader di prodotto spesso sottostimano il rischio della falsa fiducia su larga scala.
I sistemi IA sono molto bravi a produrre output che danno l’impressione di essere corretti, anche quando non lo sono. Il pericolo non è l’errore evidente. È l’accuratezza plausibile. Qualcosa che sembra giusto, suona sicuro, ma è sbagliato in modi che non sono immediatamente rilevabili.
Su piccola scala, un utente potrebbe accorgersene. A livello di prodotto, lo stesso errore si ripete migliaia di volte, influenzando silenziosamente decisioni, flussi e risultati.
L’ho visto comparire in ambiti come l’interpretazione dei documenti, le raccomandazioni e l’automazione dei processi. Il sistema funziona abbastanza bene la maggior parte delle volte, tanto che gli utenti iniziano a farci affidamento, ma i casi limite sono dove si nasconde il vero rischio. E spesso sono proprio questi casi limite a comportare le conseguenze più gravi.
Ciò che rende questo particolarmente pericoloso è che le normali intuizioni di prodotto non lo rilevano. Non si nota un calo o un blocco. Si nota coinvolgimento. Il prodotto “funziona”. Finché non funziona più.
La soluzione non sono solo modelli migliori. Si tratta di progettare pensando a fiducia e verifica:
- Mostrare le prove, non solo le risposte
- Evidenziare sicurezza e incertezza
- Creare checkpoint chiari con l’intervento umano
- Analizzare quando il sistema sbaglia, non solo quando viene utilizzato
Il rischio è dare per scontato che l’accuratezza cresca linearmente con l’utilizzo. In realtà, il rischio si accumula più rapidamente dell’accuratezza.
Come il giudizio dell’AI può diventare debole
L’AI fa più fatica quando il prodotto deve comprendere quanto contano le decisioni umane, l’ambiguità e il costo dell’errore – non solo generare una risposta plausibile.
Un buon esempio sono i flussi di lavoro orientati alla conformità o che richiedono elevata affidabilità. Ho lavorato su concept di prodotto dove l’AI estrae informazioni da documenti, segnala problemi e suggerisce i prossimi passi. Sulla carta sembra un caso d’uso perfetto per l’AI. In pratica, la difficoltà sta nel fatto che il modello può produrre una risposta con apparente sicurezza pur mancando di contesto, leggendo male una clausola o non comprendendo perché un’eccezione conta più di un’altra.
Questo crea subito un problema di fiducia. L’utente non si chiede: “Questo risultato è impressionante?”. Si chiede: “Posso fidarmi senza correre rischi successivi?”
Quello che ho imparato è che spesso l’AI mostra carenze di giudizio quando:
- Il contesto è parziale
- Le conseguenze degli errori sono asimmetriche
- L’utente ha bisogno di una spiegazione, non solo del risultato
Come l’AI sta ristrutturando i team
L’AI ha cambiato la composizione dei miei team di prodotto, passando da silos basati sui ruoli a team più piccoli, integrati e orientati al sistema.
In passato, i team erano organizzati secondo passaggi ben definiti: il prodotto definisce, il design crea, l’ingegneria realizza e il data analyst esamina. Questo modello non regge più quando l’AI accelera l’esecuzione e introduce sistemi probabilistici che richiedono cicli di feedback molto stretti.
Ora tendo a preferire meno persone che sappiano muoversi tra i confini. I product manager si aspettano di approfondire dati, progettazione dei prompt e logica dei flussi. Gli ingegneri sono più vicini ai problemi e al contesto utente, non solo all’implementazione. Il design si occupa meno di schermi statici e più di flussi di interazione, fiducia e di come il sistema si comporta quando è incerto o sbaglia.
Ho anche osservato la nascita di nuove responsabilità, più che di nuovi ruoli veri e propri. Ad esempio:
- Farsi carico del “comportamento del sistema” nei casi limite, non solo nella situazione ideale
- Definire soglie di fiducia e momenti di intervento umano
- Gestire la qualità dei dati e i cicli di feedback come aspetti fondamentali del prodotto
Come i responsabili di prodotto dovrebbero usare l’AI
Il mio consiglio è semplice: non usate l’AI per andare più veloci. Usatela per sbagliare di meno.
In questo momento, la maggior parte dei team è focalizzata sulla velocità, su più funzionalità, cicli più rapidi e risultati più veloci. È il vantaggio più ovvio. Ma la velocità senza chiarezza amplifica solo gli errori.
Il vero cambiamento è questo: costruire non è più il vincolo. Lo è il giudizio.
Quindi, come responsabile di prodotto, il tuo ruolo è meno guidare l’esecuzione e più:
- Definire i problemi giusti
- Sequenziare le decisioni
- Assicurarsi che ciò che viene realizzato cambi davvero il comportamento degli utenti
Usa l'IA per espandere il tuo pensiero, sintetizzare i 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:
- Considera la fase di discovery come continua, non come una fase a sé stante.
- Progetta per la fiducia, non solo per la funzionalità.
- Costruisci sistemi, non solo funzionalità.
E, cosa più importante, resisti alla tentazione di saltare la riflessione più complessa.
Segui gli aggiornamenti
Puoi seguire Adam Root su LinkedIn mentre continua a sviluppare Sotia, VowVista e gli altri prodotti SaaS del suo portafoglio.
Altre interviste ad esperti in arrivo su The CPO Club!
