Competencias Clave del Product Owner

Introducción

Diseño sin título (17).png

El rol de Product Owner completa la triada de roles en los cuales se basa el enfoque colaborativo del marco de trabajo Scrum. Esta triada, independientemente de la nomenclatura, buscar tener representación y participación del negocio, la parte humana, y la parte técnica. 

El rol del Product Owner es especialmente importante pues es quién definirá el producto que construirá el Equipo de Desarrollo, los tiempos en los cuales será liberado, las características esenciales del producto, y a quienes serán sus principales consumidores.

Yendo un paso mas atrás, el Rol del Product Owner se hace necesario cuando vamos a construir nuevos productos o cuando queremos llevar productos existentes a nuevas alturas. Si lo anterior no ocurre habría que partir por el primer cuestionamiento de si vale la pena usar Scrum o no.

La carrera de un Product Owner estará marcada por varios lanzamientos de productos −algunos exitosos con suerte− y la constante lectura del mercado y sus tendencias. 

Es vital también entender que la organización donde trabaja el Product Owner le concede total poder de decisión acerca del producto; para esto desde luego la organización deberá repensarse a si misma como una organización que crea productos y no solo ejecuta proyectos.

Fundamentos del Rol de Product Owner

El rol de Product Owner muchas veces es confundido con el de un Project Manager que se encarga de hacer que todo funcione bien, es decir lo mismo de antes pero sólo con un cambio de nomenclatura. Desde luego ésta es una disfunción de Scrum y no conduce a resultados positivos y duraderos.

En la práctica he observado que algunos Product Managers transicionan al rol de Product Owner y eso produce mejores resultados por dos razones:

  1. La existencia de Product Managers indica que la organización ya trabaja en función de productos y no sólo proyectos

  2. Los Product Managers ya tienen poder de decision suficiente para decidir el curso de acción sobre un producto

Lo anterior no es mencionado como una receta para maquillar el esquema actual y ahora llamarlo Scrum, lejos de eso sólo lo menciono con el afán de enfatizar que el Product Owner necesita tener poder de decisión y que el enfoque organizacional debe estar ahora en productos. 

Product Owner Vision.png

Existen varias responsabilidades para el rol de Product Owner, algunas de las más importante son:

Product owner (2).png
  • Ayudar a la organización a crear productos comercialmente y técnicamente viables que acaben deleitando a los clientes finales

  • Trabajar de la mano con los clientes para descubrir como solucionar sus problemas y atender sus necesidades a través de un producto

  • Descubrir a través del ordenamiento del Product Backlog que características no se incluirán (o por lo menos no todavía) en el producto

  • Promover dentro del equipo, la organización y con los clientes el enfoque minimalista y de retroalimentación rápida (basado en Lean Startup [Reis11]) para construcción de productos

  • Fomentar el crecimiento técnico dentro del Equipo de Desarrollo a través de la inversion de tiempo para aprendizaje

  • Educar a los clientes y la organización acerca de la realidad en la variabilidad del alcance 

Cuando el Product Owner llega a dominar las competencias de su rol se podrían esperar beneficios como estos:

  • Haber desarrollado una vision estratégica para colocar el esfuerzo del equipo en la implementación de características con gran futuro

  • Tener un pensamiento sistémico que le permitirá ver el producto y su ciclo de vida considerando múltiples variables [Senge90]

  • Concebir el producto como un ente viviente que se extiende a lo largo del tiempo, las tecnologías, los mercados y los clientes

  • Dominar el vocabulario del cliente y entender a cabalidad su giro de negocio

  • Desarrollar una intuición de hacia donde debe ir el producto a futuro

El rol del Product Owner mal interpretado puede degenerar en anti-patrones que afectan grandemente al equipo Scrum y a la organización. Algunos de estos anti-patrones son:

  • El Product Owner es solamente un tomador de ordenes y escritor de historias de usuario sin poder de decisión sobre el producto

  • El Product Owner es incapaz de ordenar el Product Backlog y sostiene que todos los items son igualmente importantes y se deben implementar

  • El Product Owner trabaja a tiempo parcial en otra función y no dispone de tiempo para cumplir a cabalidad con las responsabilidades de su rol

  • La organización pone a alguien técnico que no conoce del nada del mercado y los clientes en el rol de Product Owner

  • El Product Owner solamente aparece en el Sprint Planning y el Sprint Review dejando al equipo a la deriva durante el Sprint

Estos anti-patrones son desde luego lo opuesto a lo que se debería esperar de un Product Owner que entiende y cumple a cabalidad con las responsabilidades que su rol implica.

El contexto organizacional dentro del cual opera el Product Owner también tiene un efecto sobre el rol, los siguientes son algunos ejemplos de estos contextos:

  • La organización le confiere poder absoluto sobre el producto al Product Owner, es decir, esta en sus manos conocer y decidir acerca del problema, la solución, el producto y el mercado

  • El Product Owner recibe el mandato de construir un producto que a alguien más se le ocurrió y para un mercado que el no conoce a cabalidad

  • El Product Owner en realidad no trabaja en un producto sino en varios proyectos de corta duración

  • El Product Owner no construye un producto para un mercado interno sino que más bien provee soluciones para otros equipos o departamentos 

Si bien Scrum se podría llegar a aplicar en los cuatro contextos anteriores he observado que el primero explota a cabalidad el potencial del rol del Product Owner. Cabe aquí puntualizar que en esencia Scrum se pensó para creación de productos, no para ejecución de proyectos o prestación de servicios. 

Trabajando con los Stakeholders

Gran parte del trabajo del Product Owner consiste en mantener el respaldo de los stakeholders; para esto mostrar el progreso en la construcción del producto es esencial [Pichler16]. La lógica detrás de esto es mostrar a los stakeholders que se esta avanzando hacia un objetivo. 

Para mostrar avance existen varias maneras, dos de las más comunes son:

Product Owner and Stakeholders
  1. Con indicadores y métricas como el product roadmap y el release burn-up chart

  2. Con software funcionando con el cual los stakeholders pueden interactuar en el Sprint Review o en cualquier otro momento durante el Sprint

La segunda manera es la que a la larga provee mejores chances de conseguir retroalimentación real y una apreciación más realista del grado de progreso del producto. 

Los stakeholders necesitan permanecer interesados en el producto para que su participación sea activa y voluntaria en lugar de pasiva y forzada [Watts17]. Hacer preguntas directas es siempre la forma preferida pero hay situaciones en las cuales las respuestas pueden ser muy largas o el grupo de stakeholders es muy grande.

En situaciones como las mencionadas en el párrafo anterior se pueden aplicar técnicas como estas para tener a los stakeholders participando e involucrados con el producto:

  • Grupos de afinidad que se forman con stakeholders que comparten la misma opinion, interés o punto de vista

  • Votación con puntos en un papelógrafo para decidir acerca de que item, idea o alternativa tiene mas futuro

  • Votación con los dedos de la mano que permite decidir incorporando el voto de la mayoría 

El Product Owner podría llegar a actuar como un facilitador neutral con los stakeholders en situaciones como estas:

  • Cuándo un stakeholder presenta una idea que le parece descabellada al resto e interrumpe a quien la propone sin dejar que termine de proponerla

  • Cuando los stakeholders tienen opiniones contrapuestas acerca de un item o característica del producto

En ambas situaciones el Product Owner podría proponer la escucha como mecanismo para la información, el entendimiento y el posterior debate. 

La no-neutralidad podría generar una fractura en la relación con un stakeholder o un grupo de ellos; o lo que es aun peor, perderse de la creatividad que viene de la diversidad de opiniones que solo ocurre cuando el grupo es funcional [Lencioni02]. 

Sin embargo existirán situaciones en las cuales el Product Owner deberá tomar un abordaje diferente, por ejemplo cuando se ha perdido demasiado tiempo debatiendo y se necesita una decisión rápida.

En situaciones como estas el Product Owner puede usar su prerrogativa y decidir por ejemplo en qué orden se implementaran los items del Product Backlog, o si un item merece la pena o no ser incluido en el Product Backlog.

Cabe sin embargo recalcar que el Producto Owner no construye un producto que le sirva a él sino que contribuya valor para los stakeholders. La lógica aquí es no imponer la voluntad o preferencia del consultor por encima de la necesidad del cliente [Lencioni10]. 

Trabajando con el Equipo de Desarrollo

Diseño sin título (19).png

El Product Owner colaborar con el equipo en varias instancias, una de las más importantes es en la Definición de Terminado. Esta definición es un acuerdo de trabajo creado y mantenido por el Scrum Team y la intención es tener claridad acerca de cuándo algún item se considerara realmente terminado.

Cabe enfatizar que “terminado” para que tenga valor debe ser algo que los stakeholders puedan ver y de lo cual puedan dar retroalimentación. Como corolario, items que cumplen con condiciones solamente técnicas, como por ejemplo que no rompan el build, no presentan valor de negocio y por tanto no accionan el feedback de parte de los stakeholders. 

Otra instancia cuando el Product Owner debe colaborar con el equipo de desarrollo, y principalmente con los stakeholders, es descubriendo el Product Backlog con las cosas que tendrá el producto. 

Descubrir el Product Backlog es una tarea central y funciona mejor bajo un enfoque colaborativo y dinámico en el cual en grupo de personas exploran juntas las características, mercados, usuarios y problemas que potencialmente resolverá el producto [Patton14]. 

En eventos como el Refinamiento el Product Owner tendrá la oportunidad la oportunidad de trabajar lado al lado con el Equipo de Desarrollo ordenando los items que vendrán en el siguiente Sprint; cabe hacer notar que es el Equipo de Desarrollo el que se encarga de descomponer y estimar los items para el siguiente Sprint.

También es factible que el Equipo de Desarrollo planifique solamente suficientes items para uno o dos días y que en la reunion de Refinamiento se planifiquen los siguientes items; este tipo de planificación en base a items terminados y capacidad liberada se basa en un sistema pull [Ohno13].

Es importante recalcar que él Product Owner no conoce en detalle cada uno de los items del Product Backlog pues esta labor seria demasiado exhaustiva y lo desviaría de la verdadera función de su rol que es tener la vision y estrategia del producto.

Lo anterior nos lleva a que el Product Owner debe saber quien originó el requerimiento para que así pueda direccionar al desarrollador que trabajará en ese requerimiento para que hable directamente con el usuario. 

Si las conversaciones deben ser registradas para la posteridad por razones pragmáticas como poder recordar lo dicho entonces grabar un video resulta la forma mas eficiente. Aun mejor es cuando se graba un video de la conversación que va ilustrada con dibujos en un papelógrafo.

Product Ownership con Multiples Equipos

Ser el Product Owner de multiples equipos implican desafios como por ejemplo:

Diseño sin título (20).png
  • El principal y mas grande desafío siempre es la comunicación, empeora cuando los equipos se hallan en zonas horarias diferentes y hablan idiomas distintos

  • Un segundo gran desafío es hacer que todos lo equipos tomen items del Product Backlog que sea de alta prioridad y que contribuyan valor perceptible para los stakeholders

  • Finalmente esta el desafío de mantener un producto congruente creado por un único equipo aunque este este globalmente distribuido

Los desafíos anteriores son solamente algunos ejemplos de los que encontrara un Product Owner que trabaje con múltiples equipos. Desde una perspectiva sistémica mientras mas equipos se tiene mayor es la complejidad y por tanto habría que tender a la simplificación.

Como se sugiere en LeSS [Larman17] para lograr simplicidad sistémica a la hora de trabajar con multiples equipos abría que mantener la simplicidad y elegancia de Scrum a través de condiciones como: trabajar con equipos locales, mantener un solo Product Backlog y tener un único Product Owner.

El escalamiento solamente debería intentarse cuando no hay otra alternativa, mas aun, en lugar de escalar con mas gente habría que de-escalar reduciendo la complejidad sistémica para rescatar así la esencia de Scrum que se basa en equipo autónomos y auto-manejados.

Conclusiones

El rol del Product Owner bien entendido puede llevar a las organizaciones a construir productos que realmente produzcan un impacto positivo en el mercado beneficiando a los usuarios o clientes finales. 

Para que lo anterior acabe ocurriendo se necesitara no solamente de Scrum dentro del equipo sino también del cabal entendimiento por parte de la alta gerencia de la organización que implica el cambio hacia Scrum.

Un punto esencial de ese cambio es entender que el Product Owner tiene total poder de decisión acerca del rumbo del producto, decidiendo qué características tendrá el producto y en qué orden se implementaran.

Finalmente, quien asuma este rol deberá poseer entre otras cualidades una mentalidad estratégica y un espíritu emprendedor que le permita fallar rápido de ser necesario o perseverar hasta alcanzar los objetivos del producto. 

Bibliografia 

Reis11 Reis E., 2011. The Lean Startup, Crown Business 

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Watts17 Watts G, 2017. Product Mastery: From Good To Great Product Ownership, CreateSpace Independent Publishing Platform

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Lencioni02 Lencioni P., 2002. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass; 1st edition

Lencioni10 Lencioni P., 2010. Getting Naked: A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty, Jossey-Bass; 1st edition

Patton14 Patton J., 2014,  User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Artículo Original: https://percella.com/2019/03/01/competencias-clave-del-product-owner/






Bruno SuarezComentario