Construir software dejó de ser el problema. Un equipo con la infraestructura de IA ya montada saca en semanas lo que antes le costaba trimestres, y lo pone en producción sin que eso se considere una hazaña. El cuello de botella se movió a otro sitio: acertar con qué merece construirse, y conseguir que alguien lo acabe usando.
Álvaro Jordà, Product Owner en Mango, lo mide así en su propio equipo: lo que antes llevaba cuatro o cinco meses ahora sale en una semana, ya funcionando en producción. Ese desplazamiento es el que explica por qué aparece un perfil nuevo, el product engineer, y por qué el criterio para decidir vale ahora más que la capacidad de ejecutar.
TL;DR. Un product engineer decide qué construir y lo construye, de la hipótesis al resultado medido. El rol aparece porque la IA abarató la ejecución y dejó el coste real en dos sitios que no se automatizan: elegir bien el problema y lograr la adopción. Cuatro sesgos empujan a construir de más, y cuatro prácticas los corrigen. Ojo con el término: en español, ingeniería de producto nombra también la fabricación industrial, que no es de lo que va esto.
¿Qué hace un product engineer y de qué responde?
Un product engineer es un perfil técnico que lleva un proyecto de software desde la hipótesis hasta el resultado medido: decide qué construir, lo construye y comprueba si se usa. La pregunta que gobierna su trabajo cambia de sitio. Deja de ser si algo se puede hacer y pasa a ser si merece la pena hacerlo.
Conviene resolver una ambigüedad antes de seguir. En español, ingeniería de producto nombra también el diseño y la industrialización de un producto físico: materiales, moldes, tolerancias de fabricación, series de producción. Es una disciplina distinta, con décadas de recorrido, y es la que Google devuelve por defecto cuando se busca el término en castellano. Este artículo no habla de eso. Habla del perfil de software que absorbe decisión de producto y ejecución técnica en la misma persona.
La diferencia práctica está en el alcance de la responsabilidad. Un perfil técnico clásico recibe un problema ya acotado por alguien y responde de la calidad de la solución, lo que significa que puede hacer un trabajo impecable sobre una decisión equivocada y salir del proyecto sin una sola mancha en su historial. Un product engineer responde también de que el problema estuviera bien elegido. Ahí está todo.
¿Por qué aparece este perfil ahora?
Porque el coste de construir cayó y dejó al descubierto lo que siempre fue caro. Los equipos montan primero la infraestructura de IA: contexto, documentación, agentes que ejecutan. Con eso resuelto, la distancia entre una idea y algo que funciona en producción se mide en días.
El coste nuevo no se ve en el calendario. Con muchos frentes abiertos a la vez casi nadie se detiene a entender qué hay que resolver de verdad, y el equipo acaba dedicando sus mejores horas a revisar texto y código escritos por una máquina en lugar de a discutir si esa pieza tenía que existir. Se ejecuta más y se piensa menos. El resultado es un catálogo de cosas construidas que nadie pidió.
A escala de mercado, ese hueco ya está medido. BCG encontró que el 75% de las empresas había probado IA y solo el 25% había visto resultados reales, la brecha entre el piloto y la producción que se conoce como implementation gap (BCG, enero 2025). La lectura habitual de ese dato lo atribuye a falta de capacidad técnica, como si el problema fuera que a las empresas les faltan manos o herramientas para llevar un modelo a producción, cuando la experiencia de quien está dentro apunta a una causa bastante menos halagadora: se construyó rápido lo que no había que construir, y después nadie se ocupó de que alguien lo usara.
Dónde está el coste cuando construir es barato
Los dos puntos que la ejecución acelerada no resuelve, y que siguen decidiendo el resultado:
- Elegir el problema. Ninguna herramienta te dice si lo que vas a construir merece existir. Esa decisión se toma antes de abrir el editor.
- Conseguir la adopción. Desarrollar más rápido se puede. Que un equipo cambie de costumbres lleva su tiempo, y ese tiempo no se comprime con más capacidad de cómputo.
¿En qué se diferencia de un software engineer y de un product manager?
El product engineer no es un híbrido a medias entre los otros dos. Cubre el recorrido completo de una apuesta, y eso reordena de quién es cada decisión. La tabla lo separa por responsabilidad, no por tareas.
| Dimensión | Product manager | Software engineer | Product engineer |
|---|---|---|---|
| Pregunta que gobierna su trabajo | ¿Qué necesita el usuario? | ¿Cómo lo construyo bien? | ¿Merece la pena construirlo? |
| Dónde empieza su responsabilidad | En el problema y la prioridad | En el problema ya acotado | En la hipótesis sin validar |
| Dónde acaba | En la definición y el seguimiento | En la solución entregada y estable | En el uso real medido |
| Riesgo propio del rol | Definir sin poder ejecutar | Ejecutar bien lo que no valía | Decidir solo, sin nadie que rebata |
Ese último riesgo es el precio de concentrar decisión y ejecución. Cuando una sola persona lleva el proyecto de la hipótesis al resultado se ahorra todas las reuniones de traspaso, todas las especificaciones intermedias y toda la pérdida de contexto entre quien decide y quien construye, y a cambio se queda sin nadie que le diga que la idea era mala. Gana velocidad. Pierde contraste. Y el contraste es exactamente lo que evita construir de más, así que un equipo que adopta este perfil sin reponer por otra vía la discusión que antes ocurría en el traspaso entre producto e ingeniería no ha ganado eficiencia, solo ha eliminado testigos. Quien venga del reparto clásico lo ve antes comparándolo con lo que hace un product manager y con la capa de decisión que asume un CPO o director de producto.
¿Por qué los equipos construyen de más?
Por cuatro sesgos que operan antes de escribir la primera línea, y que la velocidad de la IA amplifica en vez de corregir.
- Falsa autosuficiencia. Decides tú solo, sin que nadie te rebata. Con un agente que ejecuta cualquier cosa que le pidas sin objetar nunca, desaparece ese rozamiento incómodo que antes te obligaba a explicarle la idea a un compañero y a descubrir a mitad de frase que no se sostenía.
- Espejismo del experto. Te saltas al especialista porque la herramienta ya te da una respuesta razonable. Pierdes su criterio, que era justo lo que distinguía una respuesta razonable de una correcta.
- Trampa del tachado. Disfrutas tachando tareas más que preguntándote si valían la pena. Es un sesgo antiguo y bastante humano, pero cuando la ejecución va a velocidad de máquina se vuelve caro de un modo nuevo, porque el número de cosas que puedes tachar sin cuestionar ninguna crece sin techo.
- Síndrome del creador. Cancelas la suscripción a una herramienta convencido de que harás una mejor, y acabas valorando lo tuyo muy por encima de lo que vale por el simple hecho de haberlo montado tú, que es el efecto IKEA aplicado al software. Validar es preguntar a los usuarios. No a tu entorno cercano.
¿Cómo se decide qué merece construirse?
Con prácticas que devuelven a propósito el rozamiento que la velocidad eliminó. Ninguna es nueva y ninguna es cara. Lo que cambió es que antes te las podías saltar sin consecuencias visibles, porque el propio calendario de desarrollo actuaba de filtro y te obligaba a pensar mientras esperabas, y ahora ese filtro ya no existe.
Antes de empezar a construir
- PR de producto. Alguien de fuera revisa tu enfoque antes de que escribas nada. Es el equivalente a la revisión de código, aplicado a la decisión en lugar de a la implementación.
- Premortem. Lista todo lo que puede salir mal asumiendo que ya salió mal. Es más fácil imaginar el fallo de algo que das por fracasado que anticiparlo desde el optimismo.
Mientras y después
- Iterar. Casi nada sale bien a la primera. Lo bueno aparece cuando lo trabajas después, así que la primera versión no es el entregable, es el material de partida.
- Validar con usuarios reales. Enséñales también lo que ya existe en el mercado, a ver si de verdad prefieren lo tuyo. Sin la alternativa delante, la validación mide entusiasmo, no preferencia.
El cuarto punto es el que más se salta y el que más señal da. Preguntar a un usuario si le gusta lo que has hecho devuelve casi siempre un sí educado, porque nadie disfruta diciéndole a la cara a quien ha construido algo que no piensa volver a abrirlo, y ese sí se interpreta como validación cuando solo era cortesía. Poner tu opción al lado de la que ya usa devuelve otra cosa. Devuelve una decisión.
¿Por qué la adopción decide el resultado, y no la velocidad?
Porque un sistema que nadie usa vale lo mismo que uno que no existe, y encima cuesta mantenerlo. Tratar la adopción como un requisito del proyecto, y no como una consecuencia agradable que llegará sola si el producto es bueno, es el cambio de encuadre que separa a los equipos que ven resultados de los que acumulan pilotos correctos y desiertos.
De ahí se sigue una idea menos cómoda. Tirar lo que no funciona es la mejor decisión disponible. Cuando construir era caro cancelar significaba perder meses de inversión, y los proyectos se sostenían por inercia hasta que alguien con suficiente autoridad se atrevía a enterrarlos; cuando construir es barato, lo caro es exactamente lo contrario, mantener vivo algo que nadie abre.
"Crear va a ser muy fácil, pero que lo que crees tenga un impacto va a ser muy difícil."
Álvaro Jordà, Product Owner, Mango
Ese es también el límite práctico de delegar en agentes. Un agente ejecuta, prueba variantes y sostiene el ritmo. Lo que no hace es decidir qué merece existir ni convencer a nadie de que cambie de costumbres, y no lo hace porque las dos cosas dependen de leer un contexto que no está escrito en ninguna parte: quién se juega algo en ese cambio, qué intentó ya el equipo y le salió mal, y de cuánta paciencia queda. El criterio humano es lo que hace que algo se use de verdad. No conviene sustituirlo por un agente.
Leído así, el product engineer se entiende mejor como un paquete de skills que como una casilla nueva en el organigrama: criterio de producto, ejecución técnica y lectura de adopción en la misma persona. Es el movimiento de fondo del mercado, de roles a skills, con los agentes absorbiendo la parte mecánica y el criterio quedándose exactamente donde estaba.
Preguntas frecuentes sobre el product engineer
- ¿Un product engineer es lo mismo que un ingeniero de producto industrial?
No, y la confusión es habitual en español. La ingeniería de producto clásica diseña e industrializa productos físicos: materiales, moldes, tolerancias, series de fabricación. El product engineer del que habla este artículo trabaja en software y su rasgo distintivo es asumir la decisión de qué construir, además de construirlo. Son dos disciplinas sin relación entre sí más allá del nombre.
- ¿Qué diferencia a un product engineer de un software engineer?
El alcance de la responsabilidad. Un software engineer recibe un problema acotado y responde de la calidad de la solución. Un product engineer responde también de que el problema estuviera bien elegido y de que el resultado se use, así que su trabajo empieza en una hipótesis sin validar y acaba en el uso real medido.
- ¿Sustituye este perfil al product manager?
No en general. Concentrar decisión y ejecución gana velocidad y pierde contraste, y ese contraste es lo que evita construir de más. En equipos donde el product engineer opera solo, las prácticas de revisión externa dejan de ser opcionales: alguien de fuera tiene que rebatir el enfoque antes de que empiece a construirse.
- ¿Qué señales piden que un equipo incorpore este perfil?
Dos, sobre todo. Que el equipo entregue rápido y aun así acumule funcionalidades con poco uso, señal de que el problema se elige mal. Y que existan pilotos de IA que funcionan pero no llegan a producción, señal de que nadie se ocupó de la adopción. Ninguna de las dos se arregla añadiendo más capacidad de ejecución.
La conclusión es incómoda para cualquiera que haya medido su trabajo en velocidad de entrega. Cuando ejecutar deja de ser el límite, el trabajo valioso se desplaza a las dos decisiones que siguen siendo humanas: qué construir y cómo lograr que se use. Los cuatro sesgos explican por qué esas dos decisiones se toman mal incluso en equipos competentes y con buenas intenciones, y las cuatro prácticas son el precio, bastante barato, de tomarlas bien.
En Shakers operamos como infraestructura de talento certificado en skills IA: certificamos la skill contra trabajo real antes de que nadie entre en un equipo, precisamente porque el criterio es la parte que no se delega. Si el cuello de botella que reconoces es el de los pilotos que funcionan y no llegan a producción, cómo montar el equipo de agentes IA baja a la composición concreta del equipo. Y si prefieres discutirlo sobre tu caso, habla con un experto de Shakers.