PM, desenvolvedores e IA: os papéis se confundem, as responsabilidades ficam

Há meses os desenvolvedores entrevistam clientes sem passar pelo Product Manager.

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

Essas duas frases descrevem 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 do produto. Os PMs descem em direção ao protótipo, ao código e às vezes à produção.

Você pode ver nisso duas anedotas isoladas. Eu acho que é o começo de uma inversão mais profunda. Os papéis históricos do product management, do desenvolvimento e do design estão se tornando menos nítidos. As fronteiras estão se movendo. Mas, ao contrário do que se poderia pensar, isso não significa que todo mundo vai fazer tudo, nem que as responsabilidades vão desaparecer.

O ponto central não é que a IA torne os times "mais produtivos". É que ela aumenta muito a capacidade de produzir. E quando essa capacidade aumenta, o gargalo se desloca.

Antes, a restrição era com frequência: "Quanto conseguimos construir?"

Amanhã, ela se torna: "O que deve 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

O gatilho é bem simples: com IA, os desenvolvedores conseguem produzir mais rápido.

Não só escrever algumas linhas mais depressa. Eles produzem mais opções, mais variantes, mais protótipos, mais ferramentas internas, 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 com capacidade de entrega limitada pode de repente gerar muito mais coisas para testar, arbitrar, revisar, priorizar.

O problema é que a capacidade de decidir não aumenta 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 priorização, coerência de produto, validação do sinal dos clientes, arbitragem de mercado, impacto no usuário, estratégia e gestão das consequências.

Uma organização pode achar que resolveu o problema de velocidade porque os desenvolvedores produzem mais. Na prática, só deslocou o gargalo.

Existem três respostas possíveis.

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

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 demo, capturas de tela, conteúdo de PR. Isso libera tempo, mas não resolve a questão de fundo.

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

Acelerar o código não é suficiente

Seria um erro achar que a IA transforma as organizações só porque acelera o desenvolvimento.

Velocidade local não cria valor automaticamente. Pode até gerar mais desordem se o fluxo completo não mudar. Um time pode gerar mais código, mais protótipos, mais documentos e mais tickets enquanto toma 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.

Adicionar agentes de IA a um processo que não mudou só tende a deslocar os gargalos. 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.

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

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

É por isso que os novos papéis não se resumem a "PM que programa" ou "desenvolvedor que faz produto". Parte das novas necessidades é sobre orquestração de workflows, avaliação de outputs de IA, memória de produto, qualidade das decisões, legibilidade dos repositórios e 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 em escrita. Outros em dados. Outros em benchmarking, marketing de produto, discovery, design de experiência ou coordenação de entrega. Essas diferenças não desaparecem completamente. Mas parte do seu valor diferencial cai.

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

• escrever uma spec decente;
• produzir uma análise inicial de dados;
• fazer um benchmark;
• redigir uma release note;
• fazer um wireframe 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 avaliar uma spec, questionar uma análise, ler um wireframe, entender uma síntese de entrevistas ou avaliar um protótipo. Mas a produção inicial desses artefatos se torna menos rara.

Antes, um PM podia se diferenciar fortemente porque sabia produzir rapidamente uma boa spec, um benchmark claro, uma síntese útil ou um primeiro wireframe. Amanhã, isso vai ser mais o nível mínimo.

Isso coloca em risco os PMs que eram fortes principalmente pela capacidade de execução intermediária. Os que coordenavam, redigiam, administravam, acompanhavam, reformulavam e produziam artefatos corretos sem exercer um julgamento forte de produto correm o risco de perder parte do seu valor.

O papel de produto não desaparece. Mas o seu nível mínimo está subindo.

O que continua difícil: o julgamento de produto

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

É aí que o papel de PM mantém seu valor. Não na capacidade de gerar mais artefatos, mas na capacidade de escolher, arbitrar e assumir as consequências.

O que continua difícil:

• escolher o problema certo;
• entender um mercado;
• ler o sinal real por trás das demandas dos clientes;
• arbitrar entre curto prazo e estratégia;
• dizer não;
• sustentar uma visão coerente;
• criar alinhamento;
• assumir 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 um pequeno CPO. Menos na administração da entrega, menos na produção mecânica de entregáveis, e mais nas decisões onde nenhuma opção é perfeita.

O papel se torna especialmente importante quando não existe uma 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 consegue assumir as consequências.

O PM aumentado não é 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 não é mais uma vantagem suficiente.

A produção bruta de código se torna parcialmente uma commodity. Não o software. Não a engenharia. Não a arquitetura, a segurança ou a manutenibilidade. Mas a capacidade de produzir rapidamente uma primeira versão fica menos rara.

A diferenciação real se desloca para o que os concorrentes não conseguem simplesmente gerar:

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

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

A questão estratégica passa a ser: sobre qual vantagem própria estamos construindo?

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

Essa é mais uma razão pela qual o PM não desaparece. O papel se desloca para a qualidade da leitura da realidade.

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 ficam zonas mudas: casos extremos, mensagens de erro, comportamentos implícitos, regras de segurança, timeouts, prioridades invisíveis, micro-interações, decisões de fallback.

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

A IA torna essa realidade mais visível. Se um agente escreve parte do código, o humano precisa explicitar o comportamento esperado, arbitrar os edge cases, definir os critérios de aceitação, verificar o resultado. As microdecisões que eram absorvidas silenciosamente na implementação se tornam mais visíveis — e portanto mais importantes de enquadrar.

Essa é uma das razões pelas quais os desenvolvedores estão subindo em direção ao produto. Falam mais com clientes, entendem melhor os problemas, assumem mais ownership sobre suas funcionalidades, tomam decisões locais de forma mais explícita.

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

Sem acesso a clientes, dados, contexto de negócio e decisões de arbitragem, ele corre o risco de virar um operador de agentes de código. Mais responsabilidades, mais pressão, mas não necessariamente mais poder de produto.

O verdadeiro product engineer 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 wireframe, um protótipo, uma ferramenta interna, um dashboard, uma tradução, uma alteração de interface, às vezes até um PR supervisionado.

Isso muda a natureza do trabalho.

Antes, com frequência era necessário passar por uma sequência longa: formular a necessidade, escrever a spec, fazer o wireframe, pedir uma estimativa, esperar uma janela, mandar desenvolver, testar, ajustar. Hoje, em certos tópicos, dá para ir muito mais rápido da intuição a um artefato tangível.

E às vezes não é só prototipagem. Em casos simples ou bem delimitados, dá para codar algo quase real: um dashboard, uma tela de leitura, uma melhoria de interface, uma automação interna, uma tradução, um suporte de release.

Isso não significa que o PM vira desenvolvedor no sentido clássico. Significa que ele pode intervir em zonas de construção que antes estavam fora do seu perímetro.

Vale distinguir alguns níveis aqui.

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

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

O Product Engineer vai mais longe ainda: consegue levar uma responsabilidade de produto até o entregável de produção. 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 não é a origem profissional. O critério é o nível de capacidade de ação.

A pessoa fica no nível do wireframe? Produz um protótipo? Abre um PR? Carrega um entregável pronto para produção? Entende o suficiente sobre os riscos para validar corretamente o que produz?

Esse continuum é o que é novo.

Os papéis se confundem, as responsabilidades ficam

O risco seria concluir que, já que os papéis se confundem, as responsabilidades se dissolvem.

Penso exatamente o contrário.

Quanto mais os papéis se confundem, mais é necessário clarificar as responsabilidades.

Uma decisão de produto continua sendo uma decisão de produto. Cabe ao produto: visão, posicionamento, coerência, arbitragens, princípios gerais, leitura de mercado, sinal do cliente.

Uma decisão técnica continua sendo uma decisão técnica. Cabe à engenharia: segurança, performance, escalabilidade, arquitetura, manutenibilidade, qualidade de plataforma.

Uma decisão de experiência continua sendo uma decisão de experiência. Cabe ao design ou ao front-end: design system, coerência de uso, acessibilidade, padrão de UX.

A organização que funciona não é a que todo mundo faz tudo no seu canto. É a que cada um pode intervir além do seu domínio inicial porque há responsáveis que definem os padrões, as proteções e os limites.

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

Se é rejeitado 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 de engenharia ainda não tenha estabelecido as diretrizes, as ferramentas ou as proteções que permitem a outros perfis contribuir com segurança.

O PR ou o MR se torna 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 fazer deploy em produção?"

A pergunta certa é: "Em qual perímetro, com qual competência, qual risco e quais proteções?"

É útil ter uma gradação simples.

Baixo risco: traduções, conteúdo, dashboards, telas de leitura, ferramentas internas não críticas.

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

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

Mesmo em um 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 está presente. Por outro lado, um produto aparentemente simples pode conter uma zona muito sensível se tocar em dados, permissões ou uma decisão de negócio irreversível.

A analogia com um desenvolvedor júnior é útil. Você não entrega as chaves do motor de produto para alguém no primeiro dia. Começa com perímetros simples e vai ampliando progressivamente.

O PM aumentado pode seguir a mesma lógica: traduções, leitura, dashboards, pequenas escritas, e eventualmente contribuições mais críticas se a competência, o contexto e as proteções 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 têm vantagem. Eles sabem ler um repositório, entender um erro, dialogar com um agente de código, interpretar o que foi gerado, identificar certas inconsistências, pedir uma revisão técnica no momento certo.

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

A IA ainda é pouco confiável demais para ignorar completamente o que acontece por baixo do capô. Se você não entende minimamente os erros gerados, fica difícil ir além do wireframe seguro.

Isso não significa que os perfis não técnicos estão condenados. No médio ou longo prazo, o oposto pode até acontecer. 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 precisão 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 evoluir 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.

Os novos papéis nem sempre viram novos cargos

Fala-se muito em "novos papéis". O termo é útil, mas pode enganar.

Nem todos esses papéis vão necessariamente virar 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 de outputs probabilísticos, a documentação legível por agentes, a memória de produto, a orquestração de 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. Ficam centrais assim que um time passa a trabalhar com agentes.

O PM não desaparece — o nível mínimo está subindo

O product management não desaparece.

Mas o papel está ficando menos tolerante com perfis que viviam principalmente de coordenação, redação, acompanhamento e produção de artefatos intermediários.

Amanhã, haverá menos espaço para o PM administrativo.

Haverá mais espaço para dois tipos de perfis.

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

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

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

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

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

Este apêndice não tenta prever os futuros títulos do LinkedIn. Ele descreve 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 arbitragens, na coerência do produto e na leitura do sinal dos clientes.

Seu valor está em 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 todas as decisões continuam subindo para ele.

PM ou PO prototypist

Perfil de produto capaz de transformar rapidamente 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 wireframe ou contornar os desenvolvedores cedo demais em tópicos que exigem uma reflexão técnica real.

Product Builder

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

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

Seu risco é confundir um protótipo que funciona com um produto que se mantém.

Product Engineer

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

Pode vir de uma trajetória de desenvolvedor ou de um perfil de produto suficientemente técnico.

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

Seu risco é duplo: acreditar que um desenvolvedor vira product engineer sem acesso real a clientes, dados, contexto de negócio e arbitragens; ou acreditar que um PM pode virar product engineer sem capacidade de entender, validar e manter um entregável de produção.

Product Systems Designer

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

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

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

AI Product Evaluator

Papel responsável por avaliar os outputs de IA no produto: qualidade, alucinações, UX de falha, robustez, testes de negócio e alinhamento com a intenção de produto.

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

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

Product Knowledge Curator

Papel que mantém a memória de produto em uma forma aproveitável tanto por humanos quanto por agentes.

Seu valor é tornar as decisões passadas, o sinal dos clientes, as restrições, as arbitragens e a documentação genuinamente acionáveis.

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

Product Ops agêntico

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

Seu valor é manter os workflows de IA que atravessam o product management: feedback, briefs, discovery, release notes, documentação, mensuraçã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

Esses papéis podem ser lidos em três famílias.

Papéis de julgamento: PM estratégico aumentado.

Papéis de construção: PM ou PO prototypist, Product Builder, Product Engineer.

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. Em 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?"

Para saber mais

Quatro dias de vibe coding na pele de um PM enferrujado Em 8 dias, entendi que a profissão de Product Manager vai mudar completamente A IA não deveria servir só para produzir dez vezes mais. Ela também deveria nos obrigar a entender dez vezes melhor o que produzimos No software, a vantagem não será mais a tecnologia. Será a compreensão do contexto.