Cómo hacer un roadmap de producto que aguante el trimestre
El método para construir un roadmap con evidencia en vez de con la última reunión: qué va dentro, qué se queda fuera y cómo defenderlo cuando alguien pide meter algo a mitad.
Casi todos los roadmaps que veo tienen el mismo problema: son una lista de funcionalidades con un trimestre asignado. Funcionan durante tres semanas. Después entra un cliente grande pidiendo algo, alguien de ventas lo sube a dirección, y la lista se reordena sin que nadie recuerde por qué estaba en ese orden.
El roadmap no falla por falta de herramienta. Falla porque no está construido sobre nada que se pueda defender.
Un roadmap es una lista de problemas, no de soluciones
La diferencia parece de matiz y es la que decide si el documento aguanta.
Si tu roadmap dice “Q4: exportación a Excel”, cualquiera puede discutirlo, porque es una opinión sobre una solución. Si dice “Q4: que un responsable pueda llevarse los datos a su comité del lunes sin pedírnoslos por correo”, ya no se discute igual. La segunda formulación aguanta que descubras que lo que hacía falta era un informe programado y no una exportación.
Además cambia quién puede opinar. Sobre una solución opina todo el mundo. Sobre si un problema es real o no, opina quien tiene el dato.
Los cuatro inputs, en orden de fiabilidad
No todos los orígenes de una idea valen lo mismo. Este es el orden en el que yo los pondero:
- Comportamiento observado. Dónde abandona la gente, qué intentan hacer y no pueden, qué repiten a mano. Es el input más caro de conseguir y el único que no miente.
- Peticiones repetidas de clientes distintos. Una petición es una anécdota. La misma petición de siete cuentas que no se conocen entre sí es una señal.
- Objetivo de negocio. Si el año va de bajar el churn, hay cosas que no entran aunque sean buenas ideas.
- Intuición del equipo. Vale, pero va la última y necesita convertirse en una de las tres anteriores antes de ocupar un trimestre.
El error habitual es que el cuarto input entra disfrazado del tercero. Alguien tiene una idea, le pone encima una justificación de negocio construida a posteriori, y nadie la cuestiona porque suena a estrategia.
Cómo ordenar lo que sobrevive
Con la lista de problemas encima de la mesa, la ordenación no necesita un framework complicado. Necesita dos números y una conversación.
El primer número es cuánta gente lo sufre y con qué frecuencia. El segundo es cuánto cuesta resolverlo, medido en semanas de equipo y no en dificultad percibida. El cociente ordena la lista razonablemente bien.
La conversación es la parte que no se puede automatizar: mirar los tres primeros y preguntar si el equipo tiene capacidad para terminarlos este trimestre. Si no la tiene, el tercero no entra. Un roadmap con seis cosas empezadas y ninguna terminada es peor que uno con dos cosas cerradas.
Si quieres el detalle del método de puntuación, lo desarrollé en cómo priorizar features por impacto y esfuerzo, que aplica el mismo criterio al caso concreto de las funcionalidades con IA.
Qué hacer cuando alguien pide meter algo a mitad
Va a pasar. La respuesta que funciona no es decir que no, es enseñar el coste.
Cuando llega la petición, la pregunta no es “¿lo metemos?” sino “¿qué sale para que esto entre?”. Con el roadmap delante y las dos o tres cosas del trimestre a la vista, la conversación deja de ser sobre si la idea es buena. Todas las ideas son buenas. Pasa a ser sobre cuál de las dos que ya estaban decididas se aparca.
Nueve de cada diez veces, la petición se cae sola en ese momento. La décima entra, y entra bien, porque alguien ha aceptado el intercambio por escrito.
Los tres formatos que sirven
- Por trimestre, con tres franjas. Lo que está decidido, lo probable y lo que se está investigando. Es el que mejor comunica incertidumbre hacia arriba.
- Por problema, sin fechas. Ordenado y sin trimestre asignado. Funciona en equipos pequeños donde la fecha genera más discusión de la que resuelve.
- Por objetivo. Dos o tres objetivos de negocio, y debajo lo que se va a intentar para moverlos. Es el que mejor aguanta una conversación con dirección.
Ninguno necesita una herramienta de pago. Los tres funcionan en un documento compartido, y el documento tiene la ventaja de que se puede leer sin licencia.
El punto de control
Al final del trimestre, la pregunta útil no es cuántas cosas se entregaron. Es cuántos de los problemas que pusiste en el roadmap dejaron de ser problemas. Si entregaste seis cosas y ninguna movió el número que decías querer mover, el roadmap estaba mal construido aunque el equipo cumpliese.
Ese es el momento de mirar dónde falló el input. Casi siempre es el mismo sitio: algo entró por intuición y se vistió de dato.
Si tienes un roadmap lleno y la sensación de que no está atacando lo importante, una auditoría de producto te dice en dos semanas dónde se están perdiendo los usuarios de verdad, que es la lista con la que debería construirse el trimestre siguiente. Y si lo que tienes es una idea todavía sin aterrizar, el paso previo es el sprint de discovery.
¿Qué es un roadmap de producto?
Es el documento que dice qué problemas va a resolver el producto en los próximos meses y en qué orden. No es una lista de funcionalidades con fechas: eso es un plan de entregas. La diferencia importa porque un roadmap de problemas sobrevive a que cambie la solución, y uno de funcionalidades se rompe en cuanto descubres una manera mejor de hacer algo.
¿Cada cuánto se revisa un roadmap?
Cada trimestre para la estructura y cada dos semanas para el detalle del trimestre en curso. Revisarlo más a menudo lo convierte en un backlog con otro nombre. Revisarlo menos hace que la mitad de lo que hay dentro ya no responda a lo que sabes hoy.
¿Cuánta gente debería decidir qué entra en el roadmap?
Una persona decide y varias opinan. Los roadmaps que se deciden por consenso acaban conteniendo un poco de lo que quiere cada área, que es la manera más rápida de no mover ninguna métrica. Lo que sí conviene que sea colectivo es el criterio con el que se decide, no cada decisión concreta.