Il vicepresidente del prodotto di Amex afferma che l’IA deve essere integrata gradualmente nelle organizzazioni di prodotto — saltare anche un solo livello ti costerà caro

Abishek (Abhi) Gandotra ha iniziato la sua carriera come ingegnere, ma è passato al prodotto, portando con sé le sue competenze tecniche. Attualmente è VP del prodotto presso American Express. È anche l'autore di L'agente sovrano.

Si è unito a noi per condividere ciò che sta imparando mentre l'AI rende ancora più labili i confini tra ingegneria e prodotto. Ecco cosa ci ha raccontato.

Dall'ingegneria al prodotto

Sono Abhi Gandotra e guido l'organizzazione di prodotto della piattaforma bancaria presso American Express. Ho iniziato come ingegnere, trascorrendo il primo decennio della mia carriera a scrivere codice. Di conseguenza, non ho mai considerato la tecnologia una scatola nera. Quando qualcosa non viene rilasciato, voglio sapere perché, al livello in cui si verifica il problema.

Sono passato al prodotto perché mi interessava meno costruire le cose nel modo giusto e più costruire le cose giuste. In Green Dot, ho trascorso oltre un decennio a costruire una piattaforma bancaria come servizio: l'abbiamo portata dall'idea a oltre 1 miliardo di dollari di ricavi B2B attraverso più di 80 partner aziendali. Questo mi ha insegnato ciò in cui credo ancora oggi: le piattaforme vincono quando rendono semplici i problemi difficili degli altri. Ora, in Amex, faccio lo stesso per le infrastrutture bancarie e dei pagamenti, su una scala diversa e con i relativi requisiti normativi.

Per me, il momento dell'AI non è solo clamore. Sto distribuendo prodotti con questi strumenti proprio ora: costruisco agenti, avvio un programma di formazione sull'AI in tutta la mia organizzazione e gestisco piccoli gruppi che passano dall'idea al software funzionante in pochi giorni. Il mio istinto da ingegnere è tornato completamente in gioco. Il divario tra "ho un'idea" e "è in esecuzione" non è mai stato così breve. È questo che trovo entusiasmante: non il clamore, ma la velocità.

Guidare il prodotto dall'interno del livello infrastrutturale

Come ho detto, guido l'organizzazione di prodotto della piattaforma bancaria presso American Express: la piattaforma di banca digitale e pagamenti che sostiene le nostre esperienze bancarie per consumatori e aziende. È il livello infrastrutturale: i circuiti, le funzionalità per la gestione dei conti e dei trasferimenti di denaro e i controlli che supportano tutti gli elementi rivolti ai clienti.

I nostri "utenti" comprendono due pubblici distinti: i clienti finali, che vivono il prodotto come il loro servizio bancario e di pagamento, e i team interni di prodotto e ingegneria, che costruiscono sulla nostra piattaforma. Il lavoro sulle piattaforme richiede di servire contemporaneamente chi costruisce e gli utenti finali: se ottimizzi solo per uno dei due, l'altro ne risente.

Operiamo alla scala e con i requisiti normativi attesi da un'istituzione finanziaria con oltre cento anni di storia, il che significa che affidabilità e conformità non sono funzionalità, ma requisiti essenziali. Il nostro modello di distribuzione combina prodotto e ingegneria interni con partner tecnologici strategici, quindi svolgo in gran parte un ruolo di coordinamento: allineo i piani interni con le capacità esterne e con i controlli richiesti dai nostri team di gestione del rischio e conformità.

Come l'AI sposta la prototipazione dall'ingegneria al prodotto

Il cambiamento più importante che ho apportato è stato smettere di considerare la prototipazione una richiesta all'ingegneria e trasformarla in una capacità del prodotto.

Un anno fa, validare una nuova idea significava scrivere un documento, aggiungerla a un arretrato di attività e aspettare settimane affinché l'ingegneria avesse la capacità di costruire qualcosa che utenti o partner potessero valutare. Ora gestisco piccoli gruppi che passano dal concetto al software funzionante in pochi giorni, utilizzando strumenti di programmazione basati sull'AI per realizzare un prototipo funzionale basato su un SDK reale, non un modello dimostrativo cliccabile. In una recente iniziativa, per un'integrazione delle buste paga, un piccolo team ha costruito e testato un'integrazione funzionante nel tempo che prima sarebbe servito solo per allinearsi sui requisiti.

Questo ha cambiato il modo in cui prendiamo le decisioni. Quando puoi mettere un software funzionante davanti a un partner o a una parte interessata in pochi giorni, la conversazione smette di essere astratta: discuti di qualcosa di reale, con limiti reali, invece di discutere su una presentazione. Questo ha eliminato gran parte della paralisi da analisi che in passato consumava la fase iniziale della nostra pianificazione. E con i responsabili di prodotto del mio team che definiscono l'ambito e realizzano autonomamente i prototipi, il tempo dell'ingegneria viene dedicato a ciò che ne ha davvero bisogno.

Ora la parte difficile non è costruire. È decidere cosa vale la pena costruire. Il senso della qualità e la definizione delle priorità sono le risorse scarse. È questo il cambiamento su cui mi concentro maggiormente come leader.

Un flusso di lavoro reale dall'idea al prototipo

Ecco il nostro flusso di lavoro generalizzato, dall'idea al prototipo funzionante, compresso da settimane a giorni.

1. Definire il problema: Inizia tutto dalle persone — un'esigenza di un partner o una lacuna che abbiamo individuato. Uso un assistente IA come interlocutore per mettere alla prova l'impostazione: a chi è destinata, qual è l'effettiva attività da svolgere e cosa farebbe sì che non valesse la pena svilupparla? Questo rende la domanda più precisa prima di iniziare lo sviluppo.
2. Sintetizzare gli input: Indirizziamo l'IA verso il materiale rilevante — ricerche, temi emersi dall'assistenza, panorama competitivo, contesto interno precedente — e otteniamo una visione sintetizzata in pochi minuti invece che in giorni. Una persona la esamina per individuare ciò che il modello ha trascurato o a cui ha attribuito un peso eccessivo; la sintesi è un punto di partenza, non il verdetto.
3. Creare un prototipo funzionante: È il cambiamento più significativo. Invece di scrivere una specifica e aspettare la disponibilità del team di sviluppo, un piccolo gruppo utilizza strumenti di programmazione basati sull'IA per realizzare software funzionante con un'interfaccia reale — non un modello dimostrativo cliccabile, ma qualcosa che funziona davvero. Giorni, non settimane.
4. Presentarlo alle persone: Presentiamo presto il prototipo funzionante agli stakeholder o a un partner. Poiché è reale, il feedback è autentico — discutiamo del comportamento e dei casi limite, invece di reagire a una presentazione.
5. Decidere con criterio: Qui l'IA fa un passo indietro. Che si decida di investire ulteriormente, come integrarlo nella roadmap e quali siano le implicazioni in termini di controlli e conformità — sono decisioni umane, con una chiara responsabilità definita per progettazione.

Perché l'ambito di responsabilità dei PM deve cambiare

Per questo motivo, ho ridefinito attivamente l'ambito di responsabilità dei PM, i punti di passaggio tra prodotto e sviluppo e — cosa fondamentale — il livello qualitativo richiesto per gli artefatti creati dai PM e destinati alla produzione.

Nel momento in cui un PM può portare in produzione una soluzione dall'inizio alla fine, è necessario rispondere a nuove domande che il vecchio modello non ci obbligava mai a porci. Di cosa è ora responsabile un PM, rispetto a prima? In quali punti il giudizio del team di sviluppo deve ancora fungere da filtro per il lavoro e in quali, invece, ne rallenta semplicemente l'avanzamento? Cosa significa "pronto per la produzione" quando la persona che lo ha realizzato non è uno sviluppatore?

Mi concentro sulla coerenza, non sull'accelerare lo sviluppo fine a sé stesso. Dare a tutti la possibilità di costruire rischia di portare ciascuno a creare la propria versione di ogni cosa, frammentando l'organizzazione in silos competenti ma incapaci di rafforzarsi a vicenda. Perciò la riprogettazione riguarda tanto le basi condivise e uno standard qualitativo comune quanto il dare più autonomia ai PM. Se fatto bene, i team si muovono molto più rapidamente e costruiscono gli uni sugli altri, invece di lavorare separatamente.

Perché l'IA dovrebbe generare opzioni mentre le persone applicano il proprio giudizio

L'IA eccelle nel generare opzioni; le persone devono continuare ad assumersi la responsabilità del giudizio, soprattutto nel settore bancario regolamentato.

Mi affido all'IA per:

• Esplorazione e sintesi: estrarre gli elementi rilevanti da ricerche, ticket di assistenza, feedback dei partner e panorama competitivo molto più rapidamente di quanto una persona possa leggere tutto il materiale.
• Prototipazione e sperimentazione: realizzare software funzionante per testare un'idea invece di discuterne soltanto.
• La prima bozza di quasi tutto: requisiti, analisi e scansioni del mercato.

L'IA ci porta a un punto di partenza credibile — qualcosa che in passato occupava gran parte del nostro tempo — in pochi minuti.

Mantengo esplicitamente sotto responsabilità umana:

• La definizione delle priorità e le decisioni sulla roadmap: l'IA può presentare i compromessi, ma decidere cosa sviluppare — e cosa scegliere deliberatamente di non sviluppare — richiede un giudizio sulla strategia, sulla propensione al rischio e sui nostri clienti che non sono disposto a delegare.
• Qualsiasi aspetto che riguardi decisioni normative o di rischio: nel nostro mondo, "lo ha suggerito il modello" non è una risposta che si può dare a un'autorità di regolamentazione.
• Le decisioni difficili sulle persone e sugli stakeholder: con questo intendo saper leggere la situazione e gestire priorità contrastanti tra i partner. Sono aspetti irriducibilmente umani.

Come l'IA porta sia velocità sia eccessiva sicurezza

Le riflessioni di Abhi

La lezione è stata che l’IA riduce così drasticamente il costo del primo 80% che i team sottovalutano il restante 20%, ovvero la parte in cui risiedono tutte le difficoltà del settore bancario. Ora separiamo esplicitamente “sembra completato” da “è completato,” e ho stabilito come norma che una demo funzionante sia l’inizio della conversazione difficile, non la sua conclusione.

Il vantaggio più evidente è la velocità nella fase iniziale del ciclo di vita:

• I cicli di prototipazione che prima richiedevano settimane ora richiedono giorni, il che significa che testiamo più idee ed eliminiamo prima quelle sbagliate — prima che consumino reale capacità ingegneristica.
• Ora i miei PM riescono a completare ricerche, analisi dei feedback dell'assistenza e analisi della concorrenza in una frazione del tempo, arrivando così alle conversazioni sulle priorità meglio preparati.
• I PM che prima non potevano realizzare nulla senza un ingegnere ora possono creare autonomamente un prototipo funzionante. Questo cambia l'energia del team. Le persone si sentono di nuovo più simili a creatori.

Ma abbiamo imparato a nostre spese che l'output dell'IA è sicuro di sé anche quando è sbagliato, e questo è pericoloso in un ambiente regolamentato. All'inizio, un prototipo sembrava abbastanza rifinito da creare una falsa sicurezza su quanto fossimo vicini a qualcosa di reale. La demo funzionava, ma il difficile 20% — i casi limite, i controlli, la logica di conformità — era completamente ignorato.

La lezione è stata che l'IA riduce così drasticamente il costo del primo 80% che i team sottovalutano il restante 20%, ovvero la parte in cui risiedono tutte le difficoltà del settore bancario. Ora separiamo esplicitamente "sembra completato" da "è completato," e ho stabilito come norma che una demo funzionante sia l'inizio della conversazione difficile, non la sua conclusione.

Il divario tra demo e valore del prodotto

C'è un grande divario tra la magia della demo e il valore duraturo del prodotto. L'IA eccelle nell'impressionante passaggio da zero a uno, ma delude sistematicamente nel lavoro poco appariscente che determina un impatto duraturo.

Alcuni esempi specifici:

• Il "miglio finale" nei flussi di lavoro regolamentati: L'IA fornisce rapidamente un prototipo funzionante, ma nel settore bancario il valore non risiede nel percorso ideale — risiede nei controlli, nelle tracce di audit, nella gestione delle eccezioni e nella logica di riconciliazione. L'IA non ha accelerato in modo significativo questa parte. Mi aspettavo che comprimessse l'intero processo di sviluppo; ha compresso solo la metà iniziale. La metà finale rimane difficile come sempre, ed è lì che risiede la maggior parte del valore reale del prodotto.
• L'integrazione con la realtà dei sistemi legacy: Gran parte del valore di una piattaforma deriva dalla qualità dell'integrazione con i sistemi esistenti: API dei partner, elaboratori principali, servizi interni vecchi di decenni. Gli strumenti di IA eccellono negli ambienti realizzati da zero, ma si indeboliscono notevolmente nel momento in cui incontrano i nostri vincoli reali. Il complesso lavoro di integrazione, ricco di contesto, che definisce l'ingegneria delle piattaforme nel mondo reale è esattamente il settore in cui aiutano meno.
• La qualità delle decisioni a livello strategico: Speravo che la sintesi dell'IA rendesse più precise le nostre priorità. Ci ha reso più veloci e meglio informati, ma non ha reso più semplici le decisioni difficili, perché le decisioni difficili non sono mai dipese dalla mancanza di informazioni; riguardavano convinzione, compromessi e propensione al rischio. L'IA ci ha fornito più analisi; non ci ha fornito maggiore chiarezza. È stato utile correggere questa aspettativa.

Perché l'integrazione dell'IA dovrebbe essere un percorso graduale

Non si possono saltare i livelli inferiori. L'istinto con l'IA — soprattutto con i modelli capaci di oggi — è puntare direttamente allo stato finale più impressionante: il sistema autonomo, l'agente che agisce da solo. Ho imparato che bisogna arrivarci per gradi. Cercare scorciatoie ha un costo.

Ora lo considero un percorso di maturità. La capacità dell'IA in qualsiasi contesto operativo serio attraversa diverse fasi: prima la produttività (rendere più veloce il lavoro esistente), poi l'efficienza (automatizzare i passaggi di routine), quindi l'intelligenza (approfondire le conoscenze e supportare le decisioni) e solo dopo l'autonomia (sistemi che agiscono autonomamente). Ogni livello dipende da quello sottostante. Non si può distribuire un agente affidabile su una piattaforma che non è ancora in grado di osservare se stessa, rendere visibile la propria configurazione o mostrare il motivo per cui ha preso una decisione. L'autonomia senza osservabilità non è sofisticazione: è un rischio che non si riesce a vedere.

Se l'avessi capito prima, avrei evitato la tentazione di promettere troppo sulla parte alta dello stack prima che le fondamenta fossero solide. La demo più ambiziosa ti conquista facilmente, perché entusiasma tutti. Ma una capacità autonoma appariscente basata su fondamenta immature si rompe in modi difficili da diagnosticare ed erode rapidamente la fiducia — e la fiducia, una volta consumata da un sistema che ha agito in modo errato, è costosa da ricostruire.

Quindi, direi a chiunque stia lanciando il suo primo prodotto basato sull'IA: sii onesto sul livello in cui ti trovi, distribuisci valore reale a quel livello e lascia che le capacità di livello superiore si guadagnino il loro posto. La sequenza è tutto.

Come i CPO possono ottimizzare per la scarsità giusta

In generale, il mio consiglio è di smettere di ottimizzare per la scarsità sbagliata.

Per la maggior parte della nostra carriera, il collo di bottiglia era la produzione — riuscire a realizzare le cose. Quindi abbiamo organizzato tutto intorno al flusso di lavoro: backlog, pianificazione della capacità, distribuzione più rapida. L'IA ha semplicemente fatto crollare quel collo di bottiglia. Il costo per generare un'opzione, un prototipo, una bozza o un'analisi si sta avvicinando allo zero. E quando un vincolo scompare, un altro diventa quello che conta.

La nuova risorsa scarsa è la capacità di giudizio — sapere cosa vale la pena costruire, a cosa dire di no, che aspetto abbia qualcosa di "buono" e quali errori l'output sicuro di sé dell'IA stia commettendo silenziosamente. Quindi il mio consiglio si articola in tre parti:

1. Spendi il tuo dividendo dell'IA sul giudizio, non solo sulla velocità: Il senso di muoversi più velocemente non è distribuire di più, ma ottenere più tentativi per poter essere più selettivi. Se l'IA ti fa semplicemente costruire più rapidamente le cose sbagliate, hai peggiorato il problema invece di migliorarlo.
2. Resta vicino alla pratica: I leader che faranno fatica sono quelli che considerano tutto questo una decisione sugli strumenti di qualcun altro. Costruisci qualcosa tu stesso. Non puoi guidare un team attraverso un cambiamento di cui hai solo letto — i tuoi istinti saranno calibrati su un mondo che non esiste più.
3. Diventa più esperto nel tuo ambito, non più vago: Ora tutti hanno accesso alla stessa IA generalista. Il tuo vantaggio non è il modello, ma la conoscenza specifica, conquistata con fatica, dei tuoi clienti, della realtà normativa in cui operi e della tua azienda. L'IA rende il generico un bene indifferenziato e rende più prezioso ciò che è specifico. Punta su ciò che è tuo.

Questo momento premia il discernimento e la convinzione più delle informazioni e dell'impegno. È scomodo, perché puoi controllare l'impegno, mentre devi sviluppare il discernimento. Ma i leader che lo interiorizzano presto sono quelli che capitalizzeranno sempre di più nel tempo.

Segui gli aggiornamenti

Puoi seguire il lavoro di Abhi Gandotra su LinkedIn e sul suo sito web. Oppure dai un'occhiata al suo libro, L'agente sovrano.

Presto arriveranno altre interviste a esperti su Il CPO Club!