La maggior parte delle roadmap di prodotto vengono abbandonate entro un trimestre dalla loro stesura. Non perché i team non siano disciplinati, ma perché la roadmap è stata costruita su fondamenta sbagliate: date fisse, elenchi di funzionalità e desideri degli stakeholder spacciati per un piano. Quando la realtà inevitabilmente diverge — una funzionalità impiega più tempo, un'esigenza dei clienti cambia, un concorrente si muove — la roadmap diventa finzione e i team smettono di guardarla.
Una roadmap che le persone seguono davvero non è un diagramma di Gantt travestito da strategia di prodotto. È un documento vivo che rappresenta le migliori valutazioni attuali del team sull'ordine in cui i problemi dovrebbero essere risolti, strutturato in modo da essere onesto su ciò che è noto e ciò che non lo è.
Prima di progettare una roadmap, vale la pena essere chiari sul suo scopo. Una roadmap fa tre cose: comunica la direzione (dove stiamo andando e perché), impone di stabilire le priorità (non possiamo fare tutto: cosa viene prima?), e crea una base per l'allineamento (in modo che ingegneria, design, vendite e supporto lavorino tutti verso gli stessi obiettivi).
Una roadmap non garantisce date di rilascio. Non si impegna su funzionalità specifiche. E non sostituisce la necessità di una discovery continua. Se gli stakeholder trattano la roadmap come una promessa, quello è un problema di processo — non un motivo per inserire nel documento una falsa precisione.
Il formato di roadmap più duraturo per la maggior parte dei team è il modello a tre orizzonti. È onesto sull'incertezza: le voci in "Ora" sono confermate, quelle in "Prossimo" sono pianificate ma non vincolanti, e quelle in "Più tardi" indicano una direzione ma possono cambiare man mano che impari di più.
Nota che ogni voce indica non solo cosa sia, ma anche perché si trovi lì. Una roadmap senza motivazioni è solo un elenco. Quando i membri del team capiscono perché ogni voce è stata scelta, possono prendere decisioni migliori quando le cose cambiano — e possono avere conversazioni più produttive quando un cliente chiede qualcosa che non è nell'elenco.
Le roadmap basate su funzionalità ("costruisci X, costruisci Y, costruisci Z") creano una dinamica pericolosa: il team rilascia le funzionalità e lo considera concluso, anche se le funzionalità non muovono le metriche che dovevano muovere. La funzionalità è stata rilasciata; il problema non è stato risolto.
Le roadmap basate su risultati riformulano ogni elemento come un obiettivo: "Riduci il time-to-first-value per i nuovi utenti da 4 giorni a meno di 24 ore." Il team può quindi decidere — e rivisitare — come raggiungere quell'obiettivo. Questa struttura rende anche molto più facile togliere priorità a una funzionalità quando scopri un modo migliore per raggiungere lo stesso obiettivo.
La roadmap è responsabilità del product manager. Questo significa che risponde del suo contenuto, i suoi aggiornamenti, e la sua comunicazione agli stakeholder. Ma avere la responsabilità non significa scrivere tutto da soli — le migliori roadmap sono costruite in collaborazione, con il contributo dell'ingegneria (su fattibilità e sforzo), design (sulle implicazioni per l'esperienza utente), e team customer-facing (sui segnali dal mercato).
Ciò a cui il PM deve resistere è progettare la roadmap per comitato. Gli stakeholder possono fornire input; non dovrebbero avere potere di veto sulle singole voci. Il PM sintetizza input e prende le decisioni. Se il processo con cui si arriva a quelle decisioni gode di fiducia, ne godranno anche i risultati.
La colonna "Ora" dovrebbe essere rivista a ogni sprint. La colonna "Prossimo" dovrebbe essere rivista all'inizio di ogni trimestre, o ogni volta che emergono nuove evidenze significative (un cliente importante se ne va, un concorrente lancia qualcosa di rilevante, uno sprint di discovery produce un risultato sorprendente). La colonna "Più tardi" va rivista una volta a trimestre — non per affinarla, ma per confermare che le scommesse di direzione abbiano ancora senso.
L'obiettivo è una roadmap che non sia mai così vecchia da risultare imbarazzante, ma nemmeno aggiornata così spesso da creare ansia. La maggior parte dei team tende a sbagliare per difetto, aggiornando troppo poco — la roadmap riflette decisioni prese sei mesi prima e nessuno sa esattamente quando sia stata cambiata l'ultima volta.
La roadmap verrà seguita se — e solo se — il team si fida. Questa fiducia nasce da tre cose: le motivazioni di ogni voce sono visibili e solide, il team è stato coinvolto nella costruzione invece di riceverla già pronta, e il PM l'aggiorna prontamente quando le circostanze cambiano invece di fingere che il piano originale sia ancora valido.
Una roadmap che viene trattata come uno strumento di negoziazione, o come un documento prodotto per soddisfare i dirigenti, sarà ignorata a livello di team e malvista a livello di stakeholder. Una roadmap che riflette un pensiero autentico, compromessi reali e un'incertezza onesta diventerà uno strumento a cui le persone ricorrono — perché le aiuta davvero a decidere.