Por supuesto que podríamos remontarnos hasta 1986 cuando Hirotaka Takeuchi y Ikujiro Nonaka publicaron The new new product development game, un paper con fuerte impronta de producto considerado como un hito fundacional que dio origen al desarrollo con Scrum.
Pero como este estudio minucioso en producto es por demás conocido, no nos adentremos en él. De todos modos, destaquemos que la esencia de sus ideas sigue vigente en la actualidad a pesar de la velocidad con la que cambian las cosas.
Para alguien que tiene a cargo sacar adelante un producto, es común que en el camino deba atender muchos. A veces parece que tuviera que poner dentro de su descripción de skills que también posee capacidades de adivinación, y esa no es la idea.
En realidad, si se llevan adelante las prácticas adecuadas que ofrece el Agile Product Management, podemos sufrir menos sobresaltos. Veamos algunas de ellas y cómo marcan la diferencia.
¿Qué es la Gestión Ágil de Productos o Agile Product Management?
Comencemos por definir brevemente qué es la disciplina del Product Management ágil. En primer lugar, el Product Management es el conjunto de prácticas que nos permite conocer y entender las problemáticas por las que atraviesa el usuario y a diseñar la mejor estrategia y tácticas para entregar el producto más valioso posible por ser el que mejor responde a sus necesidades, dentro de los alcances del negocio.
El atributo de la agilidad para la gestión de productos nos viene a ofrecer la flexibilidad necesaria para responder constantemente a los cambios que ocurren durante la creación del producto.
Es importante tener en cuenta que el Agile Product Management no es aplicable para el desarrollo de cualquier tipo de producto. Sin embargo, se puede encontrar muchos beneficios cuando hablamos de productos de base tecnológica o impulsados por la tecnología (powered by technology).
Cuáles son los beneficios de salir de la mentalidad de delivery
Veamos ahora algunas de las claves más relevantes a la hora de tener éxito con la gestión ágil de productos. Si superamos el mindset que nos hace enfocarnos exclusivamente en la entrega, ya estaremos dando un paso vital hacia una experiencia de desarrollo mucho más innovadora y cercana al cliente. De hecho, observo cada vez más cómo en muchas empresas ya fue superado.
El mindset de delivery aparece cuando, entre otras cuestiones, los equipos se caracterizan por producir entregables sin poner atención al valor que le aportan a los usuarios (lo veremos más adelante) y, en muchas ocasiones, con una organización de trabajo en silos.
Un ejemplo habitual de este esquema de trabajo ocurre cuando el accionar del Scrum Product Owner se reduce a gestionar el backlog, incluso llegando a carecer de autonomía para priorizar las Historias de Usuario (PBIs de Scrum). En cambio, al salir de este modelo de trabajo, vemos que las responsabilidades de un Scrum Product Owner incluyen, entre otras, la definición de la estrategia de producto y la coordinación del Discovery.
Cuando el equipo deja atrás la mirada exclusiva en los entregables y sus criterios de aceptación y pasa a comprometerse con los resultados de lo que está creando y no únicamente con hacer "lo que le fue solicitado" se abren nuevas oportunidades de creación y satisfacción.
Otra forma de verlo es en la clase de conversaciones que ocurren en las sprint reviews. Cuando salimos de la atención primordial en el delivery, notamos que no sólo se evalúa si el incremento cumple con las especificaciones de las historias de usuario, sino que también se consideran múltiples factores de éxito del producto.
Certified Scrum Product Owner (CSPO)
Qué es el Product Discovery y por qué es estratégico
When we empower product teams, we are giving them problems to solve, and we are giving them the context required to make good decisions.
Marty Cagan (EMPOWERED: Ordinary People, Extraordinary Products)
Product Discovery o Descubrimiento de Producto son las actividades de exploración que se realizan para identificar cuál es la solución que mejor resuelve los problemas de nuestros usuarios, especialmente cuando se trata de contextos complejos e impredecibles como aquellos que involucran el comportamiento humano. Un típico ejemplo donde se practica el Descubrimiento de Producto es en la creación de soluciones digitales.
Para hacer Product Discovery, es fundamental partir de la base de que todas las decisiones de diseño de un producto tienen altas probabilidades de derivar de supuestos erróneos y que seguirlos puede resultar en un desperdicio de tiempo y otros recursos. Aunque al principio nos pueda llegar a causar una sensación de contrariedad, las actividades de Descubrimiento de Producto son aliadas que vienen a mostrarnos que es necesario validar las creencias que tenemos acerca de las necesidades de los usuarios para evitar ofrecer soluciones infructuosas a través de nuestros productos.
¿Para qué más sirve el Product Discovery? Sus beneficios son muy amplios y podemos resumirlos en que nos ayuda principalmente a mitigar cuatro tipos de riesgo: los de usabilidad para el cliente, viabilidad del negocio, factibilidad técnica y el valor que le encontrará el usuario en comparación con otras propuestas.
En todo esto se lleva muy bien con la agilidad porque también nos enseña que en contextos complejos no equivocamos si creemos que podemos conocer anticipadamente lo que necesitamos construir. Pero cuidado que hacer Product Discovery no es garantía de agilidad.
Equipos tradicionales y equipos de producto
Vinculado con el Descubrimiento de Producto, veamos otro criterio fundamental del equipo de producto y por qué es tan importante esta comparación con respecto a los equipos de desarrollo tradicionales a la hora de tener éxito con nuestros objetivos de negocio.
El equipo de producto es aquel que desempeña actividades de Delivery y de Discovery al mismo tiempo. Se conoce como dual-track ágil o agile dual-track a la combinación entre actividades de desarrollo y descubrimiento que ocurren en simultáneo dentro del mismo equipo. Un equipo con estas prácticas se encuentra en un nivel que demuestra estar más atento a los outcomes, es decir que no solo se preocupa por que lo que construya sea de calidad técnica y basados en el cronograma (los outputs), sino que también se pregunta por el sentido de lo que está creando y el resultado que obtienen los usuarios y la empresa (los outcomes). Busca activamente los medios posibles para acercarse a los mejores resultados y hace pruebas para verificarlos.
El hecho de que diferenciemos entre outcome y output es muy importante porque es lo que marcará el horizonte del valor de negocio que está aportando el equipo. Una particularidad de los outcomes es que se basan en supuestos que el equipo debe validar mediante la exploración.
Una tendencia creciente es la de hacer validación de supuestos directamente en producción mediante lo que se conoce como técnicas de production data tests para censar el comportamiento de una feature en particular. Un feature de tránsito, feature intermedia o transit feature puede ser algo tan sencillo como un google form, un switch o un pop-up que se utiliza durante un cierto tiempo para verificar que los usuarios lo utilicen
Otro aspecto fundamental de la diferencia entre un equipo tradicional y un equipo de producto es que el primero mide su rendimiento únicamente en función de generar los incrementos del producto. El propósito de un equipo de producto no es entregar features sino generar resultados, cambios en el comportamiento de los usuarios del producto, etc. No es suficiente con entregar historias de usuario. Más allá de la Sprint Review (de que el feature cumple con lo esperado, con la calidad esperada y cumpliendo el Definition of Done) es necesario dar el paso de corroborar que el incremento entregado generó un impacto real en producción.
Esta mirada abre la puerta a la experimentación. Por ejemplo, los A/B testing o pruebas A/B nos permiten comparar dos features por medio de la segmentación del público con el fin de censar su interés en cada uno de ellos.
Por supuesto que para que esto suceda tienen que darse las condiciones organizacionales que les permitan a los equipos animarse a explorar y aprender de estos ejercicios.
Cómo llevar adelante la relación con el cliente
Desde el punto de vista del negocio, un ambiente de desconfianza que promueve la idea del “nosotros contra ellos” con los clientes es muy nocivo pero frecuente dentro de la cultura del trabajo. Este tipo de contexto, algunas veces más evidente que otras, deriva en falta de transparencia para esquivar conflictos, un Scrum Product Owner que es excluido del equipo por representar los intereses del cliente, un sentido de propósito ausente de lo que se está construyendo, e incluso falta de motivación, la cual se limita a entregar estrictamente lo que fue pedido, sin un interés por indagar en las necesidades reales.
Esta predisposición a la larga nos termina jugando en contra, entre otras cosas, porque genera más re-trabajo, los productos no terminan teniendo el impacto deseado y los clientes no regresan si tuvieron una experiencia negativa. Para los que prefieren escapar de este tipo de comportamientos y moverse dentro de un paradigma orientado al producto, pensar el tipo de vínculo que mantienen con el cliente juega un papel central. Tan solo una de las ventajas que trae fomentar una relación de colaboración estrecha es la cercanía para comprender mejor las problemáticas reales del cliente dentro de nuestro alcance de negocio para poder sorprenderlo con lo que tenemos para ofrecer.
¿Cuál es el trabajo del Scrum Product Owner?
Los Scrum Product Owners vienen creciendo en tendencia desde hace algunos años como consecuencia de la explosión de los productos digitales o productos con base tecnológica. Es un trabajo apasionante para quienes se interesan por la estrategia de producto, y es donde el Agile Product Management como disciplina juega un papel central.
La Guía de Scrum nos dice que la función del Scrum Product Owner es ser el responsable de maximizar el valor del producto y gestionar eficientemente el Product Backlog, velando así por que los incrementos que entrega el Equipo Scrum sean del mayor valor posible en cada Sprint.
Con respecto a la gestión del Product Backlog, el Scrum Product Owner tiene cuatro grandes responsabilidades: hacer que el Product Backlog sea conocido por todos, hacer que todos entiendan lo mismo del Product Backlog, determinar el orden en el que se hace el trabajo, y establecer los objetivos del producto.
A la hora de maximizar el valor del producto, en un artículo llamado "Retos que enfrenta el Product Owner más allá del Product Backlog", podrás conocer cuatro grandes desafíos que enfrenta este rol en la actualidad.
Hay que tener en cuenta que el Scrum Product Owner es el único responsable de tomar decisiones acerca del producto (no es un trabajo colectivo). La falta de cumplimiento de esta premisa trae problemas de alteración del Product Backlog que repercute en el diseño del producto.
Por otra parte, tengamos presente que la imagen típica de un Scrum Product Owner es la de alguien que se ocupa de clientes externos de la organización, pero cada vez es más frecuente hallar dentro de las mismas organizaciones las posibilidades de carrera como Scrum Product Owner interno. Considerando las 3 similitudes y 3 diferencias entre Product Owner Interno y Product Owner Externo, la distinción fundamental entre el Scrum Product Owner interno y el externo es que el cliente del Product Owner interno trabaja dentro de su misma organización. Pero tengamos presente que la naturaleza de la función de ambos roles no cambia.
¿Cuáles son las similitudes y diferencias entre el Product Owner y el Product Manager?
Otro punto clave en una práctica fluida de Product Management ágil es comprender claramente la diferencia entre disciplina y rol.
Por supuesto que, como todo en la vida, no hay absolutos. Además, los equipos evolucionan a diferentes velocidades y no todos hacen las cosas de la misma manera, ni escogen el mismo camino hacia la mejora continua.
Es importante también tener en cuenta que, en función de la envergadura y la estructura que las empresas tienen, pueden llamar a estos roles de diferente manera con expectativas distintas.
El rol del Product Manager surgió en la década del 30. Las primeras evidencias provienen de Procter & Gamble y luego se popularizó con Hewlett Packard. Si bien fue un rol menor durante gran parte de esa historia, a principios de 1980, con el advenimiento de muchas start-ups en Silicon Valley, comenzó a popularizarse y unos 17 años más tarde de la mano de Scrum apareció lo que se conoce como Scrum Product Owner.
Antes de Scrum, el Product Manager era el responsable de maximizar el valor del producto y resolver los problemas de los usuarios o los clientes.
Se dice que el cambio de nombre tiene que ver con reforzar el énfasis que tiene el Scrum Product Owner con respecto a adueñarse del producto. Es decir que no hay nadie que tome decisiones por él/ella, no hay nadie que cambie las cosas del lugar si no es él/ella, no hay nadie que defina una estrategia si no es él/ella. Así como en su momento cambiaron el rol de Team lead o Project Manager a Scrum Master en su momento para diferenciar, lo mismo sucedió con el Product Manager al convertir el nombre a Scrum Product Owner.
De hecho, la guía de Scrum en 2010 menciona anecdóticamente el rol del Product Manager y dice que si el producto se desarrolla hacia afuera el Scrum Product Owner puede ser el Product Manager y si el producto se desarrolla hacia adentro (si es un producto interno) el Product Owner puede ser el gerente de línea del área cliente de ese producto.
Sin embargo, unos años más tarde surgieron los frameworks de escalado y se identificó, por ejemplo, en el mundo de SAFe (Scaled Agile Framework) dos roles distintos para cumplir estas responsabilidades: el SAFe Product Manager se encarga de construir un producto que resuelva las necesidades y los problemas de los usuarios y el SAFe Product Owner es el miembro del equipo ágil responsable de definir las historias y priorizar el Product Backlog.
Si nos metemos un poco en la esencia de estas actividades vamos a ver que estamos hablando de Product Discovery y Product Delivery. Entonces si bien en Scrum el Scrum Product Owner se encarga de Discovery y Delivery, en SAFe esto no ocurre necesariamente, sino que el SAFe Product Owner se encarga sólo del Delivery y hay un SAFe Product Manager que se encarga de la parte de Discovery y estrategia.
Por fuera del mundo de la agilidad muchos han tomado a SAFe como referencia por ser el framework adoptado más habitual y nos encontramos entonces con la definición de que el Product Manager es el estratega, el que hace el Product Discovery, y el SAFe Product Owner es el táctico de Product Delivery. Cuando desde afuera del mundo de la agilidad o del mundo Scrum se toma como referencia a SAFe para definir estos roles estamos incurriendo en un error.
El error consiste principalmente en entender las responsabilidades de un Product Manager fuera de la agilidad. Dentro de Product Management hablamos de la visión de producto, de estrategia de productos, hacer roadmaps, comunicar, priorizar, poner objetivos, tener insights tanto de datos como de usuarios y validar hipótesis. También es parte de la definición de la expectativa de un buen Product Manager poder construir productos que sean éticos pero que generen este “sticky” y esta necesidad de seguir usándolo, cumpliendo con las normas. El Product Manager tiene que ver también con cuestiones de marketing, lanzamiento de productos y marketing de productos.
El Scrum Product Owner en la definición de maximizar el valor también tiene todas estas mismas responsabilidades. Además se suman algunas propias de estar haciendo Scrum tales como ordenar el Product Backlog, hacer slicing y transparentar el Product Backlog.
En otras palabras, Product Management es la disciplina y es parte integral del rol del Scrum Product Owner. Product Owner a su vez es el rol específico de estar haciendo Scrum. Si no estuviéramos haciendo Scrum seríamos Product Managers.
Esperamos que estos puntos claves de la práctica de Agile Product Management te hayan aportado información útil en tu visión de producto.