Prioritizzazione feature con dati

Questa lezione segue il binario ml-tabellare: ogni feature diventa una riga, ogni criterio una colonna, e il punteggio finale parla da solo. L’obiettivo è trasformare un backlog politico in un portafoglio di scommesse misurabili, dove l’ultimo che parla non è chi grida più forte ma il confronto tra numeri.

Il cuore della questione

La prioritizzazione con dati ordina feature per impatto atteso, evidenza, costo e rischio invece di opinioni dominanti. Il punto non è trovare la feature giusta in assoluto, ma rendere esplicito il compromesso tra valore atteso e costo, così che la decisione possa essere discussa, contestata e verificata dopo il lancio.

Il metodo in sei passi

1. Formula ogni feature come scommessa su segmento, metrica, effetto atteso ed evidenza.
2. Stima reach, impatto, confidenza ed effort con baseline e non a dito.
3. Calcola punteggio comparabile e ordina il portafoglio per valore su costo.
4. Applica vincoli di tempo con costo del ritardo e dimensione del lavoro.
5. Verifica basic, performance e delighter per non distorcere la roadmap.
6. Confronta stime con risultati post-lancio e aggiorna confidenza futura.

Ogni passo produce un artefatto preciso: il primo una frase di tesi, il secondo una tabella di stime con le assunzioni accanto, il terzo una classifica, il quarto una sequenza temporale, il quinto un controllo di composizione, il sesto un registro di calibrazione. Se un passo non produce nulla di scritto, probabilmente è stato saltato.

RICE su un caso con numeri

Il caso è un prodotto SaaS con 50.000 utenti mensili. Le opzioni sul tavolo sono template onboarding, export PDF enterprise e ricerca semantica. Il punteggio RICE Score è reach per impatto per confidenza diviso effort.

Feature	Reach	Impact	Confidence	Effort	RICE Score
Template onboarding	12.000	2.0	0.85	2.0	10.200
Export PDF avanzato	1.800	1.5	0.90	1.5	1.620
Ricerca semantica	30.000	1.0	0.45	5.0	2.700

I conti, passo per passo. Per l’onboarding: 12.000 per 2,0 per 0,85 fa 20.400, diviso 2,0 di effort dà 10.200. Per l’export PDF: 1.800 per 1,5 per 0,90 fa 2.430, diviso 1,5 dà 1.620. Per la ricerca semantica: 30.000 per 1,0 per 0,45 fa 13.500, diviso 5,0 dà 2.700.

La reach più alta non vince. La ricerca semantica perde per effort elevato e confidenza bassa. L’onboarding vince perché agisce sul primo valore.

Come si stima la reach senza inventarla: quella dell’onboarding è 12.000, cioè il 24% dei 50.000 utenti mensili, e si misura dagli eventi di primo login già tracciati, non si indovina. L’impatto 2,0 dichiara l’effetto atteso su una metrica di primo valore, la confidenza 0,85 cita l’evidenza di test precedenti e l’effort 2,0 distingue due settimane con una persona. Ogni numero della tabella ha una riga di assunzione scritta da qualche parte.

Intercom gestisce iniziative come product bets: ogni scommessa ha tesi, metriche e verifiche su severità, ampiezza, allineamento, confidenza ed effort.

Kano contro Cost of Delay contro WSJF

I basic sono indispensabili: la loro assenza crea insoddisfazione. I performance danno soddisfazione proporzionale al livello fornito. I delighter sorprendono ma si consumano in fretta.

Il Cost of Delay misura il valore perso per ogni settimana di ritardo. Il WSJF lo rapporta alla dimensione del lavoro come costo del ritardo diviso dimensione.

Kano si misura incrociando survey e comportamenti: l’assenza di una funzione si legge contro il churn, mentre l’uso si legge contro la retention.

Framework	Domanda	Quando decide
RICE	Quale scommessa rende di più per effort	Backlog eterogeneo comparabile
Kano	Quale bisogno evita insoddisfazione o crea entusiasmo	Bilanciamento roadmap
Cost of Delay e WSJF	Quanto costa aspettare una settimana	Sequenza temporale e scadenze

Un calcolo di WSJF con numeri. Una feature vale 40.000 euro di ricavi al mese e ogni settimana di ritardo ne costa 10.000: il costo del ritardo è 10.000 a settimana. Con una dimensione stimata di 2 settimane, il WSJF è 10.000 diviso 2, cioè 5.000. Una seconda feature ha costo del ritardo di 6.000 a settimana e dimensione di 3 settimane: WSJF 2.000. La prima va prima, anche se la seconda ha un costo del ritardo assoluto più basso: è il rapporto a decidere, non il valore assoluto.

La sintesi: RICE ordina il valore, Kano evita errori di composizione e WSJF decide l’ordine nel tempo.

Verdetto: RICE vince per ordinare il valore su costo, Kano per bilanciare la roadmap e WSJF per decidere l’ordine nel tempo quando le scadenze contano.

Gli errori che fanno fallire la prioritizzazione

Cinque errori ricorrono con sintomi riconoscibili.

1. Stime a dito senza baseline: il sintomo è che i punteggi non cambiano mai dopo una discussione, perché nessuno ha scritto da dove arrivano i numeri.
2. Confidenza usata come moltiplicatore di comodo: chi vuole una feature alza la confidenza a 0,9 senza evidenza; il sintomo è una confidenza uniforme su tutto il backlog.
3. Effort confuso con durata: un lavoro da 2 settimane con 3 persone ha effort diverso da uno da 2 settimane con 1 persona; il sintomo è che le stime non distinguono persone e settimane.
4. Nessuna verifica post-lancio: se non torni a misurare l’impatto reale, la confidenza non si calibra mai e gli stessi errori si ripetono a ogni ciclo.
5. Kano ignorato: si costruiscono delighter mentre i basic sono rotti; il sintomo è il churn che non scende nonostante le release.

La checklist prima di ordinare il backlog

Prima di presentare la classifica, rispondi a sei domande. La feature ha una tesi scritta con segmento, metrica ed effetto atteso? Reach e impact hanno una baseline citata? La confidenza riflette l’evidenza, non l’entusiasmo? L’effort distingue persone e settimane? Il framework scelto risponde alla domanda giusta, valore, composizione o tempo? Esiste un controllo post-lancio con soglia e data? Se manca anche una sola risposta, il punteggio è una decorazione.

Quando un’evidenza da 200 milioni di dollari decide la strada

Nel 2009 Google testa 41 sfumature di blu per i link delle pagine di ricerca perché dai dati risulta che la tonalità giusta vale circa 200 milioni di dollari l’anno di ricavi pubblicitari aggiuntivi. L’episodio, raccontato dal New York Times nel 2009, mostra il cuore della prioritizzazione quantitativa: è l’impatto atteso a decidere cosa merita ingegneria, non il gusto del designer più autorevole. La stessa logica è formalizzata pochi anni dopo da Intercom con il framework RICE nel 2013, con Reach, Impact, Confidence ed Effort in un punteggio che rende confrontabili scommesse diverse.

Domande per controllare le tue scelte

1. Quale scommessa su segmento e metrica giustifica questa feature?
2. Quale confidenza hai e su quale evidenza si basa?
3. Quale framework tra RICE, Kano e WSJF decide qui?
4. Quale controllo post-lancio conferma o smentisce la stima?
5. Quale assunzione, se falsa, rovescerebbe l’ordine del tuo backlog?