Construyendo puentes en equipos de producto

https://unsplash.com/@jack_anstey

Ayer estuve escuchando esta charla, y me pareció interesante sacar algunos insights y compartir los documentos que utiliza Heap para estos casos.

No podemos negar que en algunas empresas los equipos más que trabajar juntos hacia una meta, son un grupo de personas empujando en diferentes direcciones: los desarrolladores quieren pasar más tiempo con la tecnología, los diseñadores quieren mejorar la usabilidad, otros stakeholders tienen sus propias necesidades, y en ninguno de los casos lo más importante para ellos es el usuario. Y que hablar ya de cuando las decisiones las toma un HiPPO (Highest Paid Person’s Opinion) o una ZEBRA (Zero Evidence But Really Arrogant) de cualquiera de los equipos mencionados.

El PM tiene una labor muy importante de alineación, y hay ciertos aspectos que marcan la diferencia.

  1. Un PM explica al equipo QUÉ hay que hacer, pero un buen PM se toma el tiempo en explicar el POR QUÉ.

Documento: The Heap Problem Brief

Un PM, como líder del equipo, siempre debe alinear en torno al WHY, y acercar al equipo tanto como pueda al problema. Compartir el contexto del problema, las user stories, research, datos relevantes, o incluso llevar a algún desarrollador a las entrevistas para oír el feedback de primera mano. Todo esto crea consciencia al equipo sobre los problemas que se están queriendo solucionar y los outcomes que se intentan conseguir.

Hipótesis: Una vez entendido el problema, se lanza la hipótesis que se cree que mejor puede resolverlo. Y es importante recalcar que las hipótesis son ideas que se van a testar para ver si funcionan, por lo que existirán otras formas de solucionarlo y hay que estar abiertos a otras ideas.

Métricas: El equipo deberá estar alineado sobre cómo medir el éxito y qué impacto es el que se buscando.

Impacto en negocio: Finalmente, para un PM puede que sea obvio la relación sobre cómo esa feature funciona con el negocio; pero es importante compartirlo con el equipo y terminar de conectar los puntos para que sepan cuál es el impacto de negocio que se espera.

En resumen: I want to build this feature vs Help me solve this problem.

Finding the solution: Documento: Design Brief

2. Un PM celebra un lanzamiento; un buen PM celebra el impacto y hace que el equipo gire en torno al impacto.

Cuando el equipo está lanzando features continuamente, a veces en lugar de dedicar tiempo a mirar hacia atrás y aprender qué ha funcionado y qué no, se sigue adelante para preparar lo siguiente. Sin embargo, lanzar algo no significa nada; lo que se busca es el impacto en negocio. Por ejemplo, quizá se saca una funcionalidad sencilla para atacar un problema, y al hacerlo no se recibe el impacto esperado. Esto podría ser una alerta de que el problema es más complejo. Esto va a permitir llegar a la raíz para entender qué está pasando y poder iterar.

Documento: After Action Report

3. Un PM puede simplemente aceptar que en cada cosa que hacemos existe una complejidad inherente. Un buen PM no acepta la complejidad, busca la simplicidad.

Los PMs son de alguna manera domadores de complejidad en el equipo, bien sea en problemas en entender el negocio, el contexto del mercado, presiones organizacionales, stakeholders… El PM recibe la información, esta complejidad, y debe convertirlo en algo que el equipo pueda digerir.

Una de las maneras que tiene un PM de hacer esto es estableciendo un par de métricas sencillas, memorables y accionables para el equipo, así como objetivos para orientarse sobre ellas, de manera que todos puedan pensar qué pueden hacer para moverlas. Es trabajo del PM controlar el resto de métricas, pero es interesante compartir con el equipo estas key metrics para estar alineados y mantener el foco.

Como PM… ¿Dónde encuentras la dificultad para alinear al equipo?