El Product Owner y su capacidad para analizar, priorizar y negociar

En la guía de Scrum hay una sección dedicada a definir el rol del Product Owner donde se dice:

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• […]
• Ordering the items in the Product Backlog to best achieve goals and missions;
• […]

Cuando hablamos del orden de los elementos del Product Backlog solemos usar la palabra priorizar. Siempre encontré dificultades a la hora de priorizar, tanto cuando era Product Owner como ahora trabajando como Programme Manager. Las dificultades se deben a que no es fácil poner en fila de a uno los elementos que maximizan el valor de tu producto, repito, no es fácil. A mi me encantaría poder tener una respuesta única que valga para todos mis Stakeholders cuando me preguntan: «¿por qué esto va antes que eso?». No hay un truco, no hay una regla mágica, generalmente hay un trabajo de analizar datos, tomar decisiones que implican priorizar y finalmente negociar.

El valor de analizar

Han pasado un par de años desde que le he dado a los datos la importancia que merecen. Los datos me han ayudado, no sólo a tomar decisiones, sino a reducir la necesidad de ‘convencer’ a otros de dichas decisiones. Para maximizar el valor del producto a través del equipo de desarrollo debes saber, en el contexto de tu producto y empresa, que significado tiene la palabra valor. Considero que hemos de analizar de forma frecuente información que nos llega desde diferentes fuentes: entrevistas a usuarios y clientes, informes donde se plasman nuestros KPIs, estado del mercado y nuestros competidores. En el contexto en el que yo trabajo esta información la generan otros roles, pero está siempre accesible para el Product Owner de manera que pueda hacer uso de ella en las conversaciones con los Stakeholders, con el equipo de desarrollo y consigo mismo, tanto cuando tiene que poner orden en el Product Backlog, como  para incluir información en sus elementos. Considero fundamental que el Product Owner analice los datos para incrementar su conocimiento del producto y tener un criterio para priorizar.

La dificultad de priorizar

Los datos nos ayudan a tener conocimiento, algunas veces nos van a permitir ver claramente por qué deberíamos hacer una cosa antes que otra, pero otras o bien no son concluyentes o no hay datos para tomar una decisión.

Cuando los datos no son concluyentes y/o suficientes, me gusta adoptar el enfoque de las hipótesis. Al final no estamos seguros de que un elemento vaya a aportar valor, pero sí creemos que podría si una serie de eventos ocurren. En este caso el elemento del Product Backlog pretende aprender, confirmar si esos eventos ocurren para tener suficiente información que permita tomar una decisión y priorizar, sencillamente saber si vamos a invertir en algo y en qué orden respecto los otros elementos existentes, o en caso contrario, si no vamos a invertir y debemos eliminar el elemento del Product Backlog. Una aclaración, que no tengamos datos concluyentes, no significa que sólo en estos casos necesitemos aprender. Debemos aprender sobre nuestro producto de forma constante, si añadimos al producto algo que sabemos nuestros clientes quieren, debemos medir el impacto, aprender de su experiencia y seguir iterando.

Existen numerosas técnicas que nos pueden ayudar a priorizar los elementos de nuestro Product Backlog. Personalmente, no hago uso de una única técnica, sino que las uso según el contexto en el que me encuentre. Si bien es cierto, que la primera pregunta que  siempre me hago es: «¿Y si no lo hacemos qué pasa?», digamos que una de las primeras cosas que siempre evalúo es el «Cost of Delay/Opportunity Loss» porque todo tiene un coste, pero no el mismo. Esto me permite filtrar sobre qué elementos debo analizar antes que otros y así dedicar más tiempo a definir la prioridad adecuada. El Product Owner debe considerar las diferentes fuentes de información para tener una propuesta clara de prioridades y ser capaz, en la medida de lo posible, de explicar por qué debemos realizar una cosa antes que otra evitando que estas justificaciones se basen en una opinión.

La capacidad de negociar

The Product Owner is the sole person responsible for managing the Product Backlog.

Es cierto, debe ser una única persona, imaginaros el caos de varias personas cambiando el orden de los elementos, el equipo de desarrollo no tendría una visión clara. Lo que sí es cierto es que el Product Owner no decide sólo las prioridades, hay muchas personas alrededor del producto con sus datos para hablar sobre las prioridades, y aquí la capacidad de negociar del Product Owner es fundamental, por ello hace una labor de analizar datos y definir las prioridades de la mejor manera posible.

Cuando uso la palabra negociar, no me refiero a intentar satisfacer a los Stakeholders, nada de: «venga anda te lo pongo en la siguiente iteración», no. El Product Owner debe crear un entendimiento común alrededor del producto por encima de las áreas de responsabilidad de cada Stakeholder. Lo mejor para el cliente en cada momento puede ser diferente a lo que el Stakeholder quiere. Cuando surgen estas conversaciones en sesiones dedicadas a revisar prioridades, hay una labor de moderación complicada, pero el trabajo que el Product Owner ha realizado para justificar sus prioridades ayudará a que el debate sea constructivo. Esto no significa que las prioridades que el Product Owner ha puesto sobre la mesa no se puedan tocar, significa que los cambios deben hacerse con criterio y pensando en lo mejor para el cliente. En estas conversaciones pueden surgir cambios de prioridades, convertir elementos del Product Backlog en algo aún más pequeño, simple y de menor alcance que quizá afecte a la prioridad del elemento original e incluso pueden surgir nuevas ideas; no sería la primera vez que alguien sale diciendo: «yo creo que deberíamos hacer…» estos casos es mejor trabajarlos fuera de la sesión, simplemente para separar la revisión de prioridades de la captura de ideas o propuestas. El Product Owner debe tener una capacidad de negociación para moderar sesiones de revisión de prioridades del Product Backlog, es difícil satisfacer a todo el mundo y por eso debe centrarse en lo mejor para el cliente final, el producto junto con datos que lo justifiquen.

En resumen, analizar frecuentemente los datos de su cliente y producto, tener una propuesta clara de prioridades y negociar con criterio el siguiente incremento con los Stakeholders, es clave para garantizar que el equipo desarrolla lo que más valor tiene en cada momento.

Algunas referencias de interés:

• An introduction to cost of delay
• 20 Product Prioritization Techniques: A Map and Guided Tour
• How to Implement Hypothesis-Driven Development