Desde hace varios meses, los desarrolladores entrevistan a los clientes sin pasar por el Product Manager.

Y hace tres días abrí mi primera pull request en nuestro producto principal.

Estas dos frases resumen mejor que cualquier análisis lo que está ocurriendo en los equipos de producto con la IA. Los desarrolladores suben hacia el problema, el cliente y el ownership del producto. Los PM bajan hacia el prototipo, el código y a veces la producción.

Podrían verse como dos anécdotas sueltas. Yo creo lo contrario: es el principio de una inversión más profunda. Los roles históricos del product management, del desarrollo y del diseño pierden nitidez. Las fronteras se mueven. Pero, al contrario de lo que podría parecer, eso no significa que todo el mundo vaya a hacerlo todo, ni que las responsabilidades vayan a desaparecer.

El tema de fondo no es que la IA haga a los equipos "más productivos". El tema de fondo es que aumenta mucho la capacidad de producir. Y cuando la capacidad de producir aumenta, el cuello de botella cambia de sitio.

Antes, la restricción solía ser: "¿Cuánto podemos construir?"

Mañana pasa a ser más bien: "¿Qué hay que construir? ¿Por qué? ¿Para quién? ¿En qué orden? ¿Con qué riesgos?"

Es ese desplazamiento el que difumina los roles.

Cuando los desarrolladores producen más, el PM se convierte en el cuello de botella

Uno de los detonantes del asunto es bastante simple: con la IA, los desarrolladores producen más rápido.

No se trata solo de escribir unas líneas antes. Producen más opciones, más variantes, más prototipos, más herramientas pequeñas, más iniciativas. Un desarrollador que ya era autónomo puede acabar yendo tres, cuatro o seis veces más rápido en ciertas tareas. Un equipo con una capacidad de delivery limitada puede generar de golpe muchas más cosas que probar, arbitrar, revisar y priorizar.

El problema es que la capacidad de decidir no aumenta automáticamente al mismo ritmo.

Si todo tiene que seguir pasando por el PM, es él quien se convierte enseguida en el nuevo punto de saturación del sistema. Ya no se trata solo de escribir specs o de llevar un backlog. La carga se desplaza hacia la priorización, la coherencia del producto, la validación de la señal del cliente, el arbitraje de mercado, el impacto en el usuario, la estrategia y la gestión de las consecuencias.

Una organización puede creer entonces que ha resuelto su problema de velocidad porque los desarrolladores producen más. En realidad, solo ha movido el atasco de sitio.

Hay tres respuestas posibles.

La primera consiste en contratar más PM. A veces hace falta, pero no siempre es la respuesta correcta. Si el modelo sigue igual, lo único que se añade es una capa más de arbitraje.

La segunda consiste en automatizar parte del trabajo operativo del PM: documentación, release notes, materiales de lanzamiento, análisis iniciales, traducciones, síntesis, vídeos de demostración, capturas de pantalla, elementos de PR. Eso libera tiempo, pero no basta para resolver el fondo del asunto.

La tercera consiste en redistribuir parte del ownership del producto hacia quienes construyen. Ahí es donde los roles empiezan a difuminarse de verdad.

Acelerar el código no basta

Un error sería creer que la IA transforma la organización solo porque acelera el desarrollo.

La velocidad local no crea valor automáticamente. Incluso puede crear más desorden si el workflow completo no cambia. Un equipo puede generar más código, más prototipos, más documentos y más tickets, y a la vez tomar peores decisiones.

Hay que repensar el flujo entero: idea, discovery, especificación, prototipado, desarrollo, pruebas, seguridad, lanzamiento, comunicación, soporte y aprendizaje.

Si añadimos agentes de IA sobre un proceso que no cambia, solo corremos el riesgo de mover los cuellos de botella. El código acelera y entonces se atasca el producto. El producto acelera y entonces se atasca el diseño. El diseño acelera y entonces se atasca la validación técnica. La validación acelera y entonces el go-to-market o el soporte ya no dan abasto.

Así que la cuestión no es solo: "¿Cómo hacemos que los desarrolladores vayan más rápido?"

La cuestión es: "¿Cómo hacemos que el sistema entero sea capaz de absorber esa velocidad sin perder calidad, coherencia ni responsabilidad?"

Por eso los roles nuevos no se reducen a "PM que programa" o "desarrollador que hace producto". Una parte de las necesidades nuevas tiene que ver con orquestar los workflows, evaluar las salidas de la IA, mantener la memoria del producto, cuidar la calidad de las decisiones, la legibilidad de los repos y la capacidad de dar a los agentes un contexto fiable.

Lo que la IA vuelve corriente en el product management

Durante mucho tiempo, algunos PM se diferenciaban por sensibilidades o competencias bastante distintas.

Unos escribían muy bien. Otros dominaban el dato. Otros el benchmark, el marketing de producto, la discovery, el diseño de experiencia o la coordinación del delivery. Esas diferencias no desaparecen del todo. Pero parte de su valor diferencial baja.

Con la IA, muchas capacidades se vuelven más accesibles:

• escribir una spec correcta;
• producir un primer análisis de datos;
• hacer un benchmark;
• redactar una release note;
• hacer una maqueta aceptable;
• sintetizar entrevistas;
• producir una primera versión de un recorrido;
• convertir una necesidad en prototipo.

Esas competencias no se vuelven inútiles. Un PM sigue teniendo que saber juzgar una spec, cuestionar un análisis, leer una maqueta, entender una síntesis de entrevistas o valorar un prototipo. Pero producir esos artefactos por primera vez se vuelve menos escaso.

Antes, un PM podía diferenciarse mucho porque sabía producir rápido una buena spec, un benchmark claro, una síntesis aprovechable o una primera maqueta. Mañana eso será más bien el nivel mínimo.

Eso deja expuestos a los PM cuya fuerza estaba sobre todo en la ejecución intermedia. Quienes coordinaban, redactaban, administraban, hacían seguimiento, reformulaban y producían artefactos correctos sin aportar un criterio de producto firme corren el riesgo de perder parte de su valor.

El oficio de producto no desaparece. Pero su nivel mínimo sube.

Lo que sigue siendo difícil: el criterio de producto

Cuando producir se vuelve fácil, elegir qué producir se vuelve más crítico.

Ahí es donde el oficio de PM conserva su valor. No en la capacidad de generar más artefactos, sino en la de elegir, arbitrar y asumir las consecuencias.

Lo que sigue siendo difícil:

• elegir el problema adecuado;
• entender un mercado;
• leer la señal real que hay detrás de lo que piden los clientes;
• arbitrar entre el corto plazo y la estrategia;
• decir que no;
• sostener una visión coherente;
• crear alineamiento;
• asumir las consecuencias de producto, de negocio, técnicas y humanas de una decisión.

El PM estratégico aumentado se parece cada vez más a una especie de CPO en pequeño. Está menos en la administración del delivery, menos en la producción mecánica de entregables, y más en los arbitrajes donde ninguna opción es perfecta.

El rol se vuelve especialmente importante cuando no hay buena solución. Solo dos o tres malas opciones, con costes distintos, riesgos distintos, efectos políticos distintos, impactos distintos en el cliente. En esos momentos, la IA puede ayudar a analizar. Asumir, no.

El PM aumentado no es, por tanto, un PM que va más rápido. Es un PM que tiene que juzgar mejor.

La diferenciación se desplaza hacia la señal del cliente

Si todo el mundo puede construir más rápido, construir rápido deja de ser ventaja suficiente.

Producir código en bruto pasa a ser en parte una commodity. No el software. No la ingeniería. No la arquitectura, la seguridad ni la mantenibilidad. Pero la capacidad de sacar rápido una primera versión se vuelve menos escasa.

La diferenciación real se desplaza entonces hacia lo que los competidores no pueden generar sin más:

• la calidad de la señal del cliente;
• los datos propios;
• el conocimiento del negocio;
• la distribución;
• la confianza;
• las restricciones operativas;
• los aprendizajes acumulados;
• la capacidad de interpretar bien lo que los clientes piden en realidad.

Un prototipo rápido solo vale si pone a prueba una señal real. Si no, lo único que hace es acelerar una mala dirección.

La pregunta estratégica pasa a ser esta: ¿sobre qué ventaja propia construimos?

Un equipo aumentado por la IA puede producir muchísimo. Pero si no lee mejor su mercado, si no entiende mejor a sus usuarios, si no sabe distinguir una señal fuerte de un ruido bien formulado, solo producirá más rápido cosas mediocres.

Es una razón más por la que el PM no desaparece. El rol se desplaza hacia la calidad con la que se lee la realidad.

Los desarrolladores suben hacia el producto

Los desarrolladores nunca han sido simples ejecutantes.

Una especificación completa es una ficción. Ni siquiera una buena spec describe todos los comportamientos esperados de un producto. Siempre quedan zonas mudas: casos límite, mensajes de error, comportamientos implícitos, reglas de seguridad, tiempos de expiración, prioridades invisibles, microinteracciones, decisiones de fallback.

En esas zonas, los desarrolladores ya toman decisiones de producto.

La IA hace esa realidad más visible. Si un agente escribe parte del código, el humano tiene que explicitar el comportamiento esperado, arbitrar los edge cases, definir los criterios de aceptación, verificar el resultado. Las microdecisiones que la implementación absorbía en silencio se vuelven más visibles y, por tanto, más importantes de acotar.

Es una de las razones por las que los desarrolladores suben hacia el producto. Hablan más con los clientes, entienden mejor los problemas, se hacen cargo de sus funcionalidades y toman decisiones locales más explícitas.

Pero hay un matiz importante: un desarrollador no se convierte en product engineer por usar un agente de código o por entregar más rápido.

Si no tiene acceso a los clientes, a los datos, al contexto de negocio y a los arbitrajes, solo corre el riesgo de convertirse en un operador de agentes de código. Más responsabilidades, más presión, pero no necesariamente más poder sobre el producto.

El product engineer de verdad no es solo un desarrollador rápido. Es alguien que se hace cargo de una parte del criterio de producto lo más cerca posible de la construcción.

Los PM bajan hacia la construcción

El movimiento inverso también existe.

Con la IA, un PM puede materializar una idea mucho más rápido que antes. Una maqueta, un prototipo, una herramienta interna, un dashboard, una traducción, un cambio de interfaz, a veces incluso una PR acotada.

Eso cambia la naturaleza del trabajo.

Antes había que pasar a menudo por una secuencia larga: formular la necesidad, escribir la spec, hacer una maqueta, pedir una estimación, esperar un hueco, mandar desarrollar, probar, ajustar. Hoy, en ciertos temas, se pasa mucho más rápido de la intuición a un artefacto manipulable.

Y a veces ya no se trata solo de prototipar. En casos simples o bien acotados se puede programar algo casi real: un dashboard, una pantalla de solo lectura, una mejora de interfaz, una automatización interna, una traducción, un material de release.

Eso no quiere decir que el PM se convierta en desarrollador en el sentido clásico. Quiere decir que puede intervenir en zonas de construcción que antes quedaban fuera de su ámbito.

Aquí hay que distinguir varios niveles.

El PM o PO prototipador convierte una intención de negocio en prototipo o POC.

El Product Builder va más lejos: construye artefactos tangibles, herramientas internas, dashboards, primeras versiones, contribuciones acotadas.

El Product Engineer va más lejos todavía: puede hacerse cargo de una responsabilidad de producto hasta el entregable en producción. Y a ese rol se puede llegar por dos trayectorias. Un desarrollador que sube hacia el producto. O un perfil de producto lo bastante técnico que baja hacia la producción.

El criterio no es, por tanto, el oficio de origen. El criterio es el nivel de capacidad de acción.

¿La persona se queda en la maqueta? ¿Produce un prototipo? ¿Abre una PR? ¿Se hace cargo de un entregable que pueda llevarse a producción? ¿Entiende lo suficiente los riesgos como para hacer validar bien lo que produce?

Es ese continuo lo que resulta nuevo.

Los roles se difuminan, las responsabilidades permanecen

El riesgo sería concluir que, como los roles se difuminan, las responsabilidades se disuelven.

Yo pienso justo lo contrario.

Cuanto más se difuminan los roles, más hay que aclarar las responsabilidades.

Una decisión de producto sigue siendo una decisión de producto. Le corresponde a producto: visión, posicionamiento, coherencia, arbitrajes, grandes principios, lectura del mercado, señal del cliente.

Una decisión técnica sigue siendo una decisión técnica. Le corresponde a técnica: seguridad, rendimiento, escalabilidad, arquitectura, mantenibilidad, calidad de la plataforma.

Una decisión de experiencia sigue siendo una decisión de experiencia. Le corresponde a diseño o a front: design system, coherencia de uso, accesibilidad, nivel de exigencia de UX.

La organización que funciona no es aquella en la que cada cual hace de todo por su cuenta. Es aquella en la que cada cual puede intervenir más allá de su terreno inicial porque hay garantes que fijan los estándares, las salvaguardas y los límites.

Un PM puede abrir una PR. Pero esa PR se revisa, se acepta, se corrige o se rechaza.

Si se rechaza diez veces seguidas, eso dice algo. Quizá el PM aún no tenga nivel para ese tipo de contribución. Quizá el tema sea demasiado arriesgado. O quizá el equipo técnico aún no haya puesto las directrices, las herramientas o las salvaguardas que permiten a otros perfiles contribuir con seguridad.

La PR o la MR pasa a ser entonces un mecanismo de gobernanza. No solo una herramienta técnica.

Todo depende del par competencia / riesgo

La buena pregunta no es: "¿Puede un PM desplegar en producción?"

La buena pregunta es: "¿En qué ámbito, con qué competencia, qué riesgo y qué salvaguardas?"

Hace falta una gradación sencilla.

Riesgo bajo: traducciones, contenidos, dashboards, pantallas de solo lectura, herramientas internas no críticas.

Riesgo medio: pequeñas acciones de escritura, workflows internos, cambios de interfaz acotados.

Riesgo alto: pagos, permisos, seguridad, datos sensibles, lógica de negocio crítica, producto regulado, arquitectura.

Incluso en un producto regulado, no todo tiene el mismo nivel de riesgo. Un dashboard o una pantalla de consulta pueden ser bastante seguros si las reglas están claras y hay validación técnica. A la inversa, un producto aparentemente simple puede contener una zona muy sensible si toca los datos, los permisos o una decisión de negocio irreversible.

La analogía con un desarrollador junior resulta útil. A nadie se le dan las llaves del motor del producto el primer día. Se empieza por ámbitos sencillos y luego se va ampliando poco a poco.

El PM aumentado puede seguir la misma lógica: traducciones, solo lectura, dashboards, escrituras pequeñas y, más adelante, contribuciones más críticas si la competencia, el contexto y las salvaguardas acompañan.

La brecha entre perfiles de PM

No todos los PM podrán volverse builders o product engineers al mismo ritmo.

A corto plazo, los PM con bagaje técnico llevan ventaja. Saben leer un repo, entender un error, dialogar con un agente de código, interpretar lo que se ha generado, detectar ciertos absurdos, pedir una revisión técnica en el sitio adecuado.

Un PM sin esa cultura puede aprender, claro. Pero corre el riesgo de quedarse en la maqueta o en el prototipo superficial mientras no entienda lo suficiente lo que produce la IA.

La IA todavía es demasiado poco fiable como para ignorar por completo lo que pasa bajo el capó. Si no entiendes un mínimo los errores que salen, se hace difícil ir más allá de una maqueta fiable.

Eso no quiere decir que los perfiles no técnicos estén condenados. A medio o largo plazo puede ocurrir incluso lo contrario. Si los agentes se vuelven mucho más fiables, perfiles que vienen de la psicología, las letras, la filosofía, el diseño, la investigación o el negocio podrían tomar la delantera gracias a su capacidad de expresar con finura una realidad humana, social o de negocio.

Pero con las herramientas de hoy, la brecha existe.

Los PM que no quieran volverse builders probablemente tendrán que reforzarse mucho en otras dimensiones: estrategia, mercado, discovery, influencia, comprensión humana, calidad de expresión, capacidad de decir que no y de orientar a un equipo.

Los oficios nuevos no siempre son oficios

Se habla a menudo de "oficios nuevos". El término sirve, pero puede confundir.

No todos esos roles se convertirán en títulos de RR. HH. estabilizados. Algunos serán puestos. Otros seguirán siendo competencias repartidas por el equipo. Y otros los absorberán Product Ops, Diseño, Ingeniería o QA.

Lo importante no es el título. Es la responsabilidad.

¿Quién juzga?

¿Quién construye?

¿Quién garantiza?

¿Quién evalúa?

¿Quién mantiene la memoria?

¿Quién orquesta los workflows?

La IA hace visibles responsabilidades que a veces eran implícitas o secundarias: evaluar las salidas probabilísticas, mantener documentación que los agentes puedan aprovechar, sostener la memoria del producto, orquestar los workflows, cuidar la calidad del contexto, la legibilidad del repo, la claridad de los criterios de aceptación.

Estas necesidades no son periféricas. Se vuelven centrales en cuanto un equipo trabaja con agentes.

El PM no desaparece, el nivel mínimo sube

El product management no desaparece.

Pero el oficio se vuelve menos tolerante con los perfiles que vivían sobre todo de coordinar, redactar, hacer seguimiento y producir artefactos intermedios.

Mañana habrá menos sitio para el PM administrativo.

Habrá más sitio para dos tipos de perfil.

Por un lado, quienes saben construir lo bastante como para acelerar el aprendizaje del producto: prototipar, materializar, probar, contribuir y a veces llegar hasta un entregable real.

Por otro, quienes saben juzgar lo bastante bien como para orientar a un equipo capaz de construir mucho más rápido que antes: entender el mercado, leer la señal, arbitrar, decir que no, sostener una visión, proteger la coherencia y asumir las consecuencias.

Entre esos dos polos habrá muchas combinaciones. Pero el nivel mínimo va a subir.

La IA no elimina el product management. Obliga al oficio a volver a ser lo que siempre debió ser: una responsabilidad de creación, de criterio y de impacto.

Anexo: catálogo de los futuros roles de producto

Este anexo no pretende predecir los futuros títulos de LinkedIn. Describe más bien las zonas de responsabilidad que la IA vuelve visibles.

PM estratégico aumentado

PM que automatiza parte de la ejecución intermedia para centrarse en la visión, los arbitrajes, la coherencia del producto y la lectura de la señal del cliente.

Su valor está en elegir los problemas adecuados, decidir cuando ninguna opción es perfecta, proteger el posicionamiento y mantener el alineamiento entre mercado, estrategia, usuarios y ejecución.

Su riesgo es que se le confunda con un PM simplemente más productivo, o que se convierta en el nuevo cuello de botella si toda la decisión sigue subiendo hasta él.

PM o PO prototipador

Perfil de producto capaz de convertir rápido una intención de negocio en prototipo, POC, herramienta interna o primer recorrido testable con ayuda de la IA.

Su valor está en reducir la ambigüedad entre negocio, producto y tecnología.

Su riesgo es quedarse en la maqueta o esquivar demasiado pronto a los desarrolladores en temas que piden una reflexión técnica de verdad.

Product Builder

Perfil de producto capaz de convertir directamente una idea en artefacto testable, prototipo funcional, herramienta interna o contribución acotada.

Su valor está en reducir el tiempo entre la intuición y la demostración.

Su riesgo es confundir un prototipo que funciona con un producto mantenible.

Product Engineer

Perfil capaz de hacerse cargo de una responsabilidad de producto hasta el entregable en producción: comprensión del usuario, elección de la solución, construcción, entrega, medición e impacto.

Puede venir de un background de desarrollo o de un background de producto lo bastante técnico.

Su valor está en redistribuir parte del criterio de producto lo más cerca posible de la construcción y en reducir la distancia entre idea, prototipo y producción.

Su riesgo es doble: creer que un desarrollador se vuelve product engineer sin acceso real a los clientes, a los datos, al contexto de negocio y a los arbitrajes; o creer que un PM puede volverse product engineer sin capacidad de entender, hacer validar y mantener un entregable en producción.

Product Systems Designer

Rol que diseña los sistemas de producto alimentados por la IA: feedback, discovery, generación de specs, enrutado de los insights, documentación viva y workflows de release.

Su valor está en mejorar los mecanismos que permiten al equipo tomar mejores decisiones de forma continua.

Su riesgo es volverse una función demasiado abstracta si no se conecta con los workflows reales del equipo.

AI Product Evaluator

Rol encargado de evaluar las salidas de la IA dentro del producto: calidad, alucinaciones, UX del fallo, robustez, pruebas de negocio y coherencia con la intención de producto.

Su valor está en hacer testable la calidad de un producto probabilístico.

Su riesgo es quedar reducido a QA clásica, cuando la evaluación cubre también la intención de producto, la confianza y la aceptabilidad.

Product Knowledge Curator

Rol que mantiene la memoria del producto en una forma aprovechable tanto por los humanos como por los agentes.

Su valor está en hacer realmente accionables las decisiones pasadas, la señal del cliente, las restricciones, los arbitrajes y la documentación.

Su riesgo es producir documentación pesada en lugar de una memoria viva.

Product Ops agéntico

Product Ops especializado en orquestar las herramientas, automatizaciones y agentes que sostienen el trabajo de producto.

Su valor está en mantener los workflows de IA que atraviesan el product management: feedback, briefs, discovery, release notes, documentación, medición del impacto.

Su riesgo es automatizar ruido si los criterios de calidad y el ownership no están claros.

Tres familias de roles

Estos roles se pueden leer en tres familias.

Los roles de criterio: PM estratégico aumentado.

Los roles de construcción: PM o PO prototipador, Product Builder, Product Engineer.

Los roles de sistema: Product Systems Designer, AI Product Evaluator, Product Knowledge Curator, Product Ops agéntico.

El título importa menos que la responsabilidad. En los equipos aumentados por la IA, la pregunta central será menos "¿cuál es tu rol?" que "¿qué eres capaz de juzgar, construir, garantizar, evaluar o mantener?"