Marty Cagan: por que a IA não apaga o papel de produto

No meio da euforia que promete que qualquer pessoa vai virar construtor de software com IA, uma das maiores autoridades em gestão de produto puxou o freio com elegância. Em artigo publicado em 10 de agosto de 2026, Marty Cagan, autor de Inspired e Transformed e sócio da Silicon Valley Product Group, se apoia no analista Benedict Evans para dar uma das melhores definições recentes do papel de produto na era da IA. O recado, resumido: a IA baixa a barreira de construir, mas não elimina a parte difícil, que é saber o que deve existir e por quê. Essa parte continua sendo trabalho de gente com julgamento de produto, e esse julgamento segue escasso.

Quem fala, e por que ouvir

Cagan não é um comentarista de ocasião. Passou décadas definindo o que é o trabalho de produto, e diz ter visto ao longo da carreira mais de cem definições diferentes do papel do product manager. Ele conta que pergunta a candidatos como eles definem o próprio papel há décadas, e que a resposta funciona como um teste de Rorschach: revela o modelo de produto em que a pessoa trabalhou e o que ela acha que o papel contribui para o time.

O gatilho do artigo foi um texto do analista Benedict Evans, chamado "Most People Aren't Tool Builders", algo como "a maioria das pessoas não é fabricante de ferramenta". Evans não é um product manager, mas conhece a indústria de tecnologia como poucos, e Cagan diz que o texto, sem sequer usar a palavra produto, entregou uma das melhores descrições das habilidades do papel que ele já viu. A honestidade de creditar a boa ideia a outro é, por si, uma lição de quem tem repertório.

As três habilidades que a IA não distribui

O coração da tese está em três habilidades que Evans descreve e Cagan traduz para o vocabulário de produto. Vale seguir a ordem, porque ela é cumulativa.

A primeira é enxergar o problema geral por trás da dor. Muita gente reconhece uma dor e até tem ideia para resolvê-la, mas poucas conseguem ver o problema mais amplo que está por trás daquela dor ou daquele pedido. Cagan diz que, depois de tantos anos, isso virou segunda natureza para ele, e é fácil esquecer que a maioria não enxerga essas oportunidades. No jargão de produto, é a descoberta de problema.

A segunda é descobrir uma solução que de fato funcione. Aqui Evans crava a frase que dá título ao raciocínio: as pessoas que são muito boas em usar a ferramenta não são as mesmas que são muito boas em criar a ferramenta. E ilustra: você precisa saber muito sobre vendas para fazer um bom software de vendas, mas ser bom em vendas não te torna bom em fazer software de vendas. No vocabulário de produto, é o risco de valor, a solução resolve mesmo a dor do cliente?

A terceira é garantir que a solução funcione para o negócio inteiro. Além de atender ao cliente, a solução precisa caber na empresa, tocando vendas, marketing, finanças, compliance, jurídico e mais. Ela pode depender de dado regulado, precisar integrar com sistema legado ou entrar em vários fluxos de trabalho diferentes. É o risco de viabilidade, e é o que separa protótipo de coisa que entra em produção sem quebrar o resto da operação.

A IA muda os limiares, não o problema. Escrever o código nunca foi a parte difícil, e fazer a ferramenta nunca foi a parte difícil. A parte difícil é saber que ela deve existir, e saber como ela deve existir. E isso é outra pessoa.

Essa frase de Evans, citada por Cagan, é o núcleo. A IA derruba o custo e o tempo de construir. Não derruba o custo de julgar o que vale construir.

Nossa leitura: o gargalo mudou de lugar, não sumiu

O erro que Cagan admite ter cometido, e que vê muita gente de produto cometendo, é confundir a si mesmo com o cliente. Times de produto assumem que os clientes vão usar IA do jeito que eles usam. Mas, como resume Evans, a IA facilita para qualquer um construir ferramenta para automatizar o próprio trabalho, só que a maioria das pessoas e das empresas não é fabricante de ferramenta, não pensa assim, e não vai fazer isso. É por isso que empresas de software e consultorias existem. A IA muda o limiar, não o problema.

Para quem opera IA no Brasil, a leitura é direta e libertadora. O medo de que vibe coding e agentes tornem o trabalho de produto obsoleto se inverte: quanto mais barato fica construir, mais caro fica o erro de construir a coisa errada rápido. A velocidade sem julgamento só acelera a entrega de features que não importam. É a mesma conclusão a que chega quem trata a IA como ferramenta poderosa, porém não confiável, como Martin Fowler ao dizer que o maior valor da IA está em entender o que já existe, e como quem organiza o trabalho em torno do job que o cliente realmente quer resolver antes de sair codando.

Na prática, três movimentos saem da tese. Primeiro, invista no julgamento de produto do time, não só nas ferramentas de IA, porque a ferramenta virou commodity e o julgamento não. Segundo, use a IA para acelerar descoberta e entrega, mas mantenha as três perguntas de Evans como filtro: qual é o problema geral, a solução resolve o valor, ela é viável para o negócio inteiro? Terceiro, desconfie da promessa de que o cliente vai se autoatender com IA. Quase sempre ele não vai, e é aí que mora a oportunidade de produto, o que reforça a leitura de que o operador ganha ao investir nas habilidades certas de quem constrói com IA.

A voz de Cagan é valiosa justamente por ser calma e creditada. Ele não anuncia o fim nem a salvação, empresta a lente de um bom analista e a traduz para quem constrói produto. O papel de produto não morre com a IA. Ele fica mais essencial, porque o gargalo mudou de lugar: saiu do construir e foi morar no decidir o que construir.

Se o seu time está construindo mais rápido com IA e sentindo que entrega muita coisa que não move o ponteiro, o problema pode não ser a ferramenta, e sim a descoberta. Fale com a AI Boutique no WhatsApp. A gente ajuda a apontar a IA para o problema certo, com julgamento de produto no centro.