Cuando empecé a trabajar como desarrollador hace 25 años en Argentina, nos llamaban "Analistas Programadores". Arrancábamos con problemas, no con tickets. Nos sentábamos con los clientes, entendíamos qué se necesitaba, y entregábamos una solución. A veces eso significaba construir software. El trabajo era resolver problemas — el software era solo una de las formas de hacerlo.
Con los años, a medida que las organizaciones crecieron, nos especializamos. El stack se complejizó. Los frameworks se multiplicaron. Tuvimos backend, frontend, data, infra, etc. Cada capa demandaba su propio tooling, sus propios patrones, su propia carga mental. Así que dividimos la responsabilidad. El problema del cliente quedó distribuido entre equipos y roles.
¿Qué es un Product Engineer?
La descripción de puesto de Intercom lo captura bien:
"As a product engineer, you'll be taking ownership of real customer problems by building smart, efficient solutions to both back-end and front-end systems."
La frase clave es ownership de los problemas del cliente. No "implementar tickets". No "construir features". Resolver problemas. Gergely Orosz lo llama ser "product-minded" — ingenieros que sienten curiosidad por el negocio, no solo por el código. Preguntan "por qué" antes de preguntar "cómo".
El rol surgió de un vacío en cómo funcionan los equipos de producto. Luca Rossi describe bien el cambio: en el Scrum tradicional, los Product Owners manejaban el trabajo táctico — grooming del backlog, escribir user stories, gestionar tickets. Los Product Managers se suponía que manejaban la estrategia: visión de producto, posicionamiento de mercado, roadmap de largo plazo.
La mayoría de los equipos colapsaron estos dos en un solo rol de PM. Ese PM pasó a ser responsable de la estrategia y de escribir tickets. La estrategia fue la que sufrió.
Pero en los equipos de alto rendimiento, los ingenieros absorbieron la capa táctica. Los PMs pudieron enfocarse en la estrategia. Los ingenieros tomaron ownership de la ejecución desde el diseño hasta la entrega. La coordinación se simplificó. Los ciclos de feedback se acortaron.
Se nota en cómo trabajan con métricas. Los PMs se enfocan en lagging indicators — revenue, churn, MAUs. Son métricas de resultado. Importan, pero se mueven lento y responden a muchas variables a la vez. Los Product Engineers se enfocan en leading indicators — adopción de features, tasas de activación, time-to-value. Estos predicen resultados futuros. Son más difíciles de identificar pero más rápidos de mover, lo que significa que realmente podés iterar sobre ellos.
Facebook rastreaba cuántos usuarios agregaban al menos 7 amigos, y qué tan rápido. Ese era un leading indicator de engagement a largo plazo. Los ingenieros que eran dueños de esa métrica podían correr experimentos, hacer deploy, y ver resultados en días — no en trimestres.
Qué hacen los Product Engineers en la práctica
En la práctica, ser dueño de los problemas del cliente implica tres cosas:
Hacen rollouts controlados. Feature flags para liberar funcionalidades nuevas a un subconjunto de usuarios. Miden indicadores "leading" antes de afectar los "lagging". Le muestran una nueva UI al 10% de los usuarios, comparan engagement, y después deciden si hacen deploy para todos o iteran.
Corren experimentos. A/B tests cuando hay volumen. Feedback cualitativo cuando no. En B2B SaaS con pocos clientes, la significancia estadística es un lujo — medís adopción, mirás grabaciones de pantalla, y hablás con usuarios que probaron el feature pero se fueron.
Miden resultados. Post-lanzamiento, trackean indicadores adelantados y rezagados. Arman dashboards y alertas. Iteran basándose en datos en tiempo real, no en revisiones trimestrales.
Los mejores están expuestos al feedback del cliente directamente — no filtrado por un PM. En Clay, los ingenieros pasan el 20% de su tiempo con clientes. Cuando la persona que construyó el feature ve a los usuarios trabarse con él, lo arregla distinto a cuando lee sobre el problema en un ticket tres semanas después.
Volver al futuro
La cuestión es esta: no estamos inventando algo nuevo. Estamos redescubriendo algo que perdimos.
Esos "Analistas Programadores" de hace 25 años eran product engineers. Solo que no tenían un título rimbonbante. Se sentaban con los clientes, entendían los problemas, y construían soluciones. El código era un medio para un fin.
En algún punto del camino, nos sobre-especializamos. Creamos handoffs, silos, y reuniones de alineación interminables. Nos volvimos muy buenos construyendo cosas que nadie quería.
Ahora la IA está habilitando el regreso de las personas en forma de T/"goteo de pintura": profundas en un área, competentes en muchas. Cuando las herramientas pueden scaffoldear un componente React, debuggear una config de Terraform, o explicar un codebase desconocido, la carga cognitiva baja. Los ingenieros pueden trabajar en capas en las que no son expertos. La forma de T vuelve a ser viable, y con eso, ser dueños de problemas completos del cliente — no solo de una parte del stack.
Los mejores equipos con los que trabajo hoy están volviendo a lo básico — ingenieros que son dueños de resultados, no solo de outputs. En el extremo de este cambio están los indie hackers — solopreneurs que codean, hacen marketing, venden y dan soporte ellos solos. La IA está bajando la barrera cada día. Los Product Engineers son un paso en esa dirección: ingenieros que pueden ser dueños de problemas de punta a punta dentro de un equipo.
No estamos inventando un rol nuevo. Estamos recordando uno viejo.
