Skip to main content

Un buen Roadmap es uno de los documentos más importantes e influyentes que una organización puede desarrollar, publicar y actualizar continuamente. (4,5 sobre 5 nota meetup)

Por eso desde The Hero Camp organizamos este webinar, para enseñar cómo crear una hoja de ruta efectiva del producto mientras se adopta la incertidumbre

Resumen de Roadmapping

Trucos y herramientas para establecer la dirección mientras se adopta la incertidumbre

En este meetup de aproximadamente 50 min. de duración, hablamos sobre el Roadmap, esa herramienta tan utilizada. querida y odiada por igual en el mundo del Product Management. Para ello José Manuel Pérez  pudo compartir y aprender junto con el autodefinido “Data Nerd” y experimentado Product Manager (y muchas cosas más) Todd Lombardo

Actualmente es vicepresidente de MachineMetrics (IOT) y viene de Boston, EEUU. Tiene un largo historial pero podríamos resumirlo como Product Lover, Data Nerd, Design geek, profesor en la IE Business School (Madrid),… y habiendo co-creado varios libros como «Design Sprint», «Product Research Rules»  y «Product Roadmaps», del que nos habla en su introducción unos minutos sobre su motivación y las razones que le llevaron a escribirlo.

Sin duda su trayectoria es apasionante y una vez le conoces te das cuenta de que su reputación es totalmente merecida.

En este post ya explicamos toda la teoría que necesitas saber sobre Roadmaps pero aquí tenemos algo mejor aún; casos reales, experiencias, datos, consejos y recomendaciones de primera mano con Todd L.

Tras unos minutos de calentamiento y una vez tenemos todo dispuesto: ¡ARRANCAMOS!

La primera cuestión que le hacemos a Todd es:

¿Con qué problemas te puedes encontrar trabajando con un Roadmap?¿Por qué es importante un Roadmap?

“- Qué buena pregunta. Ante todo decir que el Roadmap no deja de ser una herramienta y esta como todo, puede ser usada bien o mal. Muchas veces la gente confunde el Roadmap con el Release plan y eso es un gran error”. Aquí utiliza un ejemplo con un martillo y como con un martillo puedes clavar un clavo pero mal usado puedes hacer un buen agujero.

“Además éste debe ser adaptable y cambiante (mundo agile) semanalmente e incluso diariamente y no ser algo estático en el tiempo. “

“Otra cosa que debe tener un roadmap es que no debe estar sobre detallado, que es lo que puede producir que te confundas con el release plan, que si esta muy detallado con features y a quién le sirve, para qué, por qué,  estimación en tiempo. Etc…”

Aquí nos habla sobre la diferencia de un Roadmap y un Release plan, ya que uno gestiona la parte estratégica y el otro la parte táctica respectivamente..

¿Para qué sirve un roadmap? “Una de las cosas más importantes de un Roadmap es para alinear al equipo y a los stakeholders en la estrategia a seguir”. 

¿Cómo usarlo para alinear al equipo? ¿Cómo construir un Roadmap?

”El Roadmap deber ser el camino o la dirección a seguir de cara a conseguir una serie de objetivos”. Nos cuenta la metáfora de como ir a Barcelona desde Madrid de múltiples opciones:

“Puedes ir en coche, bici, en tren, bus o avión. Incluso dentro de un avión puedes ir en turista o en Business, por lo que puedes ir de muchas maneras, y eso hay que definirlo para que todo el mundo piense en la misma forma. Esta visión usando un Roadmap nos evita perder un montón de tiempo y nos ayuda a comunicar a todo el mundo  que problemas de los clientes vamos a solventar en el tiempo.”

“Así mismo un Roadmap, que ya hemos visto es una herramienta estratégica, tiene que estar alineado con los objetivos de la empresa que pueden ser los de tu Roadmap o no. Es decir, si eres una empresa pequeña puede que el roadmap de tu producto coincida con el de la visión-misión-negocio pero si la empresa es grande como Google y eres responsable de un producto que tiene su propio roadmap (youtube, gmail, android…), éste de alguna manera debe estar alineado con el roadmap general de Google. Con esto volvemos a ver como el roadmap deber poder cambiar en el tiempo para adaptarse a todas estas circunstancias y posibles cambios. Todd lo asemeja al estado de nuestra cuenta corriente, siempre la queremos lo más estable posible pero al final puede ir variando en el tiempo. “

Todd nos dice: “Si conseguimos eso, alinear la estrategia del producto con la gente y con los objetivos de negocio (roadmap empresa), entonces, tendremos un gran roadmap”.

“Hay muchas formas de construirlo, todas con sus ventajas y contras. Al final he descubierto que hay 5 pilares esenciales en un roadmap:

  • Tiene que tener la visión del producto.
  • Los objetivos, ¿cuales son?  KPI/OKR del tipo que sea como incrementar la recurrencia, disminuir el churn etc…
  • Time themes, que son donde se resumen los resultados que se quieren alcanzar de forma definida en base a tu producto. Esto está relacionado con la estrategia. Todd comenta que él como ejemplo suele usar columnas para ellos donde se agrupan por: “En progreso”, “hecho”, “Siguientes”,“Esto no lo vamos a hacer”…
  • Lo que se quiere abarcar, el theme: Necesidades de los clientes, Problemas a resolver para los clientes o resultados de negocio a alcanzar.  NO es una lista de features.
  • Limitar el recorrido del mismo o responsabilidades (Disclaimer),para que todo el mundo sepa que el roadmap es cambiante en el tiempo y nadie se aferre a él como si fuera una foto y todo ha de salir como indica. Esto ayuda a rebajar las expectativas.“

¿Cómo podemos alinear nuestros objetivos con los de negocio?

“Por un lado tenemos los resultados qué negocio quiere conseguir (Reducir el churn, incrementar el engagement, aumentar los usuarios…) y por otro lado tenemos nuestros themes o necesidades de nuestros clientes con las que queremos aumentar el valor que les damos. En el roadmap deben estar ligados ambos de alguna manera. Muchas veces nuestros theme pueden estar ligados bajo unos resultados de negocio esperados determinados donde quieren reducir el churn y nosotros realizamos nuevas funcionalidades que pensamos que puede ayudar a reducir el churn.”

¿Cómo podemos seguir nuestro roadmap junto a las necesidades del día a día?

“¡Es una gran pregunta!”. “De nuevo tener en mente que el release plan no es el roadmap. El roadmap indica que themes o cosas en las que estamos y el release plan indica como y que se está haciendo en ese punto del roadmap. Un ejemplo es que si por ejemplo desarrollamos una feature y la sacamos (release plan) pensando en una necesidad del cliente a resolver (está en el roadmap) pero comprobamos que dicha feature no ha resuelto el problema el theme del roadmap no está solucionado por lo que continuaremos con ello (nuestro cliente sigue con el problema), pero la feature ya no existe (output que lleva a un outcome que en este caso no ha sido bueno), ya salió como parte del release plan.

Para poder comprobar esta situación nuestros KPI (satisfaction, engagement, tiempo media de visita de la web…) y los resultados de negocio esperados deben estar alineados y así poder cerrar el círculo entre lo que se ha entregado (output) y lo que el cliente/negocio ha recibido (outcome) y si es satisfactorio en el tiempo o no, para poder pasar a otra cosa.”

“Parece muy simple pero es muy muy difícil de hacer todo esto.”

¿Qué pasos seguirías para poder introducir esta forma de pensar  y esta herramienta como son los roadmaps en producto?

“Un par de cosas para pensar en este tema. Hagas lo que hagas no intentes hacerlo de forma inmediata ni todo a la vez y sin tener alineados a los stakeholders. Este fallo lo cometí cuando empecé en este mundo y lo aprendí bien.”

  • Hay que tener la visión del producto, 
  • Reunir toda la información necesaria: el feedback de nuestros clientes (user research, design research, entrevistas etc…), entender qué problemas o preocupaciones tengo que tener en cuenta… al final parte nuestro trabajo se trata de comunicar y comunicarnos con todo el involucrado reuniendo toda la información posible.
  • Tener los objetivos de negocio agrupados en áreas temáticas (themes).
  • Una vez tengas los themes, priorizarlos de alguna manera. Hay mil maneras de hacer esto y muchas son válidas. La que sí que sé que no lo es es dejando que el CEO priorice mientras estamos sentados sin hacer nada.

“Es una buena excusa para hablar a menudo con todo el mundo y crear una visión conjunta con todos los stakeholders.

Usar un roadmap es como experimentar, puedes ir viendo como reacciona todo el mundo según vas construyendo, viendo si tiene sentido para ellos o cuáles son los problemas de todo el mundo. Es una buena herramienta para recabar feedback y comunicarse.”

Priorizar es un skill muy importante para un Product manager ¿Qué herramientas o técnicas usas para priorizar? 

“Una de las cosas que suelo usar es un scorecard sobre mis themes. En base a los objetivos de negocio y lo que puedo revolver con cada theme que tengo (Problema, Necesidad de  usuario etc…) les pongo una puntuación para hacer un ranking. Esta puntuación va desde:

-1: Resuelvo el problema pero no me ayuda bien a alcanzar el objetivo de negocio. Por ejemplo si tengo un objetivo de negocio que es reducir el coste, pero nosotros realizamos una tarea que tiene un sobrecoste elevado (sobrecoste de cómputo en AWS por ejemplo) para resolver el problema (theme).

0: No tiene impacto en los objetivos de negocio.

1: Pequeño impacto.

2: Alto impacto.

Una escala pequeña es mejor que una mayor por ejemplo del 1 al 10. Simple.

Lo que yo suelo hacer es realizar este ranking de forma individual y luego voy a cada stakeholder y le hago hacer el mismo proceso pero en función de su visión, haciendo el ranking. Una vez tengo todos los datos juntos de forma agregada, donde nadie ve la puntuación del otro, ya tengo con que presentar mi roadmap priorizado en base a las necesidades de todo el mundo(en una reunión todo juntos) por importancia y consiguiendo alinear a todo el mundo. En esta reunión también se pueden sacar las dependencias de cada theme ajustando la priorización, así que es muy buena técnica. Suelo dar 2 horas para hacer esto, dando 1.45 para “pelear” y 15 minutos donde dejo todo claro tras resolver las opiniones personales, opiniones basadas en datos, etc…haciendo el papel de facilitador..

Una vez más suena fácil pero es muy difícil de hacer.”

¿Quienes suelen participar en estas reuniones?

“Suelo reunir a mi Director customer success, el director de Marketing, al director de ventas, el director de partnerships, el CEO y  el CTO, donde el CEO es la persona más complicada con la que hablar. Intento que sean siempre conversaciones de alto nivel.”

Preguntas:

¿Qué herramientas usas para hacer un Roadmap?

“Me lo han preguntado muchas veces. He usado Trello, excel, power point, ProductBoard y ProductMap (solo para el roadmap porque tiene una feature que permite asociar themes con feedback de usuario).”

¿Cómo organizas las ideas (Insights)?

“Tratamos de unir nuestras propuestas o soluciones features) con todo el feedback o problemas de nuestros usuarios, consiguiendo así alinear los objetivos y estrategia. Para conseguir esta información usamos slack entre nosotros, feedback de usuarios y feedback de marketing y customer success.

Mi consejo es poder reunir toda esta información en un único sitio porque sino es un caos.”

¿Un ejemplo donde hayas fallado aplicando un roadmap? ¿Qué aprendiste?

“Hay que hacer el roadmap colaborativo de cierta manera, alineando a todos los involucrados para evitar frustraciones y que todo el mundo se sienta cómodo. Cuando no tenía mucha experiencia hice un roadmap sin contar con nadie y al final todo el mundo se quejaba y con motivo, no estaba alineado con nada.“

“Otro error que cometí en un estado inicial de un proyecto fue que hice un roadmap con una estimación en tiempo demasiada lejana, por lo que había mucha tensión frustración sobre dónde íbamos y donde estábamos. Una locura. Esto además resaltó un problema muy grave y es que no teníamos una visión clara de nuestros objetivos.

Tu roadmap puede ser increíble pero si no tiene sentido ni visión es “basura”. 

“No deben ser de más de 2-3-4 meses. Las cosas cambian muy rápido y sino es imposible adaptarse. No se puede experimentar ni aprender con un roadmap en el tiempo si este no puede cambiar en el tiempo.”

Este post está escrito por Pablo de Lucas, Digital Product Manager alumno novena edición de Madrid

El próximo curso de Digital Product Manager en Barcelona comienza el 17 de abril y en Madird el 8 de Mayo  (Plazas limitadas). 

Aquí puedes escuchar el webinar iVoox o Spotify si prefieres verlo:

P.D. ¿Dudas o comentarios?
Nuestro WhatsApp está abierto para ti AQUÍ

Escribir un comentario