Uma semana depois do AI Festival, fui ao PM3 Summit — o maior evento de produto do Brasil.
O AI Festival trouxe quem constrói IA: Bradesco, MIT, Amazon AGI Labs, Replit, VW. O PM3 trouxe quem constrói produto com IA: PMs, founders, heads de produto de empresas brasileiras.
A diferença de perspectiva foi grande — e reveladora. Porque enquanto o AI Festival mostrou o que já está rodando em escala, o PM3 mostrou onde a maioria dos times ainda está tentando entender o que mudou no trabalho de produto.
Spoiler: mudou muita coisa.
O case da Elo
O case de destaque foi a Elo. E o que tornou esse case importante não foi o volume de agentes — foi o tipo de agente.
A maioria dos times hoje tem agentes de BUILD: escrevem código, fazem review, rodam testes, debugam bugs. É o equivalente de automatizar a execução técnica. Funciona bem, entrega velocidade.
O Elo foi além. Eles construíram agentes de PRODUTO.
São 24 agentes organizados em 3 cadeias especializadas:
Product Flow — conduz o discovery de forma contínua. O fluxo completo: hipótese → tese → PRD → protótipo. O PM não parte de um canvas em branco. Parte de uma estrutura gerada a partir de conversas com usuários, dados de uso, pesquisa de mercado e benchmarks de concorrentes. O agente faz a síntese. O PM faz o julgamento.
Priorização (Treadstone) — roda análise técnica, financeira e estratégica em paralelo antes de qualquer decisão de roadmap. Dados técnicos (complexidade, débito técnico), dados financeiros (impacto em receita, custo de oportunidade), dados estratégicos (alinhamento com visão de produto). O PM recebe um score consolidado com justificativa por item — não uma planilha pra preencher do zero.
Sinais & Ruídos — leitura contínua do mercado. Movimentos de concorrentes, tendências do setor, padrões emergentes em dados de uso, sinais de churn antes que virem crise. Alimenta a estratégia antes que a demanda apareça explicitamente.
O que me impressionou na estrutura do Elo é a separação clara de responsabilidades. Cada cadeia tem um objetivo específico. Cada agente dentro dela tem um papel. Isso é arquitetura de produto aplicada a agentes — não automação improvisada.
O novo gargalo
Houve um consenso que atravessou todas as conversas do PM3:
Quando a execução técnica acelera com IA, a qualidade da visão de produto se torna o novo gargalo.
Antes, o gargalo era velocidade de desenvolvimento. Um PM com boa visão esperava o time entregar. Agora, com agentes de build entregando rápido, o gargalo virou outra coisa: o discovery, a especificação, a clareza do problema.
Quem define mal o problema vai ter velocidade alta na direção errada — que é pior que velocidade baixa na direção certa.
Esse ponto foi repetido de formas diferentes por quase todos os speakers. E é contraintuitivo o suficiente pra merecer atenção: a IA não resolveu o problema de produto. A IA amplificou tanto o bem quanto o mal. Uma visão clara e bem especificada vira produto rápido. Uma visão vaga e mal especificada vira produto errado rápido, com muito código gerado que vai ser jogado fora.
Spec Driven Development
O conceito mais acionável que saí do evento querendo implementar foi o Spec Driven Development, apresentado como evolução natural de como times trabalham com IA.
A progressão que foi descrita:
- Prompt livre — “faz uma feature de login” — resultado imprevisível
- Engenharia de prompt — prompts mais elaborados, mas ainda ad-hoc
- SDD — spec como fonte da verdade, antes de qualquer código
A spec tem cinco elementos obrigatórios:
Goal — o que precisa ser alcançado. Uma frase, não um parágrafo. “Permitir que o usuário recupere a senha via email” — não “melhorar a experiência de autenticação”.
Scope — o que está dentro e o que está explicitamente fora. “Inclui: recuperação por email. Não inclui: recuperação por SMS, login social, 2FA.” A parte do “não inclui” é tão importante quanto a do “inclui”.
Constraints — limitações técnicas, de negócio, de prazo. “Deve funcionar com o sistema de autenticação existente. Não pode modificar a tabela de usuários. Precisa estar pronto em 3 dias.”
Validation — como vamos saber que funcionou. Critérios de aceite concretos, testáveis. “Usuário consegue fazer login com nova senha em menos de 5 minutos após solicitar recuperação.”
Guardrails — o que o agente não deve fazer. “Não altere o layout de outras páginas. Não crie novos endpoints. Não modifique a lógica de autenticação existente.”
Sempre em Markdown (LLMs processam melhor que qualquer outro formato). Sempre escrita por um humano antes de qualquer linha de código.
O que me fez pensar: a diferença entre uma spec boa e uma ruim não é técnica. É disciplina de pensamento. Quem consegue escrever esses cinco elementos com clareza já fez a maior parte do trabalho intelectual da feature.
Discovery contínuo vs discovery em sprint
Um dos debates mais interessantes do evento foi sobre o modelo de discovery.
O modelo tradicional: discovery acontece em sprint, com ciclos de entrevistas e validações espaçadas. O time “para pra pesquisar” e depois “retoma pra construir”.
O modelo com agentes de produto: discovery vira contínuo. Enquanto o time constrói, agentes estão lendo feedbacks, sintetizando padrões em dados de uso, monitorando movimentos de concorrentes. Insights chegam antes da demanda aparecer explicitamente.
A Elo aplica isso com a cadeia Sinais & Ruídos. Em vez de uma sprint de discovery a cada trimestre, o contexto de mercado está sempre atualizado.
A implicação prática: o PM que opera com discovery contínuo entra em qualquer conversa de priorização com mais informação do que o PM que pesquisa esporadicamente. O gap de qualidade na decisão é real.
O que continua sendo humano
O evento foi honesto sobre o que a IA não resolve no trabalho de produto. A lista foi consistente entre os speakers:
- Sentir o que o usuário não diz numa entrevista — o tom, o que evita falar, o que exagera
- Decidir o que importa estrategicamente para o negócio num momento específico
- Navegar política interna e conflito de stakeholders — negociação, influência, contexto de poder
- Julgar contexto cultural e emocional — o que faz sentido pra esse mercado, pra essa empresa, pra esse time
- Responsabilidade pela decisão final — o PM que delegou pro agente ainda responde pelo resultado
A IA acelera síntese, análise, geração de opções e estruturação de informação. Julgamento e responsabilidade continuam sendo humanos — e isso não é limitação, é onde o valor real está.
O PM que tenta automatizar o julgamento vai construir o produto certo na velocidade errada — ou o produto errado muito rápido.
O novo papel do PM
A conclusão que atravessou o evento:
O PM que aprender a dirigir agentes vai ter alavancagem que era impossível antes. O PM que não aprender vai perder espaço para o PM que aprendeu.
Isso não é ameaça — é a mesma dinâmica que aconteceu quando surgiram dados: o PM que sabia trabalhar com dados ganhou escopo e influência. Agora é a vez dos agentes.
A boa notícia: as habilidades necessárias não são novas. Especificar bem, definir problemas com clareza, validar resultados, comunicar decisões — bom PM já deveria fazer isso. O que muda é que agora essas habilidades têm consequências amplificadas. Spec ruim → produto errado gerado rápido. Spec boa → produto certo gerado rápido.
Juntando os dois
Juntando o AI Festival e o PM3 Summit, a imagem que fica é clara:
A era agêntica não é sobre IA ser mais inteligente. É sobre o trabalho humano mudar de natureza. Menos execução manual, mais julgamento. Menos código escrito à mão, mais contexto bem especificado. Menos velocidade cega, mais direção clara.
Quem entender isso cedo tem vantagem. O relógio já está rodando desde 2026.