Mi primer trabajo, hace dos décadas, fue construir un software de administración agropecuaria en VB y SQL Server, para una empresa argentina que todavía vende sistemas de gestión para acopios, casas consignatarias de hacienda y frigoríficos. Uno pensaría que un product manager me entregaba un documento de requerimientos, que luego se repartía en tareas para backenders y frontenders. Bueno... no. El trabajo se parecía más a lo que hoy se llama un FDE (Forward Deployed Engineer) o un ingeniero product-minded. Iba a los clientes. Me sentaba con ellos. Fui consultor incluso antes que programador. El rol se llamaba "Analista Programador".
Con los años, a medida que el software creció en organizaciones más grandes y complejas, todo se especializó. El stack se complicó. Los frameworks se multiplicaron. Backend, frontend, data, infra, ML, etc. Cada capa exige su propio tooling, sus propios patrones, su propia carga mental. Y como subproducto de eso, dividimos el ownership. El problema del cliente quedó repartido entre equipos y roles.
El regreso del Product Engineer
Me gusta la descripción de puesto de un Product Engineer de Intercom:
"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 parte a resaltar es el ownership de los problemas del cliente. No "implementar tickets". Tampoco "construir features". Resolver problemas. Gergely Orosz lo llama ser "product-minded": ingenieros con curiosidad por el negocio, con visión más allá del código. Gente a la que le importan los "por qué" antes que los "cómo".
El rol surgió (¿resurgió?) de un vacío en cómo funcionan los equipos de producto. Luca Rossi lo describe bien: en el Scrum tradicional, los Product Owners manejaban lo táctico: grooming del backlog, escribir user stories, gestionar tickets. Y los Product Managers se suponía que manejaban la estrategia: visión de producto, posicionamiento de mercado, roadmap de largo plazo.
Si alcanza el presupuesto, claro. La mayoría de los equipos colapsan los dos en un solo rol de PM. Y ese PM es responsable de la estrategia y de escribir tickets. Como es fácil de imaginar, la parte de la estrategia es la que sufre.
Dos de mis mejores amigos y mi hermano son Product Managers. Gente extremadamente inteligente a la que vi empujada a convertirse en secretarios/niñeros glorificados de ingenieros de software.
Pero en los buenos equipos (¿high-performing?), donde los ingenieros absorben la capa táctica, los PMs sí pueden enfocarse en la estrategia. En esos equipos los ingenieros se hacen dueños de la ejecución, desde el diseño hasta el delivery. La coordinación es más simple, los ciclos de feedback más cortos... es muy difícil explicarle a alguien que nunca trabajó en un equipo así lo divertido y gratificante que es.
Y cuando eso pasa, las neuronas se invierten en una capa de abstracción más arriba: las métricas. Los PMs se enfocan en lagging indicators: revenue, churn, MAUs. Las que se llaman métricas de resultado. Importan un montón, pero se mueven lento y responden a muchas variables a la vez. Los Product Engineers por su parte se enfocan en leading indicators: adopción de features, tasas de activación, time-to-value. Predicen resultados futuros. Son más difíciles de identificar pero se pueden iterar rápido.
Es vox populi que Facebook trackeaba cuántos usuarios agregaban al menos 7 amigos, y qué tan rápido. Era un leading indicator de engagement a largo plazo. Los ingenieros dueños de esa métrica podían correr experimentos, shippear cambios, y ver resultados en días.
Qué hacen los Product Engineers en la práctica
Básicamente, no consideran un feature terminado hasta que movió (o falló en mover) una métrica. That's it.
Claro que es más fácil decirlo que hacerlo. Para empezar, exige elegir una métrica de antemano. Cualquiera que haya intentado implementar algo tipo OKRs en una organización sabe lo doloroso que es. Requiere una mentalidad diametralmente opuesta a la de codear. Pero se acerca más a lo que se supone que es el trabajo de un ingeniero, ¿no?
El día a día es un loop. Un feature nuevo sale detrás de un feature flag, a una porción de los usuarios. Si la métrica se mueve, se abre a más. Si no, se itera o se mata. Con suficiente tráfico se hacen A/B tests. La mayoría de los equipos con los que trabajo no disfrutan de ese lujo, así que hacen la versión a pulmón: miran grabaciones de sesión, revisan adopción cuenta por cuenta, y llaman al usuario que probó el feature y no volvió más.
A medida que los equipos mejoran, la definición de terminado pasa de "mergeado" a "deployado" a "medido".
Y hablan con los clientes. Directamente, sin un PM haciendo de intérprete. Hay equipos que definen una proporción: los customer success engineers pasan el 80% del tiempo con clientes y el 20% codeando, y los software engineers hacen exactamente al revés. Ayuda a que los ingenieros tengan skin in the game. Cuando ven en vivo a un cliente peleándose con el feature que desarrollaron, se toman arreglarlo bastante a pecho. No se parece en nada a leer un ticket tres semanas después.
Volver al futuro
Ya sé, ya sé, ya sé. Esta versión moderna del analista programador se ve mucho más sofisticada, automatizada, eficiente, que la de hace dos décadas.
Pero no nos engañemos: la mentalidad detrás no es nueva.
Leo seguido hilos de Reddit donde alguien dice algo como "ni intentes el camino del ingeniero fullstack, es un sinsentido". Hay una generación entera que se alejó tanto de los problemas del cliente que ya no puede reconocer ese trabajo como parte del oficio que eligió para su vida profesional.
La sobre-especialización creó handoffs, silos, reuniones de alineación interminables. Nos volvimos muy buenos construyendo cosas que nadie quiere.
Reconozco que cualquier argumento a favor de la AI en este clima de despidos y trabajos perdidos es, como mínimo, polémico, pero no puedo estar más contento con el regreso de la gente en forma de T/"paint drip".
Cuando las herramientas pueden armar el esqueleto de un componente React, debuggear una config de Terraform o explicar un codebase ajeno en horas, esa baja en la carga cognitiva les permite a los mejores ingenieros expandirse por todo el stack. Ser dueño de los problemas del cliente de punta a punta vuelve a ser viable.
Durante años miré a los "indie hackers" (y tuve mis propios side projects) como una versión perdida de lo que era un ingeniero de software. Hoy los mejores equipos con los que trabajo están volviendo al origen: ser dueños de los resultados.
