PRODUCT STRATEGY · PRIORIZACIÓN · STARTUPS
Publicado: 17 septiembre 2026 · Lectura editorial
Cómo priorizar un roadmap cuando todo parece importante
Cuando features, bugs, clientes y oportunidades compiten por la misma capacidad, priorizar no consiste en ordenar una lista. Consiste en decidir dónde existe suficiente evidencia para invertir ahora.
En una startup casi nunca faltan cosas por hacer.
Una feature solicitada por ventas. Un bug que lleva semanas pendiente. Una petición de un cliente importante. Una oportunidad comercial. Deuda técnica. Una idea del founder.
El problema aparece cuando todas reciben la misma etiqueta: prioridad. Un roadmap no debería representar todo lo que podríamos construir. Debería hacer visibles las decisiones sobre dónde utilizar una capacidad limitada.
01 · PRODUCT STRATEGY
Priorizar no es ordenar una lista
Mover iniciativas hacia arriba o abajo organiza trabajo. No necesariamente mejora la decisión.
SVPG distingue entre organizaciones orientadas a features/output y equipos orientados a problemas y outcomes. En el primer modelo, los equipos reciben iniciativas priorizadas por stakeholders. En el segundo, Product Leadership identifica los problemas críticos y outcomes que vale la pena perseguir.
La diferencia parece pequeña, pero cambia la pregunta: no “¿Cuál feature hacemos primero?”, sino “¿Cuál problema merece capacidad ahora?”.
FEATURE ROADMAP
- Feature A
- Feature B
- Feature C
- Feature D
DECISION ROADMAP
- Problema
- Evidencia
- Outcome esperado
- Decisión
Un backlog ordenado no es necesariamente una estrategia.
02 · FRAMEWORKS
Los frameworks no responden la misma pregunta
RICE, Opportunity Scoring y Cost of Delay pueden ayudar a priorizar, pero utilizan señales diferentes. No deberían aplicarse como fórmulas intercambiables.
| Framework | Pregunta | Variables | Útil cuando | Riesgo |
|---|---|---|---|---|
| RICE | ¿Qué iniciativa combina alcance, impacto, confianza y esfuerzo? | Reach · Impact · Confidence · Effort. Reach × Impact × Confidence / Effort. | Necesitamos comparar iniciativas heterogéneas con estimaciones relativamente comparables. | Convertir estimaciones débiles en una puntuación aparentemente precisa. |
| OPPORTUNITY SCORING | ¿Dónde existe una necesidad importante que actualmente está mal satisfecha? | Importancia · Satisfacción actual. | Tenemos evidencia suficiente de usuarios/clientes para comparar necesidades. | Priorizar solicitudes o soluciones en lugar del outcome subyacente. |
| COST OF DELAY / WSJF | ¿Qué valor perdemos por retrasar esta iniciativa? | Valor usuario/negocio · Criticidad temporal · Reducción de riesgo/oportunidad · Tamaño o duración. | El tiempo modifica significativamente el valor de una decisión. | Asignar números relativos sin evidencia económica o estratégica. |
03 · PRODUCT EVIDENCE
Un score no mejora la evidencia que lo alimenta.
En RICE, Reach funciona mejor cuando parte de comportamiento observable y Confidence permite hacer explícito cuánto sabemos —o cuánto estamos estimando— sobre el impacto esperado. La puntuación sirve para estructurar una conversación. No convierte una hipótesis en un hecho.
04 · DECISION FRAME
Antes del score, estructura la decisión
01
PROBLEM
¿Qué situación queremos modificar?
02
EVIDENCE
¿Qué sabemos realmente?
03
EXPECTED OUTCOME
¿Qué comportamiento o resultado debería cambiar?
04
URGENCY
¿Qué ocurre si esperamos?
05
CAPACITY
¿Qué capacidad consume?
06
UNCERTAINTY
¿Qué supuesto podría cambiar la prioridad?
Sólo después tiene sentido decidir si RICE, Cost of Delay u otro mecanismo ayuda a ordenar las opciones. El framework no debe decidir por el equipo. Debe hacer visibles los supuestos detrás de la decisión.
05 · PRIORIZACIÓN EN PRÁCTICA
Cuatro iniciativas. Una capacidad limitada.
Pensemos en una startup B2B SaaS con cuatro opciones compitiendo por la misma capacidad del equipo. La matriz no asigna un ganador artificial: hace visibles los distintos tipos de evidencia y presión.
| Iniciativa | Evidencia | Urgencia | Impacto esperado | Incertidumbre | Siguiente decisión |
|---|---|---|---|---|---|
| A · Rediseñar dashboard | Solicitud recurrente de varios usuarios. | Media | Todavía poco definido. | ¿La fricción afecta comportamiento o sólo preferencia? | Precisar el problema y buscar señal de uso. |
| B · Corregir fallo en activación | Analytics muestran caída fuerte antes de primera acción de valor. | Alta | Mejorar llegada a valor. | ¿La caída es UX, técnica o de expectativa? | Segmentar la caída y revisar evidencia existente. |
| C · Feature enterprise | Un prospect relevante condiciona el contrato a esta capacidad. | Temporal | Habilitar una decisión comercial concreta. | ¿Es una necesidad repetible o un caso aislado? | Determinar alcance y coste de oportunidad. |
| D · Nuevo sistema de filtros | Petición frecuente, sin evidencia de impacto en comportamiento o revenue. | Baja/media | Aún no demostrable. | ¿Qué decisión mejoraría para el usuario? | No comprometer capacidad hasta estructurar la evidencia. |
La matriz no decide automáticamente qué construir. Muestra dónde existe evidencia, dónde existe presión temporal y dónde todavía estamos comparando opiniones.
06 · DECISION
Decir sí también significa decidir qué no hacer todavía
La capacidad del equipo es finita. Aceptar una iniciativa consume capacidad que ya no estará disponible para otra.
Por eso una buena priorización no sólo explica por qué algo entra al roadmap. También permite explicar por qué otra iniciativa todavía no.
Un roadmap útil no contiene todo lo que podríamos hacer. Representa aquello que decidimos que importa ahora y la evidencia que sostiene esa decisión.
PRODUCT & UX DIAGNOSTIC
¿Todo parece prioridad en tu producto?
Analiza tu situación de producto y obtén una primera lectura sobre la evidencia disponible, lo que todavía necesitas entender y cuál podría ser el siguiente movimiento.