O que é Product Owner?

O papel de Product Owner nasceu junto com o Scrum, apresentado por Ken Schwaber e Jeff Sutherland em 1995 e detalhado nas primeiras versões do Scrum Guide, a partir de 2010. Desde o início, o Scrum definiu esse papel como o responsável único pelo valor do produto, em contraste com o gerenciamento de projetos tradicional, que costuma dividir essa responsabilidade entre patrocinador, gerente de projeto e áreas de negócio.

A definição evoluiu nas revisões do Scrum Guide. A versão de 2020 reforçou que o PO é responsável por maximizar o valor do produto e formalizou a Meta do Produto como o compromisso de longo prazo do Product Backlog, dando ao papel um horizonte mais estratégico do que apenas gerenciar uma lista de pedidos.

Em 2025, o Scrum Guide Expansion Pack, de Jeff Sutherland, Ralph Jocham e John Coleman, propôs uma distinção entre o Product Owner, focado no Product Backlog, e um Product Manager de nível organizacional, com autoridade delegada sobre múltiplos stakeholders e áreas. É uma proposta de um complemento opcional, não uma mudança no Scrum Guide oficial.

O Scrum Guide resume o trabalho do PO em uma frase: maximizar o valor do produto que resulta do trabalho do Time Scrum. Na prática, isso se desdobra em quatro responsabilidades sobre o Product Backlog:

- Desenvolver e comunicar a Meta do Produto, o objetivo de longo prazo que dá sentido a cada item do backlog. - Criar e comunicar claramente os itens do backlog, para que qualquer pessoa do time entenda o que precisa ser feito. - Ordenar os itens por valor, risco, dependência e oportunidade, decidindo o que vem primeiro. - Garantir transparência, deixando o backlog visível e compreensível para todo mundo, dentro e fora do time.

O PO pode delegar a execução dessas atividades a outras pessoas, mas continua sendo o responsável final. Suas decisões sobre o backlog devem ser respeitadas por toda a organização: mudar a ordem sem passar pelo PO é o mesmo que ignorar a priorização inteira.

Uma pessoa, nunca um comitê. Essa é a regra mais repetida, e mais violada, do Scrum Guide. O PO pode ouvir dezenas de stakeholders, mas a decisão final é de uma pessoa só. Um comitê decidindo prioridade sempre volta ao mesmo problema: ninguém quer dizer não, e o backlog cresce sem limite.

PO não é gerente de projeto. O gerente de projeto tradicional cuida de prazo, custo e escopo de uma iniciativa fechada. O PO cuida de valor contínuo de um produto vivo. Ele não aloca pessoas nem cobra horas: decide o quê e o porquê, e deixa o como para os Desenvolvedores, com o Scrum Master cuidando de como o time trabalha junto.

Onde o PO atua no ciclo. Participa da Sprint Planning para alinhar a Meta da Sprint com o time. Fica disponível durante a Sprint para esclarecer dúvidas sobre os itens, o que evita que o time trave esperando resposta. Participa da Sprint Review para coletar feedback direto de quem usa o produto. E, embora o Scrum Guide não exija sua presença na Retrospectiva, na prática a maioria dos times inclui o PO, já que parte da melhoria contínua envolve a relação entre PO e Desenvolvedores.

O que sustenta a autoridade do PO. Autoridade de priorizar não vem do título do cargo, vem da organização respeitar as decisões tomadas. Se um diretor consegue furar a fila do backlog com uma ligação, o papel existe só no papel. Por isso, formar um bom PO é também um trabalho de gestão: a liderança precisa blindar essa autoridade, e não só nomear alguém para o cargo. Em produtos maiores, com vários Times Scrum trabalhando na mesma base, costuma existir um Product Backlog único e um PO que coordena a ordem geral, enquanto POs de área cuidam de fatias específicas, sempre reportando à mesma Meta do Produto para não fragmentar a visão.

Fundamente a ordem em aprendizado. Ordenar o Product Backlog não é apenas colocar pedidos do patrocinador no topo. O Product Owner considera valor potencial, risco, custo de atraso, dependências e evidências sobre usuários, conforme o contexto. Uma hipótese pode merecer experimento pequeno antes de grande investimento; uma obrigação regulatória pode exigir ação mesmo sem pedido explícito de cliente. Ao dizer não ou ainda não, explique a troca de prioridade e o que faria a decisão mudar. A Sprint Review oferece contato direto com stakeholders, mas uma opinião forte não substitui pesquisa, dados de uso e o Product Goal. Também é importante diferenciar responsabilidade de execução solitária: Developers e especialistas podem ajudar no refinamento, na investigação e em propostas de corte. O Product Owner continua responsável pela gestão efetiva do backlog e pela maximização de valor, com autoridade real para sustentar essas escolhas.

Imagine uma Product Owner de um aplicativo de delivery de farmácia, que trabalha com um time de seis pessoas.

9h. Ela revisa os dados de uso da última semana: o tempo médio entre pedido e confirmação da farmácia subiu 40%. Não é um pedido de stakeholder, é um sinal nos números, e ela decide investigar antes de adicionar qualquer item novo ao topo do backlog.

10h30. Reunião com o time comercial, que pede, com urgência, a integração com um novo parceiro de pagamento. Ela ouve, entende o potencial de receita, mas não promete data: o item entra no Product Backlog, abaixo da investigação sobre a confirmação lenta, porque o problema de confirmação afeta todos os pedidos, não só os de um parceiro.

14h. Sessão de refinamento com o time. Juntos, quebram a investigação em itens menores: instrumentar o tempo de cada etapa do pedido, comparar farmácias rápidas e lentas, testar um lembrete automático para farmácias que demoram. Cada item ganha critérios de aceitação claros.

16h. Um Desenvolvedor pergunta se um caso extremo, cliente cancelando o pedido no meio da confirmação, deveria mostrar uma mensagem de erro ou simplesmente reverter em silêncio. A Product Owner decide na hora: reverte em silêncio e registra no histórico do cliente, porque o objetivo é não assustar quem está esperando o remédio.

Repara no padrão: ela prioriza com base em dado, não em quem pediu mais alto. Ela decide rápido quando o time precisa, sem empurrar a decisão para uma reunião futura. Ela mantém o backlog como uma lista viva, não uma promessa engessada. E quando o time comercial questiona por que o parceiro de pagamento ficou para depois, ela mostra o gráfico do tempo de confirmação subindo, e a conversa muda de tom: deixa de ser uma disputa de prioridade e vira uma decisão compartilhada sobre o que mais afeta o cliente agora.

Muita organização empilha esses três papéis sobre um mesmo produto, na esperança de cobrir todos os ângulos. O resultado costuma ser o oposto: ninguém sabe quem decide, e decisões importantes ficam esperando alinhamento entre pessoas que deveriam estar alinhadas por definição. Quando os três papéis coexistem, vale deixar por escrito quem tem a palavra final sobre o Product Backlog: essa é a linha que o Scrum reserva ao Product Owner. Antes de aceitar os três papéis numa mesma iniciativa, vale perguntar: se PO, PM e GP discordarem sobre a próxima prioridade, quem tem a palavra final? Se a resposta não for imediata, os três papéis provavelmente vão pisar um no outro.

Cursos K21 recomendados