el handoff era el trabajo

por qué todo en el software se está doblando hacia el product engineering, y qué dice eso del trabajo que venimos haciendo desde siempre

las empresas de tecnología tienen un nombre nuevo para lo que su gente realmente hace todo el día.

ingenieros que dejaron de escribir la mayor parte de su propio código. product managers que dejaron de escribir documentos y empezaron a shippear. diseñadores que notaron que su aprobación se había convertido, sin que nadie lo pidiera, en un cuello de botella. todos en el mismo loop, iterando, hasta que cae algo que funciona.

le dicen product engineering.

no es un rol. es lo que queda después de que la ia disuelve los handoffs entre los roles viejos.

el cambio de nombre

vercel llama a esa mentalidad "code last": primero el producto funcionando, el código es aguas abajo de eso. lee robinson, que dirigió producto ahí antes de irse a cursor el año pasado, argumenta el punto sin vueltas: en una era ai-first el product engineering importa más, no menos. linear es conocida por construir casi todo su producto así, con equipos chicos que hablan directo con los clientes y son dueños del roadmap, y poca capa de pm tradicional en el medio. posthog practica una versión y lo escribe abiertamente. atlassian lo documenta en sus propios playbooks. el mismo movimiento, distinto vocabulario.

el patrón debajo de todos ellos es la resta. sacás las costuras entre disciplinas y la cosa se vuelve más rápida. así que la pregunta interesante no es qué es un product engineer. es por qué las costuras estaban ahí en primer lugar.

el handoff era el trabajo

acá viene la parte incómoda.

los artefactos sobre los que construimos carreras, el prd, la ceremonia de grooming, los story points, la aprobación de diseño, el spec hermosamente formateado, nunca fueron el trabajo. eran overhead de coordinación. infraestructura de handoff para un mundo donde mover una idea de una cabeza a otra era caro y lento.

marty cagan, en inspired, nos dijo que armáramos equipos de "misioneros, no mercenarios". teresa torres nos dio el trío de producto y el discovery continuo. los dos tenían razón, para un mundo donde producto, diseño e ingeniería eran oficios genuinamente separados que había que coser entre sí. el trío era un puente sobre una costura. buen puente. costura real.

la ia colapsa el costo del cruce. cuando una persona, o una persona más un modelo, puede sostener el problema, el diseño y la implementación en un solo movimiento continuo, el puente se convierte en un peaje. estás pagando por cruzar un hueco que ya no está.

entonces el flujo se invierte. no escribís el ticket y después construís. construís. le das el problema a dos modelos de frontera que discuten entre sí, iterás hasta que es real, y después el ticket se escribe solo, para atrás, como registro de lo que se hizo. el artefacto deja de ser una instrucción y se convierte en un recibo.

el contexto es el entregable

andrej karpathy lo dijo en 2023 y envejeció hasta volverse ley: "el lenguaje de programación nuevo más caliente es el inglés". su framing de software 3.0 ya es el agua en la que nadamos. programás el modelo en lenguaje natural, los prompts son programas, y la distancia entre la idea y el código corriendo se mide en minutos.

lo que significa que la habilidad escasa no es codear.

en el mundial pasado, chatgpt tenía semanas y no podía escribir una función. en el que acaba de terminar, el mismo tooling construyó un sdk entero en un fin de semana con el torneo de fondo. para 2030 lo que vale la pena saber hacer no es escribir el código. eso lo hace el modelo, saliendo de la conversación. es describir un problema de negocio y su solución con la precisión suficiente para construir a partir de ahí. la solución cae de la interacción. el problema es la parte que es tuya.

así que el entregable nunca fue el powerpoint. es el contexto. y el mejor contenedor para el contexto es un repo, no un documento de word: la conversación, los datos, las decisiones, versionados y shippeables, entregados al que construye después como un link que pega y sigue. todo portable. nada formateado para ser admirado.

decir, hacer

una salvedad al evangelio de "hablá con los clientes", porque es el punto exacto donde los equipos se engañan solos.

preguntarle a un cliente qué quiere vale casi nada. rob fitzpatrick escribió un libro entero, the mom test, sobre el hecho de que todos te mienten, con amabilidad: "las opiniones son inútiles", y cualquier cosa sobre el futuro es expresión de deseo. nielsen norman group lo dice hace treinta años en términos más crudos: "prestá atención a lo que los usuarios hacen, no a lo que dicen". lo autorreportado es frágil, y la gente en general no puede decirte qué quiere de verdad. en el momento en que describís tu idea, contaminaste la respuesta. esto es sesgo de confirmación con una sonrisa. salís a pescar validación y un humano educado te la entrega.

así que la señal nunca fue la opinión. es el comportamiento. lo que efectivamente hicieron, la última vez, con algo en juego. los datos de uso son simplemente la grabación de mayor fidelidad de ese comportamiento, recolectada mientras nadie está actuando para vos. es preferencia revelada en vez de preferencia declarada, y es por eso que meter el uso real y las llamadas reales de clientes en el loop le gana a otra ronda de entrevistas con stakeholders.

pero no te vayas tan al otro extremo que termines adorando el dashboard. los datos de uso traen sus propios dos cuchillos.

la ley de goodhart: "cuando una medida se convierte en objetivo, deja de ser una buena medida". apuntá un equipo a un número y va a mover el número, no la cosa que el número representaba. la fábrica soviética de clavos cumplió su meta por tonelada y despachó clavos que nadie podía usar.
el sesgo del sobreviviente: tu analytics solo contiene a la gente que sigue usando el producto. abraham wald resolvió esto blindando bombarderos en la guerra. el comando quería reforzar donde los aviones que volvían estaban acribillados; wald vio que esos eran los impactos sobrevivibles, y que los aviones baleados en el motor simplemente nunca volvían para ser contados. los que se fueron, los que rebotaron, los que nunca se registraron son tus aviones que faltan. optimizá solo sobre los que se quedaron y construís un producto cada vez más afilado para una sala que se achica.

los datos de uso además te dicen qué pasó, nunca por qué, y no hay datos de uso de algo que todavía no construiste. así que el movimiento no es analytics en vez de hablar. es comportamiento en vez de opinión, sacado de los dos lados: instrumentá todo, leé lo que la gente efectivamente hizo, y cuando hables con ellos, preguntales por su vida, no por tu idea.

un problema graeber

acá es donde deja de ser una historia de tooling.

david graeber, en bullshit jobs, definió la cosa como trabajo "tan inútil que hasta la persona que lo hace cree en secreto que no debería existir". no hablaba de nosotros (en realidad sí). pero sentate en suficientes ceremonias y el parecido se vuelve ruidoso. mucho de lo que hacemos, las reuniones que producen documentos que producen reuniones, no genera nada salvo que produzca algo. nosotros somos la fricción. construimos carreras enteras siendo excelentes en la fricción.

y esa es la trampa. la gente es genuinamente buena en eso. buena escribiendo tickets. buena groomeando un backlog. buena con un prd limpio. nada de eso importa como importaba, todos pueden sentir que no importa, y la respuesta a esa sensación es miedo, y la respuesta al miedo es más proceso. más documentos. una función de diseño que confunde su propio paso en la cadena con independencia, y defiende la costura, porque la costura es el trabajo.

la ley de conway dice que tus sistemas salen con la forma de tu organigrama. el product engineering es la ley de conway corriendo al revés: colapsá el organigrama y la arquitectura se simplifica con él. dejás de necesitar siete personas para shippear lo que pueden dos. fred brooks nos dijo en the mythical man-month que sumarle gente a un proyecto atrasado lo atrasa más. la industria entera está por fin en posición de actuar sobre eso, y en general está titubeando.

qué hacer mañana

la división no es ia versus personas. es personas que usan ia versus personas que no. un desarrollador que no quiere ya es irrelevante. una persona de producto que no quiera entender esto es la siguiente.

así que el movimiento no es mejores documentos. es enseñarle a la gente a pensar distinto:

premiá al que construye el prototipo, no al que escribe el spec más lindo
ponele una terminal adelante a tus product managers y dejalos correr research sobre el sitio en producción mientras están en la llamada
tratá cada conversación con un cliente como una fuente de datos y canalizala a algún lugar que un modelo pueda leer, y dejá que el corpus te diga qué construir
dejá de pedir permiso. para esto, el costo de pedir perdón en su lugar es más o menos cero

el product engineering no es un título para salir a contratar. es lo que pasa cuando dejás de pagar el peaje. las disciplinas no desaparecen. el oficio de un pensador de producto de verdad, de un ingeniero de verdad, importa más que nunca. lo que desaparece es el espacio entre ellos: el handoff, la ceremonia, la fricción que confundimos con el trabajo.

todo esto solo se sostiene si shippeás.

fuentes

la filosofía "code last" de vercel, articulada por lee robinson (entonces líder de producto de vercel, hoy en cursor)
posthog y linear sobre equipos de product engineering de cara al cliente que operan con poca estructura de pm tradicional
marty cagan, inspired, 2ª ed. (2017), "misioneros, no mercenarios"
teresa torres, continuous discovery habits (2021), el trío de producto y el discovery continuo
andrej karpathy, "the hottest new programming language is english" (tweet, 2023) y la keynote de software 3.0 (yc ai startup school, junio 2025)
rob fitzpatrick, the mom test (2013)
jakob nielsen y nielsen norman group, "first rule of usability? don't listen to users"
la ley de goodhart (charles goodhart, 1975; marilyn strathern, 1997)
abraham wald sobre el sesgo del sobreviviente (statistical research group, segunda guerra mundial)
paul samuelson (1938) sobre preferencia revelada vs declarada
david graeber, bullshit jobs: a theory (2018)
melvin conway, la ley de conway (1968)
fred brooks, the mythical man-month (1975)