Faz vários meses que os desenvolvedores entrevistam clientes sem passar pelo Product Manager.

E três dias atrás, abri meu primeiro pull request no nosso produto principal.

Essas duas frases resumem melhor do que qualquer análise o que está acontecendo nos times de produto com a IA. Os desenvolvedores sobem em direção ao problema, ao cliente e ao ownership de produto. Os PMs descem em direção ao protótipo, ao código e, às vezes, à produção.

Seria possível ver aí duas histórias isoladas. Eu acho, ao contrário, que é o começo de uma inversão mais profunda. Os papéis históricos do product management, do desenvolvimento e do design ficam menos nítidos. As fronteiras se mexem. Mas, ao contrário do que se poderia imaginar, isso não quer dizer que todo mundo vai fazer tudo, nem que as responsabilidades vão desaparecer.

O assunto de verdade não é a IA deixar os times "mais produtivos". O assunto de verdade é que ela aumenta muito a capacidade de produzir. E quando a capacidade de produzir aumenta, o gargalo muda de lugar.

Antes, a restrição costumava ser: "Quanto conseguimos construir?"

Amanhã, ela vira outra: "O que precisa ser construído? Por quê? Para quem? Em que ordem? Com quais riscos?"

É esse deslocamento que embaralha os papéis.

Quando os desenvolvedores produzem mais, o PM vira o gargalo

Um dos gatilhos do assunto é bem simples: com a IA, os desenvolvedores conseguem produzir mais rápido.

Não é só escrever algumas linhas mais depressa. É produzir mais opções, mais variantes, mais protótipos, mais ferramentas pequenas, mais iniciativas. Um desenvolvedor que já era autônomo pode se ver indo três, quatro ou seis vezes mais rápido em certas tarefas. Um time que tinha uma capacidade de entrega limitada pode de repente gerar muito mais coisa para testar, decidir, revisar, priorizar.

O problema é que a capacidade de decidir não aumenta automaticamente no mesmo ritmo.

Se tudo continua tendo que passar pelo PM, ele vira rapidamente o novo ponto de saturação do sistema. Não se trata mais só de escrever specs ou acompanhar um backlog. A carga se desloca para a priorização, a coerência do produto, a validação do sinal do cliente, as decisões de mercado, o impacto no usuário, a estratégia e a gestão das consequências.

A organização pode então achar que resolveu seu problema de velocidade porque os desenvolvedores produzem mais. Na prática, ela só mudou o bloqueio de lugar.

Existem três respostas possíveis.

A primeira é contratar mais PMs. Às vezes é necessário, mas nem sempre é a resposta certa. Se o modelo continua o mesmo, você só acrescenta mais uma camada de decisão.

A segunda é automatizar parte do trabalho operacional do PM: documentação, release notes, materiais de lançamento, análises iniciais, traduções, sínteses, vídeos de demonstração, capturas de tela, elementos de PR. Isso libera tempo, mas não basta para resolver a questão de fundo.

A terceira é redistribuir parte do ownership de produto para quem constrói. É aí que os papéis começam de verdade a se embaralhar.

Acelerar o código não basta

Um erro seria achar que a IA transforma a organização só porque acelera o desenvolvimento.

A velocidade local não cria valor automaticamente. Ela pode até criar mais desordem se o fluxo de trabalho inteiro não mudar. Um time consegue gerar mais código, mais protótipos, mais documentos e mais tickets, e ao mesmo tempo tomar decisões piores.

O fluxo completo precisa ser repensado: ideia, discovery, especificação, prototipagem, desenvolvimento, testes, segurança, lançamento, comunicação, suporte e aprendizado.

Se você coloca agentes de IA em cima de um processo que não mudou, corre o risco de só mudar os gargalos de lugar. O código acelera, aí o produto trava. O produto acelera, aí o design trava. O design acelera, aí a validação técnica trava. A validação acelera, aí o go-to-market ou o suporte não acompanham mais.

A questão, portanto, não é só: "Como deixar os desenvolvedores mais rápidos?"

A questão é: "Como deixar o sistema inteiro capaz de absorver essa velocidade sem perder qualidade, coerência e responsabilidade?"

É por isso que os papéis novos não se resumem a "PM que programa" ou "desenvolvedor que faz produto". Parte das necessidades novas tem a ver com a orquestração dos workflows, a avaliação dos outputs de IA, a memória de produto, a qualidade das decisões, a legibilidade dos repositórios e a capacidade de dar aos agentes um contexto confiável.

O que a IA banaliza no product management

Durante muito tempo, alguns PMs se diferenciavam por sensibilidades ou competências bem distintas.

Alguns eram muito bons de escrita. Outros, de dados. Outros, de benchmark, marketing de produto, discovery, design de experiência ou coordenação de entrega. Essas diferenças não desaparecem por completo. Mas parte do seu valor diferencial cai.

Com a IA, muitas capacidades ficam mais acessíveis:

• escrever uma spec correta;
• produzir uma primeira análise de dados;
• fazer um benchmark;
• redigir uma release note;
• fazer um mockup aceitável;
• sintetizar entrevistas;
• produzir uma primeira versão de jornada;
• transformar uma necessidade em protótipo.

Essas competências não ficam inúteis. Um PM ainda precisa saber julgar uma spec, questionar uma análise, ler um mockup, entender uma síntese de entrevistas ou julgar um protótipo. Mas a produção inicial desses artefatos fica menos rara.

Antes, um PM podia se diferenciar bastante porque sabia produzir rápido uma boa spec, um benchmark claro, uma síntese aproveitável ou um primeiro mockup. Amanhã, isso vai ser cada vez mais o nível mínimo.

Isso deixa vulneráveis os PMs que eram fortes sobretudo pela capacidade de execução intermediária. Quem coordenava, redigia, administrava, acompanhava, reformulava e produzia artefatos corretos sem sustentar um julgamento de produto forte corre o risco de perder parte do seu valor.

A profissão de produto não desaparece. Mas o nível mínimo dela sobe.

O que continua difícil: o julgamento de produto

Quando produzir fica mais fácil, escolher o que produzir fica mais crítico.

É aí que a profissão de PM mantém seu valor. Não na capacidade de gerar mais artefatos, mas na capacidade de escolher, decidir e arcar com o resultado.

O que continua difícil:

• escolher o problema certo;
• entender um mercado;
• ler o sinal real por trás dos pedidos dos clientes;
• decidir entre o curto prazo e a estratégia;
• dizer não;
• sustentar uma visão coerente;
• criar alinhamento;
• arcar com as consequências de produto, de negócio, técnicas e humanas de uma decisão.

O PM estratégico aumentado se parece cada vez mais com uma espécie de mini CPO. Ele fica menos na administração da entrega, menos na produção mecânica de entregáveis, e mais nas decisões em que nenhuma opção é perfeita.

O papel fica especialmente importante quando não existe boa solução. Só duas ou três opções ruins, com custos diferentes, riscos diferentes, efeitos políticos diferentes, impactos diferentes no cliente. Nesses momentos, a IA pode ajudar a analisar. Ela não pode arcar com isso.

O PM aumentado não é, portanto, simplesmente um PM que vai mais rápido. É um PM que precisa julgar melhor.

A diferenciação se desloca para o sinal do cliente

Se todo mundo consegue construir mais rápido, construir rápido deixa de ser uma vantagem suficiente.

A produção bruta de código vira, em parte, commodity. Não o software. Não a engenharia. Não a arquitetura, a segurança ou a manutenibilidade. Mas a capacidade de produzir rápido uma primeira versão fica menos rara.

A diferenciação de verdade se desloca então para aquilo que os concorrentes não conseguem simplesmente gerar:

• a qualidade do sinal do cliente;
• os dados proprietários;
• o conhecimento do domínio;
• a distribuição;
• a confiança;
• as restrições operacionais;
• os aprendizados acumulados;
• a capacidade de interpretar corretamente o que os clientes pedem de verdade.

Um protótipo rápido só tem valor se testa um sinal real. Fora isso, ele só acelera uma direção errada.

A pergunta estratégica passa a ser: em cima de qual vantagem própria estamos construindo?

Um time aumentado pela IA consegue produzir muita coisa. Mas se não lê melhor o seu mercado, se não entende melhor os seus usuários, se não sabe distinguir um sinal forte de um ruído bem formulado, vai só produzir mais rápido coisas medianas.

É mais uma razão pela qual o PM não desaparece. O papel se desloca para a qualidade da leitura do real.

Os desenvolvedores sobem em direção ao produto

Os desenvolvedores nunca foram simples executores.

Uma especificação completa é uma ficção. Mesmo uma boa spec nunca descreve todos os comportamentos esperados de um produto. Sempre sobram zonas mudas: casos-limite, mensagens de erro, comportamentos implícitos, regras de segurança, tempos de expiração, prioridades invisíveis, microinterações, decisões de fallback.

Nessas zonas, os desenvolvedores já tomam decisões de produto.

A IA deixa essa realidade mais visível. Se um agente escreve parte do código, o humano precisa explicitar o comportamento esperado, decidir sobre os edge cases, definir os critérios de aceitação, verificar o resultado. As microdecisões que eram absorvidas em silêncio dentro da implementação ficam mais visíveis, e portanto mais importantes de serem delimitadas.

Essa é uma das razões pelas quais os desenvolvedores sobem em direção ao produto. Eles falam mais com os clientes, entendem melhor os problemas, assumem mais ownership sobre suas funcionalidades, tomam decisões locais mais explícitas.

Mas tem uma nuance importante: um desenvolvedor não vira product engineer só porque usa um agente de código ou porque entrega mais rápido.

Se ele não tem acesso aos clientes, aos dados, ao contexto de negócio e às decisões difíceis, corre o risco de só virar um operador de agentes de código. Mais responsabilidades, mais pressão, mas não necessariamente mais poder de produto.

O product engineer de verdade não é só um desenvolvedor rápido. É alguém que carrega parte do julgamento de produto o mais perto possível da construção.

Os PMs descem em direção à construção

O movimento inverso também existe.

Com a IA, um PM consegue materializar uma ideia muito mais rápido do que antes. Um mockup, um protótipo, uma ferramenta interna, um dashboard, uma tradução, uma alteração de interface, às vezes até um PR supervisionado e com escopo definido.

Isso muda a natureza do trabalho.

Antes, era comum ter que passar por uma sequência longa: formular a necessidade, escrever a spec, fazer o mockup, pedir uma estimativa, esperar uma janela, mandar desenvolver, testar, ajustar. Hoje, em certos assuntos, dá para ir muito mais rápido da intuição a um artefato manipulável.

E às vezes nem se trata mais de prototipar. Em casos simples ou bem delimitados, dá para codar algo quase real: um dashboard, uma tela só de leitura, uma melhoria de interface, uma automação interna, uma tradução, um material de release.

Isso não quer dizer que o PM vira desenvolvedor no sentido clássico. Quer dizer que ele consegue atuar em zonas de construção que antes estavam fora do seu escopo.

Vale distinguir aqui alguns níveis.

O PM ou PO prototipador transforma uma intenção de negócio em protótipo ou POC.

O Product Builder vai além: ele constrói artefatos tangíveis, ferramentas internas, dashboards, primeiras versões, contribuições supervisionadas e com escopo definido.

O Product Engineer vai mais longe ainda: ele consegue levar uma responsabilidade de produto até o entregável de produção. E esse papel pode vir de dois caminhos. Um desenvolvedor que sobe em direção ao produto. Ou um perfil de produto suficientemente técnico que desce em direção à produção.

O critério, portanto, não é a profissão de origem. O critério é o nível de ação.

A pessoa fica no nível do mockup? Ela produz um protótipo? Ela abre um PR? Ela leva um entregável até virar produto? Ela entende os riscos o suficiente para que aquilo que produz seja validado corretamente?

É esse continuum que é novo.

Os papéis se embaralham, as responsabilidades continuam

O risco seria concluir que, como os papéis se embaralham, as responsabilidades se dissolvem.

Eu penso exatamente o contrário.

Quanto mais os papéis se embaralham, mais é preciso deixar as responsabilidades claras.

Uma escolha de produto continua sendo uma escolha de produto. Ela cabe ao produto: visão, posicionamento, coerência, decisões, grandes princípios, leitura de mercado, sinal do cliente.

Uma escolha técnica continua sendo uma escolha técnica. Ela cabe à técnica: segurança, performance, escalabilidade, arquitetura, manutenibilidade, qualidade de plataforma.

Uma escolha de experiência continua sendo uma escolha de experiência. Ela cabe ao design ou ao front: design system, coerência de uso, acessibilidade, nível de exigência de UX.

A organização que funciona não é aquela em que cada um faz tudo no seu canto. É aquela em que cada um pode atuar além do seu domínio inicial porque existem responsáveis que definem os padrões, as salvaguardas e os limites.

Um PM pode abrir um PR. Mas ele é revisado, aceito, corrigido ou recusado.

Se ele é recusado dez vezes seguidas, isso diz alguma coisa. Talvez o PM ainda não tenha o nível para esse tipo de contribuição. Talvez o assunto seja arriscado demais. Talvez o time técnico também ainda não tenha estabelecido as diretrizes, as ferramentas ou as salvaguardas que permitem a outros perfis contribuir com segurança.

O PR ou o MR vira então um mecanismo de governança. Não só uma ferramenta técnica.

Tudo depende do par competência / risco

A pergunta certa não é: "Um PM pode subir para produção?"

A pergunta certa é: "Em qual escopo, com qual competência, qual risco e quais salvaguardas?"

É preciso uma gradação simples.

Risco baixo: traduções, conteúdos, dashboards, telas só de leitura, ferramentas internas não críticas.

Risco médio: pequenas ações de escrita, workflows internos, alterações de interface supervisionadas.

Risco alto: pagamento, permissões, segurança, dados sensíveis, lógica de negócio crítica, produto regulado, arquitetura.

Mesmo num produto regulado, nem tudo tem o mesmo nível de risco. Um dashboard ou uma tela de consulta pode ser relativamente seguro se as regras são claras e a validação técnica existe. Inversamente, um produto aparentemente simples pode conter uma zona muito sensível se ele toca nos dados, nas permissões ou numa decisão de negócio irreversível.

A analogia com um desenvolvedor júnior ajuda. Você não entrega as chaves do motor do produto para alguém no primeiro dia. Começa por escopos simples, e depois vai ampliando aos poucos.

O PM aumentado pode seguir a mesma lógica: traduções, telas só de leitura, dashboards, pequenas escritas, e eventualmente contribuições mais críticas se a competência, o contexto e as salvaguardas acompanharem.

A fratura entre perfis de PM

Nem todos os PMs vão conseguir virar builders ou product engineers no mesmo ritmo.

No curto prazo, os PMs com bagagem técnica levam vantagem. Eles sabem ler um repositório, entender um erro, conversar com um agente de código, interpretar o que foi gerado, perceber certas bobagens, pedir uma revisão técnica no lugar certo.

Um PM sem essa cultura pode aprender, claro. Mas corre o risco de ficar limitado ao mockup ou ao protótipo superficial enquanto não entender o suficiente daquilo que a IA produz.

A IA ainda é pouco confiável para que se possa ignorar totalmente o que acontece embaixo do capô. Se você não entende minimamente os erros produzidos, fica difícil ir além do mockup confiável.

Isso não quer dizer que os perfis não técnicos estão condenados. No médio ou longo prazo, pode até acontecer o contrário. Se os agentes ficarem muito mais confiáveis, perfis vindos da psicologia, das letras, da filosofia, do design, da pesquisa ou do negócio podem levar vantagem pela capacidade de expressar com finura uma realidade humana, social ou de domínio.

Mas no estado atual das ferramentas, a fratura existe.

Os PMs que não quiserem virar builders provavelmente vão precisar crescer muito em outras dimensões: estratégia, mercado, discovery, influência, compreensão humana, qualidade de expressão, capacidade de dizer não e de orientar um time.

As novas profissões nem sempre são profissões

Fala-se muito em "novas profissões". O termo é útil, mas pode enganar.

Nem todos esses papéis vão virar necessariamente títulos de RH estabilizados. Alguns vão virar cargos. Outros vão continuar como competências distribuídas no time. Outros ainda vão ser absorvidos por Product Ops, Design, Engenharia ou QA.

O ponto importante não é o título. É a responsabilidade.

Quem julga?

Quem constrói?

Quem garante?

Quem avalia?

Quem mantém a memória?

Quem orquestra os workflows?

A IA torna visíveis responsabilidades que às vezes eram implícitas ou secundárias: a avaliação dos outputs probabilísticos, a documentação aproveitável por agentes, a memória de produto, a orquestração dos workflows, a qualidade do contexto, a legibilidade do repositório, a clareza dos critérios de aceitação.

Essas necessidades não são periféricas. Elas ficam centrais assim que um time trabalha com agentes.

O PM não desaparece, o nível mínimo sobe

O product management não desaparece.

Mas a profissão fica menos tolerante com os perfis que viviam sobretudo de coordenação, redação, acompanhamento e produção de artefatos intermediários.

Amanhã, vai ter menos espaço para o PM administrativo.

Vai ter mais espaço para dois tipos de perfil.

De um lado, quem sabe construir o suficiente para acelerar o aprendizado de produto: prototipar, materializar, testar, contribuir, às vezes chegar até um entregável real.

Do outro, quem sabe julgar bem o suficiente para orientar um time que consegue construir muito mais rápido do que antes: entender o mercado, ler o sinal, decidir, dizer não, sustentar uma visão, proteger a coerência e arcar com as consequências.

Entre esses dois polos, vão existir muitas combinações. Mas o nível mínimo vai subir.

A IA não elimina o product management. Ela obriga a profissão a voltar a ser o que sempre deveria ter sido: uma responsabilidade de criação, de julgamento e de impacto.

Apêndice: catálogo dos futuros papéis de produto

Este apêndice não tenta prever os futuros títulos do LinkedIn. Ele descreve, isso sim, as zonas de responsabilidade que ficam visíveis com a IA.

PM estratégico aumentado

PM que automatiza parte da execução intermediária para se concentrar na visão, nas decisões, na coerência do produto e na leitura do sinal do cliente.

Seu valor é escolher os problemas certos, decidir quando nenhuma opção é perfeita, proteger o posicionamento e manter o alinhamento entre mercado, estratégia, usuários e execução.

Seu risco é ser confundido com um PM simplesmente mais produtivo, ou virar o novo gargalo se toda a decisão continua subindo até ele.

PM ou PO prototipador

Perfil de produto capaz de transformar rápido uma intenção de negócio em protótipo, POC, ferramenta interna ou primeira jornada testável com a ajuda da IA.

Seu valor é reduzir a ambiguidade entre negócio, produto e tech.

Seu risco é ficar no nível do mockup ou contornar cedo demais os desenvolvedores em assuntos que pedem uma reflexão técnica de verdade.

Product Builder

Perfil de produto capaz de transformar diretamente uma ideia em artefato testável, protótipo funcional, ferramenta interna ou contribuição supervisionada e com escopo definido.

Seu valor é reduzir o tempo entre a intuição e a demonstração.

Seu risco é confundir um protótipo que funciona com um produto sustentável de manter.

Product Engineer

Perfil capaz de levar uma responsabilidade de produto até o entregável de produção: compreensão do usuário, escolha da solução, construção, entrega, medição e impacto.

Ele pode vir de um background de desenvolvedor ou de um background de produto suficientemente técnico.

Seu valor é redistribuir parte do julgamento de produto o mais perto possível da construção e reduzir a distância entre ideia, protótipo e produção.

Seu risco é duplo: achar que um desenvolvedor vira product engineer sem acesso real aos clientes, aos dados, ao contexto de negócio e às decisões difíceis; ou achar que um PM pode virar product engineer sem capacidade de entender, fazer validar e manter um entregável de produção.

Product Systems Designer

Papel que desenha os sistemas de produto alimentados por IA: feedback, discovery, geração de specs, roteamento dos insights, documentação viva e workflows de release.

Seu valor é melhorar os mecanismos que permitem ao time tomar decisões melhores de forma contínua.

Seu risco é virar uma função abstrata demais se não estiver ligada aos workflows reais do time.

AI Product Evaluator

Papel encarregado de avaliar os outputs de IA dentro do produto: qualidade, alucinações, UX de falha, robustez, testes de negócio e coerência com a intenção de produto.

Seu valor é tornar testável a qualidade de um produto probabilístico.

Seu risco é ser reduzido a um QA clássico, quando a avaliação trata também da intenção de produto, da confiança e da aceitabilidade.

Product Knowledge Curator

Papel que mantém a memória de produto numa forma aproveitável pelos humanos e pelos agentes.

Seu valor é tornar as decisões passadas, o sinal do cliente, as restrições, as decisões difíceis e a documentação realmente acionáveis.

Seu risco é produzir uma documentação pesada em vez de uma memória viva.

Product Ops agêntico

Product Ops especializado na orquestração das ferramentas, automações e agentes que sustentam o trabalho de produto.

Seu valor é manter os workflows de IA que atravessam o product management: feedback, briefs, discovery, release notes, documentação, medição de impacto.

Seu risco é automatizar ruído se os critérios de qualidade e o ownership não estiverem claros.

Três famílias de papéis

Dá para ler esses papéis em três famílias.

Os papéis de julgamento: PM estratégico aumentado.

Os papéis de construção: PM ou PO prototipador, Product Builder, Product Engineer.

Os papéis de sistema: Product Systems Designer, AI Product Evaluator, Product Knowledge Curator, Product Ops agêntico.

O título importa menos do que a responsabilidade. Nos times aumentados pela IA, a pergunta central vai ser menos "qual é o seu papel?" e mais "o que você é capaz de julgar, construir, garantir, avaliar ou manter?"