Cómo priorizar funcionalidades cuando todo parece urgente

Por el equipo de FabricLoop  ·  Mayo 2026  ·  6 minutos de lectura

En la mayoría de los equipos de producto, el backlog es el lugar donde la urgencia va a morir. Todo lo que entra era urgente cuando se añadió: una queja de un cliente, una petición de ventas, una funcionalidad de la competencia, una idea interna. Seis meses después, todo sigue ahí, todo sigue pareciendo urgente y nadie sabe bien qué hacer primero.

El problema no es la falta de herramientas. Hay decenas de marcos de priorización: RICE, MoSCoW, Kano, ICE, puntuación ponderada. El problema es que la mayoría exigen una especie de falsa precisión —asignar números a incógnitas— que les da apariencia de rigor cuando en realidad solo blanquean la intuición pasándola por una hoja de cálculo.

Lo que de verdad funciona es más sencillo: dos dimensiones, evaluadas con honestidad, y la disciplina de actuar en consecuencia.

Las únicas dos dimensiones que importan

La priorización se reduce a dos preguntas. Primera: ¿cuánto mejora esto el resultado que nos importa? (Impacto.) Segunda: ¿cuánto nos costará entregarlo? (Esfuerzo.) Todo lo demás es un refinamiento de estas dos o una distracción de ellas.

A veces se añade la confianza como tercera dimensión —«¿qué grado de certeza tenemos sobre el impacto?»— y conviene tenerla presente. Pero, en la práctica, la mayoría de los equipos saben cuándo están adivinando. La disciplina consiste en etiquetar esa suposición con honestidad, no en puntuarla del 1 al 5 y meterla en una fórmula.

Lo difícil no es entender la cuadrícula, sino ser honesto al rellenarla. Todos los equipos tienen funcionalidades que quieren construir y que pertenecen a los «sumideros de tiempo», pero que siguen reclasificando como «grandes apuestas». El marco solo funciona si el equipo es capaz de ser honesto sobre el impacto.

Evaluar el impacto sin falsa precisión

El impacto es la dimensión que a los equipos les cuesta más evaluar, porque a menudo exige predecir el futuro. La tentación es puntuarlo numéricamente y sentirse científico. Un enfoque mejor es cualitativo pero estructurado.

Hazte tres preguntas para cada funcionalidad que estés valorando:

• ¿Qué problema concreto del usuario resuelve esto? Si no puedes nombrar un problema concreto y recurrente, el argumento del impacto es débil.
• ¿Cuántos usuarios tienen este problema y con qué frecuencia? El impacto es frecuencia por intensidad. Una frustración leve para todos no es lo mismo que un obstáculo grave para unos pocos.
• ¿Qué pasa si no lo construimos? Si la respuesta es «no mucho», reclasifícalo. Si la respuesta es «los usuarios se van» o «perdemos ventas», el impacto es real.

Evaluar el esfuerzo sin subestimarlo

Los equipos subestiman sistemáticamente el esfuerzo. Está bien documentado —tiene que ver con la falacia de la planificación y el sesgo de optimismo— y se acentúa en las funcionalidades que afectan a varios sistemas, exigen coordinación entre equipos o requieren capacidades que el equipo no ha desarrollado antes.

Dos prácticas ayudan. Primera: pregunta siempre a ingeniería antes de puntuar el esfuerzo, no después. Los PM que puntúan el esfuerzo por su cuenta casi siempre lo subestiman. Segunda: usa el concepto de «incógnitas desconocidas» como multiplicador explícito del esfuerzo. Cualquier funcionalidad que afecte a una parte nueva del código, a una API de terceros o a un flujo de usuario que no se ha probado recientemente merece una puntuación de esfuerzo 1,5 veces superior a la que sugiere el trabajo evidente.

La ilusión de urgencia

Buena parte de la urgencia de un backlog de producto no es urgencia real, sino recencia. Un cliente se quejó la semana pasada, así que su petición parece apremiante. Un competidor lanzó algo el mes pasado, así que igualarlo parece crítico. Pero recencia no es lo mismo que importancia, y reaccionar a lo reciente es una de las formas más seguras de dejar que se escape el trabajo realmente importante.

Una prueba práctica: pregúntate si seguirías considerándolo urgente si te hubieras enterado hace seis meses en lugar de la semana pasada. Si la respuesta es no, lo que actúa es el sesgo de recencia, no una prioridad estratégica. Regístralo, evalúalo con calma en la cuadrícula y resiste la tentación de saltarte la cola solo porque es reciente.

Cuando la cuadrícula da un empate

La cuadrícula no siempre da una respuesta clara. Dos elementos acaban en el mismo cuadrante con puntuaciones similares y aun así tienes que elegir uno. En estos casos son útiles dos criterios de desempate: la alineación estratégica (¿cuál te acerca más a donde quieres estar dentro de 18 meses?) y la reversibilidad (¿cuál es más difícil de deshacer si resulta ser un error?). Elige el elemento más alineado estratégicamente y más reversible.