El cuello de botella se ha desplazado

Durante décadas, la restricción principal en el desarrollo de producto estuvo en la ingeniería. Construir software era caro y lento, y el product owner gestionaba esa escasez: priorizaba porque no todo podía construirse, refinaba porque el equipo necesitaba claridad para avanzar. El diseño del rol tenía sentido en ese contexto.

Lo que ha cambiado es dónde está la restricción. McKinsey, en su State of AI 2025, documentó que el 88% de las organizaciones ya usa IA en alguna función de negocio, pero solo el 39% reporta impacto real en resultados de negocio. BCG llega a conclusiones similares: la mayoría de las organizaciones no genera valor material pese a sus inversiones en IA. La explicación más consistente no apunta a la tecnología sino a lo que la rodea: los equipos producen funcionalidades más rápido, pero sin la orientación estratégica que convierte esa velocidad en valor para el usuario.

Cuando construir es más barato, decidir bien qué construir se vuelve el diferenciador. La restricción se ha desplazado de la ingeniería al criterio. Y el criterio sobre qué merece ser construido, para quién y por qué es, en última instancia, responsabilidad del rol de producto.

Lo que el diseño original del rol ya no cubre

El product owner de Scrum fue concebido para un contexto específico: equipos donde la ingeniería era el recurso escaso, los ciclos de entrega eran de dos semanas y el backlog era el artefacto central de coordinación. Ese diseño respondía a las condiciones de su tiempo. En un contexto donde agentes de IA pueden generar prototipos funcionales en horas y donde buena parte del trabajo de implementación puede ser asistido o delegado, tres responsabilidades clásicas del PO están siendo absorbidas o asistidas por herramientas: la síntesis de feedback de usuarios, la redacción de primeros borradores de historias y criterios de aceptación, y el seguimiento del progreso del backlog. Lo que ninguna herramienta puede sustituir es la decisión sobre qué problema merece ser resuelto, con qué criterio de valor y para qué usuario real. Esa es la parte que crece en peso e importancia.

Marty Cagan (2024) argumenta que el riesgo no está en adoptar IA sino en adoptarla sin repensar cómo se lidera y cómo se estructuran los equipos de producto. La aceleración de la ejecución no es valiosa por sí sola: puede perfectamente acelerar la entrega de las cosas equivocadas. Esa advertencia apunta directamente al rol de producto como el lugar donde se decide si la velocidad se traduce en valor o en desperdicio más rápido.

El Product Architect: qué cambia y qué se mantiene

Lo que se mantiene es la esencia del rol: representar al cliente en el equipo, decidir qué merece ser construido y en qué orden, mantener la visión del producto como referencia. Teresa Torres lleva años argumentando que la diferencia entre equipos de producto que generan valor y los que no está en si hacen discovery real o si se limitan a validar soluciones que alguien ya decidió construir. En un contexto donde construir soluciones se ha vuelto mucho más barato, esa distinción se vuelve más crítica, no menos.

Lo que cambia son tres dimensiones concretas:

• Desplazamiento hacia la validación estratégica continua. El PO clásico validaba al final del sprint, cuando el incremento ya estaba construido. El Product Architect valida antes: diseña experimentos para comprobar hipótesis antes de que el equipo construya, usa el carril rápido de exploración para obtener feedback de usuarios en horas, y decide con datos si una idea merece pasar a producción. McKinsey describe este cambio como una compresión de la distancia entre discovery y delivery: la IA hace viable prototipar y validar hipótesis a una velocidad que antes era impensable, lo que multiplica la cantidad de experimentos que un equipo puede ejecutar. Pero eso solo genera valor si hay criterio estratégico detrás de qué se experimenta y por qué.
• Gestión consciente de la paradoja de la productividad. Cuando el equipo puede generar features más rápido de lo que la organización puede evaluar si merecen ser construidas, el Product Architect necesita ejercer de freno deliberado. Hay diferencia entre ser un cuello de botella —ralentizar sin aportar valor— y ser un punto de decisión estratégica. Esto requiere criterios explícitos sobre qué entra en el backlog, qué va al carril de exploración rápida y qué merece el rigor de producción.
• Relación con las especificaciones como artefacto. Las historias de usuario fueron diseñadas para comunicar intención entre personas. Cuando parte de la ejecución la realiza un agente de IA, esa comunicación necesita un nivel de precisión diferente. El Product Architect no tiene que escribir especificaciones técnicas, tiene que asegurarse de que la intención estratégica detrás de cada funcionalidad es lo suficientemente clara como para que los desarrolladores puedan traducirla a una spec que la IA pueda procesar. Eso requiere una relación de trabajo más estrecha con el equipo técnico, no más distante.

Las competencias que ganan peso

La demanda de perfiles de producto con fluidez en IA se ha multiplicado en los últimos años. Forrester identificó que las ofertas de empleo para roles de «AI Product Manager» crecieron de forma muy significativa en un período corto, lo que indica que el mercado ya reconoce esta transformación aunque la industria aún no haya terminado de definirla.

Esto no significa que el Product Architect deba convertirse en un técnico de IA. Significa que necesita entender lo suficiente sobre cómo funciona para tomar buenas decisiones con ella y sobre ella. Las competencias que ganan peso son cuatro:

• La data literacy: capacidad de leer datos de comportamiento de usuarios, métricas de producto y resultados de experimentos para decidir con evidencia.
• El diseño de experimentos de validación: saber formular hipótesis verificables, diseñar el test mínimo que las confronta y leer los resultados con rigor.
• La gestión de la tensión velocidad-valor: criterio para decidir cuándo ir rápido y cuándo ir despacio, cuándo un prototipo es suficiente y cuándo se necesita rigor de producción.
• La comunicación en lenguaje procesable: no solo transmitir intención a personas, sino asegurarse de que esa intención puede traducirse a especificaciones que guíen el trabajo de los agentes.

Lo que no cambia —y conviene subrayarlo— es la necesidad de entender a los usuarios de verdad. Las herramientas de IA pueden sintetizar feedback a escala, analizar patrones de comportamiento y generar informes. No pueden reemplazar la conversación directa que revela el «por qué» detrás del comportamiento. En un contexto donde la tentación de ir más rápido es constante, dedicar tiempo a hablar con usuarios reales es una de las pocas cosas que sigue siendo irreemplazablemente humana.

Una transición, no una sustitución

El Product Architect no es un rol nuevo que reemplaza al Product Owner. Es lo que el Product Owner se convierte cuando las condiciones del equipo lo exigen, y esas condiciones son hoy más frecuentes que antes.

No todos los equipos necesitan hacer esa transición ya. Los que trabajan con poca o ninguna asistencia de IA, en organizaciones donde la ingeniería sigue siendo la restricción principal, pueden seguir funcionando bien con el modelo clásico. La pregunta no es si hay que cambiar el título, sino si el rol que se está ejerciendo responde a las condiciones reales del equipo.

Lo que parece claro es que las organizaciones que están obteniendo valor real de la IA no son las que han adoptado más herramientas, sino las que han rediseñado cómo se toman las decisiones de producto. Según el McKinsey State of AI 2025, los factores que distinguen a las organizaciones con mayor impacto incluyen tener procesos definidos para validar los outputs de la IA y mantener la orientación al usuario como criterio central. Ambos son responsabilidad del rol de producto.

¿Cómo está evolucionando el rol de producto en tu organización? ¿Qué has tenido que aprender o desaprender desde que la IA entró en el flujo de trabajo del equipo?

Bibliografía

• Battery Ventures (2025). The Role of a Product Manager in the Age of AI. battery.com
• Cagan, M. (2024). Transformed: Moving to the Product Operating Model. Wiley.
• McKinsey & Company
  • (2025). The State of AI: How Organizations Are Rewiring to Capture Value. McKinsey QuantumBlack.
  • (2025). How an AI-enabled software product development life cycle will fuel innovation. McKinsey Technology.
• Palacio, J. (2026). Scrum en la era de la IA: la síntesis que viene. Navegápolis.
• Torres, T. (2021). Continuous Discovery Habits. Product Talk LLC.
• Wolpers, S. (2026). AI4Agile Practitioners Report 2026. Age-of-Product / Scrum.org.