Come si è evoluta la tua carriera fino al ruolo di Product Manager in HYPE? 

Il mio percorso ha inizio con una laurea triennale in Economia e Statistica e successivamente una magistrale in Direzione d’Impresa e Marketing a Torino. Durante gli anni universitari ho avuto una breve esperienza in una startup, Foodora, dove mi occupavo principalmente di attività di data entry. 

Dopo la laurea sono entrato nel settore bancario. In quel contesto svolgevo attività molto vicine al product management, anche se all’interno di una grande organizzazione la figura del Product Manager, almeno all’epoca, non era ancora formalmente definita. In particolare, il mio ruolo era quello di business analyst su uno specifico prodotto: l’onboarding dei conti online.  

Dopo circa due anni sentivo che era il momento di fare un passo verso qualcosa di più innovativo. In quei mesi stava nascendo un progetto che in Italia non si era ancora visto: un modo completamente nuovo di immaginare il rapporto tra persone, tecnologia e servizi finanziari. 

E parlo proprio di HYPE; dove ormai lavoro da più di 5 anni. Quando entrai in HYPE, il mio ruolo non era ancora quello di Product Manager. In quel periodo l’area Product stava prendendo forma: un team nascente, costruito attorno a nuove competenze e a una visione che stava iniziando a definirsi proprio allora. 

Era una fase di avvio.  

Ho iniziato quindi come Project Manager, ma di fatto il ruolo aveva molte responsabilità simili a quelle di un Product Owner: coordinavo il team e seguivo lo sviluppo delle iniziative di prodotto. Con la crescita dell’azienda e la strutturazione dell’area prodotto, sono poi entrato formalmente nel team di Product Management. Oggi seguo diversi Product Manager che lavorano su varie aree aziendali. 

Il passaggio da Project Manager a Product Manager è stato guidato principalmente da esigenze organizzative oppure è nato anche da una tua scelta di crescita verso il product? 

È stato il risultato di una combinazione di fattori. All’inizio naturalmente HYPE stava ancora prendendo forma e i ruoli non erano ancora definiti in modo preciso. Era un momento in cui serviva flessibilità, perché si stava costruendo un modello nuovo e tutto si evolveva molto velocemente. 

Con il tempo, però, la crescita è stata importante: siamo passati da circa 50 a 200 persone, e questo ha portato naturalmente a strutturare meglio responsabilità, processi e modalità di lavoro. 

Oggi, ad esempio, la gestione degli aspetti metodologici e dei processi è affidata agli Scrum Master, che supportano i diversi team, mentre ciascun team dispone di una figura di prodotto dedicata. 

Le figure di Project Manager esistono ancora, ma sono generalmente coinvolte in progetti di natura più tecnica o infrastrutturale, come ad esempio migrazioni IT. 

Nello sketch hai scelto di parlare di post-launch management: perché proprio questo tema? 

Ho scelto questo tema perché spesso il lancio di una nuova funzionalità viene percepito come il momento conclusivo del lavoro sul prodotto. In realtà, la fase successiva al go-live è altrettanto cruciale e dovrebbe essere pianificata già durante la fase di discovery. 

Quando si parla di metriche analytics, infatti, la domanda “come sta andando il prodotto?” tende ad emergere solo dopo il lancio. Se però non si è riflettuto in anticipo su quali dati raccogliere e quali metriche monitorare, si rischia di non avere le informazioni necessarie per valutare realmente le performance della funzionalità. 

In HYPE, ad esempio, tutte le funzionalità vengono sviluppate direttamente all’interno dell’app, che è il nostro canale principale. Proprio per questo per noi è fondamentale definire fin da subito cosa tracciare. Bisogna quindi preparare bene i dati che guideranno le analisi future, altrimenti si rischia di limitarsi a dati molto superficiali, come il numero di utenti che aprono una funzionalità o completano un’azione. Questo però non consente di avere una visione completa del customer journey. Di conseguenza diventa più difficile capire se eventuali problemi derivino dall’esperienza utente oppure da aspetti tecnici. 

Come gestite la parte di analytics all’interno dei team di prodotto?  

In HYPE abbiamo un team dedicato che supporta i Product Manager nella definizione dei punti di tracciamento. Ogni user flow ha infatti caratteristiche specifiche, che possono richiedere metriche ad hoc, oltre che standard (come active users e conversion rate). 

Per la raccolta dei dati utilizziamo una piattaforma di analytics chiamata Mixpanel, che consente di tracciare diversi eventi all’interno dell’app, come la visualizzazione di una pagina, i click o il completamento di determinate azioni. 

Accanto ai dati quantitativi monitoriamo anche informazioni di carattere qualitativo, coinvolgendo direttamente gli utenti nella raccolta del feedback. Successivamente, i dati quantitativi e qualitativi vengono sintetizzati e analizzati insieme. Per supportare questo processo utilizziamo anche uno strumento interno basato su intelligenza artificiale, che aggrega diverse fonti di informazione: metriche dall'app, NPS (Net Promoter Score), le recensioni pubblicate sugli store. In questo modo possiamo concentrarci sia sui dubbi e sulle ipotesi che avevamo prima del lancio, sia su eventuali nuove evidenze che emergono dopo il go-live. 

Nella prima parte dello sketch hai evidenziato tre elementi: puoi spiegarci quali sono e che ruolo hanno? 

Nella prima parte dello sketch ho identificato tre stream principali: comunicazione, documentazione e retrospettiva, tutti elementi fondamentali. La comunicazione può essere interna o esterna. Per la comunicazione interna, il Product Manager si assicura che tutte le funzioni coinvolte - customer care, legal, compliance e privacy - siano aggiornate sul lancio della funzionalità. Per farlo utilizziamo strumenti che mostrano la roadmap di prodotto a 3-6 mesi e tengono traccia dei rilasci dell’applicazione, con una sorta di release journal che mantiene tutta l’azienda allineata. La comunicazione esterna, invece, passa dal marketing e fa parte a tutti gli effetti del go‑to‑market. In questa fase il Product Manager ha un ruolo chiave: è la persona che aiuta a raccontare la funzionalità nel modo giusto, evidenziando cosa è davvero importante per i clienti, oltre a gestire il rilascio sugli store. La documentazione serve a lasciare traccia delle funzionalità per il futuro. All’inizio è capitato che alcune funzionalità non fossero descritte in modo adeguato; quindi, oggi il Product Manager redige la documentazione insieme ai team di design ed engineering. Ci sono due tipologie principali: la documentazione di prodotto, che descrive il funzionamento del flusso, i comportamenti attesi e i corner case, e la documentazione regolatoria, richiesta dai team di sicurezza, risk o finance a seconda della tipologia di funzionalità. 

Infine, la retrospettiva e la revisione della roadmap permettono, dopo il lancio, di ragionare sui dati e i feedback raccolti per valutare eventuali miglioramenti e aggiornare la roadmap di prodotto. 

 Ci fai un esempio di una feature che avete lanciato e le relative metriche che avete deciso di monitorare? 

Vi porto l'esempio di Split Hype, una funzionalità che permette la divisione delle spese all'interno di un gruppo. Per questa feature monitoriamo quanti gruppi vengono creati, quanti includono utenti non clienti e quale modalità di invito viene utilizzata.  

Durante la fase di discovery ci eravamo chiesti se rendere la funzionalità disponibile solo ai clienti o anche ad utenti esterni. Ora, grazie al monitoraggio dei dati post-lancio, possiamo valutare se la scelta di aprirla anche ai non clienti sia stata efficace. Spoiler: Lo è stata! 

Le nuove iniziative di prodotto nascono principalmente da obiettivi di business o dalle esigenze dei clienti? Puoi fare un esempio? 

In realtà è quasi sempre un mix dei due. La maggior parte delle idee parte dalle esigenze dei clienti, che raccogliamo continuamente attraverso ricerche e feedback, e poi vengono prioritizzate in base all’impatto e alla fattibilità. 

Prendendo di nuovo Split Hype come esempio: tutto è nato da un problema reale: dividere le spese tra amici, coinquilini o coppie. A questa esigenza concreta si è affiancato un obiettivo di business chiaro, cioè aumentare l’utilizzo dell’app e il numero di transazioni. 

Ogni idea, prima di essere sviluppata, viene anche valutata dal punto di vista finanziario e del business case. Poi, dopo il lancio, monitoriamo i dati per capire se le previsioni iniziali si confermano. 

Per chiudere il cerchio: come funziona la revisione della roadmap? 

Dopo il lancio raccogliamo feedback e dati e possiamo decidere di inserire miglioramenti in roadmap. È complesso perché la roadmap è già pianificata, ma le decisioni si basano su dati, richieste clienti e obiettivi di business. 

Oggi lavoriamo con una roadmap che resta flessibile per circa il 70%, e questa è una delle nostre forze: ci permette di muoverci velocemente, adattarci ai cambiamenti e cogliere nuove opportunità senza perdere di vista le priorità strategiche. Nell’ultimo anno abbiamo lavorato molto per spostare l’attenzione sempre di più sugli obiettivi di prodotto piuttosto che sulle singole funzionalità da sviluppare. In generale esiste una roadmap annuale ad alto livello che indica le principali aree di lavoro, ma è volutamente flessibile. 

Le decisioni sono sempre guidate dai dati, dalle richieste dei clienti e dagli obiettivi di business. L’obiettivo della roadmap, infatti, non è tanto descrivere nel dettaglio quali funzionalità verranno sviluppate, ma definire gli obiettivi dei team in termini di outcome. All’inizio dell’anno si ipotizzano alcune iniziative, ma poi i team hanno la libertà di adattarle durante l’anno in base a ciò che emerge nella fase di discovery e dai dati raccolti dopo il lancio. L’aspetto più importante non è tanto cosa si sviluppa, ma il risultato che si riesce a ottenere. 

Arriviamo alla nostra solita e ultima domanda: se avessi una bacchetta magica, cosa cambieresti del processo di Post-Launch Management? 

Migliorerei soprattutto i tempi. La difficoltà principale sta nel riuscire a svolgere tutte queste attività nel momento giusto e con la giusta velocità. 

Sarebbe utile avere uno strumento che permetta di ridurre il tempo dedicato alle analisi manuali dei dati, alla raccolta delle interviste e alla sintesi delle informazioni. In questo modo si potrebbe accelerare il processo di comprensione dei risultati e arrivare più rapidamente alle risposte necessarie per decidere i passi successivi. 

Takeaway 

• Il lavoro sul prodotto non finisce con il lancio  Il go-live non rappresenta la fine del processo di sviluppo: la fase di post-launch è fondamentale per analizzare dati, raccogliere feedback e migliorare continuamente la funzionalità. 

• Il monitoraggio va progettato già in fase di discovery  Definire in anticipo cosa tracciare è essenziale. Senza una strategia di analytics chiara si rischia di raccogliere solo dati superficiali e non comprendere davvero il comportamento degli utenti. 

• Le iniziative di prodotto nascono dall’incontro tra bisogni degli utenti e obiettivi di business Le idee partono spesso da problemi reali dei clienti, ma vengono validate anche attraverso analisi di impatto e business case.