Si sos developer, ya conocés a un Product Manager. Es la persona que te trae los requerimientos, que aparece en la daily, que a veces te frena una feature que ya tenías casi lista y otras veces te apura por una que no entendés. Lo conocés por cómo te afecta el día, pero probablemente no por lo que hace cuando no está hablando con vos. Y ahí es donde está casi todo el trabajo.
Hay una confusión muy común que conviene sacar de encima primero. Un Product Manager no es el jefe del equipo, no es el dueño del producto en sentido de propiedad, y tampoco es el que más sabe de todo. Es la persona responsable de que el equipo construya lo correcto. No lo que se pidió, no lo que es más fácil, sino lo que mueve la aguja para el usuario y para el negocio al mismo tiempo.
Vamos a desarmar eso en piezas concretas.
Decide qué se construye y, sobre todo, qué no
La parte visible del rol es la priorización. El PM tiene más ideas, pedidos y problemas de los que el equipo puede resolver. Su trabajo es elegir. Y elegir bien significa decir que no la mayor parte del tiempo.
Esto es más difícil de lo que parece desde afuera. Cada cosa que entra al roadmap deja afuera a otra. Cada feature que se prioriza tiene a alguien adentro de la empresa que la pidió y que va a estar molesto si no aparece. El PM vive negociando esas tensiones y defendiendo por qué el equipo va a trabajar en esto y no en aquello.
Cuando un PM prioriza bien, el equipo de ingeniería casi no lo nota, porque trabaja en cosas que tienen sentido. Cuando prioriza mal, ustedes lo sienten en el cuerpo: features que nadie usa, retrabajos, cambios de rumbo a mitad de sprint.
Entiende el problema antes que la solución
La parte invisible, y la más valiosa, es el discovery. Antes de que llegue cualquier ticket a ustedes, alguien tuvo que entender qué problema vale la pena resolver. Ese alguien es el PM.
Eso significa hablar con usuarios, mirar datos de uso, entender el negocio, revisar qué hace la competencia y armar una hipótesis de qué construir. La mayoría de las ideas que un PM evalúa nunca llegan al equipo de desarrollo, porque las descarta antes. Esa pila de cosas descartadas es parte del trabajo, aunque ustedes nunca la vean.
Acá hay algo importante para un dev. Cuando un PM hace bien esta parte, el equipo construye menos y logra más. Cuando la hace mal, el equipo construye mucho y mueve poco. La productividad del equipo de ingeniería depende muchísimo de la calidad del discovery que hizo el PM antes.
Traduce entre mundos que no se hablan
Un PM pasa el día entre conversaciones que usan idiomas distintos. Con ingeniería habla de factibilidad y complejidad. Con diseño habla de experiencia y flujos. Con negocio habla de revenue y costos. Con management habla de objetivos y resultados.
Su trabajo es que esas conversaciones lleguen a una sola dirección. Toma lo que el negocio necesita, lo que el usuario quiere y lo que el equipo puede construir, y los hace converger en algo que tenga sentido para los tres. Buena parte del día de un PM es esto: alinear gente que naturalmente no estaría alineada.
Cierra el círculo con métricas
Lanzar no es terminar. Un buen PM define, antes de construir, cómo va a saber si lo que lanzó funcionó. Qué número tendría que moverse, en cuánto tiempo, y qué haría si no se mueve.
Esto es lo que separa a un PM que construye features de uno que construye producto. El primero entrega y pasa a la siguiente. El segundo mira qué pasó, aprende y ajusta. Para un dev acostumbrado a pensar en sistemas, esta parte del rol suele ser la más atractiva, porque es donde todo se vuelve medible.
Por qué esto te importa aunque no quieras ser PM
Entender qué hace un PM te hace mejor developer hoy. Vas a poder cuestionar mejor un requerimiento, vas a entender por qué se prioriza lo que se prioriza, y vas a tener conversaciones más útiles con tu PM en vez de recibir tickets en silencio.
Y si estás pensando en moverte hacia Producto, este es el primer paso: dejar de ver el rol como una caja negra que te trae trabajo y empezar a ver las decisiones que hay detrás.
Dónde estás parado vos
Si te pica la curiosidad de saber qué tan cerca estás de pensar como un Product Manager, en ProductPrepa tenés una autoevaluación gratuita que mide tus habilidades en los dominios clave del trabajo de producto. En cinco minutos te muestra dónde tu cabeza de dev ya juega a favor y qué te conviene desarrollar.
Hacé la autoevaluación y descubrí tu punto de partida.