PM, desarrolladores e IA: los roles se difuminan, las responsabilidades permanecen

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

Y hace tres días, hice 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 ascienden hacia el problema, el cliente y el ownership de producto. Los PM descienden hacia el prototipo, el código y a veces la producción.

Podría verse como dos anécdotas aisladas. Creo al contrario que es el comienzo de una inversión más profunda. Los roles históricos del product management, el desarrollo y el diseño se vuelven menos nítidos. Las fronteras se mueven. Pero al contrario de lo que podría pensarse, eso no significa que todo el mundo vaya a hacerlo todo, ni que las responsabilidades vayan a desaparecer.

El verdadero tema no es que la IA haga a los equipos "más productivos". El verdadero tema es que aumenta fuertemente la capacidad de producir. Y cuando la capacidad de producir aumenta, el cuello de botella se desplaza.

Antes, la restricción era a menudo: "¿Cuánto podemos construir?"

Mañana, se convierte más en: "¿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 desencadenantes del tema es bastante simple: con la IA, los desarrolladores pueden producir más rápido.

No solo escribir unas pocas líneas más velozmente. Producir más opciones, más variantes, más prototipos, más pequeñas herramientas, más iniciativas. Un desarrollador que ya era autónomo puede encontrarse capaz de ir tres, cuatro o seis veces más rápido en ciertas tareas. Un equipo que tenía una capacidad de delivery limitada puede de repente generar muchas más cosas que probar, arbitrar, releer, priorizar.

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

Si todo debe seguir pasando por el PM, este se convierte rápidamente en el nuevo punto de saturación del sistema. Ya no se trata solo de escribir specs o de seguir un backlog. La carga se desplaza hacia la priorización, la coherencia de 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 entonces creer que ha resuelto su problema de velocidad porque los desarrolladores producen más. En realidad, simplemente ha desplazado el bloqueo.

Hay tres respuestas posibles.

La primera consiste en contratar más PM. A veces es necesario, pero no siempre es la respuesta correcta. Si el modelo sigue siendo el mismo, solo se añade una capa de arbitraje adicional.

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

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

Acelerar el código no es suficiente

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

La velocidad local no crea valor automáticamente. Puede incluso crear más desorden si el flujo completo no cambia. Un equipo puede generar más código, más prototipos, más documentos y más tickets, tomando al mismo tiempo peores decisiones.

El flujo completo debe repensarse: idea, discovery, especificación, prototipado, desarrollo, tests, seguridad, lanzamiento, comunicación, soporte y aprendizaje.

Si se añaden agentes IA sobre un proceso sin cambiar, solo se corre el riesgo de desplazar los cuellos de botella. El código acelera, luego el producto bloquea. El producto acelera, luego el diseño bloquea. El diseño acelera, luego la validación técnica bloquea. La validación acelera, luego el go-to-market o el soporte ya no sigue.

El tema no es, pues, solo: "¿Cómo hacer a los desarrolladores más rápidos?"

El tema es: "¿Cómo hacer que todo el sistema sea capaz de absorber esa velocidad sin perder en calidad, coherencia y responsabilidad?"

Es por eso que los nuevos roles no se reducen a "PM que programa" o "desarrollador que hace producto". Parte de las nuevas necesidades concierne a la orquestación de los workflows, la evaluación de las salidas IA, la memoria de producto, la calidad de las decisiones, la legibilidad de los repositorios y la capacidad de dar a los agentes un contexto fiable.

Lo que la IA banaliza en el product management

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

Algunos eran muy buenos en redacción. Otros en datos. Otros en benchmark, en marketing de producto, en discovery, en diseño de experiencia o en coordinación de delivery. Esas diferencias no desaparecen completamente. 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 un prototipo aceptable;
• sintetizar entrevistas;
• producir una primera versión de recorrido;
• transformar una necesidad en prototipo.

Esas competencias no se vuelven inútiles. Un PM debe saber siempre juzgar una spec, cuestionar un análisis, leer un prototipo, entender una síntesis de entrevistas o evaluar un prototipo. Pero la producción inicial de esos artefactos se vuelve menos rara.

Antes, un PM podía estar fuertemente diferenciado porque sabía producir rápidamente una buena spec, un benchmark claro, una síntesis explotable o un primer prototipo. Mañana, será más el nivel mínimo.

Eso hace vulnerables a los PM que eran sobre todo fuertes por su capacidad de ejecución intermedia. Quienes coordinaban, redactaban, administraban, seguían, reformulaban y producían artefactos correctos sin llevar un juicio de producto fuerte 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 juicio de producto

Cuando producir se vuelve más 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 capacidad de elegir, arbitrar y asumir.

Lo que sigue siendo difícil:

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

El PM estratégico aumentado se parece cada vez más a una especie de pequeño CPO. 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 particularmente importante cuando no hay una buena solución. Solo dos o tres malas opciones, con costes diferentes, riesgos diferentes, efectos políticos diferentes, impactos en el cliente diferentes. En esos momentos, la IA puede ayudar a analizar. No puede asumir.

El PM aumentado no es, pues, simplemente un PM que va más rápido. Es un PM que debe 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 ya no es una ventaja suficiente.

La producción bruta de código se convierte en parte en una commodity. No el software. No la ingeniería. No la arquitectura, la seguridad o la mantenibilidad. Pero la capacidad de producir rápidamente una primera versión se vuelve menos rara.

La verdadera diferenciación se desplaza entonces hacia lo que los competidores no pueden simplemente generar:

• la calidad de la señal del cliente;
• los datos propietarios;
• el conocimiento de negocio;
• la distribución;
• la confianza;
• las restricciones operacionales;
• los aprendizajes acumulados;
• la capacidad de interpretar correctamente lo que los clientes piden realmente.

Un prototipo rápido solo tiene valor si prueba una señal real. De lo contrario, solo acelera una mala dirección.

La pregunta estratégica se convierte pues en: ¿sobre qué ventaja propia construimos?

Un equipo aumentado por IA puede producir muchas cosas. 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 adicional por la que el PM no desaparece. El rol se desplaza hacia la calidad de lectura de la realidad.

Los desarrolladores ascienden hacia el producto

Los desarrolladores nunca han sido simples ejecutores.

Una especificación completa es una ficción. Incluso una buena spec nunca 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, micro-interacciones, 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 debe explicitar el comportamiento esperado, arbitrar los edge cases, definir los criterios de aceptación, verificar el resultado. Las micro-decisiones que se absorbían silenciosamente en la implementación se vuelven más visibles, por tanto más importantes de enmarcar.

Es una de las razones por las que los desarrolladores ascienden hacia el producto. Hablan más con los clientes, entienden mejor los problemas, asumen más ownership sobre sus funcionalidades, toman decisiones locales más explícitas.

Pero hay un matiz importante: un desarrollador no se convierte en product engineer simplemente porque usa un agente de código o porque entrega más rápido.

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

El verdadero product engineer no es solo un desarrollador rápido. Es alguien que lleva parte del juicio de producto lo más cerca posible de la construcción.

Los PM descienden 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. Un prototipo, una herramienta interna, un dashboard, una traducción, una modificación de interfaz, a veces incluso una PR encuadrada.

Eso cambia la naturaleza del trabajo.

Antes, había que pasar a menudo por una secuencia larga: formular la necesidad, escribir la spec, hacer un prototipo, pedir una estimación, esperar un hueco, hacer desarrollar, probar, ajustar. Hoy, en ciertos temas, se puede pasar 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 encuadrados, se puede programar algo casi real: un dashboard, una pantalla en solo lectura, una mejora de interfaz, una automatización interna, una traducción, un soporte 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 estaban fuera de su perímetro.

Hay que distinguir aquí varios niveles.

El PM o PO prototipista transforma 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 encuadradas.

El Product Engineer va todavía más lejos: puede llevar una responsabilidad de producto hasta el entregable de producción. Y ese rol puede venir de dos trayectorias. Un desarrollador que asciende hacia el producto. O un perfil de producto suficientemente técnico que desciende hacia la producción.

El criterio no es pues el oficio de origen. El criterio es el nivel de capacidad de acción.

¿La persona se queda al nivel del prototipo? ¿Produce un prototipo funcional? ¿Abre una PR? ¿Lleva un entregable productizable? ¿Entiende suficientemente los riesgos para hacer validar correctamente lo que produce?

Es ese continuum lo que es nuevo.

Los roles se difuminan, las responsabilidades permanecen

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

Pienso exactamente lo contrario.

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

Una decisión de producto sigue siendo una decisión de producto. Le corresponde al 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 la técnica: seguridad, rendimiento, escalabilidad, arquitectura, mantenibilidad, calidad de plataforma.

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

La organización que funciona no es aquella donde todo el mundo hace todo en su rincón. Es aquella donde cada uno puede intervenir más allá de su dominio inicial porque hay garantes que fijan los estándares, las barandillas y los límites.

Un PM puede empujar una PR. Pero es releída, aceptada, corregida o rechazada.

Si es rechazada diez veces seguidas, eso dice algo. Quizás el PM no tiene todavía el nivel para ese tipo de contribución. Quizás el tema es demasiado arriesgado. Quizás también el equipo técnico no ha puesto todavía en marcha las directrices, las herramientas o las barandillas que permiten a otros perfiles contribuir de forma segura.

La PR o la MR se convierte entonces en un mecanismo de gobernanza. No solo una herramienta técnica.

Todo depende del binomio competencia / riesgo

La buena pregunta no es: "¿Puede un PM hacer push a producción?"

La buena pregunta es: "¿En qué perímetro, con qué competencia, qué riesgo y qué barandillas?"

Hace falta una gradación simple.

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

Riesgo medio: pequeñas acciones de escritura, workflows internos, modificaciones de interfaz encuadradas.

Riesgo alto: pago, 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 puede ser relativamente seguro si las reglas son claras y la validación técnica está presente. Por el contrario, un producto aparentemente simple puede contener una zona muy sensible si toca datos, permisos o una decisión de negocio irreversible.

La analogía con un desarrollador junior es útil. No se le dan las llaves del motor de producto a alguien el primer día. Se empieza por perímetros simples, y luego se amplía progresivamente.

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

La fractura entre perfiles PM

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

A corto plazo, los PM con bagaje técnico tienen una ventaja. Saben leer un repositorio, entender un error, dialogar con un agente de código, interpretar lo que se ha generado, detectar ciertas absurdidades, pedir una revisión técnica en el lugar correcto.

Un PM sin esa cultura puede aprender, claro. Pero corre el riesgo de estar limitado al prototipo o al prototipo superficial mientras no entienda suficientemente lo que produce la IA.

La IA sigue siendo demasiado poco fiable para poder ignorar totalmente lo que pasa bajo el capó. Si no se comprenden mínimamente los errores producidos, se hace difícil superar el prototipo fiable.

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

Pero en el estado actual de las herramientas, la fractura existe.

Los PM que no quieran convertirse en builders tendrán que subir muy fuerte en otras dimensiones: estrategia, mercado, discovery, influencia, comprensión humana, calidad de expresión, capacidad de decir no y de orientar un equipo.

Los nuevos oficios no son siempre oficios

A menudo se habla de "nuevos oficios". El término es útil, pero puede ser engañoso.

Todos esos roles no se convertirán necesariamente en títulos de RRHH estabilizados. Algunos se convertirán en puestos. Otros seguirán siendo competencias distribuidas en el equipo. Otros serán absorbidos por Product Ops, Diseño, Engineering o QA.

El punto 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: la evaluación de las salidas probabilísticas, la documentación explotable por agentes, la memoria de producto, la orquestación de los workflows, la calidad del contexto, la legibilidad del repositorio, la claridad de los criterios de aceptación.

Esas 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 coordinación, redacción, seguimiento y producción de artefactos intermedios.

Mañana, habrá menos espacio para el PM administrativo.

Habrá más espacio para dos tipos de perfiles.

Por un lado, quienes saben construir suficientemente para acelerar el aprendizaje de producto: prototipar, materializar, probar, contribuir, a veces llegar hasta un entregable real.

Por otro, quienes saben juzgar suficientemente bien para orientar un equipo que puede construir mucho más rápido que antes: comprender el mercado, leer la señal, arbitrar, decir no, mantener una visión, proteger la coherencia y asumir las consecuencias.

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

La IA no suprime el product management. Obliga al oficio a volver a ser lo que siempre debería haber sido: una responsabilidad de creación, juicio e impacto.

Anexo: catálogo de los futuros roles de producto

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

PM estratégico aumentado

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

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

Su riesgo es ser confundido con un simple PM más productivo, o convertirse en el nuevo cuello de botella si toda la decisión sigue remontando hacia él.

PM o PO prototipista

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

Su valor es reducir la ambigüedad entre negocio, producto y técnica.

Su riesgo es quedarse al nivel del prototipo o saltarse demasiado pronto a los desarrolladores en temas que requieren una reflexión técnica real.

Product Builder

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

Su valor es reducir el tiempo entre intuición y demostración.

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

Product Engineer

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

Puede venir de un background de desarrollador o de un background de producto suficientemente técnico.

Su valor es redistribuir parte del juicio de producto lo más cerca posible de la construcción y reducir la brecha entre idea, prototipo y producción.

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

Product Systems Designer

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

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

Su riesgo es convertirse en una función demasiado abstracta si no está conectada a los workflows reales del equipo.

AI Product Evaluator

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

Su valor es hacer testeable la calidad de un producto probabilístico.

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

Product Knowledge Curator

Rol que mantiene la memoria de producto en una forma explotable por humanos y por agentes.

Su valor es hacer que las decisiones pasadas, la señal del cliente, las restricciones, los arbitrajes y la documentación sean realmente accionables.

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

Product Ops agentizado

Product Ops especializado en la orquestación de herramientas, automatizaciones y agentes que soportan el trabajo de producto.

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

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

Tres familias de roles

Se pueden leer esos roles en tres familias.

Los roles de juicio: PM estratégico aumentado.

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

Los roles de sistema: Product Systems Designer, AI Product Evaluator, Product Knowledge Curator, Product Ops agentizado.

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?"

Para ir más lejos

Cuatro días de vibe coding en la piel de un PM oxidado En 8 días comprendí que el rol de Product Manager iba a cambiar por completo La IA no debería servir solo para producir diez veces más. También debería obligarnos a entender diez veces mejor lo que producimos En el software, la ventaja ya no será la tecnología. Será la comprensión del contexto.