Ciao Donato, puoi raccontarci il tuo percorso? 

Il mio percorso nel product management è nato in modo naturale, anche se inizialmente ricoprivo il ruolo di project manager IT in General Electric a Torino, in un'epoca in cui il PM in Italia era ancora poco diffuso. Pur avendo un focus formale su tempi, costi e qualità, il mio approccio era già orientato al prodotto e al valore per gli stakeholder, una direzione confermata quando GE avviò una trasformazione interna per evolvere i project manager in product owner. 

In seguito sono passato in Intesa Sanpaolo, dove ho lavorato a fianco di product manager ricoprendo anche il ruolo di agile coach, per poi sentire il bisogno di un contesto più operativo e digitale. Mi sono poi spostato in una startup fintech finanziata da Intesa, dove sono stato il primo product manager. L’azienda contava circa 15 persone e sono rimasto lì quasi tre anni, assumendo ruoli di maggiore responsabilità man mano che il team cresceva.  

Successivamente ho trascorso circa un anno e mezzo in Amazon come individual contributor senior, per poi approdare in Treatwell: prima come senior product manager, oggi come head of product per l'area marketplace e payments. 

Spostandoci sullo Sketch perché hai scelto di parlarci di MOVE? È un framework che avete creato voi? 

Il framework MOVE è stato introdotto in Treatwell dal mio attuale responsabile, ma si è rivelato uno strumento estremamente efficace per affrontare una fase specifica dell’evoluzione dell’azienda. 

Come molte organizzazioni in crescita, anche noi abbiamo attraversato diverse fasi metodologiche. Inizialmente lavoravamo con Scrum, poi siamo passati a Scrumban per guadagnare maggiore flessibilità. A un certo punto, però, ci siamo resi conto che ​non avevamo il giusto bilanciamento per imparare velocemente e rispondere ai bisogni dei clienti​​.

Nelle fasi iniziali di un’azienda si lavora spesso per output: in una logica 0-1, molte cose funzionano rapidamente e non è ancora fondamentale misurare tutto in modo sofisticato. Quando però inizi a scalare, il contesto cambia radicalmente. I team crescono, l’inerzia aumenta e ottenere anche piccoli miglioramenti incrementali diventa sempre più complesso. 

È in questa fase che diventa essenziale passare da una logica di output a una logica di outcome. MOVE nasce proprio per supportare questo cambiamento: aiuta i team a partire dagli obiettivi e a costruire il lavoro attorno al valore da generare, piuttosto che sulle feature da consegnare. 

Un concetto chiave che accompagna MOVE è quello di ragionare come un investitore. Significa chiedersi continuamente come massimizzare il ritorno rispetto al costo del team, rafforzando ownership e senso di responsabilità. 

A questo si aggiunge l’abbandono delle roadmap tradizionali a favore di un approccio più flessibile basato su now, next, later, che ci permette di adattarci rapidamente a ciò che impariamo lungo il percorso. 

Entrando più nel concreto: come funziona la vostra roadmap?

La nostra roadmap è costruita con un approccio now/next e viene definita insieme agli stakeholder, accettando esplicitamente un certo grado di incertezza. 

Non lavoriamo con milestones rigide, perché nella maggior parte dei casi non sono realistiche. Ciò che possiamo fare, invece, è allinearci costantemente sulle priorità e adattare la direzione in base a ciò che apprendiamo. 

Questo approccio ha due grandi benefici: aumenta il coinvolgimento degli stakeholder e riduce il rischio di “wishful thinking”, tipico delle roadmap tradizionali basate su scadenze poco realistiche. 

Dal punto di vista operativo, le iniziative vengono scomposte in unità molto piccole, con l’obiettivo di ottenere segnali rapidamente. Se dobbiamo validare una soluzione tecnica, ad esempio, preferiamo costruire un proof of concept in una settimana piuttosto che investire subito in uno sviluppo lungo. Se il segnale è positivo, si prosegue; altrimenti si cambia direzione. 

Come avete convinto gli stakeholder a cambiare approccio sulla roadmap? 

È stato un percorso graduale. Siamo passati da roadmap basate su Gantt agli OKR, mantenendo inizialmente una pianificazione piuttosto rigida. In una fase successiva abbiamo eliminato le date, poi anche il concetto stesso di commitment trimestrale. 

La svolta è arrivata quando ci siamo resi conto, insieme, che le pianificazioni venivano raramente rispettate e che il focus era spesso sugli output, non sugli outcome. 

Oggi ogni iniziativa è collegata esplicitamente a un OKR e a un outcome misurabile. Tutto ciò che entra nel now e nel next ha un legame diretto con una metrica da muovere. Le iniziative non sono più raccontate come attività, ma come impatto atteso. Questo ha reso il valore del nuovo approccio molto più comprensibile anche per gli stakeholder. 

Puoi spiegare MOVE a qualcuno che non conosce il product management? 

MOVE parte da una presa di consapevolezza fondamentale: il lavoro di sviluppo e di risoluzione dei problemi dei clienti è basato su assunzioni. 

Nel software, la complessità emerge mentre lavori. È un po’ come ristrutturare casa: puoi pianificare, ma scoprirai i problemi strada facendo. Accettare l’incertezza è quindi il primo passo, e probabilmente il più importante. 

Se partiamo dal presupposto che non abbiamo tutte le informazioni, tutto il resto diventa più chiaro: dobbiamo capire come raccoglierle nel modo più rapido possibile e validare le ipotesi prima di investire troppo. 

MOVE è proprio questo: un modo strutturato per muoversi nell’incertezza, imparare velocemente e decidere sulla base di segnali reali. 

Come definite il goal di una MOVE? 

Ogni MOVE parte da un goal chiaro, espresso in termini di outcome. Da lì si identificano le riskiest assumptions, ovvero le ipotesi più rischiose che, se sbagliate, renderebbero inutile tutto il resto. 

L’approccio è testare prima queste ipotesi nel modo più rapido ed economico possibile, utilizzando segnali semplici e metriche intermedie. Se il segnale non è positivo, ci si ferma subito evitando sprechi. 

Quindi le MOVE sono simili agli experiment dell’Opportunity Solution Tree? 

L’Opportunity Solution Tree è lo strumento che utilizziamo a monte, per strutturare il problema e le soluzioni. Le MOVE rappresentano invece il livello operativo: sono il modo in cui agiamo e iteriamo rapidamente. 

In sintesi, l’Opportunity Solution Tree guida il pensiero; le MOVE guidano l’azione. Funzionano davvero solo in un contesto in cui il team si sente responsabile dell’impatto nel tempo. 

Quali sono gli step di una MOVE? 

Una MOVE segue un ciclo semplice: ipotesi, esperimento, misurazione e decisione. 

Si parte dalla riskiest assumption, si costruisce un esperimento rapido e si osservano i risultati. Se l’ipotesi è confermata, si passa allo step successivo; se non lo è, si analizza cosa non ha funzionato e si itera. 

Questo ciclo continua per un numero limitato di tentativi. Quando l’impatto atteso non giustifica più l’effort, si interrompe l’iniziativa e si riallocano le energie. 

Avete avuto casi di fallimento? 

Il fallimento è parte integrante del processo. Un esempio riguarda il lavoro sulla ricerca dei saloni e sul miglioramento del conversion rate. 

Dopo alcuni miglioramenti iniziali, abbiamo testato soluzioni più complesse che non hanno portato risultati significativi, nonostante diverse iterazioni. A quel punto abbiamo deciso di fermarci. 

Non è stato un errore: semplicemente, mancava una comprensione più profonda del problema. Il fallimento, in questo senso, è stato un segnale utile per cambiare focus. 

Quante persone sono coinvolte in una MOVE? 

Una MOVE coinvolge l’intero team cross-funzionale: product manager, designer ed engineer, allineati su un unico goal. 

Anche quando emergono fasi di disallineamento operativo, la priorità rimane sempre l’obiettivo della MOVE, con tutte le altre attività chiaramente subordinate. 

La durata di una MOVE è stimata o emerge nel tempo? 

Esiste una stima iniziale, basata sul livello di conoscenza del team, ma parliamo sempre di orizzonti brevi, tipicamente da qualche giorno a un paio di settimane. 

L’obiettivo non è la precisione assoluta, ma avere una direzione sufficientemente affidabile e adattarsi strada facendo. 

Siamo arrivati alla nostra ultima domanda: Se avessi una bacchetta magica, cosa miglioreresti di MOVE? 

Lavorerei sull’allineamento con le funzioni esterne al mondo product e tech, come il marketing. In questi contesti, spesso guidati da scadenze e pianificazioni rigide, è più complesso applicare un approccio iterativo. 

La sfida futura è trovare un equilibrio che permetta di estendere i principi delle MOVE anche a questi ambiti, senza comprometterne l’efficacia. 

Takeaway 

• Passare dagli output agli outcome  

Il successo non si misura in feature rilasciate. Ogni iniziativa deve essere legata a una metrica da muovere, altrimenti si produce lavoro, non valore. 

• Testare prima le ipotesi più rischiose. 

Prima di investire in sviluppo, vale la pena identificare l'assunzione che, se sbagliata, renderebbe inutile tutto il resto. Validarla nel modo più rapido ed economico possibile, poi decidere se andare avanti. 

• Abbandonare le date, non le priorità  

Le roadmap con scadenze rigide generano wishful thinking. Allinearsi costantemente sulle priorità - accettando esplicitamente l'incertezza - produce più valore e più fiducia tra gli stakeholder.