· 5 min de lectura
La IA puede volver más lento al sistema haciendo más rápidas a todas las personas
Cagan, Atlassian y Figma describen la misma falla de diseño: sube el caudal de trabajo y queda igual la capacidad de decidir cuál importa.
En resumen
Optimizar la productividad individual puede reducir la productividad del sistema. No porque las personas trabajen peor, sino porque producen más trabajo del que la organización puede evaluar, coordinar e integrar. La pregunta relevante no es cuánto más produce cada persona con IA, sino cuánto tarda el equipo en llegar a una decisión confiable.
Una de las publicaciones de IA y gestión de proyectos de los últimos días es The AI Productivity Paradox, publicada el 23 de julio por Marty Cagan en svpg.com/the-ai-productivity-paradox
Su argumento superficial es conocido: la IA aumenta el output, pero no necesariamente los resultados. La idea importante aparece un nivel más abajo:
Optimizar la productividad individual puede reducir la productividad del sistema.
No porque las personas trabajen peor. Porque producen más trabajo del que la organización puede evaluar, coordinar, integrar y convertir en decisiones.
Ese es el riesgo que muchos equipos de producto todavía están llamando "transformación".
La evidencia converge desde lugares distintos
Marty observa equipos que generan PRD, roadmaps, prototipos y código más rápido, pero no mejoran sus outcomes (!!!). Su explicación es que están (estamos) usando IA para acelerar el viejo modelo de proyectos: reciben ideas, producen entregables y miden velocidad. La IA no corrige el sistema; aumenta su capacidad para enviar soluciones no validadas a producción.
Los datos de Atlassian respaldan el diagnóstico desde la organización: 89% de los ejecutivos afirma que la IA aumentó la velocidad del trabajo, pero solo 6% puede señalar con seguridad un retorno organizacional claro. El hallazgo más revelador es que las empresas están priorizando productividad individual aunque la mayor parte del trabajo dependa de coordinación entre equipos. (atlassian.com/blog/state-of-teams-2026)
Figma (sí, incluso con la pérdida de valor, lo tenemos en cuenta) detecta el mismo patrón desde el trabajo creativo. Cuando producir se vuelve más barato, no necesariamente disminuye el trabajo: aumenta la cantidad de opciones, exploraciones, revisiones y decisiones. Su investigación de 2026 muestra que la IA empieza a modificar la colaboración, pero también describe un efecto similar a la paradoja de Jevons: abaratar la creación aumenta la demanda de creación. (figma.com/blog/2026-ai-report)
Cagan, Atlassian y Figma describen la misma falla de diseño:
La IA aumenta el caudal de trabajo, pero el sistema conserva la misma capacidad para decidir qué trabajo importa.
Lo que cambia para Product Management
Durante años, muchos líderes interpretaron la lentitud como el principal enemigo:
- tardamos demasiado en escribir;
- tardamos demasiado en diseñar;
- tardamos demasiado en desarrollar;
- tardamos demasiado en analizar.
La IA reduce esas demoras, y gracias Claude por tanto, pero el cuello de botella era —y sigue siendo—:
- seleccionar problemas valiosos;
- conseguir evidencia suficiente;
- resolver desacuerdos;
- tomar decisiones con trade-offs;
- coordinar dependencias;
- abandonar ideas mediocres;
- sostener foco.
Nada de eso se acelera automáticamente porque un PM pueda escribir cinco PRD en una tarde. Sí es cierto que la IA nos puede ayudar a ordenar ideas, analizar más rápido el por qué de un KPI que nos molesta o incluso preparar la siguiente reunión de la agenda haciéndonos un perfil de cada participante (siempre y cuando, nuestro brain esté completo, actualizado, etc)
La coyuntura es, ¿estamos generando valor? ¿acaso mi velocidad me está corriendo del problema? ¿mi organización se está centrando en soluciones a problemas inventados por una IA?
Lo que Marty Cagan describe es un problema potencial, que llegó a muchas organizaciones, la productividad local sube mientras el throughput de decisiones permanece igual. El equipo siente velocidad (e incluso presión). La organización acumula inventario. Los outcomes bien gracias.
La métrica que puede estar dañando a tu equipo
Cuando una empresa mide:
- cantidad de documentos generados;
- tareas cerradas;
- velocidad de desarrollo;
- adopción de herramientas de IA;
- horas teóricamente ahorradas;
está midiendo la entrada del sistema, no su capacidad de producir resultados.
La pregunta relevante no es:
¿Cuánto más produce cada persona con IA?
Es:
¿Cuánto tiempo pasa desde que aparece una oportunidad hasta que contamos con evidencia suficiente para invertir, descartar o cambiar de dirección?
Eso es decision throughput.
Un equipo puede duplicar su output y reducirlo:
- genera más alternativas;
- aumenta la carga de evaluación;
- suma reuniones y revisiones;
- posterga decisiones difíciles;
- dispersa capacidad entre más iniciativas;
- aprende más lentamente por cada unidad de esfuerzo.
Por eso "todos somos más rápidos" puede coexistir perfectamente con "la empresa no avanza más". No es una contradicción. Es una consecuencia de optimizar componentes en lugar del sistema.
De acuerdo con el diagnóstico, con la solución…
Cagan interpreta el fenómeno como evidencia a favor del product operating model: equipos empoderados, discovery, outcomes y separación entre build to learn y build to earn.
En gran parte, estoy de acuerdo con el diagnóstico, pero no compraría toda la solución automáticamente.
La evidencia citada demuestra que velocidad individual no equivale a valor organizacional. No demuestra que adoptar formalmente el modelo de SVPG sea la única respuesta.
Una organización también puede fracasar haciendo "discovery":
- entrevistando sin tomar decisiones;
- produciendo árboles de oportunidades ornamentales;
- testeando problemas pequeños porque son fáciles de testear;
- usando experimentos para evitar apuestas estratégicas;
- confundiendo aprendizaje con progreso.
La versión superficial del product model puede convertirse en exactamente el mismo problema: más actividades, artefactos y ceremonias, ahora etiquetados como discovery.
El antídoto no es "hacer más discovery", sino reducir el inventario de decisiones abiertas.
Qué mediría antes de sumar más IA
Elegiría un único flujo de decisión importante —por ejemplo, priorizar oportunidades de producto— y mediría:
- cuántas oportunidades entran al sistema;
- cuánto tardamos en descartar una;
- cuánto tardamos en conseguir evidencia decisiva;
- cuántas permanecen abiertas sin próximo paso;
- cuánto trabajo se produce antes de tomar una decisión;
- cuántas iniciativas llegan a delivery y no generan el resultado esperado.
Después usaría IA para mejorar ese flujo completo, no para acelerar aisladamente sus actividades.
El objetivo no sería producir investigaciones más rápido. Sería alcanzar antes una decisión confiable.
No sería generar más prototipos. Sería identificar antes cuál no merece continuar.
No sería completar más tickets. Sería disminuir el tiempo entre una hipótesis y evidencia suficiente para sostenerla o matarla.