Más que Product Ownership, LEAN Product Ownership

El problema con el rol tradicional del Product Owner

Uno de los roles prescritos por el **Marco de Trabajo SCRUM **es el Propietario del Producto (Product Owner). Éste se encarga de gestionar una lista de funcionalidades a implementar (llamada backlog), de tal forma que se vaya maximizando el valor del producto en desarrollo. Y el resto de los roles deben respetar estas decisiones del Product Owner.

El enfoque clásico habla siempre de funcionalidades a construir sobre un software, pero este tiene un problema, que veremos en el siguiente video.

En el caso presentado en el video, la mamá tuvo un diseño y un backlog del producto que tenía que implementar: los brazos, el cuerpo, la cabeza, los ojos, los dientes de castor… ¡Y le quedó hermoso!

Pero, a pesar de eso, ¡el producto no funcionó!

¿Por qué?

Porque ella tenía la hipótesis que el Disfráz de Castor era lo que se necesitaba, pero no, se necesitaba un Disfraz de Pastor.

Esto suele pasar una y otra vez en el mundo del desarrollo de productos. Gestionamos el trabajo apartir de una solución hipotética para tener éxito, pero se suele pasar por alto una etapa clave, identificar correctamente el problema a resolver. ¿Dónde se encuentra ahora el sistema que queremos mejorar? ¿Hacia dónde queremos transformarlo? En definitiva ¿Cuál es la brecha que queremos superar?

Esto genera un problema grave: los equipos que están desarrollando la tecnología pierden de vista cuál es el problema a resolver…El “¿Para qué estoy haciendo esto?”.

Para abordar este problema, proponemos la disciplina del Lean Product Ownership, que concibe al un Product Owner como un rol que diagnostica un problema de negocios sin amarrarse a priori a una solución. Por ejemplo: “Hemos perdido un 20% de la cartera de clientes de x segmento desde el año 2020 y necesitamos recuperarlo. La causa raíz de eso, se debe a que hemos cambiado a los representantes de venta asignados y los clientes no se han adaptado al cambio. ¿La solución? Tenemos que co-crearla”.

¿La filosofía detrás de esto? El Ciclo de Resolución de Problemas (inspirado en el famoso Ciclo de Deming Plan-Do-Check-Act).

Para entenderlo mejor, pensemos en la lógica en la que un doctor que atiende a su paciente:

La primera fase consiste en entender muy bien el problema y sus causas. (En nuestro modelo, el Lean Product Owner es el que hace esta indagación, y por cierto, lo hace en equipo).

Entonces, logra entender cuál es el problema y qué lo está generando, es decir, lo diagnostica.

Luego, va a trabajar con el equipo de desarrollo y crea un Experimento de Mejora: “Este es un posible tratamiento para la enfermedad que diagnosticamos”.

La etapa que viene después es el Desarrollo Ágil: Implementaremos el experimento de a poco. Probamos la solución con el paciente para ver si funciona o no funciona.

Luego de comprobar que funciona es cuando vamos a implementarlo como una solución a nivel de toda la organización. Un tratamiento sostenido y organizado en espera de mejoras comprobables.

Allí si implementamos Scrum, pero lo importante aquí es que hay un gran paso previo, que es el CORRECTO diagnóstico del problema sin pensar en la solución.

Aquí les dejamos una tabla resumen que pueden pausar para leerla. Lo principal en realidad es que el objetivo del Product Owner tradicional es optimizar el valor del producto, pero no explica cómo. En cambio, en el Lean Product Ownership, el objetivo es optimizar los resultados de un flujo de negocios mediante productos experimentales. El foco no es el producto.

Lo más interesante de este modelo es que no solo sirve para mejorar procesos existentes sino que tiene gran potencial para desarrollar nuevos productos o líneas de negocios.

Un caso real

Pensemos en una fábrica de Software.

Teníamos que atender a clientes y a usuarios, pero teníamos a la gerencia de operaciones con muchos dolores porque había más de 100 tickets de reportes de problemas distintos. Entonces, se decidió generar una célula que encontrara la solución a los problemas. Esta célula de mejora tenía su sala especial, super vanguardista, de alto presupuesto…no se podían quejar, eran privilegiados.

Dos años después, llevaban USD2 M gastados y no habían conseguido generar un impacto visible en el negocio.

Lo que pasaba es que se saltearon la parte de analizar el problema, entonces decían: tengo 100 problemas, vamos a resolverlo uno por uno.

¿Pero qué sucede si el Doctor se salta el diagnóstico y va directo al tratamiento?… No quisiera que ese sea mi doctor honestamente.

Entonces, nosotros fuimos invitados a intervenir y analizamos los tickets con un modelo analítico del proceso y descubrimos que los tickets de reportes eran realmente fallas que estaban históricamente mal de raíz, y fue documentados por gente que luego se fue, entonces se habían reportado… pero no se había hecho nada más.

Lo segundo fue esquematizar los tickets y llegar a las causas de raíz. Luego de investigar, descubrimos que había solamente 3 subprocesos responsables por todos los errores generados.

Después de 3 meses de trabajo, logramos solucionar el 100% de los problemas restantes utilizando solamente el 6% del presupuesto original.

Los tickets eran síntomas, no el problema.

Si identificas dolores similares en tu organización, nuestra formación de Lean Product Ownership dura 5 semanas y está enfocada en la aplicación de lo aprendido en la práctica, no solamente en la teoría. Al final de las sesiones se habrá resuelto un problema del mundo real con el Ciclo de Resolución de Problemas. Esta formación también se ofrece en una modalidad cerrada para organizaciones y está certificada por la Heart of Agile Academy.

Los invitamos a conversar con nosotros por todos nuestros canales disponibles.

¡Hasta la próxima!