Um VC indiano, Sajith Pai, escreveu em agosto de 2026 algo que parece distante de Scrum e PO, mas não é. Ele reparou que fundadores chegam com MVP funcional, gerado com poucos prompts no Claude ou similar — e isso parou de provar qualquer coisa para quem decide investir. Antes, construir um MVP era, em si, a prova de que o fundador sabia executar. Hoje, prova só que ele sabe usar bem a ferramenta.
A resposta que ele propõe é de fundraising, não de engenharia — construir prova de distribuição antes do produto, porque isso não se gera com prompt. Mas o mecanismo por trás generaliza bem além de VC: quando construir deixa de ser filtro, a decisão de "vale construir isso" precisa de outra prova, e precisa vir antes, não depois.
Dentro de uma empresa, quem carrega essa decisão é o PO. E é exatamente aí que o papel está rachando.
O que o mercado já está documentando
Marty Cagan, referência em product management, escreveu recentemente que o Product Owner no sentido estrito de Scrum — dono do backlog, coordenador de sprint, tradutor de requisito — está sendo absorvido por IA mais engenheiro fazendo a própria descoberta. Em times saudáveis, essa parte do papel está sendo incorporada pelo PM; em outros, está sendo eliminada.
Andrew Ng, numa entrevista recente, descreveu o outro lado da mesma mudança: "gestão de produto está virando o novo gargalo. Não vejo o trabalho de PM acelerar no mesmo ritmo que o de engenharia." Engenharia ficou rápida. Decidir o que a engenharia deveria construir não ficou.
Um levantamento de tendência de 2026 nomeia o deslocamento como saída de "operador" para "governante" — PM que só movimenta ticket fica pra trás; quem absorve pesquisa de mercado, precificação, e a parte de distribuição que o produto sozinho não resolve, sai na frente. Reparem: isso encontra, por outro caminho, o mesmo ponto do VC — quando build fica barato, a competência que resta é a que decide e distribui, não a que constrói.
Outro material, voltado a certificação de PO, descreve a mudança como ir de "autor" para "editor": em vez de escrever item de backlog do zero, o PO orquestra o que a IA já rascunhou e decide o que aprovar. Um efeito colateral direto disso: quando o PO orquestra bem essa camada, a qualidade do próprio Definition of Ready sobe, porque menos coisa mal-especificada entra no fluxo.
A bifurcação, nomeada com mais precisão
Reunindo o que já está documentado, a fratura tem dois lados bem definidos — mesmo que cada fonte use um nome diferente para cada um:
Lado que encolhe — administração de execução. Escrever item de backlog, traduzir requisito técnico, coordenar cerimônia, fazer refinamento repetitivo. Isso é exatamente o que IA mais engenheiro fazendo discovery direto já cobre bem, sem precisar de intermediário full-time. Não é hipótese — é o que Cagan documenta acontecendo agora.
Lado que não encolheu — decisão de valor. O que construir, o que não construir, o que parar, que trade-off vale a pena, e por que construir isso e não aquilo. Um material de treinamento de PO chega a dizer, sem meio-termo: IA não substitui "articular por que construímos o que construímos" — isso continua irredutivelmente humano.
Vale nomear isso com um vocabulário que ainda não vi nenhuma fonte cravar exatamente assim, então marco como nossa formulação, não achado de mercado: o PO está bifurcando entre curador de contexto — quem organiza e valida o que a IA e o time precisam saber para decidir bem, e evita que decisão ruim nasça de contexto incompleto — e decisor — quem carrega, de fato, a responsabilidade do "vale construir isso". Nas empresas pequenas, uma pessoa ainda acumula os dois papéis. Nas que crescem, a tendência que o mercado documenta é essas duas competências se separarem em pessoas diferentes, ou a parte de curadoria de contexto ser cada vez mais apoiada — não substituída — por ferramenta.
Por que isso não é só rearranjo de organograma
O risco de tratar essa bifurcação como reorganização de cargo é perder o ponto real: a parte que sobrou para o humano é a parte mais difícil, não a mais fácil. Administrar backlog era trabalho mecânico, cansativo, mas com critério relativamente claro de "certo" e "errado". Decidir o que vale construir, com julgamento de negócio, custo de oportunidade e leitura de cliente, nunca teve régua fácil — e é isso que ficou, sozinho, como o núcleo do papel.
Isso conecta direto com algo que já apontamos no post sobre cerimônia ágil na era da IA: dev participando da elaboração da solução, junto com o PO, na fase de descoberta (dual-track agile). Se a curadoria de contexto puder ser mais distribuída — dev e PO organizando informação junto, com apoio de IA para levantar o que falta — o papel de decisor fica mais bem municiado, em vez de decidir sozinho, com contexto incompleto, sob pressão de velocidade que a engenharia agora impõe.
O que fica sem resposta
Duas perguntas que a pesquisa de mercado ainda não resolve, e que valem ficar em aberto em vez de forçar conclusão:
- Quem faz a curadoria de contexto quando o time é pequeno demais para separar os dois papéis? A tendência documentada é de empresa maior. Time pequeno provavelmente segue com uma pessoa acumulando os dois — mas isso tem limite de escala que ninguém ainda mediu direito.
- O que acontece quando a curadoria de contexto, feita majoritariamente por IA, erra de um jeito que só aparece na hora da decisão? Se o decisor confia demais no contexto que a IA organizou, e esse contexto tem viés ou lacuna, o erro só aparece depois — mesmo problema estrutural que já vimos na revisão de código, agora deslocado para decisão de produto.
## Fechando
O papel de PO não está desaparecendo, mas também não vai continuar do jeito que o Scrum de livro descreveu. A parte que exigia disciplina de processo está sendo absorvida por IA e por engenheiro fazendo discovery direto. A parte que exigia julgamento sobre o que vale a pena construir não encolheu — ficou mais exposta, porque é a única peça que sobrou sem automação disponível.
Se sua empresa está sentindo esse papel esticar, o sintoma provavelmente não é "o PO está sobrecarregado com processo". É que a parte de processo ficou mais leve, e a parte de decisão, que sempre foi a mais difícil, virou praticamente o cargo inteiro.