Polêmica: o melhor Product Owner NÃO é o cliente

Este post não tem tags.

Compartilhe:

Product Owner (PO) é certamente o mais negligenciado dos três papéis do Scrum. Exatamente por essa razão, muitas organizações acabam por adotar um caminho aparentemente mais fácil do que formar ou contratar um bom PO: dar ao próprio cliente esse chapéu.

Em função disso, já ouvimos muito por aí a propagação da ideia de que o melhor Product Owner é o cliente. As principais justificativas para essa afirmação envolvem o interesse do cliente no sucesso do projeto e seu conhecimento sobre o negócio e suas próprias necessidades.

Mas será que isso é realmente uma boa ideia? Muito pelo contrário. Em muitas das empresas que visitamos no nosso dia a dia como consultores, encontramos projetos em sérios apuros como consequência de um profundo desalinhamento entre PO e Time de Desenvolvimento. Essas empresas têm justamente essa característica em comum: o PO é o cliente. Mas então por que ter um PO-cliente é um problema?

1) O PO-cliente pensa em funcionalidades e não em problemas

O cliente raramente sabe o que quer: clientes geralmente têm dificuldade em entender os próprios problemas a serem resolvidos e, por conta disso, não é nada incomum haver clientes trazendo soluções “prontas” para problemas que eles não entenderam ainda. U

m PO-cliente causa a seguinte disfunção nesse caso: ao invés de levar problemas de negócio para resolver com o time, ele leva propostas de soluções prontas e que no final das contas não entregam muito valor. O time pode fazer exatamente o que o cliente pediu, mas como os problemas reais não são resolvidos, esse cliente não fica satisfeito. Quem nunca viu isso acontecer?

2) Relação de time ou de cliente-fornecedor?

A relação do PO-cliente com o time é tensa: no Scrum, PO, ScrumMaster e Time de Desenvolvimento formam o Time de Scrum, que deve se unir em torno do projeto. Só que quando o PO é o cliente, a relação deixa de ser de time e passa a ser de cobrança. Ao invés de colaborar com o time, o PO passa a assumir a postura de gerente de projetos, uma vez que é ele mesmo quem está “pagando” pelo produto que está sendo construído.

É bem comum nesse caso ver PO usando a Daily Scrum como status report, Retrospectiva para apertar o time e Sprint Planning para empurrar “só mais uma história”. Além disso, o PO-cliente sofre uma pressão direta e constante dos seus stakeholders por resultados. Assim, ao invés de proteger e colaborar com o time para organizar o trabalho, o PO-cliente quer tirar o máximo de seu “fornecedor”. Um efeito direto disso é que para esse PO-cliente tudo é prioridade, comprometendo uma das práticas essenciais do Scrum: a priorização.

3) Ausência frequente

O PO-cliente raramente tem disponibilidade para estar junto com o time para tirar dúvidas e para colaborarem para refinar os itens de trabalho. Aliás quando o PO é cliente, ele provavelmente está em outro local físico, o que dificulta a comunicação, causando diversas disfunções no projeto. Aliando essa questão ao problema número 2, a vida do time fica realmente complicada. Mesmo quando o projeto é interno, o PO-cliente acaba tendo outras atividades e prioridades, deixando o time muitas vezes perdido.

Se seu time tem um PO-cliente e você tem certeza que não enfrentam esses três problemas, excelente, mas saiba que vocês são uma exceção. No caso geral, nós da K21 defendemos que o melhor Product Owner NÃO é o cliente.

É fundamental que a escolha do Product Owner seja feita com bastante critério, de forma a se trabalhar com alguém que entenda de gestão ágil de produtos, que tenha disponibilidade para o papel, que saiba se comunicar com o cliente e stakeholders de forma eficiente e que trabalhe com o time de desenvolvimento em um regime de colaboração contínua. Só assim será possível formar um verdadeiro “Time de Scrum”, conforme definido por Jeff Sutherland e Ken Schwaber, os criadores do Scrum.

Click here to read this post in english.

Sobre o autor(a)

Co-fundador e Trainer na K21

Rafael Sabbagh é co-fundador da K21 e foi membro do Board de Diretores da Scrum Alliance entre 2015 e 2017. Ele é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban University. Atuando em nível executivo, possui uma vasta experiência em Transformação Digital e Gestão de Produtos. Ao longo da sua carreira, já treinou milhares de Scrum Masters, Product Owners e membros de equipes em mais de 15 países na Europa, América e Ásia.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

É uma pergunta comum em diversos times ágeis: Temos capacidade para atender a demanda? A resposta é não. Como diz Rodrigo de Toledo: “No trabalho do conhecimento, a demanda sempre irá superar a nossa capacidade de atendê-la.”. O desafio é…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Data storytelling. Se você acompanha o nosso blog, já deve ter percebido que eu gosto muito de trabalhar com métricas, dados e gráficos. É interessante, mas esses artefatos, apesar de serem interessantes, sozinhos eles não vão dizer muitas coisas. Você…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

A criação de personas é um dos passos mais importantes no desenvolvimento de produtos, mas pode ser um desafio quando se trata de reunir dados e representá-los de forma precisa. Neste artigo, vou mostrar como usamos a inteligência artificial para…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Políticas explícitas são o alicerce invisível que mantém times ágeis funcionando com eficiência e harmonia. No contexto do Kanban, elas são mais do que simples regras: são acordos claros que orientam decisões, promovem transparência e evitam confusões. Apesar disso, muitas…