Cómo cambia el trabajo del PM en la era de la IA: contexto centralizado, más producción y el juicio como diferencial

Casey Winters, de SuperMe, presenta los hallazgos de una serie de entrevistas con product managers de startups y empresas cotizadas sobre cómo ha cambiado su forma de trabajar con IA. El texto mezcla resultados, interpretaciones del autor y preguntas abiertas. Según el artículo, fue revisado por varios perfiles de SuperMe (Julie Zhou, Ami Vora, Shishir Mehrotra, Sachin Rekhi y Aparna Chennapragada).

La IA como capa de contexto del trabajo de producto. Todos los PM entrevistados tienen un flujo de trabajo centrado en IA. Antes saltaban entre editor de documentos, herramientas de analítica, Slack, el sistema de tickets, la wiki y el creador de presentaciones. Esas herramientas siguen existiendo, pero se consumen desde dentro de una herramienta de IA. El autor atribuye un peso enorme a la adopción de MCP para concentrar los flujos en un solo lugar, hasta el punto de que la interfaz de muchas herramientas deja de importar. Más que un «espacio de trabajo», lo que describe es que cada PM construye una capa de contexto personalizada, con la fórmula: modelo favorito + contexto de la empresa + contexto personal + herramientas de la empresa. Algunos usan muchos archivos locales, otros integraciones MCP y otros habilidades (skills) personalizadas. Hay PM que la construyen a título personal para llevársela a futuros empleos. La razón es que el entorno de IA se vuelve más valioso cuanto más se usa, pero buena parte del contexto acumulado pertenece al empleador y se pierde al cambiar de trabajo, de modo que empezar un puesto nuevo se siente mucho más como partir de cero. Los PM hacen su análisis, estrategia y mensajes en ese entorno y luego exportan el resultado al canal adecuado (presentación, documento, correo o Slack). Según el autor, que esa interfaz tenga contexto importa más que dominar SQL, Jira u otra herramienta concreta, y las skills permiten fijar estándares propios de la empresa, por ejemplo para analítica o formatos de documentos.

Más productividad, pero no necesariamente más impacto. PM, ingenieros y diseñadores trabajan más y entregan más: más código, especificaciones, prototipos, correcciones de errores, evals y dashboards. Sin embargo, pocos PM sienten que ese aumento de producción se haya traducido en un aumento similar de resultados de negocio. La IA hace rentable trabajo que antes no lo era: el que no estaba priorizado, el que no generaba apalancamiento, el que se quedaba en el backlog. Mantener ese ritmo deja a los PM menos tiempo para planificar lo más impactante, y tampoco es fácil dejar de hacerlo: si todas las empresas resuelven más rápido errores y peticiones menores con IA, quizá las expectativas de los clientes hayan subido tanto que no hacerlo supondría quedarse atrás. El autor admite que hoy esa respuesta es en gran medida incognoscible.

Los cuellos de botella se desplazan. Antes los PM esperaban largo tiempo al desarrollo de ingeniería. Con el código fácil de generar, el cuello de botella pasa al diseño, a la integración de nuevas funciones con el resto del producto, a la gestión de casos límite, a la alineación organizativa y a los principios de producto compartidos. La IA eliminó una restricción y dejó al descubierto otras, y las organizaciones aún no han rediseñado sus procesos en torno a ellas, mientras la tecnología cambia más rápido de lo que esos procesos pueden estabilizarse.

El criterio de producto reaparece como diferencial. Crece la expectativa de que los PM consulten datos por sí mismos, hagan prototipos, cambien prompts, escriban código, construyan herramientas internas, creen agentes y definan evals. El autor percibe que el estándar se ha desplazado en exceso desde entender la tecnología lo bastante bien como para decidir bien hacia demostrar uno mismo habilidad técnica. Eso genera incentivos extraños: los PM se esfuerzan en parecer técnicos y «nativos de IA» y tienen menos tiempo para decidir si lo que producen sus equipos debería existir. Antes la escasez de ingeniería forzaba la priorización; la IA ha eliminado parte de esa escasez sin reemplazar el mecanismo de priorización. La priorización cumplía además otras dos funciones: controlar el ritmo de cambio percibido por el cliente y rechazar malas ideas. Al lanzar mucho más rápido, llegan más añadidos a los clientes, causan confusión y muchos nunca debieron construirse; el producto y la base de código son ahora más difíciles de entender. En organizaciones maduras, ser más eficiente con IA es lo mínimo exigible; lo valorado es crear valor que antes no era posible. Eso combina una habilidad, el gusto (saber qué es bueno), y un proceso, los principios, que definen la verdad de referencia contra la que ejecutan humanos y agentes. La IA solo eleva el valor del juicio si los PM lo hacen comprensible para otros y reutilizable.

Centralizar en IA no significa confiar plenamente en ella. Los PM usan IA para todo, pero desarrollan técnicas elaboradas sobre lo que se le puede confiar: qué puede saber y qué puede decidir. Algunos le confían datos y consultas, otros nunca le dan datos en bruto, y otros se los dan pero quieren recibirlos de vuelta en bruto y no como conclusiones suavizadas. Todos han visto a la IA sobreajustarse al contexto recibido y aplanar los matices donde suelen estar las mejores ideas de producto. Cuanto más sofisticado es el flujo de trabajo, menos confía el PM ciegamente en la IA. Surge así una nueva habilidad: decidir qué contexto darle, qué síntesis puede hacer, qué puede ejecutar, dónde sigue haciendo falta juicio humano y qué debe verificar una persona.

Tres modos de operar con IA. Según el estudio, toda organización empieza igual: usa IA, experimenta magia, empieza a construir más rápido y experimenta errores. Lo que sucede después define tres respuestas. No son tipos de empresa: distintos equipos de una misma compañía pueden operar de forma distinta e incluso un equipo puede cambiar de modo.

Respuesta 1, proteger el flujo negativo («¿y si está mal?»). Tras sufrir alucinaciones o errores, algunos equipos endurecen sus procesos: aprueban herramientas de IA concretas para usos concretos, rechazan el «slop» y cuidan más que antes la corrección de los datos y la presentación. Hay puertas de aprobación estrictas, culturas fuertes de presentaciones y consecuencias serias por usar mal la IA. No son anti-IA, pero son muy sensibles a las pérdidas, tanto de la empresa como de la reputación individual. El papel del PM pasa a ser averiguar quién debe aprobar algo, qué evidencia necesita y cómo hacerlo suficientemente seguro. La innovación ocurre fuera de horas con proyectos personales. Claude fue la interfaz más usada por los participantes, pero en qué centralizaban dependía en buena medida de lo que permitiera el departamento de TI: las startups tenían acceso a lo que quisieran, mientras que las grandes empresas usaban herramientas corporativas concretas o un subconjunto casi aleatorio (lo más común era Claude más una de las opciones Cursor, Codex o Gemini; en empresas Microsoft, Copilot y quizá otra herramienta). Los plugins MCP disponibles tampoco eran homogéneos. Muchos procesos de aprobación son tácitos, y los PM «giran» hasta encontrar a quien decide; conocer la organización y tener confianza previa con las personas clave se vuelve una moneda valiosa. La ventaja es el control de calidad; el riesgo, gastar tanto esfuerzo en proteger la posición actual que un competidor descubra algo nuevo que la erosione.

Respuesta 2, maximizar el potencial («¿por qué no probarlo?»). Estos equipos prueban por defecto, aceptan que parte del trabajo sea «slop» y esperan aprender más rápido gracias a la velocidad de iteración. Trabajan más que nunca y logran mucho más, pero no crecen mucho más rápido; algunos reconocen que con 10 veces más entregado no crecieron mucho más deprisa. Se rompe la cadena «entregar más rápido → más experimentos → aprender más rápido → crecer más rápido» cuando la capacidad de entregar supera la de aprender. Se construyen jefes de gabinete con IA o herramientas centrales para seguir proyectos que quizá nunca debieron aprobarse; los experimentos mediocres generan herramientas internas mediocres y confusión organizativa y de producto. Los resúmenes internos escritos con IA generan herramientas de IA para agregarlos y leerlos. Las skills fueron la primera moneda «nativa de IA», con un componente performativo: hackathons centrados en publicar skills en lugar de construir cosas nuevas, y muchas no son mejores que prompts del tipo «finge que eres…». El «slop organizativo» es lo que ocurre cuando una organización genera trabajo más rápido de lo que puede evaluar, coordinar o absorber.

Respuesta 3, optimizar la IA para el impacto («¿importó?»). Estos equipos se centran en si lo construido mejora métricas de usuario o negocio; la productividad solo cuenta si se convierte en crecimiento o beneficio. No equiparan consumo de tokens con progreso, tienen menos herramientas pero más confianza en ellas, y trabajan en documentos y hojas de cálculo más que en presentaciones. Cada artefacto se escribe tanto para humanos como para agentes, y muchos PM sustituyen documentos y diapositivas por markdown o HTML. Construyen muchos agentes internos y funciones llamativas, con la tensión de que esos agentes afecten al trabajo de otras funciones. Su seguridad laboral es buena, pero las empresas suelen haber pasado por despidos y transformaciones organizativas importantes. El autor observa que estos equipos parecen haber empezado en la respuesta 2: quizá hay que verse desbordado por la IA para aprender a limitarla con inteligencia.

¿Cuál es entonces el trabajo del PM? Toda la carrera del PM se basó en la escasez: no se puede construir todo, así que hay que priorizar. La IA prometió abundancia, y construir todo no condujo a la tierra prometida. Para el autor, la abundancia hace aún más importante decidir qué no construir. Tras un breve periodo en que se esperaba que los PM fueran también ingenieros, la implementación vuelve mayoritariamente a ingeniería, y el PM asume qué debe ocurrir, por qué, los principios que rigen el comportamiento del producto y cómo se evalúa el éxito. El debate entre PRD y prototipos oculta, según el autor, que la eval se convierte en el artefacto central: el PRD o la estrategia sirve como documento para agentes y humanos sobre lo que se pretendía construir, y la eval define si se logró. La conclusión es que la IA facilitó construir, pero no saber qué merece la pena construir.

Comentarios destacados. Un lector pregunta cómo se define «slop» y sostiene que, desde su perspectiva de PM, lo que queda oculto tras la interfaz no tiene valor intrínseco, y que código impecable en un producto sin valor para el usuario es peor que código chapucero en uno con encaje con el mercado. Otro lector cuestiona el hallazgo del backlog: ese trabajo estaba ahí porque nadie sabía nombrar al cliente al que servía, y pregunta si los PM entrevistados identificaron quién lo pidió una vez entregado.