Hay un momento en la carrera de muchos developers donde la pregunta deja de ser "cómo lo construyo" y empieza a ser "por qué estamos construyendo esto". Si llegaste hasta acá, probablemente ya te lo preguntaste más de una vez. Te tocó implementar una feature que sabías que nadie iba a usar, o discutir con un PM una decisión que no terminabas de entender, y algo te dijo que del otro lado del problema había un lugar donde querías estar.
Pasar de desarrollo a Producto es uno de los movimientos de carrera más naturales que existen, y al mismo tiempo uno de los peor acompañados. La mayoría de las guías asumen que venís de cero, cuando en realidad venís con una ventaja enorme que casi nadie te ayuda a capitalizar.
Vamos por partes. Primero lo que ya tenés. Después lo que te falta.
Lo que ya sabés y no estás valorando
Como dev entendés cómo se construye el software por dentro. Eso significa que cuando un PM dice "esto debería ser fácil", vos sabés cuándo es mentira. Sabés estimar complejidad, sabés dónde se esconde la deuda técnica y sabés que una decisión de arquitectura tomada hoy condiciona lo que se puede hacer dentro de seis meses.
Esa intuición técnica es algo que un PM que viene de negocio tarda años en construir, y muchos nunca la construyen del todo. Vos ya la tenés. El problema es que la tenés en un idioma que todavía no sabés traducir a decisiones de producto.
También sabés trabajar con sistemas. Pensás en estados, en flujos, en casos borde. Cuando aprendas a aplicar esa misma cabeza a un funnel de usuarios o a un modelo de negocio, vas a tener una herramienta que pocos PMs manejan con esa profundidad.
Lo que te falta y nadie te dijo
Acá viene la parte incómoda. El trabajo de Producto no se evalúa por cuánto construís sino por qué decidís construir y qué pasa después de que lo lanzaste. Y eso requiere músculos que en desarrollo casi no se entrenan.
El primero es discovery. Como dev recibías un ticket y lo resolvías. Como PM tu trabajo empieza mucho antes del ticket: hablar con usuarios, entender el problema antes de saltar a la solución, distinguir lo que la gente dice que quiere de lo que realmente la haría cambiar de comportamiento. Esto se aprende haciéndolo, y se aprende mal si lo hacés solo.
El segundo es priorización con información incompleta. En desarrollo hay una respuesta correcta la mayoría del tiempo. En Producto casi nunca la hay. Vas a tener que elegir entre tres cosas buenas sabiendo que dos se van a quedar afuera, y vas a tener que defender esa elección sin tener datos que la confirmen del todo.
El tercero es comunicación con personas que no piensan como vos. Vas a pasar el día alineando a diseño, a negocio, a ventas y a tu propio equipo de ingeniería. La habilidad ya no es escribir código limpio sino lograr que diez personas con incentivos distintos se muevan en la misma dirección.
El cuarto es pensar en métricas. No el dashboard que mira el management, sino la pregunta de fondo: cómo sé si lo que lancé funcionó. Qué número se tendría que mover y por qué. Esto conecta directo con tu cabeza de sistemas, pero requiere que aprendas a leer comportamiento de usuarios, no logs.
Por dónde empezar sin renunciar a tu laburo
No necesitás cambiar de puesto para empezar a entrenar esto. Necesitás cambiar qué mirás dentro del puesto que ya tenés.
Empezá metiéndote en las conversaciones de discovery aunque no te inviten. Pedile a tu PM estar en una entrevista con usuarios. Cuando te llegue un requerimiento, preguntá qué problema resuelve antes de estimarlo. Andá a las reuniones de roadmap y escuchá cómo se toman las decisiones, qué se prioriza y qué se descarta.
Lo segundo es construir algo propio, por chico que sea. Un proyecto donde vos seas dev y PM al mismo tiempo te obliga a tomar todas las decisiones que normalmente toma otro. Vas a sentir en el cuerpo lo difícil que es decidir qué no construir.
Y lo tercero es tener una lectura honesta de dónde estás parado hoy. Es difícil cerrar una brecha que no sabés que tenés. Muchos devs que quieren pasar a Producto subestiman lo fuerte que están en pensamiento de sistemas y sobreestiman lo cerca que están en discovery y comunicación. Saber esto antes de aplicar a un puesto te ahorra meses de frustración.
El primer paso concreto
Si querés una foto clara de qué tenés sólido y qué te falta para moverte a Producto, en ProductPrepa armamos una autoevaluación gratuita que mide tu nivel en los dominios que importan en el trabajo de producto. Toma cinco minutos y te devuelve dónde están tus fortalezas y tus áreas de mejora.
Para un dev que está pensando el salto, es la forma más rápida de dejar de adivinar y empezar a tener un plan. Hacé la autoevaluación y mirá tu punto de partida.