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 era costruita su fondamenta sbagliate: date fisse, liste di funzionalità, e desideri degli stakeholder confezionati come un piano. Quando la realtà inevitabilmente diverge — una funzionalità impiega più tempo, un bisogno dei clienti cambia, un concorrente si muove — la roadmap diventa finzione, e i team smettono di guardarla.
Una roadmap che le persone seguono effettivamente non è un grafico di Gantt spacciato per strategia di prodotto. È un documento vivo che rappresenta il pensiero attuale migliore del team sull'ordine in cui i problemi dovrebbero essere risolti, strutturato per essere onesto su quello che è noto e quello 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é), forza la prioritizzazione (non possiamo fare tutto, quindi cosa viene prima), e crea una base per l'allineamento (in modo che ingegneria, design, vendite, e supporto stiano tutti lavorando verso gli stessi obiettivi).
Una roadmap non garantisce date di consegna. Non si impegna a funzionalità specifiche. E non sostituisce il bisogno di una scoperta continua. Se gli stakeholder trattano la roadmap come una promessa, quello è un problema di processo — non una ragione per costruire falsa precisione nel documento.
Il formato di roadmap più duraturo per la maggior parte dei team è il modello a tre orizzonti. È onesto sull'incertezza: gli elementi in "Ora" sono impegnati, gli elementi in "Prossimo" sono pianificati ma non bloccati, e gli elementi in "Più tardi" sono direzionalmente veri ma soggetti a cambiamenti mentre impari di più.
Nota che ogni elemento include non solo cosa sia, ma perché sia lì. Una roadmap senza razionale è solo una lista. Quando i membri del team capiscono perché ogni elemento era scelto, possono prendere decisioni migliori quando le cose cambiano — e possono avere conversazioni più produttive quando un cliente chiede qualcosa che non è sulla lista.
Le roadmap basate su funzionalità ("costruisci X, costruisci Y, costruisci Z") creano una dinamica pericolosa: il team spedisce le funzionalità e chiama fatto, anche se le funzionalità non muovono le metriche che dovevano muovere. La funzionalità era consegnata; il problema non era risolto.
Le roadmap basate su risultati riformulano ogni elemento come un obiettivo: "Riduci tempo-al-primo-valore 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 anche rende molto più facile deprioritizzare una funzionalità quando scopri un modo migliore di raggiungere lo stesso obiettivo.
Il product manager possiede la roadmap. Questo significa che è responsabile per il suo contenuto, i suoi aggiornamenti, e la sua comunicazione agli stakeholder. Ma proprietà non significa autorialità solitaria — le migliori roadmap sono costruite in collaborazione, con input da ingegneria (su fattibilità e sforzo), design (su implicazioni di esperienza utente), e team customer-facing (su segnale di mercato).
Quello che il PM dovrebbe resistere è progettare la roadmap per comitato. Gli stakeholder possono fornire input; non dovrebbero avere veto power su elementi individuali. Il PM sintetizza input e fa le chiamate. Se il processo per raggiungere quelle chiamate è di fiducia, gli output saranno pure.
La colonna "Ora" dovrebbe essere revisionata ogni sprint. La colonna "Prossimo" dovrebbe essere revisionata all'inizio di ogni trimestre, o ogni volta che prove significative nuove arrivano (un cliente maggiore abbandona, un concorrente lancia qualcosa di rilevante, uno sprint di scoperta produce un scoperta sorprendente). La colonna "Più tardi" ha bisogno di rivisitazione una volta ogni trimestre — non per raffinarla, ma per confermare che le scommesse direzionali abbiano ancora senso.
L'obiettivo è una roadmap che non sia mai vecchia abbastanza da essere imbarazzante, ma non aggiornata così frequentemente da creare ansia. La maggior parte dei team commettono l'errore di aggiornamento insufficiente — la roadmap riflette decisioni prese sei mesi fa e nessuno sa esattamente quando sia stata cambiata l'ultima volta.
La roadmap verrà seguita se — e solo se — il team si fida di essa. Quella fiducia viene da tre cose: il razionale per ogni elemento è visibile e solido, il team era coinvolto nella costruzione piuttosto che consegnato, e il PM l'aggiorna prontamente quando le circostanze cambiano piuttosto che fingere che il piano originale ancora vale.
Una roadmap che è trattata come uno strumento di negoziazione, o come un documento prodotto per soddisfare i dirigenti, sarà ignorata al livello del team e rissentita a livello di stakeholder. Una roadmap che riflette il pensiero genuino, i compromessi reali, e l'incertezza onesta diventerà uno strumento che le persone raggiungono — perché effettivamente li aiuta a decidere.