En la majoria d'equips de producte, el backlog és un lloc on l'urgència va a morir. Tot el que entra estava urgent quan va ser afegit: una queixa de client, una sol·licitud de vendes, una característica de competidor, una idea interna. Sis mesos més tard, tot segueix allà, es sent urgent, i ningú sap del tot quin és el següent per fer.
El problema no és la manca d'eines. Hi ha dotzenes de marc de priorització: RICE, MoSCoW, Kano, ICE, puntuació ponderada. El problema és que la majoria de marcs requereix una mena de falsa precisió, assignant números a incògnites, cosa que els fa semblar rigorosos mentre realment només renta la intuïció a través d'una full de càlcul.
El que realment funciona és més simple: dues dimensions, valorades honestament, i la disciplina d'actuar en el resultat.
La priorització col·lapsa en dues preguntes. Primer: quant millora això el resultat que ens importa? (Impacte.) Segon: quant ens costarà entregar-la? (Esforç.) Tot allò més és un refinament d'aquestes dues o una distracció d'elles.
La confiança a vegades s'afegeix com tercera dimensió, "quant de segurs estem sobre l'impacte?", i val la pena tenir en ment. Però en la pràctica, la majoria d'equips saben quan estan adivinant. La disciplina és etiquetar l'adivinança honestament, no qualificar-la en una escala de 1-5 i afegir-la a una fórmula.
La part difícil no és entendre la graella; és ser honest en omplir-la. Cada equip té característiques que vol construir que pertanyen a "Pous de Temps" però segueix reclassificant-les com "Grans Apuestos". El marc només funciona si l'equip pot ser honest sobre l'impacte.
L'impacte és la dimensió que els equips troben més difícil d'avaluar, perquè sovint requereix predir el futur. La temptació és qualificar-la numèricament i sentir-se científic. Un millor enfocament és qualitatiu però estructurat.
Fes tres preguntes per a cada característica sota consideració:
Els equips subestimen sistemàticament l'esforç. Això està bé documentat (relacionat amb la falsa estimació i biaix optimista) i és particularment pronunciat per a característiques que toquen múltiples sistemes, requereixen coordinació entre equips, o impliquen capacitats que l'equip no ha construït abans.
Dues pràctiques ajuden. Primer, sempre pregunta a enginyeria abans de qualificar l'esforç, no després. Els PM que qualifiquen l'esforç unilateralment gairebé sempre subestimen. Segon, utilitza el concepte de "incògnites desconegudes" com a multiplicador d'esforç explícit. Qualsevol característica que toqui una nova àrea de codi, una API de tercers, o un flux d'usuari no testat recentment mereix una puntuació d'esforç 1,5 vegades més alta que el treball obvi suggereix.
La majoria de l'urgència en un backlog de producte no és urgència real; és recència. Un client es va queixar la setmana passada, així que la seva sol·licitud es sent urgent. Un competidor va llançar alguna cosa el mes passat, així que igualar-la es sent crítica. Però la recència no és el mateix que la importància, i reaccionar a la recència és una de les formes més fiables de deixar que el treball genuïnament important es perdi.
Una prova pràctica: pregunta't si encara consideraries això urgent si ho haguessis sentit fa sis mesos en lloc de la setmana passada. Si la resposta és no, és biaix de recència en acció, no prioritat estratègica. Registra-ho, avalua-ho calmadament contra la graella, i resisteix l'atracció d'avanç ràpid només perquè és fresc.
La graella no sempre produeix una resposta neta. Dos elements aterren en el mateix quadrant amb puntuacions similars, i encara així has de triar-ne un. En aquests casos, dos desempats són útils: alineació estratègica (quin et mou més a prop d'on vols estar en 18 mesos?) i reversibilitat (quin és més difícil de desfer si està equivocat?). Prefereix l'element més estratègicament alineat i més reversible.