Marcos de priorización del roadmap: cómo elegir uno
Marcos de priorización del roadmap: cómo elegir uno El mejor marco de priorización del roadmap es el que su equipo aplicará de forma coherente con los datos de los que realmente dispone.
Marcos de priorización de hojas de ruta: cómo elegir uno
El mejor marco de priorización de hojas de ruta es el que su equipo aplicará de forma coherente con los datos de los que realmente dispone. Para la mayoría de los equipos, eso significa una matriz de valor frente a complejidad cuando la evidencia es escasa, RICE o una puntuación ponderada cuando dispone de datos de uso y hay muchos elementos que compiten entre sí, y MoSCoW cuando una fecha límite fija obliga a hacer concesiones en el alcance. El marco importa menos que los criterios que acuerden, quién puntúa y con qué frecuencia revisan el resultado.
Esta guía está dirigida a líderes empresariales, de producto y de tecnología que tienen que defender un roadmap ante las partes interesadas y después entregarlo. Explicamos qué mide cada marco habitual, cómo elegir entre ellos, cómo llevar a cabo el proceso y cómo mantener la honestidad del backlog una vez definido el roadmap.
Conclusiones clave
- Elija un marco según sus recursos de partida: los datos de los que dispone, el número de elementos y cuántas partes interesadas deben llegar a un acuerdo. No según su popularidad.
- Acuerden los criterios y las escalas de puntuación antes de que nadie puntúe un elemento. La mayoría de las disputas son, en realidad, desacuerdos sobre los criterios.
- Trate las puntuaciones como información para tomar una decisión, no como la decisión en sí. Unos datos de partida inciertos producen cifras que parecen precisas, pero que siguen siendo estimaciones.
- Asigne los temas clasificados por prioridad a horizontes temporales y etiquete los niveles de compromiso para que las partes interesadas sepan qué está prometido y qué es una apuesta.
- Involucre a ingeniería en la puntuación. Las estimaciones de esfuerzo y riesgo solo son tan buenas como las personas que desarrollarán el trabajo.
Índice
- Qué hace realmente un marco de priorización
- Los marcos habituales, comparados
- Cómo elegir: cinco preguntas
- Lleve a cabo el proceso en seis pasos
- Mantenga la honestidad de las puntuaciones
- Alinee el roadmap con la estrategia
- Del roadmap al backlog
- Errores habituales
- Dónde el apoyo de ingeniería hace posible una priorización eficaz
- Preguntas frecuentes
- Fuentes
Qué hace realmente un marco de priorización
Un marco proporciona a un equipo principios coherentes para sopesar las oportunidades frente a limitaciones como los objetivos empresariales, el valor para el cliente, los requisitos del producto y los recursos disponibles, de modo que el siguiente trabajo se elija deliberadamente y no por instinto (Atlassian). Ese es todo su cometido. No genera la estrategia ni elimina la necesidad de aplicar criterio.
Su segundo beneficio es político. Un líder de producto citado por Gusto señala que los marcos permiten a los responsables de producto decir «no» o «ahora no» a las partes interesadas basándose en un razonamiento defendible y no en una opinión personal (Gusto). Si alguna vez ha visto cómo el ejecutivo más insistente gana un debate sobre el roadmap, sabe por qué eso importa.
Nielsen Norman Group describe la priorización del roadmap como una secuencia: establecer los criterios, puntuar los temas según ellos, imponer un orden de prioridad y, después, asignar los temas con mayor prioridad a horizontes temporales más cercanos (NN/g). Todos los marcos que se presentan a continuación son variaciones de esa secuencia. Se diferencian en lo que puntúan y en la cantidad de datos que exigen.

Los marcos habituales, comparados
NN/g enumera los marcos a los que recurren la mayoría de los equipos: matrices de valor frente a complejidad o de impacto frente a esfuerzo, puntuación ponderada, RICE, MoSCoW, Kano y viabilidad técnica-deseabilidad-viabilidad empresarial (NN/g). Así se comparan en la práctica.
| Marco | Qué evalúa | Datos necesarios | Más adecuado para |
|---|---|---|---|
| Valor frente a complejidad | Valor empresarial o para el cliente frente al esfuerzo de implementación | Bajo | Productos en fase inicial y sesiones rápidas de alineación |
| RICE | Alcance, impacto, confianza y esfuerzo | Medio a alto | Productos maduros con datos de uso y listas extensas |
| Puntuación ponderada | Criterios personalizados con pesos cuya suma es del 100 % | Medio | Múltiples objetivos con distinta importancia |
| MoSCoW | Debe, debería, podría, no se hará | Bajo | Lanzamientos con alcance fijo y trabajo condicionado por plazos |
| Kano | Respuesta de satisfacción del cliente ante las funcionalidades | Alta (investigación con clientes) | Decidir qué funcionalidades deleitan y cuáles son requisitos básicos |
| Viabilidad técnica, deseabilidad y viabilidad empresarial | Adecuación técnica, para el usuario y empresarial | Medio | Nuevos conceptos que necesitan cumplir los tres aspectos |
Valor frente a complejidad
Se trata de una matriz 2x2 que representa el valor empresarial o para el cliente previsto frente a la complejidad de implementación (Productboard). Los elementos de alto valor y baja complejidad son las prioridades más claras, mientras que los de bajo valor y alta complejidad son candidatos a posponerse (ProductPlan).
Su ventaja es la rapidez: un equipo puede aplicarla en un solo taller. Su desventaja es que el «valor» es lo que la sala decida que es. Resérvela para decisiones iniciales y añada cifras cuando las tenga.
RICE
RICE puntúa cada iniciativa según su alcance, impacto, confianza y esfuerzo. NN/g presenta la fórmula como el alcance multiplicado por el impacto y la confianza, dividido por el esfuerzo, donde los factores representan a los usuarios afectados, el valor para el usuario, la confianza en las estimaciones y el trabajo necesario para implementar la iniciativa (NN/g). El factor de confianza es lo que lo hace honesto: una idea importante de la que sabe poco recibe una puntuación menor.
Un ejemplo práctico. Supongamos que una mejora de incorporación autónoma llega a 4.000 usuarios por trimestre, tiene una puntuación de impacto media de 1, usted tiene un 80 % de confianza y cuesta 2 persona-meses. La puntuación es (4.000 x 1 x 0,8) / 2 = 1.600. Una función de informes que llega a 500 usuarios, con un impacto alto de 2, un 50 % de confianza y 4 persona-meses, obtiene (500 x 2 x 0,5) / 4 = 125. Las cifras son ilustrativas, pero muestran cómo RICE puede desbancar a la opción favorita de un ejecutivo. ProductPlan señala que el método puede ayudar a reducir los sesgos personales y facilitar la defensa de las prioridades (ProductPlan).

Puntuación ponderada
La puntuación ponderada calcula una media ponderada de las puntuaciones correspondientes a criterios personalizados, cuyos pesos suman el 100 % (Productboard). Si su estrategia establece que este año la retención importa el doble que la adquisición, los pesos pueden reflejarlo. Es adecuada para organizaciones cuyos objetivos no se reducen a una sola métrica y obliga a abordar abiertamente la conversación sobre la estrategia.
MoSCoW
MoSCoW clasifica el trabajo en Imprescindible, Debería incluirse, Podría incluirse y No se incluirá por ahora, lo que ayuda al equipo a aportar valor incremental en todas las categorías (Aha!). Es la herramienta adecuada cuando la fecha es fija y el alcance es la variable que puede ajustarse. Su riesgo es la inflación de categorías: si todo es imprescindible, no se ha priorizado nada. Limite los elementos imprescindibles a aquello sin lo cual la versión realmente no puede publicarse.
Kano
Kano clasifica las funcionalidades según el grado en que satisfacen las necesidades de los clientes, agrupando las ideas en segmentos como Rendimiento, Imprescindible, Atractivo e Indiferente, y recomienda desarrollar todas salvo las del grupo Indiferente (Aha!). Requiere investigación de clientes, por lo que resulta adecuada para equipos que ya realizan encuestas o entrevistas y quieren saber qué funcionalidades generan entusiasmo.
Viabilidad técnica, deseabilidad y viabilidad empresarial
Este enfoque plantea si algo puede construirse, si los usuarios lo quieren y si funciona para el negocio. Es útil para conceptos nuevos en los que un punto débil hace fracasar la idea, por muy sólidos que sean los otros dos.
Cómo elegir: cinco preguntas
Atlassian sugiere seleccionar un marco según los objetivos del proyecto, la complejidad del producto, la experiencia del equipo y los datos disponibles (Atlassian). Convirtamos eso en cinco preguntas prácticas.
- ¿Qué datos tiene hoy? Si no tiene datos de uso ni de clientes, RICE producirá suposiciones disfrazadas de aritmética. Empiece por valor frente a complejidad.
- ¿Cuántos elementos compiten entre sí? Con menos de quince, bastarán una matriz y una conversación. Con más de cincuenta, necesita un modelo de puntuación para que el debate siga siendo manejable.
- ¿Hay una fecha fija? Una fecha límite apunta a MoSCoW. Un horizonte abierto apunta a la puntuación.
- ¿Cuántos objetivos tiran en direcciones distintas? Varios objetivos desiguales requieren una puntuación ponderada.
- ¿Quién debe estar de acuerdo? Si los ejecutivos escépticos necesitan ver la lógica, elija el marco con los criterios más transparentes, no el más sofisticado.
Muchos equipos terminan combinando dos. Un patrón habitual es utilizar RICE o una puntuación ponderada para ordenar la lista larga y, después, valor frente a complejidad para comprobar la sensatez de los elementos principales con el equipo de ingeniería presente.
Ejecute el proceso en seis pasos
Las directrices de NN/g sobre la creación de hojas de ruta ofrecen una secuencia que funciona con cualquiera de los marcos anteriores (NN/g). Aquí está, junto con los puntos en los que suele fallar.
- Defina el propósito y el alcance. Decida si esta hoja de ruta es para un trimestre o un año, y para quién está destinada. Una hoja de ruta para el consejo de administración y otra para el equipo de desarrollo son documentos diferentes.
- Recopile las aportaciones y agrúpelas por temas. Recopile las solicitudes de las partes interesadas, así como datos de investigación y soporte. Agrúpelas en problemas que resolver, en lugar de crear una larga lista de solicitudes de funcionalidades. Puntuar los temas le ayuda a no perderse en los detalles.
- Acuerden los criterios y las escalas. Entre los criterios de ejemplo de NN/g se incluyen el impacto en los usuarios, el porcentaje de usuarios afectados, la gravedad del problema, la alineación estratégica, la diferenciación, el ROI y el esfuerzo. Elija entre cuatro y seis, defina qué significan 1 y 5 para cada uno y déjelo por escrito.
- Puntúe con las personas que conocen el tema. Involucre a colegas con conocimientos pertinentes. Los ingenieros puntúan el esfuerzo y el riesgo, el equipo de soporte puntúa la gravedad del problema y ventas puntúa el impacto en los acuerdos comerciales. Que un responsable de producto puntúe por sí solo es la forma más rápida de perder la confianza.
- Calcule y establezca un orden forzoso. Los empates son una señal para debatir, no para dejarlos sin resolver. Establecer un orden forzoso hace visibles las concesiones.
- Asigne los temas a horizontes, debátalos y ajústelos. Coloque los temas con mayor puntuación en el horizonte más cercano, revise el resultado con las partes interesadas y vuelva a evaluarlo periódicamente.
Una estructura basada en horizontes temporales no es exclusiva del trabajo de producto. Un ejemplo es una hoja de ruta de 30/90/180 días para ampliar las operaciones, que muestra cómo pueden organizarse por etapas los compromisos a corto, medio y largo plazo en función de un objetivo.
Mantenga la honestidad de las puntuaciones
Los modelos de puntuación proporcionan al equipo un lenguaje común, pero pueden crear una falsa sensación de objetividad cuando los datos de entrada son inciertos (airfocus). Tres hábitos ayudan a evitarlo.
- Registre el nivel de confianza junto a cada estimación. Una puntuación basada en una encuesta a 2.000 usuarios y otra basada en una intuición no deberían parecer igual de sólidas.
- Vuelva a puntuar cuando llegue nueva información. Una prueba de prototipo o un análisis exploratorio puede cambiar el esfuerzo y el impacto de la noche a la mañana. El descubrimiento no es una etapa que se supera una sola vez; sigue alimentando la clasificación. Para saber cómo la IA está cambiando ese ciclo, consulte nuestro artículo sobre IA y descubrimiento de producto.
- Deje que el número abra el debate, no que lo cierre. Si la clasificación sorprende a todo el mundo, es posible que un criterio sea incorrecto o que se haya pasado por alto una idea. Vale la pena descubrir cuál de las dos cosas ocurre.
Alinee la hoja de ruta con la estrategia
Un enfoque centrado en los objetivos vincula las posibles funcionalidades con objetivos empresariales medibles y con la visión del producto, mientras los responsables de producto revisan y vuelven a priorizar periódicamente el backlog junto con ingeniería y otros equipos (Aha!). En la práctica, redacte los dos o tres objetivos del periodo antes de recopilar ideas. Todo aquello que no pueda vincularse con uno de ellos necesita una justificación para estar en la lista.
Las partes interesadas deben participar desde el principio y conocer el marco acordado, lo que reduce las objeciones y fomenta la responsabilidad compartida (Product School). La misma fuente cita a un ejecutivo de la NBA que habla de invertir en las relaciones con las partes interesadas para que las prioridades de la hoja de ruta respalden la visión general de la organización. La mecánica es sencilla: pregunte a cada parte interesada por el resultado del que responde y muéstrele dónde se sitúa en la clasificación.
Etiquete los niveles de compromiso
Las hojas de ruta comunican con mayor honestidad cuando las iniciativas incluyen niveles de compromiso como comprometidos, planificados, en descubrimiento o en validación, y apuestas condicionales (airfocus). Esto evita que un elemento especulativo del tercer horizonte se interprete como una promesa. También proporciona a ingeniería una forma defendible de indicar que un elemento todavía está en proceso de validación.
Establezca una periodicidad
Una guía sugiere priorizar cada 6 a 8 semanas en las empresas pequeñas y trimestralmente en las organizaciones grandes (Productboard). Elija un ritmo y respételo. Una hoja de ruta que solo se revisa cuando algo falla es una hoja de ruta en la que nadie confía.
De la hoja de ruta al backlog
La hoja de ruta marca la dirección; el backlog es donde esa dirección se convierte en trabajo. El refinamiento es el puente, y la misma disciplina se aplica a menor escala.
- Mantenga pequeña y preparada la parte superior del backlog. Los elementos que probablemente comiencen en el próximo sprint o en los dos siguientes deberían tener un resultado claro, criterios de aceptación y una estimación. Todo lo demás puede mantenerse como una aproximación.
- Vincule cada elemento con un tema. Si un elemento no puede vincularse con un tema de la hoja de ruta, es un error, una tarea de mantenimiento o ruido. Indique cuál de ellos es.
- Incluya al equipo de ingeniería en el refinamiento. Los ingenieros detectan dependencias y complejidad oculta antes de que se conviertan en sorpresas durante el sprint, y sus estimaciones se incorporan directamente al componente de esfuerzo de su puntuación.
- Haga una depuración periódica. Los elementos que han permanecido intactos durante varios ciclos de planificación normalmente no son prioridades. Ciérrelos o muévalos a una lista de asuntos pendientes, y comuníquelo.
- Vuelva a clasificar cuando cambie la hoja de ruta. Una nueva clasificación trimestral debería cambiar visiblemente el orden del backlog en cuestión de días, no de semanas.
Quién es responsable de estas decisiones depende de la organización. Si está valorando si necesita un responsable de producto, un director de proyectos o un analista de negocio, nuestra guía sobre qué función necesita expone las diferencias.
Errores frecuentes
- Puntuar antes de acordar los criterios. El debate se produce entonces sobre las puntuaciones, donde es más difícil resolver las discrepancias.
- Usar un único marco para todas las decisiones. La priorización de la corrección de errores y una apuesta por una plataforma a tres años requieren enfoques distintos.
- Ignorar el esfuerzo hasta el final. Las clasificaciones basadas únicamente en el valor colocan los elementos costosos en los primeros puestos y hacen descarrilar el plan durante el primer mes. Obtenga pronto las estimaciones del equipo de ingeniería.
- Tratar la hoja de ruta como algo permanente. La recomendación de NN/g es actualizarla periódicamente, no congelarla.
- Ocultar el método. Si las partes interesadas no pueden ver cómo se ha obtenido una puntuación, la tratarán como otra opinión más.
Cuándo el apoyo de ingeniería hace que la priorización funcione
La priorización solo resulta útil si los elementos clasificados pueden entregarse con el esfuerzo que se les ha asignado. Las estimaciones de esfuerzo, las limitaciones de arquitectura y el riesgo de integración son los datos que más suelen ser incorrectos cuando los equipos de producto e ingeniería planifican por separado. En Ridiculous Engineering, los clientes trabajan directamente con ingenieros sénior, con apoyo desde el descubrimiento hasta la mejora a largo plazo. Si necesita información sobre esfuerzo y viabilidad para una posible hoja de ruta, nuestro apoyo de consultoría y entrega de software está pensado para esa conversación. Si el primer puesto de su clasificación resulta ser un desarrollo a medida, consulte nuestros servicios de desarrollo de software a medida . Y si está decidiendo entre desarrollar o comprar un elemento clasificado, nuestro marco de decisión sobre software a medida frente a soluciones comerciales es una buena lectura para continuar.
Preguntas frecuentes
¿Qué marco de priorización es el mejor para un equipo de producto pequeño?
Empiece por valor frente a complejidad. Requiere pocos datos, se completa en un taller y ofrece una clasificación visible. Cuando reúna datos sobre alcance y uso, pase a RICE o a una puntuación ponderada para la lista más extensa.
¿Con qué frecuencia deberíamos volver a priorizar la hoja de ruta?
Una guía sugiere hacerlo cada 6 a 8 semanas para las empresas pequeñas y trimestralmente para las grandes. Sea cual sea el ritmo que elija, vuelva a puntuar también un elemento cuando nuevas evidencias cambien su impacto o esfuerzo.
¿Podemos utilizar más de un marco a la vez?
Sí, y muchos equipos lo hacen. Utilice un modelo de puntuación, como RICE o la puntuación ponderada, para clasificar una lista extensa; después, use una perspectiva de valor frente a complejidad para revisar los elementos principales con el equipo de ingeniería. Mantenga visibles los criterios para que las partes interesadas puedan seguir la lógica.
¿Cómo gestionamos a las partes interesadas que no están de acuerdo con la clasificación?
Incorpórelas al proceso antes de puntuar, no después. Acuerden los criterios conjuntamente, muestre dónde se sitúan sus prioridades en la clasificación y utilice el marco para explicar un «ahora no» con razones, en lugar de basarse en una opinión.
¿Cuál es la diferencia entre la priorización de la hoja de ruta y el perfeccionamiento del backlog?
La priorización de la hoja de ruta clasifica los temas y las iniciativas, y los asigna a distintos horizontes temporales. El perfeccionamiento del backlog convierte los elementos a corto plazo en trabajo claro, estimado y listo para ejecutarse. La hoja de ruta alimenta el backlog, y las estimaciones del perfeccionamiento retroalimentan las puntuaciones de esfuerzo de la hoja de ruta.
Fuentes
- Marcos de priorización, Atlassian
- Los 6 pasos para crear una hoja de ruta, NN/g
- 5 métodos de priorización para crear hojas de ruta de UX, NN/g
- 10 marcos de priorización para responsables de producto, Gusto
- La guía esencial para la priorización, Productboard
- Marcos de priorización de productos, Productboard
- Valor frente a complejidad, ProductPlan
- Modelo de puntuación RICE, ProductPlan
- Marcos de priorización de productos: 12 modelos habituales, Aha!
- Priorización de funcionalidades, Aha!
- Plantilla de planificación trimestral para equipos de producto, airfocus
- Hoja de ruta de funcionalidades: cómo priorizar y planificar funcionalidades, Product School