Il leader della delivery di Google spiega come i flussi di lavoro agentici cambiano i modelli di gestione prodotto
Anshumani Ruddra spiega come i flussi di lavoro agentici aiutino i team di delivery a costruire più velocemente, rendendo però il giudizio umano, la validazione e la presa di decisioni ancora più importanti.
Anshumani Ruddra
Responsabile di prodotto presso Google
Spostamento Agentico: I flussi di lavoro agentici sostituiscono le consegne lineari con una delivery parallela e interfunzionale, ancorata a codice e documentazione condivisi.
Giudizio Umano: L'IA si occupa di coordinamento e stesura, mentre i leader mantengono la responsabilità per qualità, creatività, prioritizzazione e fiducia.
Avvia l'Audit: I team dovrebbero auditare le attività settimanali che fanno perdere tempo prima di scegliere gli strumenti, evitando adozioni generiche e stack appariscenti ma inefficaci.
I Rituali Contano: Una delivery più veloce abilitata dall'IA richiede comunque uno scopo chiaro, allineamento degli stakeholder, validazione rigorosa e checklist disciplinate per mantenere alta la qualità del prodotto.
Modello di Leadership: Un'adozione efficace dell'IA unisce leader che cambiano i propri flussi di lavoro a team che sperimentano e condividono i miglioramenti in tutta l'organizzazione.
Anshumani Ruddra è un leader di prodotto in Google, dove si occupa di consegna nei prodotti di pagamento. È anche un educatore e ha ricoperto ruoli dirigenziali nei team di delivery.
Ci siamo seduti insieme ad Anshumani per scoprire come l’IA sta cambiando la delivery in aziende come Google. Ecco cosa ci ha raccontato.
Costruire prodotti in Google
Sono Anshumani Ruddra. Ho passato più di 22 anni a costruire prodotti per i consumatori al crocevia tra tecnologia, narrazione, cultura pop e comportamento umano — iniziando come autore di libri per bambini, poi come game designer su successi social globali come Mafia Wars e Café World, fino a scalare Hotstar per renderla una delle più grandi piattaforme di streaming al mondo durante gli anni dell’IPL.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Negli ultimi cinque anni in Google, ho guidato la gestione del prodotto dell’app GPay, di enorme successo in India, gestito tutta l’offerta di prodotti di pagamento Google per l’APAC e sviluppato prodotti AI rivolti al consumatore. Attualmente, guido uno sforzo di sviluppo prodotto AI end-to-end per costruire un prodotto completamente nuovo.
Inoltre, insegno a leader di prodotto e dirigenti come creare con l’IA attraverso il mio corso Maven, Level Up to Product Super IC. Ricopro due ruoli contemporaneamente: operatore e insegnante — ed entrambi plasmano il mio approccio alla delivery di prodotto: meno coordinamento e approvazioni, più passaggi dall’intuizione al prototipo funzionante senza aspettare permessi.
Come l’IA permette alle persone di fare di più ciò in cui sono eccellenti
Cerco di non considerare l’IA semplicemente come un altro strumento migliore. Questo modo di vedere le cose ti fa pensare solo all’efficienza. L’IA è un moltiplicatore — forse unico in un secolo.
Mi permette di trascorrere molto meno tempo sul tessuto connettivo della delivery: sintesi delle riunioni, stesura dei PRD, aggiornamenti di stato e comunicazioni agli stakeholder, e ricerca preliminare. Ho spostato molto di questo in un mio "agentic OS" personale, lasciando che si autogestisca per la maggior parte.
Così ora passo il mio tempo su quel 10% che è difficile e profondamente umano, non sul 90% di coordinamento che prima divorava la settimana. Mi concentro di più sulla vera arte: pensiero, valutazioni, prototipazione.
Parlando di prototipazione, quello è un cambiamento enorme di per sé. Ora posso validare una visione costruendo un prototipo funzionante da solo prima di assegnarlo a qualcun altro. La barriera alla costruzione è sparita. Se mi viene un’idea, posso crearne una prima versione funzionante.
Quando usare l’IA e quando invece serve una persona
Il lavoro più automatizzabile è quello di sintesi e amministrazione:
- Trasformare l’audio grezzo delle riunioni in decisioni e azioni
- Generare le prime bozze di PRD e ricerche
- Triaggiare i segnali in entrata
- Gestire gli aggiornamenti agli stakeholder
Questo si realizza tramite agenti personali che monitorano i tuoi input, segnalano ciò che richiede una decisione e redigono il resto.
L’intelligenza sul cliente è ancora poco utilizzata qui: ora esistono strumenti che ti dicono quali funzionalità sviluppare e stimano l’impatto sull’ARR, eppure la maggior parte dei team aggrega ancora a mano i feedback da Slack e dai ticket di supporto.
Tuttavia, le persone devono ancora definire cosa significa “buono”. Da leader, definire la qualità è il tuo compito. È per questo che penso che le valutazioni siano così importanti.
Le persone devono anche occuparsi del gusto e del giudizio sul prodotto, delle vere svolte creative da zero a uno, e del lavoro umano ad alta fiducia: guidare i team, navigare la politica, e prendere le decisioni difficili di priorità.
L’IA ti offre più tentativi al bersaglio; ma è una persona a decidere dove posizionare il bersaglio.
Perché le tech stack dovrebbero iniziare da un audit
Gli strumenti di IA sono proprio come un grande videogioco — facili da usare, incredibilmente difficili da padroneggiare. La prima esperienza, che colpisce molto, fa pensare che tutto sia semplice, così le persone restano scioccate quando la complessità aumenta. Molti si scoraggiano. La vera abilità non sta nel prompting; sta nella determinazione a insistere e imparare al proprio ritmo, più velocemente di quanto sia confortevole.
Al lavoro, il mio stack è principalmente costituito dagli ultimi modelli Gemini, con Antigravity come hub di agenti. L’agente manager di Antigravity è sottovalutato. È davvero innovativo. Quanto alla gestione dei progetti, Google utilizza i propri strumenti personalizzati, equivalenti a Jira e GitHub nel resto del mondo.
Per i miei progetti personali e per le attività didattiche, il mio stack principale è:
- Claude Code per la programmazione. Questo è il fiore all'occhiello. Gestisco più agenti in parallelo. È la cosa più vicina a un vero assistente, non solo completamento automatico.
- Replit per la prototipazione. Il suo approccio pianificato e gli agenti paralleli lo distinguono.
- NotebookLM insieme a Obsidian per ricerca e scrittura.
- Codex e Claude Cowork gestiscono molti compiti programmati e automazioni, integrando email, calendario, cloud drive e note delle riunioni.
- Granola e Wispr Flow completano lo stack. Raccomando vivamente il riconoscimento vocale e l'utilizzo della voce come input.
Negli ultimi 6–12 mesi, lo stack si è evoluto da "uso l'AI per scrivere più velocemente" a un vero e proprio sistema operativo personale agentico — meno domande estemporanee e più agenti stabili che gestiscono flussi di lavoro ricorrenti dalla A alla Z.
Il mio consiglio per costruire uno stack: non iniziare dallo strumento più appariscente. Analizza come trascorri la settimana, individua le più grandi perdite di tempo e scegli lo strumento specifico che le elimina. Le strategie generiche non funzionano.
Come i workflow agentici semplificano la consegna dei progetti
Abbiamo scelto deliberatamente di concentrarci prima sulle fondamenta condivise che rendono possibili questi workflow, perché tutto lì tiene insieme o cade a pezzi.
La quasi totalità dei nostri processi ora funziona come workflow agentici, che riguardano design, gestione prodotto ed esecuzione ingegneristica. I workflow agentici gestiscono la strategia e la pianificazione di ciò che va realizzato, la progettazione dei componenti, delle schermate e dei layout, e il modo in cui backend e frontend si integrano. Non si tratta di un esperimento isolato, ma di come il lavoro avviene a ciclo completo.
Abbiamo scelto deliberatamente di concentrarci prima sulle fondamenta condivise che rendono possibili questi workflow, perché lì tutto tiene insieme o cade a pezzi. Concretamente, ciò significa costruire infrastrutture comuni per tutto il team, un insieme condiviso di competenze per gli agenti e una piattaforma di lavoro unica per tutti. L’aspetto più importante è la documentazione non solo pronta per le persone, ma pronta anche per gli agenti. Se la tua documentazione è comprensibile solo agli umani, gli agenti si perderanno, quindi investiamo molto nello scrivere per entrambi i tipi di destinatari.
Concretamente, questo si traduce in file di conoscenza chiaramente contrassegnati, PRD e documenti di progettazione tecnica. Di solito manteniamo questi file in Markdown, molto sintetici, e li scriviamo in modo che abbiano senso sia per le persone sia per gli agenti. Fondamentale: tutte queste informazioni vengono validate da persone prima di avviare la fase di sviluppo. La validazione umana degli input mantiene il workflow agentico in ordine, perché gli agenti sono validi solo quanto i documenti e le competenze a cui li indirizzi.
Manteniamo anche checklist molto chiare e ci assicuriamo che gli agenti le seguano passo passo. Un agente segna una fase come completata solo se la checklist è realmente soddisfatta; solo allora si passa alla fase successiva. Questa disciplina di documentazione trasparente, input validati da persone, competenze condivise e checklist dettagliate trasforma il lavoro agentico da semplice curiosità a qualcosa di realmente affidabile.
Il vero ritorno si manifesta quando le fondamenta sono solide. La parte più difficile è l'investimento iniziale nell'infrastruttura condivisa e nella documentazione pronta per gli agenti. I team che saltano questo passaggio ottengono una demo d’effetto e poi vedono tutto sfasciarsi con l’aumentare della complessità. Chi investe invece ottiene esecuzione realmente veloce, parallela fra design, prodotto e sviluppo.
Come l'AI cambia i modelli tradizionali di project management
Il vecchio modello a cascata semplicemente non funziona più. Il project management tradizionale era rigidamente lineare: il primo step portava al secondo, poi al terzo, con passaggi di consegne rigidi tra le discipline. Il product scriveva lo spec, il design creava i mockup, l’ingegneria costruiva e poi il design revisionava la parte estetica — ogni fase aspettava la chiusura della precedente.
Questa catena lineare si è spezzata, e questa è un'ottima cosa. I passaggi ora sono intercambiabili e i confini tra design, sviluppo e prodotto si sono attenuati. Ad esempio, i designer hanno già integrato il sistema di design direttamente nella codebase — i componenti corretti, i layout giusti e i token colore specifici. Gli sviluppatori possono allora implementare l’intero flusso funzionale, mentre il design corregge tutte le questioni di UI direttamente nel codice per rifinire il risultato. Nessuno aspetta più il passaggio di consegne su Figma. Il design ora lavora nello stesso ambiente dello sviluppo.
Lo stesso effetto sfumatura avviene a monte. Il prodotto può redigere molti più PRD in parallelo, sbloccando l’ingegneria. L’ingegneria può generare documenti di progettazione ingegneristica approfonditi e dettagliati senza che il prodotto debba supervisionare ogni singolo passaggio, perché l’IA consente a ciascuna disciplina di produrre lavori che prima richiedevano uno specialista.
Ora i diversi membri del team possono occuparsi di parti differenti del lavoro. Quindi, invece di una staffetta lineare in cui i testimoni vengono spesso persi nei passaggi di consegna, emerge un team piccolo e proattivo dove ciascuno può muoversi in territori adiacenti per sbloccare attività.
Nella pratica, questo significa sistemi leggeri rispetto a processi pesanti: meno meeting di aggiornamento e meno passaggi di approvazione, più prototipi funzionanti. PRD e documenti di progettazione ingegneristica vengono generati rapidamente e trattati come artefatti vivi, invece di specifiche congelate. Una codebase condivisa — con il sistema di design integrato — diventa la singola fonte di verità in cui prodotto, design e ingegneria si incontrano.
Il risultato è la velocità: i team validano la visione realizzando, non coordinando, e rilasciano qualità che prima richiedeva più cicli di passaggi in una frazione del tempo.
Perché l’IA non può eliminare la necessità dei rituali di progetto
Tutti i rituali consueti esistono ancora, e diversi diventano addirittura più importanti con l’IA, non meno. Si cade nell’errore di pensare che costruire più velocemente significhi meno disciplina. È vero il contrario.
Definire l’ambito è fondamentale come sempre. Un team ha ancora bisogno di una definizione chiarissima di ciò che sta cercando di costruire. Ciò che cambia sono le possibilità dentro quell’ambito. Se un team costruisce efficacemente con l’IA, molte cose che prima erano a bassa priorità o bloccate in backlog possono ora essere prioritarie e consegnate. Quindi puoi costruire un prodotto più completo e significativo rispetto al passato. L’ambizione dell’ambito può crescere, ma la necessità di definirlo chiaramente resta.
I team necessitano ancora di pieno allineamento. Gli stakeholder richiedono ancora allineamento. Quando si lavora su più team, bisogna comunque allinearsi deliberatamente sia all’interno del proprio gruppo che tra diversi gruppi. L’IA non allinea le persone per te.
La validazione del lavoro diventa ancora più importante. Quando costruisci in una grande azienda, i tuoi prodotti raggiungono milioni di persone, non solo decine o centinaia di utenti. I prodotti devono comunque essere eccellenti, funzionare molto bene e avere prestazioni adatte a quella scala. Il fatto che l’IA ti aiuti a costruire più velocemente non abbassa il livello richiesto. Quindi la validazione rimane non negoziabile.
Ciò che cambia è che il processo non è più così difficile e lento. Gli stessi rituali — chiarezza dell’ambito, vero allineamento, validazione rigorosa — restano invariati e guadagnano ancora più importanza. Bisogna ripensare ai processi che hanno storicamente ostacolato una maggiore rapidità di esecuzione. L’IA consente di snellire la cerimonia e l’attrito intorno a questi rituali, proteggendone però la sostanza.
Perché il giudizio sarà ancora più importante nelle organizzazioni guidate dall’IA
Nel breve termine, sempre più aziende tecnologiche adotteranno l’IA nello sviluppo e nella consegna del prodotto end-to-end. La previsione più audace, tuttavia, è dove si espanderà dopo. Non resterà confinata al settore tecnologico. Si diffonderà alle grandi aziende, poi alle società non tecnologiche e infine alle imprese tradizionali.
Quando questi vantaggi si sposteranno dai singoli alle piccole squadre e poi alle organizzazioni intere, l’effetto dinamico trasformerà radicalmente team e flussi di lavoro. La struttura con cui vengono costruiti i team di delivery e il loro modo interno di operare appariranno molto diversi rispetto a oggi.
Ma l’importanza di prendere buone decisioni non sparirà; anzi, crescerà perché ora bisogna prendere decisioni molto più frequentemente. Quando la delivery complessiva era lenta, prendevi poche decisioni chiave, forse una ogni qualche settimana o mese. Ora serve prendere decisioni di qualità più volte al giorno, a volte anche più volte in un’ora.
Lo sviluppo guidato dall’IA deve essere adottato sia dall’alto verso il basso che dal basso verso l’alto.
Pertanto, l’attenzione deve spostarsi sulla presa di decisione umana. Ogni area di competenza dovrà definire un chiaro insieme di criteri attraverso cui valutare ogni decisione, per permettere scelte più rapide e nette. Altrettanto importante, le decisioni dovranno essere registrate così che gli agenti possano comprenderle e farvi riferimento in seguito.
Le squadre vincenti tratteranno il giudizio umano di alta qualità e ben documentato come una risorsa scarsa, perché l'IA lo rende sia più frequente che più prezioso.
Perché i responsabili della delivery devono adottare l’IA e incoraggiare la sperimentazione
Il punto fondamentale è che lo sviluppo guidato dall’IA deve essere adottato sia dall’alto verso il basso che dal basso verso l’alto. Non può essere solo uno o l'altro.
La parte dall’alto verso il basso richiede il coinvolgimento della leadership. Se la leadership senior non si impegna, non sperimenta e non cerca di cambiare i propri flussi di lavoro e sistemi di delivery, l’organizzazione farà molta fatica ad adottare l’IA in modo efficace. Non si può imporre una trasformazione che non si sta vivendo in prima persona. I leader che delegano l’IA a un gruppo di lavoro mantenendo intatti i propri metodi di lavoro mandano un segnale chiaro che questa è un’opzione, e l’organizzazione interpreta correttamente quel segnale. Quindi, il mio primo consiglio ai colleghi responsabili della delivery è di cambiare prima i vostri processi di lavoro, prima di chiedere agli altri di cambiare i loro.
La parte dal basso verso l’alto è altrettanto importante. I dipendenti junior e i singoli team devono avere la libertà di sperimentare, mettere in discussione le convenzioni e i flussi di lavoro esistenti. Devono avere spazio per provare nuove cose, interrogarsi su come sono sempre state fatte le consegne e poi portare ciò che imparano all’attenzione della leadership. Se questo canale non esiste, se le persone non hanno quella libertà e le loro scoperte non arrivano mai ai livelli superiori, tutto si sgretola così come accadrebbe in assenza della leadership.
La cosa più utile che un responsabile della delivery può fare adesso è tenere assieme entrambi gli estremi. Guidare dal fronte, ripensando in modo visibile i propri sistemi di delivery, e allo stesso tempo creare le condizioni perché i team possano sperimentare liberamente e riportare ciò che funziona. Deve essere sia dall’alto verso il basso che dal basso verso l’alto.
Quando si coinvolge solo una parte, l’adozione si blocca. Quando entrambe sono attive, il cambiamento si consolida.
Segui l’autore
Puoi seguire il lavoro di Anshumani Ruddra su LinkedIn. Puoi anche consultare il suo blog e i suoi corsi.
Presto arriveranno altre interviste ad esperti su The Digital Project Manager!
