Labores que un Product Owner podría hacer que no aparecen en la Scrum Guide

¿Qué leches es un Product Owner? Si nos vamos a la definición formal, siempre leemos que es “el encargado de maximizar el valor”, sin embargo, en muchas organizaciones es “una persona de negocio porque tiene que saber del negocio”. Nadie dice que no sea así, pero esto está generando un problema limitante en las organizaciones que no tienen esta figura entre sus filas.

Cuando recibí el curso de Professional Scrum Product Owner nos enseñaron que un Product Owner debe evolucionar desde lo que identificamos con un analista hasta un emprendedor o mini-CEO dentro de la organización. Un Product Owner es mucho más que la persona que sabe del negocio.

Un ejemplo que a mi me gusta mucho es el Ministro de Sanidad. El Ministro de Sanidad es Ministro, no es médico y no tiene porqué venir de la medicina. Nuestra relación con los hospitales es muy diferente según la zona donde vivamos. Si un médico ocupa ese cargo, tendrá una visión parcial de una posición así. Por encima de poner al mejor médico, es mejor seleccionar a una persona que sea capaz de tomar decisiones, que se rodee de médicos para la toma de decisiones y que sepa liderar. ¡Eso es la clave de un Product Owner!

Un buen Product Owner toma decisiones para gestionar su producto

Para tomar decisiones puede hacerlo de varias maneras, la primera la que hacemos todos, en base a su experiencia y a cómo debería funcionar el software, es el modelo Analista. Cuando eres analista lo que acaba pasando es que entramos en el mundo proyecto cerrado y entrega en fecha donde lo único importante es que el software haga lo que tiene que hacer. Scrum no está pensado para esto, no es su misión, y las empresas que trabajan así acaban tirando mucho software.

Sin embargo, cuando trabajamos en el modelo “Producto” (por eso se llama Product Owner) el rol cambia. La toma de decisiones (y en consecuencia de la priorización) se tiene que basar en datos de mercado y feedback de los afectados por el producto que construímos (que son los usuarios y mucho más).

Vamos a analizar labores que todo Product Owner podría hacer y que por lo general no hace:

Definir a tu usuario

Una de las carencias que más afectan al software es no tener claro la persona que lo utilizará. Es vital que sepamos a las personas que afectan, hay varios talleres que se pueden hacer al respecto de esto, desde personas, el User Role Modelling, o el Scope Canvas.

Una vez definido nuestro usuario deberíamos hablar con ellos. Si estamos desarrollando un producto que sustituye a otro existente pues hablemos con los actuales, nos ayudará a conocer sus sensaciones, sus problemas y sus dificultades. Después, no se trata de hacer lo que nos dicen que quieren, se trata de descubrir lo que de verdad necesitan.

En un equipo con el que colaboré, el cliente pedía un buscador para acceder a la información. Con el tiempo el equipo descubrió que realmente el buscador no era esencial, lo que realmente quería el cliente era acceder rápido a cierta información y para eso se diseñaron unas pantallas que mejoraban con creces la experiencia de usuario. El buscador se despriorizó y no se llegó a hacer. 

Taller para definir el producto

El Product Owner tiene que definir qué lo que se hace es lo que se necesita. Pero es difícil tener todas las respuestas. Hay muchas técnicas que nos ayudan a “definir el alcance”, desde Inception, o un taller de Historias de Usuario. La recomendación es que, hacer este tipo de dinámicas cada cierto tiempo o cuando se prevea un desarrollo grande.

Es importante en este tipo de dinámicas invitar al Development Team y a los usuarios finales. De esta manera  tomamos conciencia compartida y sabemos que estamos ayudando a personas a vivir mejor, como diría Jeff Patton: “¡Estamos cambiando el mundo!”.

Es vital que el Product Owner no se tome estas dinámicas como la definición total del producto, sino como una manera de saber por dónde empezar. El descubrimiento es una labor continua basada en refinamiento y constante contacto con el usuario final. 

Definir las métricas de tu producto

Un Product Owner debe olvidar las métricas tradicionales de proyecto. En vez de eso, tenemos que definir métricas de producto. Por un lado, ¿Qué métricas nos dicen si seremos exitosos y aportamos valor? Por ejemplo, número de usuarios o ingresos. Algunas son más complejas como por ejemplo “tiempo que el usuario invierte en cierta tarea” cuando lo que necesitemos sea eficientar el trabajo del usuario.

Después habrá que definir otro tipo de métricas que sean esencial: felicidad de los desarrolladores, tiempo de reuniones, time-to-market etc. Son métricas que nos aportan mucha información del estado de nuestro producto aunque no sean directas de éxito.

Otra recomendación esencial es añadir medidores al producto actual si la idea es sustituirlo por otro. Tenemos que conocer qué tal funciona el producto actual de cara a saber si el nuevo producto realmente mejora y la inversión tenía sentido.

Visitar a los usuarios finales y resto de personas afectadas por lo que construímos

Siempre se dice que un buen Product Owner pasa el 50% de su tiempo con el Development Team y un 50% con los usuarios/stakeholders. Esta segunda parte se nos olvida muchas veces. No la atendemos porque hacemos Scrum para proyectos y dejamos para el final conocer la opinión de los usuarios. Scrum nos proporciona mecanismos para inspeccionar lo que opinan los usuarios y adaptarnos gracias a la Sprint Review. 

Por ejemplo, en una entidad bancaria nos contaban que cuando iban a sacar una nueva versión de la App, montaban un stand en una sucursal y el propio Product Owner mostraba la nueva versión a las personas que entraban en la oficina.

Hay muchas maneras de conocer a tu usuario y de trabajar con él, hoy en día hay un gran sentimiento de que no nos tienen en cuenta cuando somos usuarios, esto puede ser un punto diferenciador para triunfar en nuestro producto.

Tener una estrategia de producto

Otra de las labores que ayudan mucho a los Product Owner es tener una herramienta para mirar hacia el futuro. Hay varias que podemos usar: User Story Mapping, Plan de Releases, Impact Mapping, o RoadMap de Producto. Al final, este tipo de herramientas nos proporcionan una visión de futuro de producto y eso nos permite gestionar expectativas, dependencias y riesgos.

Hay que tener cuidado con este tipo de herramientas porque, mal usadas, pueden ocultar un Diagrama de Gantt con un alcance y una fecha cerrado. No se trata de eso se trata de hacernos una idea de lo que queremos conseguir y aprender a medida que ganamos experiencia.

Por ejemplo, imagina que nuestro producto en teoría va a contener 30 features. Decidimos inicialmente distribuirlas en 5 Sprints con 6 features cada una. Una vez finalizado el primer Sprint vemos que solo hemos sido capaces de completar 2, pues actualizamos nuestra herramienta para tener en cuenta la nueva información con la que contamos.

Medir y gestionar la deuda técnica

Otra labor que muchos Product Owners pasan por alto es la deuda técnica. Por un lado hay que ser capaz de medirla, por ejemplo SonarQube nos da información, o bien por ejemplo crear un elemento del Product Backlog por cada deuda que tengamos. Esto nos permitiría medir el % de elementos que son deuda técnica o el número de elementos que resolvemos por Sprint, además de visualizarla.

Muchos Product Owner no entienden bien la deuda técnica porque no vienen del mundo del desarrollo. Para ello, es importante la comunicación con el Development Team y tratar de exponer la deuda técnica en términos del impacto en negocio, por ejemplo, el time-to-market o el coste en llamadas del call center.

La deuda técnica es vital en productos de largo recorrido porque el coste de mantenimiento se dispara. En este artículo vemos que para proyectos quizás no sea tan importante.  

Ser un líder sirviente (que da servicio)

Por último, en el libro Scrum Product Ownership proponía el autor Robert Galen que un buen Product Owner debía ser líder sirviente (y no solo el Scrum Master). En muchas organizaciones el Product Owner tiene la capacidad de desbloquear muchos impedimentos del Development Team. Cualquier impedimentos relacionado con el producto realmente es suyo y el resto del Scrum Team le podrá ayudar.

El hecho de que desde el Development Team lo vean como un líder sirviente genera más confianza. Ser muy transparente con tu equipo, incluso si hay menos dinero y hay que reducir el equipo lo ideal es transmitirlo lo antes posible, esto hará que el Development Team vea al Product Owner como una persona que no engaña, que cuenta con ellos y se rige por sus mismos valores y principios.

Estas labores ocurren poco entre los Product Owner, pero si te fijas, tienen mucho más sentido del que parece. Surgen varias dudas ahora que sabemos más labores de un Product Owner: ¿Debe de ser de negocio?¿Debe tener conocimiento técnico?