Entender o que é Product Owner começa por desfazer um mal-entendido comum: em muitas empresas, o PO virou o "anotador de pedidos" do time, a pessoa que recebe demandas das áreas de negócio e as repassa aos desenvolvedores. Nesse formato, o backlog cresce sem parar, tudo é urgente e ninguém sabe dizer por que um item vem antes do outro. O papel existe justamente para o contrário: decidir o que não fazer.
O Guia do Scrum 2020 define o Product Owner como quem responde por maximizar o valor do produto resultante do trabalho do Scrum Team. A ferramenta principal para isso é o Product Backlog, e o PO responde pela gestão eficaz dele. A forma de fazer isso varia muito entre organizações, times e pessoas, e o Guia deixa esse espaço de propósito.
Abaixo estão o significado do termo, o que o Guia atribui ao papel, como é a rotina real de um PO e os limites do que não cabe a ele.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que significa Product Owner
Em tradução literal, Product Owner é o dono do produto. A palavra "dono" aqui não fala de propriedade, e sim de responsabilidade: é a pessoa que responde pelas decisões sobre o que o produto deve ser e em que ordem as melhorias chegam. No Brasil, o termo é usado em inglês ou pela sigla PO, inclusive na tradução oficial do Guia do Scrum.
O Product Owner é um dos três conjuntos de responsabilidades do Scrum Team, ao lado do Scrum Master e dos Developers. O Guia usa a palavra "accountabilities", que dá a ideia de prestação de contas: não é um cargo na hierarquia da empresa, é um papel no time.
O que é Product Owner pelo Guia do Scrum
Pelo Guia, o PO responde pela gestão eficaz do Product Backlog, o que inclui:
- Desenvolver e comunicar explicitamente a Meta do Produto, o objetivo de longo prazo que orienta o backlog.
- Criar e comunicar com clareza os itens do Product Backlog.
- Ordenar os itens do Product Backlog.
- Garantir que o Product Backlog seja transparente, visível e compreendido.
O PO pode fazer esse trabalho pessoalmente ou delegá-lo a outros, mas continua respondendo por ele. Isso é importante na prática: um analista de negócio pode escrever histórias e critérios de aceite, mas a ordem do backlog e a decisão sobre o que entra continuam com o Product Owner.
O Guia acrescenta três pontos que mudam o dia a dia de qualquer organização:
- O PO é uma pessoa, não um comitê. Ele pode representar as necessidades de muitas partes interessadas, mas a decisão é dele.
- Quem quer mudar o backlog precisa convencer o Product Owner. Não basta mandar um e-mail para o time.
- A organização precisa respeitar as decisões do PO. Sem isso, o papel não funciona. Se o diretor muda a prioridade por fora a cada semana, o Product Owner existe só no organograma.
Para entender como o backlog funciona e quais tipos existem, veja o que é backlog na metodologia ágil.
O que o Product Owner faz no dia a dia
O Guia diz o que o PO responde, não como ele ocupa a semana. Na prática, a rotina de um Product Owner costuma se dividir em quatro frentes:
| Frente | Atividades típicas | Com quem |
|---|---|---|
| Descoberta | Entrevistar usuários, analisar dados de uso, testar hipóteses antes de construir | Clientes, usuários, área comercial, suporte |
| Backlog | Escrever e refinar itens, definir critérios de aceite, reordenar | Developers, analistas |
| Eventos do Scrum | Trazer a proposta de objetivo para a Sprint Planning, apresentar o contexto na Sprint Review, participar da Retrospectiva | Scrum Team, partes interessadas |
| Alinhamento | Negociar prioridades, dizer não com justificativa, comunicar o roadmap | Patrocinador, diretores, outras áreas |
Um exemplo ilustrativo ajuda. Num projeto de implantação de sistema de gestão de matrículas para uma rede de escolas, a diretoria pede relatórios gerenciais, a secretaria pede agilidade no cadastro e o financeiro pede integração com o boleto. O Product Owner não atende os três por ordem de chegada. Ele busca dados (quanto tempo a secretaria perde hoje, quantas matrículas se perdem por falta de boleto), propõe uma Meta do Produto ("matrícula completa on-line até o início do período letivo") e ordena o backlog para chegar lá. O relatório gerencial pode esperar, e o PO explica por quê.
O PO nos eventos do Scrum
- Sprint Planning: o PO propõe como o produto pode ganhar valor na Sprint, e o Scrum Team inteiro define a Meta da Sprint.
- Daily Scrum: é dos Developers. O PO participa como Developer só se estiver trabalhando em itens do Sprint Backlog.
- Sprint Review: o PO participa com o time e as partes interessadas da conversa sobre o que foi feito e o que fazer a seguir, e o Product Backlog pode ser ajustado com o que se aprendeu.
- Sprint Retrospective: o PO participa como membro do Scrum Team.
Fora dos eventos, ele está disponível para o time. Um PO que só aparece na Planning e na Review gera Sprints cheias de dúvidas sem resposta.
O que não é papel do Product Owner
Saber os limites evita boa parte dos conflitos:
- Não distribui tarefas nem define como o trabalho é feito. Isso é decisão dos Developers.
- Não cobra horas nem produtividade individual. O compromisso do time é com a Meta da Sprint, não com o PO.
- Não acumula o papel de Scrum Master. O Guia não proíbe expressamente, mas os dois papéis têm focos diferentes e frequentemente em tensão. A comparação entre eles está em Scrum Master e Product Owner: diferenças entre os papéis.
- Não é o gerente de projetos com outro nome. O PO responde pelo valor do produto; a gestão de prazo, custo e contratos pode ou não estar com ele, dependendo de como a empresa organiza o trabalho.
Product Owner e gerente de produto
Em empresas de tecnologia, é comum aparecer também o cargo de gerente de produto (Product Manager). O PO é um papel do Scrum, ligado a um Scrum Team e ao backlog. O gerente de produto é um cargo que pode cobrir estratégia, mercado, precificação e resultados do produto. Às vezes é a mesma pessoa, às vezes não. A diferença entre gerente de produto e Product Owner está detalhada em artigo próprio.
Competências que mais pesam no papel
Não há lista oficial, mas alguns traços aparecem em quase todo PO que funciona bem:
- Conhecimento do negócio e do cliente. O PO precisa saber o que gera valor para quem usa e para quem paga.
- Capacidade de dizer não. Um backlog bem ordenado é feito de muitos "agora não", explicados com dados.
- Clareza na escrita. Itens ambíguos custam retrabalho. Critérios de aceite objetivos economizam Sprints inteiras.
- Autoridade de verdade. Sem poder de decisão, o PO vira intermediário. Isso depende da organização, não só da pessoa.
- Disponibilidade. O time precisa de respostas durante a Sprint, não só nos eventos.
Quem quer entrar na função encontra o caminho em como ser Product Owner, com as competências a desenvolver e os primeiros passos.
Sinais de que o papel não está funcionando
- O backlog tem centenas de itens e ninguém sabe dizer por que os dez primeiros estão no topo.
- Diretores pedem itens diretamente aos Developers.
- O PO não consegue responder dúvidas do time sem "levar para a diretoria".
- A Sprint Review é uma apresentação para o PO, em vez de uma conversa com as partes interessadas.
- Não existe Meta do Produto, ou ninguém lembra qual é.
Cada um desses sinais aponta para um problema diferente: falta de autoridade, falta de tempo, falta de critério de priorização ou falta de visão. Identificar qual é o primeiro passo para corrigir.
O que fazer agora
Se você já atua como PO, escreva numa frase a Meta do Produto atual e mostre para três pessoas do time. Se as interpretações forem diferentes, é por ali que começa o trabalho desta semana. Para enxergar o papel dentro do conjunto do framework, consulte o guia completo de métodos ágeis e Scrum. E, para desenvolver as competências de descoberta, priorização e visão de produto que o papel exige, o curso Gestão de Produto da Projeto Diário é o próximo passo.
