Product Owner, ¿interno o del cliente?

Suele haber con frecuencia, en los equipos de trabajo del sector IT, un debate abierto sobre la figura del Product Owner. Este debate surge en los momentos en los que el Product Owner no cumple con lo que se espera de él.

En términos de Scrum, el rol de Product Owner tiene unas funciones claramente identificadas y su correcto desempeño es vital para el éxito del Producto.

Sin embargo, cuando el Product Owner proviene del cliente a veces nos resulta muy complicado conseguir que éste cumpla con lo esperado.

¿Qué hacemos en estos casos? ¿Sería mejor que el Product Owner fuera también de nuestra empresa?

Para responder esta pregunta, primero tenemos que conocer las responsabilidades de un Product Owner de acuerdo a Scrum. Además, deberíamos saber qué cualidades hacen de un Product Owner un Gran Product Owner.

De acuerdo con la Guía Scrum, esencialmente, estas son las tres responsabilidades de un Product Owner:

Es responsable de maximizar el Valor entregado

Para ello, es necesario que el Product Owner:

  • Conozca el Negocio.
  • Tenga una Visión del Producto que se quiere construir.
  • Sea capaz de definir los elementos que crean Valor .
  • Sea capaz de priorizar estos elementos de acuerdo a esta sencilla regla: primero (siempre que las dependencias lo permitan) los elementos de máximo Valor al mínimo Coste. La mayoría de Productos que conozco se desarrollan para ganar dinero, cuanto más y antes, mejor.

El Product Owner debe asegurarse que existe un Product Backlog

¿Significa esto que es el Product Owner la persona que debe escribirlos físicamente? La respuesta es “No”.

Si él no lo hace, puede delegar en otras personas para que lo hagan: stakeholders u otros miembros del Dev Team (analistas, UX, etc.) si así se organiza el equipo. Pero el responsable y la persona que responde ante terceros del mismo es el Product Owner.

Por ello, si él no los escribe o no los detalla al nivel requerido, sí debe participar en su definición y descripción, debe guiar a las personas que los escriben, participar en los Refinamientos y velar por que siempre se priorice el máximo Valor al mínimo Coste.

El Product Owner debe liderar el Sprint Planning y el Sprint Review, y participar en el Sprint Retrospective

  • En el Sprint Planning, el Product Owner debe definir el Sprint Goal y los elementos del Product Backlog que permiten alcanzar dicho objetivo. El Product Owner debe ayudar al Dev Team a comprender dichos elementos del Product Backlog, explicándolos con suficiente nivel de detalle y respondiendo las preguntas que formule el Dev Team. El Product Owner también debe estar dispuesto a negociar el alcance del Sprint si este excede la capacidad del equipo para ese Sprint.
  • En el Sprint Review, el Product Owner también debe liderar la reunión y esto es fundamental. Tiene que invitar a los stakeholders clave para explicarles qué elementos del Product Backlog han sido completados y cuáles no. Asimismo, debe comentar el estado del Product Backlog, recoger el feedback obtenido durante la revisión del Incremento, cruzar esta información con el estado actual del mercado, y actualizar el Product Backlog para que este feedback sea valioso de cara al siguiente Sprint Planning.
  • Por último, en la Retrospectiva, el Product Owner debe participar activamente como un miembro más del Scrum Team para inspeccionar las personas y sus relaciones, los procesos y las herramientas de cara a trazar un plan, unas acciones, que mejoren el trabajo del equipo.

Por tanto, comencemos con algo básico y evidente: si un Product Owner no cumple con estas responsabilidades, bien por falta de tiempo, capacidad o compromiso, entonces no puede ser Product Owner. O dicho de otro modo, el cumplimeinto de estas responsabilidades es condición necesaria para poder ser Product Owner.

En caso contrario, existirá una disfunción que, en última instancia, acabará lastrando el desarrollo del Producto y frustrando a todo el equipo.

Estas son las tres responsabilidades básicas para cualquier Product Owner. Pero si lo que queremos es ser un Product Owner de nota, además de lo mencionado, el perfil debe también tener las siguientes habilidades:

  • Conocedor del Negocio.
  • Capacidad de decisión.
  • Disponibilidad.
  • Orientado al Valor.
  • Saber cómo funciona el desarrollo software.
  • Comprometido con el equipo.
  • Buen comunicador.
  • Conseguidor.
  • Capacidad de resolución de conflictos.
  • Deseo por mejorar su entendimiento y aplicación de Scrum.
  • Gestionar expectativas.
  • Confiar en el equipo y en el framework.

Una vez que conocemos las principales responsabilidades de un Product Owner y qué cualidades hacen de él un Gran Product Owner, estamos en condiciones de responder a la pregunta que formulamos al comienzo, ¿Product Owner interno o del Cliente?

En mi opinión, siempre que el Cliente pueda ofrecer un Product Owner y éste se comprometa con las responsabilidades del rol (lo que, además, implica conocimiento del Negocio y dedicación) será mejor opción que un Product Owner interno.

No obstante, si el Product Owner propuesto por el Cliente no se compromete, o no cumple con lo esperado durante el desarrollo del Producto, entonces habría que buscar otra persona para desempeñar el rol, bien otra persona del Cliente o bien interno.

Un Product Owner del Cliente, en la mayoría de casos, tendrá más conocimiento del Negocio, “su” Negocio, y esto es fundamental para maximizar el Valor y saber priorizar.

Además, lo normal es que tenga mayor capacidad de influencia dentro de las distintas áreas o departamentos de “su” organización, lo que es de enorme ayuda para resolver dependencias y agilizar integraciones.

Me atrevería a decir que en Paradigma sabemos resolver cualquier problema técnico y esto nunca supone un bloqueo de un desarrollo, pero ¿qué ocurre con las dependencias cruzadas y las integraciones con otros productos de la organización?

Aquí necesitamos toda la ayuda posible para lograr influenciar y movilizar a las personas adecuadas y un Product Owner del Cliente puede abrirnos las puertas que necesitamos abrir.

Otro aspecto a considerar es la responsabilidad final sobre el Producto desarrollado. Si el Product Owner es del Cliente y el Producto no ofrece el Valor esperado, la responsabilidad es del Product Owner, pues es él quien decide y prioriza los elementos del Product Backlog.

Este no es precisamente un tema menor a la hora de elegir entre un Product Owner interno o del Cliente ya que, sin un profundo conocimiento del Negocio, existe un riesgo mayor.

Entre las ventajas de un Product Owner interno estarían su dedicación, su compromiso con el equipo y su conocimiento de Scrum. Sin duda, un Product Owner interno cumplirá con todas las responsabilidades del rol y facilitará el equilibrio de todo el equipo.

Sin embargo, es más complicado que conozca el Negocio, la organización, los stakeholders, los contactos e incluso que tenga capacidad de decisión, lo que es fundamental.

Es difícil que su opinión sea respetada y acatada dentro de la organización si no forma parte de ella, al menos hasta que se establezca una gran relación de confianza.

Otro punto a considerar es el carácter de la relación que se establece entre el Cliente y la empresa. Si queremos facilitar esta relación, es decir, que sea más integrada, un equipo mixto formado por el Cliente y la compañía facilitará la transparencia y aumentará la cohesión entre ambos.

La transparencia es un pilar básico de Scrum, la apertura del trabajo que hace el equipo genera confianza y esto es básico para evitar futuras fricciones.

Conclusión

Aunque cada caso requiere un estudio particular, siempre que el Cliente cuente con un Product Owner que se comprometa con las responsabilidades del rol (e incluso esté dispuesto a pasar evaluaciones por parte del equipo), pueda dedicar el tiempo necesario y conozca el Negocio, será la opción con mayor probabilidad de éxito.

Además, es el Cliente quien asume la responsabilidad del Valor generado, lo cual tiene pleno sentido puesto que, al fin y al cabo, el Cliente es el promotor del Producto.

Sin embargo, hay casos en los que esto no es posible por diversas razones. Entonces podemos contar con Product Owner internos que, sin duda, aportarán muchas otras ventajas, como la implicación, el compromiso, la total dedicación y el profundo conocimiento de Scrum.

En cualquier caso, habrá que estudiar cada situación para tomar la mejor decisión en un contexto específico ya que, el desarrollo de Productos no es, ni nunca será, una ciencia exacta.

Ingeniero de Telecomunicación, MBA y Master en Marketing Online y Comercio Electrónico. Pedro tiene una misión: lograr que Equipos de Alto Voltaje desarrollen productos digitales asombrosos. Optimista infatigable, le encanta trabajar duro con personas inteligentes. Como Scrum Master, le obsesiona conseguir que equipos felices entreguen el máximo Valor posible. Firme defensor de hábitos saludables, se pregunta por qué, a lo que parece, nadie sabe desayunar como es debido. Lema que le guía: "Talent wins games, but teamwork and intelligence win championships.”, Michael Jordan.

Ver toda la actividad de Pedro Revueltas

3 comentarios

  1. Jose Huerta dice:

    Hola Pedro. Estoy de acuerdo con parte, pero no con todo. Destacaría la frase “Este debate surge en los momentos en los que el Product Owner no cumple con lo que se espera de él.” Hay mucho que aprender de esta frase.
    Entiendo que el caso es exclusivo de una empresa dando servicios de desarrollo a un cliente. Pero también creo que limitar la decisión a si el PO del cliente sabrá o no sabrá hacer su rol es dejarnos aspectos por valorar, que también son importantes. Por ejemplo: ¿El modelo del contrato con el cliente es por esfuerzo dedicado o hay un alcance a cumplir? Aunque seamos ágiles, puede haber un objetivo a cumplir. ¿El equipo está dedicado en exclusiva a ese cliente o hay impactos y relaciones con otros contratos con otros clientes? Por ejemplo, ese equipo podría haber desarrollado otro producto para otro cliente y estar desarrollando el nuevo. Si hay incidencias o un pequeño cambio del antiguo, debería encargarse ese equipo.
    A lo que voy es a que el PO deberá tener en cuenta todo esto para priorizar trabajo de otros clientes en ese equipo. Y tampoco sería sano que el equipo tuviese que lidiar con esos temas con un PO del cliente. Además nuestra empresa podría tener prioridades que no tengan que ver con el cliente, y tener que mover recursos de un equipo a otro, u otras acciones. Todo esto puede decantar por convertir al PO del cliente en el principal interesado, y tener un PO propio.
    Si todos estas contras no están presentes, si el cliente tiene a alguien que pueda hacer correctamente de PO, lo mejor sería un PO del cliente. Pero hay muchos más factores, aparte de que no sepa hacer de PO, que no recomienden eso y que debemos tenerlos en cuenta.

  2. Efectivamente, Jose, hay que ver cada situación. En el caso de Paradigma intentamos que cada equipo trabaje solo en un Producto, con lo que el PO únicamente prioriza el Backlog de ese Producto.

    Por otro lado, al inicio de un proyecto con un Cliente impartimos unas formaciones con los candidatos a PO y Stakeholders para que conozcan el framework y, particularmente, las responsabilidades de cada rol en un Scrum Team, poniendo especial énfasis en las responsabilidades del PO. Además, una vez que comienza el desarrollo, el SM acompaña al PO para ayudarle a asentar los conceptos y resolver las dudas que puedan surgirle.

    Pero es cierto que generalizar conlleva una pérdida de contexto por lo que hay que estudiar cada caso para tomar la mejor decisión.

    Gracias por tu feedback :)

    • Y además de la figura del SM en Paradigma también se dispone de un equipo de Agile Coach que está siempre dispuesto a ayudar a clientes en esa transición o sencillamente a reforzar conceptos que no hayan quedado del todo claros.

      Gracias por el post Pedro!

Escribe un comentario