Olhando o mercado, o papel de Product Owner é, disparado, o mais difícil de encontrar profissionais robustos e capacitados. Quando eu fiz a certificação de Scrum Product Owner lá em 2014, o Marcos Garrido, um dos fundadores da K21, falou algo que nunca esqueci: “se você encontrar um bom P.O., mesmo sem ter um produto para dar pra ele, contrata e segura o cara”.
Quando abordamos os quatro domínios da agilidade, sempre reforçamos que o ágil é um bichinho de quatro patas: se uma patinha está manca, o bichinho capota! Portanto, todos os domínios são igualmente importantes, mas quando estamos tratando deste assunto, sempre começamos falando do domínio de Negócios. Ele é o primeiro que abordamos porque traz o propósito da empresa e do produto. Ele determina o que será sucesso para aquela iniciativa, e tem como objetivo nos dar um norte de eficácia.
Com grandes poderes vêm grandes responsabilidades
É por isso que ter um PO despreparado pode ser tão nocivo. Podemos ter o melhor time do mundo, com um clima ótimo; processos fluidos que apoiam e suportam a criação de um produto e o trabalho da organização; práticas state of the art no quesito técnico, com as melhores ferramentas… E ainda assim estarmos criando algo que ninguém quer, ou que sequer faz sentido.
Mas de onde vêm os P.Os? Como saber se você tem o perfil ou a vontade de ser PO? Para ajudar pessoas que têm essa dúvida, vamos usar o É/Não é/Faz/Não Faz, técnica criada pelo Rafael Sabbagh, co-fundador da K21 e trainer do curso Certified Scrum Product Owner.
O que um Product Owner é:
- Questionador
- Curioso
- Empático
- Comunicativo
- Apaixonado
- Bom negociador
- Um cientista
- Apegado a métricas
- Transparente e verdadeiro
O que um PO não é:
- Um chefe
- Um gerente de projetos
- Um proxy
- Irresponsável com o investimento em um produto
- Um outro papel (gerente, analista de área etc)
- Mestre dos magos (some depois da Planning e aparece na Review)
- Omisso
- Homologador
- Aprovador de entrega
O que um Product Owner faz:
- Busca descobrir qual é o problema que estamos tentando resolver
- Levanta hipóteses de solução para o problema junto com o time (obrigada, Auri!)
- Fatia itens de backlog como um sushiman
- Descarta itens de backlog que não fazem mais sentido para a realidade atual do produto
- Prioriza os itens de backlog de forma a maximizar o valor do produto
- Pesquisas com clientes/usuários
- Experimentos
- Metrifica resultados
- Estuda o mercado
- Define estratégia do produto
- Controla o investimento/orçamento
- Gestão de relacionamento com stakeholders
- Dinâmicas de consenso e priorização com stakeholders
- Alinha os stakeholders em relação ao retorno sobre o investimento
- Refinamentos com os stakeholders
- Refinamentos com o time
- Dá apoio nos refinamentos técnicos do time
- Esclarece para o time o valor que cada item no backlog agrega
- Enriquece os itens de backlog usando técnicas como histórias de usuário, 3Cs, INVEST e job stories
- Mapeia e compreende a experiência do cliente
- Descoberta contínua
- Motiva o time com um propósito fantástico
- Fica disponível para o time durante a sprint
- Ajuda o time a definir um objetivo para a sprint
- Cancela a sprint quando o objetivo não faz mais sentido
- Dá feedback para o time
- Melhoria contínua
O que um PO não faz:
- Status report
- Controle de ocupação
- Microgerenciamento
- Priorização sem métricas
- Pressão sobre o time
- Repassa necessidades e demandas dos stakeholders
- Prioriza atividades que não têm a ver com o produto
- Incentiva o time a ser tarefeiro
- Falta nos eventos do time (planning, review, retro)
- Documentação extensa
- Busca culpados
- Contrata ou demite membros do time
- Gestão do time
- Descobre o que foi entregue durante a Review
- Omite problemas
Sou “…” e Product Owner nas horas vagas
Costumo dizer que se o PO estiver fazendo bem seu trabalho, ele não tem tempo livre. Vemos em algumas empresas uma crença de que o PO só “escreve as histórias do backlog”, o que cria uma impressão que o PO tem tempo de assumir outras atividades. Isso não é realista. Se o PO está com tempo livre para assumir outras atividades é porque há alguma atividade do produto que ele certamente está deixando para trás.
Além disso, o PO deve estar estudando o tempo todo. Tanto para trazer novas técnicas de produto, gerando melhoria contínua na sua atuação, como estudando o mercado, o consumidor e os problemas que ele está buscando resolver, gerando melhoria contínua no produto.
#FicaDica
Se você está começando nessa jornada e quer material para ler, vale a pena dar uma olhada no artigo 10 livros imperdíveis para Product Owners.
Mais conteúdos sobre Product Owner:
E-book: Epicentro – A arte de começar pelo que mais importa
Artigo: O trabalho de FDP do Product Owner
Artigo: Pensando produto e evitando armadilhas
Artigo: Os sete arquétipos de um Product Owner
E aí? Se identificou? Venha fazer o treinamento de CSPO e aprender as principais ferramentas do PO em um curso prático.
Quer fazer uma gestão de portfólio pensando em produtos? Escute o episódio do Love The Problem!
Viu algum item que você acha que ficou faltando no É/Não é/Faz/Não faz? Deixa aqui nos comentários!
