Alineación a través de hojas de ruta de producto (con Brandon Blackman de Crema)

Michael Luchen

Las hojas de ruta, el documento clave que puede potenciar la colaboración en tantos equipos de producto o reducir su potencial por desalineación. Todos conocemos las hojas de ruta, pero ¿y si pudiera usarse para fomentar una colaboración verdadera y auténtica? ¿Y si en vez de verlas como un documento estático, fueran orgánicas, transparentes e iterativas? Hoy tenemos a un gerente de producto de primera clase con experiencia que va desde el sector salud hasta el desarrollo de productos empresariales que nos acompaña para hablar sobre hojas de ruta y cómo pueden utilizarse de la mejor manera para crear productos excelentes. Quédate con nosotros.

Este es el podcast del gerente de producto, las voces de una comunidad que está escribiendo el manual de gestión, desarrollo y estrategia de producto. Estamos patrocinados por Crema, una agencia de productos digitales que ayuda a personas y empresas a prosperar a través de la creatividad, la tecnología y la cultura. Más información en crema.us.

Sigue escuchando para recibir consejos prácticos y auténticos que te ayuden a tener éxito en el mundo de la gestión de productos.

Así que estoy muy emocionado hoy de dar la bienvenida a

Brandon Blackman al podcast. La experiencia de Brandon en la gestión de productos comenzó en una startup de tecnología para la salud y se expandió hacia la supervisión del desarrollo de tiendas de comercio electrónico, aplicaciones móviles y trabajo en aplicaciones web a nivel empresarial, apasionado por llevar ideas a la vida.

La pasión de Brandon está en motivar equipos de producto de alto rendimiento, ágiles y multidisciplinarios. Además de tener yo mismo la fortuna de poder colaborar junto a Brandon en Crema, también es miembro de la junta directiva de HealthSplash, una plataforma de salud enfocada en resolver el problema de reclamaciones médicas denegadas debido a datos incorrectos.

Brandon, bienvenido al programa.

Brandon Blackman

Hola. Es muy bueno estar aquí.

Michael Luchen

Muchas gracias por acompañarnos. ¿Listo para adentrarnos en la elaboración de hojas de ruta de producto?

Lectura relacionada: Cómo usar la mapeo de historias de usuario para mejorar la priorización del backlog en Agile

Brandon Blackman

Sí. Estoy muy emocionado de hablar de ello.

Michael Luchen

Muy bien. Yo también estoy muy emocionado. Es uno de esos temas sobre los que siento que hay muchas opiniones y muchas formas correctas de hacerlo.

Así que supongo que partiendo de la base, ¿cuál es tu experiencia personal con las hojas de ruta?

Brandon Blackman

Sí, he tenido mucha experiencia con ellas por necesidad como gerente de producto. Es una parte clave de nuestro proceso de desarrollo de productos y flujo de trabajo. Pero debo decir que mi aprendizaje fue a base de prueba y error. Recuerdo algunas de las primeras hojas de ruta que preparé. Estaban muy enfocadas en fechas, casi tipo Waterfall, y nunca se cumplía nada a tiempo según la hoja de ruta. Así que se volvieron más una molestia y una causa de estrés y ansiedad para mí cuando algún interesado o alguien de la alta dirección de la empresa me preguntaba: "¿Cuándo podemos esperar tal cosa o puedo ver la hoja de ruta?". Y yo pensaba, uf, me estoy metiendo en un lío aquí, pero tengo que compartirla, y así fue como comencé inicialmente con las hojas de ruta. Y eso me llevó a pensar que tenía que haber una mejor manera. Así que he leído mucho e investigado bastante, y también experimentado con los equipos de producto donde participo, y estoy muy satisfecho con dónde estamos ahora.

Realmente disfruto la hoja de ruta. Se ha convertido en una herramienta invaluable para mí, mi equipo y nuestros usuarios o interesados, tanto internos como externos, y es algo que he disfrutado mucho aprender a crear.

Michael Luchen

Eso es genial, así que hablaste un poco de tu experiencia y cómo empezaste con hojas de ruta muy rígidas tipo Waterfall y te encontraste con limitaciones en todo ello.

¿Cuál es tu propia filosofía personal sobre las hojas de ruta de producto que desarrollaste al pasar por esa experiencia?

Brandon Blackman

Sí, eso es genial. No está bellamente redactada, es un poco cortada, pero diría que los principios clave de mi filosofía son mantenerla a un nivel alto. Cuanto más detallada es, más posibilidades de expectativas incumplidas tendrás. Y mantenerla siempre ordenada, siempre manteniéndola, y lo último es estar siempre publicando. Yo soy partidario de liberar temprano y liberar seguido cuando se trata de productos digitales.

Michael Luchen

Así que comencemos con algunos conceptos básicos sobre la elaboración de hojas de ruta de producto. ¿Cuál debería ser el objetivo principal de una hoja de ruta?

 

Brandon Blackman

Esa es una gran pregunta. Yo diría que el objetivo principal de una hoja de ruta es comunicar la dirección del producto. Incluso realmente, debe comunicar la dirección del producto, pero debe reflejar la dirección de la empresa o la organización en su conjunto. Y la razón por la que digo esto es porque la esencia de lo que la hoja de ruta debe lograr es lograr alineación entre todos los involucrados en el producto. Esto podría ser alineación externa con nuestros usuarios o alineación interna con tu equipo de producto o con la dirección de tu empresa, pero la clave de la hoja de ruta es que estamos tratando de alinear a un grupo de personas diferentes con distintas perspectivas sobre lo que pueden esperar en el futuro. Y ese es un gran reto, por lo que el objetivo es de manera clara y concisa comunicar hacia dónde vamos con este producto.

Michael Luchen

Entonces es casi como una historia que siempre está cambiando, de cierta forma, porque

Brandon Blackman

Absolutamente.

Michael Luchen

Sirve a múltiples partes interesadas.

Brandon Blackman

Sí, exactamente eso. Y como en cualquier buena historia, no quieres aburrir a alguien con demasiados detalles. Me gusta la idea de que sea una historia porque quieres mantenerla interesante y dar la información justa para lograr el objetivo, que es lograr alineación, pero no ser tan detallista que termines olvidando requisitos o perdiendo plazos porque te enredaste en demasiados detalles.

Michael Luchen

Definitivamente. Así que hemos empezado a adentrarnos, pero preguntando directamente, ¿debería una hoja de ruta ser un artefacto estático que solo se crea y se revisa durante el desarrollo, o algo más orgánico, más iterativo?

Brandon Blackman

Sí, definitivamente creo que debe ser algo más orgánico, más iterativo. Si es estática, creo que hemos hecho suposiciones erróneas sobre los usuarios y sobre cómo funcionará el producto una vez lanzado. Porque al final del día, la hoja de ruta comunica algo hacia el futuro. Está pronosticando algo que, honestamente, no importa cuánto planifiques, nunca lo sabrás hasta llegar allí. Por eso la hoja de ruta debe tomarse como lo que es: un pronóstico, una vista al futuro y la mejor forma de tener el pronóstico más acertado es observar el presente y ajustar tu pronóstico según eso. Así que creo que siempre debe ser iterativa y nunca asumir que existe una versión final de algo.

Michael Luchen

Sí. Y básicamente asumir que es una versión final también puede ir en contra de los resultados deseados por los que se emplea.

Me gusta la palabra pronóstico que usas porque es sobre nuestra ciencia actual, por decirlo así, sobre el producto, nuestra comprensión actual de los usuarios y necesidades, el entorno de negocios, el entorno competitivo, pero a medida que construimos, todas esas variables cambian, lo que significa que la hoja de ruta debe servir a esas variables y también cambiar y evolucionar.

Brandon Blackman

Cien por ciento. Sí, estoy totalmente de acuerdo contigo en eso.

Michael Luchen

Entonces, supongamos que me voy a sentar a crear una hoja de ruta de producto para mi increíble producto ABC. ¿En qué debe centrarse?

Brandon Blackman

Esa es una excelente pregunta. Debes enfocarte realmente en el por qué y el qué estás construyendo. Creo de verdad que la tentación, especialmente si no tienes mucha experiencia elaborando hojas de ruta, es concentrarte en el cómo, porque esa es la pregunta que probablemente surge. Y querrás evitarlo. El cómo se deja para el backlog; el backlog describirá cómo vamos a hacerlo, pero la hoja de ruta debe centrarse en el por qué y el qué. ¿Por qué vamos en esa dirección? ¿Por qué nos centramos en ciertos temas? ¿Qué estamos priorizando? Usa la hoja de ruta para responder a esas preguntas y evita el cómo.

Michael Luchen

En muchas de nuestras hojas de ruta incluimos estados, temas y resultados. ¿Puedes hablar de ellos en el contexto de una hoja de ruta?

Brandon Blackman

Sí, buena pregunta. El estado, si una hoja de ruta tiene estados, son cosas como: esto es lo que estamos trabajando ahora, esto es lo que trabajaremos después y esto es para más adelante. Observa que no hay fechas asociadas. En cuanto pones una fecha y entiendo que a veces es necesario incluir fechas, pero en cuanto lo haces te comprometes con algo que tal vez no era necesario. Así que el concepto de estado es: esto hacemos ahora (hoy, mañana), después haremos esto (podría empezar mañana o la semana que viene, pero sabemos que es lo siguiente) y para más adelante (dirige más hacia el futuro). Así comunicamos claridad de dirección, pero sin comprometer fechas.

En cuanto a los temas, sería algo como la relación con el cliente. Puedes empezar a pensar en items, épicas o historias de usuario que contribuyen al tema. Si la hoja de ruta es orientada a resultados, puede ser "aumentar las interacciones con clientes en un 30%". Ese es un buen por qué y qué. El cómo, de nuevo, se queda en el backlog y para los especialistas. Puede haber muchas formas de incrementar esas interacciones, pero todo lo que la hoja de ruta debe comunicar es que vamos en esa dirección.

Michael Luchen

Eso es genial. Gracias por repasar esos caminos. Personalmente, he visto tanto poder en ese enfoque tan ágil al desarrollo de hojas de ruta. Permite concentrarse en lo que sabemos ahora y tener un área “en espera”, el siguiente paso, en función de temas o resultados, si se quiere.

Pero también tener el backlog con todas esas ideas adicionales, que quizá sean valiosas o no según se implementen, pero que no son compromisos estampados en una hoja de ruta permanente.

Brandon Blackman

Sí. Cuanto más te comprometes y grabas en piedra, más requisitos y expectativas tendrás que cumplir.

Michael Luchen

Totalmente, y algo que nombraste mucho fue: No pongas fechas, pase lo que pase, no pongas fechas. Seguro que muchos de los que escuchan piensan: me encantaría no poner fechas, pero mis interesados insisten en que hay que entregar para el día X o cumplir para el día X. ¿Cómo lo navegas?

Brandon Blackman

Sí, si pudiera controlar todo como quisiera, nunca habría fechas en una hoja de ruta. Sé que digo eso como un ideal, pero a veces tienes a tu CEO preguntando cuándo pueden esperar algo, o tu equipo de marketing necesita fechas para campañas, o soporte al cliente… Así funciona el mundo, a veces tienes que incorporar fechas, pero vivo en esa tensión e intento mantener la hoja de ruta lo más alto posible, usando fechas lo más generales posibles. La mayoría de las veces, esto se puede manejar con hojas de ruta trimestrales. Por ejemplo: en el segundo trimestre aumentaremos interacciones con clientes un 30% y tendremos tales funciones. Eso le sirve al marketing, al soporte y a todos para planificar, pero sigue siendo alto nivel y con margen, que es clave en el entorno ágil.

Así puedes trabajar con fechas de margen: inicio, medio o final de trimestre o incluso siguiente trimestre para externos, pero el actual internamente.

Michael Luchen

Me encanta la palabra margen y usarla como herramienta en la hoja de ruta. También el modelo mental del cono de incertidumbre: imagina un triángulo horizontal que empieza grande y se va estrechando. En el extremo ancho es donde estás hoy; hay mucha incertidumbre, mucho margen. Pero a medida que avanzas, te acercas y hay más certeza y aprendizaje.

En entornos ágiles, una táctica que valoro es usar los story points para poder establecer nuestra propia filosofía. Con algunos sprints, el equipo estabiliza una velocidad y entiendes riesgos técnicos, de UX, de mercado… Así puedes afinar fechas y permanecer ágiles.

Brandon Blackman

Me encanta esa idea del cono de incertidumbre y me recuerda a algo que acabo de hacer: miré mi 401k, y ese portafolio tiene una función de pronóstico, un poco como mi hoja de ruta hacia la jubilación, y muestra ese cono de incertidumbre. Ajustas las inversiones para tener una alta probabilidad de llegar a una meta, pero nunca sabes qué pasará. En productos, es parecido, y cuanto más alto está el interesado, más presión hay por fechas exactas.

Cuando preguntan qué esperar para tal fecha, está bien responder: ¿quieres saber con 90% de certeza o con 30%? Eso ayuda a manejar expectativas.

Michael Luchen

Qué gran analogía. Ahora, pasando a otro tema que genera opiniones: ¿cómo gestionas las dependencias en la hoja de ruta?

Brandon Blackman

Difícil de contestar universalmente. Pero, en general, lo mejor es notarlas y comunicarlas. Deben estar visibles en la hoja de ruta. Por ejemplo, si planeas algo para cierto trimestre, asegúrate de anotar: esto depende de X, Y, Z. Así mantienes la alineación. Un ejemplo típico: equipos de frontend y backend, donde uno depende de otro. A veces se crean “contratos de API”: documentos que definen lo que la API hará, así el frontend puede avanzar aunque el backend aún no exista. Ocurre igual a la inversa: el contrato especifica qué necesita el frontend para que el backend lo construya. Ambos equipos están obligados por el contrato y puede ser entre equipos de desarrollo y marketing, soporte u otros. Así el equipo dependiente puede ir preparando sus sistemas.

Michael Luchen

Muy interesante, sobre todo lo de los contratos de API. No solo se gestionan dependencias de negocio o contenido, sino técnicas y la estructura de equipos para una colaboración sana.

Brandon Blackman

Totalmente. Y claro, siempre habrá cosas que salgan mal. Por eso insisto en anotar las dependencias; cuando surja un cambio, puedes señalar exactamente el por qué y mantener la hoja de ruta como algo iterativo y vivo. Así eliminas el 80-90% de los problemas al pronosticar el futuro, solo con comunicar esas incertidumbres.

Michael Luchen

Hablaste de desafíos en el roadmapping ¿qué otros retos típico enfrentas, especialmente en gestión de releases junto con hojas de ruta ágiles?

Brandon Blackman

Buena pregunta. Un reto frecuente son los equipos que no son de producto. A menudo, stakeholders internos, especialmente en empresas grandes, no están familiarizados con Agile, así que toca comunicar y educar constantemente. La analogía que uso es: no estamos construyendo una casa, donde ya se conoce el proceso, sino algo único, a menudo sin precedentes. No hay forma de saber el futuro, por eso uso esa analogía. Otro desafío es admitir la obviedad: hay mucho desconocido. Con Agile aceptamos esa tensión entre "conocido conocido", "conocido desconocido" y "desconocido desconocido". Agile no lo elimina, pero sí lo maneja y canaliza para crear productos valiosos para el usuario.

Michael Luchen

Genial. Además, en desarrollo de software, la creación y gestión de conocimiento es continua. La típica metáfora de construir una casa no sirve aquí: es cómo crear los ladrillos, cómo aprender a fabricarlos y qué hacer si necesitas otro material. Ese aprendizaje continuo añade aún más variabilidad a la hoja de ruta.

Brandon Blackman

Correcto.

Michael Luchen

Ahora, bajemos un poco y hablemos de sprints y cómo ayudan a desglosar la hoja de ruta. ¿Cómo lo ves, Brandon?

Brandon Blackman

Un sprint debe tener un objetivo. Al final del sprint, ese objetivo debe cumplirse y siempre llevar el producto, el equipo y al usuario un paso adelante en la hoja de ruta. Si el objetivo de tu sprint está desconectado de la hoja de ruta, entonces lo que trabajas no contribuye a la dirección del producto. Siempre empiezo la planificación de sprints recapitulando la visión general de la hoja de ruta, luego elegimos las historias de usuario y aterrizamos el objetivo del sprint, que debe estar claramente vinculado al aspecto de la hoja de ruta en el que estamos. Incluso si hay pasos previos (por ejemplo, trabajo de back-end que sirve a una historia principal futura), debe ser claramente comunicado. El objetivo es el puente entre trabajo diario y hoja de ruta.

Michael Luchen

Muy bien. Me encantan los objetivos de sprint. Pero los sprints pueden volverse mini-Waterfalls: en dos semanas hay que cumplir o todo está mal. ¿Cómo evitar ese efecto en el contexto de la hoja de ruta?

Brandon Blackman

El sprint debe componerse de historias de usuario independientes y utilizables. Para quienes practican Agile, eso es crucial, pero incluso yo a veces caigo en historias mal definidas. Mantén las historias independientes, testeables y utilizables: nunca debes acabar un sprint con algo que no puede usarse hasta dos o tres sprints después. Ese sería un sprint waterfall. Deberías planificar de forma que cada sprint sea independiente, liberable y útil. No necesariamente se lanza a usuarios, pero sí a un entorno de pre-producción donde se pueda probar el valor entregado. Si siempre trabajas así, las fechas dejan de ser un problema.

Michael Luchen

Totalmente, y sobre historias de usuario, sin profundizar tanto porque daría para otro episodio, hay una línea fina: demasiadas detalles puede hacerlas rígidas; demasiada vaguedad, frena al equipo. Necesitas claridad suficiente para avanzar, pero también permitir la flexibilidad y creatividad del equipo.

Brandon Blackman

Sí, eso es esencial. Si eres demasiado detallista caes en el cómo, cuando como gerente de producto no necesariamente tienes esa visión técnica o de diseño. Es mejor dejar cierta ambigüedad y permitir a los expertos buscar la mejor solución.

Michael Luchen

Bien. Hemos hablado de las hojas de ruta, sus tipos y cómo desglosarlas en sprints. ¿Con qué frecuencia debe revisarse la hoja de ruta?

Brandon Blackman

Como gerente de producto, la veo casi a diario. Desde el punto de vista del equipo, debe revisarse en cada kickoff, cada periodo de planificación. Es la base para definir sprints y objetivos. A nivel empresa, cada vez que los responsables del producto comunican avances, es buen momento para mostrar la hoja de ruta y dar contexto, así stakeholders entienden el panorama general. Así que, siempre que puedas, muéstrala. Y como gerente de producto, deberías revisarla a diario o cada dos días.

Michael Luchen

Genial. Personalmente, ¿qué tipo y enfoque de hoja de ruta prefieres por defecto?

Brandon Blackman

Depende del producto, pero la mayoría de las veces prefiero hojas de ruta orientadas a temas. Permiten ver el tema vinculado a los objetivos vitales de la empresa y empoderan al equipo para elegir en qué trabajar, delegando a los desarrolladores y diseñadores la forma de lograr los temas. En productos pequeños como uno de venture lab que tengo con solo 14 días al año asignados, la hoja de ruta debe ser muy concisa para comunicar qué entregaremos en el año. En esos casos prefiero el enfoque de estados: esto hacemos ahora, esto después y esto más adelante.

Michael Luchen

Muy bien. Para acabar, ¿puedo hacerte unas preguntas rápidas personales?

Brandon Blackman

Adelante.

Michael Luchen

¿Cuál de tus hábitos personales más ha contribuido a tu éxito?

Brandon Blackman

Soy un poco tradicional y tomo notas con lápiz y papel. A veces escribo digitalmente para agilidad, pero tomar o repasar notas en papel me ayuda a grabar ideas, organizar el presente y planificar el futuro. Lo robo del método bullet journal.

Michael Luchen

Eso es genial. ¿Y fuera de cuadernos y lápiz, qué otra herramienta usas regularmente?

Brandon Blackman

Probablemente no te sorprenda: Miro, la pizarra virtual. No he hecho una hoja de ruta fuera de Miro desde que lo descubrí. Permite tener frames para hojas de ruta, imágenes, integración con Figma y con Jira. Miro cambió mi vida profesional.

Michael Luchen

Totalmente de acuerdo. Es la mejor hoja de ruta contextual posible.

Brandon Blackman

Sí.

Michael Luchen

Para alguien que empieza en la gestión de producto, ¿qué consejo le darías?

Brandon Blackman

Si pudiera hablarle a un Brandon más joven, lo animaría a aceptar un puesto de gerente de producto en una startup de tecnología sin experiencia previa. No sabía nada de gestión de producto ni Agile; simplemente salté. Mi consejo para aspirantes es: encuentra una startup o crea una, aunque sea de 5 pm a 2 am fuera del trabajo. Aplica el proceso ágil para crear algo propio. Lo mejor, tal vez fundas una startup exitosa; lo peor, obtienes experiencia y puedes trabajar en lo que te gusta.

Michael Luchen

Muy sabio. Muchas gracias, Brandon, por compartir tu experiencia en hojas de ruta y en otras áreas de desarrollo de producto.

Ha sido enriquecedor. Los que escuchan, pueden saber más de Brandon en crema.us o en LinkedIn. De nuevo, gracias por acompañarnos, Brandon.

Brandon Blackman

Gracias por invitarme.

Michael Luchen Y gracias a todos por escucharnos.

No olviden dejar una reseña del podcast, contarnos qué les gustó, qué les gustaría oír más, o algo que no hayamos tratado que quieran que abordemos. Y por supuesto, sígannos y únanse a nuestra comunidad en theproductmanager.com. Gracias de nuevo a todos por escuchar. Nos vemos en la próxima.