Por que Product Managers brasileiros estão perdendo relevância (e como recuperar)

Na semana passada, três coisas aconteceram quase simultaneamente. Nikhyl Singhal, ex-VP de Produto do Meta e Google, publicou um alerta direto: metade dos PMs está em perigo. Cat Wu revelou como a equipe de produto da Anthropic trabalha de forma radicalmente diferente. E a confusão sobre preços de ferramentas de IA — de Claude a GitHub Copilot — expôs quanto a estrutura de custos de desenvolvimento está mudando.

Não são eventos isolados. É um padrão que precisa de atenção.

O que Nikhyl Singhal está dizendo (e por que importa)

Singhal não é um influenciador de LinkedIn fazendo previsões genéricas. Ele liderou produto em Google, Meta e Credit Karma. Quando ele diz que metade dos PMs está em risco, ele está olhando para padrões de mercado que já observou antes — em outras ondas tecnológicas que redistribuíram poder dentro das empresas.

O argumento dele é específico: muitos PMs construíram carreiras em torno de atividades que estão sendo automatizadas ou eliminadas. Escrever specs. Organizar backlogs. Facilitar comunicação entre times. Criar documentação de produto.

Essas atividades não desapareceram. Mas deixaram de exigir uma pessoa dedicada em tempo integral.

A armadilha do PM operacional

No Brasil, esse problema é amplificado. O mercado de produto digital cresceu rápido nos últimos anos. Muita empresa contratou PMs para resolver um problema específico: alguém precisa organizar o backlog e garantir que o time de engenharia tenha contexto suficiente para trabalhar.

Esse papel é legítimo. Mas não é estratégia de produto.

O PM operacional:

• Traduz pedidos de stakeholders em tickets
• Prioriza features por pressão política, não por impacto
• Mede sucesso por entrega, não por resultado
• Conhece bem o Jira, mas não conhece bem o usuário

Quando Claude Code, Cursor ou GitHub Copilot aceleram a velocidade de desenvolvimento em 3x ou 5x, o gargalo muda de lugar. O problema deixa de ser “transformar decisões em código” e passa a ser “tomar decisões certas”.

E tomar decisões certas nunca foi o trabalho do PM operacional.

O que a Anthropic está fazendo diferente

Cat Wu, que lidera produto na Anthropic, descreveu recentemente como a equipe funciona. O modelo é diferente do que você vê na maioria das empresas brasileiras.

PMs na Anthropic não são facilitadores. São responsáveis por visão e direção. Eles passam mais tempo com usuários do que com stakeholders internos. Eles definem o problema antes de pedir soluções. E — ponto crítico — eles entendem profundamente as capacidades e limitações da tecnologia que estão construindo.

Não é um modelo que funciona para todo tipo de empresa. Mas revela uma mudança estrutural: quando a velocidade de execução aumenta, o valor migra para quem sabe o que executar.

PM operacional (em risco)

• Foco em backlog e entregas
• Prioriza por pressão interna
• Mede sucesso por features lançadas
• Conhece ferramentas de gestão
• Comunica entre times

PM estratégico (em demanda)

• Foco em problema e resultado
• Prioriza por impacto comprovado
• Mede sucesso por métricas de negócio
• Conhece usuário e tecnologia
• Define direção e visão

Por que isso está acontecendo agora

Três forças convergindo:

Ferramentas de IA aceleraram execução. GitHub Copilot, Claude Code, Cursor — o tempo entre “decidir fazer” e “ter feito” diminuiu drasticamente. Isso não elimina a necessidade de produto. Mas elimina a justificativa para um intermediário que só traduz decisões em tarefas.

Custos de desenvolvimento estão em fluxo. A confusão recente sobre preços de APIs de IA (Claude subiu quanto? Desceu? Para quem?) expõe que a estrutura de custos de construir software está mudando. Empresas que dependiam de PMs para “otimizar” roadmaps por restrição de recursos estão descobrindo que o recurso escasso não é mais engenharia — é clareza de direção.

Expectativas de liderança mudaram. Quando CEOs veem o que times pequenos com IA conseguem entregar, a tolerância para processos lentos de produto diminui. A pergunta deixa de ser “quando vai ficar pronto?” e passa a ser “por que estamos construindo isso?”.

O que PMs precisam desenvolver agora

Singhal é direto sobre o que separa PMs que vão prosperar dos que vão lutar para se manter relevantes. Não são skills técnicos de IA. São capacidades que sempre diferenciaram bons PMs — mas que agora se tornaram obrigatórias, não diferenciais.

• Você consegue defender uma direção de produto sem dados completos?
• Você passa mais tempo com usuários do que em reuniões internas?
• Você sabe explicar por que não fazer algo é mais importante que o roadmap?
• Você entende as capacidades técnicas do que está construindo?
• Você mede sucesso por mudança de comportamento, não por entregas?

Se você respondeu “não” para mais de duas perguntas, o alerta de Singhal se aplica a você.

A competência que ninguém está falando

Muito do debate sobre “futuro do PM” foca em aprender a usar ferramentas de IA. Isso é necessário, mas não suficiente.

A competência que vai separar PMs nos próximos anos é capacidade de julgamento sob incerteza.

Quando você pode testar mais rápido, a pergunta muda de “como validar?” para “o que vale a pena testar?”. Quando você pode construir mais rápido, a pergunta muda de “como priorizar?” para “o que não deveria existir?”.

PMs que prosperam nesse ambiente são os que conseguem tomar decisões com informação incompleta, defender essas decisões com argumento sólido, e ajustar rápido quando estão errados — sem precisar de seis meses de dados para agir.

O que fazer na prática

Se você é PM no Brasil e está lendo isso com desconforto, aqui está o que eu recomendaria:

Primeiro, audite seu tempo. Na última semana, quanto tempo você gastou em atividades que uma IA poderia fazer (escrever specs, organizar tarefas, criar documentação) versus atividades que exigem julgamento humano (entrevistar usuários, tomar decisões de trade-off, definir direção)?

Se a proporção está 70/30 para o lado automatizável, você tem um problema de posicionamento, não de skill.

Segundo, aumente contato direto com usuários. Não pesquisa delegada. Não survey analisado por outro time. Conversa direta, regular, com pessoas que usam (ou não usam) o que você está construindo. Isso não é romantismo de produto. É a única forma de desenvolver intuição que não pode ser automatizada.

Terceiro, aprenda a tecnologia de verdade. Não para virar desenvolvedor. Para saber o que é possível, o que é fácil, o que é difícil, e o que é impossível com a stack atual. PM que não entende tecnologia sempre foi um problema. Agora é insustentável.

Quarto, pratique tomar decisões explícitas. Muitos PMs se escondem atrás de processo: “vamos priorizar no planning”, “vamos ver o que os dados dizem”, “vamos alinhar com stakeholders”. Isso é evitar decisão, não tomar decisão. O PM estratégico diz: “estamos fazendo X porque Y, e não fazendo Z porque W”. E assume a responsabilidade.

O paradoxo brasileiro

O mercado de produto no Brasil tem uma característica peculiar. Muitas empresas ainda operam com estruturas de produto de 2018 — times grandes, processos lentos, PMs como coordenadores de backlog — enquanto competem com startups e empresas globais que já reorganizaram como trabalham.

Isso cria uma janela interessante. PMs que se reposicionarem agora vão encontrar demanda. As empresas que estão acordando para essa mudança precisam de pessoas que sabem trabalhar nesse novo modelo. E não tem muita gente disponível.

Mas a janela não vai durar muito. O alerta de Singhal não é previsão de futuro distante. É diagnóstico de presente.

A escolha que você precisa fazer

Não existe posição neutra aqui. Se você é PM e continua fazendo o mesmo trabalho da mesma forma, você está escolhendo o lado do risco. Não por incompetência — por inércia.

A boa notícia: a mudança não exige que você aprenda a programar ou vire especialista em IA. Exige que você faça o trabalho que sempre deveria ter sido o trabalho de PM. Só que agora não dá mais para adiar.