O PO não é uma profissão, é uma função — e a IA não muda isso, ela acelera

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

66 mil impressões e umas quarenta respostas depois, duas coisas ficaram claras. A primeira é que eu mexi com muita gente. A segunda é que metade das discordâncias vem de um mal-entendido que eu quero resolver agora.

Eu não estava buscando polêmica — não me importo com número de visualizações. E, principalmente: eu já tinha exatamente essa posição antes da IA. Mencionar a IA cristalizou as reações, mas não é o fundamento do meu argumento. É o acelerador.

O post original e a discussão completa estão aqui. Este artigo é minha resposta estruturada para quem teve o trabalho de me contradizer.

O que eu não estou dizendo

Eu não estou dizendo 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 na frente de um sponsor, não segura um NO GO e não presta contas seis meses depois. Concordo. Completamente.

Também não estou dizendo que quem tem "PO" no cartão de visita não serve para nada. Conheço gente excelente nesse papel. Eu critico a divisão, não as pessoas que vivem dentro dela.

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 mockup 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 deve partir do código-fonte:

Compromissos são feitos. Detalhes são ajustados. Casos-limite aparecem. Decisões são tomadas durante o desenvolvimento. Restrições técnicas obrigam a modificar levemente o comportamento. Discussões acontecem num pull request ou num merge request. Arbitragens nem sempre 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 roda.

Isso não é um problema. É até normal: um produto vivo não é construído como um documento congelado.

Mas tem uma consequência que a gente se recusa a encarar. Se a verdade do produto é fabricada 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. Nunca vê as decisões que, de fato, definem o que o cliente vai viver.

O cliente não vê a sua discovery. Não vê seu framework de priorização nem sua roadmap bonita. Ele vê o que entra em produção. E a qualidade de um produto está numa soma de pequenos detalhes — e você só percebe esses detalhes se acompanhar até o fim.

Daí a minha convicção: quem pensa o produto tem que ser quem entrega e quem acompanha depois da entrega. Uma única 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 para mim não é 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, manter a relação com os desenvolvedores, cuidar da subida para produção.

Isso é taylorismo aplicado ao produto.

E a gente já viu esse filme.

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

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

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

Eu me imponho a regra que imponho aos desenvolvedores

Tem um argumento que preciso encarar antes de todos os outros, porque aponta direto para mim.

Em A qualidade pertence a quem entrega, deixei uma regra que considero não negociável do lado da engenharia:

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

Não porque seja preciso punir. [...] E sim porque a responsabilidade de correção deve continuar ligada à responsabilidade de produção.

E mais adiante:

Na maioria dos casos, se um desenvolvedor criou o defeito, ele deve 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. Escondê-la não a torna gratuita.

Eu ficaria numa posição bem ruim exigindo isso dos desenvolvedores e me isentando.

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

E é esse ciclo que cria qualidade.

A qualidade não é delegada depois do fato. 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, sustentar 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 concordamos no conteúdo e estamos discutindo uma palavra.

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

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

Ninguém sustenta uma profissão sobre um artefato descartável

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

Só que eu já demoli essa base em outro lugar, sem falar de IA nenhuma 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 valor.

Os tickets se desatualizam. As specs se desatualizam. As decisões mudam durante a execução. O comportamento final em produção muitas vezes é 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 não é mais o lugar onde a gente pensa o produto:

Ferramentas como Jira, Notion ou equivalentes ainda costumam ser ferramentas de cartões. Editores de texto turbinados. [...] Elas 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 a gente pensa. É o lugar onde a gente empurra o resultado de um pensamento já estruturado.

Então, se o backlog não é a memória do produto, nem o cérebro do produto, nem um ativo durável — como se sustenta uma profissão em cuidar dele?

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

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

O nome importa, e é por isso

Me disseram que PO é um papel dentro de um framework metodológico, enquanto PM é uma profissão. Que o importante é o que você faz, não como você é chamado.

No princípio, concordo. Eu fiz project management numa época em que nem sabia que aquilo tinha nome. O que a gente faz importa mais 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 que eu nos comentários: o título de PO muitas vezes serviu para isolar a responsabilidade de produto sem entregar o mandato de decisão.

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

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

Uma decisão clara torna a responsabilidade visível. Ela expõe quem decide. Ela dá margem à crítica. Ela obriga a assumir que certos 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 cautelosas, as validações sucessivas.

Cortar a responsabilidade de 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 arranjo é confortável. E é também por isso que ninguém mais é realmente responsável por nada.

Onde a IA entra de verdade

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

A divisão entre quem pensa e quem executa tinha uma justificativa econômica. O trabalho de tradução, documentação, redação e formatação custava caro em tempo. Caro o bastante para justificar um cargo dedicado a absorver essa camada operacional.

Por muito tempo o PM foi uma central de distribuição: coletar necessidades, reformular, produzir documentos, esclarecer tickets, organizar, 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 massa de tarefas que não eram o coração do trabalho, apenas o encanamento dele.

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 original 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. Ninguém pode mais 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 base numa descrição de vaga 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 não vou dizer o contrário.

Mas no sentido amplo, discordo. Eu sou o único PM da empresa inteira. Quando é preciso produzir um vídeo em quinze idiomas com legendas, artigos em quatro ou cinco idiomas, os posts, os briefs sobre as vantagens e os pontos a destacar — o volume é absurdo. A IA me permite fazer coisas para as quais eu simplesmente não tinha tempo. Não era o gargalo da decisão. Mas era um muro, sim.

Eu vejo a IA como um excelente assistente pessoal. Ela pega a minha reflexão, engole as fontes, faz o trabalho pesado. Mas quem entende com profundidade, quem escolhe, quem assume o risco e quem presta contas é o PM. Não a IA.

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

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

Onde quem discordou me fez avançar

Três coisas que eu tiro do debate.

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

Dá para repensar o cargo em vez de eliminá-lo. Um tech lead me descreveu o time dele, num software de saúde regulado com uma codebase legada: eles não eliminaram o cargo, redefiniram. O desenvolvedor carrega parte da visão de produto, o PO projeta. As pessoas ficam, o papel muda. Isso provavelmente é mais justo que a minha formulação inicial, e vale dizer: o que fica indefensável é a correia de transmissão, não as pessoas.

O perigo real é a camada de isolamento. O problema não é um PO existir. É quando ele se torna 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, os desenvolvedores entrevistam os clientes direto há vários meses. E há alguns dias eu subi meu primeiro pull request no nosso produto principal.

Sobre o conhecimento do negócio, por fim, corrijo uma ideia pronta: ele não é propriedade do PO. Encontrei esse conhecimento em CSMs que vieram do campo, em gente do suporte. Ele pode estar em qualquer lugar — e precisa estar no PM. Na minha área, eu devoro livros e vídeos de manutenção industrial. Eu me obrigo a ser excelente no negócio, senão não tenho nada para 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 algo mais incômodo 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 fica com a parte que rende bem numa reunião e delega a parte que custa.

É exatamente por isso que eu desconfio disso.

Separar quem pensa de quem executa é uma aberração. Não porque a IA chegou. Porque o produto é o que está em produção — e ninguém delega a responsabilidade do que projetou.

A IA não torna esse argumento verdadeiro.

Ela torna impossível contorná-lo.

Para saber mais

A qualidade pertence a quem entrega O backlog não é um depósito de lixo: é uma ferramenta de ação A pergunta de produto deve partir do código-fonte