Tengo dos libros que me formaron en producto: el Inspired, de Marty Cagan, y el Gestão de Produtos, de Joca Torres, con quien además tuve la suerte de hacer mentoría. Por años esos dos fueron mi mapa: qué es un PM, qué es un product designer, qué es un ingeniero, quién hace qué. Cada papel con un contorno claro.
En el último año, viendo a mi equipo trabajar con IA en Prolog, empecé a sentir esos contornos deslizarse. No que los libros hayan quedado equivocados: es que la capa donde ocurre cada papel subió.
En el primer texto de la serie conté el malestar que me hizo empezar a reconstruir tech en Prolog, y en el segundo, qué es harness, la infra que hace que la IA rinda. Allá al final del primero prometí abrir una parte específica: cómo cambia el trabajo de cada cargo cuando la IA pasa a ser quien construye. Ese es el tema acá.
El trabajo no desaparece, sube una capa
La IA no está borrando el papel de cada profesión, está cambiando la capa donde ocurre.
La lectura fácil, la que vende susto, es “la IA va a sustituir el cargo X”, y no fue lo que vi pasar. Lo que vi fue el contenido del trabajo cambiar de lugar: lo que antes era hacer pasó a ser dirigir y criticar a quien hace.
El ingeniero, que escribía el código, ahora revisa lo que el agente escribió. El PM, que escribía la spec, ahora juzga el prototipo que salió de ella en horas. La persona es la misma, lo que cambió es el instrumento en su mano.
Cuando volví a Cagan y a Joca con eso en la cabeza, la ficha cayó de otra forma. Los dos describen, con cuidado, la ejecución de cada papel (la tarea concreta, el entregable, lo que sale de tus manos al final del día), y es exactamente eso lo que la IA está asumiendo. Lo que le queda al humano es la otra mitad: decidir qué merece ser construido, encontrar el agujero en lo que se construyó, tener el gusto para saber qué es bueno. El juicio, no la ejecución.
Entonces voy a hacer lo que hice conmigo: tomar la definición de cada papel según los libros, y preguntar qué se come la IA de ella y qué sobra (y se vuelve más caro).
El equipo de tres, según los libros
Antes de separar papel por papel, vale recordar cómo los libros arman el equipo. Joca es directo: un producto de éxito necesita ser deseable, viable y posible de construir, y eso define “las tres funciones esenciales para crear un producto de éxito” (cap. 2): diseñador de UX, gestión de productos y desarrollador, el trío que él llama core team. Cagan, en Inspired, describe los mismos papeles en el capítulo de apertura, “Key Roles and Responsibilities”.
Los dos insisten en un punto que voy a retomar al final: no es una relación de jefe y subordinado. En palabras de Joca, “ingeniería de productos, gestión de productos y UX son un equipo, no hay relación de subordinación entre ninguno de esos grupos” (cap. 31), y en Cagan la misma idea aparece como PM e ingeniería siendo “pares, ninguna posición está subordinada a la otra” (cap. 5, en mi traducción). Y cuando la IA entra en medio del trío, es esa colaboración la que más cambia de forma.
Tabla: cada profesión en tech sube una capa. Ingeniería pasa de productor de código a crítico de agente; producto, de spec writer a arquitecto de iteración; diseño, de productor de pantallas a director de experimento; calidad, de testeador a constructor de validación.
El papel de cada profesión en tech
El mismo papel, una capa arriba
la ejecución pasa al agente · el juicio queda contigo: decidir, criticar, tener gusto
Ingeniero: de productor de código a crítico de agente
Para ingeniería, lo que cuenta dejó de ser cuánto código produces: pasó a ser qué tan bien criticas lo que el agente produjo.
La definición de Joca es tan clara que duele releerla ahora: “ingeniería de productos es responsable de desarrollar el producto y mantenerlo operando”, y, más adelante, la ingeniería “construye el producto” (cap. 31). Construir era el verbo. Cagan lo completa por el otro lado, hablando de la relación con producto: “el product manager es responsable de definir la solución, pero el equipo de ingeniería sabe mejor qué es posible, y es él quien al final entrega esa solución” (cap. 5, en mi traducción). Definir de un lado, entregar del otro.
Ahora la entrega de la primera versión es del agente. Lo que no cambió, y se volvió más caro, es todo lo que Cagan pegaba al ingeniero como fuente de innovación: “los ingenieros saben mejor que nadie qué es posible” (cap. 5). Saber qué es posible, encontrar el agujero en el plan que el agente propuso, ver el trade-off de performance o seguridad que él no ve, decidir cuándo intervenir y cuándo dejar correr. Eso pesa más cada mes. Memoria de sintaxis, boilerplate a mano, barrer Stack Overflow, volumen de código como trofeo personal: eso pesa menos.
En Prolog lo dije con todas las letras al equipo: nadie va a ser evaluado por línea de código. Quien siempre fue bueno en “encontrar el agujero” se vuelve más valioso, y quien se identificaba con “producir mucho código rápido” va a tener que recalibrar dónde invierte. Y esto no disminuye la ingeniería. Su valor siempre estuvo más en saber qué sirve que en producir rápido, y ahora eso solo se vuelve explícito.
PM: de spec-writer a arquitecto de iteración
El PM lo siente cuando el prototipo se vuelve barato: su trabajo deja de ser escribir el documento y pasa a ser elegir qué idea merece el tiempo del equipo.
Cagan es categórico sobre el corazón del trabajo: “alguien necesita descubrir cuál es la solución, el producto, incluyendo las funcionalidades, la experiencia del usuario y los criterios de lanzamiento. Ese alguien es el product manager, y esa tarea es el corazón de su trabajo” (cap. 1, en mi traducción). Joca da el contorno amplio: gestión de productos es “la función responsable de todos los aspectos de un producto de software, durante todo el ciclo de vida de ese producto, desde su concepción hasta el fin de su vida” (cap. 2).
Fíjate que en los dos la palabra clave es descubrir, no especificar. Cagan tiene un capítulo entero solo para defender que el trabajo es discovery, no “requisitos”: el software tiene dos etapas, “descubrir qué construir (el producto correcto) y construir (el producto de la forma correcta). La primera está dominada por el discovery, la segunda es ejecución” (cap. 12, en mi traducción). Ese siempre fue su mensaje, y la IA solo lo volvió literal.
Porque cuando el build colapsa de semanas a horas, el cuello de botella deja de ser construir y pasa a ser decidir qué vale la pena construir. La spec larga revisada en comité, el planning trimestral cerrado, el status report como entregable, el control de tráfico entre ingeniería y diseño: todo eso pesa menos. Lo que pesa más es discovery rápido (prototipar para entender, no specar para construir), curaduría de hipótesis (qué idea merece el tiempo del equipo) y decidir qué no hacer, con más frecuencia. Algunas empresas ya están llamando a ese PM “Editor” o “Arquitecto”. No es menos PM: es otro PM, quien cura, quien decide con gusto, quien da dirección. Lo que era central en el antiguo, escribir la spec, es lo que quedó liviano.
Product designer: de productor de pantallas a director de experimento
En el diseño, la unidad de trabajo sale de la pantalla y va al sistema que produce pantallas, y el product designer pasa a elegir qué variación sobrevive.
En Joca, la definición de UX es entender para diseñar: “UX es el responsable de entender a fondo al usuario y el problema que se desea resolver para ese usuario” (cap. 32). Y el flujo que él describe es el ritual que todos conocen: prototipo de papel, después wireframe, después “el diseñador visual de UX empieza a poner color y forma en esas pantallas”. Cagan corta el papel en dos con la misma lógica: el interaction designer “desarrolla un entendimiento profundo de los usuarios y crea las tareas, la navegación y el flujo”, mapea eso en wireframes y se lo pasa al visual designer, que “le pone carne al wireframe” (cap. 4, en mi traducción).
Ese encadenamiento, entender, esbozar, refinar pantalla por pantalla, es justo lo que la IA acorta. La unidad de trabajo deja de ser “la pantalla” y pasa a ser “el sistema que genera pantallas”. Rehacer la misma variación cinco veces en Figma, especificar componente por componente, el handoff pixel-perfect como rito: pesa menos. Prototipar a velocidad de iteración (varias opciones en paralelo, descarta las malas), definir el sistema visual en vez de cada pantalla aislada, y la crítica visual rápida (ver a la IA proponer algo y notar de un vistazo que está mal antes de que el usuario lo note): pesa más.
Y acá Cagan dice, allá en 2008, algo que protege al product designer de creer que se volvió apretador de botones: su trabajo nunca fue solo dibujar bonito. “Un buen producto exige una buena experiencia del usuario. Y una buena experiencia exige la colaboración cercana entre producto y diseño” (cap. 4, en mi traducción). La IA genera la variación, y quien decide cuál de ellas merece llegar al usuario sigue siendo gente con gusto.
QA: de testeador a constructor de validación
QA es el caso más interesante, porque es el papel que los libros casi no aislaron, y es el que la IA mueve más.
Fíjate: en el trío de Joca (diseñador, PM, desarrollador) y en los papeles de Cagan, la calidad aparece diluida, como responsabilidad del equipo, no como silla propia con un método propio. Por mucho tiempo eso tuvo sentido, pero ahora ya no lo tiene, y la razón es simple: si el agente construye rápido y la validación sigue manual, solo produjiste deuda técnica a alta velocidad.
Entonces QA deja de ser quien corre el caso de test a mano y pasa a ser quien diseña el testing harness, el sistema que testea el sistema: configurar IA para escribir test para el código que otra IA escribió, detectar regresión antes que el usuario, pensar dónde tiende a aparecer el defecto. En la práctica, se volvió una pregunta operativa que adoptamos: cada bug que se escapa se vuelve “¿cómo detectamos esto automáticamente la próxima vez?”. Test manual exhaustivo de flujo conocido, regresión corrida a mano en cada release, QA como portón único antes de subir: pesa menos. Validación como sistema, no como pase de pelota al final de la línea.
Es el papel que más sube de capa justamente porque era el menos definido. Donde los libros no marcaron un contorno, la IA está dibujando uno nuevo.
La constante: lo que los libros ya decían que importaba más
Hay una cosa que no cambia, y estaba escondida a plena vista en los dos libros: lo que ellos ponen como la característica más importante es exactamente lo que la IA no hace.
Joca abre el capítulo de las características de un buen PM sin rodeos: “la más importante de todas es, sin duda alguna, la empatía” (cap. 4). No es tabla de función ni entregable: es la capacidad de ponerse en el lugar de quien usa. Cagan, por su lado, gasta el libro entero defendiendo discovery, taste y juicio por encima del proceso, y los dos, cada uno a su manera, estaban diciendo lo mismo: lo que separa al bueno del mediocre nunca fue la parte mecánica del trabajo.
Y la parte mecánica es justamente la que se fue al agente. Escribir la spec, diseñar la pantalla, escribir el código, correr el test. Lo que quedó, y se volvió más caro, es el sentido crítico, taste (saber qué es bueno), juicio bajo ambigüedad, curiosidad, cuidado con quien usa lo que haces. Resumiendo en la frase que usé con el equipo: el contenido del trabajo cambia, la persona que lo hace, no.
Diagrama en dos capas. Arriba, lo que se quedó con nosotros y se volvió más caro: taste (saber qué es bueno), juicio bajo ambigüedad, empatía con quien usa, decidir qué no hacer, lo que los libros ya decían que importaba más. El trabajo subió una capa. Abajo, lo que se fue al agente: escribir la spec, diseñar la pantalla, escribir el código, correr el test manual.
Se quedó con nosotros · y se volvió más caro
lo que los libros ya decían que importaba más
el trabajo subió una capa
Se fue al agente
Lo que esto va a cobrar (sin clichés)
No quiero cerrar esto demasiado bonito, porque no lo es. Este cambio cobra cosas concretas, y ninguna es cómoda.
La primera es dejar atrás hábitos de una década. Quien lleva cinco, diez años en la forma antigua carga patrones que ayudaron a llegar hasta acá, y son justamente esos patrones los que pesan para cambiar. No hay atajo, y el malestar es esperado.
Después, criticar a la IA tanto como crear con ella: aceptar la sugerencia que apareció no es trabajo; encontrar el agujero en el plan que ella propuso, sí. Lo que siempre fue caro (pensamiento crítico, taste, juicio) se vuelve más caro.
También está el errar como equipo, no como persona. No despedimos a un ingeniero por un bug en producción, mejoramos el review, y cuando la IA se equivoca es el harness lo que fortalecemos. Bug del agente es proceso, no persona: un compromiso, no un eslogan.
Y la más incómoda: aceptar que algunas funciones cambian más que otras. Eso genera incomodidad en quien cambió poco hasta ahora, y no se puede fingir que está todo igual. Lo que sí se puede hacer es traerlo a una conversación abierta.
Y para no sonar como quien llegó al destino: Prolog todavía está al comienzo de esto. Seguimos en el AI-assisted, con ganancia de 10 a 20%, no en el AI-first de 5x o 10x. Estoy contando una dirección que estamos construyendo, con aciertos y con errores, no una victoria.
Lo que me llevo de esto
Los libros no quedaron equivocados. Describían la ejecución de cada papel con una precisión que solo entendí de verdad ahora (escribir la spec, diseñar la pantalla, construir el producto, correr el test), y esa ejecución ahora es del agente. Y lo que le quedó al humano es la otra parte, juzgar, criticar, tener gusto, cuidar de quien usa, que, volviendo a Cagan y a Joca, es lo que ellos decían que importaba más desde la primera página.
Tal vez sea esa la parte buena: el trabajo que la IA sacó de nuestra mano es el que era más repetitivo, y lo que dejó es lo que siempre fue más difícil, y más interesante. Voy a seguir contando cómo va.
Fuentes
- Marty Cagan, Inspired: How to Create Products Customers Love (1ª edición, 2008). Las definiciones de papel vienen de los capítulos 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) y 12 (Product Discovery). Las traducciones de los pasajes son mías.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Las definiciones vienen de los capítulos 2 (¿Qué es la gestión de productos de software?), 4 (Principales características de un gestor de productos), 31 (Ingeniería de productos y gestión de productos) y 32 (UX y gestión de productos).
- La lectura sobre el papel subir una capa apoya la serie: OpenAI, Harness Engineering, y Peter Pang, CTO de CREAO.