Para Marty Cagan, a IA não acaba com o PM: acaba com dois tipos de PM

Todo founder já ouviu as duas versões contraditórias: "o cargo de product manager está morrendo" e "product manager vai ser o cargo mais importante da era da IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →". Em keynote para o Product Leader Summit 2026, publicada em texto no dia 6 de novembro no site da Silicon Valley Product Group, Marty Cagan dá a explicação mais simples que já vi pra essa contradição: as duas frases estão certas, porque existem três cargos diferentes escondidos sob o mesmo título, e a IA só está acelerando um divórcio que já devia ter acontecido.

A tese de Cagan é direta. O que define o trabalho de um PM não é a empresa, o produto ou o setor: é o modelo operacional. Empresas que rodam no modelo de projeto (roadmap de features priorizadas, com solução já prescrita) geram dois cargos: o PM de feature team e o product owner de Scrum↳Scrum7 conteúdosPMP vs Scrum Master: Qual certificação escolher em 2026?Marketing Tech · nov 2025Scrum passo a passo para implementação do Ágile MarketingGestão Dev & TI · jul 2020Scrum Gathering anuncia novidadesDev (Back & Front) · mai 2019Ver tudo em Gestão Dev & TI → ou SAFe. Empresas que rodam no modelo de produto (roadmap de problemas a resolver, com outcome em aberto) geram um terceiro: o PM de empowered team. São ofícios diferentes, com habilidades diferentes, e é aí que mora o problema de quem está contratando ou formando esse time hoje.

Os dois cargos que a automação já está apagando

O PM de feature team, segundo Cagan, nunca foi de fato um gerente de produto: era um gerente de projeto disfarçado, cuja função era coordenar recursos para entregar uma solução que o roadmap já tinha decidido de antemão. É o PM que um dia escreve documentação, no outro faz QA, no outro ainda mexe em front-end↳Front-end60 conteúdosFront-end em larga escala: quando seu projeto vira um Frankenstein (e como evitar)Dev (Back & Front) · mar 2026Build e bundling no front-end: 7 decisões que impactam performance de verdadeDev (Back & Front) · abr 2026Como modelar APIs pensando no front-end: 8 práticas para evitar retrabalho entre timesDev (Back & Front) · abr 2026Ver tudo em Dev (Back & Front) → simples. Esse é exatamente o tipo de trabalho que a IA agêntica está automatizando primeiro, porque empresas estão correndo para montar o que Cagan chama de "fábrica de software": agentes fazendo o que antes era função de QA, de release manager e desse PM.

O product owner de squads ágeis corre risco parecido, e por um motivo mais específico ainda: seu trabalho é gerenciar backlog de entrega e coordenar sprint. Se a IA acelera e automatiza boa parte do próprio processo de entrega, o ritual em torno do qual o product owner organiza seu dia perde sentido. Cagan é direto: "o papel dedicado de product owner vai se resolver sozinho", e ele vem recomendando que essas pessoas façam upskilling o quanto antes.

Para quem funda ou lidera uma empresa de tecnologia, isso não é um debate acadêmico de nomenclatura. Se o seu time de produto hoje gasta a maior parte do tempo em cerimônia de sprint, priorização de backlog e coordenação de entrega de features já definidas, você está pagando salário de PM por um trabalho que a própria dinâmica do mercado está tornando redundante, independente do que está escrito no cargo.

O cargo que sobra, e por que ele fica mais raro

O PM de empowered team é outra coisa. Sua responsabilidade central não é entregar uma solução prescrita, é ajudar a descobrir qual solução resolve o problema e entrega o outcome prometido. Isso exige o que Cagan chama de discovery de produto: testar protótipos com usuários (valor e usabilidade), com stakeholders (viabilidade) e com engenheiros (viabilidade técnica), usando técnicas qualitativas e quantitativas, não achismo de reunião.

Essa é a parte do trabalho que a IA ainda não sabe fazer bem, porque não é um workflow definido, é julgamento. Cagan nota que a IA ajuda nesse processo (entender dinâmica de mercado, concorrência, comportamento de cliente), mas como ferramenta de apoio ao product sense, não como substituto dele. É por isso que esse é o único dos três perfis em alta demanda agora, segundo ele.

Por que isso pesa mais ainda em produto de IA

Aqui entra o ponto que mais importa pra quem está construindo um produto probabilístico, ou seja, um produto cujo comportamento depende de modelo e não é determinístico. Cagan argumenta que o PM de empowered team precisa estar no centro do processo de eval, a definição do que conta como resultado bom ou aceitável, justamente porque os riscos de viabilidade (unit economics, responsabilidade legal, segurança, privacidade, ética) são maiores e menos previsíveis do que em produto convencional.

Traduzindo pra quem está levantando rodada ou decidindo headcount: se o seu produto usa IA generativa de forma central, terceirizar a decisão de "isso está bom o suficiente pra lançar" só pra engenharia ou só pra um agente é delegar exatamente o tipo de julgamento de viabilidade que Cagan diz ser o núcleo do cargo que sobrevive. Não é tarefa de automação, é tarefa de responsabilização.

O sinal que já aparece na contratação

Cagan cita uma observação recente de Shreyas Doshi, que resume bem o que já está mudando nos processos seletivos:

Gerentes de produto que historicamente viam seu papel como "meu trabalho principal é executar" estão achando bem mais difícil conseguir vaga em empresas de ponta do que aqueles que sempre viram seu papel como "meu trabalho é fazer o produto dar certo". Por umas duas décadas, muitas empresas (e lideranças) passaram, explícita ou implicitamente, a mensagem de que o trabalho principal de um PM é execução. A verdade é que execução, por mais importante que seja, nunca foi o trabalho principal. Garantir o sucesso do produto sempre foi.

Shreyas DoshiProduct Managers who've historically viewed their role as "my main job is to execute" are finding it way harder to get hired at top companies than those who've viewed their role as "my main job is to make the product successful". For a couple of decades now, many companies (and leaders) were explicitly or implicitly giving PMs the unfortunate message that a PM's main job is execution. The truth is that execution, while extremely important, was never a PM's main job. Enabling product success was always the main job.

Se você entrevista candidatos a PM, essa é uma pergunta de corte melhor do que qualquer case de framework: peça pra pessoa descrever a última vez que ela matou uma feature própria por causa de dado de discovery. Quem só sabe descrever entregas é, na definição de Cagan, um product owner com nome bonito no LinkedIn.

O contra-argumento que não dá pra descartar

O próprio Cagan menciona que "alguns líderes importantes do setor proclamam que o cargo de produto está morto". Vale levar essa visão a sério, porque ela tem um fundo verdadeiro: se a IA hoje já ajuda a entender mercado e concorrência, é razoável apostar que, em algum horizonte, ela consiga rodar partes maiores da pesquisa de usuário sozinha, achatando ainda mais a necessidade de um humano no meio do discovery.

O ponto fraco dessa visão, pra mim, é tratar discovery como coleta de informação. Não é. É julgamento sobre viabilidade de negócio, exposição legal, ética e trade-off estratégico, decisões que carregam responsabilização que uma empresa não pode terceirizar pra um sistema sem accountability formal. Agente de IA não assina termo de responsabilidade com investidor nem responde a processo de privacidade. Enquanto isso for verdade, o PM de empowered team segue sendo o nome que a empresa aponta quando a decisão de produto dá errado, e é esse peso que mantém o cargo relevante mesmo que a ferramenta ao redor dele mude todo ano.

A pergunta pra fazer no seu próprio time

Antes de cortar ou contratar PM achando que está "se adaptando à IA", olhe pro que a pessoa realmente faz no dia a dia. Se o trabalho dela é majoritariamente coordenar entrega de algo que o roadmap já decidiu, você está pagando por um cargo que a própria indústria está deixando de precisar, com ou sem IA. Se o trabalho dela é decidir, com evidência, o que vale a pena construir e assumir a responsabilidade por esse julgamento, você está protegendo exatamente a parte do produto que nenhum agente substitui ainda.

Fonte: SVPG (Marty Cagan)