Cómo escribir un documento de roadmap que explique las decisiones de prioridad
6 min de lectura
La mayoría de los documentos de roadmap son una lista ordenada sin razonamiento visible. Eso funciona bien hasta que un interesado pregunta por qué la función B está sobre la función A, y la respuesta honesta es una mezcla de instinto y quién preguntó más recientemente, lo cual no se sostiene bien en la reunión. Un PM que presenta un roadmap de seis elementos a una sala de interesados, cada uno con su función favorita, puede pasar la reunión entera defendiendo el orden en voz alta en lugar de señalar un razonamiento que ya estuviera en el documento.
Advertencia
Una lista ordenada sin razonamiento no es una decisión, es un marcador para una. La primera pregunta difícil en la sala revela si el orden realmente se pensó a fondo.
Un roadmap que no puede explicar su propio orden no es un roadmap. Es una lista esperando a que la vuelvan a discutir.
Por qué una razón sin registrar se vuelve a discutir cada vez
Ordenar por instinto puede estar en lo correcto, pero nadie más puede evaluarlo, así que cualquier interesado con una intuición distinta tiene motivos para oponerse. Sin un razonamiento visible, la misma conversación sobre prioridades se repite en la siguiente reunión, y en la que sigue. Un roadmap presentado como una simple lista ordenada invita exactamente al tipo de debate que uno bien razonado evita, porque no hay nada en el documento con lo que un interesado escéptico pueda confrontar, salvo el recuerdo del PM de por qué tomó cada decisión.
Imagina una revisión trimestral de roadmap donde un líder de ingeniería pregunta por qué una función de menor impacto está ordenada sobre otra con un alcance esperado claramente mayor. Si la respuesta honesta vive solo en la cabeza del PM, "simplemente se sintió más urgente", la reunión se convierte en una negociación en tiempo real con quien presione más fuerte. Si la misma pregunta ya tiene respuesta en el documento, "la función A queda más arriba a pesar de un alcance menor porque desbloquea una integración con un socio con fecha límite contractual el próximo mes", la conversación se mueve a si ese razonamiento se sostiene, que es un lugar mucho más productivo para que vaya.
Antes: ordenar funciones por instinto, presentar la lista, pasar la reunión defendiendo el orden desde cero.
Después: darle a Claude las funciones candidatas con su esfuerzo e impacto, recibir un roadmap ordenado con el razonamiento de cada posición ya escrito, y entrar a la reunión con las decisiones de prioridad ya puestas en el documento.
Un proceso para un roadmap con razonamiento visible
- 1
Lista a los candidatos con estimaciones reales de esfuerzo e impacto
Da cifras reales, aunque sean aproximadas, semanas de ingeniería para el esfuerzo, usuarios afectados esperados para el impacto, en lugar de etiquetas vagas como "grande" o "pequeño". Datos vagos producen un orden sin nada sólido detrás.
- 2
Pide un orden con una razón declarada por elemento
Solicita dos frases de justificación por función, no solo una lista ordenada. El razonamiento es lo que hace que el roadmap sea defendible en una sala llena de gente con sus propias opiniones.
- 3
Pregunta qué cambiaría el orden
Una vez que tengas un primer borrador, pregunta qué funciones están más cerca de intercambiar lugares, y qué tendría que ser verdad para que eso ocurra. Ahí es donde se vuelven visibles las verdaderas decisiones de prioridad, no solo el orden final.
- 4
Revisa el razonamiento contra lo que de verdad valoran los interesados
Compara el razonamiento declarado contra lo que sabes que le importa a la gente en la sala, ingresos, retención, deuda técnica. Un orden que solo refleja esfuerzo e impacto puede seguir sin captar la conversación real.
Aquí hay 6 funciones candidatas con estimaciones aproximadas de esfuerzo e impacto esperado. Ordénalas en un roadmap para el Q3, y escribe dos frases justificando cada posición.
”Si se sabe que un interesado específico pesa una dimensión más que las demás, por ejemplo, el liderazgo de ingeniería valora la reducción de deuda técnica más de lo que la lista actual refleja, vale la pena pedirle a Claude que pondere el orden con esa prioridad nombrada explícitamente, en lugar de presentar un único orden que asume implícitamente que todos comparten las mismas prioridades.
El liderazgo de ingeniería ha marcado la deuda técnica como una prioridad mayor de lo que este orden refleja actualmente. Muéstrame cómo cambiaría el orden si reducir la deuda técnica pesara tanto como el impacto en usuarios, para poder comparar ambas versiones antes de la reunión.
”
Dentro de Claude Tutorial
Hacer visible el razonamiento detrás de un orden es transferible.
Convertir una decisión por instinto en una con razonamiento declarado y verificable aplica mucho más allá de los roadmaps. La app tiene una lección completa sobre esto, con práctica que se traslada a cualquier decisión de prioridad que necesites defender.
Cuando dos funciones están genuinamente cerca
A veces la respuesta honesta es que dos funciones están lo bastante cerca como para que cualquier orden sea defendible. Vale la pena decirlo directamente en lugar de presentar una falsa seguridad sobre un orden específico. Un roadmap que presenta cada posición con la misma certeza invita a un interesado a presionar fuerte sobre una decisión reñida como si fuera algo ya resuelto, cuando el movimiento más honesto y, al final, más persuasivo es nombrarla como reñida desde el inicio.
Consejo
Pide a Claude que marque qué posiciones son decisiones reñidas frente a claras. Un roadmap honesto sobre sus decisiones reñidas es más creíble que uno que presenta cada posición con la misma certeza.
Mirando esta lista ordenada de 6 funciones, ¿qué pares están lo bastante cerca como para que el orden razonablemente pudiera invertirse? Sé específico sobre qué tendría que cambiar para que eso pase.
”Para un par genuinamente reñido, vale la pena preguntar si hay un criterio de desempate más allá del esfuerzo y el impacto que lo resuelva con más confianza, una dependencia, una fecha límite estacional, un compromiso ya hecho con un cliente, en lugar de dejar el roadmap descansando sobre un orden arbitrario a cara o cruz.
Estas dos funciones están prácticamente igualadas en esfuerzo e impacto. ¿Hay un criterio de desempate práctico, una dependencia entre ellas, una fecha límite externa, algo más allá de los números, que haga a una claramente la mejor opción para construir primero?
”Sigue leyendo
- Convierte tickets de soporte en temas priorizados: de dónde suelen venir las estimaciones de impacto de las que depende un orden de roadmap.
- Convierte una función lanzada en notas de versión y una actualización para interesados: qué pasa una vez que un elemento del roadmap de verdad se lanza.
- Redacta un PRD a partir de una petición de función de una sola línea: convertir un lugar en el roadmap en una especificación una vez priorizado.