Come Sono Sopravvissuto agli Ultimi 3 Anni nella Leadership di Prodotto

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un software. Perdonate eventuali errori di battitura: il bot non è corretto al 100% delle volte.

Hannah Clark: Ecco un esercizio folle per te. Prova a immaginare una giornata della tua vita tre anni fa. Nel 2022, i grandi temi del momento erano la crescita guidata dal prodotto contro la crescita guidata dalle vendite, e il dibattito tra ritorno in ufficio e remote-first. L'IA sembrava una missione facoltativa, e il mercato del lavoro era a favore dei candidati. Quanto sono cambiate le cose in un tempo così breve.

Ma un'altra differenza era che questo show aveva un altro conduttore—e quel vecchio conduttore è il mio ospite di oggi. Michael Luchen ha trascorso gli ultimi tre anni concentrandosi sulla leadership di prodotto e, come Product Transformation Architect, si è trovato nel vivo di un periodo cruciale in cui l’unica costante è stata il cambiamento, sia all’esterno che all’interno dei team di prodotto.

Nell'episodio di oggi rifletteremo sulle scommesse strategiche e tattiche che ha fatto negli ultimi anni, quelle che hanno funzionato, quelle che no, e dove soffia il vento per il product management mentre ci avviciniamo alla seconda metà del 2025. Iniziamo subito.

A proposito, teniamo conversazioni come questa ogni settimana. Quindi, se ti interessa, perché non ti iscrivi? Va bene, ora entriamo nel vivo. Bentornati al podcast del Product Manager. Oggi sono qui con Michael Luchen, che alcuni di voi potrebbero ricordare.

Michael, grazie per essere con noi oggi.

Michael Luchen: Grazie, Hannah. È un piacere essere di nuovo qui.

Hannah Clark: Certo. Puoi raccontarci un po' del tuo background e di come sei arrivato dove sei ora?

Michael Luchen: Certo, ciao a tutti. Sono Michael, ex conduttore di questo podcast, ma ultimamente mi definisco architect della trasformazione di prodotto. Il mio focus è stato aiutare aziende in fase di crescita a costruire organizzazioni di prodotto che rilasciano come startup e scalano come grandi imprese. Personalmente ho oltre 12 anni di esperienza su più di 50 prodotti, dalle startup di 10 persone a brand globali come Adidas.

In tutto questo tempo ho imparato che le aziende vincenti non sono solo ricche di idee ma anche guidate dai sistemi. Dalla mia esperienza, grandi sistemi di prodotto trasformano la visione in esecuzione ripetibile. Questa consapevolezza nasce dall’aver guidato prodotti in ogni contesto e struttura organizzativa immaginabile. Ognuna mi ha insegnato nuovi schemi su ciò che funziona davvero.

Recentemente sono stato Director of Product in Float, dove ho trasformato l’organizzazione di prodotto passando da rilasci irregolari a una cadenza continua di delivery su tutti i team, contribuendo a una forte crescita ARR e alla posizione numero uno su G2. Prima ho trascorso nove anni in Crema, importante agenzia digitale, guidando la gestione di prodotto sia per l’agenzia che per clienti, da società di consulenza d’élite a startup emergenti.

A livello personale, sono un sistemista nel cuore. Che stia strutturando processi di prodotto, scattando una foto con la mia Fuji o costruendo Lego con i miei figli, esploro come i pezzi si incastrano per creare qualcosa di più grande della somma delle parti.

Hannah Clark: Molto interessante. Abbiamo parlato tanto recentemente di pensiero sistemico nel podcast e questo si integra proprio nella nostra tematica del periodo.

Sei stato il conduttore fondatore, in effetti, del podcast Product Manager. Grazie quindi per aver gettato le basi dello show. Era, direi, il 2022. Non molto tempo fa, ma nel mondo del prodotto è passato un secolo. La disciplina era completamente diversa. Quali sono stati, secondo te, i cambiamenti più grandi da allora ad oggi?

Facciamo un confronto: com’era allora la disciplina e cosa vedi ora sul campo?

Michael Luchen: Sì, bella domanda, perché nella nostra industria sembra di dover cavalcare un’onda continua di cambiamenti. Non esiste un processo, una struttura o una modalità fissa con cui collaboriamo come product manager e con i team di prodotto per realizzare e consegnare valore ai clienti.

Quindi è difficile rispondere, perché onestamente sto già pensando a cosa verrà dopo mentre racconto i cambiamenti che ho visto. All’epoca, quando iniziai a condurre questo podcast, coesistevano due mondi in competizione.

C’era chi seguiva la "feature factory", ovvero un processo molto definito, nel bene e nel male. E poi il culto dello scrum agile quasi venerato. I team dovevano scegliere l’approccio, oppure, su scala enterprise, c’era SAFe. Ora vedo che questi approcci sono in secondo piano.

I processi ci sono ancora: waterfall, scrum, SAFe—per il bene e per il male. Ma vedo che i team che hanno successo guardano alla propria cultura di prodotto, ai modi di pensare, alle persone in squadra e scelgono elementi dai vari processi senza nominarli come tali.

Creano in modo sistematico il proprio metodo per costruire grandi prodotti e divertirsi, favorendo scoperta e delivery continua.

Hannah Clark: Ora vorrei cambiare leggermente tema e parlare di qualcosa che solitamente non affrontiamo, ma che trovo molto interessante: una storia di fallimento.

Mi hai detto in una conversazione precedente di un’iniziativa di trasformazione in Float che non è andata bene la prima volta. Cosa è successo? Qual è il postmortem e cosa hai imparato?

Michael Luchen: Sono arrivato in Float dopo nove anni in agenzia, avendo il privilegio di lavorare con tanti tipi diversi di organizzazioni.

Avevo visto molti schemi in aziende piccole, grandi, o che stavano superando una fase di crescita. Così, appena arrivato in Float e parlandone con tutti, tutti erano allineati sui punti dolenti del processo.

Avevo guadagnato la fiducia del CEO e dei due co-founder per tenere una presentazione dal vivo al primo meeting aziendale dopo pochi mesi dal mio arrivo: “Passeremo alle squad. Sarà fantastico!”

La presentazione è stata accolta molto bene da tutti, anche dai co-founder. Tutti dicevano che risolveva i problemi. Ma nei mesi successivi la cosa è lentamente scemata e tutto è tornato come prima. Ho capito dopo che, anche se tutti erano d’accordo sul problema e sulla soluzione, la verità è che non era il momento giusto per un cambiamento così grande.

In parte dipendeva da come stavamo facendo crescere l’organizzazione: avevamo ruoli molto specializzati, ad esempio in ingegneria. Quindi se serviva una persona con skill particolare, ce n’era solo una all’interno, e questo metteva i bastoni tra le ruote alla sostenibilità delle squad.

L’altro aspetto imparato: il cambiamento culturale richiede tempo. Non basta una presentazione, anche se tutti sono convinti. Serve una serie di conversazioni continua, molto sfumata, sul piano individuale o di team. Non lo dimenticherò mai.

È curioso perché ne rido ancora con il CEO, dopo tempo!

Hannah Clark: Credo che qui si entri nel pensiero sistemico: bisogna considerare tutte le ragioni per cui qualcosa potrebbe non funzionare e valutare il contesto per capire come reimpostare l’approccio in futuro.

Parliamo ora della parte pratica della trasformazione. Hai sviluppato un framework per mappare i pain point a livello organizzativo usando Miro, uno strumento che molti di noi conoscono. Come hai identificato i punti di frizione, non solo nel prodotto e che aspetto aveva quel processo nel quotidiano?

Michael Luchen: Secondo me, prima ancora degli strumenti serve curiosità ed empatia. Ricordo l’inizio in Float (e lo stesso succedeva con alcuni clienti in Crema): si sentono spesso le stesse difficoltà, ad esempio “ci vuole troppo perché i design siano pronti”, oppure “non sono allineati con ciò che vogliamo realizzare”, o “non c’è chiarezza di scope”, “non si sa quando qualcosa è finito”.

È facile reagire di pancia e cercare di forzare una soluzione immediata sul punto dolente, soprattutto se sei il leader di quel team.

In Float, come Director of Product sovrintendevo i product manager, la data, la UX research, per un periodo anche il design. Naturalmente mi verrebbe da proteggere il mio team, ma ho dovuto metterlo da parte per svolgere questo esercizio e incontrare uno a uno le persone di tutta l’organizzazione, dagli ingegneri al marketing fino a customer success e sales. "Cosa funziona? Cosa manca?"—Un dialogo aperto e curioso, senza giudizio o scaricabarile.

Se si imposta così, si ottengono ottimi insight che puoi mappare con dei post-it su una board Miro per trovare dei temi ricorrenti. Poi, a fianco, mappi il processo ufficiale dell’azienda e vedi subito le discrepanze.

Da lì, prendi le discrepanze e i temi ricorrenti, li visualizzi con un nuovo processo, li usi per cercare allineamento sia con chi hai già parlato che con il resto dell’organizzazione, su e giù per la struttura: sono le cose che vogliamo provare, questi sono gli esperimenti di cambiamento che faremo.

Se ottieni buy-in in questo modo, costruendo sopra i veri pain point vissuti da tutti, raramente avrai resistenza.

Hannah Clark: Ottimo. E su questo vorrei approfondire, perché il buy-in è spesso la cosa più difficile.

Anche se la soluzione proposta sulla carta risolve i pain point, il cambiamento è difficile. Modificare le abitudini e i flussi di lavoro non è banale. Per esempio, come dicevi, Float aveva una cultura di engineering molto specializzata e passare a squadre di prodotto cross-funzionali non è stato semplice: si è creata tensione.

Come gestisci queste situazioni e faciliti la transizione quando vuoi facilitare la vita a tutti? Come ottieni il buy-in quando c'è tensione?

Michael Luchen: Sì, è una bella domanda. E qui torna in gioco, senza gioco di parole, l’obiettivo stesso di Float: la gestione delle risorse.

Si tratta di chiarezza e rispetto. Senza linee di comunicazione chiare e rispetto reciproco, nasce la frizione. Se invece ci si concentra sulla collaborazione—ad esempio c’è una persona altamente specializzata che si vorrebbe dedicare a una squad ma che deve anche gestire un’infrastruttura critica—non c’è una risposta bianca o nera.

Le opzioni di solito sono: possiamo assumere, ma assumere e onboardare a un certo livello richiede tempo.

Quindi qual è il piano B? Qui entra in gioco la pianificazione capacità e la gestione delle risorse, trovando compromessi condivisi.

Ci sono due livelli: il singolo individuo (gestisce bene l’allocazione? Riesce a coprire il supporto trasversale?) e l’organizzazione—in termini di roadmap prodotto, di ops e product che devono lavorare insieme. Non puoi decidere come allocare le risorse senza il contesto delle priorità strategiche del prodotto.

Hannah Clark: Ottimo spunto. Come si inseriscono i rituali operativi pratici in questa transizione? Hai introdotto il concetto di "One Team, One Roadmap" e delle async design sprint. Come sono evoluti e quali sono state le lezioni più utili?

Michael Luchen: "One Team, One Roadmap" è stata la sintesi di tutta la mia opera di trasformazione in Float. Sono partito dal fallito tentativo di introdurre le squad, che poi con il tempo (e con investimento culturale e in nuove assunzioni) è diventato un successo duraturo.

Crescendo, Float aveva più squad di prodotto, squad di piattaforma, lavoro marketing dedicato. Product marketing chiedeva visibilità sulle novità, il sales voleva poter raccontare la roadmap, i co-founder volevano investire con saggezza.

Ogni squad aveva la sua roadmap, ogni team anche, tutto gestito separatamente. Abbiamo deciso di unificare tutto in un sistema snello ma informativo e poco dispendioso di tempo per le persone coinvolte.

Abbiamo sfruttato le nuove funzioni roadmap di Linear per creare viste aggregate di prodotto e piattaforma. Ai team bastava aggiornare lo stato su Linear e questi aggiornamenti confluivano in un canale Slack, dove chiunque nell’azienda poteva iscriversi per essere aggiornato, spesso con una demo Loom o link all’ambiente di test.

A questo ho aggiunto incontri mensili di "product huddle"—sessioni di 60 minuti di demo in cui i product manager e i lead di piattaforma mostravano i progressi. Ero solito alternarle su base bisettimanale anche per rispettare i 15+ fusi orari dell’azienda.

Questa trasparenza radicale, tra le product huddle focalizzate sulle demo, le roadmap automatizzate e gli aggiornamenti incrementali, costruiva fiducia, cultura di condivisione e permetteva decisioni più efficaci a tutti i livelli.

Hannah Clark: Mi colpisce anche l’empatia per i diversi stili di apprendimento delle persone e la possibilità di integrarsi nella strategia ai propri tempi. Una visione davvero multilivello del buy-in.

Michael Luchen: Già, e questo si ricollega anche alle design sprint asincrone. Da anni conducevo design sprint con i clienti in Crema, ma oggi penso che non serva seguire la procedura canonica: è meglio scegliere gli strumenti giusti e adattare la design sprint alle proprie esigenze di allineamento.

In Float, passai quindi a design sprint asincroni: una board FigJam in cui gli esercizi del ciclo di 5 giorni venivano distribuiti su due settimane, per dare modo ai colleghi dei diversi emisferi di partecipare quando volevano. Così si ottiene più partecipazione, ognuno contribuisce con le sue idee, si lascia traccia dei commenti e si possono, se necessario, approfondire le discussioni più calde in incontri sincroni ad hoc.

Hannah Clark: Sembra quasi come lo scambio di lettere invece della didattica in classe: c’è più sicurezza e meno giudizio nell’esprimersi a mente fredda invece che “dal vivo”.

Michael Luchen: Esatto! E la possibilità di alternare tra i due approcci, sempre nel rispetto delle necessità del team.

Hannah Clark: Davvero interessante. Ora cambiamo argomento, non possiamo non citare la parola magica a due lettere di oggi: IA. Quando conducevi tu il podcast, non se ne parlava praticamente, ora è sulla bocca di tutti.

All'epoca, anche io mi sono unita a quel periodo, ma le conversazioni erano molto vaghe. La tecnologia non sembrava ancora pronta. Ora invece tutti vogliono IA nei propri flussi di lavoro e prodotti. In Float, come avete gestito l’integrazione AI? È un tema grande, lo so. Tu sei stato vicino al progetto di recente. Come hai affrontato la cosa?

Michael Luchen: All'inizio, con il lancio di ChatGPT, ero ipnotizzato come tutti.

Ho iniziato a sperimentare e a documentarmi sulle opportunità dal punto di vista prodotto, sia per interesse personale che poi portando questi concetti su Float. Ho abbozzato idee, scritto una sorta di white paper sulle mie ipotesi (erano ancora i primissimi tempi), su dove sarebbe arrivata la tecnologia LLM in 3 mesi, 6 mesi, 1 anno e 3 anni nel SaaS B2B come quello di Float.

Poi documentando riferimenti di settore, mi chiedevo: quali investimenti dobbiamo fare prodotto e quando? Quando è il momento giusto per scommettere, senza però buttare tutto il resto per inseguire solo l’AI, come tanti tentati all’epoca.

Ho allegato anche schizzi di mappatura dati tra API Float e possibilità di LLM. Ho condiviso il documento con il leadership team: ha generato entusiasmo e buy-in.

Ci siamo poi confrontati con una consulenza AI generativa di Melbourne, Move 37, che ci ha consigliato su come approcciare l’IA in linea con il valore che volevamo offrire agli utenti. Il discrimine chiave era tra dati strutturati e non strutturati. Stavamo anche migliorando il sistema di reportistica, ma molto si può fare solo con dati strutturati. L’ambito non strutturato è quello della vera AI generativa, più simile all’ambiguità di ChatGPT—ed è lì che abbiamo focalizzato gli esperimenti.

La priorità diventava concentrarsi sui "flussi agentici". Con la consulenza abbiamo creato un" playground" per agenti dedicato a sperimentare con i dati, mappando flussi utente e, "sotto il cofano", flussi agentici di supporto.

Questa è un’inversione rispetto alla prassi di settore, dove si offre una semplice chat. Quella va bene ma non esprime tutto il potenziale: l’AI può essere integrata anche in modo trasparente per l’utente, rafforzando l’esperienza senza che neanche se ne renda conto.

Hannah Clark: Cambiamo ancora argomento. Parliamo del cambiamento nella funzione del product manager: ora il PM si sposta dall’esecuzione pura a un ruolo molto più strategico.

Tu che guidato la trasformazione, come consiglieresti ai product leader di aiutare i PM ad adottare questi cambiamenti e skillset più radicali?

Michael Luchen: Qui ho una posizione netta che mantengo da tutta la carriera: un grande product manager deve saper tenere insieme strategia ed esecuzione. È una hot take, perché in molti dicono: se fai solo execution sei un project manager glorificato; se solo strategia, un mini CEO. Secondo me sono entrambe tossiche. È proprio il saperle bilanciare che fa la differenza.

Non è facile farlo, perché si pensa che siano in contrasto. Invece, come ho già condiviso, se parti da empatia e curiosità hai tutte le informazioni sul tavolo. Fai brainstorming, magari su Miro o FigJam insieme al team, trovi la via migliore per una esecuzione strategica ed efficace, che rispetta il tempo di tutti.

Per chi oggi lavora più nell’execution, il consiglio è di essere curioso sulle leve strategiche: quali opportunità tecniche i colleghi engineering vedono? Quali nuove pratiche portano il design? E tu, come product manager, cosa porti dai clienti e dal business? Integrare tutto queste prospettive permette di fondere execution e strategia.

Hannah Clark: Non è una hot take, secondo me. Anzi, è un ottimo spunto! Chiudiamo con una domanda più leggera e personale. Mi hai detto che stai facendo progetti AI col tuo figlio, che trovo bellissimo.

Ne abbiamo parlato anche nella nostra newsletter (iscrivetevi!), su come essere genitori cambia anche il modo di essere leader e product manager. In che modo la tua vita familiare ha orientato il tuo approccio alla leadership e alla trasformazione?

Michael Luchen: Cerco di lasciare che la vita privata e quella lavorativa si influenzino a vicenda. Dico di avere un buon work-life balance, ma la verità è che il mio lavoro è anche la mia passione.

Recentemente mio figlio (cinque anni e mezzo) è tornato da scuola dicendo: "Papà, costruiamo un videogioco ninja per la PlayStation!". Avrei potuto svicolare, ma invece ho deciso di fondere la mia sperimentazione lavorativa con lui. “Ok, useremo questa nuova tecnologia chiamata AI”.

Ho così portato in modo naturale il metodo prodotto: facciamoci venire delle idee, disegna il personaggio, pensa alle regole. Ha riempito pile di fogli di carta! Poi abbiamo discusso insieme come doveva essere il gioco, io ho registrato la conversazione, trascritto e passato a ChatGPT per far generare un documento di sviluppo e i primi concept, pensati per un developer junior.

Poi l’ho lavorato in Bolt, corretto il prompt e ottenuto un livello uno giocabile. Abbiamo fatto playtest e QA, lui mi segnala "qui non si sente l’audio, qui il controllo non va bene". Iteriamo. Miglioriamo finché vuole farlo vedere agli amici. Poi nuove idee: "facciamone un film 3D", e via con nuovi tool di AI.

Insomma: faccio product thinking con lui, che in fondo deriva dal metodo scientifico. Così provo a far convergere le due sfere ogni giorno.

Hannah Clark: È un esempio molto più profondo del solito! Di solito sento storie tipo: "Mi tocca convincerlo a mangiare verdura". Tu hai un bimbo con una specie di curriculum di sviluppo prodotto prima ancora di saper leggere! Complimenti!

Michael Luchen: Sì, ricordo che alla sua età sognavo di lavorare per Nintendo, leggevo riviste... Oggi ci si può semplicemente mettere e provare con questi strumenti. Bello davvero.

Hannah Clark: Grazie. È un esempio incredibile—e umiliante per altri genitori. Aggiornerò la mia lista di attività per giornate di pioggia!

Michael Luchen: Sì, è un’ottima attività.

Hannah Clark: Grazie mille per essere tornato, averci aggiornato e per questa chiacchierata davvero stimolante. Dove ti possono seguire le persone online?

Michael Luchen: Sì, potete visitare michaelluchen.com dove trovare tutti i link ai miei profili social. Mi piacerebbe collegarmi, scrivetemi senza problemi.

Hannah Clark: Grazie infinite, Michael.

Michael Luchen: Grazie Hannah, è stato fantastico essere di nuovo qui.

Hannah Clark: Grazie per averci ascoltato. Per altri approfondimenti, guide pratiche e strumenti recensioni, iscriviti alla newsletter su theproductmanager.com/subscribe. Puoi ascoltare altre conversazioni come questa iscrivendoti a The CPO Club ovunque tu ascolti i podcast.