Come definire una Product Roadmap.

In questo post scoprirai come creare una Product Roadmap partendo da zero. Imparerai gli errori tipici in cui si rischia di incorrere e le scorciatoie per evitarli.

La prima volta che mi é stato chiesto di organizzare un workshop sulla Product Roadmap ho pensato: facile! 

In realtà, il percorso non é stato così semplice come io avevo previsto in quanto ho avuto difficoltà a reperire materiale interessante su cui costruire casi che meritassero la nostra attenzione.

Ecco cosa troverai in questo post:

  1. Cosa è la Product Roadmap?
  2. Cosa NON deve contenere una Product Roadmap?
  3. Cosa deve contenere una Product Roadmap?
  4. Un esempio di Product Roadmap

1. Cosa è la Product Roadmap?

Prima di addentrarci nello specifico dell’articolo, vorrei soffermarmi brevemente sulla parola “roadmap” e fare un riflessione sul significato di road=viaggio in senso allargato, e map=mappa. Quindi, unendo i due concetti la roadmap risulta una mappa del viaggio – fantastico, no? 
Bene, prepariamoci al nostro viaggio e partiamo subito con la definizione di roadmap che prediligo: 

“The roadmap is a prototype for your strategy” Janna Bastow

Ora analizziamo le due keyword:

1) Prototype: inteso come test, processo di apprendimento ed evoluzione che richiede flessibilità dato che può essere modificato sulla base di nuove esigenze.

2) Strategy: intesa come stato di intenti e direzioni.
Aggiungerei a questa definizione altri due ulteriori elementi quali insoddisfazione e promesse dato che talvolta é successo di vedere espressioni di delusione quando un progetto ritenuto prioritario veniva disatteso o posticipato.

Quindi, la roadmap oltre ad essere un prototipo della strategia é anche un insieme di aspettative che può essere gestito efficacemente con diverse tecniche di comunicazione e allineamento degli obiettivi e deve creare valore, rispondendo alle seguenti domande:
1) Quale problema il tuo team vuole risolvere?
2) Perché ti focalizzi su queste priorità?

Ora costruiamo questo tool che aiuta a comunicare la strategia identificando gli elementi da inserire e quelli che non devono essere assolutamente presenti, quali output e date. Partiamo da quest’ultimi.

2. Cosa NON deve contenere una Product Roadmap?

Output Vs Outcome & Business Objective

La roadmap non deve essere una lista di funzionalitá – per intenderci una lista della spesa – ma deve contenere gli outcome destinati a risolvere i problemi dell’utente – la pietanza che prepareremo con gli ingredienti acquistati – in quanto i benefici che si traggono sono:
1) creazione del valore per il cliente;
2) allineamento di aspettative e attivitá interfunzionali;
3) indipendenza e libertá di definizione dell’iter progettuale ed esecutivo finalizzato a raggiungere gli obiettivi prefissati.

Prima di passare al secondo elemento, rispolveriamo brevemente la differenza tra outcome e output:

  • l’outcome é il risultato o l’effetto di una azione o situazione, ad esempio, mettere in sicurezza il proprio bambino quando é in auto. Ricordiamo che l’outcome risulta più efficace se influenza il comportamento di un individuo e che si differenzia del business objective dal fatto che deve essere S.M.A.R.T. (specifico, misurabile, raggiungibile, realistico e legato al tempo).
  • l’output é un insieme di attività prodotte da una persona o un macchinario e, riallacciandoci all’esempio precedente, l’output sarà il seggiolino dell’auto.

Se vuoi approfondire abbiamo scritto un post dedicato alla differenza tra Output e Outcome.

Date

La roadmap non é un documento di scadenze in quanto questo compito viene svolto dal project plan (vedi esempio) dove vengono dettagliatamente elencate le single attività con relative date di completamento. Quindi, il project plan si focalizza sul How & When e la roadmap sul What & Why.

Gantt Chart

Continuiamo la nostra analisi descrivendo gli elementi che devono essere presenti in una roadmap:

3. Cosa deve contenere una Product Roadmap?

Product Vision & Strategy


Con Product Vision intendiamo una visione di lungo periodo che risponde alla semplice domanda: in x anni, dove voglio vedere il mio prodotto?

La Product Strategy, invece, spiega come raggiungere la visione indicando la direzione da percorrere.

Se dovessimo incorporare la Product Vision & Strategy nel nostro processo di definizione della roadmap, troveremmo entrambe dopo la Company Vision e prima della definizione degli outcome.

Temi & Iniziative


I temi sono aree di prodotto su cui vengono definiti gli outcome e le iniziative sono dei sotto-temi. Qui di seguito un esempio:

1) Tema: new users should understand the sign-up value.
2) Iniziativa 1: improve onboarding tutorial.
3) Iniziativa 2: using social proof in the form of testimonials.

Mi raccomando: ogni tema si deve focalizzare su un problema e/o bisogno da soddisfare quindi migliore é la conoscenza del vostro utente, maggiore sará la probabilità di sviluppare soluzioni di successo.

Orizzonte temporale


L’orizzonte temporale su cui costruire la roadmap può essere a cadenza mensile, trimestrale e semestrale oppure può essere definito con altri criteri quali, ad esempio, Now, Next & Later – opzione che prediligo.

Quindi, massima libertà di scelta sulla definizione dell’arco temporale con la piccola condizione che, nel lungo periodo, vengano definiti solo i macrotemi in quanto nel processo di roadmapping non si può definire con esattezza cosa accadrà tra 6/12 mesi dato che le decisioni future dipenderanno anche dai risultati e informazioni consolidate durante i mesi precedenti. Quindi, reputo una perdita di tempo spendere troppe energie nel definire con precisione cosa accadrà nel lungo periodo e invito a focalizzarsi sui primi 3/6 mesi.

Dipendenze


Ho identificato due tipologie di dipendenze di prodotto:
1) Strategica;
2) Esecutiva.

La prima si riferisce al modo in cui vengono lanciati i prodotti al fine di creare valore, ad esempio, ricevere una torta il giorno dopo la data del proprio compleanno non ha lo stesso valore che riceverla il giorno stesso, giusto?

La seconda dipendenza é, invece, un insieme di azioni che sono fondamentali per il rilascio del valore come, ad esempio, quella tecnologica dove moduli interconnessi devono essere predisposti o adattati al nuovo rilascio.

Tip: per identificare le dipendenze di prodotto vi suggerisco di porvi le seguenti domande:
1) Questa dipendenza crea un valore connesso ad un outcome definito?
2) Questa dipendenza crea valore solo per un cliente o per più clienti?
3) Cosa implica focalizzarsi su questa dipendenza (costo-opportunità)?

4. Un esempio di Product Roadmap

Ora condivido un esempio di roadmap in cui l’arco temporale si articola su 3 periodi quali Now, Next & Later, e contiene alcuni elementi sopracitati.

Fonte: https://www.prodpad.com/

2 replies on “ Come definire una Product Roadmap. ”
  1. Io la vedo in maniera leggermente diversa, nella mia idea la roadmap deve avere le idee un po’ più chiare sul cosa si farà.
    Per un OKR mi sta bene dire miglioriamo questa metrica del x%. Come? Lo decideremo dopo aver fatto esperimenti ed analizzato le opportunità.
    La roadmap, quantomeno quella che qui si definisce come Now, deve dire cosa vuoi fare nello specifico per dare valore ai clienti. Nell’esempio viene detto “Provide integrations with external services”, ma come ce l’hai in roadmap e non sai neanche quale service vuoi integrare?
    Condivido sul non dare timelines ma solo timeframes, anche se chiunque abbia lavorato con business stakeholders con gli attributi sa che la prima domanda sarà “when is ETA?”.
    Secondo me va anche detto che la Product Roadmap è il risultato dell’armonizzazione di Company Vision, Customer requests, Product Vision e Tech Debt e solo il PM ha la visione di insieme. Quando il management dice ora si fa quello che diciamo noi è il momento giusto per andarsene se non si riesce a convincerli dell’errore.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *