Frameworks de Priorización

El Arte de Decir No: Priorización de Features

La priorización es la habilidad más importante y difícil de un PM. Siempre hay más ideas que capacidad para ejecutarlas. Tu trabajo es elegir las pocas que generarán el mayor impacto con el menor esfuerzo posible.

RICE Framework

• Reach (Alcance): ¿a cuántos usuarios afecta esta feature en un período dado? (número estimado)


• Impact (Impacto): ¿cuánto mejora la experiencia para esos usuarios? (3=masivo, 2=alto, 1=medio, 0.5=bajo)


• Confidence (Confianza): ¿qué tan seguro estás de estas estimaciones? (100%, 80%, 50%)


• Effort (Esfuerzo): ¿cuántas semanas-persona requiere? (1, 2, 4, 8...)


• Score = (Reach × Impact × Confidence) / Effort — compara scores para priorizar objetivamente

Matriz de Impacto vs Esfuerzo

• Alto impacto + Bajo esfuerzo = Quick Wins (hacer primero — son las victorias fáciles)


• Alto impacto + Alto esfuerzo = Big Bets (planificar para el próximo trimestre — valen la inversión)


• Bajo impacto + Bajo esfuerzo = Fill-ins (hacer cuando haya tiempo libre — no son urgentes)


• Bajo impacto + Alto esfuerzo = Money Pit (evitar — alto costo con poco retorno)


• Ubica cada feature en la matriz y el orden de prioridad se vuelve evidente

Otros frameworks útiles

• MoSCoW: clasifica features en Must have, Should have, Could have, Won't have (para definir scope de un release)


• Kano Model: categoriza features por satisfacción del usuario (básicas, de rendimiento, sorpresas deleitosas)


• ICE Scoring: versión simplificada de RICE — Impact × Confidence × Ease (escala 1-10 cada uno)


• Opportunity Scoring: pregunta a usuarios la importancia de una tarea y su satisfacción actual — la mayor brecha es tu mayor oportunidad

Reglas prácticas de priorización

• Si todo es prioridad 1, nada es prioridad 1 — fuerza un stack rank (lista ordenada sin empates)


• Prioriza resultados, no outputs: 'aumentar retención en 10%' es mejor meta que 'lanzar feature X'


• Incluye al equipo en la priorización — los desarrolladores ven complejidades que tú no ves


• Revisa prioridades cada 2 semanas — el mercado cambia y la información nueva debe alterar tu ranking


• Documenta POR QUÉ dijiste no a cada feature — lo vas a necesitar cuando te lo vuelvan a pedir

Consejo: La priorización no es un ejercicio matemático — es una negociación. Los frameworks te dan una base objetiva, pero al final necesitas juicio humano y consenso del equipo.

Aplicación práctica en un caso real

Aplicar Frameworks de Priorización dentro del contexto de Introducción a Product Management con criterio práctico, evitando quedarse en una definición aislada. Para que esta lección sea útil, imagina un escenario concreto: tienes que usar este tema para mejorar un proceso, tomar una decisión, crear un entregable o explicar una recomendación a otra persona. La pregunta no es solo “qué significa”, sino “qué haría diferente después de entenderlo”.

Un buen uso empieza por delimitar el problema. Define qué resultado quieres lograr, qué información tienes disponible, qué restricciones existen y cómo sabrás si la decisión fue correcta. Esta forma de pensar evita respuestas genéricas y convierte el aprendizaje en una herramienta de trabajo.

Marco de decisión

Antes de avanzar, revisa tres niveles: primero, el objetivo operativo; segundo, los recursos disponibles; tercero, el riesgo de equivocarte. En Introducción a Product Management, muchas decisiones fallan porque se copia una táctica sin entender el contexto. El marco correcto te obliga a adaptar, no solo repetir.

• Objetivo: qué resultado medible o visible quieres conseguir.
• Contexto: quién usará esto, con qué nivel de experiencia y bajo qué restricciones.
• Acción: cuál es el siguiente paso mínimo que puedes ejecutar hoy.
• Señal: qué evidencia vas a observar para decidir si funcionó.

Ejemplo guiado

Supón que debes implementar esta idea en una pequeña empresa o proyecto personal. En vez de intentar una versión perfecta, prepara una versión mínima: una plantilla, una prueba, una lista de control, una automatización simple, una página, un mensaje o una medición inicial. Luego pide feedback o compara el resultado contra una métrica.

Si el resultado mejora, documenta el proceso. Si no mejora, identifica si falló la hipótesis, la ejecución o la medición. Esta distinción es clave: muchas personas abandonan una buena idea por una mala primera ejecución, o escalan una mala idea porque miraron la métrica equivocada.

Errores frecuentes

• Confundir actividad con avance: hacer muchas tareas sin saber qué resultado persiguen.
• Copiar ejemplos sin adaptarlos al cliente, audiencia, equipo o nivel técnico real.
• No dejar evidencia: si no registras decisiones y resultados, no aprendes del proceso.
• Querer automatizar o escalar antes de validar que el enfoque básico funciona.

Ejercicio práctico

1. Escribe el objetivo de esta lección en una frase aplicada a tu caso.
2. Define un entregable pequeño que puedas crear en menos de una hora.
3. Lista tres criterios para evaluar si ese entregable está bien hecho.
4. Ejecuta una versión inicial y anota qué cambiarías en una segunda iteración.

Checklist de salida

• Puedo explicar el concepto con mis propias palabras.
• Tengo un ejemplo aplicado, no solo una definición.
• Sé qué error debo evitar primero.
• Tengo una acción concreta para practicar esta semana.