Feature prioritization with data

Su una roadmap di prodotto le feature candidate sono sempre tante, ma le persone in engineering sono poche. Prioritizzare con i dati significa scegliere cosa costruire pesando impatto, evidenza, costo, rischio e strategia, così la decisione smette di essere una gara di opinioni.

Il problema che vogliamo risolvere

Lasciato a se stesso, il backlog diventa un’arena politica dove vincono le voci più forti. C’è la HiPPO, cioè l’opinione del dirigente più pagato. C’è il cliente più rumoroso che minaccia di andarsene. C’è il bias della recenza, che fa sembrare urgente l’ultimo problema emerso. Ci sono le preferenze tecniche di chi sviluppa e la pressione commerciale per chiudere contratti.

I dati non spengono la politica, ma la rendono più costosa: chi propone una feature è costretto a mettere sul tavolo ipotesi, segmenti, metriche, rischi e trade-off.

Un modello per orientarsi

Conviene guardare a una feature come a una scommessa su un comportamento futuro dell’utente, non come a un deliverable da spuntare. Una proposta seria suona più o meno così:

Costruendo X per il segmento Y, ci aspettiamo di aumentare la metrica Z del N%, perché abbiamo l’evidenza E. Lo verificheremo entro T giorni misurando M.

Messa in questi termini, la discussione si sposta da “mi piace o non mi piace” a quanto è plausibile la scommessa, quanto è rilevante, quale metrica la misura e quanto costa.

Come formalizzare un’analisi

Per analizzare la prioritizzazione con i dati serve definire alcuni elementi.

Element	Specifica
Unit of analysis	user, cohort, product event, feature, or journey
Primary signal	activation, retention, frequenza, conversione, churn, valore per coorte
Baseline	periodo precedente, gruppo comparabile, benchmark, scenario controfattuale
Decisione attesa	diagnosi prodotto, esperimento, prioritizzazione, intervento UX
Risk	scambiare un numero disponibile per una prova sufficiente

La formalizzazione regge se un altro analista può ripercorrere la logica e arrivare alla stessa decisione.

Un caso concreto

Prendiamo un prodotto SaaS con 50.000 utenti attivi mensili che deve scegliere tra tre feature: un template di onboarding per i nuovi utenti, un’esportazione PDF avanzata richiesta dai clienti enterprise e una ricerca semantica per migliorare la discovery.

Con il framework RICE, che pesa Reach, Impact, Confidence ed Effort, il punteggio si calcola così:

RICE Score = (Reach × Impact × Confidence) / Effort

Feature	Reach	Impact	Confidence	Effort	RICE Score
Onboarding templates	12.000	2.0	0.85	2.0	10.200
Export PDF avanzato	1.800	1.5	0.90	1.5	1.620
Semantic search	30.000	1.0	0.45	5.0	2.700

La ricerca semantica ha la reach più alta, eppure finisce in coda perché l’effort è elevato e la confidenza bassa. Vince l’onboarding, che agisce sul momento più critico di tutti: la prima esperienza dell’utente.

Esercizio guidato

A livello base scrivi una scheda sintetica su una feature: decisione da supportare, metrica primaria, baseline, rischio principale e azione prevista se l’ipotesi è confermata.

A livello intermedio costruisci una tabella con tre segmenti o scenari, indicando per ciascuno cosa cambia, quali spiegazioni alternative sono plausibili e quali controlli faresti prima di agire.

Per il livello avanzato prepara un memo decisionale con ipotesi, dati necessari, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo il lancio.

Come materiale puoi usare eventi prodotto, funnel, sessioni, survey, dati CRM, ticket di supporto ed esperimenti. Se non li hai, costruisci un dataset sintetico con almeno 200 righe, una dimensione temporale, qualche segmento e una metrica di outcome.

L’errore che ricorre più spesso

L’errore tipico è trattare la prioritizzazione con i dati come un’etichetta: grafici senza decisioni collegate, metriche senza baseline, conclusioni che non dicono quali assunzioni potrebbero ribaltarle. La domanda da farsi è la solita: se il risultato fosse instabile, quale scelta sbaglierei?

Quiz or checkpoint

1. Quale decisione concreta migliora questa lezione?
2. Which unit of analysis makes the problem measurable?
3. Quale baseline evita letture ingenue?
4. Quale errore tipico può cambiare la conclusione?
5. Which output would you deliver to a non-technical stakeholder?

Operational Summary

Prioritizzare con i dati significa trasformare il backlog in un portafoglio di scommesse. RICE mette a confronto impatto, reach, confidenza ed effort; il Kano Model evita sia di sottovalutare i bisogni basic sia di sopravvalutare i delighter; il Cost of Delay aggiunge la dimensione del tempo. Il salto di qualità arriva quando confronti le stime con i risultati dopo il lancio, perché è lì che un team impara dai propri errori invece di ripeterli.

---

Framework complementari

Kano Model

Le feature non spostano la soddisfazione allo stesso modo. I bisogni basic sono indispensabili e la loro assenza genera insoddisfazione, anche se la loro presenza viene data per scontata. I bisogni di performance danno una soddisfazione proporzionale alla qualità con cui li soddisfi. I delighter, infine, sono quelli inattesi che generano entusiasmo, ma il loro effetto si consuma col tempo. Misurare Kano con i dati vuol dire incrociare survey e comportamenti, per esempio correlando l’assenza di una feature con il churn o il suo uso con la retention.

Cost of Delay e WSJF

A volte il tempo pesa più dello score RICE. Il Cost of Delay misura il valore che perdi per ogni settimana di ritardo. Il WSJF, cioè il Weighted Shortest Job First, lo mette in rapporto con la dimensione del lavoro:

WSJF = Cost of Delay / Job Size

Il Cost of Delay a sua volta combina valore di business, criticità temporale e riduzione del rischio.

Come fa Intercom

Intercom gestisce le iniziative come “product bets”, con una tesi chiara, metriche e momenti di verifica, pesando severità del problema, ampiezza del segmento, allineamento strategico, confidenza ed effort. È un approccio che va oltre i numeri e richiede una cultura decisionale, non solo un foglio di calcolo.