Nella maggior parte dei team di prodotto, il backlog è il posto in cui l'urgenza va a morire. Tutto ciò che ci entra era urgente al momento dell'inserimento: il reclamo di un cliente, una richiesta del team commerciale, una funzionalità della concorrenza, un'idea interna. Sei mesi dopo è ancora tutto lì, tutto sembra ancora urgente e nessuno sa bene cosa fare per primo.
Il problema non è la mancanza di strumenti. Esistono decine di framework di prioritizzazione: RICE, MoSCoW, Kano, ICE, weighted scoring. Il problema è che la maggior parte richiede una falsa precisione, cioè assegnare numeri a variabili ignote, che li fa sembrare rigorosi mentre in realtà si limitano a riciclare l'intuito in un foglio di calcolo.
Ciò che funziona davvero è più semplice: due dimensioni, valutate con onestà, e la disciplina di agire in base al risultato.
La prioritizzazione si riduce a due domande. Prima: quanto migliora questa funzionalità il risultato che ci sta a cuore? (Impatto.) Seconda: quanto ci costerà realizzarla? (Impegno.) Tutto il resto è un affinamento di queste due dimensioni o una distrazione.
A volte si aggiunge una terza dimensione, il grado di confidenza ("quanto siamo sicuri dell'impatto?"), ed è utile tenerla a mente. Ma in pratica la maggior parte dei team sa quando sta tirando a indovinare. La disciplina sta nel dichiarare onestamente la stima incerta, non nell'assegnarle un voto da 1 a 5 e inserirla in una formula.
La parte difficile non è capire la matrice, ma essere onesti quando la si compila. Ogni team ha funzionalità che vorrebbe costruire e che appartengono ai "Buchi neri di tempo", ma che continuano a essere riclassificate come "Grandi scommesse". Il framework funziona solo se il team riesce a essere onesto sull'impatto.
L'impatto è la dimensione più difficile da valutare per i team, perché spesso richiede di prevedere il futuro. La tentazione è assegnargli un punteggio numerico e sentirsi scientifici. Un approccio migliore è qualitativo ma strutturato.
Per ogni funzionalità in esame, poniti tre domande:
I team sottostimano sistematicamente l'impegno. È un fenomeno ben documentato, legato alla fallacia della pianificazione e al bias dell'ottimismo, ed è particolarmente marcato per le funzionalità che toccano più sistemi, richiedono coordinamento tra team o implicano competenze che il team non ha mai sviluppato prima.
Due pratiche aiutano. Primo: chiedi sempre al team di sviluppo prima di assegnare il punteggio di impegno, non dopo. I product manager che stimano l'impegno da soli lo sottostimano quasi sempre. Secondo: usa il concetto di "incognite sconosciute" come moltiplicatore esplicito dell'impegno. Qualsiasi funzionalità che tocchi una nuova area del codice, un'API di terze parti o un flusso utente non testato di recente merita un punteggio di impegno 1,5 volte superiore a quanto suggerisce il lavoro più evidente.
La maggior parte dell'urgenza in un backlog di prodotto non è vera urgenza: è recenza. Un cliente si è lamentato la settimana scorsa, quindi la sua richiesta sembra pressante. Un concorrente ha lanciato qualcosa il mese scorso, quindi eguagliarlo sembra critico. Ma recenza non significa importanza, e reagire alla recenza è uno dei modi più sicuri per lasciar scivolare via il lavoro davvero importante.
Un test pratico: chiediti se la considereresti ancora urgente se ne fossi venuto a conoscenza sei mesi fa invece che la settimana scorsa. Se la risposta è no, è il bias della recenza all'opera, non una priorità strategica. Registrala, valutala con calma sulla matrice e resisti alla tentazione di accelerarla solo perché è fresca.
La matrice non produce sempre una risposta netta. Due elementi finiscono nello stesso quadrante con punteggi simili e devi comunque sceglierne uno. In questi casi sono utili due criteri di spareggio: l'allineamento strategico (quale ti avvicina di più a dove vuoi essere tra 18 mesi?) e la reversibilità (quale è più difficile da annullare se si rivela sbagliato?). Preferisci l'elemento più allineato alla strategia e più reversibile.