La distancia era una coartada

Durante años parecía que una carrera profesional madura tenía un itinerario bastante claro: primero hacías; después dirigías a quienes hacían. El programador dejaba de programar, la diseñadora dejaba de diseñar y el responsable de producto acababa alejado de las pantallas, del código y de los problemas concretos.

Había una parte razonable en esa evolución. A medida que crecen los equipos y el alcance de un producto, nadie puede hacerlo todo. Delegar es necesario. Pero se confundieron dos ideas muy distintas: dejar de ser quien ejecuta cada tarea y dejar de entender (o de ser capaz de tocar) la materia sobre la que se decide.

La IA ha roto esa confusión.

No escribo esto a partir de un estudio. Es algo que llevo tiempo observando, y cada vez más deprisa, en conversaciones con compañeros del sector TIC y de otros campos, y en pistas que salen del trabajo diario y que voy contrastando con gente con la que trabajo. No tengo datos para medirlo; sí suficientes señales para querer pensarlo por escrito.

Hoy una persona puede convertir una hipótesis en una interfaz navegable, una especificación, una consulta de datos o una primera implementación en muy poco tiempo. El oficio sigue haciendo falta, pero el coste de explorar se ha desplomado. Y cuando explorar cuesta menos, queda más visible qué parte de una decisión era realmente criterio y qué parte era solo distancia respecto al trabajo.

La IA no ha matado el liderazgo. Ha matado, o al menos ha dejado sin coartada, al liderazgo que solo lideraba.

La cadena que diluía el criterio

En muchas organizaciones grandes, una idea vaga podía recorrer una larga cadena antes de convertirse en algo visible: reunión, documento, presentación, backlog, diseño, desarrollo, revisión. Si el resultado era malo, la responsabilidad quedaba repartida entre demasiadas manos. Se podía atribuir a quien interpretó mal el requisito, a quien no entendió el contexto, a quien implementó deprisa o a quien aprobó tarde.

La estructura no eliminaba la falta de criterio: la diluía.

A esa forma de dirigir, en gestión, se le llama «hacer hacer», y se presenta como la madurez natural de quien dirige. «Hacer hacer» es a menudo la frase bajo la que se esconden quienes nunca han trabajado. Siempre lo he pensado, y lo he comentado con más gente que dirige equipos. Delegar exige saber qué se pide y reconocer si lo que vuelve está bien; sin eso, solo queda repartir.

Con IA, esa cadena se acorta. Una instrucción pobre puede transformarse casi de inmediato en una pantalla pobre, una experiencia confusa o un código frágil. El artefacto aparece antes y permite discutir antes. Eso no significa que todo resultado erróneo sea culpa de un mal prompt: los modelos cometen errores, inventan información y pueden producir soluciones inseguras incluso ante una instrucción razonable. El propio perfil de riesgos de IA generativa de NIST insiste en la validación, la supervisión humana y la definición explícita de responsabilidades.

Aun así, la conclusión se mantiene: la herramienta ya no permite esconder una decisión imprecisa detrás de una larga cadena de ejecución. Quien plantea el problema debe aportar el contexto, marcar las restricciones, definir qué significa que algo funcione y reconocer una mala respuesta cuando la tiene delante.

La IA no ha creado el criterio. Ha reducido la distancia que permitía fingir que se tenía.

Cuando producir cuesta menos, el criterio vale más

Decidir es una acción; el valor diferencial está en el criterio, es decir, en la calidad del juicio que permite decidir, priorizar y transformar. Las cifras de productividad deben leerse con cautela y varían mucho según tarea y contexto. Aun así, ya hay evidencia de aceleración material en trabajos acotados. En un experimento controlado de GitHub con 95 desarrolladores, el grupo que usó Copilot completó una tarea concreta de programación un 55 % más rápido que el grupo de control. Extrapolarlo a cualquier proyecto sería un error; indica, eso sí, que parte de la producción técnica ya puede comprimirse.

Hay datos en sentido contrario. Un ensayo de METR con desarrolladores expertos trabajando en repositorios open source que conocían bien encontró, con herramientas de principios de 2025, que tardaban un 19 % más al usar IA. En sistemas reales, llenos de contexto, dependencias y deuda acumulada, generar código no equivale automáticamente a entregar valor.

Esa tensión es precisamente el argumento. La IA hace barata una parte de la ejecución, pero no resuelve por sí sola el problema de decidir qué merece construirse, qué compromiso es aceptable o cómo encaja una solución en un producto ya existente.

Cuando cualquier equipo puede producir una primera respuesta deprisa, la ventaja se desplaza al criterio: elegir bien, aprender pronto y desechar con rapidez lo que no merece seguir adelante.

El PM ya no traduce: arranca

Esto cambia de forma concreta el trabajo de producto.

El PM tradicional podía llegar al equipo con un problema descrito, unos requisitos y una lista de historias. El diseño debía convertirlo en una experiencia; ingeniería, en un sistema. Sigue siendo necesaria esa especialización, pero el punto de partida puede ser mucho más rico.

Un PM con criterio y con herramientas de IA puede iniciar la conversación con entregables que antes habrían requerido varios ciclos de coordinación:

• Una hipótesis de producto formulada con claridad, incluyendo para quién es y qué no pretende resolver.
• Un prototipo navegable o una primera versión funcional para comprobar si el flujo tiene sentido.
• Casos límite, estados vacíos, errores previsibles y criterios de aceptación explícitos.
• Una especificación conectada con las métricas, las restricciones de negocio y la deuda técnica que ya se conoce.
• Preguntas abiertas separadas de las decisiones que ya se han tomado.

Entregar una solución cerrada a diseño e ingeniería sería confundir rapidez con arrogancia. El objetivo es poner sobre la mesa un objeto suficientemente concreto para que ambas disciplinas puedan mejorarlo, cuestionarlo y hacer visibles sus riesgos antes de invertir semanas en interpretaciones diferentes.

El movimiento hacia el spec-driven development apunta en esa dirección. GitHub describe este enfoque como definir primero el qué y el porqué, convertirlo en una especificación, un plan técnico y tareas accionables, y usar esos artefactos para guiar la implementación. La especificación, que antes era un PDF estático que alguien interpretaba al final, pasa a ser un artefacto vivo, comprobable y conectado con el resultado.

Para producto, la etiqueta metodológica importa poco. El enfoque sí sirve porque eleva la calidad de la conversación inicial: menos «creo que queríamos decir esto» y más «aquí está el flujo, estos son sus supuestos y esto es lo que tendría que pasar para considerarlo válido».

El contexto es la materia prima del criterio

El contexto es la materia prima; el criterio es la capacidad de usarla para elegir.

Se confunden con facilidad. Acumular contexto es relativamente sencillo: basta con haber estado en suficientes reuniones, leer los informes y conservar el historial de decisiones. El criterio aparece cuando ese material sirve para descartar: saber qué dato pesa más que otro, qué restricción es negociable y cuál no, qué queja de un cliente es un síntoma y cuál es ruido. Dos personas con el mismo contexto pueden llegar a decisiones muy distintas, y una de ellas puede estar equivocada.

La IA hace más visible esa diferencia. Un modelo puede generar una interfaz atractiva sin saber por qué un usuario abandona un proceso, qué decisión comercial hay detrás de un límite de uso, qué informe regulatorio no puede romperse o qué deuda técnica hace inviable una aparente simplificación. Y aunque reciba cientos de documentos, sin nadie que le indique qué pesa más devolverá una síntesis correcta que no ayuda a decidir nada. Una persona con mucho contexto puede fallar de la misma forma si no sabe formularlo para elegir. En los dos casos falta lo mismo: alguien que convierta lo que sabe en una decisión con consecuencias.

Julián de Cabo formula una versión especialmente útil de este problema en It’s always day one: la IA puede saber muchísimo y, aun así, no conocer a la organización. Puede encontrar el acta donde se aprobó una decisión sin saber qué alternativa se descartó, qué compromiso se aceptó a regañadientes o qué condición informal hizo viable el acuerdo. Conectar un modelo a documentos, correo o CRM hace recuperable una parte de la información; no equivale a haber estado presente cuando se formó el conocimiento.

Un sistema RAG puede devolver el requisito que se documentó, pero no necesariamente el motivo por el que se priorizó, los intentos previos que fracasaron o el riesgo que el equipo decidió asumir. La IA empieza cada conversación con el contexto que se le da. Por eso, además de una buena instrucción, necesita una memoria de producto que conserve decisiones, evidencias, excepciones y cambios de rumbo: una memoria al servicio de todo el equipo, que le evite redescubrirla cada vez.

Hay empresas que llevan décadas construyendo ese contexto a propósito. En Japón, la rotación entre departamentos forma parte de la carrera de quien aspira a dirigir: la primera selección para puestos de mando llega de media casi ocho años después de la contratación, y haber trabajado en funciones distintas de la propia es de lo más valorado para ascender. Toyota lo lleva al terreno: sus nuevos titulados, también los de oficina e ingeniería, pasan por la fábrica y por el concesionario para entender cómo se hace un coche y qué espera quien lo compra. En Alemania, ALDI SÜD hace que sus futuros responsables regionales trabajen en tienda, incluso como encargados, antes de dirigir varias. Quien pasa por ahí no acaba siendo especialista en nada, pero sabe lo que cuesta el trabajo que va a pedir. Ese contexto es justo lo que necesita quien orquesta un producto.

El problema es que el mercado laboral occidental premia lo contrario. En Estados Unidos, la antigüedad mediana en una empresa es de 3,9 años, y quien cambia de trabajo ve subir su sueldo bastante más que quien se queda. Aquí también se rota, pero entre empresas: se gana variedad y se pierde justo el contexto propio de cada organización. Si las personas se van a los tres años, lo que saben tiene que quedarse de alguna forma. Es otra razón para esa memoria de producto. Es una tensión que no se resuelve en un párrafo y que quiero explorar con calma en una próxima nota.

El contexto de producto contiene cosas que rara vez caben en un ticket: investigación de usuarios, conversaciones comerciales, comportamiento medido, decisiones anteriores, restricciones legales, particularidades del negocio, arquitectura existente y efectos de segundo orden. Un PM que se guarda ese conocimiento acaba convertido en cuello de botella.

Su responsabilidad es ordenarlo, conectarlo y convertirlo en decisiones que el equipo pueda usar. Un buen prototipo, una buena especificación o una buena instrucción para un agente hacen que el contexto sea operativo y compartido; el nivel de detalle es solo el medio.

El trabajo del PM consiste en transformar contexto disperso en una decisión que diseño, ingeniería y negocio puedan discutir sobre algo real.

Programar, diseñar y liderar vuelven a tocarse

Nada de esto convierte al PM en sustituto de diseñadores e ingenieros. Una IA no convierte a nadie de forma automática en especialista en interacción, arquitectura o seguridad. De hecho, al aumentar la velocidad de producción, esas disciplinas importan más: hay muchas más maneras de crear rápidamente algo que parece funcionar y falla al escalar, al llegar a un usuario real o al pasar una auditoría.

Pierde sentido, en cambio, la separación orgullosa entre quien «piensa» y quien «hace». En producto, las tres capacidades se vuelven a tocar:

• Programar para entender posibilidades, costes y fragilidad; no necesariamente para escribir cada línea de producción.
• Diseñar para convertir una intención en una experiencia comprensible, usable y accesible.
• Liderar para escoger el problema, alinear decisiones, proteger el foco y asumir el resultado.

Las tres forman un ciclo: se entiende un problema, se materializa una hipótesis, se observa el resultado y se decide de nuevo. La IA acelera ese ciclo. Por eso castiga particularmente a quien solo era competente en una de sus partes más vacías: administrar la distancia entre la idea y su ejecución.

Las habilidades que la IA va a laminar

La coordinación, la gestión de personas, la negociación y la estrategia van a seguir ahí. Son formas exigentes de liderazgo cuando sirven para crear claridad, resolver conflictos reales o sostener decisiones difíciles.

Las que quedan bajo presión son sus versiones huecas: la política que sustituye a la decisión, la reunión que evita concretar, la presentación que disimula que no hay una hipótesis comprobable y la cadena de intermediarios cuya aportación es repetir información sin mejorarla.

Las grandes corporaciones seguirán siendo capaces de proteger esos comportamientos durante bastante tiempo. La tecnología no elimina por sí sola los incentivos políticos. Pero baja el coste de comprobar quién aporta algo. Si una persona con contexto puede pasar de una intuición a un artefacto evaluable en una tarde, la retórica sin sustancia se vuelve más fácil de detectar.

El liderazgo útil consistirá en construir las condiciones para que el equipo tome mejores decisiones, con más autonomía y con una comprensión mucho más directa de lo que está construyendo. Repartir tareas desde lejos tendrá cada vez menos que ofrecer.

Para mí, la pregunta útil es si un PM sabe usar estas herramientas para convertir su criterio en algo que el equipo pueda ver, cuestionar y mejorar. Programar o diseñar como un especialista es otra cosa, y no hace falta. Si ese criterio no está, las herramientas no lo suplen, y ahora se nota antes.

---

Fuentes y notas

1. GitHub Research, Quantifying GitHub Copilot’s impact on developer productivity and happiness. Experimento controlado con 95 desarrolladores; útil como evidencia de aceleración en una tarea acotada, no como promesa universal de productividad.
2. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Ensayo controlado en repositorios reales de desarrolladores expertos; sirve de contrapeso frente a las afirmaciones lineales sobre velocidad.
3. Anthropic Economic Index, Learning curves (marzo de 2026). Datos agregados de uso de Claude que muestran el peso de las tareas técnicas y de programación. Lectura de contexto: no mide productividad y procede de un proveedor de IA.
4. GitHub Spec Kit, Spec-Driven Development. Referencia práctica del enfoque: especificación, plan, tareas, implementación y verificación como artefactos conectados.
5. NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative AI Profile. Marco para tratar riesgos como confabulación, supervisión humana, validación y responsabilidades en sistemas de IA generativa.
6. Julián de Cabo, It’s always day one, 22 de septiembre de 2026. Una reflexión sobre la diferencia entre recuperar información y conocer una organización; se incorpora aquí como referencia conceptual sobre contexto y memoria institucional.
7. Yashiro, N. (2013), Selection and Promotion of Managers in Japanese Companies, Japan Labor Review. Comparación entre Japón, Estados Unidos y Alemania sobre selección tardía y experiencia en varias funciones.
8. Toyota Motor East Japan, 研修・育成制度. Formación de nuevos titulados con prácticas en fábrica y en concesionario.
9. Karriereführer, Regionalverkaufsleiter bei ALDI SÜD: Jeder Tag ist anders. Año de incorporación con trabajo en tienda y como encargado.
10. U.S. Bureau of Labor Statistics, Employee Tenure in 2024. Antigüedad mediana de 3,9 años en enero de 2024.
11. ADP, National Employment Report, agosto de 2026. Crecimiento interanual del sueldo base: 4,7 % para quien cambia de empresa frente a 3,0 % para quien se queda.