Cómo priorizo cuando todo es prioritario
En la práctica, todos los stakeholders tienen razones legítimas para que su petición sea prioritaria. El trabajo del PM es navegar esa presión con criterio propio y un proceso transparente.
“Todo es prioritario” no es un problema de comunicación. Es el estado natural de cualquier equipo de producto que tiene más demanda que capacidad de entregar, que es prácticamente todos.
La versión honesta del problema: hay cinco stakeholders que tienen cinco iniciativas legítimamente importantes, hay capacidad para dos, y ningún framework de priorización resuelve eso de forma matemática.
Lo que sigue es cómo lo resuelvo yo en la práctica. No es una fórmula universal. Es mi proceso actual, con sus imperfecciones.
Empezar por el objetivo, no por las iniciativas
El error que cometí durante mucho tiempo fue intentar priorizar iniciativas entre sí directamente. Comparar “mejora del onboarding” con “nueva funcionalidad de reporting” es difícil porque son cosas distintas que pueden responder a objetivos distintos.
Lo que funciona mejor es empezar por el objetivo. ¿Cuál es el resultado más importante que el producto tiene que generar en los próximos tres meses? Si eso está claro, la priorización de iniciativas se hace contra ese criterio.
“Mejora del onboarding” puede ser más o menos relevante dependiendo de si el objetivo es aumentar la activación de nuevos usuarios o aumentar el valor por usuario activo existente. Sin el objetivo claro, estoy comparando peras con manzanas.
La pregunta que desbloquea el 80% de los casos
Cuando tengo dos iniciativas candidatas y no sé cuál priorizar, la pregunta que más me ayuda es: ¿qué nos diría que estamos equivocados?
Para cada iniciativa, trato de articular cuál sería la señal de que la hipótesis detrás de ella es incorrecta. Qué tendría que pasar para que yo dijera “esto no era tan prioritario como pensaba”.
Si no puedo articular esa señal, probablemente no tengo claridad suficiente sobre la hipótesis de valor de la iniciativa. Y sin esa claridad, la priorización es más política que de producto.
Hacer el coste de oportunidad explícito
Una de las razones por las que “todo es prioritario” se mantiene como situación crónica en algunos equipos es que nadie hace explícito el coste de oportunidad.
Cuando priorizo A sobre B, no solo estoy diciendo que A es más importante. Estoy diciendo que posponer B hasta después de A es aceptable dado el contexto actual. Esa segunda parte de la decisión raramente se comunica, y genera expectativas no cumplidas.
Lo que he encontrado útil: cuando comunico una decisión de priorización, comunico también qué no estamos haciendo y por qué. “Hemos decidido priorizar la mejora del onboarding sobre el reporting avanzado porque el objetivo del Q3 es la activación, y el reporting beneficia principalmente a usuarios ya activados. Revisaremos esta decisión cuando revisemos el objetivo del Q4.”
Esa comunicación no hace felices a todos. Pero crea un contexto donde la conversación puede continuar con más productividad.
Cuándo el proceso formal ayuda y cuándo no
Los frameworks de priorización (RICE, ICE, MoSCoW, Impact/Effort) son útiles para estructurar el pensamiento y generar transparencia en el proceso. No son útiles para tomar la decisión en mi lugar.
Los uso como herramienta de alineación, no como generadores automáticos de decisión. El valor real de hacer un ejercicio de RICE con el equipo no está tanto en el número final como en las conversaciones que genera: “¿por qué estimamos el alcance de esta iniciativa tan diferente?” “¿por qué tienes tanta más confianza en el impacto de esa que yo?”
Esas conversaciones revelan información y alinean criterios. Los números son un medio, no el fin.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.