La mayoría de roadmaps fallan el mismo test diagnóstico. Cuando se les pregunta "¿por qué está esto en la lista?" no producen una respuesta clara. La razón rara vez es falta de esfuerzo. Es la ausencia de un framework lo suficientemente riguroso para filtrar el input de la ejecución. Sin él, cada voz ruidosa consigue un feature, y el roadmap se vuelve un registro de política interna en lugar de estrategia de producto.
El framework de Aha! para desarrollo de producto se construye respondiendo cuatro preguntas en orden. Este artículo toma esa espina dorsal de la guía del framework de Aha! y la reduce a una versión funcional que cualquier equipo de PM puede implementar este trimestre.
Por qué los frameworks importan (sobre todo cuando no los quieres)
El pushback contra los frameworks es real. Pueden volverse burocracia. Pueden ralentizar la toma de decisiones. Pueden producir teatro de documentación que nadie lee.
Pero la alternativa es peor. Sin framework, cada decisión de roadmap depende del juicio personal de quien esté más alto en la sala. Los frameworks externalizan los criterios, así el juicio es repetible y defendible. Los mejores frameworks no son pesados. Solo hacen explícito lo implícito.
Las 4 preguntas, en orden
Pregunta 1: ¿A quién estamos sirviendo?
No "quiénes son nuestros usuarios" en abstracto. ¿A quién específicamente estamos sirviendo con esta iniciativa del roadmap? ¿Qué segmento, con qué job-to-be-done, en qué situación?
Fallo común: "todos los usuarios". Esa respuesta casi siempre está mal. Los productos sirven a personas específicas haciendo cosas específicas. Un roadmap que no puede nombrar el segmento objetivo de una iniciativa está tomando decisiones por instinto.
Test concreto: ¿puedes nombrar la entrevista de cliente que informó esta iniciativa? Si sí, probablemente tienes una respuesta real a la Pregunta 1. Si no, la iniciativa es especulativa.
Pregunta 2: ¿Por qué importa?
Una vez sabes a quién sirves, ¿por qué importa esta iniciativa para ellos y para el negocio? ¿Qué problema resuelve? ¿Qué métrica mueve? ¿Qué posición estratégica apoya?
Fallo común: "porque los clientes lo pidieron". Eso es una petición, no una razón. Muchas peticiones de cliente, si se conceden, degradarían el producto. La razón necesita conectar con un outcome de negocio, no solo con un log de peticiones.
Test concreto: escribe la declaración de valor de una frase. "Para [segmento], que tiene [problema], estamos construyendo [solución] para que pueda [outcome], lo que produce [resultado de negocio]." Si no puedes rellenar los cinco huecos, todavía no tienes una razón.
Pregunta 3: ¿Qué estamos construyendo?
Solo ahora especificas la solución. La mayoría de equipos invierten el orden: empiezan con la solución y la justifican hacia atrás con audiencia y razonamiento. El resultado es un roadmap lleno de features buscando justificación.
Fallo común: "un rediseño del dashboard". Eso es un feature, no un qué. El qué debe describir el cambio cara al usuario en lenguaje claro. "Los usuarios pueden ver sus tres métricas más importantes en una sola pantalla sin filtrar."
Test concreto: si un cliente lee la descripción, ¿puede decir si recibió lo que quería? Si sí, la descripción está en el nivel correcto. Si no, todavía estás describiendo implementación.
Pregunta 4: ¿Cuándo y en qué secuencia?
La pregunta del cuándo es la más política. Los stakeholders quieren sus ítems primero. La decisión de secuenciar es donde vive la disciplina del roadmap. Tres inputs:
- Dependencias: si A debe enviarse antes que B, el orden es fijo.
- Valor ajustado por riesgo: un outcome de $1M con 60% de probabilidad vence a uno de $5M con 10%, a pesar del número titular más grande.
- Opcionalidad: si hacer X abre caminos futuros y hacer Y los cierra, X tiene valor oculto.
Fallo común: secuenciar por peso político del stakeholder. El arreglo es hacer los inputs de secuenciación visibles y forzar conversaciones sobre ellos en lugar de sobre el orden en sí.
Cómo las 4 preguntas reconfiguran la conversación del roadmap
| Conversación vieja | Conversación nueva |
|---|---|
| ¿Deberíamos añadir el feature X? | ¿Para quién, por qué, qué específicamente y cuándo? |
| ¿Por qué el feature X está retrasado? | ¿Cambió el por qué? ¿Cambiaron las dependencias? |
| El cliente quiere el feature X. Añádelo. | ¿Qué segmento es este cliente? ¿Qué outcome movería? ¿Dónde secuencia? |
Fíjate que las conversaciones nuevas tardan más. Ese es el punto. El coste de la conversación más larga es mucho menor que el coste del feature equivocado enviado a tiempo.
La mayoría de roadmaps malos fallan en la Pregunta 1. Si no puedes nombrar el segmento específico, cada respuesta posterior se construye sobre arena.
Un ejemplo trabajado
Entrada vieja del roadmap: "Q3 - Construir reporting avanzado."
La misma entrada tras las 4 preguntas:
- Quién: Operations managers en empresas de 50 a 200 empleados que ya usan nuestras analíticas semanalmente. Identificados en 12 entrevistas en mayo.
- Por qué: Actualmente exportan a hojas de cálculo y reconstruyen los mismos tres reportes cada semana. Esto les cuesta a cada manager ~3 horas semanales. Resolverlo reduce el riesgo de churn en este segmento (que representa el 38% del MRR) y desbloquea un camino de upsell al tier Enterprise.
- Qué: Un constructor de reportes donde los managers pueden guardar hasta 5 dashboards personalizados y programar exports por email semanales. No es un reemplazo completo de BI; la meta es eliminar el ida y vuelta de las hojas de cálculo.
- Cuándo: Q3, después de que el experimento de activación termine en Q2 (para saber a qué usuarios apuntar). Secuenciado antes del lanzamiento del tier Enterprise en Q4 porque es un feature prerrequisito para ese segmento.
La entrada original podía ignorarse o discutirse. La expandida es defendible y revisable.
El filtro de las 4 preguntas para peticiones entrantes
Cada petición de feature que llega (de ventas, soporte, clientes, ejecutivos) pasa por el mismo filtro antes de entrar al set de consideración del roadmap:
- ¿Quién específicamente?
- ¿Por qué importa para ellos y para el negocio?
- ¿Qué exactamente estamos cambiando?
- ¿Por qué ahora vs después?
Las peticiones que no pasan el filtro vuelven al peticionario para más información. Esta sola disciplina reduce el ruido entrante un 50-70% en la mayoría de equipos. Las peticiones restantes son de mejor calidad y más fáciles de comparar.
Para llevar
Los frameworks estratégicos de roadmap no son burocracia. Son la externalización del juicio que permite a un equipo tomar decisiones repetibles. Las cuatro preguntas (quién, por qué, qué, cuándo) son el framework mínimo viable. Pasa cada ítem del roadmap y cada petición entrante por ellas. Las conversaciones se alargan; los ítems equivocados se filtran; el roadmap que emerge se defiende solo.
