No esperaba escribir de jardinería

Cómo tratar a tu roadmap como a un bonsái para que funcione

Que buena idea, lo meto en el roadmap.

Es la mejor forma de quitarse a un cliente de encima. No lo hacemos con malicia. Nos proponen una nueva funcionalidad, de primeras nos parece interesante y para agradar la dejamos escrita en la lista de próximas funcionalidades dentro del roadmap. Al ponerla, vas imaginando el día en el que otro cliente proponga algo parecido. ¿Cómo puedo generalizar ese problema? Incluirás ese feedback en la tarjeta. Crearás un dashboard para monitorizar el uso actual y ver cómo podría afectar al comportamiento una solución. Refinarás con el equipo varias ideas y propondréis soluciones. Las mejores soluciones pasarán por los ciclos de ideación, diseño, validación y desarrollo hasta llegar a producción.

Gracias al pequeño gesto de documentar bien una necesidad de un cliente en el roadmap, tu producto irá mejorando con el tiempo. A mí me gusta pensar que estas cuidando un pequeño bonsái que poco a poco irá creciendo.

Pero claro, no todas las ideas que sugieren los clientes acabarán desarrollándose. De hecho, tu misión es asegurarte de que sólo progresen las ideas que de verdad mejoren el producto, aquellas ramas que fortalezcan a tu bonsái.

Y si, “el cliente tiene la razón”, “son expertos de su dominio”, etc. Pero la realidad, es que muchas veces le dedican 5 minutos a añadir una propuesta que llevará horas de gestión y puede no aportar ningún valor final.

Hoy, os quiero recomendar tres ejercicios que hago de forma recurrente, para asegurarme de que mi roadmap está al día y libre de peticiones que no se harán nunca.

Disclaimer: Quiero destacar que los ejercicios que propongo, sólo afectan a las funcionalidades del producto, no a las necesidades estratégicas de la empresa. Si este trimestre, el objetivo es aumentar retención, eso es inamovible. Sin embargo, podemos ser flexibles con las funcionalidades que vamos a desarrollar.

Regar el roadmap

Cuando digo regar, me refiero a añadir nuevas funcionalidades sobre las que trabajar. En una empresa de producto, todo el equipo puede crear funcionalidades en el roadmap. TODOS. Si ventas descubre una funcionalidad que quieren varios clientes, al roadmap. El equipo de desarrollo está planteando una base de datos para reducir latencias, al roadmap. Una idea que surge de una conversación con cliente, al roadmap. ¿Por qué no íbamos a querer tener todo identificado en el roadmap? Así nos aseguramos de que a la hora de planificar, todo está sobre la mesa. No existe un roadmap de ventas, uno para el CEO, otro para inversores, … Toda la información está en el mismo sitio.

Esto tiene un problema muy claro y evidente: el roadmap se llena de funcionalidades que no están listas para ser desarrolladas. Si metemos demasiadas ideas de este tipo inundamos el roadmap.

Abonar el roadmap

Además de agua, los roadmaps necesitan abono para prosperar. Toda esta lista de ideas no sirve de nada si no se enriquece con más información. Hay incluir los detalles relevantes para cada una de estas funcionalidades para que se puedan desarrollar y medir el impacto en la métrica de negocio asociada. Una vez definida la funcionalidad, podemos pasar a priorizarla frente a otras funcionalidades.

Para priorizar internamente utilizamos RICE, por lo que es necesario que el equipo identifique bien las palancas de alcance, impacto, confianza y esfuerzo para priorizar las funcionalidades según su relevancia. Por defecto, definimos unos valores de impacto, confianza y esfuerzo “poco atractivos”, que sólo pueden mejorar a través de entrevistas, experimentos y refinamientos.

El RICE está muy bien para priorizar elementos que tienen un nivel de madurez similar, pero se distorsiona cuando comparas proyectos grandes con un impacto grande con cosas pequeñas de mucha incertidumbre. Por eso, además de este índice de priorización definimos fechas de entrega para cada funcionalidad. Esa fecha tiene implícitos dos conceptos ligados que evitan que nos perdamos en sobre-planificar nuestro roadmap.

• Intervalo de estimación: dentro del roadmap la granularidad más pequeña para una fecha es de un mes. Si una funcionalidad está planificada para junio, quiere decir que saldrá durante junio. Puede ser la primera semana o la última. Incluso, puede salir en julio. Es una fecha de referencia para que toda la empresa pueda organizarse. Conforme nos alejamos en la estimación, agrupamos por trimestres, medios años y años. De esta forma no tenemos que perder tiempo hoy decidiendo en qué mes de 2024 desarrollaremos algo sobre lo que no tenemos visibilidad.

• Esfuerzo de desarrollo: las funcionalidades las dimensionamos por talla de camiseta. Una funcionalidad normal tardamos en desarrollarla y llevarla a producción una semana de media. Eso es una S. A partir de ahí vamos multiplicando por dos. Una M dos semanas, una L cuatro y por ahora no tenemos ninguna XL de ocho semanas en el roadmap.

Gracias a estos dos parámetros definidos ya puedes rellenar tu roadmap. En Q4 de 2023 te caben 12 S’s o 4 L’s o una XL y 2 M’s. Como es razonable que no tengas 12 semanas perfectamente refinadas para dentro de 6 meses, te recomiendo que por defecto crees tarjetas con un esfuerzo de L. Hasta que no las refines no serás capaz de tener claro que entra en ese desarrollo y que dejarás para más adelante.

Podar el roadmap

No he querido engañarte. Se que ha sonado a que con estas dos cosas vas a tener un roadmap infalible. Épicas priorizadas, fechas para todos los departamentos, todo el equipo alineado, …

Y en parte es así. La mitad del trabajo está hecho. La otra mitad del trabajo es podar aquellas iniciativas que:

• No tienen contenido.

• No están bien acotadas (¿qué es arreglar home?)

• Atienden a necesidades puntuales de un cliente, que ni si quiera él ha vuelto a pedir

Todos esos motivos suenan mal. Suenan a individuos que no hacen bien su trabajo. A personas que mancillan nuestro perfecto roadmap. Pero yo no lo veo así. Era una rama que podría haber mejorado a nuestro pequeño bonsái y que, con paz y calma, la podamos para dejar que el resto del roadmap siga creciendo.

Es importante que la poda la hagamos con todo el equipo. Identificar que iniciativas no se han tocado en cierto tiempo y podar. Un mes, dos meses, tres meses, … el criterio que acordéis. Pero de manera periódica entrad en el roadmap y entre todos, borrad esas funcionalidades. No os preocupéis por borrar la idea. Si de verdad era importante, volverá a salir. Hay que definir bien los criterios que hacen que una funcionalidad sea candidata para borrar. ¿Funcionalidades sin descripción que llevan dos meses sin modificarse? Suena a algo que se puede quitar de momento.

---

Gestionar roadmaps no es fácil. Incluir la información del equipo y de los clientes para que refleje tu situación actual ayudará en la coordinación entre equipos y te permitirá mostrar una visión más robusta a tus clientes. Si haces este trabajo una vez al año cuando la dirección pide una hoja de ruta para el próximo año estás perdido… Por el contrario, si día a día riegas, abonas con buenos nutrientes y podas con cariño, acabarás con un roadmap infalible.