10 Mitos del Product Manager
Actualmente estoy leyendo el libro de Cracking the PM Interview y quisiera compartir algunas reflexiones. En particular, quería resumir este capítulo en el que hablan de los mitos del PM. Como el rol de Product Manager aún no está bien definido, hay un montón de confusiones sobre su trabajo:
Mito 1. Los Product Managers son Project Managers
Quizá algunos Product Managers tengan en su día a día una gran parte de Project Management, pero muchos no. Los Projects están más enfocados a timelines y coordinación. Aunque son responsables de agrupar los requerimientos del producto, no participan en identificarlos y definirlos.
Los Product Managers, por otro lado, son responsables de identificar problemas y oportunidades, eligiendo cuales quieren atacar apoyándose en el equipo de diseñadores y desarrolladores para conseguir buenas soluciones.
Mito 2. Los Product Managers pertenecen al área de Marketing
A pesar de que algunas compañías tengan el puesto Marketing Product Manager, el rol de Marketing Manager no se parece en nada al de Product Manager.
El primero se centra en atraer a los usuarios, el segundo en lo que pasa cuando el usuario llega/usa el producto. Mientras el departamento de marketing puede pedir a los Product Managers las funcionalidades que podrían ayudar al branding o al mensaje a transmitir, ellos no participan en el proceso de definición de esas funcionalidades ni trabajan con los desarrolladores para construirlas.
Mito 3. No puedes convertirte en Product Manager al acabar tus estudios
La palabra “Manager” hace que algunas personas piensen que necesitas tener un perfil más senior para ser Product Manager. Sin embargo, algunas compañías tech como Google, Microsoft, Facebook o Yahoo, contratan PMs que acaban de terminar la carrera por su gran pasión, energía y gran enfoque hacia el usuario. No es necesario tener un trabajo previo para ser Product Manager.
Mito 4. Los Product Managers solo escriben especificaciones
Igual que de los desarrolladores no se espera únicamente que entreguen código ni de los diseñadores un wireframe, para los Product Managers entregar los requisitos no es suficiente. Son responsables del éxito del producto; por lo que escribir una especificación puede ser una técnica para comunicar y avanzar con el proyecto, pero no tiene valor intrínseco. No solo deben expresarse a través de esta herramienta, sino asegurarse de que el equipo lo ha entendido e implementa las ideas.
Mito 5. Los Product Manager solo convocan reuniones
Algunas personas piensan que el trabajo del PM consiste en reunir a los stakeholders en una habitación para que tomen decisiones. Pero los buenos Product Managers no son mediadores pasivos, sino que investigan y aportan en las reuniones su punto de vista basado en datos.
Es necesario que los PMs se reúnan con los stakeholders y comprendan sus opiniones y prioridades, para luego tomar perspectiva y presentar una estrategia que satisfaga a las partes interesadas. Pero en cualquier reunión que no sea con el equipo, el Product Manager debe representar los intereses de las personas que no están en la sala.
Mito 6. Los Product Managers deben construir exactamente lo que los usuarios piden.
Hacer customer research y escuchar las peticiones de los usuarios aporta mucho valor, pero no es suficiente. El Product Manager debe mirar más allá de lo que dicen para descubrir las necesidades más ocultas.
Mito 7. Los Product Manager establecen los deadlines
Como PM, podemos decirle al equipo qué hay que construir, pero los desarrolladores nos dirán cómo lo harán y cuánto tardará. Si el timeline que nos dan es muy largo no podemos pretender que lo hagan más rápido, porque no funcionará.
En su lugar, si tenemos deadlines externos que debemos cumplir, debemos pensar en compensaciones y negociaciones. Necesitaremos partir las entregas o encontrar una manera de ampliar el equipo. A veces, puede ser de utilidad reducir la carga de trabajo de los ingenieros, como no incluirles en reuniones innecesarias o que no hagan entrevistas a futuros candidatos.
Además, no seguir las estimaciones de los desarrolladores y prometer a otros stakeholders que se hará en menos tiempo es una manera de perder la confianza y deteriorar la relación con el equipo.
Mito 8. Los Product Managers son jefes
Algunos quieren vender el rol de PM como “CEO del producto o del equipo”. Pero en realidad, los Product Managers no tienen autoridad sobre el equipo. Ninguno está obligado a hacer lo que dice el Product Manager.
En su lugar, los PMs influencian, esforzándose por su confianza y la credibilidad, comunicándose con claridad, recopilando datos e investigando, siendo persuasivo, liderando al equipo….
Los equipos siguen al Product Manager cuando están convencidos de que sus objetivos están alineados y que el PM les ayudará a lograrlos, sin que les diga lo que deben hacer. Los diseñadores serán los dueños del diseño del producto, y los desarrolladores poseen la implementación. El Product Manager debe entender las decisiones de cada miembro y el impacto que tendrá, así como estar dispuesto a hablar si no se alinean. Pero nunca controlar esas decisiones.
Mito 9. Las ideas son más importantes que la ejecución
Las personas que entran en el mundo del Product Management por primera vez, pueden pensar que tener buenas ideas es la parte más importante del trabajo. Sin embargo, es la ejecución lo que cuenta.
En el equipo pueden surgir ideas geniales, pero como PM es importante saber hacerlas tangibles y accionables. El Product Manager necesita pensar en los corner cases y descubrir los pasos para convertir esa idea en realidad. A menudo esto implica meterse en el barro: encontrar servidores para ejecutar su código, convencer otros equipos para priorizar el trabajo del que depende y utilizar el producto consistentemente para encontrar y eliminar todas las asperezas.
Mito 10. El Product Manager puede decir “Ese no es mi trabajo”
Si bien la mayoría de los roles del equipo están claramente definidos, los PMs no tienen un papel claro. Cuando eres Product Manager, tu trabajo consiste en hacer aquello que no está cubierto por el resto del equipo. Eres responsable del éxito o fracaso del producto, por lo que si hay algo que nadie quiere hacer, necesitas encontrar la manera de que se haga, incluso si eso supone hacerlo por ti mismo.
