La roadmap non è una lista di feature: costruirla con Impact Mapping e Value Proposition Canvas

Una delle domande che mi fanno più spesso i founder è: “Quali feature sviluppiamo dopo?”. La domanda è legittima, ma partire dalle feature è il modo più rapido per costruire una roadmap che sembra piena e invece non porta da nessuna parte.

Le due forme più diffuse di roadmap hanno lo stesso difetto. La lunga lista di feature elenca cosa si farà, ma non perché. Il diagramma di Gantt aggiunge le date, ma le date senza un perché sono solo un’illusione di controllo. In entrambi i casi manca la domanda che conta: che valore porta questa cosa, e a chi?

Una roadmap utile non è un elenco di consegne. È una sequenza di ipotesi validate: ogni feature deve avere un senso logico, un motivo valido per esistere e un valore dimostrabile per qualcuno. Per costruirla in modo collaborativo uso tre strumenti che lavorano a livelli diversi: il Value Proposition Canvas, l’Impact Mapping e, per scendere di dettaglio, l’Opportunity Solution Tree. Capire quale domanda hai davanti è il modo migliore per scegliere quale adottare.

La stella polare: vision, business model e revenue model

Prima di qualsiasi strumento di prodotto c’è un prerequisito: sapere dove sta andando l’azienda. Vision, business model e revenue model sono la stella polare della roadmap. Non si discutono ogni volta: si guardano per tenere la rotta. Se la stella manca o è sfocata si può costruire: ci sono strumenti che lavorano a livello strategico per crearla in modo collaborativo, come il Business Model Canvas, il Revenue Model Canvas e altri ancora.

In una startup post-seed questa stella dovrebbe già esserci: è quella con cui è stato raccolto il round. Se non è chiaro dove si va, qualsiasi roadmap fa solo girare in tondo, che sia una lista di feature, un Gantt o una sequenza di ipotesi.

Ed è qui che gli strumenti che seguono mostrano il loro primo valore: rendono evidente quando la stella polare manca. Un Value Proposition Canvas la cui proposta non si aggancia alla vision, una mappa degli impatti che non riesce a enunciare un goal misurabile: non sono esercizi falliti, sono il segnale che il problema da risolvere è la direzione, non la roadmap.

Quando manca la stella: si sale di un livello

Il prerequisito va onorato nel momento in cui applichiamo gli strumenti di prodotto. Se durante la preparazione o durante il workshop stesso emerge che non c’è, si fa un passo indietro. Anzi, un passo verso l’alto: un livello di astrazione sopra.

Mi è capitato più di una volta di progettare un workshop con Value Proposition Canvas o Impact Mapping e accorgermi in corso d’opera che i prerequisiti mancavano. Il workshop si è trasformato mentre era in corso: Business Model Canvas, Revenue Model Canvas, o entrambi.

Il caso più istruttivo è stato con una startup in cui C-level e head of area sentivano il disallineamento con il team di prodotto. Il piano era fare Value Proposition Canvas e Impact Mapping, per coprire i due versanti: portare la visione e i goal aziendali verso il team di prodotto, lo stato dell’applicazione e le necessità emerse dagli utenti verso l’alto. All’inizio della prima giornata ci siamo accorti che l’allineamento mancava anche dentro il gruppo dei decisori. L’head of marketing, per esempio, non conosceva il revenue model aziendale. Siamo saliti di livello: si è partiti da un Revenue Model Canvas e solo dopo siamo scesi a definire gli obiettivi e a lavorare con l’Impact Mapping.

Approfondimenti

Il caso completo è raccontato nell’esperienza «Il codice rallentava, ma il problema era un altro».

Come si lavora: la stanza, i tempi, il formato

Nella stanza serve il team di prodotto, insieme alle persone che hanno relazioni dirette con gli utenti: customer success, sales, chi raccoglie feedback tutti i giorni. In alcuni casi si invita anche marketing e operations, dipende dai temi trattati. A volte ci sono gli Head of area come rappresentanti dei rispettivi team, quando la startup è più strutturata. Founder, CEO e C-level ci sono raramente e spesso sono opzionali: in molte startup non hanno ruoli operativi nel day-by-day. Diventano necessari quando si sale di livello, verso gli strumenti strategici.

La durata tipica è uno o due giorni, in base alla dimensione del lavoro e al livello di chiarezza preesistente. La prima volta si tende a fare due giorni, le volte successive si scende a uno e in rari casi a mezza giornata.

È preferibile lavorare in presenza, con una coda finale da remoto per riorganizzare le idee e formalizzarle in bella copia. La giornata inizia con un momento di setup e icebreaking e si conclude con uno shareback. L’agenda non è sfidante di proposito: restano momenti liberi per il networking e per lasciar fluire idee nuove. Da remoto funziona tutto, ma l’organizzazione e la durata delle sessioni cambiano completamente.

Value Proposition Canvas: stiamo risolvendo un problema vero?

Il Value Proposition Canvas mette di fronte due metà. Da un lato il profilo del cliente: i suoi job-to-be-done, le sue difficoltà (pains), i risultati che cerca (gains). Dall’altro la proposta di valore del prodotto: cosa offre, come riduce quelle difficoltà, come produce quei risultati.

Il lavoro è cercare il fit tra le due metà. Dove la proposta intercetta un pain o un gain rilevante, c’è valore. Dove non intercetta nulla, c’è una feature che piace a noi ma non serve a nessuno.

Impact Mapping: questa attività serve l’obiettivo?

Avere una value proposition solida non basta: serve collegare gli obiettivi di business agli impatti che vogliamo creare e da lì alle attività di sviluppo.

L’Impact Mapping lo fa con quattro livelli:

Goal: l’obiettivo di business misurabile.
Actors: chi può influenzare quel risultato.
Impacts: cosa dovrebbero fare (o smettere di fare) quegli attori.
Deliverables: quali interventi di prodotto possono favorire quegli impatti.

La cosa importante da non dimenticare è che i Deliverables non sono ancora feature su cui lavorare: stanno un livello sopra.

Il vantaggio è che si parte dal “perché” e si arriva al “cosa”, non il contrario. Una feature che non risponde a un impact, che non serve a un actor, che non contribuisce a un goal, non entra in roadmap.

Quando non bastano: l’Opportunity Solution Tree

A volte i due strumenti lasciano scoperto il passo finale. L’Impact Mapping individua l’impatto giusto, ma non dice quali deliverable lo producono. Il Value Proposition Canvas mostra un pain o un gain scoperto, ma nessuno ha un’idea su come affrontarlo. Quando l’incertezza è sui deliverable, serve scendere di un livello.

L’Opportunity Solution Tree ha una struttura ad albero con quattro elementi:

Desired outcome: la radice, il risultato che si vuole ottenere.
Opportunities: i bisogni, i problemi e i desideri degli utenti che potrebbero muovere quel risultato. Emergono dai feedback e dalla ricerca, non dalle idee di soluzione.
Solutions: i possibili interventi per ciascuna opportunità. Ne cerco sempre più di una, perché la prima idea non è quasi mai quella giusta.
Experiments: il modo più piccolo e veloce per validare una soluzione prima di costruirla.

Si parte dalla radice e si scende solo dove serve: si confrontano le opportunità prima di scegliere dove investire, e ogni soluzione entra in roadmap solo dopo aver superato il suo esperimento. Anche qui non si parla mai di feature in partenza: le soluzioni sono ipotesi, e diventano feature solo a validazione avvenuta. Non è un caso che il desired outcome possa essere esattamente un impact di una mappa, un pain da rimuovere o un gain da creare: l’albero attacca dove gli altri due strumenti si fermano o iniziano a essere sfocati.

Quando l’uno, quando l’altro

La domanda decide lo strumento.

Se la domanda è “stiamo costruendo qualcosa che qualcuno vuole davvero?”, si parte dal Value Proposition Canvas e si verifica prima che il valore esista. È il caso di una nuova idea da sviluppare, di una parte di prodotto che gli utenti non capiscono, di feedback che si contraddicono.

Se la domanda è “tra tutte le cose che potremmo fare, quali muovono l’obiettivo?”, si parte dall’Impact Mapping: prima si decide dove puntare, poi si taglia tutto il resto. È il caso tipico di una startup con tanti feedback e idee che arrivano dall’esterno, il backlog pieno e le metriche di business ferme.

Se la domanda è “come arriviamo a quel risultato?”, si scende di un livello con l’Opportunity Solution Tree. Si può usare da solo, oppure come approfondimento sugli outcome emersi dagli altri due strumenti, se necessario.

I due strumenti principali sono complementari: uno guarda al valore per il cliente, l’altro al contributo verso l’obiettivo. Usati insieme si rafforzano perché coprono aspetti diversi. Un deliverable che supera entrambi i filtri merita la roadmap, uno che ne supera uno solo no. Ma non è obbligatorio farli entrambi. Quando team di prodotto e stakeholder sono già allineati, il valore dei due insieme è inferiore alla somma dei singoli. Lo scopo è lo stesso: dare un senso a ciò che si costruisce. Gran parte del valore che portano si sovrappone. Meglio uno fatto bene che due per abitudine.

Il rischio annidato: voler fare tutto

Questi strumenti funzionano così bene a generare opzioni che la tentazione è tenerle tutte: tutti i deliverable di tutti gli impact, tutti i pain risolti, tutti i gain abilitati. Il risultato è una roadmap che torna a essere la lista di feature da cui eravamo partiti, solo più lunga e con giustificazioni migliori.

Il valore di questi strumenti non sta in quello che generano, ma in quello che permettono di tagliare. Alcune pratiche che aiutano:

Un goal alla volta. Una mappa degli impatti con un solo obiettivo misurabile è uno strumento di scelta; con dieci obiettivi è un backlog con una grafica migliore.
Pain e gain non sono tutti uguali: contano frequenza e intensità. Un pain reliever per un problema marginale è una feature che nessuno rimpiangerà.
Potare l’albero: nell’Opportunity Solution Tree le opportunità che non muovono il desired outcome si tagliano, e ogni ramo che resta merita un esperimento, non un impegno.
Il taglio è una decisione, non un’omissione: quello che resta fuori va scritto, con il suo perché. Altrimenti rientra dalla finestra al primo feedback rumoroso.

La domanda finale non è “cosa possiamo fare?”, perché gli strumenti rispondono fin troppo bene. È “cosa non faremo, e perché?”.

Una pratica che tiene tutto questo sul piano della realtà: darsi obiettivi SMART (Specific, Measurable, Achievable, Relevant, Time-bound) con metriche di risultato e di tempo. Vale a ogni livello: goal, impact, desired outcome. Le metriche dicono quando l’obiettivo è raggiunto, e quel momento è anche quello in cui si valutano le altre iniziative legate a quell’obiettivo: deliverable, soluzioni, esperimenti ancora in coda. Se l’obiettivo è raggiunto, si scartano.

Il vincolo temporale è quello che fa la differenza. Una scadenza permette di trattare idee e intuizioni come esperimenti da validare entro quella data, senza procrastinare il momento della decisione. E limita lo scope da sola: non si può fare tutto, quindi bisogna dare priorità a quello che serve per raggiungere l’obiettivo.

Lo stato del software come vincolo, non come scusa

Tutto questo funziona se il processo di sviluppo è iterativo e incrementale, e raccoglie feedback a ogni giro. È quello che permette di accorgersi in anticipo che un obiettivo non è raggiungibile, in corso d’opera e non alla vigilia della scadenza. Se lo sviluppo non è iterativo, tanto vale disegnare un diagramma di Gantt e chiamare un project manager waterfall.

In quest’ottica anche un obiettivo mancato può contenere dei successi. Conta come successo ogni passo che ci avvicina all’obiettivo e da cui impariamo qualcosa di utile, per esempio cosa non vuole l’utente. Se alla scadenza l’obiettivo manca, la domanda non è “chi ha sbagliato” ma “cosa non ha funzionato nel modo in cui il team itera”.

C’è poi un momento, e questo momento c’è sempre, in cui qualcuno dal lato business dice: “Ma noi vogliamo X”, e qualcuno dal lato tech risponde: “X è impossibile con il codice che abbiamo”. Entrambe le frasi sono parziali.

Lo stato del software entra nella roadmap come vincolo reale:

dove il codice è solido, si può muoversi velocemente;
dove è fragile, ogni intervento richiede più test, più osservabilità, più cautela;
dove non esiste, bisogna valutare se costruire, comprare o integrare.

Una roadmap seria non ignora questi vincoli: li rende espliciti e li trasforma in scelte. A volte la strada giusta non è la feature più appetibile, ma quella che sblocca le altre.

La roadmap è viva

Una roadmap costruita così non si archivia. La si verifica in continuo, man mano che le ipotesi vengono validate e i feedback dal campo si integrano. Una revisione più consistente si fa quando si avvicina la fine di un blocco di attività, qualunque sia il risultato. E se qualcosa smette di tornare, per un imprevisto o un evento di mercato, si rivedono priorità, tempi e scope.

Un rapido check ogni tre o quattro mesi è una buona pratica. Se la roadmap è mantenuta viva e sana, di solito non serve nemmeno quello: il check è già più frequente.

Cosa cambia

Alla fine del percorso non si ottiene una lista di feature, e nemmeno un Gantt. Si ottiene una sequenza di ipotesi del tipo:

Se facciamo [deliverable], allora [actor] cambierà comportamento in [impact], contribuendo a [goal misurabile].

Oppure, con il taglio del Value Proposition Canvas:

Se [soluzione] riduce un [pain] / abilita un [gain] per [segmento di clienti], allora quel segmento avrà un motivo in più per sceglierci, restare o consigliarci. Lo vedremo dalla [metrica].

Gli artefatti hanno due forme. Quella della giornata: muri pieni di post-it e disegni, fotografati e trasformati in board digitali per consultarli e farli evolvere, con app che automatizzano buona parte del lavoro. Quella tattica: ogni team coinvolto — prodotto, marketing, customer support, sales — adotta la forma che preferisce, una kanban board o altro.

Da questi artefatti nasce la visualizzazione della roadmap: una scala temporale che diventa vaga man mano che va verso il futuro, su cui si mettono in fila goal, impatti, desired outcome, pains e gains, a seconda dello strumento usato. Mai elementi di livello più basso. Mai feature.

Ogni voce della roadmap diventa un esperimento da validare, non una consegna da accettare. E ogni priorità può essere discussa con lo stesso linguaggio da business, prodotto e gli altri team coinvolti.