Frequentemente durante uma consultoria ou treinamento percebo que as pessoas tem alguma dificuldade em entender o principal objetivo do PO. Muito se fala sobre isso, e vou colocar a minha visão.

Antes, vamos entender quem ele é. Segundo o Scrum Guide, o PO

“é responsável por maximizar o valor do trabalho que o Time de Scrum faz”

“é o ‘porco’ do Product Backlog”

“é a única pessoa responsável (…) por garantir o valor do trabalho realizado pelo Time”

Diz-se também que:

“Espera-se dos Product Owners que eles saibam como conseguir otimizar valor através do Scrum”

O que essa pessoa faz também pode ser inferido a partir do curso oficial da Scrum.org para o PO, o PSPO. Vejam alguns dos tópicos abordados no curso:

• Value Driven Development
• Product Management
• Managing Requirements
• Release

Está claro que o PO está focado no produto, e em maximizar seu valor, a ponto de termos um tópico (um dos primeiros) tratando só de desenvolvimento dirigido a valor. O PO também gerencia o produto, os requisitos e o lançamento do produto.

Ainda que o papel do PO seja muito importante no gerenciamento dos requisitos, não entendo essa como sua principal função. Seu foco é obter retorno sobre o investimento feito pela empresa, ele quer um retorno maior que o valor investido, e não simplesmente maior, mas maior dentro de uma certa margem. Para isso, gerenciar requisitos é uma função auxiliar, que entendo que pode ser auxiliada por pessoas mais preparadas, como analistas de negócios experientes. O planejamento de um release está diretamente ligado a quando o produto começa a dar retorno. E o gerenciamento do produto está ligado à adequação do produto a uma demanda que garanta o retorno. Tudo está ligado ao retorno do investimento.

Diante disso, o principal foco do PO, além de tudo que já foi falado, o motivo pelo qual o PO vai trabalhar, é garantir que está entregando no melhor timing possível a melhor solução possível para uma oportunidade de mercado. Dentro deste foco fechado, uma das suas principais atividades é cortar requisitos que agregam pouco valor. Um PO responsável coloca no fim do backlog os itens menos importantes, e no Scrum, os itens que ficam no fim do backlog acabam em geral nunca sendo feitos. E é exatamente esse o destino que devem ter.

Vamos ver as consequências desse foco no resultado:

• Esse é um dos motivos que desenvolvimento ágil não combina com projetos de escopo fechado. Se o escopo está fechado o PO deixa de cumprir sua principal atividade.
• Esse é também um dos motivos que projetos ágeis são iterativos, não waterfall (apesar de não ser o único). Dessa forma o PO tem como prever quando o produto vai ser lançado com mais precisão, além de poder fazer releases intermediários sempre que bem entender, podendo chegar até no ponto de fazer um por sprint.

Portanto, sempre que você ouvir que o PO deve obrigatoriamente entender muito de análise de negócios e levantamento de requisitos responda que esse não é seu foco principal, que é gerar ROI. Tal conhecimento, dependendo do perfil do PO, pode até mesmo ser ruim, uma vez que ele pode querer trabalhar em um nível muito baixo do gerenciamento do produto, deixando pra segundo plano a verdadeira motivação para a existência do seu papel no projeto. Se você conhece um PO assim, lembre-o de focar onde mais precisamos dele.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.