«Product engineer» parece un nombre nuevo para un trabajo antiguo, pero la diferencia es real. Al ingeniero clásico se le mide por la producción: tickets cerrados y funciones entregadas según lo especificado. Al product engineer, por el resultado: ¿los usuarios completaron la acción? ¿Se movió la métrica? ¿Obtuvo el negocio aquello por lo que pagó? El código es el mismo; cambia la pregunta que uno se hace antes de escribirlo.
En la práctica, un product engineer actúa de otra manera. Pregunta «por qué» antes de «cómo»: qué problema resuelve esto, para quién y cómo sabremos si funcionó. Cuestiona una especificación cuando una versión más sencilla ofrece el mismo valor en un tercio del tiempo. Se preocupa por todo el recorrido del usuario —incluidos los estados de carga, error y vacío—, no solo por el caso ideal del diseño. Y tras el lanzamiento consulta analítica, tickets de soporte y grabaciones de sesiones, no únicamente la insignia verde de CI.
El puesto exige amplitud. No hace falta ser el mejor experto en bases de datos ni el mejor diseñador, pero sí sentirse cómodo en todo el recorrido: modelo de datos, API, UI, despliegue, analítica y ahora también IA. Por eso muchos ingenieros full-stack evolucionan hacia product engineers: cuando te ocupas de una función de principio a fin, no hay nadie a quien pasarle el «por qué». En mi caso, va desde el esquema de Postgres hasta la pantalla de Next.js y el evento que nos indica si alguien la usó.
Los product engineers entregan en pequeño y aprenden rápido. La primera versión es una acción medida en producción, detrás de un feature flag; no una plataforma que se lanzará dentro de seis meses. Saben qué aspectos pueden simplificarse (el panel de administración puede ser feo, un paso manual puede seguir siéndolo durante un mes) y cuáles no (pagos, permisos, integridad de los datos). Ese criterio ocupa buena parte del trabajo y solo se adquiere viviendo con las consecuencias de las propias decisiones.
También es un puesto de comunicación. El product engineer habla con los fundadores de riesgos, costes y plazos, no de frameworks. Con los diseñadores conversa sobre lo caro que es construir algo y propone alternativas menos costosas. Habla con usuarios siempre que puede. Y deja constancia de las decisiones: seis meses después, una nota breve sobre el motivo de una decisión suele valer más que el propio código.
Me llamo product engineer porque esa es la parte del trabajo que más me importa: no la pull request, sino el momento en que una persona real usa lo que construimos y funciona. Por eso prefiero las colaboraciones a largo plazo a las entregas en dos semanas: no puedes responsabilizarte de un resultado si no estás allí para verlo. Si necesitas un ingeniero que haga preguntas incómodas y luego entregue la respuesta, escríbeme.
Dale al próximo producto alguien que se quede.
¿Listo para empezar? Envíame un mensaje: puedo comenzar ahora y quedarme. Colaboraciones a largo plazo, no una entrega de dos semanas. Hablemos de tu proyecto, requisitos y la mejor forma de avanzar.