En la mayoría de equipos de producto, el backlog es un lugar donde la urgencia va a morir. Todo lo que entra estaba urgente cuando se añadió: una queja de cliente, una solicitud de ventas, una característica de competidor, una idea interna. Seis meses después, todo sigue ahí, se siente urgente, y nadie sabe bien qué hacer primero.
El problema no es la falta de herramientas. Hay docenas de marcos de priorización: RICE, MoSCoW, Kano, ICE, puntuación ponderada. El problema es que la mayoría de marcos requieren una especie de falsa precisión, asignando números a incógnitas, lo que los hace parecer rigurosos mientras realmente solo lavan intuición a través de una hoja de cálculo.
Lo que realmente funciona es más simple: dos dimensiones, evaluadas honestamente, y la disciplina de actuar en el resultado.
La priorización colapsa en dos preguntas. Primero: ¿cuánto mejora esto el resultado que nos importa? (Impacto.) Segundo: ¿cuánto nos costará entregarla? (Esfuerzo.) Todo lo demás es un refinamiento de estas dos o una distracción de ellas.
Confianza a veces se añade como tercera dimensión, "¿cuán seguros estamos del impacto?", y vale la pena tener en mente. Pero en la práctica, la mayoría de equipos saben cuándo están adivinando. La disciplina es etiquetar la adivinanza honestamente, no calificarla en una escala de 1-5 y añadirla a una fórmula.
La parte difícil no es entender la cuadrícula; es ser honesto al llenarla. Cada equipo tiene características que quiere construir que pertenecen a "Sumideros de Tiempo" pero sigue reclasificándolas como "Apuestas Grandes". El marco solo funciona si el equipo puede ser honesto sobre impacto.
El impacto es la dimensión que los equipos encuentran más difícil de evaluar, porque a menudo requiere predecir el futuro. La tentación es calificarlo numéricamente y sentirse científico. Un mejor enfoque es cualitativo pero estructurado.
Haz tres preguntas para cada característica bajo consideración:
Los equipos subestiman sistemáticamente el esfuerzo. Esto está bien documentado (relacionado con la falacia de planificación y sesgo optimista) y es particularmente pronunciado para características que tocan múltiples sistemas, requieren coordinación entre equipos, o involucran capacidades que el equipo no ha construido antes.
Dos prácticas ayudan. Primero, siempre pregunta a ingeniería antes de calificar esfuerzo, no después. Los PMs que califican esfuerzo unilateralmente casi siempre subestiman. Segundo, usa el concepto de "incógnitas desconocidas" como multiplicador de esfuerzo explícito. Cualquier característica que toque un área nueva de codebase, una API de terceros, o un flujo de usuario no probado recientemente merece una puntuación de esfuerzo 1.5x más alta que el trabajo obvio sugiere.
La mayoría de urgencia en un backlog de producto no es urgencia real; es recencia. Un cliente se quejó la semana pasada, así que su solicitud se siente apremiante. Un competidor lanzó algo el mes pasado, así que igualarlo se siente crítico. Pero recencia no es lo mismo que importancia, y reaccionar a recencia es una de las formas más confiables de dejar que el trabajo genuinamente importante se escape.
Una prueba práctica: pregúntate si aún considerarías esto urgente si lo hubieras escuchado hace seis meses en lugar de la semana pasada. Si la respuesta es no, es sesgo de recencia en funcionamiento, no prioridad estratégica. Regístralo, evalúalo calmadamente contra la cuadrícula, y resiste el tirón de avance rápido solo porque está fresco.
La cuadrícula no siempre produce una respuesta limpia. Dos elementos aterrizan en el mismo cuadrante con puntuaciones similares, y aún tienes que elegir uno. En estos casos, dos desempates son útiles: alineación estratégica (¿cuál te mueve más cerca de donde quieres estar en 18 meses?) y reversibilidad (¿cuál es más difícil de deshacer si está equivocado?). Prefiere el elemento más estratégicamente alineado y más reversible.