Definición

El Product Owner es uno de los 3 roles del marco de trabajo Scrum, cada rol en Scrum tiene su objetivo. El objetivo del Product Owner es maximizar el valor del producto entregado por el equipo, es quien debe lograr que entreguemos el producto «correcto», el producto que quiere el mercado y stakeholders. Para ello contará con grandes responsabilidades como por ejemplo el ordenamiento del Product Backlog.

Responsabilidades del Product Owner

Co-creación de la visión del producto

La visión es lo que nos define hacia donde va nuestro producto. Básicamente en una visión tienen que quedar en claro: quienes son nuestros clientes, qué problema les vamos a resolver y beneficios clave del producto.

La co-creación de la visión es una actividad colaborativa en la cual participan stakeholders e integrantes de los equipos. La visión no es algo fijo que se define al principio del proyecto, sino que es algo que se co-crea durante toda la vida del producto, la visión puede cambiar pero es importante que esta este clara en todo momento para el Product Owner.

Gestión del Product Backlog

El Product Owner es el responsable de que el Product Backlog sea:

  • Visible y transparente: debe ser visible para stakeholders y equipo.
  • Expresado claramente: sus ítems Product Backlog Items (PBIs) deben estar especificados de manera clara y estar lo suficientemente detallados para ser entendidos por el equipo.
  • Ordenado:debe estar ordenado de manera que maximice el valor del producto creado por el equipo.

 

El Product Owner ordena el Product Backlog

Una de las principales y más importantes responsabilidades del Product Owner es la priorización del Product Backlog. A la hora de priorizar consideraremos la conocida «Regla de Pareto», buscaremos encontrar el 20% de características del producto que aporten el 80% del valor, lo cual no es una tarea fácil.

Cuando hablamos de valor de producto es importante considerar que ese valor no sólo es el valor de mercado que le aporta a nuestros usuarios, sino también el valor de aprendizaje (cuanto podemos aprender de nuestro contexto y reducir riesgos con esos PBIs) y el valor de desarrollo de competencias (qué competencias podemos desarrollar con esos PBIs).

Existen diferentes técnicas de priorización que puede aplicar un Product Owner, desde las más simples cómo «Burbujeo» (donde se prioriza por comparación de cada PBI contra el resto), hasta un análisis completo de flujos de caja NPV (Net Present Value). La estrategia a utilizar puede tener mayor o menor complejidad, puede ser más o menos precisa, la decisión sobre cuál utilizar dependerá del contexto y criterio del Product Owner.

Es importante considerar que la única persona que tiene la última palabra en el ordenamiento del Product Backlog es el Product Owner. No puede aparecer otra persona que fuerce al equipo en trabajar en algo diferente a lo prioririzado por el Product Owner.

El Product Owner maneja las expectativas de los stakeholders

El Product Owner pasa gran parte de su tiempo con los stakeholders (interesados), teniendo conversaciones sobre el producto, su visión, características y funcionalidades. La comunicación efectiva es una competencia clave en un Product Owner ya que tiene que poder comunicarse efectivamente con múltiples stakeholders y el equipo.

Por otro lado el Product Owner no es el único que debe comunicarse con los stakeholders, eso es algo que sucede frecuentemente y se le llama: «El Product Owner Proxy», quien es un intermediario de la comunicación del equipo con stakeholders. El Product Owner debe ser un facilitador de esas conversaciones, de manera que exista comunicación directa y efectiva entre las partes.

 Release Plan y estrategia de producto

El Product Owner tiene un plan de entregas en el cual refleja la visión del producto a lo largo del tiempo. Un Relese Plan contiene entre otras cosas:

  • La visión del producto descompuesta en objetivos, funcionalidades y épicas.
  • Un Release Burndown Chart que muestre de qué manera avanzamos hacia la entrega del release.
  • Un Roadmap que muestre la cronología de entrega de funcionalidades y épicas a futuro, tiene el objetivo de facilitar conversaciones con stakeholders.

El Release Plan no es fijo sino que cambia de manera contínua y se adapta a los cambios de contexto.

Experimentación & MVP

Cuando trabajamos en contextos complejos y particularmente en el inicio de un nuevo producto, el valor que más buscamos generar es el aprendizaje de nuestros clientes a la par que reducimos riesgos. En busca de maximizar ese aprendizaje validado, el Product Owner prioriza la construcción de ciertas funcionalidades o experimentos que nos permitan aprender lo más que podamos en el menor tiempo posible. Para lograrlo se crea un producto mínimo viable (MVP) del cual recibamos feedback y validemos las hipótesis más importantes de nuestro producto.