Agile, Métricas, scrum

¿Qué actitud debe tener un Product Owner?

Hemos hablado en el pasado de Herramientas que puede utilizar un Producto Owner y de labores que puede realizar. Todo este tipo de herramientas facilitan el trabajo de un Product Owner, ¿funcionan con todos? En mi experiencia, he visto que no siempre funcionan todas las herramientas con todos, y tiene que ver con la parte soft, con la actitud con la que un Product Owner afronta su trabajo. 

En los últimos meses, he podido trabajar con Products Owner con una actitud diferente que demuestran su capacidad de entrega y que permiten mejores resultados a la organización. Un buen Product Owner aporta muchísimo a cualquier iniciativa de desarrollo ágil que se esté elaborando en una empresa, porque ayuda a demostrar que trabajar de otra manera permite mejores resultados. 

¿Hasta dónde alcanza el trabajo del Product Owner? 

Es importante que recordemos que el trabajo de un Product Owner es el de gestionar su propio producto. Gestionar un producto tiene muchísimas labores y no todas las cubre Scrum: gestionar entregas, subir a producción, ponerle nombre al producto, decidir el equipo, hacer marketing del mismo, ponerle precio a los usuarios… Todas estas labores son necesarias en un producto, pero Scrum no habla de ellas y deja cierta libertad a las organizaciones para decidir. 

¿Qué ocurre con todas aquellas actividades de Product Management que no son cubiertas? Todo dependerá de la organización en la que estemos.

scrum-y-product-managemnet.png

En algunas organizaciones, existe una jerarquía operativa encima del Product Owner, y esas funciones de Product Management se van escalando. En la mayoría de organizaciones, están repartidas, como branding y marketing, que pueden realizarse en un departamento comercial. En algunas, suelen crear la figura del Product Manager como una figura que realiza gran parte de esas labores, dejando al Product Owner como una figura más operativa y de construcción de producto. 

En mi experiencia, nunca he visto a un Product Owner con un poder absoluto. Sin embargo, los mejores Product Owner que he conocido tenían un cierto grado de autonomía y de capacidad de tomar decisiones. Si eres un corre-ve-y-dile, difícilmente tu labor tendrá sentido más allá de ser un comunicador y, por tanto, un punto de posible pérdida de información. 

¿Cómo afrontar las labores que no puedo cubrir? 

Los mejores Product Owner piensan principalmente en su producto, esto significa que son capaces de poner encima de la mesa argumentos para discutir una decisión si consideran que no es correcta. Por ejemplo, negocio nos pide añadir una funcionalidad de manera temporal hasta que abordemos una solución definitiva. Un Product Owner, con visión estratégica, puede argumentar que el tiempo invertido en algo temporal afectará a features que pueden querer más adelante. 

La actitud de un buen Product Owner es la de conocer muy bien la estrategia de la compañía y cómo su producto está alineado con la misma de cara a desbloquear impedimentos. Por ejemplo, si necesitamos una feature que va a desarrollar otro producto, podemos pedir que adelanten ese desarrollo si nuestro producto es muy prioritario. Este tipo de debates enriquecen la labor del Scrum Team de poder entregar valor ya que se focaliza todo en entregar y en los impedimentos que provocan que nos cueste más tiempo. 

Herramientas Básicas para hacer tu trabajo

Hemos hablado mucho sobre diferentes herramientas que puede tener un Product Owner. La principal de todas es la palabra “no”. Muchas personas solicitarán funcionalidades, dependencias, fechas… Un buen Product Owner debe ser capaz de ponerse firme y el “no” ayuda. Eso sí, hay que usar el “no” con alternativas que permitan una buena gestión de interesados. 

Para poder decir que “no”, recomiendo a los Product Owner que construyan una Estrategia de Producto y métricas de valor que definan el éxito de lo que estamos construyendo. De esta manera, ante una petición externa, podemos confrontarla con nuestra estrategia y con el impacto en nuestras métricas que tiene esa solicitud. Si, por ejemplo, teníamos pensado hacer el módulo A y esta petición ataca a una parte del producto que no pensábamos abordar ahora, podremos argumentarlo y defender nuestra postura. 

A la hora de hacer la estrategia, tenemos multitud de opciones: User Story Mapping, RoadMap o Planes de Releases. Todos ellas nos permiten ver a largo plazo lo que vamos a construir, y cómo los elementos que estamos abordando se relacionan con el total de nuestro producto. Además, podemos gestionar dependencias de cara a evitar introducir en un Sprint elementos que no están bien trabajados o tienen dependencias sin resolver. 

Para las métricas, recomendamos seguir Evidence Based Management, donde encontraremos muchas opciones que podremos aplicar en nuestro producto. Es interesante tener métricas de éxito y métricas secundarias, ambas nos dan información que un Product Owner utilizará para gestionar expectativas con interesados. 

Puede que el debate sobre “¿Cuándo estará todo?” siga estando, pero demostrando que tenemos una estrategia y métricas de valor, podremos eliminar conversaciones en torno a fechas, y centrarlas en impedimentos que limiten al equipo en su capacidad de entrega.

women-1209678_1280.jpg

Actitud con los interesados

Un Product Owner tiene que comunicarse tanto internamente (Scrum Team) como externamente (Interesados / Stakeholders). Para los primeros, recomiendo transparencia. A veces, la palabra “no” falla, y tenemos que aceptar trabajos o hitos con los que no estamos de acuerdo. Es vital tener informado al Development Team en todo momento, si le transmitimos transparencia generamos confianza, y es un elemento clave de un equipo sano que “rema junto”. Recordemos que el Product Owner define el valor, pero será el Development Team quien lo cree, y hay que tenerlos enganchados. 

Disponer de métricas de salud o felicidad del Development Team es importante. Los mejores Product Owners con los que he trabajado querían tener estas métricas porque entendían que un equipo motivado le ayudaría más a afrontar los retos que el equipo tendría que superar. 

Respecto a los interesados, esto es clave para el Product Owner. La gestión de productoque haga y cómo la transmita le puede permitir trabajar bien o que el producto sufra mucho. Es importante apoyarse en la Sprint Review como evento en el que inspeccionar el producto y adaptar mejoras o cambios a futuro. Orientar las conversaciones a negocio, hace que un Product Owner gane en credibilidad y que le permita tomar decisiones en áreas que inicialmente no puede tocar. 

Un buen consejo es tener un mapa de interesados donde se tengan localizadas las preocupaciones de cada uno. Tener reuniones constantes para obtener necesidades y requisitos hace partícipe a las personas de la toma de decisión, y permite tener a los interesados enganchados con el producto. 

Be Product Owner My Friend

Ser Product Owner es una figura clave en las organizaciones. Muchas de ellas no entienden esta figura y, por eso, hay pocas personas con experiencia real ejerciendo. Apoyarse en el Scrum Master con experiencia puede ayudar a desbloquear impedimentos del propio equipo o de interesados. Por todo ello, si eres Product Owner o estás acompañando a uno, hazle ver la importancia de su trabajo, no son analistas “agile”, son maximizadores de valor, y deben destacar al equipo como una pieza importante para las organizaciones, sobretodo aquellas que buscan la transformación digital. 

¿Cómo actúan tus Product Owner? 

2 comentarios sobre “¿Qué actitud debe tener un Product Owner?”

  1. Daros las gracias a los dos por este Blog. He ido pasando por diferentes etapas profesionales comenzando por la parte técnica y pasando los últimos 4 por tareas de gestión. Desde hace un año la empresa para la que trabajo está viviendo una gran transformación digital pasando del 100% de Proyectos WaterFall a más del 75% en Agile con nuevas figuras que han tenido que ir incorporando porque se pensaban que los antiguos jefes de proyecto eran Scrum Master y los antiguos responsables del Negocio, los Product Owner.

    La realidad es que ni unos son una cosa ni los otros la primera y me he encontrado con un proyecto de más de 1 año de duración como Gestor de proyectos, teniendo que realizar tareas también de Jefe de Equipo, Scrum Master y Product Owner. Esto es poco viable pero la experiencia ganada me ha hecho dar el salto y la próxima semana comienzo como Product Owner (cómo único rol) para una nueva empresa en plena transformación digital, pero aparentemente, con las cosas bien hechas.

    Tengo grandes lagunas en el puesto y es algo que saben, pero han apostado por mi. Blogs como el vuestro me ayudan a seguir comprendiendo cómo será mi trabajo los próximos años.

Deja un comentario