Priorizar en desarrollo web: la matriz P0, P1, P2

Cuando un proyecto acumula pendientes durante semanas, llega un punto en que el backlog ya no es un plan: es un inventario de ansiedad. Hay que hacer el formulario de contacto, arreglar el bug de móvil, revisar los textos de SEO, integrar el CRM, mover la web a un hosting más rápido, actualizar las dependencias, añadir analítica y revisar la accesibilidad. Todo es urgente. Nada avanza.

El problema rara vez es falta de trabajo. Es falta de criterio para ordenarlo.

La matriz P0/P1/P2 es el framework que uso para salir de ese bucle. No es compleja ni requiere software especial. Requiere que alguien tome la decisión de separar lo que bloquea de lo que suma valor de lo que puede esperar, y que esa decisión quede escrita y visible para todo el equipo o cliente.

1. Qué significa cada nivel

La nomenclatura viene del mundo del desarrollo de producto y la gestión de incidencias, pero su lógica es directamente aplicable a cualquier proyecto web.

P0 — Bloqueante. Si no se resuelve, el proyecto no puede avanzar, el negocio pierde dinero de forma directa o hay un riesgo legal o de seguridad activo. Un P0 no espera al próximo sprint: se resuelve ahora, hoy, aunque eso signifique parar todo lo demás. Ejemplos típicos: el formulario de contacto no envía, el checkout falla para un porcentaje de usuarios, hay datos personales expuestos, la web está caída. La definición clave es que un P0 no puede quedar pendiente al cerrar una iteración; si se cierra con P0 abiertos, no era un P0 real.

P1 — Alta prioridad, no bloqueante. Son issues importantes que afectan la experiencia o los objetivos del proyecto, pero con los que se puede operar. No justifican parar un lanzamiento, pero deben resolverse en la siguiente iteración o ciclo. Si se acumulan sin atenderse, acaban convirtiéndose en P0. Ejemplos: el LCP en móvil está por encima del umbral bueno, un formulario secundario tiene problemas de validación, hay errores de consola visibles, la navegación por teclado falla en un componente crítico.

P2 — Mejora planificable. Tareas que suman valor pero cuya ausencia no compromete el funcionamiento ni los objetivos inmediatos. Van al backlog con fecha orientativa, no con urgencia. Ejemplos: mejorar la descripción meta de posts antiguos, añadir un filtro en el blog, refactorizar un componente que funciona pero que está acoplado de más, revisar el copy de la página de servicios.

La trampa más habitual es que todo acabe en P0 o P1. Cuando eso pasa, la matriz pierde sentido: si nada puede esperar, nada tiene prioridad real.

2. Dos ejes para clasificar: impacto y esfuerzo

La letra P por sí sola no basta. Para asignar nivel con criterio necesitas cruzar dos variables:

• Impacto: ¿qué ocurre si esto no se resuelve? ¿Pierde dinero el negocio, pierde leads, pierde confianza, o simplemente pierde una oportunidad de mejora?
• Esfuerzo: ¿cuánto cuesta resolverlo? No solo en horas de desarrollo: también en riesgo de regresión, dependencias con terceros, necesidad de coordinación.

Un issue de impacto alto y esfuerzo bajo es el candidato perfecto para P0 o P1 con resolución rápida. Un issue de impacto bajo y esfuerzo alto es el candidato perfecto para P2 o para eliminarlo directamente del backlog.

El cruce que más confunde: impacto alto, esfuerzo también alto. Ahí es donde hay que ser honesto sobre los recursos disponibles. Una reconstrucción completa de la web puede tener impacto potencial altísimo, pero si no hay presupuesto ni plazo para ejecutarla bien, forzarla como P0 solo genera deuda técnica y proyectos a medias.

3. Aplicación práctica: tres escenarios habituales

Escenario A: reconstrucción desde WordPress

Un negocio tiene su web en WordPress con una plantilla pesada, plugins acumulados durante años y un rendimiento medible que penaliza el SEO y la conversión. El cliente quiere “renovar la web” y hay una lista de treinta cosas que mejorar.

Con la matriz, la conversación cambia:

• P0: La web actual tiene vulnerabilidades de seguridad activas por plugins sin actualizar, o hay páginas clave que no cargan en móvil. Eso va primero, antes de cualquier diseño nuevo.
• P1: El LCP está por encima de cuatro segundos en las páginas de servicio. La migración a un stack más ligero (Astro, por ejemplo) resuelve esto estructuralmente, y es la decisión que desbloquea el resto del trabajo.
• P2: Mejorar el copy de las páginas de blog antiguas, añadir schema markup detallado, revisar la paleta de colores en móvil. Todo esto suma, pero no bloquea la migración ni el lanzamiento.

El criterio aquí es claro: no tiene sentido invertir semanas en el copy si la web sigue sin cargar bien. Primero lo que desbloquea.

Escenario B: optimización de performance en una web existente

Una auditoría detecta varios problemas de Core Web Vitals: CLS elevado por imágenes sin dimensionar, INP malo por un script de terceros bloqueante, y algunas mejoras de accesibilidad pendientes en el formulario. Hay también una lista de features nuevas que el cliente quiere añadir.

• P0: Si el CLS y el INP están en zona roja y la web tiene tráfico orgánico significativo, eso afecta al posicionamiento activo. Resolverlo es P0 porque tiene coste medible en SEO ahora mismo.
• P1: Las mejoras de accesibilidad en el formulario. No bloquean el negocio hoy, pero son un riesgo legal potencial y un problema de UX real para una parte de los usuarios.
• P2: Las features nuevas. Añadir funcionalidad a una base con problemas de rendimiento es contraproducente: cada feature nueva puede empeorar lo que ya está mal.

En este escenario la matriz ayuda a decirle al cliente algo que no siempre quiere escuchar: las features esperan hasta que la base esté sana.

Escenario C: lanzamiento de un MVP

Un negocio quiere digitalizar un proceso que hoy gestiona con Excel y WhatsApp. Hay ideas para un panel de administración, notificaciones automáticas, integración con un CRM, exportación a PDF, un sistema de roles y permisos, y una app móvil.

• P0: El flujo mínimo que permite al negocio operar: crear un registro, visualizarlo y enviarlo al cliente. Sin eso, no hay MVP.
• P1: Autenticación básica y protección de datos. No es opcional si el proceso maneja información de clientes, aunque sea una versión simple.
• P2: Panel de administración avanzado, exportación a PDF, roles granulares, app móvil. Todo eso puede venir en iteraciones posteriores, una vez validado que el flujo base funciona y que los usuarios lo usan.

Este es el escenario donde la matriz salva más dinero: evita construir funcionalidad que nadie ha validado todavía. Si quieres profundizar en cómo abordar el alcance de un MVP antes de escribir la primera línea de código, el post Del Excel a tu primer producto digital desarrolla el proceso de definición desde cero.

4. Checklist para auditar tu backlog

Antes de asignar prioridades, asegúrate de que cada tarea del backlog puede responder estas preguntas. Si no puede, hay trabajo previo de definición que hacer.

Para cada tarea:

• ¿Qué pasa concretamente si esta tarea no se resuelve esta semana?
• ¿Afecta a la capacidad del negocio de operar o de captar clientes?
• ¿Tiene dependencias con otras tareas? ¿Bloquea o está bloqueada?
• ¿El esfuerzo de resolución es conocido o hay incertidumbre técnica significativa?
• ¿Tiene propietario claro (quién la resuelve)?

Para el backlog completo:

• ¿Hay más de dos o tres P0 abiertos simultáneamente? Si sí, revisión de criterios.
• ¿Los P2 llevan más de dos ciclos sin moverse? O se planifican con fecha o se eliminan.
• ¿Las features nuevas están en P2 mientras haya P0 o P1 sin resolver?
• ¿El cliente o el equipo ha validado el orden antes de empezar a ejecutar?

5. Cuándo la matriz no es suficiente

La matriz P0/P1/P2 es una herramienta de clasificación, no de estimación ni de planificación de capacidad. Sirve para ordenar; no dice cuánto tiempo llevará cada cosa ni si tienes recursos para ejecutarlo todo en el plazo esperado.

Dos situaciones en las que necesitas algo más:

• Backlog muy grande con interdependencias complejas: ahí la matriz se queda corta y necesitas un mapa de dependencias o un grafo de tareas antes de priorizar. Clasificar cien tareas sin entender qué bloquea qué no aclara nada.
• Decisiones estratégicas de producto: si la discusión es entre “construimos feature A o feature B para el próximo trimestre”, el P0/P1/P2 no es el marco adecuado. Ahí se necesita análisis de impacto en negocio, datos de usuarios y criterios de mercado. El marco que describe Atlassian de valor vs. esfuerzo —o modelos como RICE— complementan bien la clasificación de prioridad para ese tipo de decisiones.

La matriz P0/P1/P2 brilla en lo que es: un protocolo rápido de triage para decidir qué entra en la próxima iteración y en qué orden. Combinada con una estimación honesta de esfuerzo y con conversaciones claras con el cliente sobre qué es negociable, es suficiente para la mayoría de los proyectos web con los que trabajo.

Si quieres revisar cómo tienes estructurado tu backlog actual o necesitas un criterio externo para ordenar el trabajo de un proyecto nuevo, cuéntame en qué punto estás y lo vemos juntos.