Publiquei uma frase simples no LinkedIn: o cargo de Product Owner já me parecia uma aberração organizacional, e na era da IA ele fica francamente difícil de defender.

66 mil impressões e umas quarenta respostas depois, eu constato duas coisas. A primeira é que toquei num nervo exposto. A segunda é que metade das discordâncias gira em torno de um mal-entendido que eu quero desfazer logo de cara.

Eu não estava atrás de polêmica — não ligo para número de visualizações. E, principalmente: eu já tinha exatamente essa posição antes da IA. A menção à IA cristalizou as reações, mas ela não é o fundamento do meu argumento. Ela é o acelerador.

O post original e a íntegra das conversas estão aqui. Este artigo é a minha resposta construída para quem dedicou tempo a me contestar.

O que eu não estou dizendo

Eu não digo que a IA vai substituir os Product Owners.

Me responderam, com razão, que uma IA não entende um mercado, não antecipa uma necessidade, não defende uma visão diante de um patrocinador, não segura um NO GO e não presta contas seis meses depois. Eu concordo. Totalmente.

Também não digo que as pessoas com “PO” no cartão de visita não servem para nada. Conheço POs excelentes. É a separação que eu critico, não as pessoas que a sofrem.

O que eu digo: o produto é o que está em produção

Uma especificação descreve uma intenção. Um PRD descreve um objetivo, regras esperadas, cenários. Um protótipo descreve uma interface desejada.

Mas entre essa intenção e a produção, sempre acontece alguma coisa. Desenvolvi esse ponto em A pergunta de produto tem que partir do código-fonte:

Concessões são feitas. Detalhes são ajustados. Casos-limite aparecem. Decisões são tomadas durante o desenvolvimento. Restrições técnicas obrigam a mudar um pouco o comportamento. Conversas acontecem dentro de um pull request ou de um merge request. Nem sempre essas decisões voltam para a documentação inicial.

[...] a spec não é a verdade do produto. Ela é uma aproximação útil num dado momento. A verdade é o que está rodando.

Isso não é grave. É até normal: um produto vivo não se constrói como um documento congelado.

Mas tem uma consequência que a gente se recusa a encarar. Se a verdade do produto se fabrica entre a intenção e a produção, então quem fica antes da produção não trabalha no produto. Trabalha numa intenção. E nunca vê as decisões que, na prática, definem o que o cliente vai viver.

O cliente não vê o seu discovery. Não vê o seu framework de priorização, nem o seu roadmap bonito. Ele vê o que sai em produção. E a qualidade de um produto está num acúmulo de pequenos detalhes — e esses detalhes você só enxerga se acompanhar até o fim.

Daí a minha convicção: quem pensa o produto tem que ser quem o entrega e quem cuida dele depois da entrega. Uma única e mesma pessoa. Ownership completo.

A aberração não é o conteúdo do cargo, é o que a existência dele revela

O que torna o cargo de PO indefensável aos meus olhos não é, portanto, o que um PO faz no dia a dia. É o fato de uma organização ter achado útil separar a parte “nobre” — pensar o produto — da parte que se delega: acompanhar o backlog, cuidar da relação com os desenvolvedores, monitorar a subida para produção.

Isso é taylorismo aplicado ao produto.

E esse filme a gente já viu.

Houve uma época com analistas de um lado e programadores do outro. Uns pensavam, os outros produziam código em série. Essa separação desapareceu. Hoje existem desenvolvedores, que pegam um problema de ponta a ponta: a arquitetura, o código, a segurança, a entrega, o acompanhamento. Existem até cada vez menos arquitetos separados do resto do time.

Ninguém sente saudade dos analistas-programadores. Ninguém defende a ideia de que se fazia software melhor quando a reflexão e a execução moravam em duas cabeças diferentes.

Não vejo razão nenhuma para o produto escapar desse movimento.

Eu me imponho a regra que imponho aos desenvolvedores

Tem um argumento que eu preciso encarar antes de todos os outros, porque ele me atinge diretamente.

Escrevi em A qualidade pertence a quem entrega uma regra que considero inegociável do lado do desenvolvimento:

A regra mais saudável é simples: quem cria o bug, corrige o bug.

Não porque seja preciso punir. Não porque seja preciso humilhar. Porque a responsabilidade pela correção tem que continuar grudada na responsabilidade pela produção.

E mais adiante:

Na maior parte dos casos, se um desenvolvedor criou o defeito, ele precisa corrigi-lo. Mesmo que já tenha passado para um assunto importante. Mesmo que isso atrapalhe o planejamento. Mesmo que isso atrase a próxima feature.

A qualidade consome capacidade. Esconder isso não a torna gratuita.

Eu não teria muita legitimidade para exigir isso dos desenvolvedores e me isentar disso.

Um PM que concebe e depois confia a um PO a tarefa de levar aquilo até a produção faz exatamente o que eu critico no desenvolvedor que entrega e já parte para o assunto seguinte. Ele terceiriza o custo do que produziu. Nunca vê onde a compreensão dele era insuficiente, onde a formulação era ambígua, onde a decisão estava torta. O ciclo não se fecha.

E é esse ciclo que cria qualidade.

Qualidade não se delega depois. Nem do lado do código, nem do lado do produto.

“Você está descrevendo um PO ruim”

Essa é a objeção mais frequente, e veio de várias pessoas diferentes: o papel de um PO é entender a necessidade, definir as funcionalidades do ponto de vista do cliente, carregar uma visão, decidir entre prioridades contraditórias, maximizar o valor.

Minha resposta é sempre a mesma: isso se chama Product Manager. Você acabou de descrever a minha profissão.

Se a sua definição de PO cobre a minha definição de PM, então estamos de acordo no fundo e brigando por uma palavra.

O problema é que não é isso que o mercado contrata. Me criticaram por descrever um PO que não existe. Abra as vagas de emprego: alimentar o backlog, escrever as user stories, fazer a interface entre o negócio e os devs, conduzir as cerimônias. Esse PO está em todo lugar. Ele é até a maioria.

E aí tem um ponto que ninguém levantou nos comentários.

Não dá para fundamentar uma profissão em um artefato descartável

O argumento mais usado para defender o papel é o do backlog: o PO maximiza o valor do produto cuidando, refinando e priorizando o backlog.

Só que eu já derrubei essa base em outro lugar, sem falar de IA uma única vez. Em O backlog não é um depósito de lixo:

Um item de backlog serve até a entrega. Depois, ele perde boa parte do seu valor.

Os tickets se dessincronizam. As specs se dessincronizam. As decisões mudam durante a construção. O comportamento final em produção costuma ser diferente do que tinha sido escrito no começo.

[...] O backlog não é uma fonte de verdade. É um apoio temporário de coordenação.

E, principalmente, ele já não é o lugar onde se pensa o produto:

Ferramentas como Jira, Notion ou equivalentes continuam sendo, na maioria das vezes, ferramentas de cartões. Editores de texto melhorados. [...] Podem ser úteis para coordenar a ação. Mas são muito fracas para construir uma reflexão de produto.

[...] O ticket não é mais o lugar onde se pensa. É o lugar onde se despeja o resultado de um pensamento já estruturado.

Então, se o backlog não é nem a memória do produto, nem o cérebro do produto, nem um ativo duradouro — como é que se fundamenta uma profissão na manutenção dele?

Dá para fundamentar uma função em um artefato consumível. Uma profissão, não.

Repare que esse argumento não tem nada a ver com IA. Ele já era verdade em 2020.

O nome conta, e é por isso

Me objetaram que PO é um papel dentro de um enquadramento metodológico, enquanto PM é uma profissão. Que o importante é o que a pessoa faz, não como ela se chama.

No princípio, eu concordo. Fiz project management numa época sem saber que aquilo tinha nome. O que a gente faz conta mais do que o rótulo.

Mas o título fabrica o mandato.

Na prática, os POs têm menos ownership e menos autonomia. Quando você é PM, você é owner do seu escopo, ponto. Várias pessoas formularam isso melhor do que eu nos comentários: o título de PO serviu muitas vezes para isolar a responsabilidade do produto sem entregar o mandato de decisão.

Um PO sem mandato para decidir não é um papel. É uma posição desconfortável.

E eu reconheço aí um mecanismo que já descrevi em Por que as organizações preferem as decisões frouxas:

Uma decisão clara torna a responsabilidade visível. Ela expõe quem decide. Ela dá margem para a crítica. Ela obriga a assumir que alguns pedidos não foram atendidos.

Uma decisão frouxa distribui essa responsabilidade. Ela a dilui entre os participantes, as reuniões, os documentos, as formulações prudentes, as validações sucessivas.

Separar a responsabilidade do produto em duas é o mesmo reflexo aplicado ao organograma. Permite ter alguém que carrega a consequência sem ter tido a escolha, e alguém que teve a escolha sem carregar a consequência.

O procedimento é confortável. É também a razão pela qual ninguém mais é de fato responsável por nada.

Onde a IA entra de verdade

Meu argumento sobre a IA não é “ela vai substituir os POs”. Ele é mais mecânico que isso.

A separação entre quem pensa e quem executa tinha uma justificativa econômica. O trabalho de traduzir, documentar, redigir, formatar custava caro em tempo. Caro o suficiente para se criar um cargo dedicado a absorver essa camada operacional.

Durante muito tempo, o PM foi um ponto de passagem obrigatório: recolher necessidades, reformular, produzir documentos, esclarecer tickets, colocar ordem, coordenar, priorizar, acompanhar, cobrar, documentar de novo. Uma parte da profissão consistia em compensar os atritos da organização. A gente acabou aceitando como normal uma pilha de tarefas que não eram o coração da profissão, apenas a sua camada operacional.

Esse custo está desabando.

E quando a justificativa econômica de uma divisão do trabalho desaparece, a divisão do trabalho não sobrevive por muito tempo.

É aí que a minha discordância inicial e a IA se encontram. A IA não cria o problema: ela tira a última desculpa prática que a gente tinha para conviver com ele. Já não dá para dizer “sim, em teoria o PM deveria acompanhar até a produção, mas na prática ele não tem tempo”.

Então continuar contratando hoje com uma descrição de cargo construída em torno da transmissão de informação é otimizar um circuito que já ficou obsoleto.

A nuance sobre a redação

Me responderam: “a redação nunca foi o gargalo da profissão”.

Sobre a decisão, é verdade. Decidir nunca foi um problema de redação, e eu não vou fingir o contrário.

Mas, num sentido amplo, eu não concordo. Sou o único PM de toda a empresa. Quando é preciso produzir um vídeo em quinze idiomas com as legendas, artigos em quatro ou cinco idiomas, os posts, os briefings sobre as vantagens e os pontos a destacar — é um trabalho insano. A IA me permite fazer coisas que eu simplesmente não tinha tempo de fazer. Não era o gargalo da decisão. Mas era, sim, um muro.

Eu enxergo a IA como um ótimo secretário particular. Ela pega a minha reflexão, engole as fontes, faz o trabalho braçal. Mas quem entende com finura, quem escolhe, quem corre o risco e quem assume é o PM. Não a IA.

E tem uma coisa que ela nunca vai fazer: a aposta.

Se você está numa startup e a pergunta é “a gente vai com tudo ou a gente morre”, essa escolha pertence a quem fundou a empresa. Uma IA pode analisar a opção. Ela não pode assumi-la.

Onde meus contestadores me fizeram avançar

Três coisas que eu guardo do debate.

O mandato conta mais que o título. Várias pessoas recentraram o assunto nisso, e elas têm razão. Um PM trancado no operacional e na gestão de urgências, sem margem para definir uma estratégia de produto, vai ficar ocupado sem produzir nada de útil. Renomear cargos não resolve nada se o mandato não vem junto. Minha insistência no vocabulário não pode esconder isso.

Dá para repensar o cargo em vez de eliminá-lo. Um líder técnico me descreveu o time dele, num software de saúde regulamentado com uma base de código legada: eles não eliminaram o cargo, redefiniram. O desenvolvedor carrega uma parte da visão de produto, o PO concebe. As pessoas ficam, o papel muda. Isso é provavelmente mais justo do que a minha formulação inicial, e vale ser dito: o que fica indefensável é a correia de transmissão, não as pessoas.

O perigo de verdade é a camada de isolamento. O problema não é existir um PO. É quando ele vira a camada que corta os desenvolvedores da necessidade real — sob o pretexto de que os devs não precisariam entender o negócio, apenas executar specs. Isso a IA vai tornar ainda mais insustentável. Aqui na empresa, os desenvolvedores entrevistam os clientes diretamente há vários meses. E alguns dias atrás eu subi o meu primeiro pull request no nosso produto principal.

Sobre o conhecimento do negócio, enfim, eu corrijo uma ideia pronta: ele não é propriedade do PO. Eu já o encontrei em CSMs que vieram da linha de frente, em gente do suporte. Ele pode estar em qualquer lugar — e precisa estar no PM. Na minha área, eu engulo livros e vídeos de manutenção industrial. Eu me obrigo a ser excelente no negócio, senão não tenho nada a decidir.

Onde eu não me mexo

Me disseram que o PO que eu descrevo é provavelmente o PO que eu fui. É possível.

E acrescento uma coisa mais incômoda de admitir: é muito confortável se livrar do backlog, do acompanhamento dos devs, das subidas para produção. O PM tem um interesse objetivo em que o cargo de PO exista. A gente guarda a parte que rende boas histórias em reunião e delega a parte que custa.

É exatamente por isso que eu desconfio.

Separar quem pensa de quem executa é uma aberração. Não porque a IA está chegando. Porque o produto é o que está em produção — e porque a gente não delega a responsabilidade daquilo que concebeu.

A IA não torna esse argumento verdadeiro.

Ela o torna impossível de contornar.