PARA QUEM É ESTE LIVRO

“Quero me tornar Product Owner. Por onde posso começar?”

“Me tornei Product Owner por acidente e não sei o que fazer.”
“Busco uma transição de carreira e me interessei pelo papel de Product Owner.”

Se você se identificou com, pelo menos, uma dessas citações, nos encontramos em
tempo - e fico muito feliz por isso!

Escrevi esse livro pensando, principalmente, em pessoas que querem trabalhar ou

que já trabalham como Product Owner (PO) em empresas de produtos SaaS.

Dentro do universo dos produtos digitais, pessoas que estão buscando uma
transição de carreira, que querem crescer e que exercem papéis de liderança de forma
natural - mesmo que não hierarquicamente - também encontrarão apontamentos e dicas
bastante proveitosos aqui.

Além disso, tenho encontrado, nos cursos que ministro sobre o papel de PO, muitas
pessoas que, quase acidentalmente, se viram ocupando esta posição. Neste caso, o
conteúdo deste livro poderá ser útil da mesma forma.

Livro de Rafael Helm, Edição 1, março de 2022. 1

INDICAÇÕES DE GÊNERO

Nos cursos que dou, estou atento para intercalar, no discurso oral, o uso dos artigos
masculino e feminino, já que nem sempre encontro alternativas neutras. Às vezes, explico o
que eu espero que o PO faça. Em outras, destaco a postura esperada da PO em determinada
situação.

Quis trazer esta mesma atenção para cá: diferente do que prega o padrão da norma
culta da língua portuguesa, optei por não escrever sempre no masculino. Busco uma
comunicação mais inclusiva, respeitosa e abrangente.

Livro de Rafael Helm, Edição 1, março de 2022. 2

CONTEÚDO

PARA QUEM É ESTE LIVRO 1

INDICAÇÕES DE GÊNERO 2

CONTEÚDO 3

ANTES DE TUDO 4

NÃO TOME UMA COCA-COLA SEM SABER POR QUE 6

PRODUCT OWNER: DESCOMPLICA! 8

Uma única pessoa 9
Gerenciamento de Backlog 9
Uma única pessoa, mas com apoio 10
Comitê de Produto 10
Respeito às decisões 12
Resumindo 13

O QUE NINGUÉM CONTOU PRA VOCÊ AINDA 14

De volta ao médico! 14
Cliente quer ser PO: pode isso, produção? 14
Scrum Master + PO: dá bom? 15
PM ou PO? 16
Tem lugar ao sol pra todo mundo mesmo? 17
Não conheço ninguém que parou de errar, mas habemus dicas! 18
Priorizar: definir prioridades; i.e. tentar não enlouquecer 19

PRÓXIMOS PASSOS 21
[eBook] Histórias de Usuário: Porque e como especificar requisitos de forma ágil? 21
[Livro] Product Backlog Building 21
[Canais sobre design] UXNOW, Design Team, XLab Design 22
[Meus vídeos] Meu canal no youtube 22

SOBRE O AUTOR (E COMO FALAR COMIGO) 23

Livro de Rafael Helm, Edição 1, março de 2022. 3

 ANTES DE TUDO

Antes de começarmos a falar sobre o papel de Product Owner, relembro que este é
um dos papéis descritos no Guia do Scrum, uma estrutura que propõe uma forma de pensar
e de praticar os princípios de agilidade no trabalho do dia a dia. Já neste ponto, imagino que
você possa estar se fazendo uma pergunta importante - e pressuponho isso porque eu
mesmo me deparei com esta questão no início de tudo. Por me questionar, busquei
diferentes pessoas de referência na área para me ajudar a responder a esta simples e
considerável dúvida: “O que é Agilidade?”.

De todas as respostas que obtive, a que mais gostei foi a de meu sócio e amigo
Daniel Wildt, que me enviou uma resposta rica e, ao mesmo tempo, tão enxuta, que até
caberia em um tweet:

- Agilidade é atitude, foco em entrega de valor, trabalho em equipe e melhoria

contínua. -

Nós vamos retomar e detalhar, durante todo o livro, os quatro pilares da mentalidade
ágil descritos em minha resposta favorita, mas vale um destaque para o segundo deles, que
está diretamente relacionado com o papel de um Product Owner. Isso porque o principal
objetivo de um PO é maximizar a entrega de valor para seu cliente.

Pense bem: clientes não contratam um projeto porque precisam de um software.

Clientes contratam um projeto porque têm um problema que precisa ser resolvido ou têm
alguma oportunidade de mercado que esperam abrir com o uso desse software. Por outro
lado e de forma complementar, uma equipe de software não acorda todas as manhãs para
criar um software. As pessoas desenvolvedoras dessa equipe levantam todos os dias para
criar softwares que, de fato, vão agregar valor para quem os demanda: vão resolver o
problema ou criar espaço para a oportunidade vislumbrada.

Pessoalmente, entendo que, inclusive, é muito mais motivante acordar para trabalhar
assim. O ponto crucial aqui é garantir que o trabalho seja priorizado para cumprir com este
objetivo, considerando todos os pedidos, demandas, impedimentos, solicitações,
alinhamentos e desalinhamentos (ufa!) que atravessam o trabalho de uma PO todos os dias.
Aliás, desde já, fique sabendo: um projeto tem uma diversidade de stakeholders pedindo
todo o tipo de coisa o tempo todo. São muitas ideias e desejos e, cada vez que entregamos
uma nova versão, receberemos novas sugestões. E, se tentarmos fazer tudo que nos

Livro de Rafael Helm, Edição 1, março de 2022. 4

pedirem, muito provavelmente, não conseguiremos atender a tudo que foi solicitado. E isso,
definitivamente, não é motivante. Pelo contrário: atrapalha o foco das pessoas envolvidas
no projeto e prejudica a qualidade e a quantidade de suas entregas. Para que o time não
fique sobrecarregado, a pessoa que ocupa o papel de PO deverá entender a capacidade de
entrega deste time e descobrir quais são as demandas mais importantes para serem
desenvolvidas dentro desta capacidade. A esta fila de demandas escolhidas damos o nome
de backlog. E, até aqui, você já pode ter uma boa ideia das atividades chave deste papel:
com base na premissa de maximizar a entrega de valor, decidir o que desenvolver (e o que
não desenvolver), priorizar e gerenciar o backlog.

Daqui para frente, vamos descobrir juntos quais são os principais objetivos,
atribuições, responsabilidades e desafios do Product Owner, e eu já destaco: por favor, leve
esse entendimento sobre agilidade até o fim do livro e durante todo o seu trabalho como PO.

Livro de Rafael Helm, Edição 1, março de 2022. 5

NÃO TOME UMA COCA-COLA SEM SABER POR QUE

Ainda falando sobre Agilidade, o Manifesto Ágil é composto por quatro valores
(Indivíduos e interações, Software em funcionamento, Colaboração com cliente e Resposta a
mudanças) e doze princípios (Time Multidisciplinar, Motivação, Autonomia, Entregas
funcionais, Entregas incrementais, Excelência, Simplicidade, Sustentabilidade, Cliente em 1º
Lugar, Reflexão, Comunicação e Adaptabilidade), que acabaram dando origem a uma série de
práticas. Por exemplo: refinamento, especificação de requisitos no formato de histórias de
usuários, desenvolvimento pareado, reunião diária… São práticas ilimitadas e fascinantes! E,
justamente por isso, trago outro destaque, ilustrando-o com uma pequena história.

Você sabe por que o grupo competidor do Tour de France, uma corrida de ciclismo
de estrada por etapas, toma uma Coca-Cola antes de escalar com suas bicicletas as
íngremes montanhas do percurso da prova? E mais, vendo este grupo de ciclistas
profissionais, você entende que também deveria tomar uma Coca-Cola ao sair para se
aventurar nos pedais, esperando ter um resultado tão bom quanto as pessoas que disputam
o Tour de France?

Diferente do que você pode ter imaginado, os experientes atletas não tomam
Coca-Cola para ingerir glicose ou cafeína, buscando uma fonte de energia e, muito menos,
optam pelo refrigerante por uma ação de merchandising. Eles bebem o famoso líquido preto
porque, durante uma prova de longa duração, precisam se alimentar, e o jeito mais prático
de fazerem isso é ingerindo gel de carboidrato de rápida absorção combinado com
isotônico. O ponto é que esses alimentos de prática esportiva são muito doces e, quando
consumidos, é muito natural justamente perceber a boca doce demais, além de sentir azia. É
aí que entra a Coca-Cola: ela ajuda a limpar a boca do ciclista em função do gás, trazendo
uma sensação de limpeza, e ainda faz o atleta arrotar, o que proporciona uma sensação de
alívio em relação ao desconforto gerado pela queimação. Por outro lado, no caso de uma
aventura de final de semana, por exemplo, pedalando de forma amadora, se você não pedala
por várias horas consumindo gel de carboidrato e isotônico como alimentação, pode acabar
até ganhando uns quilinhos a mais tomando uma Coca-Cola durante o passeio.

Ou seja, no contexto de um ciclista amador, que pedala por hobbie, não faz sentido
consumir coca-cola durante o pedal. Então, atenção, o contexto sempre precisa ser
considerado. Não esqueça disto!

Livro de Rafael Helm, Edição 1, março de 2022. 6

 Também é importante que você não esqueça que não vai adiantar você organizar as
raias do seu kanban da mesma forma que o Spotify organizou ou estruturar as reuniões
diárias com as mesmas adaptações realizadas pelo pessoal do Facebook, se sua
mentalidade não for entregar valor, ter atitude para buscar uma cultura de melhoria contínua,
verdadeiramente atuando em equipe. É imprescindível que você esteja entendendo quais
práticas fazem sentido para o seu dia a dia, mas que você nunca perca a mentalidade ágil,
entendendo o verdadeiro contexto da empresa em que atua.

Livro de Rafael Helm, Edição 1, março de 2022. 7

 PRODUCT OWNER: DESCOMPLICA!

O Time Scrum é formado pelo Product Owner, o Time de Desenvolvimento e o Scrum

Master. De acordo com o Guia do Scrum:

- O Product Owner, ou dono do produto, é responsável por maximizar o valor do

produto resultado do trabalho de Time de Desenvolvimento. Como isso é feito
pode variar amplamente através das organizações, Times Scrum e indivíduos. -

Falamos, há pouco, que o principal objetivo de um PO é maximizar a entrega de valor

para seu cliente - repito aqui de tão importante que é essa compreensão! Portanto, o
objetivo de um PO é transformar o custo arcado pelo cliente em retorno o mais rápido
possível. Por custo, entendemos o custo da contratação do projeto de software, e, por
retorno, a oportunidade que o cliente tem quando o software entra em produção, quando
temos uma primeira versão do software rodando no ambiente de produção.

Citando um caso simples e análogo, enquanto um estudante universitário não

conseguir um emprego em sua área, mesmo que como estagiário, ele não terá retorno sobre
seu investimento. Inclusive no caso de uma faculdade pública, há investimento financeiro se
considerarmos os custos com passagens de ônibus, gasolina e alimentação. Assim, quanto
mais rápido um aluno estiver atuando no mercado de trabalho, mais rápido ele começará a
retornar seu investimento nos estudos.

Voltando para o projeto de software, que precisará também retornar o investimento o

mais rápido possível, lembre-se: não é um software qualquer, é um software que resolva
problemas reais, que agregue valor. Para isso, você vai precisar entender quais
funcionalidades precisam ser desenvolvidas e por que isso é importante para o seu cliente.

Como isso é feito, em sprint de uma semana, duas semanas, com kanban ou não,
isso pode variar amplamente. Não é uma receita de bolo! Por isso, falamos que scrum não é
uma metodologia ágil, mas um framework ágil, porque ele deixa muitas lacunas que você
vai preencher com o que fizer mais sentido pra você, sempre considerando o contexto do
seu projeto e organização.

Livro de Rafael Helm, Edição 1, março de 2022. 8

 Uma única pessoa

- O Product Owner é a única pessoa responsável por gerenciar o backlog do

produto. -

Isso não quer dizer que as pessoas envolvidas no projeto não vão ter acesso ao
backlog, já que ele é um documento público para todos os envolvidos no projeto, como
clientes, Time de Desenvolvimento e stakeholders. Também não quer dizer que outras
pessoas não poderão ser consultadas no entendimento sobre qual deverá ser a ordem de
ataque do backlog. Isso quer dizer que a única pessoa responsável por realizar a gestão e ter
a palavra final sobre a priorização do backlog é o PO. Nesse sentido, o PO é sempre uma
pessoa e não um comitê - o PO não terá todas as respostas, precisará interagir com colegas
e complementar seu entendimento, mas esse papel é único. Cachorro com dois donos morre
de fome!

Gerenciamento de Backlog

O gerenciamento do backlog inclui as seguintes atividades:

- Expressar claramente os itens do Backlog de Produto: o backlog precisa estar

organizado e expressado de uma forma que todos consigam ler e entender a
demanda. O Time de Desenvolvimento, por exemplo, precisará conseguir ler o
backlog e entender o que está escrito ali, obtendo conhecimento sobre o contexto do
projeto.
- Ordenar os itens do backlog para alcançar melhor as metas e missões: o PO deve
priorizar os itens buscando sempre a otimização de valor. Seguindo na minha lógica
de adivinhações, se a gente estivesse jogando pôquer, eu apostaria todas as minhas
fichas que o seu backlog é maior do que você gostaria que ele fosse. Já que existem
muitas coisas a serem feitas e o cliente sempre tem pressa, o segredo é termos
certeza de que os itens que estão sendo desenvolvidos são os mais importantes.
- Garantir o valor do trabalho realizado pelo Time de Desenvolvimento: o PO deve
garantir que o time sempre esteja trabalhando nos itens mais importantes do
backlog, ou seja, em funcionalidades e recursos daquele software ou sistema que
realmente resolvam problemas reais ou que abram oportunidades de mercado
também reais. Para isso, o PO precisará investigar a motivação por trás de cada

Livro de Rafael Helm, Edição 1, março de 2022. 9

 demanda e entender quais demandas vão, de fato, trazer os maiores benefícios para
a empresa e para os usuários.
- Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e
mostrar o que o Time Scrum vai trabalhar a seguir: desenvolvimento de software não
é um processo repetitivo - é um processo criativo! Quanto mais informação de futuro,
de para onde aquele projeto está indo, maiores são as possibilidades de o design ser
assertivo. Se você passar para o seu time apenas o que precisa ser feito agora, e o
time fica sem visão do todo, provavelmente eles farão uma modelagem de dados
que não vai ser a mais adequada para o que vem a seguir.
- Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no
nível necessário: considerando o item anterior, podemos entender que existem
diferentes níveis de detalhamento da informação dependendo do momento em que
estamos. Nesse sentido, o que vai estar sendo feito nas sprints mais próximas
deverá ter uma riqueza de detalhes maior do que os itens que serão trabalhados em
sprints futuras.

Uma única pessoa, mas com apoio

- O Product Owner pode fazer o trabalho acima ou delegar para o Time de

Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o
responsável pelos trabalhos. -

O PO é uma única pessoa, mas vamos pensar juntos em um projeto com 20 pessoas
desenvolvedoras. Esse time tem uma vazão de entrega muito grande para que apenas um
PO dê conta, sozinho, de priorizar todo o backlog, fazer todas as histórias de usuários e fazer
todos os protótipos (entre outros artefatos). Nesse caso, o PO poderá confiar parte desse
trabalho a outras pessoas do Time de Desenvolvimento, mas continua sendo o responsável
pelo todo.

Comitê de Produto

- O Product Owner é uma pessoa e não um comitê. O Product Owner pode

representar o desejo de um comitê no Backlog do Produto, mas aqueles que

Livro de Rafael Helm, Edição 1, março de 2022. 10

 quiserem uma alteração nas prioridades dos itens de Backlog devem convencer
o Product Owner. -

Como falamos há pouco e mais de uma vez, o PO é uma pessoa - tem nome,
sobrenome, CPF, e-mail e endereço. No entanto, ele poderá estar representando o desejo de
um comitê e, na verdade, é bastante comum que empresas que trabalham com produtos
digitais tenham Comitês de Produto.

Abaixo, listo papéis/cargos acredito que devem fazer parte deste comitê:

- Representante do Time de Suporte Técnico: este time terá ótimos insights de

evolução de produto (funcionalidades novas ou evoluções em funcionalidades já
existentes), já que está em contato direto com a base de clientes e buscará reduzir
demandas de suporte técnico. Por ter contato com as principais dores apontadas
pelos clientes, o time tem conhecimento sobre quais são os pedidos de ajuda e quais
são as insatisfações em relação ao produto.
- Representante do Time Comercial: este time demandará novas funcionalidades que
fariam os Executivos de Venda ganharem contratos com determinados clientes ou
deixarem de perder clientes para concorrentes específicos. A ótica comercial vai
apresentar ao comitê funcionalidades que, se forem desenvolvidas, aumentarão as
vendas do time.
- Representante do Time de Sustentação (TechOps): este time vai estar preocupado
com oportunidades relacionadas à arquitetura ou infraestrutura do produto,
buscando manter ou aumentar sua estabilidade, adquirir alta performance e torná-lo,
cada vez mais, escalável.
- CEO: o CEO da empresa estará garantindo um olhar lá na frente, buscando manter o
produto inovador, moderno e atrativo sempre.

Cada uma dessas pessoas tem um ponto de vista, uma dor e um foco diferente. E o
que o PO faz? Uma triagem - a mesma coisa que já deve ter acontecido com você quando
precisou ir a uma emergência médica. Ao chegar lá, um enfermeiro atendeu você, investigou
seus sintomas, fez alguns exames prévios entendendo como estão seus batimentos
cardíacos, pressão arterial e temperatura corporal e, com base nisso, pode entender a
criticidade do seu caso. Essa entrevista inicial chama-se anamnese e resulta em um
diagnóstico que, a depender do resultado, lhe dá uma pulseirinha vermelha, amarela ou
verde, por exemplo, sinalizando a prioridade com que você poderá ser atendido. No caso do
Comitê de Produto, é assim que o PO deve atuar. Ele vai entender a visão de todos os

Livro de Rafael Helm, Edição 1, março de 2022. 11

representantes e, tendo uma visão cross, conseguirá sugerir uma ordem de ataque que faça
mais sentido para o produto e para empresa como um todo. Mesmo que exista um comitê
de produto entregando solicitações e ideias de produto, quem vai tomar conta disso é o PO.

Contudo, como você já deve ter percebido, eu consigo imaginar algumas das
perguntas e pensamentos que podem estar passando pela sua cabeça enquanto lê este
livro. Aqui, meu palpite é o seguinte: “Mas, na empresa em que eu trabalho, no fim das
contas, quem toma a decisão é sempre o CEO”. E, aqui, precisamos admitir: pode haver uma
grande diferença entre o mundo fantástico da teoria e o mundo real. Nesses casos, você vai
fazer o melhor que você puder com aquilo que está ao seu alcance. Ainda sobre isto,
recomendo que assista este rápido vídeo.

Respeito às decisões

- Para que o Product Owner tenha sucesso, toda a organização deve respeitar as
suas decisões. As decisões do Product Owner são visíveis no conteúdo e na
priorização do Backlog do Produto. Ninguém tem permissão para falar com o
Time de Desenvolvimento sobre diferentes configurações de prioridade, e o
Time de Desenvolvimento não tem permissão para agir sobre o que outras
pessoas disserem. -

Imagine que o Comitê de Produto se reuniu, você como PO ouviu, analisou e

apresentou o backlog priorizado. Se todo mundo começar a brigar por uma nova priorização,
vamos ter uma grande sessão de bate boca. É importante que todos entendam e confiem na
tomada de decisão do PO em relação à priorização do backlog.

Sobre a visibilidade do backlog, é fundamental que todos entendam facilmente as

decisões de priorização. Por exemplo, mesmo que seja evidente que um bug vai precisar ser
prioritário versus uma nova funcionalidade, isso precisa estar sinalizado no backlog.

Ainda, uma vez que o PO leva as demandas para o Time de Desenvolvimento, se

surgir algum trabalho não planejado, o PO precisa ser envolvido. Ninguém pode forçar o
Time de Desenvolvimento a trabalhar em um conjunto de itens diferente daquele que foi
combinado na reunião de planejamento.

Livro de Rafael Helm, Edição 1, março de 2022. 12

 Resumindo

Em resumo, as principais atividades de um PO são:

● Definir a visão do produto

● Maximizar o ROI e o trabalho do Time de Desenvolvimento
● Especificar os requisitos
● Apresentar ao time os requisitos necessários para a entrega do produto
● Planejar a entrega de releases
● Priorizar os requisitos de acordo com seu valor
● Gerenciar novos requisitos
● Atuar como interface perante os vários clientes do projeto
● Garantir que os especialistas de negócio estejam disponíveis

Livro de Rafael Helm, Edição 1, março de 2022. 13

 O QUE NINGUÉM CONTOU PRA VOCÊ AINDA

Eu vou contar. Simples assim!

Escrevi este livro pensando em quem quer aprender ou em quem está em apuros.
Para isso, reuni respostas a questionamentos que já experienciei e conclusões sobre
situações específicas que aprendi ao longo de minha caminhada e que entendo que podem
ser bastante relevantes para você. São dicas, pequenos-grandes truques e entendimentos
sobre outros pontos de vista que acredito que fazem a diferença no desempenho deste
papel.

De volta ao médico!

Já falamos sobre a emergência médica. Agora, a metáfora está em um cenário muito

parecido: quando vamos a uma consulta médica, não dizemos ao médico o que ele precisa
fazer, correto? O médico, antes de tudo, faz a anamnese - busca investigar mais a fundo o
que está acontecendo para entender a causa raiz do problema, pede exames, observa e
questiona. Como PO, temos que atuar da mesma forma: diagnosticar antes de medicar. “Por
que você precisa deste relatório?”, “Qual problema você está buscando resolver com este
relatório?”, “Que prejuízo você tem na sua operação hoje por não ter um relatório como
este?”. Isso vai ajudá-lo a dimensionar o problema frente ao backlog todo, trazendo
informações sobre gravidade e urgência.

Atuando como PO, você precisa ouvir o cliente e questioná-lo para entender se ele
precisa daquilo de fato. E, vamos admitir, nem sempre o cliente realmente precisa do que
está pedindo ou, em algumas vezes, é uma ótima ideia, mas não é algo que poderá ser feito
naquele momento.

Cliente quer ser PO: pode isso, produção?

Entendemos que um bom PO precisa ter bastante contexto sobre o negócio e

analisar criticamente a importância de cada entrega. Por que, então, o cliente não poderia
ser o próprio PO do projeto?

Livro de Rafael Helm, Edição 1, março de 2022. 14

 Em meu ponto de vista, por diferentes experiências de trabalho que já tive, essa
estratégia pode funcionar desde que a pessoa do cliente seja desonerada de todas as suas
demais funções. Não pode haver acúmulo de funções e, muito menos, pode acontecer de o
cliente executar as atribuições de PO em suas horas livres - ninguém tem horas livres. Além
disso, entendo que pode haver conflito de interesses quando o cliente exerce esse papel e
perde-se a riqueza das interações e, principalmente, dos questionamentos entre cliente e
PO.

Scrum Master + PO: dá bom?

Para responder esta pergunta, compartilho um trecho do livro Scrum: A Arte de Fazer
o Dobro do Trabalho na Metade do Tempo:

- O engenheiro chefe não pode simplesmente dizer que algo tem que ser
feito de uma maneira específica, ele tem que persuadir, convencer e demonstrar
que aquela maneira é a melhor maneira de desenvolver aquela solução. Em
geral, precisa-se de alguém com 30 anos de experiência para assumir esse
papel. Eu queria aquilo no Scrum, mas também sabia muito bem que havia
pouquíssimas pessoas com aquele nível de habilidade e experiência e, então,
eu dividi o papel em dois, dando os nomes de Scrum Master e Product Owner.
O papel do Scrum Master é pensar em como o time vai estar trabalhando e o
papel do PO é decidir o que o time vai estar fazendo primeiro. -

O Scrum Master, portanto, tem como objetivo manter a equipe atuando de forma
ágil. Para isso, ele apoia o time na implantação do Scrum, facilita reuniões de retrospectiva,
verifica se o time está se comunicando bem, por exemplo. Ele busca manter e desenvolver a
mentalidade ágil com seus principais pilares: atitude, foco em entrega de valor, trabalho em
equipe e melhoria contínua. Já o PO está focado em entregar software que agrega valor
para o cliente o mais rápido possível - tenho certeza de que você não esqueceu disso até
aqui!

Um PO bem intencionado, mas que foca muito em uma entrega rápida de valor,
poderá conduzir o time, inconscientemente, para um modelo go horse. Por outro lado, um
Scrum Master também bastante dedicado poderá tornar-se obstinado em implantar culturas
de agilidade, deixando de lado a importância das entregas efetivas. Os interesses em

Livro de Rafael Helm, Edição 1, março de 2022. 15

entregar rapidamente e atuar com agilidade, combinados, geram um equilíbrio interessante:
entregar software em um ritmo legal, mantendo uma mentalidade e práticas ágeis. Se
concentrarmos os dois papéis em uma pessoa só e se essa pessoa não tiver muita
consciência e muita experiência, a probabilidade é de não dar certo. Não é proibido
acumular os dois papéis, mas entendo que seja mais saudável se tivermos duas pessoas
diferentes.

PM ou PO?

É comum haver confusão entre esses dois papéis e, por isso, explico em mais
detalhes aqui. O framework Scrum é muito claro ao afirmar que o PO é uma única pessoa
responsável pela construção e evolução do produto. Também já sabemos que não é por
isso que o PO vai conseguir realizar todo o trabalho sozinho, e a função de PM pode
preencher muitas das lacunas que acabam não sendo preenchidas pelo papel de PO,
principalmente quando falamos de modelo de negócio, visão de futuro e sobre a conexão do
produto com a estratégia do negócio.

O PO tomará decisões sobre o que será atacado pelo Time de Desenvolvimento

através da gestão do backlog do produto, mas ele não tem todas as informações para tomar
tais decisões corretas de forma isolada.

● Qual o objetivo da empresa no médio e no longo prazo?

● Qual o planejamento estratégico?
● Qual o mercado alvo? Qual o principal concorrente?
● Como está a nossa taxa de churn (cancelamentos)?

Veja que essas são perguntas de negócio e que não têm uma relação óbvia com o
backlog de produto. O PM, então, vai atuar de uma forma muito mais atenta aos objetivos
estratégicos e rumos do produto: tomará decisões sobre porque a empresa está trabalhando
naquele produto. O PO, por consequência, estará focado em transformar estes objetivos em
funcionalidades, adicionando estas funcionalidades ao backlog, escrevendo as histórias de
usuário e executando seu refinamento, planejando e entregando essas funcionalidades
rodando em produção.

Que fique claro e sem rodeios: o papel de PM está acima do papel de PO. O primeiro
dá a direção, o segundo, faz acontecer. O primeiro tem um papel estratégico, o segundo, um

Livro de Rafael Helm, Edição 1, março de 2022. 16

papel tático-operacional - o que não quer dizer que o PO vai precisar o tempo todo pedir
autorização para o PM para realizar qualquer avanço. O PO tem autonomia desde que esteja
muito bem alinhado com o PM.

Vale comentar que, em empresas menores, é comum que a pessoa que atua como
CEO acabe absorvendo as responsabilidades de um PM. E isso até vai dar certo por algum
tempo, mas, quando o negócio e o produto começam a ficar mais complexos, este papel
tende a exigir uma dedicação em tempo integral. Além disso, na minha visão, existe um
certo conflito quando a mesma pessoa ocupa os dois papéis porque o CEO, nestes casos,
pode ter uma tendência bastante parcial em relação às suas próprias ideias, enquanto que o
PM deveria validar as ideias em questão com pesquisas, análises de concorrentes,
entrevistas com usuários e clientes e outras práticas. Se essa tendência se confirmar,
perde-se um filtro importante na escolha dos requisitos.

Existem ainda os casos em que apenas uma pessoa trabalha tanto como PO quanto
como PM. Aqui, é importante que haja o entendimento de que ela está exercendo dois
papéis diferentes: em alguns momentos, sua atenção vai estar mais voltada para a
estratégia, em outros momentos, será necessário focar em fazer o software ser entregue
em produção.

Tem lugar ao sol pra todo mundo mesmo?

Qualquer profissional pode se tornar PO? Pode! Aspectos como formação, vivências
e histórico pessoal e profissional irão compor POs com estilos de atuação diferentes.
Dependendo onde você estiver vindo, poderá ter cacoetes e formas de pensar que foram
também construídos por estes lugares e experiências. Uma pessoa que trabalhava como
desenvolvedora de software, por exemplo, provavelmente vai pender para uma linha mais
técnica e racional. Cada PO terá, então, seu estilo de atuação, sua caixa de ferramentas com
habilidades e conhecimentos que detém e suas deficiências.

Uma habilidade que, rapidamente, destaco como crucial para o trabalho de PO é a

capacidade de comunicação. Embate não resolve nada! Bons comunicadores costumam ser
mais assertivos e diretos em relação aos problemas, conseguem transmitir mensagens
simples ou complicadas com clareza e no tempo certo, impactando fortemente no
andamento do trabalho e nas relações ali impostas.

Livro de Rafael Helm, Edição 1, março de 2022. 17

 Para lidar com alguma deficiência que poderia atrapalhar o desempenho de seu
trabalho, você poderá atuar de forma pareada. Por exemplo, se, pelas suas experiências até
então, você ainda não tem tanto conhecimento técnico, uma opção seria convidar um líder
técnico para apoiá-lo em uma determinada reunião. Para além disso, eu acredito que toda
capacidade pode ser desenvolvida e aperfeiçoada.

A fórmula (nem tão!) mágica é: se você se comunica bem, se conhece o contexto em

que está atuando e se entende de modo claro e evidente o seu papel, você pode atuar
tranquilamente como PO.

Não conheço ninguém que parou de errar, mas habemus dicas!

De forma muito simples e direta, o erro mais comum é não saber dizer não. O tempo
todo o cliente, seus colegas e os usuários do seu produto estarão pedindo mais
funcionalidades, mais requisitos, mais evoluções - e vão estar demandando muito mais do
que seu time é capaz de absorver. Se você disser sim para tudo, seu backlog vai ficar
gigante e você vai ter que lidar com uma frustração enorme com seu cliente ou com as
pessoas que estão demandando de você porque, dizendo sim, você inevitavelmente vai
acabar criando uma expectativa de algo que não poderá ser cumprido. O tempo todo, pense
em um funil - você vai precisar filtrar, escolher, priorizar e, definitivamente, vai precisar negar
algumas demandas.

Dizer não pode ser bastante difícil, eu sei. Mais uma vez, suponho que você esteja se
fazendo uma outra pergunta importante: “Qual o segredo para dizer não e a pessoa não ficar
chateada comigo?”. Minha dica é: justificar porque está dizendo não e explicar quais
evoluções efetivamente estão sendo entregues. Já sei, você pensou: “Como fazer isso?”.
Volte no tempo, na época em que você era criança e acompanhava seus pais no
supermercado. Você pedia uma lata de refrigerante, e sua mãe dizia que não. Pedia uma
barra de chocolate, e seu pai também dizia que não. Era não atrás de não. E você,
provavelmente, se sentia aborrecida, chateada, incomodada. Até o dia em que você foi ao
supermercado com seus pais, pediu um pacote de bolachas (bolacha ou biscoito?!) e seus
pais explicaram: “Hoje não vamos poder comprar esse pacote de bolachas porque estamos
economizando dinheiro para fazer as compras da sua festa de aniversário que acontece no
mês que vem”. Aqui, você entendeu que não iria ganhar o pacote de bolachas naquele dia,
mas soube que ganharia uma festa inteira de aniversário. Entenda, é do jogo dizer: “Entendi

Livro de Rafael Helm, Edição 1, março de 2022. 18

seu pedido, mas, neste momento, não conseguimos atender porque nosso time já está
bastante comprometido com trabalho nos próximos 60 dias. Nosso backlog tem itens muito
importantes, que até já combinamos datas de entrega, e podemos voltar a conversar na
data tal”.

Importante: é comum que, mesmo assim, os clientes não aceitem sua negativa. Eles
podem ficar bravos, podem pedir para falar com seu superior e, até mesmo, com o CEO. Isso
também faz parte do jogo! É da natureza do trabalho do PO lidar com expectativas e,
claramente, com expectativas frustradas também.

Outro erro comum é atender o pedido do cliente ao invés de atender a necessidade

dele. Busque entender efetivamente o problema dele, pense no que o cliente pediu e porque
o cliente precisa disso. Tenha, de forma bem nítida para você, a história com início, meio e
fim. Não se contente com a sugestão de uma solução que chega prontinha para você -
muito provavelmente, ela é uma ilusão.

Ainda sobre este ponto, vale uma observação: quando um único produto é utilizado
por vários clientes diferentes (como uma plataforma SaaS, por exemplo), e recebemos um
pedido de evolução de um cliente, precisamos entender se este pedido - e o esforço que
seria empenhado em sua entrega - faz sentido para o produto como um todo. Caso
contrário, entenderemos que aquela é uma dor específica deste único cliente, o que pode
ser um indício de uma negativa.

Priorizar: definir prioridades; i.e. tentar não enlouquecer

Até aqui, você realmente deve ter entendido que não é a palavra mais importante
para um PO. Dizer sim para uma nova demanda é muito fácil. O trabalho do PO é difícil: ele
precisa decidir, envolvendo os stakeholders, o que não vai desenvolver e arcar com as
consequências dessa decisão. E, tendo decidido o que entra e o que não entra, o PO
também precisará definir a ordem dos acontecimentos, priorizando os itens que serão
construídos agora e os que ficarão para mais tarde.

Como fazer isso? O PO precisará ter uma ideia do valor e do esforço envolvidos em
cada demanda. Algumas delas serão excepcionalmente críticas, enquanto que outras serão
apenas desejos. Algumas demandas poderão levar meses para serem desenvolvidas,
outras, um par de horas. E, aqui, fique atento: não há relação direta entre o valor e tamanho

Livro de Rafael Helm, Edição 1, março de 2022. 19

de uma demanda. Maior não significa melhor, assim como menor também não significa
melhor. Exatamente como viemos brincando até agora, será um jogo de adivinhação! O PO
não sabe nem o valor nem o tamanho da demanda e vai ter que conversar, o tempo todo,
com os envolvidos para tentar descobrir o que eles valorizam mais. Também vai ter que
conversar, o tempo todo, com o time de desenvolvimento para descobrir o que poderia ser
grande ou pequeno em termos de esforço.

Com isso, eis que devemos ter algumas aproximações. Isso mesmo: suposições,
suspeitas, chutes. E ainda teremos dúvidas: O que devemos desenvolver em seguida?
Corrigir aquele bug urgente? Construir uma funcionalidade nova que os usuários estão
pedindo? Realizar a tão aguardada mudança de plataforma que trará mais produtividade e
estabilidade? Para além do valor e do esforço envolvidos, será preciso pensar no tipo de
demanda. O PO deverá buscar equilibrar o trabalho pró-ativo e reativo. Apagar incêndios e
prevenir incêndios. Construir a coisa certa, da forma correta e rápido!

Livro de Rafael Helm, Edição 1, março de 2022. 20

 PRÓXIMOS PASSOS

Muito legal saber que você chegou até aqui, parabéns! Como próximos passos eu
vou sugerir alguns conteúdos muito legais que vão te ajudar a seguir sua jornada.

[eBook] Histórias de Usuário: Porque e como especificar requisitos

de forma ágil?

Uma vez que o backlog esteja priorizado, ou pelo menos os primeiros itens, é hora de
começar a alimentar o time de desenvolvimento com o detalhamento das funcionalidades
que serão desenvolvidas na próxima sprint. Especificar os requisitos de uma forma clara e
ao mesmo tempo enxuta é um grande desafio e pensando nisso eu escrevi um ebook que
ajuda POs a detalhar os requisitos de seus projetos no formato de Histórias de Usuário. Aqui
está o link para download gratuito do ebook, recomendo fortemente a leitura e a adoção da
prática de registrar os requisitos no formato de Histórias de Usuário.

[Livro] Product Backlog Building

Falei bastante aqui sobre a importância de gerenciar o backlog do produto, pois bem,
o Fábio Aguiar e o Paulo Caroli publicaram um livro muito interessante chamado de “Product
Backlog Building: Um guia prático para criação e refinamento de backlog para produtos de
sucesso”.

No livro, os autores abordam sobre o método que ele desenvolveu para Construir um
entendimento compartilhado da necessidade do produto; Facilitar a descoberta do produto
e a escrita das histórias de usuário; Estruturar a granularidade dos itens do backlog;
Priorizar os itens de maior importância para o produto e maior valor para o cliente; Melhorar
o trabalho do time com a construção e refinamento do backlog.

Eu adorei o livro e recomendo. Link para o livro na amazon.

Livro de Rafael Helm, Edição 1, março de 2022. 21

 [Canais sobre design] UXNOW, Design Team, XLab Design

O design é uma área de conhecimento muito importante para quem atua como
Product Owner. Temos excelentes canais que produzem conteúdos muito ricos sobre o
assunto, e aqui quero registrar a indicação de três canais que eu recomendo que você siga e
assista todos os vídeos. Os três canais são mantidos por pessoas experientes na área e que
compartilham conceitos, técnicas, e práticas que de fato são aplicadas no mercado de
trabalho.

Link para o canal UXNOW.

Link para o canal Design Team.

Link para o canal XLab Design.

[Meus vídeos] Meu canal no youtube

Eu tenho produzido alguns vídeos e postado no no meu canal no youtube e quase

sempre o conteúdo é voltado para pessoas que atuam como PM e/ou PO, bem como para
pessoas que têm muitas dúvidas sobre a dinâmica de condução de projetos. Então te
convido para conferir meus conteúdos por lá também. :)

Livro de Rafael Helm, Edição 1, março de 2022. 22

 SOBRE O AUTOR (E COMO FALAR COMIGO)

Meu nome é Rafael Helm, nasci em Porto Alegre em 1979 (faz as contas aí para
saber a minha idade) e, desde os 19 anos, atuo na construção de produtos digitais. Virei PO
por acidente, em 2005, sem nem saber que este papel existia - tomei muita porrada, acertei,
errei, mas, principalmente aprendi bastante.

Sou um tanto inquieto e atualmente atuo em mais de uma frente. 1) Sou um dos
sócios da Wildtech onde atuo como instrutor e consultor de métodos ágeis; 2) Sou um dos
fundadores da UXConf BR, a mais importante entre as conferências de UX Design do Brasil;
3) Ocupo um cargo de diretoria na uMov.me, que é uma plataforma no code para criação de
apps para o segmento B2B.

Gosto muito de compartilhar conhecimento e trocar experiências, adoro conversar

com pessoas e, quando participo de conferências, fico mais no lounge bebendo café e
conhecendo pessoas do que assistindo palestras (até porque geralmente a gente encontra
os conteúdos das palestras no YouTube depois).

Sou casado com a Aline, pai do Rafael Helm Junior e tenho uma yorkshire chamada
Vida. Para conversar comigo me siga no linkedin e mande mensagem. ;)

Livro de Rafael Helm, Edição 1, março de 2022. 23