Cuando hablamos de Producto Owner vemos que se habla mucho sobre su gestión del producto enfocándose en el ¿Qué? del producto. Pero en el trabajo del día a día el Product Owner también debe responder sobre el producto que estamos haciendo ¿A costa de qué?. Repasemos un poco la definición de PO:

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Scrumguides.org 2019

El Product owner es responsable de:

  • Maximizar el valor del producto resultante del trabajo del equipo de desarrollo.

El Product Owner (PO) es responsable también del trabajo que lleva el equipo de desarrollo y el ciclo de vida del producto.

Si bien el PO es responsable del producto, este no vive solo, no es una isla dentro de la empresa. Debe estar inter-conectado con stakeholders (interesados) que apuestan por el y por los objetivos de la empresa de los cuales se desencadena esta iniciativa.

Enfocarse solo en el producto puede dejarnos en el rol de product owner flácido. Debemos conectar con los stakeholders, pues ellos requieren respuestas sobre la inversión que se esta haciendo, seguirán preguntando entorno a alcance, costo y tiempo. Y debemos estar en capacidad de responder a esas dudas.

Por otro lado, Si solo me enfoco en mi visión del producto puede que me desvíe de los intereses de la empresa o de como esta ve a sus clientes. Puede que la empresa haya pensado en satisfacer a un cliente tipo A y en mi ímpetu y visión haya desarrollado solo funcionalidades para clientes tipo B. Es probable que traiga gran beneficio para la empresa pero esto ya haya sido pensado en ser cubierto con otra iniciativa, generando así yo el producto incorrecto y por ende sobre-costos.

Cuando planteo esta preocupación a los Product Owner que acompaño suelen estar más preocupados pues de por si el rol del PO es muy difícil de llenar.

Para ellos les propongo llenar una hoja muy simple y no perder de vista lo que considero las 3 ventanas de Producto. Es decir, vamos a ver el mismo producto pero con ojos de Proyecto, Producto y Servicio.

Veamos primero la ventana de Proyecto. En el ejemplo que muestro lo hago con el producto Iphone X. Iphone X como producto cuenta con un sistema operativo con funcionalidades esperadas. Estas deben estar en sinergia con el lanzamiento del producto. Se esperan ciertas funcionalidades en un tiempo fijo de lanzamiento, es más, estas ya están anunciadas al publico. El alcance esperado ya esta visible, la fecha anual del nuevo Iphone no suele moverse mucho así que el tiempo esta ya definido aproximadamente y el costo es el que se maneja dentro del mismo equipo o mejor dicho el sueldo del equipo de desarrollo en el tiempo. Si vemos esto El Iphone X con su sistema operativo tienen un vista de producto. Los Chips y las unidades previstas ya tienen una fecha proyectada en la que deben ser entregados. Esta ventana nos permite no perder de vista los compromisos, que si bien en agile no esta escritos en piedra si queremos ser competitivos en el mercado debemos hacer lo posible en cumplirlos. ¿Se imaginan que Apple no lance un nuevo celular en un año? o ¿Que la fecha de lanzamiento se mueva un mes? esto seria terrible!. Se cruzaría con otros eventos que apocarían su lanzamiento, la competencia podría adelantarse y generar grandes perdidas.

¿Qué debe tener mi producto?
¿Qué debe tener mi producto?

Vamos con la vista de producto. Esta es un poco mas conocida pues es ver el Producto desde su propuesta de valor. ¿Qué valor ofrece el Iphone X? ¿Cómo satisface las necesidades del cliente? ¿Están cambiando las necesidades del cliente?. Esta ventana nos permite ver la gestión del Product Backlog así como su validez en el tiempo. Nos permitirá observar y ajustar nuestra propuesta de valor de aquí hacia atrás. Es decir, cambios en nuestro producto vistos por esta ventana nos obligaran a abrir la ventana del proyecto y hacer los cambios necesarios.

En pocas palabras esta ventana es nuestra vista a la gestión de Product Backlog, las métricas del producto y el feedback que obtenemos de los usuarios.

¿Estamos alineados con el servicio que da la empresa?

Nuestra ultima y tal vez mas importante ventana es la del Servicio. Esta ventana nos permite conectar con el servicio que brindara el uso de nuestro producto y los niveles de servicio que da la empresa. En el caso del Iphone X ¿A que clientes estará dando servicio? ¿Con que otros servicios de la empresa me conecto? ¿Estoy ayudando a dar un buen servicio? ¿Hago que el servicio sea empático y responda a nuestros colaboradores con mi producto? ¿Como el servicio de la empresa me permite conocer mas a los clientes?. Esta ventana nos permite también ver si no nos estamos cruzando en esfuerzos.

Recuerdo mucho el caso de LEGO®. En el que en su reunión de sincronización encontraron que dos equipos estaban trabajando en productos orientados al mismo tipo de cliente (niñas) y decidieron juntar esfuerzo. O un caso tardío fue LEGO® Boost un robot que se interceptaba con la propuesta de valor de la linea Mindstorm. Boost salio al mercado pero con relativo éxito porque un producto de la misma empresa competía con el.

Así es como con este pequeño lienzo podemos tener alineados nuestro producto dando soporte a un servicio y respuestas a un proyecto. También, permite que Agile coaches puedan ir trabajando con los PO que acompañan y tener una herramienta que les permita responder preguntas de los diversos frentes de la empresa.

En la medida que más personas adquieran un mindset ágil. La ventana de Producto se juntara con la de Proyecto siendo una sola. Pero ese sera ya tema de otro articulo.

Gracias por leerme.
Quedo atento a tus comentarios.
No olvides suscribirte para tener en tu correo mas contenido interesante.