El Product Owner

Índice

¿Qué es un Product Owner?

El Product Owner es el miembro del equipo Scrum responsable de maximizar el valor del producto entregado por el equipo.

El objetivo del Product Owner es 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 y roles del Product Owner

El Product Owner es un rol de gran responsabilidad, lo cual involucra diversos roles y tareas fundamentales para ser efectivo.

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

La visión es lo que nos define hacia donde va nuestro producto. El Product Owner es responsable de co-crear 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.

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. Cuando hablamos de priorizar, hablamos de ordenar los items del Product Backlog de manera de maximizar la entrega de valor del equipo.

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 es importante considerar 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, 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 ya que tiene que poder comunicarse efectivamente con múltiples stakeholders y el equipo.

Por otro lado 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 (producto mínimo viable)

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 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.

Conclusiones

El rol del Product Owner es clave dentro de un equipo Scrum, sin un Product Owner efectivo podríamos quizás estar construyendo un producto de calidad y siendo muy eficientes en su construcción pero haciendo un producto que nadie quiere, que no aporta valor real. En la actulidad el rol es cada vez más requerido en las organizaciones siendo una de las posiciones más buscadas en Linkedin al igual que el Scrum Master.

 

8 Comentarios

  1. Martin

    Muy orientativo el resumen. Gracias!

    Responder
    • Ever

      Muy concreta la descripción de esta tendencia

      Responder
  2. Sebastián

    Muy bien explicado Octi

    Responder
    • Octavio Levy

      Gracias Seba! 😉

      Responder
    • Jazmin

      Gracias

      Responder
  3. Micaela

    Súper claro, me encantó!

    Responder
  4. Beatriz Cardona

    Super interesante el tema, me gusto mucho

    Responder
    • Marcelo Garcia

      Muchísimas gracias Beatriz!

      Responder

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Más sobre Reglas de Scrum | Scrum