La imparable adopción de filosofías Agile en el desarrollo de productos viene suscitando una cierta polémica sobre el papel del Product Owner y su intersección (en algunos casos, colisión) con el del Product Manager.

En este post introductorio no pretendo hacer una descripción detallada de la función del Product Owner (no soy un experto y podéis encontrar miles de mejores referencias), sino centrarme en algunas de sus peculiaridades en empresas orientadas a producto y en la evolución que está experimentando para adaptarse a estos entornos.

Pero antes de empezar tal vez convenga recordar un par de características de Agile que influyen en este tema (y que hemos tratado anteriormente aquí y aquí). Aunque originalmente las metodologías Agile provienen del campo de los proyectos a medida de un cliente, es en los últimos años cuando se han incorporado al desarrollo de productos repetibles para un mercado. Sin embargo, por su propia naturaleza, Agile se aplica principalmente a las actividades de construcción / implementación del producto, es decir, entra en juego cuando se ha analizado la oportunidad de mercado y se ha decidido que se va a construir “algo” (la “unidad 0” de un producto replicable).

Product Owner y gestión de proyectos

El rol o función de Product Owner proviene de Scrum, una metodología Agile de gestión de proyectos en la que el equipo colabora unido e integrando continuamente el feedback del cliente a través de un proceso iterativo dividido en sprints.

En sus orígenes, el Product Owner de Scrum era un rol táctico, orientado al proyecto e integrado en el equipo técnico que lo ejecuta. Su misión era representar al “negocio” en el proyecto y asegurar que las decisiones de implementación estaban alineadas con las necesidades del cliente y que cualquier problema o duda se resolvía lo antes posible. Para ello actúa como interfaz entre el cliente y el equipo técnico, recabando el feedback del primero al final de cada sprint y adaptándose a los cambios en sus necesidades.

El Product Owner está en contacto permanente con equipo de proyecto (jefe y desarrolladores) gestionando el backlog de la release, elaborando y priorizando historias de usuario, expandiendo especificaciones y tomando decisiones inmediatas sobre funcionalidad y prioridades. Originalmente, en escenarios de proyectos a medida, era incluso habitual que el propio Product Owner fuera un miembro de la organización cliente. En estas circunstancias el Product Owner era literalmente el dueño del “producto” (entendido éste como el resultado del proyecto).

Product Owner y construcción de productos

La gestión de productos replicables para un mercado difiere de la gestión de un proyecto para un cliente en muchos aspectos fundamentales. Empezando por el hecho de que en el escenario de producto repetible no hay un cliente predefinido, sino una mezcla de clientes más o menos heterogéneos y desconocidos (y que en el mejor de los casos podremos segmentar y representar mediante uno o varios arquetipos significativos de clientes). Por eso uno de los primeros pasos en el desarrollo de un producto es acotar el espacio de problemas de mercado y definir el problema a resolver.

Como consecuencia, resulta prácticamente imposible que el Product Owner sea una persona proveniente de la (o, mejor, una) organización cliente: tiene que tratarse de un miembro de la empresa desarrolladora, encargado de representar al mercado en las actividades de construcción del producto. Unas actividades que se enmarcan en un ciclo de vida de producto mucho más amplio y que abarca desde el análisis de la oportunidad de mercado hasta la comercialización del producto.

Aplicado al desarrollo de productos para un mercado, el rol del Product Owner es muy exigente: antes de planificar los sprints, debe escribir historias de usuario y colaborar con el equipo de testing para definir los criterios de aceptación. Durante la planificación de los sprints debe explicar al equipo de implementación las historias sobre las que van a trabajar a lo largo de las siguientes semanas. Durante el sprint (típicamente 1-4 semanas) supervisa el avance, toma decisiones sobre alternativas de implementación,  responde a preguntas, valida las historias terminadas y prepara las historias para el siguiente sprint.

Del Product Owner se espera que esté disponible para el equipo cuando aparecen dudas y que mantenga actualizado el backlog del producto, reorientando las prioridades en función del feedback de los clientes y otros afectados, unas responsabilidades que exigen una presencia casi continua en la war room. El del Product Owner es un trabajo a jornada completa.

Por poner este rol en el contexto de empresas de producto, podemos compararlo con las funciones típicas del Product Manager. En este post Rich Mironov toma el Framework de Pragmatic Marketing al que nos hemos referido otras veces y superpone las actividades del Product Owner.

Así obtenemos una perspectiva de las funciones del Product Owner y de su intersección con las actividades globales de Product Management: ocupan un área a caballo entre la zona estratégica y la táctica y muy centrada en el hemisferio más “técnico” del plano. De hecho, el alcance del rol de Product Owner guarda un gran paralelismo con el del clásico Technical Product Manager, si bien algunas de las actividades que desempeñan, la cadencia con que las realizan (y, desde luego, el nombre que les dan ;- ) son muy diferentes.

Y en este contexto el nombre de Product Owner es menos afortunado: en general sigue estando más enfocado en el proyecto de construcción que en el resto de la vida del producto y la propiedad que ejerce no abarca mucho más que el backlog y las historias.

El Product Owner ideal… y el real

En aquellas empresas que aplicaron un Agile “de manual” al desarrollo de productos (lo que en muchos casos significa la exclusión de la figura del Product Manager) pronto se descubrió que el alcance original del Product Owner era insuficiente para asegurar el éxito del producto en el mercado. Como consecuencia, los defensores de Agile han ido reclamando para el Product Owner la responsabilidad sobre un rango más amplio de funciones que van desde la visión y el roadmap de producto hasta la asignación de recursos.

Se ha pretendido evolucionar hacia un Product Owner ideal (una especie de “Súper Product Owner”) más estratégico y centrado en el negocio, aunque ello ha llevado a una cierta explosión de sus atribuciones… y a una tendencia sospechosa a solaparse con el papel tradicional del Product Manager. En general, esta definición del papel del Product Owner responde a una concepción de la gestión de producto desde la óptica del departamento de Tecnología, que inevitablemente resulta incompleta (y, en ocasiones, sesgada).

Además, en la realidad el puesto de Product Owner es habitualmente cubierto con personal del departamento de Tecnología/Ingeniería con escasos conocimientos del mercado (clientes, competidores) y de otras áreas y funciones de la empresa. Y eso limita su capacidad para realizar eficazmente las tareas de interacción externa e interna necesarias para garantizar el éxito del producto.

Algunos autores y consultores que promueven este nuevo papel del Product Owner llegan a sostener que hasta ahora no había en las empresas una única persona responsable de cada producto y que el Product Owner viene a suplir esa carencia (y si queréis saber cómo, no tenéis más que leer su libro o cursar uno de sus seminarios ;- ). Pero como ya sabemos, la realidad es que en cualquier empresa de producto razonablemente gestionada ya existe esa figura de “CEO del producto” y que atiende al nombre de Product Manager.

Por eso hace unos años se suscitó la polémica de si las empresas de producto comercial necesitaban únicamente Product Managers o Product Owners (o los dos) y si ambas funciones podían ser desempeñadas por la misma persona, aspectos estos que iremos cubriendo en próximas entradas.

El post “Agile y el papel del Product Owner en empresas de producto” se publicó primero en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]