Diez formas de tener éxito con la presentación de la hoja de ruta de un producto

Presentar la hoja de ruta de un producto puede ser muy estresante tanto para los desarrolladores como para los gestores de productos; una parte se ha esforzado para presentar una visión, mientras que la otra se enfrenta a la incertidumbre de no saber cómo se verá afectado su trabajo.

Sentí esa tensión cuando trabajé como desarrollador y, a menudo, me sentía insatisfecho con las hojas de ruta que el equipo de gestión de productos establecía. No me creí todas las decisiones y, con bastante frecuencia, salía de las reuniones de planificación con una sensación de "Bueno, esto no tiene sentido, pero si así lo creen...", o aún peor, pensando que "Tendremos que resolver los problemas nosotros mismos y lograr que parezca que lo que hacemos encaja con lo establecido en la hoja de ruta".

Se podría decir que el problema era que yo sufría el síndrome del rechazo a las ideas de otras personas, y quizá fuera cierto. Como desarrollador, tenía una opinión muy clara sobre qué era lo más acertado. Sin embargo, ahora, como gestor de productos, veo qué provocaba esta desconexión y qué pueden aprender los gestores de productos de esta situación para salir por la puerta grande en la presentación de una hoja de ruta. Después de todo, si el equipo técnico acepta y comprende la idea general, las decisiones diarias de diseño e implementación se tomarán teniendo en cuenta el contexto apropiado, y tú obtendrás el producto que has visualizado.

Estas son mis diez formas de conquistar a los equipos en la presentación de la hoja de ruta de un producto.

Expresiones como "análisis de big data", "aprendizaje automático" o "iniciativa del Internet de las Cosas (IoT)" pueden servir como pilares fundamentales para las partes interesadas de la empresa, pero estos elementos no son útiles ni prácticos para los equipos técnicos. El departamento de ingeniería tiene que saber exactamente qué es lo que está desarrollando, qué relación tiene con los productos actuales, cómo debe entregarse, quién lo utilizará y para qué.

Definir temas generales es genial para estructurar la hoja de ruta y el contexto, pero asegúrate de que no te detienes ahí y de que tienes buenas respuestas para lo que se esconde detrás de cada elemento general. Por ejemplo, si has denominado a un tema "servicios inteligentes", asegúrate de desglosarlo en las iniciativas clave y los epics que son necesarios para desarrollar dicho tema.

Los equipos técnicos necesitan conocer el contexto de por qué estás creando algo en una hoja de ruta. Ningún equipo técnico va a decirte jamás "Dime lo que quieres y yo lo creo". Al contrario, los ingenieros necesitan ver evidencias de por qué requieres una funcionalidad. Deja que los datos hablen, pero cuenta también una historia impactante desde el punto de vista de tus usuarios. Utiliza personas y habla sobre algunas alternativas que hayas excluido y por qué. Para ayudar a todo el equipo a comprender la hoja de ruta, piensa que el "porqué" importa tanto como el "qué".

Si una funcionalidad no parece bien elaborada o realista, pero sigue en la hoja de ruta, deberían saltar todas las señales de alarma. No querrás que el equipo técnico tenga la impresión de que ha creado algo simplemente porque se lo prometiste a alguien. Podría ser un compromiso con un cliente o porque el "departamento de gestión lo quiere". Así que, sé prudente a la hora de comprometerte. Incluso si tienes una función forzada detrás de ti que requiere un cambio particular, asegúrate de que comprendes y transmites la justificación al equipo, y de que tú mismo la apoyas.

Una visión es buena, pero es aún mejor si todo el mundo tiene la confianza de que puede lograrse. El plan no tiene que ser preciso, pero si lo primero que ve tu jefe de desarrollo al mirar la hoja de ruta es un enorme cuello de botella (por ejemplo, si la hoja de ruta tiene un diseño fuerte y centrado en el frontend, pero el equipo solo tiene a un diseñador y ha tenido problemas con cuestiones del frontend en los últimos meses), entonces tendrá problemas con la hoja de ruta durante el resto de tu presentación.

Asegúrate de que realizas una comprobación inicial de la realidad con el equipo y juega con situaciones hipotéticas. Tienes que tener respuestas, un plan de acción claro y una breve consideración sobre “cómo puede realizarse” antes de pedir el compromiso de todos.

Tienes que tener en cuenta en qué lugar están el producto y las habilidades de equipo frente a dónde quieres que estén. Es fantástico avanzar hacia nuevos campos, lo que puede requerir nuevas habilidades en el equipo o alejarse de la tecnología existente, pero no te limites a escribir los sueños de dónde te gustaría estar en un año. En su lugar, piensa en cómo conseguirlo de forma realista. La adquisición de talento lleva tiempo, la adopción de nuevas tecnologías lleva tiempo y abandonar los productos existentes requiere compromisos claros y un plan de transición.

¿Un plan de negocio? Sí. Los equipos técnicos se preocupan por los planes de negocios. Quizás no tanto como a un responsable sénior, pero un equipo de desarrollo al completo se preocupa de por qué algo es importante para el negocio, si produce verdaderos resultados y cómo van a medirse. Aprovecha la inteligencia empresarial de tu equipo técnico. Todo el mundo tiene un interés personal en que el negocio tenga éxito en su conjunto, y puede ser una gran fuente de feedback o de ideas adicionales.

Además, una claridad total sobre el impacto del negocio y ver cómo ocurre puede ser una gran motivación; impulsar los resultados resulta satisfactorio más allá de simplemente haber creado y presentado una funcionalidad.

Los ingenieros quieren desarrollar productos innovadores y exclusivos de los que puedan sentirse orgullosos. Si resulta ser la misma vieja historia que otros les han contado antes, puede resultar desmotivante. Asegúrate de constatar que tu historia es tan innovadora como piensas. Aparte de desmotivar a los desarrolladores, el impacto empresarial de la falta de innovación es incluso peor.

Dicho esto, incluso las hojas de ruta serán siempre un equilibrio entre funciones nuevas y fascinantes, y requisitos imprescindibles no demasiado interesantes desde un punto de vista técnico que, sencillamente, hay que hacer. Trata de asegurarte de que incluso lo rutinario es motivador en tu hoja de ruta.

Crear un producto viable mínimo (MVP, por sus siglas en inglés) y después una versión 1 es una cosa, pero también está todo lo que ocurre tras el lanzamiento: operaciones, mantenimiento, solicitudes de funcionalidades de los usuarios, mejoras continuas y nuevas versiones de otros productos o plataformas que se integran. Una rápida reflexión sobre cuáles son los desafíos y obstáculos que se pueden encontrar tras el lanzamiento los sacará a la luz sin demasiado esfuerzo, y los ingenieros estarán agradecidos de que no hayas ignorado estas realidades. Las estimaciones aproximadas sugieren que el esfuerzo inicial de crear una nueva funcionalidad solo supone de un tercio a la mitad del esfuerzo total destinado a ello durante todo el proceso. En otras palabras: las consecuencias son más costosas que la creación inicial, y, a la larga, algunas "pequeñas cosas rápidas" salen muy caras.

Las estimaciones son algo bueno. Te orientan y se crean según el leal saber y entender de un gestor de productos en cada momento determinado. Sin embargo, muchas suposiciones hechas para las estimaciones salen muy mal una vez que se procede a la implementación o el ajuste de un diseño. Asegúrate de preparar y presentar la hoja de ruta de modo que sea flexible a los cambios.

Una hoja de ruta tiene como objetivo servir de orientación. No es un plan detallado para su ejecución y cualquier miembro del equipo de software lo sabe. No es necesario que lo vendas como algo distinto a eso. Así pues, si aún no tienes todos los detalles de un tema, sé claro. Comparte lo que tienes, cuál es la intención, cuáles son las cuestiones sin resolver y los mayores riesgos que aún quedan por abordar. Destaca áreas que requieran experimentación y más investigación para concretar el "qué". Simplemente, recuerda tener en cuenta el tiempo de experimentación durante la planificación.

Tu equipo se merece una hoja de ruta que ofrezca una imagen global clara, pero que no descuide las realidades. Asimismo, se merece una hoja de ruta que resulte motivadora, fascinante, y que tenga suficientes detalles como para que todo el equipo de software sepa qué hacer en los próximos 1 o 2 sprints con la seguridad de que obtendrán grandes resultados y una repercusión importante para el negocio.

¿Necesitas más ayuda? Consulta las funciones de las hojas de ruta en Jira Software y una plantilla de hoja de ruta de un producto en Jira. También puedes probar de forma gratuita Jira Product Discovery, hecho a medida para gestores de proyectos.