En la majoria d'equips de producte, el backlog és un lloc on la urgència va a morir. Tot el que hi entra era urgent quan es va afegir: una queixa d'un client, una petició de vendes, una funció d'un competidor, una idea interna. Sis mesos després, tot continua allà, tot continua semblant urgent i ningú sap ben bé què cal fer primer.
El problema no és la manca d'eines. Hi ha dotzenes de marcs de priorització: RICE, MoSCoW, Kano, ICE, puntuació ponderada. El problema és que la majoria requereixen una mena de falsa precisió, que consisteix a assignar números a incògnites, i això els fa semblar rigorosos quan en realitat només blanquegen la intuïció amb un full de càlcul.
El que funciona de debò és més senzill: dues dimensions, valorades amb honestedat, i la disciplina d'actuar segons el resultat.
La priorització es redueix a dues preguntes. Primera: fins a quin punt això millora el resultat que ens importa? (Impacte.) Segona: quant ens costarà lliurar-ho? (Esforç.) Tota la resta és un refinament d'aquestes dues o una distracció que n'allunya.
De vegades s'hi afegeix la confiança com a tercera dimensió, «fins a quin punt estem segurs de l'impacte?», i val la pena tenir-la present. Però a la pràctica, la majoria d'equips saben quan van a cegues. La disciplina consisteix a etiquetar amb honestedat la suposició, no a puntuar-la en una escala d'1 a 5 i afegir-la a una fórmula.
La part difícil no és entendre la graella, sinó ser honest en omplir-la. Tots els equips tenen funcions que volen construir i que pertanyen als «pous de temps», però continuen reclassificant-les com a «grans apostes». El marc només funciona si l'equip és capaç de ser honest sobre l'impacte.
L'impacte és la dimensió que als equips els costa més d'avaluar, perquè sovint exigeix predir el futur. La temptació és puntuar-lo numèricament i sentir-se científic. Un enfocament millor és qualitatiu però estructurat.
Fes tres preguntes per a cada funció que estiguis considerant:
Els equips subestimen sistemàticament l'esforç. Està ben documentat (té a veure amb la fal·làcia de la planificació i el biaix d'optimisme) i és especialment marcat en les funcions que toquen diversos sistemes, requereixen coordinació entre equips o impliquen capacitats que l'equip no ha construït mai.
Dues pràctiques ajuden. Primer, pregunta sempre a enginyeria abans de puntuar l'esforç, no després. Els PM que puntuen l'esforç pel seu compte gairebé sempre el subestimen. Segon, fes servir el concepte d'«incògnites desconegudes» com a multiplicador explícit de l'esforç. Qualsevol funció que toqui una àrea nova del codi, una API de tercers o un flux d'usuari que no s'ha provat recentment mereix una puntuació d'esforç 1,5 vegades superior a la que suggereix la feina evident.
Gran part de la urgència d'un backlog de producte no és urgència real, sinó recència. Un client es va queixar la setmana passada, i per això la seva petició sembla urgent. Un competidor va llançar alguna cosa el mes passat, i per això igualar-ho sembla crític. Però la recència no és el mateix que la importància, i reaccionar a la recència és una de les maneres més segures de deixar que se't escapi la feina realment important.
Una prova pràctica: pregunta't si això et semblaria urgent si n'haguessis sentit a parlar fa sis mesos en lloc de la setmana passada. Si la resposta és que no, és biaix de recència en acció, no prioritat estratègica. Registra-ho, avalua-ho amb calma amb la graella i resisteix la temptació de donar-li via lliure només perquè és recent.
La graella no sempre dona una resposta neta. Dos elements acaben al mateix quadrant amb puntuacions semblants, i tot i així n'has de triar un. En aquests casos, van bé dos criteris de desempat: l'alineació estratègica (quin t'apropa més al punt on vols ser d'aquí a 18 mesos?) i la reversibilitat (quin és més difícil de desfer si ens equivoquem?). Tria l'element més alineat estratègicament i més reversible.