Product roadmap
Una product roadmap non è un elenco di cose belle da avere: è la lista ordinata di ciò che una startup costruirà nei prossimi mesi, e perché in quell'ordine. Qui spiego come costruisco una roadmap di prodotto per una startup early-stage, cosa la distingue da una wishlist, e come si prioritizza davvero.
Perché una roadmap non è una wishlist
Una wishlist raccoglie tutto quello che sarebbe bello avere: feature richieste da un cliente, idee del founder, cose viste in un prodotto concorrente. Una roadmap seleziona, tra tutto questo, cosa costruire davvero e in che ordine, con un perché dichiarato per ogni voce. La differenza non è la lunghezza dell'elenco, è il criterio con cui si è deciso cosa metterci e cosa lasciare fuori.
Da cosa nasce: dati, non desideri
Una roadmap solida parte da input reali: discovery con gli utenti, segnali di utilizzo, vincoli tecnici già noti, non solo intuizioni del founder. È lo stesso principio dietro il servizio di product management che offro: roadmap di prodotto, prioritizzazione, discovery con utenti, decisione di cosa esce e cosa no, con il prodotto in mano a chi lo costruisce, non solo a chi lo immagina.
Prioritizzare: cosa entra e cosa resta fuori
Ogni voce in roadmap dovrebbe rispondere a una domanda semplice: cosa succede se non la costruiamo? Se la risposta è "niente di misurabile", quella voce può aspettare. I criteri che uso sono pochi e concreti: impatto sulla domanda che il prodotto deve ancora validare, costo reale di implementazione, e urgenza legata a un vincolo esterno (una scadenza, un cliente, un round). Tutto il resto è discutibile, e va discusso apertamente, non deciso di pancia.
90 giorni, non 12 mesi
In una startup early-stage una roadmap a 12 mesi è quasi sempre fiction: troppe variabili cambiano prima che arrivi il decimo mese. Preferisco un orizzonte di 90 giorni, con priorità chiare e riviste a ogni milestone: abbastanza tempo per costruire qualcosa di sostanziale, abbastanza corto da restare vero. Oltre i 90 giorni, la roadmap diventa una direzione di massima, non un impegno.
Chi la scrive e chi decide
La roadmap si scrive insieme, ascoltando founder, team e segnali dagli utenti, ma qualcuno deve avere l'ultima parola quando le priorità sono in conflitto. In un ingaggio come fractional CTO, quel ruolo spesso lo copro io per la parte tecnica: non per accentrare le decisioni, ma perché in un team piccolo qualcuno deve essere responsabile di dire no.
L'errore più comune: la roadmap che nessuno guarda più
Una roadmap scritta una volta e mai più aggiornata è peggio di non averla: dà una falsa sicurezza mentre la realtà del prodotto va altrove. Va rivista a ogni milestone, non ogni anno, ed è normale che cambi: una roadmap che non si aggiorna mai probabilmente non viene più letta da nessuno.
Domande frequenti
Cos'è una product roadmap per una startup early-stage?
È l'elenco ordinato e motivato di cosa costruire nei prossimi mesi, basato su discovery con gli utenti e vincoli reali, non un elenco di feature desiderate senza un criterio di scelta.
Qual è la differenza tra una roadmap e una wishlist?
La wishlist raccoglie tutto ciò che sarebbe bello avere; la roadmap seleziona cosa costruire davvero e in che ordine, con un perché dichiarato per ogni voce.
Ogni quanto va aggiornata una product roadmap?
A ogni milestone, tipicamente tra 30 e 90 giorni in fase early-stage: una roadmap scritta una volta e mai rivista smette presto di essere vera.
Chi dovrebbe scrivere la roadmap se il founder non è tecnico?
Va scritta insieme a chi guida la parte tecnica, un fractional CTO o un product manager, così le priorità tengono conto anche di vincoli e costi reali di implementazione, non solo del desiderio del mercato.
Meglio una roadmap a 90 giorni o a 12 mesi?
In fase early-stage, 90 giorni: abbastanza per costruire qualcosa di sostanziale, abbastanza corto perché le priorità restino vere invece di diventare fiction.