De usar IA a operar com IA: o que muda na gestão de produto quando os gargalos desaparecem

Escrito por: Nubank Editorial e Cinthia Scarlatti

Para muitos product managers, o primeiro contato com IA acontece por meio de texto: um modelo resume uma reunião, refina um documento ou reformula uma mensagem para stakeholders. Esses usos economizam tempo. Mas, em grande parte, deixam o trabalho em si intocado: as mesmas tarefas, na mesma ordem, só que feitas um pouco mais rápido.

A mudança mais significativa começa quando a pergunta deixa de ser “como a IA pode me ajudar a escrever isso?” e passa a ser “quais partes do meu trabalho ainda precisam depender da fila de outra pessoa?”. Quando essa pergunta entra em cena, a IA deixa de ser uma assistente de escrita e passa a fazer parte de como as decisões são preparadas, como as análises são feitas e como um projeto acompanha a si mesmo. Em outras palavras, a verdadeira mudança não é de trabalhar sem IA para usá-la, mas de usar IA para operar com ela.

Essa ideia orienta a forma como Cinthia Scarlatti, Lead Product Manager do Nubank, vem reorganizando o próprio trabalho. Scarlatti é Lead PM de Growth na expansão do Nu nos Estados Unidos, depois de um período em CX Platforms, onde trabalhou nas plataformas internas usadas pelos agentes de atendimento, incluindo produtos de IA criados para eles. Ela também é AI Champion da unidade de negócio do mercado dos EUA do Nu e mentora de outros PMs. Em maio de 2026, compartilhou sua experiência no PM3 Summit, uma conferência de gestão de produto, em uma sessão intitulada “De usar IA a operar com IA”. O PM3 Summit é um grande evento de tecnologia em São Paulo que, em 2026, reuniu mais de 800 líderes de produto em torno do tema ‘Lead with AI’, discutindo como a inteligência artificial está redefinindo a função.

Seu ponto de partida foi uma pergunta simples: se a IA pode assumir uma parcela cada vez maior da execução, o que realmente merece o tempo de um product manager?

Definir o problema sempre foi o trabalho

A resposta a que Scarlatti chega não é nova para a gestão de produto. É a habilidade que PMs já praticam todos os dias: descrever um problema com clareza suficiente para que outra pessoa possa agir sobre ele. O que muda é quem essa “outra pessoa” pode ser.

Na visão dela, o PM se torna um arquiteto de fluxos de trabalho. O PM define o que importa e como é um bom resultado; a IA ajuda a refinar o problema, implementar uma solução e executar as etapas repetitivas; e o PM toma as decisões com base no que volta. É por isso que operar com IA vai além de escrever prompts melhores. Exige repensar os processos que um PM aprendeu a seguir e identificar onde a IA pode entrar para remover uma dependência, e não apenas para acelerar uma tarefa.

Não existe receita universal aqui, e Scarlatti deixa claro que seus exemplos servem para inspirar, não para serem replicados. Em sua carreira, ela trabalhou com produtos internos e externos, e tanto em um produto com mais de dez anos de história quanto em outro ainda em discovery. Cada um desses contextos tem gargalos diferentes.

O que se transfere é o método. Antes de pensar em agentes ou ferramentas, ela mapeia o processo: onde estão as dependências, onde o trabalho passa de uma pessoa para outra e onde estão os gargalos reais. As oportunidades para a IA tendem a aparecer exatamente nesses pontos. Os três casos abaixo seguem essa lógica.

Um prompt escrito como um requisito de produto

O primeiro caso começou com uma auditoria interna, que identificou um erro nas orientações exibidas aos agentes de atendimento no México ao lidar com casos envolvendo um cliente falecido: o sistema direcionava os agentes para o e-mail de suporte do Brasil, em vez do mexicano. A correção era urgente, e o time de engenharia responsável já tinha várias entregas prioritárias e um prazo apertado.

À primeira vista, parecia uma simples mudança de texto. Na prática, não era. As orientações eram organizadas por idioma, não por país, e idioma e país são coisas diferentes. México e Colômbia usam espanhol, então alterar o texto em espanhol mudaria também a instrução para os agentes colombianos, sem nenhum motivo. A correção certa precisava mudar o comportamento para o México e manter a Colômbia intacta.

O insight de Scarlatti foi que, para um time de engenharia já no limite da capacidade, a economia de tempo viria de alguém que conhecesse o produto descrevendo o problema com precisão suficiente para que um agente de IA o executasse. Então ela escreveu um prompt para o Cursor, um assistente de programação com IA, na mesma estrutura que usaria para uma história no Jira: o problema, o comportamento atual, o comportamento desejado e as restrições. O comportamento desejado estabelecia que os agentes de cada país deveriam sempre ver as informações de contato do próprio país, independentemente do idioma da interface.

A partir daí, o fluxo ficou assim:

Solicitação no Slack → análise da PM → Cursor + GitHub → pull request → aprovação da engenharia

O Cursor investigou como a plataforma lidava com internacionalização, a parte do código que gerencia diferentes idiomas e regiões, e confirmou que a mudança precisava ser feita por país, e não por idioma, o que evitou qualquer impacto na Colômbia. Ele propôs duas opções de implementação. Scarlatti escolheu a mais robusta, e o agente a implementou, criou a branch e abriu o pull request. A mudança passou em todas as verificações automatizadas e foi aprovada por um engenheiro do time.

A etapa de aprovação importa. A PM não passou por cima da engenharia; ela chegou com uma mudança bem definida e revisável, em vez de um ticket esperando priorização. Como Scarlatti descreve, o lead time para esse tipo de solicitação caiu de mais de uma semana, seguindo o caminho habitual de ticket, priorização e entrega, para menos de um dia.

O princípio é um que os PMs já conhecem: a estrutura de um bom documento de requisitos também pode guiar uma implementação com IA, dependendo da complexidade do problema.

Quando o gargalo é o acesso, não a complexidade

O segundo caso veio de Operações. Após o rollout parcial de um novo fluxo de UX para os agentes de atendimento, surgiram relatos de um possível bug técnico. Para entender o que estava acontecendo, o time precisava saber quais motivos de contato os agentes estavam selecionando em um conjunto específico de chats.

PMs precisam desse tipo de dado o tempo todo, para validar hipóteses, responder a stakeholders e negociar prazos. Muitas vezes, a pergunta em si é simples. O obstáculo é o acesso: normalmente, a análise exigiria que um analista de dados ou um engenheiro com acesso ao Databricks priorizasse a solicitação, ou o PM teria que encontrar tempo de foco para escrever as queries manualmente.

Scarlatti passou alguns IDs de chats de exemplo para o Cursor e pediu que ele investigasse. O perfil dela ainda não estava autenticado no Databricks, então o agente primeiro configurou a autenticação, usando o Glean, a ferramenta de busca corporativa da empresa, por meio de uma conexão Model Context Protocol (MCP) para encontrar sozinho a documentação relevante. Foi uma etapa que, segundo ela, não saberia fazer sem perguntar a alguém. Em seguida, o agente localizou os datasets certos e cruzou mais de um deles para montar uma análise detalhada. Quando uma tabela exigiu acesso especial a dados pessoais, ele mudou para outro dataset que continha apenas os campos necessários para responder à pergunta.

O resultado chegou em uma única sessão de poucos minutos. Todos os chats em questão tinham o mesmo motivo de contato específico, o que indicava que os agentes não estavam usando o novo fluxo. Em outras palavras, era um problema de experiência e treinamento dos agentes humanos, não um bug técnico. Era exatamente a informação de que Scarlatti precisava para responder aos stakeholders e negociar as datas de rollout. Os agentes humanos receberam um reforço de treinamento, e uma melhoria na experiência foi colocada em andamento para ajudar a evitar o mesmo erro.

Velocidade vem com responsabilidade sobre os dados

Ir da pergunta à resposta em uma única sessão muda a forma como o discovery funciona. Perguntas como quantas conversas de atendimento mencionam um determinado conjunto de palavras-chave não precisam mais esperar pela disponibilidade de outra pessoa.

O que não muda, na visão de Scarlatti, é que o julgamento crítico pertence ao PM. O trabalho ainda começa com a definição do problema e da pergunta específica a ser respondida. Continua com a validação das dimensões da análise: nomes de colunas, filtros, tamanho da amostra e a origem de cada tabela. E termina perguntando se o resultado faz sentido antes de usá-lo em uma decisão.

A IA ajuda a construir e executar a query, mas a interpretação é responsabilidade do PM. O ganho são decisões mais rápidas e mais bem informadas, desde que o rigor analítico não se torne a etapa que é pulada.

Um agente que devolve tempo para pensar

O terceiro caso é menos sobre uma tarefa específica e mais sobre uma nova forma de trabalhar. Na época, Scarlatti estava montando um novo time e começando um novo produto do zero, um produto exigido por regulação que ainda estava em discovery. O contexto era denso: dezenas de documentos, mais de dez stakeholders, mais de oito canais de Slack dedicados ao projeto e dezenas de reuniões de alinhamento e discovery por semana, além do seu próprio diário de anotações.

Sem um sistema bem estruturado, um projeto assim vaza informação: decisões tomadas em reuniões se perdem, threads do Slack somem de vista e perguntas ficam em aberto sem resposta. Manter essa estrutura costuma custar a um PM, ou a outras pessoas do time, horas de documentação. São horas que poderiam ser dedicadas à experiência do cliente e a entender o problema com mais profundidade.

A resposta dela foi o Daily Digest, um agente construído com o Claude Cowork que roda todo dia útil às 18h30. Ele segue sete etapas:

Página de Open Questions → canais de Slack do projeto → diário da PM → Google Calendar e transcrições de reuniões → Open Questions atualizadas → resumo diário → rascunho de atualização no Slack

O agente lê a página viva de perguntas em aberto no Confluence, varre os canais de Slack do projeto em busca das threads do dia, lê o diário da PM e verifica no calendário as reuniões do projeto que aconteceram, coletando suas transcrições. Com esse contexto, ele atualiza as perguntas em aberto com o que avançou e o que ainda está pendente, escreve um resumo do dia e de quanto o projeto avançou desde o anterior, e redige uma mensagem para o canal do projeto para manter todos alinhados.

Todos os dias, isso gera quatro entregas: um arquivo de resumo diário, um rascunho de atualização de status para o Slack, uma página de Open Questions atualizada no Confluence e uma página de Meeting Notes com palavras-chave e links para as transcrições completas. A página de Open Questions se tornou uma peça central do projeto. Ela reúne perguntas levantadas no Slack, em reuniões e em documentos, organiza-as por ID, categoria (como UX ou Compliance) e data e, quando uma pergunta é respondida, o agente adiciona os próximos passos. Mais de 60 perguntas já foram mapeadas até agora. Ela vem evoluindo o agente desde a apresentação no PM3 Summit e estima que ele economiza cerca de 1 hora por dia, tempo usado para de fato decidir e buscar respostas e conexões que ajudem a resolver cada uma das questões, desenvolvendo um produto melhor para os clientes.

O PM como arquiteto do fluxo de trabalho

Juntos, os três casos descrevem a mesma mudança. A IA executa e documenta. O PM analisa, valida e decide. O papel se afasta da execução e se aproxima de decidir o que deve ser feito, como o trabalho deve fluir e o que conta como um bom resultado.

Essa mudança é sustentada por ferramentas com papéis específicos. O Cursor funciona como um copiloto técnico para explorar código, repositórios e pull requests, enquanto o Claude Cowork cuida de skills, automações recorrentes e análises. Gemini e ChatGPT cobrem revisões de texto e uma segunda opinião sobre os resultados do Claude em cenários complexos. Figma Make e Claude Design cobrem wireframes e protótipos rápidos. Conexões MCP com ferramentas como Glean, Databricks, GitHub, Atlassian, Slack, Miro e Google Drive dão a esses agentes acesso ao contexto da empresa de que precisam.

O contexto é o que une a stack. Um agente que consegue ler a documentação certa, encontrar o dataset certo ou ver as conversas do dia é muito mais útil do que um modelo mais poderoso trabalhando isoladamente.

Comece com uma etapa, depois construa um sistema

Para PMs que querem seguir na mesma direção, as recomendações de Scarlatti são deliberadamente práticas. O primeiro agente não precisa ser perfeito, nem construído na melhor ferramenta disponível. Pode começar com o que o time de TI da empresa já permite e melhorar por meio de iteração. O prompt pode seguir a estrutura que os PMs já usam para requisitos: o problema, o comportamento atual e o comportamento desejado.

A partir daí, o objetivo é construir sistemas, e não interações isoladas. Skills, contexto compartilhado e documentação viva fazem com que cada sessão alimente a próxima, em vez de começar do zero toda vez. Ao longo do caminho, os PMs devem confiar no que sabem sobre seu produto. A IA pode executar e ajudá-los a pensar melhor, mas decidir qual problema vale a pena resolver continua sendo responsabilidade deles.

É também por isso que Scarlatti não enxerga isso como a IA substituindo product managers, nem qualquer outro papel ao redor deles. O que muda é a distribuição de autonomia. Os PMs dependem menos das filas de outras pessoas para análises e pequenas mudanças, e todos os envolvidos ganham mais espaço para focar no que mais importa: o cliente. 

Ainda é cedo, e as práticas descritas aqui continuarão mudando à medida que as ferramentas mudarem. Mas a lição de fundo provavelmente vai permanecer: quando a execução deixa de ser o gargalo, a qualidade do trabalho de um PM depende, mais do que nunca, de quão bem o problema está definido.