Come costruire una roadmap di prodotto dal feedback
5 min di lettura
Come costruire una roadmap di prodotto si riduce a questo: raccogli ciò che i clienti hanno già chiesto, raggruppalo per il problema dietro ogni richiesta, ordina i gruppi con una regola che sai spiegare, decidi quanto sei sicuro di ciascuno e pubblica il risultato in un formato adatto a chi lo legge. L’ordine conta. I team che partono da un layout e lo riempiono di idee ottengono un documento che sembra finito e non porta nessuna prova. I team che partono dalle richieste ottengono una roadmap più corta, con un motivo dietro ogni riga.
| Passaggio | Cosa fai | Cosa ottieni |
|---|---|---|
| 1. Raccogli | Porta richieste, temi del supporto e dati d’uso in un’unica lista | Una lista grezza con una fonte su ogni riga |
| 2. Raggruppa | Unisci i duplicati, dai un nome al problema di ogni gruppo | Da dieci a venti problemi con un conteggio |
| 3. Ordina | Applica una sola regola di punteggio e scrivila | Una lista ordinata che puoi difendere |
| 4. Impegnati | Etichetta ogni voce come impegnata, prevista o in esplorazione | Una certezza onesta su ogni riga |
| 5. Formato | Scegli un layout per chi legge | Una roadmap Now/Next/Later, per temi o a timeline |
| 6. Rivedi | Fissa una data per riguardare ogni riga | Una roadmap che resta aggiornata |
Da dove si parte per costruire una roadmap di prodotto?
Parti dalle prove che hai già, non da una pagina bianca. Le richieste di funzionalità aperte, le conversazioni di supporto etichettate con la stessa lamentela, gli appunti delle chiamate commerciali e i dati d’uso del tuo prodotto sono tutti input. Mettili in un’unica lista e annota da dove viene ogni voce.
Le richieste raramente arrivano in una forma utilizzabile. “Aggiungi l’integrazione con Slack” e “avvisa il mio team quando cambia un’attività” possono essere lo stesso bisogno. Per questo il passaggio successivo è il raggruppamento, e per questo vale la pena avere un tracker che unisce i duplicati; le richieste di funzionalità duplicate spiegano come. Tieni presente che ticket di supporto e richieste di funzionalità portano segnali di tipo diverso, e una roadmap costruita solo su uno dei due penderà dalla parte sbagliata.
Come si trasformano le richieste in voci della roadmap?
Raggruppa le richieste per problema, dai a ogni gruppo il nome di un risultato e conserva il conteggio. Un gruppo di quattordici richieste che descrivono tutte la perdita di un filtro dopo il ricaricamento diventa una voce: “Mantieni il filtro usato l’ultima volta”. Il conteggio va nella colonna della fonte, così chiunque legga la roadmap vede il peso che c’è dietro.
Scrivi il risultato con le parole del cliente. “Implementare la persistenza delle viste salvate” dice a un ingegnere cosa costruire e a un cliente niente. Formulare il risultato costringe anche a una domanda utile: se non sai dire cosa cambia per il cliente, forse hai davanti un’attività interna che va su un’altra lista.
Come si decide cosa viene prima?
Scegli una sola regola di punteggio, scrivila e applicala a ogni voce. RICE, che valuta portata, impatto, certezza e sforzo, è la più diffusa; la fonte originale è l’articolo di Intercom su RICE. Una regola più semplice va bene lo stesso, se la sai spiegare: numero di richieste, pesato in base a se chi le fa è un account pagante attivo, diviso per lo sforzo approssimativo.
Quello che conta è che la regola sia dichiarata, perché il primo cliente che chiede perché la sua richiesta non è in lista vorrà una risposta. Dove la regola e il tuo giudizio non coincidono, scrivilo nella riga. Dare priorità alle richieste di funzionalità passa in rassegna i metodi di punteggio, la questione della ponderazione per ricavo e cosa dicono e non dicono i voti.
Quanto sei sicuro di ogni voce?
Etichetta ogni voce con la sua certezza prima di pubblicare qualsiasi cosa. Basta una scala semplice a tre valori: impegnata significa che il team sarebbe sorpreso di non rilasciarla nella finestra, prevista significa che è il piano salvo imprevisti, in esplorazione significa nessuna promessa.
Questa colonna da sola evita la maggior parte dei danni di una roadmap. Senza, un cliente legge una voce in esplorazione come un impegno, i commerciali la citano, e un trimestre dopo diventa un reclamo. Il saggio di Marty Cagan su l’alternativa alle roadmap argomenta la questione di fondo: un elenco di funzionalità con le date è un elenco di congetture presentate come piani, e il rimedio è essere espliciti su ciò che sai.
Quale formato dovrebbe avere la roadmap?
Scegli il layout per ultimo, in base a chi legge. I clienti che si chiedono se li hai ascoltati hanno bisogno di una vista pubblica breve. La direzione che chiede perché si fa un certo lavoro vuole temi o risultati. Un team che cambia direzione ogni mese sta bene con Now, Next e Later e senza date. Gli esempi di roadmap di prodotto mostrano sei formati con voci realistiche e come fallisce ciascuno, e il template di roadmap di prodotto dà i campi da copiare una volta fatta la scelta.
La maggior parte dei team finisce con due documenti: una roadmap strategica per i lettori interni e una pubblica ridotta, che mostra solo ciò di cui accetti di rispondere. Se ne pubblichi una, roadmap pubblica descrive come guidarla con le etichette sulle issue che già tracci.
Come si evita che la roadmap invecchi?
Dai a ogni riga una data di revisione e tieni la roadmap dove il lavoro già si svolge. Una roadmap aggiornata a mano in uno strumento separato invecchia perché nel lavoro quotidiano di nessuno c’è questo compito. Se ogni colonna corrisponde a un’etichetta sulla issue, la roadmap cambia quando cambia l’etichetta.
Chiudi il ciclo quando una voce viene rilasciata. Chi l’aveva chiesta dovrebbe saperlo, e il posto abituale è la voce di changelog; il ciclo di feedback del cliente descrive l’intero percorso. Se decidi di non costruire qualcosa, diglielo. Un no chiaro serve a chi aveva chiesto, e rifiutare le richieste di funzionalità spiega come formularlo.
FAQ
Quali sono i passaggi per costruire una roadmap di prodotto? Raccogli richieste e dati, raggruppali per il problema dietro ciascuno, ordinali con una regola scritta, etichetta ogni voce con quanto sei sicuro, scegli un formato per chi legge e fissa una data di revisione. Partire dalle prove tiene la roadmap corta e difendibile.
Su cosa dovrebbe basarsi una roadmap di prodotto? Su richieste dei clienti, temi del supporto, dati d’uso e strategia, in ordine di quanto spesso vengono saltati. Una roadmap senza una fonte dietro le righe è una lista dei desideri.
Quanto dovrebbe coprire una roadmap di prodotto? Abbastanza da essere utile e poco abbastanza da essere credibile. Per molti piccoli team è il trimestre in corso nel dettaglio e il prossimo o i due successivi come temi. Tutto ciò che sta più in là va sotto “later”, senza date.
Chi dovrebbe partecipare alla costruzione di una roadmap di prodotto? Decide il responsabile di prodotto, l’ingegneria verifica fattibilità e sforzo, e supporto e vendite portano le richieste e i temi che sentono. I clienti vedono il risultato in una versione pubblica, ma non la modificano.
Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.