En esta Product Session sin duda nuestros compañeros Victor Corrales y Paco Crespo van a abordar uno de los temas que más ampollas levanta en el mundo del Product Management. La gestión de stakeholders.
¿Qué es un stakeholder?
Para Paco, básicamente y resumiendo muchísimo entre risas son “la gente que te pide cosas”. Entrando más en detalle los diferencia dependiendo del tipo. Por ejemplo, uno de los stakeholders que tendría cualquier producto digital es la Unión Europea con la ley de GDPR y por alusión tendríamos también a uno de los stakeholders más duros dentro de las empresas: el departamento de Legal. Este departamento y su relación con los Product Managers es una historia un tanto tensa en la que Víctor y Paco nos dan un consejo muy útil para conseguir que sea más beneficiosa para todos:
El buzón de contacto del departamento de Legal debe ser nominativo. Es decir, como Product Managers no podemos estar realizando una gestión o comunicación con un buzón donde no hay una persona física identificada como interlocutor. No puede ser una comunicación a nivel departamental.
Entrando más a fondo en la definición de lo que es un stakeholder, para Paco Crespo es “cualquier persona interesada en el producto o servicio y/o tenga influencia sobre él”. Gobierno, usuarios, la competencia, departamentos, etc. son stakeholders de nuestros productos.
Como Product Manager es muy importante tener muy bien identificados dentro de tu empresa a los stakeholders que son impactados por tu producto o servicio. Por ejemplo, si tu producto afecta directamente a la métrica de visitas a lead tendrás como stakeholders muy importantes los departamentos de Marketing y Negocio. Si, en cambio, tu trabajo se centra más en el backoffice operativo, tendrás a Ventas o Comercial. Estos departamentos te pedirán que cambies o añadas cosas a tu producto y como PM deberás lidiar con sus solicitudes.
Paco comenta que el enfoque para detectar e identificar a los stakeholders debe ser mucho más amplio si tu rol es el de Head of Product o CPO, ya que debes tener en cuenta stakeholders que como PM no es necesario que tengas en el radar. Hablamos de reformas legales, laborales, etc. que harán que entren en escena nuevos stakeholders. Menciona el ejemplo de Deliveroo y como debido al cambio en la legislación laboral no pudo adaptarse y terminó abandonando España.
¿Por qué tenemos tantos conflictos con los stakeholders?
Paco y Víctor lo tienen clarísimo. Porque priorizamos y tenemos una capacidad de producción finita. Esto nos lleva a situaciones en las que tus acciones y cambios de priorización para atender la demanda de algunos de tus stakeholders generarán roces y situaciones tensas.
Cuando un departamento como Legal te hace una petición no quedará otra que abandonar nuestra forma Lean de trabajar en producto para abordarlo como un proyecto si queremos cumplir con los plazos establecidos. Esto provoca un cambio de priorización, ya que habrá que colocarlo por encima de lo que tenías hasta ahora. Víctor añade un punto muy a tener en cuenta y no es otro que los objetivos.
Cuando los objetivos de ese departamento que ha realizado la petición son diferentes a los tuyos pueden chocar provocando aún más tensión si cabe. Paco pone como ejemplo una de las startups donde trabajó en la que el objetivo del departamento de Negocio era básicamente vender mucho, mientras que el objetivo de Producto era eficientar los procesos y operativa para poder vender con el mismo número de personal. Esto hacía que las propuestas de uno y otro departamento chocaran frontalmente, creando constantes tiranteces.
Víctor recalca que en muchas ocasiones los stakeholders no entienden por qué priorizamos y ejecutamos determinadas tareas que se realizan desde Producto. Es muy común que, por un lado, se infravalore la complejidad de lo que supone priorizar y, por el otro, eviten entender mínimamente la parte técnica de la tecnología que tiene tu producto. La combinación de ambas posturas aleja a nuestro stakeholder de entender nuestras decisiones y la implicación que conllevan sus peticiones.
Los PMs que trabajan en productos internos B2B muchas veces mantienen posturas muy totalitaristas imponiendo funcionalidades bajo su criterio cuando lo que se debe hacer es escuchar a ese usuario interno que conoce perfectamente lo que necesita. Ojo, esto no quiere decir que como PM no velemos porque nuestro producto sea escalable. Deberemos vigilar la arquitectura funcional, modelo de datos flexible, nunca reglas demasiado rígidas, etc.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
¿Qué tipo de estrategias sueles utilizar para la gestión de los Stakeholders?
Con esta pregunta Paco lo tiene muy claro. Debemos tener una estrategia con cada uno de ellos. Para poder definir dicha estrategia es necesario realizar un stakeholder map donde plasmemos de una forma visual los stakeholders que tenemos y el nivel de influencia e interés que tienen.
En este stakeholder map, Paco recalca que hay que saber diferenciar muy bien entre el poder y la influencia. El poder lo tiene la persona que influye. Pone como ejemplo un CEO de una empresa con mucho poder, pero que basa sus decisiones bajo la influencia de su CTO. Por lo tanto, la estrategia se centraría más en el CTO y no en el CEO.
En definitiva, mapeando los stakeholders podemos categorizarlos, conseguir entender por qué están en el cuadrante que están y cómo puedo lograr moverlos al cuadrante que más me conviene.
Es importante conocer que en muchas ocasiones no podemos esperar que los stakeholders se muestren colaborativos o nos den su confianza si llevamos poco tiempo en la empresa. Muchas veces es cuestión de tiempo para que tú como PM puedas demostrar tu valía como profesional ganando esa confianza y ellos como stakeholders puedan cambiar esa percepción de alguien del que aún no se fían. Una vez que se ha dado ese primer paso hacia la confianza, es fundamental darse cuenta lo antes posible que es imposible dar a todos los stakeholders todo lo que piden.
Ante esta afirmación, Víctor le pregunta a Paco:
¿Qué stakeholder es el más duro de gestionar?
Paco es unánime. El stakeholder más duro con mucha diferencia si la relación se tuerce es Tecnología. Ellos tienen la palanca de la ejecución. Si como PM terminas teniendo problemas con el Tech Lead o con los desarrolladores, puede convertirse en una situación muy complicada de encauzar afectando mucho a nuestro producto.
¿Cómo podríamos pasar de gestionar a colaborar con los stakeholders?
Paco pone como ejemplo una empresa en la que trabajó: Adevinta. En ella comenta que la gestión de los stakeholders pasó a ser colaborativa porque entendieron que era muy importante trabajar como equipos multidisciplinares para que no hubiera constantes conflictos con peticiones provenientes de diferentes departamentos. Cuando hay una persona de cada departamento dentro de cada equipo se reducen muchísimas tensiones y se tiene muchísimo más alineamiento en cuanto a las acciones que se llevan a cabo.
¿Cómo podemos gestionar a los stakeholders que se entrometen en nuestro trabajo?
Como bien sabemos, el Product Manager es el único rol de la empresa con apellido de manager, pero que no manda sobre nadie. Partiendo de esta base, Paco nos da un gran consejo que muchas veces cuesta seguir: NO HAY QUE ENFADARSE. Solo hay un momento en la vida de un PM en el que podría estar justificado que se enfadara y no es otro que cuando alguien le toca el backlog. Para un PM, el backlog es donde reside su poder para con su producto y su capacidad de negociar con el resto de stakeholders. Si un stakeholder puede acceder al backlog y priorizarlo, el PM deja de ser alguien relevante en cuanto a las decisiones de producto.
Ante el poder que aporta priorizar nuestro backlog y la gestión de stakeholders que lleva implícita esta labor, Paco nos da una serie de pasos que podemos seguir para poder realizar ambas labores sin que salte todo por los aires:
- Entiende el problema que quieren resolver.
- Una vez entendido el problema, busca soluciones fuera de la caja. Por experiencia, cuando los stakeholders llegan a nosotros aportando soluciones, normalmente es recomendable que en lugar de verlo como algo funcional lo veas como un análisis del problema que está detrás de esa funcionalidad. Seguramente, llegarás a una feature más pequeña con la que podrás cumplir con todos tus stakeholders.
- Alineamiento con negocio. Si tras el análisis del problema y la búsqueda de soluciones fuera de la caja no has conseguido encontrar nada que pueda resolver las necesidades de tus stakeholders, no queda otra que alinearte con negocio. Ojo, no se resolverán tus conflictos con los stakeholders, pero buscando el alineamiento con negocio podrás justificar tu priorización.
- Mira por ti. Si ninguna de las reglas de priorización anteriores te han llevado a una justificación para priorizar una u otra petición de los stakeholders, ya solo queda mirar por nuestro interés. Buscar cuál de las peticiones resolvería más deuda técnica, deuda funcional, etc…
- Por último, aunque no es muy partidario de los frameworks, utilizaría los más usados como ICE, MoSCoW, etc…
Un importante apunte que Paco nos da es que debemos tener muy claro como PMs que a la hora de priorizar debemos empezar por la base que no es otra que la respuesta a ¿Trabajamos en modo Lean o en modo proyecto?
Si trabajamos en modo Lean deberemos priorizar en base a las iniciativas que muevan el número que tenemos como objetivo mediante iteraciones con las que validaremos. En cambio, si trabajamos en modo proyecto utilizaremos frameworks como ICE, RICE, etc.
¿Qué consejo le darías a esos Product Managers que ahora mismo no tienen el control de su backlog?
A esta pregunta Paco prefiere diferenciar dependiendo de la causa por la que el PM ha perdido el control de su backlog. Puede ser debido a un tema cultural de la propia empresa por la complejidad de la estructura de la empresa y producto o, simplemente, puede ser algo que esté en la parte del PM por lo que habría que analizar el caso concreto.
Víctor, bajo su experiencia, habla de corporates donde no es nada sencillo escapar de la gestión del backlog por parte de los stakeholders. Una iniciativa que siempre le ha funcionado es justificar sus priorizaciones basándose en datos con el framework WSJF.
Los números en la mayoría de las ocasiones apagan cualquier atisbo de duda o discusión, ya que, estamos justificando nuestras decisiones en base a datos. Paco enlaza esta iniciativa de Víctor, añadiendo que el siguiente paso natural para afianzar esta toma de decisiones es mediante los objetivos numéricos por equipo. Esta transición sería decisiva para poder justificar tus priorizaciones.
¿Qué ocurre cuando los stakeholders nos piden fechas?
Bien. Ante esta pregunta es necesario hablar de roadmaps donde normalmente los stakeholders quieren ver plasmadas las entregas que recibirán en una determinada fecha. Y, cómo no, de nuevo, la cuestión clave es si trabajamos en modo Lean moviendo números o trabajamos en modo proyecto. En modo Lean el roadmap será muy sencillo o incluso puede que no tenga demasiado sentido que exista, ya que cuando trabajamos así ponemos en marcha 10 - 12 iniciativas para mover un número y vamos midiendo cuál de ellas mueve nuestro número. No podemos comprometernos en la entrega de algo funcional en un roadmap porque no sabemos si lo llegaremos a hacer, ya que a medida que vayamos leyendo al usuario iremos iterando, pero sin saber qué nivel de complejidad tendrá la funcionalidad en el futuro. En el proyecto sí podemos comprometernos ya que se ha establecido con antelación el alcance, costes, entregas, etc.
¿Cómo dices NO a un stakeholder sin decir que NO?
Depende mucho del carácter que tengamos y cómo comuniquemos, pero si alguna vez nos encontramos con un stakeholder al que no se le puede decir que NO hay una frase que puede ayudarte a conseguir el mismo efecto sin buscarte ningún problema:
“Tranquilo lo pongo en el backlog”
Esta frase sin duda puede ayudarte a dar “largas” de una forma muy sutil a esas ideas sorprendentes que vienen mientras tu CEO desayunaba…
Otra de las frases que puede amedrentar y espantar las ganas de llevar a cabo felices ideas es la de:
“Espera porque creo que esa funcionalidad técnicamente es suuuuper difícil”
o la de:
“Esto ya se pensó hacer una vez y no se pudo hacer por algo…”
Sin duda en el cesto de la gestión de los stakeholders entran multitud de factores que pueden hacernos tomar unas decisiones u otras, pero nuestro trabajo como PMs es aprender a lidiar de la mejor forma posible con ellos sin dejar de ser profesionales.
Si quieres aprender más, echa un vistazo al Certificado de Product Manager
