Idea principale

Una roadmap si legge per ciò che mostra. Eppure il suo effetto viene da ciò che lascia fuori: tutto ciò che non compare in nessuna delle sue colonne è fuori scope per l'orizzonte corrente. Questo rifiuto non è scritto da nessuna parte — nessuna colonna si chiama «no» — ed è comunque l'unica parte che produca concentrazione.

Dire che si avanza sull'automazione, sull'onboarding e sulla riduzione del supporto significa dire, nello stesso momento, che adesso non si faranno la riprogettazione dell'interfaccia, il marketplace di integrazioni, il portale per i commercialisti e le richieste specifiche di un piccolo segmento. Ciò che si fa e ciò che non si fa sono le due metà di una stessa decisione; scriverne una sola lascia credere che l'altra resti aperta.

Una roadmap che non ammette questo rifiuto non allinea nessuno. Mette i conflitti in un ordine presentabile e li rinvia al momento dell'esecuzione, quando bisognerà scegliere sul serio e nessuno si ricorderà più che si sarebbe dovuto scegliere prima.

Perché è importante

Sposta il test di qualità di una roadmap. Di solito la si giudica sulla pertinenza di ciò che contiene; il test utile è chiedersi cosa esclude, e verificare che qualcuno sappia dirlo.

Disinnesca anche il rimprovero rivolto alla rinuncia — «così si chiudono porte». La rinuncia non è un danno collaterale della prioritizzazione: è il meccanismo con cui la prioritizzazione produce qualcosa.

Sfumature e limiti

Un rifiuto implicito resta un rifiuto che nessuno ha formulato. Protegge la concentrazione del team senza impedire al tema scartato di ricomparire: nessuno ha firmato, quindi nessuno deve tornare sulla propria firma.

E l'esclusione ha senso solo su un orizzonte delimitato. Un «non lo faremo» che si legge come «mai» crea opposizioni inutili, mentre la frase esatta è: per adesso, salvo una rottura maggiore.

Domande aperte

• Bisogna scrivere la lista di ciò che è fuori scope, a rischio di trasformare un rifiuto implicito in una negoziazione esplicita tema per tema?