El rol del Product Manager

Una de las preguntas que más recurrentemente me hacen mis amigos, familia y novia es: “Pero Pablo, ¿tú que haces exactamente en tu trabajo?”

Para personas alejadas de la creación de productos digitales a veces es complicado explicar los roles necesarios en la construcción de los mismos porque todo lo que hacemos es intangible, es software.

Por otro lado, no todas las personas del mundillo comprenden correctamente el rol que desempeño debido a que en según que empresas no existe la cultura necesaria y en otras el puesto ha derivado en algo totalmente diferente por distintas circunstancias.

Comencé mi carrera como data engineer, para pasar a trabajar como data scientist para terminar en el actual rol en el que trabajo, product manager. Muchos pasos laterales hasta encontrar la posición en la que más disfruto.

El rol de product manager a diferencia del resto de roles en la creación de software no es algo que se pueda aprender en las escuelas o universidades, no existe formación reglada para ser product manager y es por ello que el rol no está tan claramente delimitado e identificado como otros.

A día de hoy la única manera de llegar a serlo es dando un paso lateral en tu carrera (ya sea técnico, diseño o negocio…) y emprender el aprendizaje de todas las habilidades multidisciplinarias que se necesitan.

¿Qué es un Product Manager?

Dentro de un equipo que desarrolla productos digitales, un product manager es el encargado de identificar aquellas oportunidades que permiten producir un valor añadido a tu producto e ir a por ellas. Suena muy abstracto, lo sé. Típica definición de un vende humos en una organización, sin embargo creo que es un rol crucial en un equipo de desarrollo de productos digitales y un rol que no está muy entendido por la comunidad.

Es un rol transversal que tiene como objetivo escuchar y entender al cliente y/o usuario, al negocio y a la tecnología. Un rol que pese a su título de manager no es jefe de nadie, si no parte de un equipo multidisciplinar. Un rol que debe ser siempre capaz de responder las preguntas más cruciales sobre los 3 ejes de usuario, negocio y tecnología, por ejemplo:

• ¿Cuál es la arquitectura tecnológica de nuestro producto y dónde tenemos nuestros cuellos de botella? ¿Esto escala a las necesidades futuras que tengamos?
• ¿Qué está haciendo nuestra competencia? ¿A qué segmento de usuarios nos deberíamos enfocar? ¿Cuales son los usuario de más valor?
• ¿Cuál es la experiencia que estamos ofreciendo a nuestros usuarios? ¿Dónde están los pain points? ¿Dónde perdemos a nuestros usuarios?

Con toda la información que todos los equipos nos proporcionan debemos identificar cuales son los problemas más importantes a resolver en el producto y sobretodo el por qué. El objetivo es hacer entender a los equipos de desarrollo y tecnología así como a los stakeholders de negocio o diseño por qué se debe hacer algo y cuál es la consecuencia o cambio de comportamiento de los usuarios/clientes esperado.

No es un jefe de proyecto

En proyectos de ingeniería no relacionados con el software existe la figura del jefe de proyecto que tiene como objetivo manejar los tiempos y saber cuando estarán las entregas para optimizar la carga de trabajo entre equipos y hacer que todas las piezas encajen cuando se fabriquen entre sí como es debido en tiempo y forma. De esta concepción de jefe de proyecto se ha creado en proyectos de software una figura similar también denominado jefe de proyecto.

Este jefe de proyecto es el encargado de saber el cuándo. Cuándo ciertos componentes software estarán listos una vez se conocen las especificaciones de los mismos y asegurar que encajarán con el resto de componentes del proyecto así como de organizar la logística para que todo se ejecute de manera correcta.

No obstante, es importante diferenciar entre el rol de product manager y el del project manager. De hecho, en equipos grandes pueden convivir un product manager y un project manager.

Es cierto que todo product manager necesita de ciertas dotes de jefe de proyecto pero no es su objetivo principal, su objetivo es entender qué se debe construir y sobretodo el por qué debe construirse y que problema se resuelve con ello asegurando que toda la organización empuja en la misma dirección.

Un rol que solo se preocupe del cuando y de la logística es un jefe de proyecto. Un rol que se preocupe de entender qué se debe construir, y sobretodo el porqué, y alineé a toda la organización es un product manager.

Ni un Product Owner

De la misma manera, en entornos agile existe el concepto de product owner que a veces se utiliza para denominar a los product manager, sin embargo, ocurre lo mismo que con los project managers. Product owner es un rol que se juega en los frameworks agile para desarrollo de software, un rol que se encarga de definir y organizar las historias de usuario y de comunicarse con el equipo de desarrollo.

Un product owner es también un product manager si dedica su esfuerzo a entender qué se debe desarrollar en el siguiente sprint y por qué, asistiendo a investigaciones con usuarios, entendiendo el modelo de negocio en el que se opera, adelantándose a la competencia y comprendiendo las limitaciones tecnológicas con las que se debe avanzar.

Sin todo esto, el rol de product owner no deja de ser un rol dedicado a responder únicamente sobre el cuando, un rol sobre un framework de trabajo, sin un conocimiento profundo del porqué.

No es un proxy

Mi compañero Jorge Munuera, un crack, se refiere como proxies a los product managers que se dedican a hablar con todos los stakeholders, preguntarles que necesitan y hacer una lista de la compra con la que tener un backlog lleno de funcionalidades. Algo que un buen product manger no debe de hacer.

Un product manager debe hablar con todos los implicados pero debe hacer el ejercicio de entender sus problemas y comprender qué puntos de fricción tienen con el producto o por qué no lo utilizan tanto como nos gustaría. Es decir, entender porqués.

De nada sirve simplemente reunirse con todos los stakeholders y apuntar una lista de las nuevas funcionalidades que te solicitan. En tal caso, el product manager solo actúa de proxy entre un equipo y otro, un puente que simplemente conecta (y que a veces incluye retardos en las comunicaciones) pero que no aporta valor y que no imprime una dirección en base a lo aprendido con otros stakeholders. Un buen product manager no es un proxy, debe ser un modelo inteligente que recibe inputs en crudo y devuelve insights.

Y en vuestras empresas y equipos de desarrollo de software… ¿Existe un rol claramente identificado de product manager?