La alternativa a los roadmaps
La siguiente cita del General George Patton siempre me ha parecido genial:
"No le digas a la gente cómo hacer las cosas. Diles qué hacer y te sorprenderán con su ingenio".
Desafortunadamente, los roadmaps hacen exactamente aquello contra lo que advierte el General
Los roadmaps les dicen a los equipos qué hacer y cómo hacerlo. Normalmente esto ocurre en forma de listas priorizadas de features o proyectos, de los cuales alguien realmente cree que resolverán el problema (aunque el problema a menudo aún no está claro o no se ha comprendido realmente).
Si en tu roadmap aparece algo como "añadir PayPal como opción de pago adicional", ¿es porque crees que hay clientes que no pueden pagar con tus otros métodos de pago? ¿O tiene que ver con el comercio de pagos internacionales? ¿O quizás alguien cree que sería una desventaja competitiva no ofrecer esta opción?
Ya he señalado en varios artículos que considero los roadmaps clásicos de producto como la fuente de muchísimo desperdicio (waste) en equipos de producto. El artículo Productos fallidos trata sobre este tema y en Verdades incómodas del desarrollo de productos profundizo más en este concepto.
Dado que el problema con los roadmaps está recibiendo cada vez más atención, últimamente me han pedido con más frecuencia que hable sobre la alternativa a los roadmaps.
Un tema amplio
En este artículo quiero intentarlo. Es un tema grande, que también está relacionado con temas como cultura de producto, empoderamiento y autonomía. Normalmente necesito al menos una hora para explicar todo esto personalmente, pero espero poder resumir la esencia aquí.
Antes de lanzarnos a la alternativa a los roadmaps, debemos tener claro que los roadmaps se han utilizado durante tanto tiempo porque cubren dos necesidades muy específicas, y estas necesidades no van a desaparecer sin más.
1) La dirección quiere asegurarse de que los equipos trabajen primero en los ítems con mayor valor para la empresa.
2) Como tienen una empresa que dirigir, hay situaciones en las que necesitan plazos y compromisos concretos, y con los roadmaps pueden capturar y rastrear esos compromisos.
Para que una alternativa a los roadmaps clásicos sea aceptada en las empresas, estos dos puntos deben abordarse al menos tan bien como hasta ahora.
Los roadmaps tienen sus raíces en el antiguo modelo centralizado de Command-and-Control. Algunos stakeholders celebran una reunión, generalmente trimestral, para pensar en las prioridades y proyectos de los equipos para el próximo trimestre.
En cambio, en el modelo de equipos de producto, los equipos deben poder descubrir por sí mismos cómo resolver los problemas de negocio de los que deben ocuparse.
Pero para eso no basta con tener buenos empleados. El equipo necesita el contexto necesario. Los miembros del equipo deben haber interiorizado hacia dónde quiere ir exactamente la empresa y deben haber comprendido qué debe contribuir su propio equipo a ese objetivo superior.
Volviendo al General Patton:
Como quizás ya sepas, el ejército también trabaja con el concepto de equipos autónomos. Estos equipos (Squads) se mantienen deliberadamente pequeños y son en su mayoría autónomos, siempre tienen en mente las intenciones comunes, pero pueden decidir por sí mismos lo que consideran la mejor manera de resolver un problema determinado.
Estas intenciones comunes son el contexto que mencioné antes. "A través de las intenciones se formulan con precisión los objetivos e intenciones superiores... Intenciones claras conducen a actividades enfocadas en las fuerzas. Reflejan lo que el comandante quiere lograr y por qué, y generan un sentido de pertenencia en las fuerzas. Normalmente se expresan a través de posibles impactos, objetivos y resultados deseados... Intenciones realmente bien formuladas son comprensibles para los subordinados sin una gran cantidad de detalles adicionales."
Las empresas tecnológicas tienen diversas formas de proporcionar este contexto o estas intenciones. Sin embargo, yo abogo por dos componentes muy específicos:
La visión de producto: describe la perspectiva holística de las cosas que la organización en su conjunto intenta lograr.
Los objetivos empresariales: describen los objetivos empresariales específicos y priorizados para cada equipo de producto individual.
Existen varios sistemas y metodologías para gestionar estos objetivos empresariales. Mi favorito actualmente es el sistema OKR (Objectives and Key Results).
La idea en sí es bastante simple: dile a los miembros del equipo qué deben lograr y cómo se medirán los resultados. Luego deja que el equipo decida por sí mismo lo que consideren la mejor manera de resolver los problemas respectivos.
Supongamos, por ejemplo, que tu producto actualmente necesita 30 días para el proceso de onboarding de nuevos clientes. Sin embargo, para poder escalar de forma efectiva, esto debe reducirse a 3 horas o menos. Eso sería un buen ejemplo de objetivo para uno o varios equipos de producto: "Reducir drásticamente el tiempo hasta que un cliente esté operativo." Uno de los resultados clave podría ser: "Tiempo medio de onboarding inferior a 3 horas."
Aunque el concepto de objetivos de equipo suena bastante simple, hay muchas formas de institucionalizarlo en equipos de producto y organizaciones, y puede llevar algunos trimestres hasta que la organización disfrute de los beneficios de este concepto.
Hay algunas ideas sobre la visión de producto y especialmente sobre la buena aplicación del sistema OKR que destacaré en los próximos artículos. Mientras tanto, puedes echar un vistazo al material de Christina Wodtke.
Este contexto es muy importante: la visión de producto y los objetivos del equipo.
Al principio señalé que debemos tener en cuenta las dos razones principales de los clásicos roadmaps. La primera era el deseo de trabajar primero en los ítems con mayor valor para la empresa. Esperemos que quede claro que la dirección aborda esta necesidad proporcionando los objetivos específicos para la organización y su priorización. La diferencia, sin embargo, es que ahora priorizan la importancia de los resultados de negocio en lugar del valor subjetivo de los features.
La segunda razón era la necesidad de compromisos, que abordamos con el concepto de compromisos de alta integridad. Esto se refiere a situaciones en las que realmente necesitamos un compromiso para una fecha o un resultado determinado.
Este enfoque tiene varias ventajas:
En primer lugar, los equipos están mucho más motivados cuando pueden pensar por sí mismos cuál consideran la mejor solución al problema.
En segundo lugar, el equipo no se sale con la suya simplemente entregando un feature o proyecto deseado; el feature también debe funcionar realmente (lo cual se mide mediante los Key Results). Si no es así, el equipo debe probar otro enfoque para resolver el problema.
En tercer lugar, independientemente de dónde venga la idea para una solución, muy frecuentemente el primer enfoque no funciona y, en lugar de negarlo, en este modelo se es muy consciente de ello.
Todo gira más en torno al Outcome en lugar del Output: obtener un resultado significativo en lugar de simplemente cumplir un objetivo cualquiera.
A menudo pido a los equipos que miren hacia atrás al último año y se evalúen a sí mismos según la tasa de éxito de su roadmap, específicamente en cuántos ítems realmente correspondían a los objetivos empresariales. Si haces esto y no estás orgulloso de lo que descubres, espero que consideres esta alternativa. Asegúrate de que tu organización de producto tenga una visión de producto convincente. Asegúrate de que cada equipo de producto tenga objetivos empresariales claros y priorizados. Asegúrate de que todos los compromisos que deban asumirse sean compromisos de alta integridad.
Y ahora empodera a tus equipos de producto para que puedan decidir por sí mismos qué soluciones consideran más adecuadas para determinados problemas de negocio, y observa cuántos de tus equipos te sorprenden con sus resultados.
Este texto proviene del blog de Marty Cagan y fue traducido al español.
Seminario de Product Owner
=> Visita ahora un seminario de Product Owner de Agile Academy.
El Product Backlog
=> Lee más sobre el Product Backlog en el diccionario ágil.
El rol del Product Owner
=> Aprende más sobre el rol del Product Owner.
