7 mitos del Product Owner

La figura del Product Owner es, de largo, de las más difíciles de conseguir dentro de una organización. Para empezar, porque es transversal, aglutina responsabilidad tanto en la parte de creación y construcción de producto como en la venta y puesta en marcha. Al asumir tal cantidad de labores, se dificulta mucho encontrar personas capaces de abordar, de manera completa, dichas funciones. Repasemos siete de los muchos mitos que existen alrededor del Product Owner. 

Es de negocio

Un Product Owner representa el equilibrio entre la venta y la ejecución de un producto. Debe pensar en los clientes, usuarios, interesados… pero también debe tener en cuenta lo que se puede hacer y el coste de hacerlo. Debe equilibrar lo que se hace con lo que se vende, para conseguir que el Producto genere valor, el máximo posible. 

En los departamentos de tecnología, se ha dado la espalda al negocio históricamente. Esto supone que nos cueste entender los detalles funcionales de un nuevo producto, lo que supone que exijamos personas de negocio dedicadas al papel del Product Owner. Sin embargo, nadie se obliga a ello. 

Es evidente que, para ser efectivo, un Product Owner debe conocer su negocio. Ahora bien, por encima de ello, debe dominar técnicas de Product Management, como por ejemplo: gestión de expectativas, métricas de valor, roadmaps o vertical slicing. 

Eso sí, si eres un Product Owner y tu experiencia en el contexto de tu producto es baja, ¡ponte las pilas! Mientras aumentas tus conocimientos, apóyate en personas que sí lo tengan para que te asesoren y te transmitan posibilidades que puedas usar en favor de la entrega de valor. 

Escribe Historias de Usuario

Recordemos que las Historias de Usuario son una técnica independiente respecto a Scrum. Aun así, un Product Owner no tiene por qué ser la persona que escriba los items del backlog (sean historias o no). Debe asegurarse de que lo que vayamos a hacer está claro, para evitar retrabajo. Siendo la persona con mayor contacto con los customers, debe estar encima de los detalles. Escribir los items ayudaría a ello, sin embargo no siempre es posible. 

Podemos tener algún developer de Scrum ayudando al Product Owner en esta función. Igualmente, podemos disponer de personas especialistas en UX o Análisis que completen los items, de cara a mejorar el entendimiento de los requisitos y reducir el retrabajo por errores de comprensión. 

El motivo por el que existe este mito es que en mucha bibliografía sobre Historias de Usuario se recomienda que el “cliente” escriba las mismas. ¿Quién es el cliente? Pues el propio usuario, las personas que deben describir cómo es su historia. Sin embargo, en muchas empresas consultoras confundimos cliente (el que paga) del usuario (quien lo usa) y esto nos hace entender que es el Product Owner el responsable de escribir las historias. 

Métricas de Proyecto

Las métricas se han convertido en una obsesión para muchos equipos y empresas. Cierto, necesitamos poder medir para poder controlar o, al menos, eso hemos aprendido con el paso de los años. Aquello que mides  es aquello que puedes mejorar, por tanto, debes elegir las métricas que se adecúan a tus objetivos. 

En un proyecto, se define la línea base de alcance, coste y tiempo, es decir, lo que haremos, cuánto nos llevará y cuánto costará. Una vez fijado, deberemos controlar que alcanzamos dichos objetivos o que no nos desviamos fuera de los parámetros que consideremos aceptables. 

En Agile, existen métricas como puntos de historia que, aunque mejoran lo existente, siguen viviendo en el paradigma de la estimación a priori. Este tipo de métricas deben ser rechazadas o, al menos, puestas en segundo plano. 

Un Product Owner maximiza valor, por tanto, necesita métricas de valor. El valor de un producto es el resultado de muchas métricas: ROI, time to market, capacidad de innovar o calidad técnica. Es clave elegir las métricas correctas sobre las que inspeccionamos cada Sprint Review. 

Ordena el Backlog por Valor

La gestión del Product Backlog es clave para la labor de un Product Owner. Decidir el orden en el que acometeremos el trabajo es una de las decisiones más relevantes para maximizar valor. Muchos equipos consideran, erróneamente, que hay que ordenar el trabajo por valor y no es del todo exacto. Un Scrum Team debe hacer aquello que aporte más valor, que tenga menor tamaño y no tenga riesgo desarrollar. 

¿Cuál es la regla para ordenar del Product Backlog? Como  considere el Product Owner, alineándose con el Product Goal y la estrategia que se haya definido. Por ejemplo, podemos decidir desarrollar funcionalidades que, a corto plaza, no nos aporten mucho valor pero que sirvan para habilitar futuro valor o velocidad en el desarrollo. 

No asiste a la retrospectiva

La Sprint Retrospective (Retrospectiva) es el evento que cierra cada Sprint. Su función es inspeccionar cómo trabaja el Scrum Team para crear un plan de acción con mejoras que permita entregar mayor valor. En Scrum, la única más importante es el Scrum Team, y el Product Owner es parte de este equipo por lo que su función en la retrospectiva es la misma que cualquier otro miembro. 

Los Product Owners que no asisten a este evento acaban provocando una separación entre los developers, lo que puede acabar en un enfrentamiento que no suele ser muy productivo. Es cierto que un Product Owner tiene un foco diferente al resto, porque se centra en el “qué” y la gestión de expectativas, ahora bien, la unión de todos es pieza esencial de la entrega de valor y por eso es parte de la Retrospectiva. 

Repartir tareas

Existen los Product Owner que están muy encima de los equipos. Hay detalles que nos muestran este tipo de Product Owner: 

• Muy pendientes de las tareas del equipo
• En la Sprint Planning, se centran en “dar tareas a las personas”
• Participan activamente en la Daily Scrum preguntando a las personas cómo van
• Planifican a largo plazo las tareas a nivel persona
• Priorizan el trabajo en base a “ocupar a las personas”

Todas estas pistas nos ayudan a identificar al Product Owner con mentalidad de Jefe de Proyectos. Este tipo de perfiles busca “maximizar el trabajo de los recursos (personas)”. ¡Esto es un gran error! Un Product Owner se centra en el trabajo que hay que hacer. Una vez el trabajo está ordenado, dejamos que el equipo se autogestione para acometerlo. Si tenemos que estar encima de las personas, el problema no es de Scrum sino de confianza.

Valida los desarrollos

Existe mucha bibliografía que asegura que, durante la Sprint Review, el Product Owner debe validar el incremento de los Developers. Esto es incorrecto, el objetivo de la Sprint Review es inspeccionar el producto con los interesados para adaptarnos lo antes posible. El Product Owner debe ir a la reunión sabiendo el estado del producto, ya que debe poder explicarlo y trabajarlo con los interesados. 

Es cierto que ciertos equipos  buscan que el Product Owner inspeccione previamente el trabajo a medida que se completa, para validar que se ha entendido lo que se quería desarrollar. Este ejercicio puede ser sano y entenderse como parte de la autogestión promovida dentro del Scrum Team. Ahora bien, no debemos convertir esta práctica en un hábito porque puede llevarnos a un desarrollo en fases, lo que afectaría a nuestro tiempo de entrega. 

Estos son los principales errores que hemos podido detectar en el Product Owner, ¿cuáles has visto?