Llevo mucho tiempo plantando unas semillas en mi entorno, y es recordar a todas las personas que trabajan en la organización que todos somos producto, todos hacemos producto, sólo que aportándole valor desde diferentes perspectivas. Este mensaje me resultó muy importante cuando observaba como muchos Product Owners trabajan siempre con los mismos Stakeholders y de la misma manera, lo que luego se traduce en aspectos que no se han tenido en cuenta que pueden: retrasar la entrega del incremento de producto, entregar un incremento de producto incompleto y en ambos casos, afectar negativamente en la confianza hacia el trabajo del Product Owner.
Un Product Owner debe conocer perfectamente la organización de la empresa y tener una persona de referencia en cada una de sus funciones, departamentos, áreas, tribus o como en vuestro entorno se denomine. Estas personas pueden ser sus Stakeholders o ayudarles a encontrarlos.
Un Product Owner debe conocer si el producto requiere de un soporte externo a la organización: otros proveedores y/o entidades, que permiten el correcto funcionamiento del mismo.
Un Product Owner debe encontrar la manera de que haya transparencia en el estado del producto de forma constante y simple. Esto es fundamental para la gestión de Stakeholders que además es un gran beneficio el equipo de desarrollo y la organización, y si lo hace bien, la gestión de Stakeholders se simplifica considerablemente.
Creo que todos los posibles miembros anteriores son Stakeholders del producto, pero en mi experiencia la clave está en que no todos son Stakeholders de las mismas iniciativas y por tanto el trato en cada caso es diferente. Por ello voy a definir dos tipos de gestiones de Stakeholders a muy alto nivel que espero os puedan encajar en vuestro día a día: la gestión de Stakeholders global, la gestión de Stakeholders por iniciativas.
Gestión de Stakeholders global
La mayor parte de los Stakeholders quieren saber qué pasa en el producto, cuándo se va a hacer lo que ellos han pedido, qué vamos a entregar al cliente y los valores de las métricas del producto – globales y el área que a ellos les compete – lo que podemos traducir a dar visibilidad, proporcionar información que se entienda, actualizada y que esté accesible.
Todos los Stakeholders deben tener acceso al Product Backlog, así pueden ver qué se va a hacer y dónde están sus peticiones.
Todos los Stakeholders deben tener acceso a otros artefactos que usamos para proporcionar información del producto, ejemplo: nosotros hacemos unas sesiones semanales para revisar métricas del producto y tomar decisiones que pueden afectar a las prioridades. Las presentaciones que se elaboran para esa sesión están en una carpeta, con un formato de nombrado específico y cualquier Stakeholder puede acceder, de esta manera puedan o no asistir a la sesión la información está ahí y la pueden consultar.
Todos los Stakeholders deben estar invitados a las sesiones donde se presente el incremento de producto que vamos a entregar. Algunas cosas que podemos hacer para facilitar la vida a los Stakeholders en estos casos:
- Proporcionar una agenda de la sesión y así pueden elegir si les merece la pena asistir en persona
- Grabar las sesiones y/o tener material donde se resuman las sesión y que esté accesible para los que no han asistido
Todos los Stakeholders deben asistir a sesiones donde se presente en estado del roadmap del producto o al menos tener acceso al mismo. Es importante que el Product Owner haga una buena gestión del producto backlog organizando el trabajo para el equipo de desarrollo, pero también que disponga de otros elementos para visualizar la dirección del producto, sus objetivos, la misión, ese ‘alto nivel’ o ‘big picture’, que en caso de que exista debe mantenerse vivo al igual que el product backlog.
Considero que el Product Owner debe saber mantener informados a todos los Stakeholders, para ello debe gestionar los artefactos necesarios que proporcionan transparencia de lo que ocurre alrededor del producto. Por otro lado, el Stakeholder debe poner también de su parte, es decir, debe asistir, leer y sobre todo dar feedback en caso de que las comunicaciones no sean comprensibles.
Gestión de Stakeholders por iniciativa
En la sección de antes he mencionado aspectos para gestionar a los Stakeholders de forma global que generalmente se basa en mantenerlos informados. Pero cuando estamos trabajando en una iniciativa en concreto, hay Stakeholders que están directamente involucrados pues llevan a cabo ciertas tareas para que la iniciativa pueda entregarse. La gestión de Stakeholders por iniciativa requiere que formen parte del ciclo de vida de la misma, desde que se decide invertir en la iniciativa, se descubre qué hacer, se detalla el trabajo a realizar, se empieza a llevar a cabo el trabajo hasta que por fin se entrega y empezamos a aprender con el feedback del cliente.
Un Product Owner debe tener dos dimensiones para trabajar con los Stakeholders por iniciativa:
- Identificar claramente los Stakeholders involucrados en la iniciativa y su porqué
- Comunicarse con los Stakeholders en función del estado de la iniciativa
Para mi este es uno de los retos más grandes del rol del Product Owner, la gestión de los Stakeholders, en función de cada iniciativa y su estado, ya que todo está basado en comunicación y el tipo de comunicación es muy diferente en función del estado del a iniciativa.
Durante las sesiones de descubrimiento de producto es importante que haya una interacción personal y se facilite bien la sesión para que todos los involucrados aporten como ellos contribuyen a que la iniciativa pueda entregarse.
Durante el proceso de desarrollo es importante que haya una comunicación fluida y periódica para transmitir avances, impedimentos. Cuando llevo iniciativas cuyo foco es de 2 o 3 meses, procuro tener un canal de comunicación donde cada dos semanas envío un breve informe en 3 líneas: progreso, impedimentos, siguientes pasos. Esto da visibilidad, indica que se sigue trabajando en ello, que estás pendiente de los Stakeholders y que les avisarás cuando tengan que entrar ‘en juego’ de una manera u otra.
Una vez entregado el producto, las métricas que se evalúan con los Stakeholders involucrados son a más bajo nivel, y es muy valioso si el Product Owner trabaja codo con codo con ellos, en una sesión dedicada donde se evalúen los resultados, se comparten aprendizajes y se alimente el product backlog para seguir iterando.
Si os dais cuenta, en este segundo caso esos Stakeholders se ‘convierten en uno más del equipo’ ya que sin su trabajo, no podríamos entregar un incremento del producto.
Y algunos os podéis preguntar: ¿cómo se si estoy haciendo un buen trabajo con mis Stakeholders?. Puedes observar cuántas veces te preguntan por lo mismo, cuántos emails tienes abiertos para el mismo asunto, qué tipo de preguntas te hacen para ver si tú das visibilidad de esas respuestas, si te preguntan por elementos del producto backlog que no entienden muy bien… ellos quieren información, ¿cómo la proporcionas tú?.
Los Stakeholders quieren ser autónomos a la hora de saber qué pasa en el producto y sentirse parte del equipo cuando hay objetivos comunes,
Os dejo los enlaces a los artículos que estoy escribiendo sobre el Product Owner:
Vanesa Tejada 
4 pensamientos