Yo de mayor quiero ser jefe…¿o no?
Aprendizajes de la vida sobre el paso de Product Manager a liderar un equipo de producto
Mis tíos no tienen ni idea de qué hago en mi trabajo (creo que se creen que vendo seguros o algo así), pero lo primero que me preguntaron la última vez que me cambié de trabajo ni siquiera fue el sueldo que iba a cobrar, sino cuánta gente iba a llevar en mi equipo. Vale, mis tíos son mayores y quizá tienen otra forma de pensar…pero ¿qué me decís de mis amigas? Tienen la misma edad que yo…pues otra vez la preguntita el último fin de semana, que estuvimos de casa rural: “oye, Laura, ¿y tú cuánta gente tienes a cargo en tu trabajo de ahora?”. En fin.
Y es que esto de llevar equipo es como lo de tener hijos: parece que llega un momento que es “lo que toca”. Y no digo que sea malo, es maravilloso (si te gusta, claro), pero no todo el mundo está hecho para eso y desde luego no se suelen contar lo que tiene el rol de feo ni las típicas “cagadas” del jefe principiante liderando product managers por primera vez.
Así que he pensado hacer un poco de memoria y contar algunos de los aprendizajes que me he llevado yo directamente a base de darme tortazos y hacerlo mal al principio, por si os vale. Me vais a permitir hacerlo sin dar nombres concretos ;-) ¡Vamos a ello!
Los demás no son como tú, ni tú eres como los demás
Uno de los primeros grandes cambios que tuve que absorber cuando empecé a liderar equipos de producto fue aprender a delegar. Esto suena a lo típico…pero es que de verdad hay que aprender.
Cuando yo era product manager me encantaba hablar con usuarios, entender bien los problemas y oportunidades, pensar en soluciones con tech y buscarles pros y contras a las distintas opciones…al final el producto es tu pequeña criatura.
Cuando eres líder de otros PMs tienes que dejar de hacerlo tú para darle ese papel a tu equipo, darles margen a que lideren ellos, e incluso a que se equivoquen. Es 100% seguro que harán las cosas distintas a cómo tú las harías…porque no son tú :-) . Así que hay que tener un cierto nivel de confianza en ellos y dejarles hacer, aunque sea con cierto guiado.
Un ejemplo de cómo no hacer las cosas es una de las primeras veces que pasé a liderar a un junior PM: como era junior no me fiaba de que pudiese hacer un buen papel de definición de producto, así que le tuve un tiempo haciendo tareas menos “de producto” como test cases, y con mínima responsabilidad…claro, cuando me decidí a darle la responsabilidad de definir una nueva funcionalidad tenía tan poca confianza y experiencia que cometió errores y eso le generó menos confianza (propia y mía)... Círculo vicioso malo, y al final se fue de la empresa.
Con el tiempo he aprendido que hay que enseñar antes de pedir, y hay que dar confianza con pequeñas tareas, pero de producto y con las que aprenda.
Un buen ejemplo ha sido recientemente, con una junior PM de mi equipo que apenas tenía experiencia, pero a la que poco a poco fui involucrando con el squad, haciendo que me acompañase en actividades como sesiones con tech o stakeholders y dándole primero pequeñas tareas como coordinación entre tech y operaciones, recogida de feedback de un grupo de stakeholders de negocio…y al poco tiempo se ha convertido en la PM de referencia de ese squad. ¡Ole!
¿Cómo organizamos al equipo?
Otra de las labores importantes de un líder de equipo de producto es definir la topología del equipo (normalmente junto con tech y diseño)... pero claro, ¿Dónde enseñan eso? Se ve que yo me perdí esa clase😂. Siempre me ha parecido de lo más complejo: foco en jobs to be done, en user personas, en pasos en el funnel…hay muchas opciones. Pero la peor seguro es la que yo escogí la primera vez que me tocó liderar un equipo de producto: era en una startup más o menos pequeña, pero con más de un PM.
Empezamos trabajando todos en todo (incluida yo que hacía rol mixto), modo “comuna”...
Fuimos creciendo como equipo, y ese modelo nos generaba mucha carga cognitiva tanto en tech como en producto y diseño (todos tenían que saber de todo el producto) y poco foco, y encima el CEO veía mucha gente trabajando “en lo mismo” y poco avance…frustración para todos.
Es importante dar un alcance y misión o enfoque concreto a cada persona del equipo, y que este se alinee con la estrategia de producto de la compañía.
Más adelante, en otra de las compañías en las que trabajé, llegó un momento en que éramos ya bastantes y necesitábamos dividir el trabajo, así que lo hicimos dividiendo al equipo en dos, según el tipo de usuario: usuarios internos (que usaban una herramienta propia para hacer su trabajo más eficiente) y usuarios externos (que usaban una app). Ambos tipos de usuario eran clave para el éxito de la compañía. Aunque había ciertos puntos de contacto entre ambos usuarios y productos (ej base de datos de assets), esto ayudó a enfocar al equipo y que la carga cognitiva fuese menor.
¿Me convierto en su escudo, o no?
Ya sabéis lo que dicen: cuando eres líder de un equipo de producto, tu producto es tu equipo. Así que una de tus métricas de éxito principales será que tu gente evolucione y avance en su carrera…incluso si eso supone que cambien de equipo o hasta que se marchen a otra empresa.
Esto supone dedicar muuuucho tiempo a entender a cada persona de tu equipo, sus intereses, fortalezas y debilidades, y ayudarle a mejorar y crear las relaciones relevantes con stakeholders. Eso no es siempre fácil, y puede requerir decisiones difíciles.
Por ejemplo, en uno de mis primeros trabajos como líder de equipo de producto, uno de los PMs de mi equipo (que llevaba en la empresa un tiempo antes de que yo llegase) había tenido una muy mala experiencia con un lanzamiento fallido del producto, y eso generó una pérdida de confianza con el CEO y el CTO. Al llegar yo intenté resolverlo haciendo de “escudo” y evitando que el PM se expusiese en lo posible...pero eso no hizo más que acrecentar el problema. Al final, el PM acabó dejando la compañía, pasando antes por varios meses de mal ambiente y frustración.
Quizá si hubiese afrontado el problema de cara desde el primer día no habría podido evitar que se fuese esa persona de mi equipo, pero habría sido antes y con menos frustración.
Un tiempo después, recientemente, me he encontrado con un problema similar, con una persona de mi equipo teniendo problemas para comunicarse con stakeholders complicados; esta vez, en vez de edulcorar el problema o hacer de escudo lo que he hecho es analizar las fortalezas y puntos de mejora de esta persona, y hemos planteado un cambio a otra área de producto más técnica, donde podrá aprovechar mejor sus fortalezas como su background técnico y tener menos exposición a los stakeholders complicados de antes.
Concluyendo…
Pues como resumen, ser líder de un equipo de producto tiene cosas muy satisfactorias (como ver crecer y tener éxito a tu equipo, tener un impacto mayor, y con suerte participar en las conversaciones top de estrategia de empresa), pero también tiene cosas menos bonitas (como tener que tener conversaciones difíciles con tu equipo o con stakeholders complicados, dejar de ser tú el que define el producto para que lo haga tu equipo, o tener que aprender a navegar en el mar de relaciones personales y jerarquías de la empresa).
Quizá no sea para todo el mundo, pero con un poco de empatía y aprendiendo de los errores se acaba disfrutando mucho.
¿Y vosotros, qué tortazos os habéis dado como jefes?¿y qué cambiaríais de vuestros jefes actuales?