Somos conscientes de que al hablar del Product Owner (PO) podemos caer en la trampa de contar cosas que ya se han escrito. Por eso, hemos querido contar nuestras experiencias desde la perspectiva de cualquier Scrum Master (SM) con lenguaje cercano, consejos y ejemplos reales y del día a día.

Por poneros en contexto, somos dos SM que hemos tenido varias experiencias en común con POs de proyectos “hermanos” y hemos tenido los típicos cafés donde hemos compartido experiencias y preocupaciones y de donde hemos sacado más de una idea o sinergia.

En base a las vivencias que hemos tenido con diferentes personas desempeñando el rol de PO, vamos a daros nuestra clasificación particular con diferentes observaciones y tips, partiendo de la base de que son muy generales y cada persona requiere una personalización y un contexto.

Antes de empezar con nuestra particular clasificación, nos gustaría hacer una pequeña introducción para explicar algunas de las muchas clasificaciones que se hacen el PO.

Un par de clasificaciones que nos resultan de interés

En este post, Ron Eringa nos ofrece su punto de vista respecto a la evolución del PO en cinco fases:

  • Escriba
    • Previo rol de analista.
    • Generalmente, viene del departamento de TI.
    • Necesita de otros departamentos para resolver dudas de negocio.
    • Delega creando cuellos de botella.
  • Proxy
    • Analista senior con fuertes habilidades de comunicación.
    • Más unido a la parte de negocio que un escriba.
  • Representante de negocio
    • Pertenece al departamento de marketing/ventas/gestión de productos.
    • No se crean tantos cuellos de botella al tener más contexto de negocio.
    • Sus decisiones tienen que pasar previamente por el departamento de gestión de marketing\ventas\producto.
  • Sponsor
    • Tiene plena autoridad para tomar la mayoría de las decisiones, pero las decisiones de alto impacto económico necesita validarlas con otro responsable.
  • Emprendedor
    • Es la última fase de la evolución y es totalmente responsable de la funcionalidad y presupuesto.
Product Owner Levels

También nos encontramos con otra clasificación muy famosa en función de su actitud o talante.

Nuestra clasificación particular

Para realizar esta distinción, hemos tenido en cuenta su afinidad con Agile, el grado de empoderamiento que se le da desde la compañía y su propio background. Para facilitar una aproximación vamos a establecer un paralelismo con los 5 niveles (o fases) de un PO (escriba, proxy, representante de negocio, sponsor y emprendedor) de Ron Eringa resumidos más arriba.

PO amigable

Lo clasificamos de este modo “friendly” porque son POs que han sido cercanos desde el primer momento, mostrándose muy accesibles con todo el equipo y abiertos a la cultura Agile. Han trabajado en un entorno waterfall, pero aceptan consejos y los llevan a la práctica. Nos los encontramos en distintas fases de evolución, pero con un punto en común “Agile mola, enséñame cómo”.

Tips para hacerles evolucionar:

  • Muéstrales herramientas para que ellos “trasteen” (para POs que se inician).
  • Acepta cambios y sugerencias respecto a cómo compartir información con el equipo técnico (para POs que se inician).
  • Hay que acompañarlos y aconsejarlos, sin resultar intrusivos, evitando que tomen una vía que se aleje de la cultura. Estarán abiertos a las opiniones (para POs que se inician).

Cualquier herramienta y consejo lo tendrán en cuenta, lo pondrán en práctica y les ayudará a crecer. Creemos que son un tipo de PO “ideal” que no siempre te encontrarás y que tienen gran potencial si se les ayuda a desarrollarse.

PO dependiente

Muchos conocemos algún caso similar donde se elige a una persona cercana al producto o a negocio, pero sin ningún tipo de experiencia en un puesto similar, le vemos entre fases de Escriba o Proxy. Suelen tener conocimientos de Agile, pero sin experiencia como PO y con poca confianza. Este perfil suele dar mucho más trabajo al SM por tener que realizar reuniones previas con el PO para evitar que su inexperiencia en el rol repercuta al equipo.

Algunas ideas para impulsar su transformación:

  • Acompañamiento o preparación en las reuniones con negocio y stakeholders: sesiones pre y post para ajustar o ver encaje en backlog y roadmap (aplicable a POs con menos experiencia y confianza como es el caso).
  • Sesiones de refinamiento y mantener una bitácora del producto para mejorar su visión global, más allá del roadmap (práctica también especialmente recomendable para POs con poca dedicación como el denominado “figurante”).
  • Reuniones One to One con el PO orientadas a afianzar la confianza y poder evolucionar (práctica común a todos los niveles pero especialmente importante en este caso).

En algunos casos, su evolución hacia PO proxy es temprana, pero nosotros hemos tenido casos donde esa proyección no proseguía y debíamos “asistir” para cubrir esas deficiencias no cubiertas por esta persona.

PO figurante

Este perfil suele tener conocimientos básicos de Agile, pero a veces no conoce bien sus responsabilidades o no tiene el tiempo suficiente para desempeñarlas o su experiencia previa o el entorno en el que se encuentra no ayudan. Este rol de figurante nos lo encontramos entre las fases de Proxy y Business Representative.

Para este tipo, algunas pautas que nos han servido son:

  • Tener un panel de Jira “mascado”, donde vea todas sus historias y su única preocupación será decidir qué refinar y priorizar (aplicable a todos los POs que no tengan tiempo suficiente para gestionar backlog o estén aprendiendo).
  • Hacerle reminder de próximos eventos para su preparación (aplicable a este perfil que tiene dedicación baja).
  • Bitácoras donde se refleje la información de las reuniones con negocio donde no ha asistido (aplicable a este tipo de PO donde es frecuente que no asista a todas las reuniones y le estemos haciendo cobertura al rol).

Con todo esto, tiene las herramientas necesarias para, en un futuro, pueda avanzar en su fase como PO o, al menos, mantener una armonía y seguimiento del día a día que no impacte en la productividad del equipo.

PO dominante

Este tipo de PO se distingue por la necesidad de tener el control por encima de sentirse dentro de un equipo y conocer la cultura Agile, aunque no están especialmente interesados en prodigarse. Desde nuestra experiencia, son los más complejos de tratar y de ayudarles a evolucionar. Puede ser gente muy posicionada en su compañía y con un fuerte carácter (son duros a la hora de negociar y alcanzar acuerdos) que puede radicar en ocultar ese miedo a la pérdida del “control” sobre el proyecto, producto o equipo. Este tipo de PO nos lo encontramos entre las fases de Proxy y Business Representative.

Algunos tips utilizados:

  • Hablar con la persona para saber cómo quiere trabajar en base a la cultura y qué opciones de mejora tiene para ver posibles acuerdos negociados y alcanzar un equilibrio entre su rol y “su visión” (para todos los POs no Agile friendly). Alcanzando acuerdos marco en gestión como proponer fechas y que el equipo de desarrollo se autoorganice para alcanzar dichos hitos.
  • Que comparta su roadmap y visión de negocio para acercarle al resto del equipo (especialmente aplicable a estos perfiles que son muy cerrados y opacos en comunicación).
  • En cuanto a comunicación, evitar hacer islas en el equipo y tratar de que la información se comunique a todos para no torpedear la auto-organización y la gestión del equipo. Conseguir un acuerdo de modo que los objetivos sean alcanzados sin que se inmiscuya haciendo microgestión y monitorización (especialmente aplicable a este tipo).

Como resumen, recomendamos sobre todo trabajar mucho para que no exista un abismo entre el PO y el equipo técnico, aunque a su vez se evite la exposición de forma individual, que bajo nuestra experiencia son los que más “sufren” a este tipo de POs. Tuvimos dos casos, en el primero la situación era bastante compleja para el equipo y dificultaba la auto-organización del mismo. En el segundo caso, la experiencia fue mucho más sostenible y, a pesar de que este tipo de POs siempre lo ponen complicado, el acuerdo de marco de trabajo era satisfactorio para ambas partes, ya que pudimos demostrar que la auto-organización funcionaba.

PO motivante

Es lo más parecido al PO de manual, alcanzando muchas similitudes con el nivel “Emprendedor” ya que busca propuestas y oportunidades para el equipo. En nuestra experiencia era alguien novato desempeñando el rol pero con alto conocimiento de agilismo trabajando en equipos Scrum.

Estrategias para facilitar su crecimiento:

  • Mantenerse en constante evolución y trabajar en nuevos objetivos que desafíen al equipo y al PO para mejorar y poder ser más ambiciosos (esto es algo que aplica a todos como norma general, pero es crítico con este perfil).
  • Asegurarse de que el equipo está alineado e identifica las bondades de tener un PO que les otorga un papel principal, ya que un gran poder conlleva una gran responsabilidad (en este caso es especialmente importante que el equipo aproveche la oportunidad y se potencien las capacidades del equipo).
  • Disponer de unas bases sólidas de comunicación y confianza (aunque esto se aplica a todos, este tipo de PO conlleva unos niveles de exigencia en términos de comunicación y coordinación, donde es fundamental mantener altos niveles de confianza de forma bidireccional).

En nuestro caso, a pesar de que sus predecesores y compañeros tenían un nivel más Escriba o Proxy, este PO se apoyaba más en el equipo y quería implantar herramientas y medidas que potenciasen al equipo tanto técnica como metodológicamente a medida que adquiría más experiencia.

Unos consejos finales

Tras este recorrido por la clasificación personal, nos gustaría recomendar ciertos tips que creemos comunes y necesarios a aplicar en cualquier tipo de PO y que se reflejan (en su mayoría) dentro de Polaris, nuestro framework de gestión de proyectos:

  • Reuniones One to one, que dan pie a crear acercamiento, conocer sus necesidades y generar ese momento de confianza.
  • Sesiones de roadmap y follow up en conjunto para tener la misma visión de futuro sin dejar nada en el tintero.
  • Generar y compartir métricas tanto de negocio como de equipo para visibilizar el trabajo.

Este post es el resultado del ejercicio de síntesis que hemos realizado, donde hemos intentado aportar nuestras ideas para quien le pueda resultar de utilidad y/o curiosidad. Además, queremos matizar que cada persona requiere una personalización y un contexto, siendo indispensable la individualización en cada caso.

Cuéntanos qué te parece.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.