Si la semana pasada Patricia hablaba sobre “el buen Scrum Master”, hoy hacemos lo propio con el Product Owner.

Recuerdo cuando hace algunos años fui a renovar el carné de conducir y la persona en administración me preguntó por mi profesión, para completar algún formulario. Intentando simplificar y no confundir a nadie, le respondí que era «manager de producto». Su comentario posterior, que podría haberse ahorrado, no me defraudó: «eso y nada es lo mismo, ¿no?» 😊 Lo cierto es que el de Product Owner o Propietario de Producto es uno de esos perfiles raros, nacidos de la mano de Scrum y al albur de las empresas tecnológicas, además con un fuerte componente técnico. Son individuos que se sitúan en la intersección entre tecnología, experiencia de usuario y negocio, y cuyo papel se ha vuelto esencial en este tipo de compañías, a pesar de que habitualmente no «pican» código.

Abajo he listado, a modo de carta a los Reyes Magos, aquellos ingredientes que el buen Product Owner debería tener, y al que ya me hubiera gustado acercarme en todos estos años…

1/ Se centra en solucionar problemas reales para el cliente o usuario y que representan una oportunidad comercial: ¿Por qué necesitan nuestro producto? ¿Cómo lo van a usar? ¿Cuáles son el modelo de negocio que lleva aparejado y las hipótesis que lo sostienen?

2/ Es el “mini-CEO” del producto. Tiene capacidad de toma de decisiones y la “última palabra” sobre todos los aspectos relacionados con este. Esto exige que la organización respete este ámbito de decisiones, algo a lo que el Scrum Master debe contribuir mediante su labor de promoción de Scrum.

3/ Formula la visión del producto y el product roadmap.  El buen Product Owner es capaz de articular una imagen ilusionante pero realista sobre cómo será el producto en el futuro. Para ello, identifica qué funcionalidades y epics son esenciales y en qué orden deben implementarse; a la par, sabe que esa visión y plan de producto deberá ser flexible y adaptarse a las circunstancias, pero siempre manteniendo la visión a largo plazo.

4/ Ordena el Product Backlog sin descanso. Refleja sus decisiones de Producto a través de la ordenación de los elementos del Product Backlog, a medida que obtiene más información sobre el producto y sus clientes o usuarios, y según cambien los requerimientos y el entorno. Utiliza además un único Product Backlog por producto, como “fuente de la verdad”, y que recoge de una forma clara todas las funcionalidades y necesidades atinentes a aquel en un momento determinado.  

5/ Utiliza Scrum como framework base, que complementa y amplifica con múltiples técnicas provenientes de Agile (Kanban, historias de usuario, user story mapping, impact mapping, etc.) y Lean.

6/ Forma tándem con el Scrum Master. Mientras que el Product Owner se preocupar por maximizar el valor del producto y de aquello en lo que trabaja el Equipo de Desarrollo, el Scrum Master vela porque se haga con el proceso adecuado y protegiendo al Equipo Scrum.

7/ Escucha y absorbe feedback como una esponja. Invita a los stakeholders a la Sprint Review, y colabora con ellos en la inspección del Incremento de Producto y revisión del Product Backlog. Tiene en cuenta la opinión de clientes y usuarios, a muchos de los cuales conoce en persona. Conversa con ellos a menudo, participa en entrevistas y utiliza herramientas como Uservoice o NPS para conocer sus impresiones directas. Tiene una curiosidad genuina por entender al cliente y su experiencia con el producto. En especial, valora el feedback negativo, las críticas. También observa cómo los clientes usan el producto, acudiendo a aplicaciones como Hotjar o Usertesting.com.

8/ Trabaja en equipo como pez en el agua y sabe delegar. No programa ni es un mago de Sketch. Sin embargo, habla en el lenguaje de desarrolladores y diseñadores y comprende las limitaciones y complejidades técnicas. Por ejemplo, entiende la importancia de minimizar la deuda técnica y su impacto en el Total Cost of Ownership. Sabe escribir especificaciones de producto en forma de user stories, wireframes o acceptance criteria, pero delega estas tareas cuando es necesario y se apoya en el Equipo de Desarrollo para ello.

9/ Colabora estrechamente con el Equipo de Desarrollo a través de conversaciones útiles, aportando feedback sobre el trabajo en curso, resolviendo sus dudas funcionales y haciendo refinamiento del Product Backlog. Se asegura de que todos entienden la funcionalidad que están creando y por qué, y sabe que las historias de usuario son tan solo recordatorios sobre conversaciones en las que concretar los requerimientos. No pone el énfasis en lo que escribimos ni en tener una documentación completamente exhaustiva, sino en la generación de un entendimiento compartido sobre los elementos del Product Backlog.

10/ Llega a la Sprint Planning con los “deberes” hechos. Ha refinado los elementos del Product Backlog junto con el Equipo de Desarrollo, facilitando que estén “ready” (añadiendo detalles, estimaciones, tests de aceptación, etc.), de manera que en la Planning solo tendremos que resolver dudas o cambios de última hora.

11/ No modifica el Objetivo del Sprint y negocia cambios en su alcance con el Equipo de Desarrollo cuando sea estrictamente necesario, respetando el carácter autoorganizado del Equipo.

12/ Exige al Equipo de Desarrollo que se entregue funcionalidad terminada, de acuerdo con la Definition of Done, y no acepta elementos del Product Backlog que no se hayan testeado adecuadamente o que no cumplan con dicha definición. En este sentido, no utiliza la Sprint Review para aceptar o rechazar el Incremento de Producto, puesto que ha estado trabajando con el Equipo de Desarrollo durante el Sprint; se asegura de que elementos no terminados no son presentados en la Review.

13/ Es un enamorado del producto. Lo usa como el que más, y esto le ayuda a ponerse en la piel del cliente. Desarrolla una especie de conexión emocional con el producto, su visión y sus usuarios, que le permite ser tester y encontrar aspectos a mejorar constantemente.

14/ Es analítico y está obsesionado con la experimentación y las métricas clave. El buen Product Owner escucha a los clientes, pero no se fía y contrasta lo que le dicen con los números. Formula las historias de usuario como hipótesis de producto que han de ser validadas. Diseña A/B tests y emplea dashboards de estadísticas propias, así como herramientas como Google Analytics o MixPanel para medir los resultados. No solo establece métricas claras, sino que interroga la procedencia de los datos y su fiabilidad.

15/ Se guía por métricas de valor (ventas, tasa de uso del producto, ratio de innovación, etc.), no por la velocidad u otras medidas de productividad del Equipo.

16/ Evita la toma de decisiones basada en la PMI (Persona Más Importante). No hace las cosas simplemente porque las diga el CEO, un cliente importante o algún gurú. Busca argumentos numéricos en lugar de amparar sus decisiones en meras impresiones o instintos, y los defenderá ante el CEO, el resto del Consejo de Administración u otros stakeholders cuando haga falta.

17/ Sabe cuándo decir «no» y desecha requerimientos absurdos, que no tienen cabida en el Product Backlog. Se mantiene firme en su visión y rechaza de plano funcionalidades que no encajen con ella. Vela porque el desarrollo del producto sea armónico, no un collage sin sentido. Eso sí, el buen Product Owner es un malabarista y encuentra compromisos donde otros ven obstáculos insalvables.

18/ Tiene un conocimiento profundo sobre la industria en la que opera la empresa, sus tendencias y las principales soluciones de la competencia.

19/ Guarda un equilibrio adecuado entre discovery y delivery. Dedica tiempo y recursos a comprender las necesidades y comportamiento de los clientes, y consigue que las mejores ideas ganen, sin imponer las suyas propias. Al mismo tiempo, evita la parálisis por el análisis: es impaciente y empuja para que los nuevos productos o mejoras estén disponibles para el cliente cuanto antes. Involucra al Equipo de Desarrollo en estas actividades de discovery y es la voz del cliente o usuario para con ellos. En proyectos que utilizan “dual track”, se esfuerza porque no haya dos equipos (diseño y programación), sino uno solo.

20/ Practica lean. Descompone soluciones complejas en MVPs (Minimun Viable Product) sucesivos, que permiten poner en producción partes de funcionalidad en lotes pequeños, incluso antes de la Sprint Review. Hace simple lo difícil. Intenta hacer el máximo número de releases en el menor tiempo posible, obtener datos de uso y seguir iterando.

21/ Es detallista y pringa como el que más. Que sea lean no quiere decir que lance versiones mediocres, sino al contrario. Evita MVPs defectuosos o incompletos y apoya al resto del Equipo a cada paso de la implementación.

22/ Asume los fracasos como propios y aprende de ellos. Entiende que, cuando una determinada funcionalidad tiene éxito, ha sido el resultado de un proceso de desarrollo conjunto por parte del Equipo Scrum, pero que, cuando los resultados no son los esperados, el error ha sido suyo. Lejos de auto flagelarse, sabe que tiene que asumir riesgos y que estas derrotas no son más que nuevos aprendizajes para continuar iterando. Si procede, defiende rectificar la estrategia (pivotar) para trabajar en una dirección diferente, o quitar funcionalidad que ya no sirva, por mucho que haya costado desarrollarla.

23/ Es adorado por los stakeholders, en particular por los responsables de marketing y desarrollo de negocio, pues les ayuda a vender más. Para qué lanzar nuevas características a producción continuamente si las novedades no se comercializan y son olvidadas. El buen Propietario de Producto se preocupa por el blog post, la nota de prensa, el email para los clientes, el manual para el usuario o la diapositiva a incluir en las presentaciones comerciales.

24/ Comunica la visión más bien por exceso. Explica y comparte la visión del producto cada vez que tiene ocasión, aprovechando la Sprint Planning y la Sprint Review. Relaciona la visión con el Objetivo de cada Sprint. Utiliza la Retrospective para cerciorarse sobre la efectividad de esta comunicación.

25/ Disfruta del proceso de creación del producto, se lo pasa bien y contagia a los demás, dentro y fuera del Equipo Scrum.

¿Qué piensas? ¿Cuál ha sido tu experiencia trabajando con producto owners o como product owner?