El PM que parecía haber subido de nivel
Voy a contar algo que vi hace no mucho en un equipo de producto con el que estaba trabajando. No voy a dar nombres ni empresa, pero los detalles son reales.
El equipo era un squad estándar: un PM, dos diseñadores, un tech lead y tres ingenieros. Llevaban trabajando juntos algo más de un año. Buen equipo. No perfecto, pero funcional: se conocían, se respetaban, y las decisiones de producto se tomaban con debate real.
El PM empezó a usar Claude de forma intensiva. No solo para borradores — para todo. Análisis competitivo, síntesis de research, estructuración de roadmaps, preparación de decks para stakeholders. En cuestión de semanas, su output cambió visiblemente. Los PRDs eran más completos. Los análisis tenían más profundidad aparente. Las presentaciones a dirección se veían más afiladas. En los standups, siempre tenía algo nuevo que mostrar.
Desde fuera, parecía que el PM había subido de nivel.
Lo que realmente había pasado es que su herramienta había subido de nivel. Su criterio seguía siendo el mismo — bueno, pero el mismo. Lo que cambió fue la velocidad y el acabado de lo que producía. Y esa diferencia es invisible para cualquiera que mire el resultado sin saber cómo se produjo.
El problema no era que el PM usara IA. El problema era lo que empezó a pasar alrededor.
La diseñadora que dejó de hablar
Una de las diseñadoras del equipo — la más senior de las dos — llevaba años trabajando de una forma que le funcionaba. Bocetaba a mano antes de ir a digital. Hacía prototipos sencillos en Figma, los testeaba con usuarios, iteraba. Su proceso era más lento que el del PM, pero su criterio de diseño era excelente. Entendía al usuario mejor que nadie en el equipo.
Cuando el output del PM se disparó, ella empezó a sentir algo que le costó semanas identificar. No era envidia exactamente. Era más bien una sensación de que sus contribuciones se veían pequeñas al lado. El PM llegaba a las reuniones con documentos de quince páginas perfectamente estructurados. Ella llegaba con tres wireframes y una lista de preguntas sobre el usuario.
Objetivamente, sus preguntas eran más valiosas que las quince páginas del PM. Pero en una reunión de una hora, ¿qué ocupa más espacio? ¿Qué parece más “trabajo”?
Fue dejando de hacer ciertas cosas. Dejó de cuestionar las prioridades del roadmap porque el PM siempre tenía un análisis preparado que parecía irrebatible. Dejó de proponer alternativas de diseño porque sus dos conceptos se veían modestos al lado de las ocho opciones que el PM generaba con IA. Dejó de levantar la mano en las reviews para decir “no estoy segura de que esto resuelva el problema del usuario” porque esa frase, dicha frente a un PRD perfecto, sonaba como si ella no se hubiera preparado lo suficiente.
No se fue del equipo. No se quejó. Simplemente se volvió más pasiva. Y nadie lo notó, porque el equipo seguía entregando. Más rápido que nunca, de hecho.
Con el tiempo, decidió empezar a sumarse al movimiento del vibe-coding, cayendo en la trampa ya conocida de que velocidad y aparente perfección no es igual a razonamiento. Empezó a diseñar sin cuestionarse ni a seguir esas buenas prácticas que la llevaron en el pasado a tomar buenas decisiones de diseño; a hacerse las preguntas correctas.
Lo que veía el stakeholder
En ese mismo equipo, el VP de producto tenía una reunión quincenal con el squad para revisar avance de producto. No estaba en el día a día — veía resultados, decks, documentos de propuesta.
En un par de meses, su percepción del equipo cambió. Empezó a dirigirse al PM directamente en las reuniones. Le pedía a él las actualizaciones, le consultaba a él las dudas sobre dirección de producto, le copiaba a él en los correos a dirección. No por mala intención — simplemente porque el PM era el que presentaba mejor material. Los decks eran más claros, los análisis más completos, las respuestas más articuladas.
La diseñadora, que antes tenía interlocución directa con negocio sobre decisiones de experiencia de usuario, fue quedando fuera de esas conversaciones. No porque alguien decidiera excluirla, sino porque el PM ya llegaba con todo “resuelto.” ¿Para qué preguntar a la diseñadora sobre el usuario si el PRD ya incluye una sección de user needs perfectamente estructurada?
Lo perverso es que esa sección la generó Claude. El PM la revisó y le pareció razonable, pero no venía de hablar con usuarios ni de trabajar con la diseñadora. Venía de un prompt. Y el VP de producto tomó decisiones de roadmap basándose en ella.
Nadie mintió. Nadie actuó con mala intención. Pero una brecha de herramientas se convirtió en una redistribución de influencia dentro del equipo. Y eso es mucho más difícil de revertir que una mala evaluación trimestral.
El tech lead que se fue desconectando
Hay una cuarta perspectiva que se habla todavía menos. La del perfil técnico que no ha entrado en la IA y que ve cómo el mundo a su alrededor cambia sin que nadie le haya preguntado si quiere cambiar con él.
En otro equipo con el que trabajé, el tech lead era una persona con quince años de experiencia. Excelente arquitecto, buen comunicador, respetado por el equipo. Pero no usaba herramientas de IA. No por rechazo ideológico — simplemente no las había incorporado a su forma de trabajar. Tenía un proceso propio para pensar la arquitectura, para evaluar trade-offs técnicos, para revisar código. Y ese proceso funcionaba.
Lo que empezó a pasar es que las conversaciones del equipo fueron girando hacia un lenguaje que él no compartía. “Le pregunté a Claude por todos estos datos y dice que el mejor approach es...” “Copilot me sugiere este patrón para...” “He generado cinco opciones de arquitectura con...” El tech lead no participaba en esas conversaciones porque no tenía el mismo marco de referencia. Y poco a poco, sin que nadie lo decidiera explícitamente, su voz fue perdiendo peso en las decisiones.
No es que le excluyeran. Es que el ritmo y el lenguaje del equipo cambiaron, y él se quedó en la versión anterior. Como cuando todo el mundo empieza a hablar en un idioma que tú entiendes pero no dominas — puedes seguir la conversación, pero dejas de liderarla.
En su caso, la reacción fue un escepticismo creciente. Empezó a cuestionar no solo las herramientas sino los outputs que generaban. “¿Habéis verificado eso?” “¿De dónde saca Claude esa recomendación?” Preguntas legítimas que el equipo empezó a interpretar como resistencia al cambio. La realidad era más simple y más triste: era la única forma que tenía de seguir participando desde su posición. Para mí, el ancla que hemos perdido por la fiebre de las herramientas de IA.
Lo que nadie dice en voz alta
Estos tres casos son variaciones del mismo fenómeno. Me gusta llamarlo adoption asymmetry: cuando la adopción desigual de IA dentro de un equipo crea una brecha de herramientas que se malinterpreta como una brecha de talento.
Lo preocupante es que nadie lo nombra. Y no lo nombra por razones diferentes según el lado en el que estés.
El que adopta rápido no dice “estoy usando IA para el 70% de mi output” porque, ¿por qué lo haría? Su trabajo se ve bien. Recibe buen feedback. No tiene incentivo para desvelar el truco — aunque no lo viva como un truco. Para esa persona, usar IA es simplemente trabajar de forma inteligente.
El que no adopta no dice “me siento obsoleto” porque admitirlo sería reconocer una vulnerabilidad profesional. Es más fácil achacarlo a que “no me da tiempo” o “prefiero hacerlo a mi manera” que decir “no sé por dónde empezar y cada día que pasa me siento más lejos.”
Y el manager no dice “creo que estoy confundiendo output con juicio” porque probablemente no es consciente de que lo está haciendo. Evaluar rendimiento es difícil. Evaluar rendimiento cuando parte del equipo tiene un multiplicador invisible que se llama IA y la otra parte no, es un problema que nadie le ha enseñado a gestionar.
El resultado es un silencio colectivo donde cada persona sufre su versión del problema y nadie pone palabras a lo que está pasando.
Dónde se nota en el día a día
Si te cuesta identificar si tu equipo tiene adoption asymmetry, busca estas señales en situaciones que vives cada semana.
En los standups. ¿Hay una persona que siempre tiene más que contar? ¿Que siempre parece haber avanzado más? Puede que sea más productiva. O puede que tenga un copiloto que los demás no tienen. La pregunta es si el equipo percibe esa diferencia como talento o como herramienta. Si no se ha hablado nunca de quién usa IA y para qué, la percepción por defecto será talento.
En las sesiones de ideación. Alguien llega con veinte conceptos generados con herramientas de IA. Otra persona llega con tres ideas trabajadas a mano. ¿Cuáles reciben más atención? Las veinte. No porque sean mejores — porque ocupan más espacio visual, porque parecen más trabajo, porque la cantidad proyecta seriedad. Pero tres ideas donde cada una tiene una razón de ser pueden ser infinitamente más valiosas que veinte variaciones que nadie filtró con criterio.
En las reviews de entregables. El documento AI-assisted se ve más completo, más pulido, más profesional. El documento escrito sin IA puede tener mejor pensamiento detrás pero peor envoltorio. Y en una review donde hay seis documentos que revisar en una hora, ¿cuál recibe el beneficio de la duda? El que se ve mejor. No el que es mejor.
En los 1:1 con el manager. “Necesito que subas el ritmo.” ¿El ritmo de qué? ¿De producir artefactos? ¿O de pensar? Si tu manager no distingue entre las dos cosas — y la mayoría no lo hacen conscientemente — te está pidiendo que adoptes IA sin decírtelo explícitamente. Y eso no es gestión del equipo. Es presión por proxy.
Qué hacer con esto
No voy a proponer que todo el mundo use IA ni que nadie la use. Ambas posturas son igual de absurdas. Lo que propongo es que el equipo haga visible lo que ahora es invisible.
Primer movimiento: tener la conversación.
En un equipo con el que trabajé, el PM hizo algo muy simple después de que le explicara este fenómeno. En la siguiente retro, dedicó los últimos quince minutos a una pregunta abierta: “¿Cómo estamos usando IA cada uno y cómo nos sentimos al respecto?”
El silencio inicial duró unos diez segundos. Después, la diseñadora dijo algo como “la verdad es que a veces siento que mi trabajo se ve pequeño al lado de los docs que generas tú” El tech lead dijo “yo no sé ni por dónde empezar y a estas alturas me da hasta vergüenza preguntar.” Y el PM dijo “no era consciente de que esto estaba pasando. Además, siento que estamos perdiendo pensamiento crítico y asentimos demasiado rápido”.
Quince minutos. Sin framework. Sin workshop. Sin consultor. Solo una pregunta honesta y permiso para responderla.
No resolvió todo. Pero nombró el problema. Y como dije en la primera entrega, la mitad de estos problemas se resuelven solo con nombrarlos.
Segundo movimiento: hacer visible el proceso, no solo el output.
El equipo acordó algo sencillo: cuando alguien presenta trabajo, dice cómo lo hizo. No como una confesión — como contexto. “El borrador lo generé con Claude, los trade-offs son míos.” “Estas exploraciones las hice con Midjourney, la dirección de arte es mía.” “Este análisis lo hice a mano porque quería entender los datos yo mismo antes de pedirle a la IA que los procesara.”
Esto hace algo que parece menor pero cambia la dinámica por completo: le da al equipo la información para evaluar el pensamiento por separado del acabado. Y le da permiso a la persona que no usa IA para que su forma de trabajar también sea legítima. Además, descubrí un efecto muy interesante que era el aumento del interés por compartir conocimiento como equipo: si la diseñadora aprendió a hacer mockups más que interesantes con Weavy.ai, ¿por qué no enseñarle al PM o Tech lead a usarlo a su favor?
Tercer movimiento: mostrar cómo trabaja cada uno.
A colación con lo último mencionado, estructurar ese know-how tuvo mucho sentido, para demostrar mejoras como para evidenciar gaps. Una vez al mes, dedicar treinta minutos a que alguien del equipo enseñe cómo trabaja. No una formación. No un tutorial. Simplemente: “así es cómo yo hago esto.” El PM enseña cómo promptea para specs. La diseñadora enseña por qué boceta a mano antes de ir a digital. El tech lead enseña cómo piensa una arquitectura sin IA. El ingeniero enseña cómo usa Copilot y cuándo decide no hacerle caso.
El objetivo no es que todos adopten la misma herramienta. Es que todos entiendan cómo trabajan los demás. La asimetría de adopción no es un problema de skills. Es un problema de visibilidad. Cuando no ves cómo trabaja el otro, asumes. Y las asunciones en un equipo de producto son peligrosas — eso ya lo vimos en la entrega anterior.
Lo que está en juego
La adoption asymmetry no es un problema temporal que se resuelve solo cuando “todos se pongan al día.” Siempre va a haber una nueva herramienta, un nuevo modelo, una nueva forma de trabajar que unos adoptarán antes que otros. Es un fenómeno permanente que necesita gestión permanente.
Lo que está en juego no es la productividad — esa probablemente sube con o sin intervención. Lo que está en juego es la confianza. La sensación de que todos estamos en el mismo equipo, jugando con las mismas reglas, y que el valor de cada persona se mide por su pensamiento y su criterio, no por la sofisticación de su herramienta.
Un equipo donde la persona más valiosa es la que tiene mejor tooling es un equipo frágil. Depende de la herramienta, no de las personas. Y cuando la herramienta cambie — que cambiará — ese equipo no tendrá los músculos para adaptarse.
Un equipo donde la persona más valiosa es la que hace mejores preguntas, la que ve lo que otros no ven, la que dice “espera, ¿estamos seguros de esto?” — ese equipo puede absorber cualquier herramienta nueva sin perder lo que le hace funcionar.
La pregunta es en cuál de los dos se está convirtiendo tu equipo. Y si no la has hecho en voz alta, probablemente ya conoces la respuesta.
The Human Layer es una serie que explora la infraestructura humana debajo de la adopción de IA en equipos de producto.
También encontrarás en el libro PRAXIS (www.praxisbook.com) más información acerca de los fenómenos y prácticas que estaré informando a través de esta serie.
Si esto te ha resonado, compártelo con alguien de tu equipo. Estas conversaciones funcionan mejor cuando las dos personas tienen el lenguaje.