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
Em gestão de projetos, quase tudo o que se discute como problema técnico é na verdade um problema de expectativas mal negociadas no começo. Escopo, prazo e custo foram acordados num momento em que ninguém tinha informação suficiente, e depois ninguém quis reabrir a conversa.
Meu filtro é a qualidade do relatório de status. Se todos os projetos estão em verde, o sistema de informação não serve: em qualquer portfólio real há iniciativas com problema, e uma organização saudável as mostra a tempo em vez de descobri-las no comitê de encerramento.
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
- O tamanho da primeira entrega útil: quanto mais longe estiver, mais se parece com uma aposta.
- Como foi estimado e quão perto estiveram as estimativas anteriores da mesma organização.
- Quem é o patrocinador e com que frequência real aparece — não no organograma, na agenda.
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.
