La mayoría de las hojas de ruta de producto se abandonan antes de que acabe el trimestre en que se redactan. No porque los equipos sean indisciplinados, sino porque la hoja de ruta se construyó sobre unos cimientos equivocados: fechas fijas, listas de funcionalidades y deseos de las partes interesadas presentados como un plan. Cuando la realidad se desvía inevitablemente —una funcionalidad lleva más tiempo, cambia una necesidad de los clientes, se mueve un competidor—, la hoja de ruta se convierte en ficción y los equipos dejan de mirarla.
Una hoja de ruta que la gente sigue de verdad no es un diagrama de Gantt disfrazado de estrategia de producto. Es un documento vivo que recoge lo que el equipo piensa en cada momento sobre el orden en que deben resolverse los problemas, estructurado para ser honesto sobre lo que se sabe y lo que no.
Antes de diseñar una hoja de ruta conviene tener claro su propósito. Una hoja de ruta hace tres cosas: comunica la dirección (hacia dónde vamos y por qué), obliga a priorizar (no podemos hacerlo todo, así que qué va primero) y crea una base de alineación (para que ingeniería, diseño, ventas y soporte trabajen hacia los mismos objetivos).
Una hoja de ruta no garantiza fechas de entrega. No se compromete con funcionalidades concretas. Y no sustituye la necesidad de un descubrimiento continuo. Si las partes interesadas tratan la hoja de ruta como una promesa, es un problema de proceso, no una razón para introducir una falsa precisión en el documento.
El formato de hoja de ruta más duradero para la mayoría de los equipos es el modelo de tres horizontes. Es honesto con la incertidumbre: lo que está en «Ahora» está comprometido, lo que está en «Próximo» está planificado pero no cerrado, y lo que está en «Más adelante» apunta en una dirección cierta, pero puede cambiar a medida que aprendas más.
Fíjate en que cada elemento incluye no solo qué es, sino también por qué está ahí. Una hoja de ruta sin justificación es solo una lista. Cuando los miembros del equipo entienden por qué se eligió cada elemento, pueden tomar mejores decisiones cuando las cosas cambian, y pueden mantener conversaciones más productivas cuando un cliente pide algo que no está en la lista.
Las hojas de ruta basadas en funcionalidades («construye X, construye Y, construye Z») crean una dinámica peligrosa: el equipo entrega funcionalidades y da el trabajo por terminado, aunque no muevan las métricas que se suponía que debían mover. La funcionalidad se entregó; el problema no se resolvió.
Las hojas de ruta basadas en resultados replantean cada elemento como un objetivo: «Reducir el tiempo hasta el primer valor de los usuarios nuevos de 4 días a menos de 24 horas». Entonces el equipo puede decidir —y revisar— cómo lograr ese resultado. Esta estructura también facilita mucho despriorizar una funcionalidad cuando descubres una forma mejor de alcanzar el mismo resultado.
El responsable de producto (product manager) es el responsable de la hoja de ruta. Eso significa que responde de su contenido, de sus actualizaciones y de su comunicación a las partes interesadas. Pero ser responsable no significa escribirla en solitario: las mejores hojas de ruta se construyen de forma colaborativa, con aportaciones de ingeniería (sobre viabilidad y esfuerzo), de diseño (sobre las implicaciones para la experiencia de usuario) y de los equipos de cara al cliente (sobre las señales del mercado).
Lo que el PM debe evitar es diseñar la hoja de ruta por comité. Las partes interesadas pueden aportar ideas; no deberían tener derecho de veto sobre elementos concretos. El PM sintetiza las aportaciones y toma las decisiones. Si el proceso para llegar a esas decisiones inspira confianza, los resultados también.
La columna Ahora debería revisarse en cada sprint. La columna Próximo debería revisarse al comienzo de cada trimestre, o cada vez que llegue nueva evidencia relevante (se va un cliente importante, un competidor lanza algo pertinente, un sprint de descubrimiento da un hallazgo sorprendente). La columna Más adelante hay que revisarla una vez por trimestre: no para afinarla, sino para confirmar que las apuestas de futuro siguen teniendo sentido.
El objetivo es una hoja de ruta que nunca esté tan desfasada como para dar vergüenza, pero que tampoco se actualice con tanta frecuencia que genere ansiedad. La mayoría de los equipos pecan de actualizar poco: la hoja de ruta refleja decisiones tomadas hace seis meses y nadie sabe bien cuándo cambió por última vez.
La hoja de ruta se seguirá si, y solo si, el equipo confía en ella. Esa confianza nace de tres cosas: la justificación de cada elemento es visible y sólida; el equipo participó en su elaboración en lugar de recibirla ya hecha; y el PM la actualiza con rapidez cuando cambian las circunstancias, en lugar de fingir que el plan original sigue vigente.
Una hoja de ruta que se usa como herramienta de negociación, o como un documento elaborado para satisfacer a la dirección, será ignorada por el equipo y mal vista por las partes interesadas. Una hoja de ruta que refleja un pensamiento genuino, compromisos reales entre alternativas y una incertidumbre honesta se convertirá en una herramienta a la que la gente recurre, porque de verdad le ayuda a decidir.