Nella maggior parte dei team di prodotto, il backlog è un luogo dove l'urgenza va a morire. Tutto ciò che entra era urgente quando è stato aggiunto — un reclamo dei clienti, una richiesta di vendita, una funzionalità concorrente, un'idea interna. Sei mesi dopo, tutto è ancora lì, sembra tutto ancora urgente, e nessuno sa veramente quale cosa fare dopo.
Il problema non è una mancanza di strumenti. Ci sono dozzine di framework di prioritizzazione: RICE, MoSCoW, Kano, ICE, scoring ponderato. Il problema è che la maggior parte dei framework richiede una sorta di falsa precisione — assegnare numeri agli sconosciuti — che li rende rigorosi mentre in realtà solo il lavaggio interiore attraverso un foglio di calcolo.
Quello che funziona veramente è più semplice: due dimensioni, onestamente valutate, e la disciplina di agire in base al risultato.
La prioritizzazione si riduce a due domande. In primo luogo: quanto questo migliora il risultato che ci importa? (Impatto.) In secondo luogo: quanto ci costerà consegnarlo? (Sforzo.) Tutto il resto è o un affinamento di questi due o una distrazione da essi.
La fiducia a volte viene aggiunta come terza dimensione — "quanto siamo certi dell'impatto?" — ed è utile tenere a mente. Ma in pratica, la maggior parte dei team sa quando sta indovinando. La disciplina è di etichettare l'indovina onestamente, non di punteggiarlo su una scala da 1 a 5 e aggiungerlo a una formula.
La parte difficile non è comprendere la griglia — è essere onesti quando la riempi. Ogni team ha funzionalità che vuole costruire che appartengono a "Perdite di Tempo" ma continuano a essere riclassificate come "Grandi Scommesse." Il framework funziona solo se il team può essere onesto sull'impatto.
L'impatto è la dimensione che i team trovano più difficile da valutare, perché spesso richiede di prevedere il futuro. La tentazione è di punteggiarlo numericamente e sentirsi scientifico al riguardo. Un approccio migliore è qualitativo ma strutturato.
Poni tre domande per ogni funzionalità in considerazione:
I team sottovalutano sistematicamente lo sforzo. Questo è ben documentato — è legato al fallacy della pianificazione e al bias dell'ottimismo — ed è particolarmente pronunciato per le funzionalità che toccano più sistemi, richiedono coordinamento tra team o implicano capacità che il team non ha costruito prima.
Dove la prioritizzazione realmente si rompe non è nel calcolo — è nella comunicazione. Un backlog priorizzato è inutile se il team non capisce perché alcune cose sono al top e altre sono in fondo. Se il venditore che ha chiesto "la funzionalità X" tre mesi fa la vede ancora nel backlog senza una spiegazione di impatto e sforzo, il sistema fallisce.
La migliore pratica è di documentare il quadrante di prioritizzazione di ogni pezzo — non come un numero su una scala, ma come una dichiarazione verbale di "questo è una Vittoria Rapida" o "questo è una Perdita di Tempo che abbiamo deciso consapevolmente di non costruire adesso." Poi, quando qualcuno chiede "perché non stiamo costruendo la funzionalità X?" la risposta è una conversazione, non un numero.