×
×

Product Owner y Product Manager: ¿son iguales o diferentes?

 

 ¿De qué va este artículo?

El rol de Product Owner de Scrum se inspira en el Product Manager tradicional. Pero, ¿son lo mismo? ¿puede una persona desempeñar ambos roles? ¿dónde tiene sentido mantener ambos roles y dónde integrarlos? En la comunidad ágil hay un cierto desconocimiento del rol tradicional de Product Manager 

En este artículo damos algunas pistas para responder estas preguntas, así:

  • Comentamos problemas habituales de Product Owners y Product Managers.
  • Explicamos las responsabilidades del Product Manager y vemos cuales de ellas podría realizar el Product Owner.
  • Revisamos que hace un Product Owner fuera del Sprint.
  • Finalmente, presentamos un camino para ayudar a Product Owners a asumir más responsabilidades de Product Management.

Here we go!

 

 Problema #1: el Proxy PO

Los Product Owners tienen muchos desafíos, algunos vienen de no entender el rol y otros del diseño organizativo en el que éste se desempeña.

En las organizaciones "tradicionales", el departamento de IT ofrece "servicios internos" al resto de la organización. Entre estos está la gestión de los proyectos, que frecuentemente se subcontratan total o parcialmente. Cuando se trata de organizar equipos Scrum, un caso típico es que los jefes de proyecto se conviertan en Product Owners. Esto pasa porque siguen planificando y controlando la entrega de una solución "al negocio" usando otra "metodología". En este caso, aunque se les llame Product Owners, son "proxy" product owners o intermediarios con el negocio con baja efectividad para maximizar el valor porque:

  • No definen la visión.
  • No controlan el presupuesto ni el alcance.
  • Acaban yendo constántemente a negocio para validar sus decisiones.

 

P11_proxy.png

De organización funcional a equipos ágiles: la aparición del "proxy" Product Owner.

 

 Problema #2: el PO desbordado en startups que crecen

En otro caso, como startups que crecen y se convierten en scaleups, el Product Owner cada vez tiene más equipos de desarrolladores y suele colapsar. Es habitual comenzar a incorporar figuras que le den soporte, con perfiles de márketing, ventas o financieros. En este caso un riesgo común es que el Product Owner pierda efectividad porque:

  • Se satura con actividades poco estratégicas como los requisitos o las pruebas.
  • Tiene que mantener la interlocución y coordinación con "su equipo de producto" y a la vez con el "equipo de desarrollo".
  • Cuando un producto crece, las responsabilidades que se exigen al liderazgo son mayores. La gestión del producto se vuelve mucho más compleja.

 

 Problema #3: el Product Manager que comienza a utilizar Scrum

Otros problemas frecuentes son los que pueden tener los Product Managers que comienzan a trabajar con Scrum. Estos pueden ser:

  • Inestabilidad inicial de la transición organizativa hacia la agilidad, en forma de carencias de diseño organizativo, falta de experiencia de los roles en agilidad, etc.
  • La curva de aprendizaje para trabajar de una manera diferente, a nivel organizativo y de gestión de los proyectos.
  • Disfunciones en el rol, como perder poder en algunos aspectos o tener nuevas responsabilidades (p.e. asistir a reuniones del Sprint) cuando ya tenían la agenda saturada.

 

 ¿Qué hace un Product Manager? ¿Es lo mismo que un Product Owner?

Las comunidades de Emprendedores y de Product Managers (llamadas a veces Producto) y de Agile no tienen demasiada visibilidad entre ellas, aunque en las empresas acaben colaborando frecuentemente. Con la perspectiva de Agile, no suele comprenderse bien lo que hace un Product Manager, especialmente en organizaciones grandes. En este mapa de actividades de Pragmatic Marketing, se listan actividades que van desde la concepción de un producto (estratégicas) hasta el soporte y evolución (tácticas). La lista es tan amplia que incluso sugieren que su realización la lideren tres roles:

  • Director o estrategia de producto, que se ocupa de decidir qué producto construir y como debe ser este producto.
  • Product Manager técnico, que se ocupa de los aspectos técnicos y funcionales del desarrollo.
  • Manager del márketing del producto, que se ocupa del éxito en la comercialización del producto.

 

Aunque parezca de perogrullo, el rol de Product Manager solo tiene sentido cuando la empresa considera el software como un producto que hay que gestionar, y eso pasa fundamentalmente en entornos "B2B", o sea cuando el producto se vende en el mercado. Si revisamos de nuevo las actividades de este modelo vemos que:

  • La mayoría solo tienen sentido para productos comerciales: p.e. evaluación del mercado o estrategia de precios.
  • Pero algunas otras deberían realizarse igualmente si la organización trata también el software interno como un producto, opción muy minoritaria actualmente: p.e. métricas operativas, requisitos y hoja de ruta de producto, o gestión del soporte.

 

P57_PM_triad.png

Mapa de actividades de Product Management, de Pragmatic Research.

 

A diferencia de un Product Manager, que en ocasiones puede estar situado en un departamento de márketing o producto y tener relativo poco contacto con los equipos técnicos, un Product Owner siempre debería estar cercano al Equipo:

 

 ¿Qué hace un Product Owner dentro y fuera del Sprint?

El Product Owner define la visión del producto, y respecto a la elaboración de la estrategia:

  • En organizaciones pequeñas, frecuentemente startups con un único producto, colabora con el equipo en la definición de la estrategia de negocio y técnica.
  • En organizaciones grandes, lo más habitual es que la estrategia de negocio la elabore conjuntamente con roles externos al equipo, como márketing, ventas y el liderazgo. La estrategia técnica en estos casos suele ser definida por el equipo en colaboración con roles técnicos como CTO, Arquitectura, UX, etc.

Considerando la gran carga de trabajo que suele tener un Product Owner en ambos casos, si quiere realizar el rol de manera influyente, debe delegar la mayoría de tareas no estratégicas a nivel de negocio, pero también a nivel funcional. Esto implica que debería delegar al equipo actividades como la definición de requisitos y de pruebas. Si el Product Owner tiene tiempo de dedicarse a estas actividades, es probable que haya un Product Owner de negocio (Product Manager) y su función sea la de Proxy Product Owner.

En Scrum.org, los cursos:

 

P57_ProdManagement_Scrum.jpg

 

 El PO en el descubrimiento y entrega de producto

Otra pespectiva para entender a un Product Owner este modelo de responsabilidades de Charles Bradley, compañero PST en Scrum.org:

  • Descubrimiento de producto (Building the "Right Thing"): como definir la visión, estrategia y necesidades del producto. Estas actividades se realizan habitualmente fuera del Sprint y puede hacerlas tanto con roles fuera y dentro del Equipo de Desarrollo.
  • Entrega de producto (Building the thing "Right"): como planificar, realizar y entregar un producto satisfactorio. Estas actividades las hará fundamentalmente con el Equipo de desarrollo durante el Sprint.

Este enfoque está más basado en la innovación que en la gestión organizativa y financiera del producto, que es el foco habitual del Product Manager.

 

P57_ProductDiscoveryDelivery.jpg

 

 El viaje de un PO hacia las versiones más efectivas del rol

Finalmente, ¿cómo podemos ayudar a los Product Owners a ser más estratégicos, asumiendo más responsabilidades de Product Management y delegar al equipo de desarrollo las actividades más tácticas?

Este modelo de Gunther Verheyen muestra una evolución en el empoderamiento del Product Owner para conseguir su misión de maximizar el valor del producto.

  • En primer nivel, como analista, se dedica a definir funcionalidades y pruebas de aceptación. Personalmente pienso que todavía no cumple los mínimos del rol, pues no gestiona el backlog controlando y priorizando sus contenidos.
  • En segundo nivel, como Proxy, gestiona el backlog parcialmente: no tiene capacidad de decidir qué cosas entran y qué cosas se destacan. Además, el hecho que éstas decisiones suelan estar "en el negocio" o "en el cliente" hace que caiga mucho su capacidad de planificar efectivamente los sprints y releases debido a los cambios incontrolables. En este artículo revisamos como aumentar la autonomía de este nivel de PO.
  • En tercer nivel, como Business Representative, algún responsable de negocio puede entender mejor las necesidades del producto, a la vez que delega más al equipo por tener menos conocimiento técnico. Ambas cosas suelen ser positivas, pero existe el riesgo que las decisiones de este Product Owner no sean suficientemente respetadas por otras áreas del negocio, o que no sean aceptadas por la dirección.
  • En cuarto nivel, un Sponsor, representante de la dirección y con responsabilidad máxima respecto a la inversión en el producto y sus resultados, tiene un nivel suficiente para la toma de decisiones efectiva y para maximizar el valor que se obtiene del producto. El riesgo principal de este rol es que no tenga suficiente foco en el producto por responsabilidad sobre otras iniciativas.
  • En quinto nivel, el Emprendedor, tiene el producto como misión única y responsabilidad máxima sobre éste. Es el CEO de una startup o el mini-CEO en una organización mayor donde está empoderado para disponer de todos los recursos y decisiones al margen de la "organización madre". Es el nivel ideal, y el más difícil de alcanzar.

 

P57_gunther.png

 

 Bonus track: video de Dave West (CEO y PO en Scrum.org)

En este video, Dave West explica en solo 17 minutos muchos de los puntos de los que hemos hablado en este artículo. ¿Te lo vas a perder?