Che tu sappia già il significato di questa parola o la senti oggi per la prima volta, una cosa è certa: approfondire cosa sia una Product Roadmap e farne un buon uso fa sempre la differenza. Questo è infatti il classico strumento amico, un supporto che una volta integrato alla tua quotidianità non ne uscirà più. Ma andiamo a capire insieme innanzitutto di cosa si tratta.
La Product Roadmap di un prodotto è un piano di azione, una tabella di marcia per delineare come in un arco temporale il prodotto evolverà (il mix delle due parole può essere traducibile come “mappa del viaggio”, intendendo per viaggio la nascita e sviluppo nel tempo del tuo prodotto). Come afferma Janna Bastow, la Product Roadmap è un prototipo della tua strategia: un test basato su una direzione strategica ma flessibile e riformulabile in base a nuove necessità.
Ma andiamo più nel dettaglio a capire come si costruisce la Product Roadmap.
La Roadmap non va assolutamente confusa con una semplice lista della spesa di funzionalità da rilasciare in relazione al prodotto ma deve essere costruita secondo gli outcome che andranno a risolvere, in ordine di priorità, i problemi del customer. Possiamo immaginare questa struttura:
Realizzata dal Product Manager, per avere la sua efficacia deve essere condivisa con il team, il Project Manager e gli stessi stakeholder.
La Product Roadmap si basa su goal e misurazioni precise, che con immediata chiarezza allineano quindi tutte le figure e le risorse coinvolte nel prodotto.
Il Product Manager utilizza la Product Roadmap per esempio per delineare le funzionalità e quando queste dovranno essere rilasciate nel tempo in base agli obiettivi. Il Product può decidere di rilasciare nella prima release certe funzionalità spostandone altre nella successiva, proprio perché riesce ad avere con questo strumento ben chiaro il quadro della situazione).
Nella costruzione della Product Roadmap si deve assolutamente tener presente che questa deve contenere:
1. Identità e visione del prodotto
2. Strategia del prodotto (product strategy)
3. Outcome e obiettivi di business
4. Temi e iniziative
5. Dipendenze
6. Orizzonte temporale
Quindi si definisce l’identità del prodotto e la sua visione a lungo termine: cos’è e dove questo deve essere diffuso. Con la strategia del prodotto andiamo invece a spiegare come il prodotto stesso arriverà a realizzare la visione. Altro punto che non può mancare (n.3) nella Product Roadmap riguarda gli outcome, ovvero il valore del prodotto generato per il cliente.
Gli outcome sono definiti in relazione a delle aree del prodotto legate a dei temi e a dei sotto temi. Ogni tema si focalizza su un problema da risolvere e quindi una necessità da soddisfare per il vostro user. In tal senso il team si porrà una serie di domande come quali sono le priorità da risolvere legate a un tema, quali attività vincolano altre attività, quale sarà lo spazio di tempo in cui andremo a lavorare, ad esempio.
La roadmap si organizza su un orizzonte temporale stabilito liberamente dal product manager e condiviso con il team. Può avere una cadenza mensile o andare a coprire periodi più lunghi come un intero semestre ad esempio o ancora scandirsi secondo altri criteri come Now - Next - Later. Prevedere con esattezza cosa accadrà a lungo termine non è possibile, in quanto ciò che verrà sarà determinato dalle azioni e dai risultati dei mesi precedenti ma si può andare a lavorare nei macrotemi e in quello che mi aspetto in tal senso.
Altro punto della Product Roadmap sono le dipendenze: dipendenze strategiche che avvalorano il prodotto in relazione al tempo di rilascio o dipendenze esecutive che creano sempre valore al prodotto ma solo se legate a determinati outcome o determinati clienti.
Cosa non deve assolutamente contenere la Product Roadmap?
Innanzitutto la Product Roadmap non deve contenere le date e le scadenze: tutto ciò viene gestito dal Project Manager nel Project Plan, dove vengono inseriti i singoli task con relative date di scadenza. Quindi come già affermato nei precedenti post, l’attività del
Product Manager si focalizza sul cosa e perché, mentre quella del Project Manager sul come e quando.
La Product Roadmap non deve contenere gli output, ovvero quell’insieme di attività prodotte da una persona o da uno strumento per raggiungere gli obiettivi legati al progetto. A differenza degli outcome, gli output sono tangibili e facilmente misurabili e possono essere monitorati da chi gestisce il progetto. Ma attenzione il cosa non è il perché: gli output sono ciò che realizziamo per il cliente, gli outcome sono il risultato prodotto, l'effetto che quella funzionalità, quel prodotto o quel servizio generano per il cliente.
(Esempio
Scenario: una pizzeria che produce pizze gourmet.
Output: pizza gourmet. Possiamo misurare gli output misurando il numero di clienti che ogni sera vengono serviti e il numero di pizze che ogni sera vengono sfornate.
Outcome: è l’effetto che il prodotto ha sul cliente, in questo caso la qualità percepita della pizza).
Product Roadmap VS diagramma di Gantt.
Il diagramma di Gantt è uno strumento di supporto alla gestione di progetti e si sviluppa su un’asse orizzontale e una verticale: il risultato finale è un grafico a barre.
Strutturato come un diagramma cartesiano predispone nelle ascisse la scala temporale e nelle ordinate le attività da fare per portare a compimento il progetto. Il tempo per svolgere ogni task è rappresentato visivamente con una barra colorata che include la data di inizio e fine dell’attività. Quindi guardando il diagramma si vedono tutte le cose da fare, quali prima e quali dopo, quali da svolgere in contemporanea, quali sono legate da dipendenze, quali vanno svolte in sequenza (una dopo l’altra) o possono invece essere svolte in parallelo. Guardando il diagramma di Gantt è possibile individuare i vincoli, le attività più complesse che potrebbero condizionare il progetto per tempo e complessità, capire immediatamente i legami di dipendenza tra le attività. Rispetto alla Product Roadmap scende maggiormente nel dettaglio ed è più difficile da leggere per i non addetti ai lavori. La Product Roadmap è infatti più flessibile ed è una tabella di marcia ideale per essere condivisa anche con gli stakeholder piuttosto che persone non direttamente interne al team.