Image It's Monday morning. Over the weekend, an AI system read every support ticket from the last quarter, every sales-call transcript and every competitor's release notes.
Image It's Monday morning. Over the weekend, an AI system read every support ticket from the last quarter, every sales-call transcript and every competitor's release notes.
The memo is good. Better, honestly, than what most of us would have produced in the same week. Then a stakeholder forwards it with one question: "What does the Product Owner add here?"
In my Professional Scrum Product Owner – AI Essentials classes, I hear some version of that question more and more. Usually it is framed as "Will AI replace Product Owners?" I think that framing misses the point. Today's AI is no longer just a tool that saves the Product Owner a few hours. For much of the work that fills a Product Owner's week, it is a candidate for the job.
So the more useful question for our community is this: if artificial general intelligence, or something close to it, can do most Product Owner tasks, what does Scrum say the Product Owner is still for?
The Scrum Guide was never about the tasksRead the Product Owner section of the Scrum Guide again with AI in mind. It describes one accountability: maximizing the value of the product resulting from the work of the Scrum Team.
It then lists Product Backlog management: developing and communicating the Product Goal, creating and communicating Product Backlog items, ordering them, and keeping the Product Backlog transparent. And it adds a sentence that matters more now than when it was written: the Product Owner may do this work or delegate it to others, but regardless, the Product Owner remains accountable.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 18/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por que importa
Um escritório de projetos vale pelas decisões que torna possíveis, não pelos relatórios que produz. Quando o PMO vira a área que persegue atualizações de status, já perdeu: a equipe aprende a preencher o formulário e a informação real volta a circular pelos corredores.
Leio essas coisas procurando onde o risco estava antes de virar incidente. Quase sempre já estava escrito em algum registro que ninguém revisava, com um dono atribuído que nunca soube que era. O risco identificado e não gerenciado é pior que o não identificado: dá a falsa sensação de que há controle.
O que costuma dar errado
Onde costuma quebrar é na passagem para a operação. O projeto é declarado concluído quando é entregue, não quando a área que recebe consegue sustentá-lo. Três meses depois a equipe se dissolveu, ninguém documentou nada, e a operação convive com algo que não entende e não pode modificar.
O que observar
- Quem é o patrocinador e com que frequência real aparece — não no organograma, na agenda.
- Se o relatório de status mostra projetos em vermelho: um portfólio todo verde é um portfólio sem informação.
- Quais riscos estão identificados, quem é dono de cada um e quando foram revisados pela última vez.
Como leio esta publicação
Se isto chegasse à minha mesa, a primeira coisa que eu pediria não é o avanço percentual: é a lista de decisões pendentes com nome e data. O percentual dá para maquiar; uma decisão travada há três semanas com um responsável identificado não dá para discutir, e explica o atraso muito melhor.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Comentários
Ainda não há comentários. O primeiro pode ser o seu.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
