El enfoque que debe tener un Product Owner

Quisiera empezar mencionando, que es muy común encontrar Product Owner que piensan de la siguiente manera: “Si tengo un/unos usuario(s) que tiene(n) un problema, se lo planteo al equipo de desarrollo, el cual desarrolla una nueva funcionalidad, una mejora o un cambio en el sistema y listo resuelvo el problema.” Déjame decirte algo mi querido Product Owner, no pienses que por el solo hecho de entregar una funcionalidad, mejora o cambio, el problema se resolverá. O incluso más importante aún, que por realizar dicha entrega, se causó el impacto deseado en el comportamiento del usuario y/o se generó un impacto financiero o de posicionamiento positivo para la compañía. Sin duda, nada mas ajeno de la realidad que esto y nada más desacertado para ti, el tener este tipo de pensamiento.

En el post anterior, estuve mostrándote las cosas que deberías evitar hacer para ser un buen Product Owner (el post lo puede leer aquí). En esta ocasión, quiero mostrarte los dos enfoques que hay en el desarrollo y la gestión de productos y/o soluciones, cuáles son las consecuencias de llevar cada uno de ellos y por lo tanto cual es el enfoque que tu como Product Owner deberías tener.

Enfoque de gestión y desarrollo de productos y/o soluciones orientado a entregas.

¿Alguna vez has tenido que preparar una presentación para tus superiores, con una hoja de ruta que muestre cuando van a ser entregadas las distintas funcionalidades que han sido planificadas? Y ¿las discusiones en los espacios de presentación, han estado centradas en estas? Si tu respuesta es sí, quiere decir, que las funcionalidades, mejoras o cambios a realizar en el sistema, están en el centro de nuestra estrategia de organización del Product Backlog. Por lo tanto, nuestro enfoque de gestión y desarrollo de productos y soluciones está orientado a entregas, es decir a Outputs. Lo cual es muy común cuando las personas (en especial los jefes que no cuentan con un Mindset agile) necesiten/quieran ver cuándo y qué se entregarán para comprender dónde y cuándo se obtendrán los resultados para el usuario o la empresa.

La consecuencia de tener este tipo de enfoque, es que tanto los gerentes/jefes de las organizaciones, así como desafortunadamente los Product Owner, terminan enamorándose y/o preocupándose más por las soluciones que por los problemas en sí. Lo que conlleva entre otras cosas a estar mas pendientes de la productividad que de analizar los resultados de negocio obtenidos. Lo correcto sería (aunque es más difícil) enamorarse más del problema que de la solución. Esto significa, que se debería invertir más tiempo en la etapa inicial del proceso, para conocer más sobre el problema, comprender sus complejidades y razones, y luego pasar a una solución. Esto les haría ver, que la cantidad de entregas que se realicen de nada importan, si estas no están afectando el comportamiento del usuario, lo que a su vez afecta los indicadores del producto, lo que a su vez debería afectar los indicadores comerciales.

Enfoque de gestión y desarrollo de productos y/o soluciones orientado a resultados.

Tener un enfoque de gestión y desarrollo de productos y/o soluciones es organizar el Product Backlog para orientar a los equipos y su planificación, a alcanzar un determinado objetivo, teniendo como referencia el avance obtenido en el tiempo de determinados resultados (comerciales, de marca, de comportamiento, etc.). Dichos resultados, deben estar alineados con los objetivos de los Sprint que tienen los equipos y las presentaciones a realizar en los distintos comités organizacionales. Sin duda pensarás, que esto es mucho más fácil decirlo que hacerlo, pero es el mejor enfoque que puedes tener como Product Owner, para que los equipos logren generar los mejores resultados para la organización y para los clientes.

Pero ¿Cuál es el impacto no tener un objetivo para el Sprint o tenerlo pero que este no esté alineado a la estrategia de liberación?

Cuando los equipos no tienen un objetivo de Sprint, se vuelve imposible controlar las tres fuentes de fricción identificadas por Stephen Bungay, que influyen en la determinación de tener una estrategia con un enfoque orientada a resultados por encima de una orientada a hacer cosas (en este caso a entregas). De hecho, se presentaran cada vez a mayor escala. Dichas fuentes son:

  1. Brecha de conocimiento. Cuando esta se presenta, las personas dedican aún más tiempo a grandes análisis y planificación inicial para tratar de cerrar la brecha (¿te recuerda algo?).
  2. Brecha de alineación. La respuesta típica a los problemas de alineación es emitir instrucciones más detalladas. Todos estos detalles adicionales terminan obstruyendo la claridad y generan aún más confusión.
  3. Efectos gap. La respuesta habitual es imponer controles y métricas más estrictos en los equipos para tratar de garantizar que estén entregando los resultados correctos.

Y adicionalmente a esto, cuando se cuenta con un objetivo, pero este no está alineado a la estrategia de liberación se presenta lo siguiente:

  • Se desperdicia mucho tiempo en la planificación y el análisis. Sin objetivo del Sprint, los planes se vuelven rígidos e inflexibles, y no será posible incorporar nueva información a medida que se aprenda más y se avanza en el desarrollo del producto o Solución.
  • El equipo de desarrollo no puede autoorganizarse y definir lo que debe hacer. Por lo que, lo que se debe hacer, se define por adelantado sin una relación con un objetivo claro.
  • Cada elemento del Backlog, se convierte en un compromiso. Como resultado, el alcance ya no es flexible. Cuando aparece la inevitable complejidad imprevista, la única forma de terminar lo planeado eliminado ítems e introduciendo deuda técnica.

Ahora, un Objetivo de Sprint, establecido de manera centrada en los resultados, hace posible que el equipo se alinee a la estrategia de liberación establecida por el Product Owner, con la cual se busca alcanzar los resultados establecidos, y así podremos saber si se están alcanzado los objetivos. Adicionalmente a esto, un objetivo de Sprint, establecido de manera centrada en resultados, reduce el efecto provocado por las tres fuentes de fricción identificadas por Stephen Bungay.

En este orden de ideas, hay que decir que:

  • La brecha de conocimiento se reduce por la correcta definición y comunicación del Objetivo Sprint. Es decir que tener claro el ¿Por qué y qué queremos lograr?, los equipos pueden incorporar una mejor información para determinar como lograr dicho objetivo. Y tu como Product Owner, tendrás mejor información para construir el plan de liberación.
  • Para cerrar la brecha de alineación, la organización debe tener una alineación clara y transparente sobre los objetivos que deben alcanzarse. De esta manera, el equipo puede decidir cómo impactar al usuario para lograr objetivos globales. En este sentido tu responsabilidad como Product Owner, es instigar el liderazgo para definir y crear una alineación con los objetivos que deben lograrse.
  • Para minimizar la brecha de efectos, es importante dar a los equipos la libertad de ajustar sus acciones en función del objetivo del Sprint. Esta es la razón por la cual el Sprint Backlog de Sprint es flexible durante el Sprint siempre que no ponga en peligro el/los Objetivo de Sprint.

Ahora, mi querido amigo lector como Product Owner, debes definir lo que serán los entregables (outputs), solo después de definir Resultados (Outcomes). Sin embargo, ten presente que, la definición de los resultados que se deben lograr, llega solo después de haber identificado, comprendido y entendido los problemas y las necesidades de los usuarios. Por eso es tan importante conocer bien el tipo de valor y la propuesta de valor que se ha de generar.

Por lo tanto, cuando una empresa trabaja con un marco (como los OKR), o un Product Owner tiene un enfoque de gestión y desarrollo de productos/soluciones orientado a resultados, prioriza primero los objetivos y los resultados, por encima de las entregas. Entonces, definir, medir y monitorear lo que se hará, será mucho más fácil.

Si quieres aprender mas, te invito a que le des un lectura a mi libro: Product Backlog, una mirada sistemica (Aqui). En donde te ofrezco una visión completa de lo que es el Product Backlog y su importancia en el desarrollo de productos y soluciones que generen valor al cliente. Ademas de mostrarte como crear, organizar y gestionar product backlog orientado a outcome (resultados) por encima de output (entregables).

Pd:Te invito a dar un vistazo a mi libro recomendado del mes (Clic Aquí)

Gracias por tu tiempo.

Saludos,


También te puede interesar Leer



SUSCRÍBETE A MI BLOG

Y cada vez que realice una nueva publicación, recíbela al instante.


Una respuesta a «El enfoque que debe tener un Product Owner»

    
Suscríbete al Blog
Y entérate cada vez que realice una nueva publicación.
Suscribirse
Te puedes dar de baja cuando lo desees!
close-link
A %d blogueros les gusta esto: