De usar la IA a operar con la IA: qué cambia en la gestión de producto cuando desaparecen los cuellos de botella

Escrito por: Nubank Editorial y Cinthia Scarlatti

Para muchos product managers, el primer contacto con la IA ocurre a través del texto: un modelo resume una reunión, pule un documento o reformula un mensaje para los stakeholders. Estos usos ahorran tiempo. Sin embargo, en su mayoría dejan intacto el trabajo en sí: las mismas tareas, en el mismo orden, solo que hechas un poco más rápido.

El cambio más significativo comienza cuando la pregunta pasa de «¿cómo puede ayudarme la IA a escribir esto?» a «¿qué partes de mi trabajo todavía tienen que depender de la cola de otra persona?». Una vez que esa pregunta está sobre la mesa, la IA deja de ser una asistente de redacción y empieza a formar parte de cómo se preparan las decisiones, cómo se realizan los análisis y cómo un proyecto lleva su propio seguimiento. En otras palabras, el verdadero cambio no es pasar de trabajar sin IA a usarla, sino de usar la IA a operar con ella.

Esa idea guía la forma en que Cinthia Scarlatti, Lead Product Manager de Nubank, ha ido reorganizando su propio trabajo. Scarlatti es Lead PM de Growth en la expansión de Nu en Estados Unidos, tras una etapa en CX Platforms, donde trabajó en las plataformas internas que usan los agentes de atención al cliente, incluidos productos de IA creados para ellos. También es AI Champion de la unidad de negocio del mercado estadounidense de Nu y mentora de otros PMs. En mayo de 2026, compartió su experiencia en el PM3 Summit, una conferencia de gestión de producto, en una sesión titulada «De usar IA a operar com IA» (De usar la IA a operar con la IA). El PM3 Summit es un importante evento de tecnología en São Paulo que, en 2026, reunió a más de 800 líderes de producto en torno al tema ‘Lead with AI’, para debatir cómo la inteligencia artificial está redefiniendo la función.

Su punto de partida fue una pregunta sencilla: si la IA puede asumir una parte cada vez mayor de la ejecución, ¿qué merece realmente el tiempo de un product manager?

Definir el problema siempre fue el trabajo

La respuesta a la que llega Scarlatti no es nueva para la gestión de producto. Es la habilidad que los PMs ya practican todos los días: describir un problema con la claridad suficiente para que otra persona pueda actuar sobre él. Lo que cambia es quién puede ser esa «otra persona».

En su opinión, el PM se convierte en arquitecto de flujos de trabajo. El PM define qué importa y cómo es un buen resultado; la IA ayuda a refinar el problema, implementar una solución y ejecutar los pasos repetitivos; y el PM toma las decisiones a partir de lo que recibe. Por eso operar con IA va más allá de escribir mejores prompts. Requiere repensar los procesos que un PM aprendió a seguir e identificar dónde puede entrar la IA para eliminar una dependencia, no solo para acelerar una tarea.

Aquí no hay una receta universal, y Scarlatti deja claro que sus ejemplos buscan inspirar, no ser replicados. A lo largo de su carrera, ha trabajado en productos internos y externos, y tanto en un producto con más de diez años de historia como en otro todavía en discovery. Cada uno de esos contextos tiene cuellos de botella distintos.

Lo que se traslada es el método. Antes de pensar en agentes o herramientas, ella mapea el proceso: dónde están las dependencias, dónde el trabajo pasa de una persona a otra y dónde se encuentran los verdaderos cuellos de botella. Las oportunidades para la IA suelen aparecer exactamente en esos puntos. Los tres casos que siguen responden a esa lógica.

Un prompt escrito como un requisito de producto

El primer caso comenzó con una auditoría interna, que identificó un error en las indicaciones que se mostraban a los agentes de atención al cliente en México al gestionar casos de un cliente fallecido: el sistema dirigía a los agentes al correo de soporte de Brasil en lugar del de México. La corrección era urgente, y el equipo de ingeniería responsable ya tenía varias entregas prioritarias y un plazo ajustado.

A primera vista, parecía un simple cambio de texto. En la práctica, no lo era. Las indicaciones estaban organizadas por idioma, no por país, e idioma y país son cosas distintas. México y Colombia usan español, así que cambiar el texto en español habría modificado también la instrucción para los agentes colombianos, sin motivo alguno. La corrección adecuada debía cambiar el comportamiento para México y mantener intacta Colombia.

La idea clave de Scarlatti fue que, para un equipo de ingeniería que ya estaba al límite de su capacidad, el ahorro de tiempo vendría de que alguien que conociera el producto describiera el problema con la precisión suficiente para que un agente de IA lo ejecutara. Así que escribió un prompt para Cursor, un asistente de programación con IA, con la misma estructura que usaría para una historia en Jira: el problema, el comportamiento actual, el comportamiento deseado y las restricciones. El comportamiento deseado establecía que los agentes de cada país siempre debían ver la información de contacto de su propio país, independientemente del idioma de la interfaz.

A partir de ahí, el flujo quedó así:

Solicitud en Slack → análisis de la PM → Cursor + GitHub → pull request → aprobación de ingeniería

Cursor investigó cómo la plataforma gestionaba la internacionalización, la parte del código que maneja distintos idiomas y regiones, y confirmó que el cambio debía hacerse por país y no por idioma, lo que evitó cualquier impacto en Colombia. Propuso dos opciones de implementación. Scarlatti eligió la más robusta, y el agente la implementó, creó la branch y abrió el pull request. El cambio superó todas las verificaciones automatizadas y fue aprobado por un ingeniero del equipo.

El paso de aprobación importa. La PM no se saltó a ingeniería; llegó con un cambio bien definido y revisable, en lugar de un ticket a la espera de ser priorizado. Según describe Scarlatti, el lead time de este tipo de solicitud pasó de más de una semana, siguiendo el camino habitual de ticket, priorización y entrega, a menos de un día.

El principio es uno que los PMs ya conocen: la estructura de un buen documento de requisitos también puede guiar una implementación con IA, según la complejidad del problema.

Cuando el cuello de botella es el acceso, no la complejidad

El segundo caso vino de Operaciones. Tras el lanzamiento parcial de un nuevo flujo de UX para los agentes de atención al cliente, surgieron reportes de un posible bug técnico. Para entender qué estaba pasando, el equipo necesitaba saber qué motivos de contacto seleccionaban los agentes en un conjunto específico de chats.

Los PMs necesitan este tipo de datos todo el tiempo, para validar hipótesis, responder a los stakeholders y negociar plazos. Muy a menudo, la pregunta en sí es sencilla. El obstáculo es el acceso: normalmente, el análisis requeriría que un analista de datos o un ingeniero con acceso a Databricks priorizara la solicitud, o el PM tendría que encontrar tiempo de concentración para escribir las queries manualmente.

Scarlatti le pasó a Cursor algunos IDs de chats de ejemplo y le pidió que investigara. Su perfil todavía no estaba autenticado en Databricks, así que el agente primero configuró la autenticación, usando Glean, la herramienta de búsqueda empresarial de la compañía, a través de una conexión Model Context Protocol (MCP) para encontrar por sí mismo la documentación relevante. Fue un paso que, según ella, no habría sabido hacer sin preguntarle a alguien. Luego, el agente localizó los datasets correctos y cruzó más de uno de ellos para construir un análisis detallado. Cuando una tabla requirió acceso especial a datos personales, cambió a otro dataset que contenía solo los campos necesarios para responder la pregunta.

El resultado llegó en una sola sesión de pocos minutos. Todos los chats en cuestión tenían el mismo motivo de contacto específico, lo que indicaba que los agentes no estaban usando el nuevo flujo. En otras palabras, se trataba de un problema de experiencia y capacitación de los agentes humanos, no de un bug técnico. Era precisamente la información que Scarlatti necesitaba para responder a los stakeholders y negociar las fechas de lanzamiento. Los agentes humanos recibieron una capacitación de refuerzo, y se puso en marcha una mejora en la experiencia para ayudar a evitar el mismo error.

La velocidad viene con la responsabilidad sobre los datos

Pasar de la pregunta a la respuesta en una sola sesión cambia la forma en que funciona el discovery. Preguntas como cuántas conversaciones de atención al cliente mencionan un determinado conjunto de palabras clave ya no tienen que esperar a la disponibilidad de otra persona.

Lo que no cambia, en opinión de Scarlatti, es que el criterio crítico le corresponde al PM. El trabajo sigue empezando por definir el problema y la pregunta específica que hay que responder. Continúa con la validación de las dimensiones del análisis: nombres de columnas, filtros, tamaño de la muestra y el origen de cada tabla. Y termina preguntándose si el resultado tiene sentido antes de usarlo en una decisión.

La IA ayuda a construir y ejecutar la query, pero la interpretación es responsabilidad del PM. La ganancia son decisiones más rápidas y mejor informadas, siempre que el rigor analítico no se convierta en el paso que se omite.

Un agente que devuelve tiempo para pensar

El tercer caso trata menos de una tarea puntual y más de una nueva forma de trabajar. En ese momento, Scarlatti estaba formando un nuevo equipo y empezando un nuevo producto desde cero, un producto exigido por la regulación que todavía estaba en discovery. El contexto era denso: decenas de documentos, más de diez stakeholders, más de ocho canales de Slack dedicados al proyecto y decenas de reuniones de alineación y discovery cada semana, además de su propio diario de notas.

Sin un sistema bien estructurado, un proyecto así pierde información: las decisiones tomadas en reuniones se pierden, los hilos de Slack desaparecen de la vista y las preguntas quedan abiertas sin respuesta. Mantener esa estructura suele costarle a un PM, o a otras personas del equipo, horas de documentación. Son horas que podrían dedicarse a la experiencia del cliente y a entender el problema en mayor profundidad.

Su respuesta fue el Daily Digest, un agente creado con Claude Cowork que se ejecuta todos los días hábiles a las 18:30. Sigue siete pasos:

Página de Open Questions → canales de Slack del proyecto → diario de la PM → Google Calendar y transcripciones de reuniones → Open Questions actualizadas → resumen diario → borrador de actualización en Slack

El agente lee la página viva de preguntas abiertas en Confluence, revisa los canales de Slack del proyecto en busca de los hilos del día, lee el diario de la PM y consulta en el calendario las reuniones del proyecto que se realizaron, recopilando sus transcripciones. Con ese contexto, actualiza las preguntas abiertas con lo que avanzó y lo que sigue pendiente, redacta un resumen del día y de cuánto avanzó el proyecto desde el anterior, y prepara un borrador de mensaje para el canal del proyecto para mantener a todos alineados.

Cada día, esto genera cuatro resultados: un archivo de resumen diario, un borrador de actualización de estado para Slack, una página de Open Questions actualizada en Confluence y una página de Meeting Notes con palabras clave y enlaces a las transcripciones completas. La página de Open Questions se ha convertido en una pieza central del proyecto. Reúne las preguntas planteadas en Slack, reuniones y documentos, las organiza por ID, categoría (como UX o Compliance) y fecha y, una vez que se responde una pregunta, el agente añade los próximos pasos. Hasta ahora se han mapeado más de 60 preguntas. Desde su presentación en el PM3 Summit, ha seguido evolucionando el agente y estima que le ahorra alrededor de 1 hora al día, tiempo que dedica a decidir de verdad y a buscar respuestas y conexiones que ayuden a resolver cada uno de los temas, desarrollando un mejor producto para los clientes.

El PM como arquitecto del flujo de trabajo

En conjunto, los tres casos describen el mismo cambio. La IA ejecuta y documenta. El PM analiza, valida y decide. El rol se aleja de la ejecución y se acerca a decidir qué se debe hacer, cómo debe fluir el trabajo y qué cuenta como un buen resultado.

Ese cambio se apoya en herramientas con roles específicos. Cursor funciona como un copiloto técnico para explorar código, repositorios y pull requests, mientras que Claude Cowork se encarga de skills, automatizaciones recurrentes y análisis. Gemini y ChatGPT cubren revisiones de texto y una segunda opinión sobre los resultados de Claude en escenarios complejos. Figma Make y Claude Design cubren wireframes y prototipos rápidos. Las conexiones MCP con herramientas como Glean, Databricks, GitHub, Atlassian, Slack, Miro y Google Drive dan a estos agentes acceso al contexto de la empresa que necesitan.

El contexto es lo que une el stack. Un agente capaz de leer la documentación correcta, encontrar el dataset adecuado o ver las conversaciones del día es mucho más útil que un modelo más potente trabajando de forma aislada.

Empieza con un paso y luego construye un sistema

Para los PMs que quieran avanzar en la misma dirección, las recomendaciones de Scarlatti son deliberadamente prácticas. El primer agente no tiene que ser perfecto ni estar construido con la mejor herramienta disponible. Puede empezar con lo que el equipo de TI de la empresa ya permita y mejorar mediante la iteración. El prompt puede seguir la estructura que los PMs ya usan para los requisitos: el problema, el comportamiento actual y el comportamiento deseado.

A partir de ahí, el objetivo es construir sistemas y no interacciones aisladas. Las skills, el contexto compartido y la documentación viva hacen que cada sesión alimente a la siguiente, en lugar de empezar desde cero cada vez. En todo momento, los PMs deben confiar en lo que saben de su producto. La IA puede ejecutar y ayudarles a pensar mejor, pero decidir qué problema vale la pena resolver sigue siendo su responsabilidad.

Por eso mismo, Scarlatti no lo plantea como una IA que reemplaza a los product managers, ni a ninguno de los otros roles que los rodean. Lo que cambia es la distribución de la autonomía. Los PMs dependen menos de las colas de otras personas para análisis y cambios pequeños, y todos los involucrados ganan más espacio para enfocarse en lo que más importa: el cliente. 

Todavía es pronto, y las prácticas descritas aquí seguirán cambiando a medida que cambien las herramientas. Pero es probable que la lección de fondo se mantenga: cuando la ejecución deja de ser el cuello de botella, la calidad del trabajo de un PM depende, más que nunca, de lo bien definido que esté el problema.