Product Ownership es un rol. Product Management es el trabajo.
Nos adentramos en los orígenes del término Product Owner para descubrir en qué punto la industria de desarrollo de software confundió el rol con el trabajo de un Product Manager.
La semana pasada publicaba Los Product Managers NO escriben historias de usuario. El artículo comentaba como, en mi opinión, crear historias de usuario es un detalle de implementación que recae del lado del equipo. En equipos de producto sénior, generalmente será el Engineering Manager quién liderará la ejecución, y eso lo puede hacer escribiendo historias o bien utilizando cualquier otro método que permita al equipo cumplir con la entrega.
Argumentaba también que, pese a que esta me parece la situación ideal, la realidad es que muchas empresas asocian el rol de creación de historias de usuario a los Product Managers. Mi hipótesis es que sucede porque en países con poca cultura de producto, confundimos la posición de Product Manager con el rol de Product Owner.
Hoy me gustaría ahondar en los orígenes del término Product Owner para tratar de entender cómo hemos llegado a esta situación.
Orígenes del término Product Owner
En 1986, Hirotaka Takeuchi y Ikujiro Nonaka publican en HBR “The new new product development game”. En el artículo, los autores analizan un conjunto de empresas de la época que destacan por desarrollar productos de éxito aplicando modelos distintos al tradicional en cascada.
Frente al modelo clásico donde un producto se desarrolla secuencialmente por distintos departamentos (análisis > diseño > desarrollo > testeo), el nuevo modelo se basa en equipos multidisciplinares trabajando juntos desde el primer día en pos de un objetivo común. Takeuchi y Nonaka hacen la analogía con un equipo de rugby, dónde los jugadores avanzan como una unidad a lo largo del terreno de juego. Estirando la analogía, llegan a utilizar la palabra “Scrum” (melé) en uno de los encabezados: “Moving the Scrum Downfield”.
Unos años más tarde, a principios de los 90, Jeff Sutherland y Ken Schwaber, ambos ingenieros de software, colaboran para crear un nuevo modelo de desarrollo de software inspirado en los principios descritos por Takeuchi y Nonaka. Nace así Scrum.
Es dentro de este nuevo framework planteado por Sutherland y Schwaber dónde aparece por primera vez el término Product Owner. Un Product Owner en Scrum es uno de los tres roles sobre los que pivota el mismo. Sus responsabilidades de acuerdo a la guía oficial son:
Maximizar el valor del producto resultante del trabajo del equipo
Gestionar efectivamente el backlog
Definiendo y comunicando explícitamente el objetivo del producto
Creando y comunicando los elementos que componen el backlog
Ordenando los elementos dentro del backlog
Asegurándose de que el backlog es transparente, visible y entendible.
Es interesante que la guía no menciona en ningún punto el término historias de usuario (user stories), sino el término genérico elementos del backlog (backlog items). Tampoco encontramos en la guía referencias a términos clave en el desarrollo de producto como son “Strategy”, “Vision” o “Discovery”.
Desde mi punto de vista, esta ambigüedad, probablemente intencionada, es una de las causas principales de que la industria haya entendido mal el rol de Product Owner.
El Product Owner es un rol que deben ejercer personas de negocio
Según las propias palabras de Sutherland en su libro Scrum: The Art of Doing Twice the Work in Half the Time:
“When I created the Product Owner role, I gave it more responsibility for product strategy and revenue generation than a Product Manager. I specifically pulled the best Product Manager Easel Corporation had out of Product Marketing and retrained him. It also has more responsibility for directly working with engineering 50% of the time to assure that the product fits customer needs. So it is a broader role in that sense but usually does not include Product Marketing (sales collateral, shows) or long term Competitive Analysis although it needs to support those efforts.
The goal was to eliminate the common Product Manager failing of throwing requirements over the wall only to have the customer receive something that they didn’t want.” — Jeff Sutherland
Es clave entender este punto. Sutherland y Schwaber, cansados de ver fracasar desarrollos por la falta de entendimiento entre negocio y desarrollo, crean el concepto de Product Owner con el objetivo de entrenar a Product Managers para trabajar con equipos de ingeniería.
Así, el Product Owner nace como un rol a ejercer dentro de las funciones de un Product Manager. Los creadores de Scrum asumían que la persona a ejercer el rol ya traía los conocimientos de negocio aprendidos de casa.
La industria ha copado el rol de Product Owners con técnicos
Ahora bien, en mi experiencia afirmaría que la industria no ha captado este matiz. Lo que generalmente he encontrado a lo largo de mi carrera son empresas promocionando a técnicos a puestos de Product Owners. El perfil típico es el de un ingeniero que destaca en aspectos organizativos y gestión de personas.
De nuevo, creo que la falta de cultura de producto es clave. En realidad, las empresas que actuan así no están buscando una persona que defina el producto, la estrategia o la visión. Lo que buscan es una persona que gestione la entrega del equipo de desarrollo. Se asume que esa persona va a recoger los requisitos de otra parte de la organización.
Un gran indicio que me hace pensar así es que las grandes consultoras han abrazado con fuerza el rol del Product Owner. Por definición, una consultora necesita personas que recojan, organicen y trasladen al equipo de ingeniería los requisitos del cliente. El mal entendido rol de Product Owner, adornado además con un velo de “agilidad”, les viene como anillo al dedo.
El peligro del Product Owner a tiempo completo
Otra de los problemas derivados de haber entendido mal el rol, siempre desde mi punto de vista, es que el Product Owner se ha convertido en un trabajo a tiempo completo cuando en realidad se concibió como un rol a desarrollar dentro de las funciones de un Product Manager.
Que sea un rol dentro de tus funciones habituales implica que no vas a dedicarle el 100% de tu tiempo. Sin embargo, al promocionar a técnicos como Product Owners sin cederles efectivamente la parte estratégica, hemos creado un entorno donde estos han tenido que rellenar los huecos de tiempo restantes ocupando el espacio de otros miembros del equipo.
El ejemplo más claro es el de la creación de historias de usuario. Originalmente, las historias de usuario debían ser lo más breves y abiertas posible. Su objetivo era abrir una conversación entre el equipo de ingeniería y el usuario. De esta forma, los desarrolladores podían entender el contexto e idear la mejor solución posible.
Sin embargo, con la introducción de la figura del Product Owner desprendido de la parte estratégica, y al que explícitamente le has asignado la responsabilidad de gestionar el backlog, lo que ha ocurrido es que los Product Owners han terminado aislando a ingeniería del cliente final.
Es el Product Owner el que se relaciona con los usuarios, recoge sus requisitos, y los traslada a historias de usuario tan detalladas que no deja lugar a la imaginación. Ingeniería se convierte así en una mera cadena de montaje que simplemente procesa historia de usuario tras historia de usuario sin aportar más valor que su capacidad de implementación.
Este escenario, que bien puede ser ideal para una gran consultora que vende horas de trabajo al peso, es terrible para una empresa de producto por las dinámicas que genera.
La posición del Product Owner en una empresa producto
Personalmente opino que la posición de Product Owner dentro de una empresa de producto no tiene cabida salvo en muy contadas excepciones. Mi argumento principal para pensar así es que añade un filtro más entre el equipo y el usuario final.
Imaginemos una situación hipotética en una empresa con un Product Manager y un Product Owner. La persona ejerciendo las funciones de Product Manager define la estrategia y la visión del producto estando en contacto con los usuarios y el mercado. Este, le pasa los requisitos al Product Owner, quién los transforma en historias de usuario que llegan a los desarrolladores sin haber tenido la posibilidad de tener una conversación sobre ellas con la persona que los ha planteado.
Además, la propia existencia del Product Owner, hace más difícil que el Product Manager pueda involucrar directamente al equipo. Como Product Manager, generalmente siempre queremos implicar al Engineering Manager y al Product Designer lo antes posible en la ideación de una iniciativa. Cuando hay un Product Owner dedicado a tiempo completo, esa persona tiende a ocupar el espacio de los dos anteriores.
Desde mi punto de vista, la solución en empresas de producto pasa por eliminar la figura del Product Owner. Sus funciones de gestión de la entrega pasan a ser gestionadas por el Product Manager y el Engineering Manager o Product Designer.
Sólo hay un caso en el que puedo entender que, existiendo un Product Manager, pueda ser necesario el trabajo de un Product Owner a tiempo completo. Se da cuando el negocio es especialmente complejo y abunda en requisitos indirectos. Por ejemplo, en sectores como el financiero o salud, pueden haber muchos pequeños aspectos regulatorios a tener en cuenta que pueden requerir de una persona dedicada a describirlos y asegurarse de que se cumplen.
Otra situación dónde sí puede tener cabida un Product Owner, se da cuando este está ejerciendo efectivamente las funciones de Product Manager.
Esta es la situación ideal a la que aspiraban Sutherland y Schwaber. Una empresa que ha enseñado a una persona de negocio a ejercer el rol de Product Owner. Lo normal sería que la posición fuera la de un Product Manager, pero por falta de cultura o desconocimiento quizás su título es Product Owner.
Dentro de lo malo, es lo mejor que podría pasar. Hay una persona con conocimientos del negocio que ha sido entrenada para interactuar con el equipo de ingeniería. Este es el espíritu original de Scrum y cómo se llame el cargo importa poco, aunque mi recomendación sería que se retitulara a Product Manager. La condición indispensable es que esa persona pase la mayor parte de su tiempo (70%) definiendo estrategia, visión y producto, y no gestionando el día a día del equipo de desarrollo.
Conclusiones
A modo de resumen, destacaría:
El Product Owner nace en los 90 como un rol dentro de Scrum.
La idea original era entrenar a personas de negocio en el desarrollo de productos de software. Sin embargo, la industria ha terminado copando las posiciones de Product Owners con técnicos.
La falta de conocimiento del negocio ha sido suplida retirándoles la parte estratégica. Se asume que los requisitos les vendrán dados desde fuera.
Los Product Owners tienden así a centrarse en la parte de ejecución, absorbiendo funciones que podrían ser desarrolladas por otros miembros del equipo.
Si bien para las consultoras puede ser un buen modelo, en una empresa de producto es contraproducente porque se añade un intermediario más entre el usuario final y el equipo.
Críticas al artículo
No es cierto que los Product Owners se centren sólo en la ejecución
Puede ser. He escrito el artículo desde mi experiencia personal de más de 20 años de carrera. Estoy seguro que hay empresas donde se respeta el espíritu original de Scrum, y el rol es ejercido por una persona de negocio que ha sido entrenada para interactuar con el equipo de ingeniería. Personalmente, no he encontrado muchas de ellas.
El curso de Product Owner te enseña la parte estratégica
El curso oficial de Product Owner de Scrum.org, Professional Scrum Product OwnerTM (PSPO) dura dos días. Gran parte del mismo se dedica a la gestión del backlog y los rituales de Scrum.
Permitidme que os diga que no se puede aprender mucho de negocio y/o estrategia en dos días. Se necesitan años de experiencia para aprender todas las habilidades imprescindibles para poder identificar una necesidad en el mercado, validarla y definir una estrategia.
Un camino muy popular de llegar a tener esos conocimientos por parte de un ingeniero suele ser hacer un MBA, que viene a suponer una inversión de un año y medio de media. Otro camino muy popular es emprender y crear algo desde cero.
📝 Referencias
Entrada sobre el Product Manager en la Wikipedia, donde se cita explícitamente que se puede confundir con el rol de Product Owner.
Product Manager vs Product Owner (Roman Pichler)
Product Manager vs Product Owner revisited (Marty Cagan)
📖Contenidos recomendados de la semana
🙌 ¡Comparte!
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes utilizar estos enlaces para compartirlo directamente en Twitter o LinkedIn y así me ayudarás a que esta lista llegue a más gente. Muchísimas gracias de antemano, Simón.