El rol de product manager, tal como lo hemos conocido durante la última década, fue diseñado para un mundo de software determinista. Escribías specs. Los ingenieros construían features. QA verificaba que los botones hacían lo que debían hacer. Lanzabas, medías, iterabas. El feedback loop era limpio: los usuarios hacen clic, observas dónde hacen clic, construyes más cosas donde hacer clic.

Ese mundo se está acabando. No lentamente. Rápido.

Cuando tu producto es un agente de IA que toma decisiones autónomas, todo cambia. El agente no tiene botones. Tiene comportamientos. No sigue un user flow. Razona, actúa, y a veces alucina. No puedes hacer QA de un comportamiento como haces QA de una feature, porque el mismo input puede producir outputs diferentes dependiendo del contexto, la confianza y el estado de cada otro agente en el sistema.

Los PMs que sobrevivan a este cambio no serán los que aprendan a hacer mejores prompts. Serán los que aprendan a pensar en sistemas, no en pantallas.

Cinco Mutaciones en el Rol de PM

1. Los roadmaps de features se convierten en roadmaps de comportamiento

Un roadmap de PM tradicional lista features: "Q2: Añadir exportación masiva de pagos. Q3: Filtrado de dashboard. Q4: App móvil." Cada feature es una unidad discreta con una definición clara de done.

Un roadmap de AI PM lista comportamientos: "Q2: El agente gestiona matching de pagos parciales con >90% de precisión. Q3: El agente prioriza cobros autónomamente en tres países. Q4: El agente ajusta forecasts de caja en respuesta a eventos de mercado sin aprobación humana para desviaciones menores del 5%."

La diferencia es fundamental. Una feature se lanza o no. Un comportamiento existe en un espectro. Tu agente de cobros no "se lanza" en una fecha concreta. Gradualmente se gana el derecho a tomar decisiones cada vez más consecuentes, a medida que demuestra competencia en cada dominio. El trabajo del PM no es decidir cuándo lanzar. Es definir los umbrales de competencia que desbloquean cada nivel de autonomía.

2. Las user stories se convierten en agent stories

"Como analista de tesorería, quiero ver un informe diario de posición de caja para poder tomar decisiones de financiación." Eso es una user story. Asume un humano en el loop, tomando la decisión. El software sirve información.

Las agent stories son diferentes: "Como agente de forecasting de caja, ingesto balances bancarios diarios, aplico medias móviles ponderadas con decay de recencia, ajusto por patrones estacionales por bucket de cobro, y produzco un forecast a 30 días. Cuando mi forecast se desvía más de un 10% respecto al día anterior, marco el cambio para revisión de tesorería con los tres factores principales. Cuando la desviación es menor del 10%, actualizo el forecast autónomamente."

Las agent stories especifican comportamiento, requisitos de confianza, triggers de escalación, y el contexto que el agente necesita para tomar decisiones. Están más cerca de especificaciones de sistema que de narrativas de usuario. Y escribirlas bien requiere entender tanto el dominio (¿qué constituye una desviación significativa en cash forecasting?) como la tecnología (¿cuánta confianza puede tener realmente este agente, dada la calidad y volumen de datos de entrenamiento?).

3. El QA se convierte en evaluación

En software tradicional, QA es binario. El botón funciona o no. El cálculo es correcto o incorrecto. Puedes escribir tests automatizados que verifican comportamiento determinista.

Con agentes de IA, necesitas frameworks de evaluación. No "¿produce el agente la respuesta correcta?" sino "¿produce el agente respuestas dentro de un rango aceptable, con confianza apropiada, y escala correctamente cuando no está seguro?" La evaluación es estadística, no determinista. Estás testeando distribuciones, no outputs.

Cuando construí un analista de tesorería en Claude, la evaluación no era "¿coincide el forecast con la realidad?" Era: ¿identifica correctamente el agente qué buckets de cobro tienen mayor incertidumbre? ¿Ajusta su confianza cuando la calidad de datos se degrada? ¿Marca anomalías que un humano marcaría? ¿Evita afirmar con confianza cosas que no debería? El framework de evaluación se convirtió en el artefacto de diseño más importante, más importante que los prompts o las herramientas del agente.

4. La gestión de stakeholders se convierte en gestión de confianza

Un PM tradicional gestiona stakeholders fijando expectativas, negociando prioridades y comunicando progreso. Los stakeholders son humanos que entienden (más o menos) lo que hace el software.

Un AI PM gestiona confianza. Tus stakeholders son directores financieros que se han quemado con herramientas "AI" que resultaron ser dashboards glorificados. Son equipos de tesorería a los que les dijeron que la automatización les "liberaría" y en su lugar creó más trabajo validando outputs de IA. Son oficiales de compliance que no pueden explicar a los reguladores cómo un modelo tomó una decisión.

La gestión de confianza no va de demos. Va de transparencia, despliegues graduados y dar a los humanos la capacidad de verificar y overridear. Cuando diseñé el framework de gobernanza AI para nuestra plataforma de tesorería, la estrategia de change management incluía un sistema de early warning que monitorizaba señales de adopción: frecuencia de login, uso de features y, críticamente, si los equipos mantenían hojas de cálculo paralelas como sistema shadow. Los procesos shadow son la señal más clara de que los usuarios no confían en la IA. Ignorar esa señal es cómo fracasan las implementaciones.

5. El PM se convierte en diseñador de sistemas

Quizás el cambio más profundo: el objeto de diseño principal del PM ya no es la interfaz. Es el sistema.

En un producto multi-agente, el PM define cómo interactúan los agentes, qué estado comparten, cómo se propagan los errores, qué circuit breakers existen y cómo el sistema degrada graciosamente cuando un agente falla. La UI es casi secundaria: es la capa de monitorización sobre un sistema que opera mayoritariamente de forma autónoma.

Por eso los operadores tienen ventaja. Si has vivido dentro del sistema que estás automatizando, ya tienes el modelo mental de cómo se conectan las piezas, dónde están los modos de fallo y cómo es "funcionar correctamente" en la práctica, no en la teoría. No necesitas entrevistar usuarios para entender el flujo de trabajo. Has hecho el flujo, a las 2 de la mañana, bajo presión, con dinero real en juego.

Cómo Es la Transición

Si eres un PM haciendo esta transición, esto es lo que he aprendido:

Empieza con evaluación, no con features. Antes de construir nada, define cómo es "bueno" para el agente. ¿Qué umbral de precisión importa? ¿Qué nivel de confianza dispara la escalación? ¿Cuál es el coste de un falso positivo vs. un falso negativo en tu dominio específico? Si no puedes responder estas preguntas, no estás listo para construir.

Diseña la gobernanza antes que el agente. ¿Quién aprueba qué? ¿A qué nivel de confianza? ¿Con qué audit trail? No son afterthoughts. Son la arquitectura. En industrias reguladas, el framework de gobernanza es más el producto que el modelo de IA.

Aprende a pensar en sistemas, no en flujos. Los user flows son lineales: paso 1, paso 2, paso 3. Los sistemas son redes: el Agente A afecta al Agente B que afecta al Agente C que retroalimenta al Agente A. Si no puedes dibujar los feedback loops de tu sistema, aún no entiendes tu producto.

Consigue experiencia operativa. El AI PM más peligroso es uno que nunca ha operado el sistema que está automatizando. Diseñará para el happy path porque nunca ha visto el unhappy. Fijará umbrales de confianza basados en benchmarks en lugar de impacto de negocio. Construirá demos que funcionan y productos que no.

El rol de AI product manager no está desapareciendo. Se está convirtiendo en algo más difícil y más valioso: la persona que diseña cómo se comportan los sistemas inteligentes en el mundo real, donde el mundo real es desordenado, regulado e implacable.

Los PMs que prosperen en esta nueva realidad combinarán tres capacidades que raramente se encuentran juntas: experiencia profunda de dominio (idealmente de operar los sistemas que ahora están automatizando), fluidez técnica en arquitecturas de IA (no solo prompt engineering, sino diseño de sistemas, evaluación y gobernanza), y el criterio de producto para saber dónde trazar la línea entre autonomía y supervisión humana.

Si eso suena como una intersección pequeña, lo es. Y por eso exactamente es una oportunidad de carrera.