El Product Owner

¿Qué es un Product Owner?

En Scrum, el Product Owner es el encargado de maximizar el valor del producto en el que trabajan los Desarrolladores. Dicho en sentido contrario, es quien intenta minimizar el riesgo de lanzar un Incremento de producto que luego carezca de viabilidad.

Dentro de Scrum, el Product Owner se concibe como un Agile Product Manager. Es decir, el Product Owner asume las responsabilidades que describe la Guía Scrum (maximización del valor y gestión del Product Backlog), pero no se limita exclusivamente a estas: necesitará servirse de técnicas de Agile y de Product Management en general para tener éxito. En este sentido, hay que destacar su trabajo en cuanto a la visión y estrategia de producto, así como las actividades de Product Discovery (Descubrimiento de Producto).

Se dice que el Product Owner o Product Manager se sitúa en la intersección entre experiencia de usuario, tecnología y negocio; lo habitual será que el Product Owner provenga de uno de estos tres campos, y que sepa desempeñarse también, hasta cierto nivel, en los otros dos.

En este artículo, por cierto, reflexionamos sobre las características que hacen al “buen Product Owner”.

 

 

El Product Owner y su papel en los diferentes eventos Scrum

 

▶ Sprint Planning. El Product Owner debe haber preparado este evento (a ser posible realizando labores de refinamiento del Product Backlog con el Equipo, previamente) y traer una propuesta de objetivo de negocio y de los elementos del Product Backlog a incluir en el Sprint. Además, debe poder explicar al Equipo Scrum la relación entre esa propuesta y el Product Goal o Meta de Producto en el que estén trabajando. Ello permitirá que el Equipo cree un Sprint Goal u Objetivo del Sprint durante Sprint Planning.

 

▶ Daily Scrum. El Product Owner no tiene que asistir a la Daily, que es un evento por y para los Desarrolladores. Si lo hace, porque los Desarrolladores así lo quieran, debe ser más bien en calidad de oyente o para resolver dudas.

El Product Owner puede dar feedback o realizar aclaraciones en cualquier momento, no tiene por qué ser durante en la Daily (que, insistimos, es un evento que pertenece a los Desarrolladores).

Si el Product Owner asumiera ciertas tareas de implementación, entonces sí asistiría, en calidad de Desarrollador.

 

▶ Sprint Review. Es, quizás, el evento Scrum de mayor relevancia para el Product Owner, pues representa la oportunidad obtener feedback de los stakeholders y colaborar en qué hacer a continuación. El Product Owner es el anfitrión de la Sprint Review. Hagamos algunas puntualizaciones aquí:

• Será conveniente que el Product Owner recuerde a los asistentes el Product Goal y el Sprint Goal asociados al Sprint.
• Los stakeholders serán, normalmente, invitados por el propio Product Owner.
• No es el momento para aceptar o rechazar el Incremento por parte del Product Owner, que debe haber estado al tanto del progreso del Equipo y del estado del Incremento durante el Sprint.
• Es habitual que el Product Owner comente el Product Backlog en su estado actual, y que proyecte objetivos probables y fechas de entrega, basándose en el progreso hasta la fecha. Por ejemplo, puede que haga uso de un release burn-down chart.

 

▶ Sprint Retrospective. El Product Owner participa como un miembro más del Equipo Scrum. Por ejemplo, puede ser un buen momento para contrastar con el resto la efectividad con la que el Product Goal o la visión de producto se están comunicando.

 

 

Qué hace un Product Owner: las actividades que el Product Owner desempeña durante el Sprint

Entre otras actividades, el Product Owner invertirá buena parte de su tiempo durante el Sprint en las siguientes:

 

▶ Discovery. El product discovery alude a todas aquellas tareas encaminadas a dilucidar si un producto o feature merece ser desarrollado. Un buen Product Owner pasara aquí la mayor parte de su tiempo, en torno al 80%. El discovery es lo que determina el contenido del Product Backlog, puesto que es la única forma de entender al cliente o usuario (mediante entrevistas, análisis de datos, experimentación y un largo etcétera de técnicas). En este enlace puedes ver nuestra guía completa sobre product discovery.

 

▶ Definición de la estrategia de producto. Incluimos aquí temas como la concepción y comunicación de la visión del producto, del Product Goal o del Product Roadmap.

 

▶ Gestión de stakeholders. El Product Owner ha de estar en contacto con aquellas personas o grupos que se vayan a ver afectados por el producto que el Equipo Scrum está creando, a fin de asegurarse que tal producto se alinea con las necesidades de estos stakeholders y del negocio. Los stakeholders pueden ser internos (representantes de otros departamentos, directivos, etc.) o externos (clientes, usuarios, proveedores, etc.).

 

▶ Gestión del Product Backlog. El Product Owner es el responsable del orden y contenido de los elementos del Product Backlog.

Por ejemplo, puede ser que el Product Owner sea quien escriba las diferentes historias de usuario y sus criterios de aceptación, y quien determine su orden, según prioridad. No obstante, el Product Owner puede delegar muchas de estas tareas de gestión del Product Backlog, como la propia redacción de historias de usuario, si bien seguirá siendo el responsable último del Product Backlog.  

Será común que el detalle de los elementos del Product Backlog se vaya desgranando durante las sesiones de refinamiento de producto, que es, en definitiva, un deporte de equipo.

 

▶ Resolución de dudas planteadas por los Desarrolladores. A medida que los Desarrolladores trabajan en el Incremento, con frecuencia surgirán preguntas relativas al producto y su funcionalidad, casos de uso, etc. El Product Owner debe estar disponible para ser parte de la conversación y contribuir a su resolución.

En este post comentamos con más detenimiento las interacciones entre Product Owner y Desarrolladores durante el Sprint.

 

▶ Feedback sobre el Incremento de producto en curso. El Product Owner debe estar al tanto del progreso del Incremento y testearlo durante el Sprint. Incluso, puede ser que la Definición de hecho incluya el “okay” del Product Owner. Como decíamos, aquello que se presente en la Sprint Review no debe sorprender al Product Owner.

De hecho, hay una cosa que he visto hacer a muchos muy buenos Product Owners / Product Managers y de la que nunca se habla: testear. No digo hacer el QA necesariamente, que a veces también. Pero, sí, digo testear el producto, como si fuéramos un usuario cualquiera, para comprobar que la funcionalidad en curso se ajusta a lo esperado. Esto es importante porque:

👉 Representamos a clientes y usuarios y, en el caso de nuevas funcionalidades, siempre hay criterios subjetivos y de usabilidad. Puede que el “OK” del Product Owner sea incluso parte de la Definición de Hecho.

👉 Es casi imposible dar feedback útil al equipo sin ver, tocar, usar el Incremento de producto.

👉 Muchos POs tienen una atención al detalle sobresaliente, y la extraña habilidad de “romper” el producto, encontrando escenarios que fallan.

👉 Es una forma de conocer el producto en profundidad, qué hace y qué no; también de forjar compromisos sobre lo que debemos entregar ahora y lo que puede esperar.

 

▶ Negociaciones sobre la funcionalidad o alcance del Sprint, sin afectar a su Objetivo.

 

 

Gestión del Product Backlog: ¿cómo se establecen prioridades?

A la hora de establecer el orden de los elementos del Product Backlog, el Product Owner tendrá en cuenta una serie de factores, como son:

• Valor de negocio.
• Riesgo.
• Coste o tamaño.
• Dependencias.
• Estrategia del negocio

Dicho esto, el día a día de cualquier PO es un cúmulo de información y circunstancias, y decidimos, a menudo sobre la marcha, con apoyo en tres ejes (simplificando):

▶ 1) Evidencia empírica. Tenemos datos de uso que nos ayudan a entender cómo se está utilizando o no nuestro producto. O datos de experimentos que refutan o validan nuestras asunciones.

▶ 2) Feedback variopinto. Quejas de clientes, feedback de stakeholders, entrevistas de discovery, investigaciones de mercado, etc. Aquí no siempre contamos con datos, sino con una información más o menos subjetiva y/o fiable que nos toca interpretar.

▶ 3) Intuición. Impulso creativo. Visión.

Los tres apartados son importantes. Lo digo porque está de moda querer ser “data-driven”. Y ser “data-driven” está muy bien, pero no debe ser a costa de dejar de escuchar a los usuarios directamente. O de perder toda capacidad de impulso creativo.

 

 

Diferencias entre Product Owner y Scrum Master

El Scrum Master vela por la adopción de Scrum y la efectividad del Equipo Scrum, mientras que el Product Owner se encarga de maximizar el retorno de la inversión asociada al producto. Ni uno ni otro pueden definirse como Project Managers en el sentido tradicional.

En este post tratamos en qué se diferencian Product Owner y Scrum Master.

 

 

Diferencias entre Product Owner y Product Manager

Desde Scrumio, interpretamos que, a efectos de Scrum, Product Owner y Product Manager aluden al mismo conjunto de responsabilidades y actividades. Utilizamos uno y otro de manera indistinta. El Product Owner utiliza Scrum como framework base, pero lo completa y amplifica con otras técnicas procedentes de agile y product management en general.

En este post profundizamos sobre la distinción entre Product Owner y Product Manager.

En determinados frameworks, como SAFE, sí existe una distinción explícita entre ambas figuras. Esto es un anti-patrón que contribuye a generar problemas de entendimiento entre uno y otro, y que suele llevar a equipos centrados en outputs en lugar de en outcomes. El resultado de este diseño suele ser:

▶ Problemas de comunicación entre PM y PO.
▶ Falta de entendimiento por parte del PO del porqué, del problema que estamos intentando resolver (que lo convierte en un «Proxy», como exponemos en el siguiente apartado).
▶ Esa falta de propósito se traslada al equipo, que se limita a lanzar features tan rápido como puede (foco en user stories & story points).

👉 ¿La alternativa? Unificar ambas figuras en una sola. Esto es, un Product Manager en toda su extensión. Que, si usamos Scrum, pues también será el Product Owner.

 

 

¿Qué es un «Proxy» Product Owner?

Proxy Product Owner:

– El roadmap con las soluciones a implementar se lo dan otros (los stakeholders o algún jefe o Product Manager)

– Carece de acceso a clientes y usuarios; no hace product discovery.

– Trabaja, sobre todo, «de puertas para adentro», para el equipo: creando las historias de usuario y priorizando el Product Backlog para los desarrolladores. Se centra en su ejecución en plazo.

 

Product Owner “al completo” (Agile Product Manager):

– Es responsable de la visión y de los objetivos de producto. De la estrategia de producto.

– Invierte la mayor parte de su tiempo en actividades de discovery, en las que colabora estrechamente con stakeholders y el resto del equipo.

– Es responsable de la gestión del Product Backlog, pudiendo delegar en otros tareas de administración de este (como la propia creación de historias de usuario).  

 

 

Certificaciones para Product Owners

La certificación con mayor reconocimiento en la industria es PSPO (Professional Scrum Product Owner, de Scrum.org). Comprende tres niveles: PSPO I (dominio de los fundamentos relacionados con Scrum y la maximización de valor), PSPO II (que presenta situaciones prácticas, por lo que se recomienda experiencia previa para afrontarlo) y PSPO III (dominio teórico-práctico muy profundo).

Si estas preparando el examen, aquí puedes encontrar preguntas test de preparación para PSPO I.

También puedes consultar nuestros próximos cursos en Agile Product Management: PSPO y PSPO-Advanced.

 

 

Errores que he cometido como Product Owner

Resumo a continuación algunos de los errores que he cometido como Product Owner, y con los que he visto tropezar a otros POs.

▶ 1) Decir que sí a muchas pequeñas cosas, “quick wins”, que luego no son tan pequeñas ni tan rápidas. Al final, esto nos distrae y nos hace invertir tiempo en optimizaciones de escaso valor. Nos impide enfocarnos en las cosas grandes que de verdad pueden marcar la diferencia.

▶ 2) Creerme que yo soy el cliente o usuario del producto. Esto nos lleva a asumir más de la cuenta, a ser “vagos” y a no hacer el trabajo de discovery con el rigor necesario.

▶ 3) No ponerme en el papel del stakeholder. En especial, cuando he tenido que llevar “malas noticias” (por ejemplo, un feature que no se va a hacer, que se va a retrasar, u otro que le va a afectar de manera potencialmente negativa). Para comunicar de forma efectiva en situaciones complicadas hay que saber ponerse en el lugar del otro. Tener mucha mano izquierda. Los POs debemos tener esa psicología.

▶ 4) Dejarme llevar por el último requerimiento “urgente” del stakeholder o cliente de turno. No hay que precipitarse. En el 90% de los casos, lo que parece urgente no lo es tanto. No dejes que otros te marquen el paso. No menosprecies tu Sprint Goal ni tu Product Goal.

▶ 5) No delegar lo suficiente, en el equipo o stakeholders. El trabajo de Product Owner es muy intenso. Abarcarlo todo es imposible. Hay que saber delegar tareas e involucrar a los demás en el product discovery. Sin miedo, somos un equipo. Lo contrario es quemarnos, o bloquear a los demás.

 

 

«Mitos y leyendas» sobre el Product Owner

En esta sección comentamos y desmontamos algunas de las ideas erróneas sobre el Product Owner.

❌ El PO es quien debe escribir todas las historias de usuario. El PO es el responsable de gestionar el Product Backlog, pero puede delegar la redacción de sus elementos; el refinamiento del Product Backlog es, como hemos dicho, un deporte de equipo.

❌ El PO es un comité o grupo de personas. El PO es uno solo. Uno. Lo contrario es diluir la responsabilidad, ralentizar la toma de decisiones y confundir al Equipo.

❌ El PO y el Product Manager son siempre personas distintas. El buen PO es un Agile Product Manager. “Product Owner” es una accountability en Scrum, no un job title.

❌ El PO tiene que tener perfil técnico. El saber no ocupa lugar, pero el PO es el responsable de maximizar el valor del producto para clientes y stakeholders; los Desarrolladores son quienes tienen los conocimientos técnicos.

❌ El PO es el único responsable de hacer product discovery. El Equipo en su conjunto es responsable de hacer el trabajo de discovery, que suele requerir del “product trio” (PO + diseño + ingeniería) y de una estrecha colaboración dentro del Equipo.

❌ El PO tiene que procurar que todos los stakeholders estén contentos. Intentar contentar a todos es no satisfacer a ninguno. Decirles que sí a todo y a todos es receta para el desastre.

❌ El PO es el único que debe hablar con los stakeholders, que no deben interactuar directamente con los Desarrolladores. El contacto directo con los stakeholders puede ser muy beneficioso para el Equipo, que así adquiere un mejor contexto de negocio. Lo que no vale es menoscabar la autoridad del PO e ir pidiendo “favores” por la espalda.

❌ El PO es un Project Manager vanagloriado. El PO maximiza el valor para el cliente y para el negocio; el éxito del producto no se mide por la entrega de un alcance en plazo y presupuesto.

❌ El PO no debe ir a la Retrospectiva del Sprint. Claro que sí, el PO es un miembro más del Equipo.

❌ El PO es obligatorio en la Daily. La Daily es por y para los Desarrolladores, el PO es opcional.

 

< Volver a Scrum