C’è molta illusione e fumo negli occhi nel mondo del prodotto in questo momento—soprattutto quando si parla di intelligenza artificiale. Strumenti scintillanti e prototipi accattivanti si spacciano per soluzioni pronte per la produzione, e i team sentono la pressione di tenere il passo. Ma cosa succede quando la moda supera i fondamentali?
Hannah si confronta con Matt Graney, CPO di Celigo, per parlare dei trucchi nascosti nei prodotti: dal vibe coding e le illusioni no-code alle scorciatoie alimentate dall’AI che minano la vera solidità del prodotto. Con decenni di esperienza nel B2B e una carriera nello sviluppo e nella crescita dei team, Matt offre una visione lucida e radicata su ciò che sta davvero cambiando, su ciò che rimane invariato e su come mantenere intatto il proprio senso del prodotto attraverso tutto questo.
Cosa imparerai
- Perché veloce ≠ pronto per la produzione—e come comunicarlo agli stakeholder
- I rischi nascosti di affidarsi troppo agli strumenti di AI nel lavoro di prodotto
- Cosa significa davvero scalare un’organizzazione di prodotto (metafore caotiche comprese)
- Perché le pratiche da PM “vecchia scuola” sono forse più rilevanti che mai
- Dove l’AI brilla davvero—e dove invece è ancora carente
Punti chiave
- Attenzione alla sfilata di prototipi: Solo perché qualcosa sembra fantastico non significa che sia stato costruito per durare. La velocità nel creare una demo non è la stessa cosa della velocità nello scalare un prodotto.
- Usa l’AI per espandere l’immaginazione, non per sostituire il giudizio: Lascia che emergano punti ciechi e prospettive diverse, ma non lasciare che sia l’AI da sola a guidare la roadmap.
- La priorità spietata è senza tempo: Man mano che sviluppare diventa meno costoso, decidere cosa costruire è sempre più importante. Le funzionalità “zombie” esistono davvero.
- I prototipi devono essere usa e getta: Servono per esplorare, non per durare. Non costruire una villa sul cartone.
- La ricerca utente ha ancora bisogno del cervello umano: Le trascrizioni AI sono utili, ma le sfumature vivono nelle cose non dette. L’arte conta.
- Non innestare processi senza la cultura adatta: Strumenti come OKR o LLM non possono risolvere ciò che è rotto alla base—lo evidenziano solo più in fretta.
Capitoli
- 00:00 – Il problema dell’hype nei prodotti
- 01:19 – Incontro con Matt Graney, CPO di Celigo
- 02:53 – Vibe coding e momenti alla Scooby-Doo
- 04:35 – Velocità di demo vs. velocità di produzione
- 06:34 – E se il costo di sviluppo arrivasse a zero?
- 08:00 – Quando gli strumenti AI nascondono cattivi giudizi
- 10:25 – Dove gli LLM promettono troppo
- 11:07 – Scorciatoie di prodotto che erodono la fiducia
- 13:34 – Scale-up dei team di prodotto: lezioni apprese
- 16:28 – Competenze da PM “vecchia scuola” che contano ancora
- 18:30 – Dove l’AI può davvero aiutare (e dove non può)
- 19:58 – Conclusione + dove trovare Matt
Conosci il nostro ospite

Matt Graney è Chief Product Officer presso Celigo, dove attinge a oltre 20 anni di leadership di prodotto in aziende software B2B e startup per guidare la visione, la strategia e la roadmap dell’azienda. Prima di entrare in Celigo, Matt ha ricoperto ruoli dirigenziali presso Axway, Borland Software e Telelogic (ora parte di IBM Rational), e ha iniziato la sua carriera come ingegnere del software in Australia dopo aver conseguito una laurea in Ingegneria dei Sistemi Informatici presso l’Università di Adelaide.
Risorse da questo episodio:
- Iscriviti alla newsletter The CPO Club
- Connettiti con Matt su LinkedIn
- Scopri Celigo
Articoli e podcast correlati:
Hannah Clark: Le cose non sono sempre come sembrano. Dai prezzi di abbonamento attira-e-cambia, alle persone che giurano che le caramelle di mais siano buone, non mancano motivi per essere scettici su tutto—soprattutto nel mondo del prodotto in questo momento. La velocità del cambiamento in questo settore è così rapida che le mode possono iniziare a sembrare best practice e le vere best practice possono sembrare superate. Ma quando l'obiettivo è costruire un prodotto che possa scalare nel tempo, sta a noi controllarci per non farci risucchiare dall'ipnosi dell'hype train.
Il mio ospite di oggi è Matt Graney, CPO di Celigo. Matt ha oltre 20 anni di esperienza in prodotti B2B e quasi nove di questi li ha trascorsi facendo crescere il team prodotto di Celigo da quattro a oltre 45 persone. E anche se l'IA si è rivelata un'opportunità straordinaria per l'azienda, ha notato un divario tra aspettative e realtà quando si tratta di alcune delle nuove, scintillanti tattiche che invadono il nostro feed su LinkedIn. Da prototipi che si travestono da codice pronto per la produzione a strumenti troppo belli per essere veri, ascolterai la sua opinione su dove procedere con cautela e sulla saggezza provata dal tempo su cui fa affidamento per superare indenne questa trasformazione dell'IA. Iniziamo.
Ah, tra l'altro, teniamo conversazioni come questa ogni settimana. Quindi se ti sembra interessante, perché non ti iscrivi? Bene, ora andiamo avanti.
Bentornati a Il Podcast del Product Manager. Oggi sono qui con Matt Graney. È il CPO di Celigo.
Matt, grazie mille per aver trovato il tempo di parlare con noi.
Matt Graney: Grazie a te, Hannah. È un piacere parlare con te oggi.
Hannah Clark: Ci racconti un po' del tuo background e del tuo percorso che ti ha portato a diventare CPO di Celigo?
Matt Graney: Sì, dunque, lavoro nel product B2B da molto tempo ormai, circa 20 anni. Celigo è una piattaforma di integrazione e sono con Celigo da otto anni e mezzo, sono entrato poco dopo il finanziamento di Serie A.
E altri cinque anni e mezzo prima ancora sempre nell'ambito dell'integrazione. Non è stato proprio intenzionale, è semplicemente andata così. Prima di ciò, ero coinvolto in prodotti relativi al ciclo di vita dello sviluppo software, inclusi strumenti di modellazione UML. Per chi si ricorda cosa fossero, inizialmente ero un ingegnere del software in Australia, nel settore telecomunicazioni e difesa.
La mia prima esperienza negli Stati Uniti è stata come sales engineer, proprio per un prodotto del quale ero già un power user mentre ero in Motorola. Quindi, background variegato. Poi ho fatto anche un periodo nel marketing di prodotto e infine sono approdato definitivamente al product.
Hannah Clark: Periodo di servizio. Non l'avevo mai sentito descritto così.
Divertente. Oggi ci divertiremo un po' con una puntata quasi a tema Halloween. Ci concentreremo sul tema delle cattive strategie di prodotto camuffate. Inizieremo scavando nel vibe coding. Tante opinioni circolano sul Vibe Coding tra i professionisti del prodotto.
E lo ammetto per prima, le piattaforme no code sono strumenti incredibili. Le uso costantemente, ma possono anche portare a momenti molto simili a Scooby-Doo, momenti in cui ci avviciniamo, togliamo la maschera e vediamo che la realtà è tutt'altra. Qual è stata la tua esperienza, Matt, con il vibe coding all’interno dei team di prodotto?
Raccontami i pro, i contro e gli aspetti critici.
Matt Graney: Sì. E ce l’avremmo fatta se non fosse stato per voi ragazzini impiccioni. Giusto. Quindi penso che sia una democratizzazione, il che è straordinario. Ma dobbiamo pensare anche all’illusione: il potere di rendere qualcosa bello non significa che sia costruito a regola d’arte.
Credo ci siano tante cose che devono accadere sotto la superficie. Non dobbiamo confondere prototipi rapidi con codice pronto per la produzione. Va bene, creatori cittadini, ma servono anche architetti cittadini. Nel nostro ambito, ad esempio nel B2B, abbiamo a che fare con software infrastrutturale, parliamo di miliardi di transazioni al mese.
Solo alcune parti dell’applicazione, forse i livelli più superficiali, ci fanno sentire a nostro agio a fare vibe coding. Quindi, deve essere lo strumento giusto per il compito giusto, come è sempre stato. E allo stesso tempo bisogna garantire una cultura della sperimentazione, incoraggiare il team a rischiare, provare nuovi strumenti e restare aggiornati sulle ultime novità in questo periodo davvero rivoluzionario per l’intero settore.
Hannah Clark: Andando ancora più a fondo: quando ragioniamo sul diverso livello di comprensione della tecnologia in tutta l'organizzazione, è molto allettante per chi ha meno esperienza con la tecnologia o per i fondatori alle prime armi vedere quello che sembra codice funzionante e lanciarsi. Questo mette tanta pressione sui team di ingegneria, che devono tenere il passo o produrre con la stessa velocità, facendo sembrare tutto lucido e nuovo.
Come aiutiamo gli stakeholder a capire i veri vincoli e le reali differenze tra un prototipo realizzato con gli strumenti di vibe coding e il software pronto per la produzione?
Matt Graney: È un punto fondamentale perché la rapidità nel mostrare una demo non è la stessa cosa che velocità verso la produzione, e specialmente quando parliamo di 5.000 clienti B2B. A volte parliamo di ciò che facciamo come infrastruttura, la ‘plumbing’.
Quindi, l’IA può pitturare la casa, ma non sempre ci farà l’impianto idraulico, giusto? Serve affidabilità su alcune cose. Ci sono sfide legate alla pressione sia sui team di ingegneria, sia da parte degli executive. Ho visto recentemente membri di livello alto non tecnici vibare e ‘coddare’ proof of concept per mostrare nuove funzionalità richieste dai clienti.
Ha acceso l’immaginazione, ma ha anche creato una pressione non esplicitata che tutto questo sia alla portata di tutti e che possiamo portarlo subito in produzione. E tornando alla casa: queste pareti potrebbero non essere portanti, ma solo facciata. Sembrano belle. Non dico che non ci sia spazio per tutto questo, la velocità di realizzazione delle POC è incredibile e va sfruttata.
Serve per spiegare meglio i requisiti, per i designer che possono proporre flussi alternativi. Se prima disegnavano tanti schermi con lo strumento preferito di design, il valore di avere del codice funzionante è innegabile. Dobbiamo sfruttarlo quanto più possibile, sempre tenendo presente che non equivale a codice pronto per la produzione.
Hannah Clark: Una cosa su cui rifletto spesso è che questi strumenti, inevitabilmente, diventeranno molto più sofisticati e noi come utenti pure, quindi il costo di sviluppo tenderà a zero.
Da leader di prodotto, quali sono le preoccupazioni di questa tendenza? E cosa hai fatto tu in Celigo per mitigarle?
Matt Graney: Ottimo modello mentale, Hannah. Una bella ipotesi mentale: cosa succede se il costo di realizzazione va verso lo zero?
Magari i tool progrediscono così in fretta e anche la competenza degli utenti. Proprio come vediamo miglioramenti costanti nelle esperienze ChatGPT e simili: ci aspettiamo un calo drammatico di costi. Paradossalmente, questo mette più pressione sui product manager affinché scelgano di costruire le cose giuste. Non ci dispensa da fare analisi, ricerche qualitative e quantitative, interviste con i clienti, consigli consulenti di prodotto, e così via.
Proof of concept, test AB, lavoro stretto in triade PM, designer, ingegnere. Tutto ciò rimane ed è fondamentale. Anzi, occorre stare attenti, o rischiamo di ritrovarci un’orda di “progetti zombie”: idee facili da realizzare che infestano il prodotto pur non essendo solide.
Le vecchie discipline del product management tornano in primo piano: dobbiamo decidere bene e produrre risultati, e nulla di ciò è cambiato.
Hannah Clark: Concordo. E restando sulle idee mal concepite: vedo un’esplosione di tool che sembrano offrire benefici incantati, ma che celano enormi rischi.
Ho visto concetti abbastanza gravi circolare, che potrebbero essere facilmente manipolati da malintenzionati. Cosa stai vedendo tu che ti lascia perplesso, e quale ruolo hanno ancora il giudizio e il buon senso del product manager, che non possono essere automatizzati?
Matt Graney: Da sempre cerchiamo la sfera magica della gestione del prodotto, che siano metodologie di scoring come RICE.
Ma ho visto anche queste metodologie usate male. Lasciano margine perché i PM possano influenzare i punteggi per favorire le proprie idee. Bastano pochi giri per imparare come ‘truccare’ i risultati. Vedremo gli stessi rischi anche qui.
Alcuni strumenti promettono di raccogliere tutti i dati, ogni telemetria, ogni conversazione di prodotto. Ma sappiamo che molti fatti importanti emergono “fuori canale”, da osservazioni che magari vengono da un replay di sessione, ma che non sono strutturate in modo da essere comprese da un LLM.
Non esiste quindi sostituto per un sano giudizio di prodotto; anche avendo più dati che mai, sono sempre dati incompleti. Serve visione, strategia, e capacità di scommettere e misurare i risultati, se lavoriamo bene.
Ma resta un processo iterativo, e non penso che l’IA ci dia la risposta magica per un roadmap infallibile.
Hannah Clark: Concordo. Recentemente ho parlato con un ospite che sarà nella prossima puntata: discutevamo proprio di come l’IA sia una tecnologia ‘frastagliata’, capace in alcune aree ma carente in altre che però sembrano invece coperte.
Quindi, serve sia senso di prodotto che comprensione della tecnologia per valutare cosa stiamo davvero delegando all’IA.
Matt Graney: Anche con le semplici chat AI, abbiamo visto esempi di IA molto ossequiose, che ti danno sempre ragione. Se non ne sei consapevole, rischi di credere di avere sempre grandi idee.
Personalmente, preferisco stimolare l’AI a darmi feedback molto critici sulle mie idee, così da avere una visione alternativa. Altrimenti, rischio di passare per un genio nel dialogo con l’IA!
Hannah Clark: Eh sì, ci adorano! Lasciamo il “vibe pointing” e passiamo ad altri scorciatoie tanto allettanti quanto insostenibili, che vediamo nei team di prodotto.
Quali sono quelle che hai visto più spesso?
Matt Graney: Un classico: gli OKR. Rapporto travagliato, a livello aziendale magari funzionano, ma nel prodotto sono complessi. Il problema è soprattutto cercare di importare qualcosa dalle “big tech” (le FANG) senza averne la cultura di base. Non si può “innestare un arto” come Frankenstein: se manca la cultura, non attecchisce mai veramente.
Poi c’è il “teatro delle metriche”: tante vanity metrics che non portano a decisioni migliori. È un rischio noto. O le “feature factory” o “feature farm”: ora possiamo “coltivare” per ettari, perché la capacità di produrre aumenta, ma dobbiamo assicurarci di fare le cose giuste. Insomma, troppe scorciatoie, in cerca di soluzioni magiche sentite magari su X o LinkedIn, ma senza il rigore necessario si erode la fiducia.
Hannah Clark: Sì, parlando di fiducia erosione, penso subito all’impatto nella community della UX research. I ricercatori UX sono sempre stati un po’ sottovalutati nel processo di prodotto, ma ora con gli LLM la metodologia si fa ancora più confusa.
Lo direi a gran voce: non si può sostituire la user research con un LLM.
Matt Graney: Il nostro responsabile della ricerca utente mi dice la stessa cosa: le trascrizioni AI sono utili, ma spesso mancano di sfumature, almeno per ora. Può cambiare con le prossime generazioni di tech, ma oggi è fondamentale conoscerne i limiti e continuare con la buona, vecchia ricerca utente.
Hannah Clark: Cambiando un po’ argomento, parliamo della tua esperienza con la crescita dei team. Hai portato il team di Celigo da 2 PM a dieci volte tanto. Sono certo che ci siano stati errori nel percorso.
Quali sono state le lezioni più importanti per la crescita di un team da una realtà piccola a una matura? Cosa hai imparato che vale ancora oggi, anche nell’era dell’IA?
Matt Graney: Sì, è stata una bella avventura.
Quando sono arrivato, ho ereditato due PM e due technical writer. Team da quattro. Ora siamo circa 45, quasi 50. È un team di PM, designer, ricercatori, documentazione tecnica, product operations. La lezione? Forse l’ordine con cui fare le cose.
All’inizio era tutto semplice: io, il CTO e un altro, tutti in una stanza a gestire la backlog. Ma questo non scala. Lavorare con team offshore complica.
Poco a poco abbiamo aggiunto processi. All’inizio il design era fatto come si poteva: il PM cuciva schermate, quasi come un biglietto di riscatto, un po’ grunge e imbarazzante. Il primo tentativo di designer professionisti non è stato ottimale: li usavamo come un’agenzia “fatecelo bello” più che sul vero UX. La documentazione sempre ben curata, sempre evoluta. Quindi abbiamo introdotto processi quando necessari, senza pretese di perfezione, ma seguendo la crescita reale del business e lasciando spazio di crescita ai membri del team.
È stata una grande esperienza, con tante prime volte. Ho qualche cicatrice di battaglia (e capelli grigi) a dimostrarlo!
Hannah Clark: Davvero? Dove?
Matt Graney: Oh sì. Ma preferisco dare la colpa ai miei figli…
Hannah Clark: Dai la colpa ai figli per tutto, lo faccio sempre anch’io! Per restare in tema, ti chiedo: quali sono le pratiche di product management che oggi ritieni magari più importanti di prima, per quanto possano sembrare un po’ datate?
Sono concetti, framework o pratiche che rivaluti o sottolinei più che mai ai tempi dell’AI?
Matt Graney: Come detto, se il costo di sviluppo arriva vicino allo zero, maggiore importanza ha la priorità. Quindi penso a tutti gli strumenti per prioritizzare.
Serve allineamento su visione e strategia: la squadra deve sapere abbastanza da poter decidere in autonomia. Non esiste nulla che sostituisca il contatto diretto con utenti e clienti: i miei primi anni erano quasi una negoziazione da ostaggio con clienti infelici!
Non c’è niente che dia una visione più concreta e strumenti per capire le priorità. Fare priorità spietate è essenziale: la capacità non basta mai, nemmeno nelle grandi aziende. Tutti i classici strumenti restano utili. L’IA serve per gestire grandi quantità di dati nella ricerca e, come detto, prototipazione rapida (vibe coding) se ben contestualizzato.
Molti dimenticano che il prototipo nasce per essere buttato, non per essere la base della produzione. Se si fa tutto questo, i tool accelerano davvero il lavoro e aiutano ancora nella priorità.
Hannah Clark: Giusto. Concludendo con ottimismo: dove vedi, oggi, le opportunità più concrete e di valore per l’IA a supporto del lavoro dei product manager? E che consiglio dai ai leader di prodotto per sfruttare l’IA in modo consapevole senza cadere nelle trappole o “smaskeramenti” discussi?
Matt Graney: La cosa maggiore, credo, è la ricerca. Oggi la possibilità per un PM di fare competitive research è eccezionale, e lo avrei voluto avere anni fa. Molte documentazioni ora sono pubbliche, ma occorre farla comunque.
Poi, scrivere rapidamente documentazione. Molti parlano di scrivere prima il press-release o le FAQ: ora ha davvero senso, anche se prima sembrava laborioso. L’IA aiuta a stimolare la fantasia: cosa non sto considerando? L’IA può evidenziare punti ciechi se usata bene. A volte “allucina”, ma può dare comunque spunti o pensieri laterali inaspettati. L’IA è come uno specchio deformante: se la disciplina interna manca, peggiora le cose; ma usata bene dà il focus che serve ai product manager.
Hannah Clark: Concordo in pieno. Matt, grazie: è stato illuminante. Grazie di aver condiviso la tua esperienza e aiutato a fare chiarezza su questi temi così attuali e spesso fraintesi.
Dove possono seguirti online?
Matt Graney: Il modo migliore è su LinkedIn, lì sono più attivo che altrove. Sarò felice di confrontarmi lì.
Hannah Clark: Fantastico, grazie ancora.
Prossimamente su Il Podcast del Product Manager: pensavi che questa puntata avesse già messo bene a confronto aspettativa e realtà? Nella prossima approfondiremo la tecnologia LLM in modo che ti farà rivalutare tutto ciò che pensi sull’IA.
Il potenziale è illimitato, ma i limiti attuali sono molto più complessi di quanto sembri, così come gli impatti su chi costruisce e usa prodotti AI. Sarà una puntata intensa, quindi iscriviti ora per non perdertela!
