Product Owner: Técnicas e Habilidades

Prévia do material em texto

COMO SER UM PRODUCT OWNER
DAVID PEREIRA
O CURSO
¡ Objetivo
¡ Técnicas que auxiliam ao PO a atingir os objetivos de forma simples e eficaz
¡ Público alvo
¡ Product Owners que querem amplicar o conhecimento
¡ Profissionais em transição de carreira
¡ Metodologia
¡ Conexão entre teoria e prática
¡ Expectativa e realidade
¡ Exercícios
QUEM SOU EU?
¡ Formação
• Técnico – Informática Industrial – Tancredo Neves
• Graduação – Ciência da Computação
• Pós Graduação – Engenharia de Software – Anhembi Morumbi
• MBA – Gestão Estratégica de Negócios – FIAP
• MBA – Innovation Entrepreneurship – Babson College
¡ Experiência Profissional (12+ anos)
• Desenvolvedor – Delphi Automotive Systems 
• Product Owner – Ability Trade Marketing
• Product Owner – Instacarro
• Product Owner – ( evino )
• Product Owner – Windeln De
• Product Owner – Limango GmbH
COMO SER UM PRODUCT OWNER David Pereira
COMO SER UM PRODUCT OWNER
DAVID PEREIRA
COMO SER UM PRODUCT OWNER
HABILIDADES DO PRODUCT OWNER
TOP 6 HABILIDADES MANDATÓRIAS DE UM PO
HABILIDADES DO PO
COMUNICAÇÃO
UM DESAFIO CONSTANTE
COMUNICAÇÃO
¡ Clientes
¡ Time de negócios
¡ Time de desenvolvimento
CLIENTE
¡ Ouvir o cliente para entender:
¡ O que é importante
¡ O que não é importante
¡ Quais são as dores
¡ Validar hipóteses
¡ O meu produto resolve algo para o cliente?
¡ O cliente entende o meu produto?
¡ Receber Feedback de forma aberta
CANVAS PROPOSTA DE VALOR
TIME DE NEGÓCIOS
¡ Quando?
¡ Em todo os momentos que for relevante. Por exemplo: release realizado. 
¡ O que?
¡ Tudo que for de interesse to time de negócio, por exemplo:
¡ Planejamento de um Release
¡ Como?
¡ Depende do objetivo da comunicação e público alvo, podendo ser e-mail, reunião F2F, 1:1, workshop 
¡ Quem?
¡ Todos que tiverem interesse ou forem impactados pelo assunto
¡ Qual a frequência?
¡ O suficiente para garantir que todos entendam o cenário atual
PLANO DE COMUNICAÇÃO
Nome Público Frequência Informação Tipo Duração
Alinhamento
Prioridades
All Stakeholders Quinzenal Consenso
prioridades
F2F 1hora
Reclamações dos 
clientes
Customer 
Service
Quinzenal Entender as 
dores dos 
clientes
F2F 1hora
TIME DE DESENVOLVIMENTO
¡ Garantir o entendimento do objetivo
¡ Remover quaisquer dúvidas e incertezas
¡ Encontrar melhores soluções juntos
¡ Facilitar Trade-offs
¡ Estar sempre aberto para conversar
EXERCÍCIO
¡ Faça um plano de comunicação para o seu cenário
¡ Quais são as informações que devem ser comunicadas?
¡ Quem deve receber as informações?
¡ Como está comunicação deve ocorrer?
¡ Qual a frequenência desta?
¡ Qual a duração?
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
TOMADA DE DECISÕES
BE A DECISION MAKER
TOMADA DE DECISÃO
¡ Confie em seus instintos
¡ Definir o que importa e o que não importa
¡ MoSCoW
¡ Good enough
¡ Trade offs
CONFIE EM SEUS INSTINTOS
¡ Acredite nas descisões que toma em um piscar de olhos
¡ Qual direção deveremos ir?
¡ É necessário desenvolver determinada funcionalidade?
¡ É necessário sempre provar com números?
CONFIE EM SEUS INSTINTOS
¡ Acredite nas descisões que toma em um piscar de olhos
¡ Qual direção deveremos ir?
¡ É necessário desenvolver determinada funcionalidade?
¡ É necessário sempre provar com números?
CONFIE EM SEUS INSTINTOS
¡ Acredite nas descisões que toma em um piscar de olhos
¡ Qual direção deveremos ir?
¡ É necessário desenvolver determinada funcionalidade?
¡ É necessário sempre provar com números?
DEFINIR O QUE IMPORTA E O QUE NÃO IMPORTA
¡ Entender o que é necessário no momento, qual é o foco?
¡ Trazer novos usuários?
¡ Fidelizar usuários?
¡ Escalar?
¡ Aumentar a eficiência
¡ Profitabilidade
¡ Entender o que não é importante
¡ O que o produto não precisa?
¡ O que o público alvo não valoriza?
¡ O que não é aderente a proposta de valor?
MOSCOW
¡ Must-have
¡ Funcionalidades primordiais
¡ Sem isso, não é útil
¡ Should-have
¡ Importante, porém não é primordial
¡ A solução funciona sem isso
¡ Pode impactar a eficiência
¡ Could-have
¡ Desejável, porém não é crítico
¡ Não gera impacto relevante
¡ Won’t have this time
¡ Acordado em não fazer
GOOD ENOUGH
¡ Quando a funcionalidade está boa o suficiente?
¡ Resolve o problema apresentado de forma satisfatória?
¡ O usuário compreende como funciona?
¡ O que evitar?
¡ Construir uma bazooka para matar um mosquito?
TRADE-OFFS
¡ Tempo disponível não é conectado com a capacidade do time
¡ Fazer da forma certa vs fazer funcionar
¡ Arriscar vs falhar
¡ Interromper o Time vs atingir o objetivo comprometido
EXERCÍCIOS
¡ Imagine que o AirBnb está em sua fase inicial e você é o responsável em definir o Roadmap deste produto.
¡ Define quais seriam as funcionalidades necessárias
¡ Classifique as funcinoalidades conforme a técnica MoSCoW
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
FOCO
FOQUE NO OBJETIVO E DIGA NÃO!
FOCO
¡ Priorização
¡ Diga não
¡ Sprint Goal, objetivos concretos
¡ Less is more
PRIORIZAÇÃO
¡ Defina quais objetivos devem ser atingido
¡ Quais são os resultados esperados?
¡ O que evitar?
¡ Definições subjetivas, exemplo: “melhorias”
¡ Tudo é prioridade
¡ O que fazer?
¡ Resultados esperados de forma testável e mensurável:
¡ Como validar se o resultado foi atingido?
¡ Comunicar claramente o que será feito e o que não será feito!
PRIORIZAÇÃO
¡ Defina quais objetivos devem ser atingido
¡ Quais são os resultados esperados?
¡ O que evitar?
¡ Definições subjetivas, exemplo: “melhorias”
¡ Tudo é prioridade
¡ O que fazer?
¡ Resultados esperados de forma testável e mensurável:
¡ Como validar se o resultado foi atingido?
¡ Comunicar claramente o que será feito e o que não será feito!
PRIORIZAÇÃO
¡ Defina quais objetivos devem ser atingido
¡ Quais são os resultados esperados?
¡ O que evitar?
¡ Definições subjetivas, exemplo: “melhorias”
¡ Tudo é prioridade
¡ O que fazer?
¡ Resultados esperados de forma testável e mensurável:
¡ Como validar se o resultado foi atingido?
¡ Comunicar claramente o que será feito e o que não será feito!
PRIORIZAÇÃO
¡ Defina quais objetivos devem ser atingido
¡ Quais são os resultados esperados?
¡ O que evitar?
¡ Definições subjetivas, exemplo: “melhorias”
¡ Tudo é prioridade
¡ O que fazer?
¡ Resultados esperados de forma testável e mensurável:
¡ Como validar se o resultado foi atingido?
¡ Comunicar claramente o que será feito e o que não será feito!
DIGA NÃO
¡ Foco!
¡ Diga não! Mas como?
¡ O que acontece se isso não for feito?
¡ Por que isso é mais importante do que as prioridades?
¡ Típicos: PRECISAMOS AGORA:
¡ Isso é um requisito LEGAL!
¡ É de interesse do CEO
¡ O impacto atinge MUITOS usuários!
DIGA NÃO
¡ Foco!
¡ Diga não! Mas como?
¡ O que acontece se isso não for feito?
¡ Por que isso é mais importante do que as prioridades?
¡ Típicos: PRECISAMOS AGORA:
¡ Isso é um requisito LEGAL!
¡ É de interesse do CEO
¡ O impacto atinge MUITOS usuários!
SPRINT GOAL, OBJETIVOS CONCRETOS
¡ Sprint Goal: Define qual é o foco durante o ciclo da Sprint
¡ O que evitar?
¡ Múltiplos objetivos
¡ Múltiplos times
¡ Objetivo definido ao terminar a Sprint Planning
¡ O que fazer?
¡ Definir o objetivo antes de começar a Sprint
¡ Definir o objetivo com clareza
¡ Colocar tarefas apenas referente ao objetivo
LESS IS MORE
¡ Um objetivo por vez
¡ Multi tarefa? Não, obrigado!
¡ Foco no que é necessário!
EXERCÍCIOS
Faça uma reflexão sobre as 3 últimas vezes que você disse não sobre uma solicitação:
¡ Você desafiou a solicitação? Se sim, houve uma explicação satisfatória?
¡ Qual foi a reação do solicitante ao ouvir o não?
¡ Houve uma tentativa de top-down?
¡ A solicitação de fato era relevante?
¡ Haveria uma melhor forma de abordar ou evitar a situação?
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
PROBLEM SOLVER
TENHO O MINDSET FOCADO EM RESOLVER PROBLEMAS
PROBLEM SOLVER
¡ Foco no problema¡ Qual o problema que resolvemos?
¡ E se… e se… Foco, take risks
FOCO NO PROBLEMA
¡ Start with why
¡ Problema vs Solução
¡ Ouça o cliente
¡ Problemas
¡ Dificuldades
FOCO NO PROBLEMA
¡ Start with why
¡ Problema vs Solução
¡ Ouça o cliente
¡ Problemas
¡ Dificuldades
FOCO NO PROBLEMA
¡ Start with why
¡ Problema vs Solução
¡ Ouça o cliente
¡ Problemas
¡ Dificuldades
QUAL O PROBLEMA QUE RESOLVEMOS?
¡ Sempre pergunte qual o problema é resolvido?
¡ Evite resolver um problema que não existe
¡ Envolva sempre o cliente!
¡ Pergunte, não suponha
E SE… E SE… FOCO, TAKE RISKS
¡ E se isso acontece?
¡ Isso não vai funcionar… 
¡ Entregue e teste!
E SE… E SE… FOCO, TAKE RISKS
¡ E se isso acontece?
¡ Isso não vai funcionar… 
¡ Entregue e teste!
EXERCÍCIOS
Avalie como você aborda os seguintes cenários:
¡ Como você comunica seus objetivos com o time?
¡ Como você busca resolver os problemas? O foco seria o produto ou o cliente?
¡ Você supõe a existência de problemas ou arrisca?
¡ O resultado atingido é satisfatório?
¡ Como você poderia melhorar o resultado?
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
MEDIR OS RESULTADOS
MEASURE WHAT MATTERS
MEDIR OS RESULTADOS
¡ Construa produtos de forma mensurável
¡ Objective Key Result
¡ Net Promoter Score
¡ Indicadores para web/mobile
¡ Fúnil de vendas
CONSTRUA PRODUTOS DE FORMA MENSURÁVEL
¡ Sempre defina como medir o resultado
¡ É importante saber se o resultado foi atingido, pois:
¡ Se não foi, o que fazer?
¡ Melhorar?
¡ Pivotar?
¡ Parar?
CONSTRUA PRODUTOS DE FORMA MENSURÁVEL
¡ Sempre defina como medir o resultado
¡ É importante saber se o resultado foi atingido, pois:
¡ Se não foi, o que fazer?
¡ Melhorar?
¡ Pivotar?
¡ Parar?
CONSTRUA PRODUTOS DE FORMA MENSURÁVEL
¡ Sempre defina como medir o resultado
¡ É importante saber se o resultado foi atingido, pois:
¡ Se não foi, o que fazer?
¡ Melhorar?
¡ Pivotar?
¡ Parar?
OBJECTIVE KEY RESULT
¡ OKRs: uma ferramenta simples para gerar alinhamento
entre objetivos e resultados
¡ Objetivos: onde queremos chegar?
¡ Key Results: quais resultados ajudam a alcançar os
objetivos?
¡ Mensurável de forma clara
¡ Quem utiliza? Google, Intel, Samsung, Microsoft etc.
OKR - EXEMPLO
¡ Objetivo: engajar mais lojistas na plataforma de leilão de carros usados
¡ Resultados Chaves:
¡ Aumentar o número de lojistas ativos mensalmente em 30% até o final do mês de Junho/2019
¡ Aumentar o número de lances feitos por lojistas em 40% até o final do mês de Junho/2019
¡ Duplicar o tempo de sessão dos lojistas até o final do mês de Junho/2019
NET PROMOTER SCORE
¡ NPS: em uma escala de 0 a 10 qual a chance de recomendar o serviço?
¡ Detratores: insatisfeitos, denigrem o serviço
¡ Passivo: neutros, não são leais ao serviço
¡ Promotores: recomendam o serviço e são leais
¡ Como calcular?
¡ 70 – 100: Excelente serviço
¡ 30 – 70: Ótimo serviço
¡ 0 – 30: Atenção
¡ -100 – 0: Precisa de ações urgentemente
INDICADORES PARA WEB/MOBILE
¡ Indicadores:
¡ Unique Users
¡ New Users
¡ MAU: Monthly Active Users
¡ WAU: Weekly Active Users
¡ Bounce Rate: %usuários que saem sem ação
¡ Tempo de Sessão: tempo de utilização
FÚNIL DE VENDAS
¡ Taxa de conversão:
¡ Plataforma
¡ Dispositivo
¡ Fonte do tráfego
¡ Diferentes caminhos
¡ Newsletters
¡ Google
¡ Busca
EXERCÍCIOS
Prepare ao menos um fúnil de vendas para cada uma das empresas a seguir:
¡ Uber
¡ AirBnB
¡ Amazon
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
APRENDIZADO CONSTANTE
APRENDA TODOS OS DIAS
APRENDIZADO CONSTANTE
¡ MVP
¡ MLP
¡ Lean Startup
¡ Aprenda diariamente
MINIMUM VIABLE PRODUCT
¡ Definição da hipótese
¡ Definição do público alvo
¡ Definir um protótipo
¡ Vantagens
¡ Baixo investimento
¡ Curto tempo de desenvolvimento
¡ Rápida validação da hipótese
¡ Mitos do MVP
¡ Precisa ser feio
¡ Deve conter erros
MOST LOVABLE PRODUCT
¡ Most Lovable Product
¡ Pequeno grupo de usuário
¡ Aprimoração constante
¡ Busca da maior satisfação
¡ Não é escalável
LEAN STARTUP
¡ Lean Startup movement
¡ Feedback loop
¡ O que fazer?
¡ Persistir
¡ Pivotar
¡ Parar
APRENDA DIARIAMENTE
¡ Participe de Meet-ups
¡ Ouça todos ao seu redor
¡ Busque novos conhecimentos
¡ Observe o que as outras empresas
fazem
¡ Estude novos modelos de negócio
¡ Copie sucesso
¡ Leia novos livros
EXERCÍCIOS
Você já implementou um MVP ou MLP? Se sim:
¡ Qual foi a sua experiência?
¡ O que funcionou?
¡ O que não funcionou?
¡ Como poderia ter obtido um melhor resultado?
Caso nunca tenha implementado, qual seu ponto de vista para:
¡ Como ser bem sucedido com um MVP ou MLP?
¡ Quais são os grandes desafios?
¡ Qual o principal resultado?
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
ATIVIDADES DO PRODUCT OWNER
QUAIS ATIVIDADES O PO FAZ EM SEU DIA A DIA?
ATIVIDADES DO PO
BACKLOG
ONDEVAMOS?
BACKLOG
¡ Product Backlog
¡ User Stories
¡ Bugs
¡ Spikes
¡ User Story Mapping
PRODUCT BACKLOG
¡ Composto de Product Backlog Items (PBI)
¡ User Stories
¡ Spikes
¡ Bugs
¡ Qual a idade máxima um PBI deve ter?
¡ Quando devemos revisar?
¡ Ordenado da prioridade mais alta para a menor
¡ Backlog total
¡ Por Sprints
PRODUCT BACKLOG
¡ Composto de Product Backlog Items (PBI)
¡ User Stories
¡ Spikes
¡ Bugs
¡ Qual a idade máxima um PBI deve ter?
¡ Quando devemos revisar?
¡ Ordenado da prioridade mais alta para a menor
¡ Backlog total
¡ Por Sprints
USER STORIES
¡ Composta de três partes principais
¡ Proposta de valor
¡ Modelo Tradicional: Como <cliente> gostaria de <pagar as minhas compras com qualquer cartão de crédito> para que <eu
tenha mais flexiblidade com o pagamento>
¡ Modelo focado no valor: Para que <eu tenha mais flexibilidade com o pagamento>, como cliente, gostaria de <pagar minhas
compras com qualquer cartão de crédito>
¡ Critérios de Aceitação
¡ O que deve ser definido para avaliar se o objetivo foi atingido?
¡ Conversa com o time
¡ Discussão com o time sobre como abordar esta solução
CRITÉRIOS DE ACEITAÇÃO
¡ Define como verificar se uma User Story foi concluída
¡ Modelo tradicional:
¡ Quando um cartão de crédito válido é informado, o pagamento é processado
¡ Modelo Gherkin:
¡ Dado que um cartão de crédito válido é informado, e.g. xxxx
¡ Quando o usuário solicita o pagamento
¡ Então o pagamento é processado
¡ E o usuário recebe a confirmação de forma imediata
FATORES IMPORTANTES PARA USER STORIES
BUGS
¡ Representação qualquer comportamento inesperado no Sistema
¡ O formato de descrição pode variar, o importante é ter as informações necessárias para reproduzir o problema
¡ Qual o impacto?
¡ O usuário é bloqueado ou há alguma alternativa?
¡ Sugestão: utilizar Gherkin para descrever o Bug tanto quando o cenário esperado
BUGS
¡ Exemplo de um bug para pagamento com cartões Master Card
¡ Como reproduzir o BUG
¡ Dado que estou no check-out
¡ Quando eu faço o pagamento com cartão de Crédito
¡ E o cartão informado é Master Card
¡ Então o pagamento não é concluído
¡ E uma mensagem de erro é apresentada
¡ Cenário esperado
¡ Dado que estou no check-out
¡ Quando eu faço o pagamento com cartão de Crédito
¡ E o cartão informado é Master Card
¡ Então o pagamento é concluído
¡ E uma mensagem de sucesso é apresentada
SPIKES
¡ São utilizadas para que o time de desenvolvimento possa investir um determinado tempo para pesquisar como
uma tarefa pode ser melhor implementada:
¡ Quanto tempo? Definido pelo Product Owner
¡ Quando usar? Quando houver incerteza do time
USER STORY MAPPING
¡ User Story Mapping: forma visual de apresentar a jornada do usuário e entender quais são as atividades
necessárias para prover a melhor experiência do usuário.
EXERCÍCIOS
Pense em um produto que você admira e faça uma sugestão para:
¡ Jornada do usuário
¡ Definição de épicos
¡ Definição de User Stories para os épicos
COMO SER UM PRODUCT OWNER
DavidPereira 
david.aurelio@yahoo.com.br
GROOMING
O MOMENTO DE REFINAR O BACKLOG
GROOMING
¡ O que é o Grooming?
¡ Story Points
¡ Planning Poker
¡ Team Estimation Game
O QUE É O GROOMING?
¡ Refinamento das tarefas
¡ PO apresenta
¡ Time discute
¡ Estimativa é feita
¡ Qual a frequência e duração?
¡ O que evitar?
¡ Discussões extensas
¡ Tarefas que não são prioridades
¡ Qual o resultado esperado?
¡ Tarefas discutidas entre o time
¡ Refinamento das tarefas
¡ Tarefas prontas para serem priorizadas
STORY POINTS
¡ Uma maneira de fazer estimativas
¡ São referentes à complexidade
¡ Não tem conexão com o tempo
¡ Quais são os possíveis valores?
¡ Como começar?
PLANNING POKER
¡ Dinâmica utilizada para fazer estimativas.
¡ Como funciona?
1. PO apresenta a tarefa
2. Time de desenvolvimento discute
3. Time de desenvolvimento estima
4. Quem colocou a menor estimativa deve falar
5. Quem colocou a maior estimativa deve falar
6. Este ciclo ocorre até atingir o consenso
PLANNING POKER
¡ Dinâmica utilizada para fazer estimativas.
¡ Como funciona?
1. PO apresenta a tarefa
2. Time de desenvolvimento discute
3. Time de desenvolvimento estima
4. Quem colocou a menor estimativa deve falar
5. Quem colocou a maior estimativa deve falar
6. Este ciclo ocorre até atingir o consenso
PLANNING POKER
¡ Dinâmica utilizada para fazer estimativas.
¡ Como funciona?
1. PO apresenta a tarefa
2. Time de desenvolvimento discute
3. Time de desenvolvimento estima
4. Quem colocou a menor estimativa deve falar
5. Quem colocou a maior estimativa deve falar
6. Este ciclo ocorre até atingir o consenso
PLANNING POKER
¡ Vantagens
¡ Discussão entre o time sobre diferentes pontos de vista
¡ Consenso entre o time
¡ Desvantagens
¡ Pode se tornar tecnica
¡ Pode gerar discussões infinitas
¡ Lentidão na estimativa
TEAM ESTIMATION GAME
¡ Dinâmica entre o time para estimar as User Stories
1. Scrum Master prepara o ambiente
2. PO traz as User Stories em cards
3. Um membro do time pega a primeira User Story
1. Lê em voz alta e clara
2. Seleciona o tamanho da User Story
4. Os próximos membros podem:
1. Reestimar as User Stories
2. Estimar uma nova User Story
5. A dinâmica continua até que todas User Stories estejam estimadas
6. O time faz o refinamento
7. A dinâmica se encerra quando todos do time estão de acordo
TEAM ESTIMATION GAME
¡ Dinâmica entre o time para estimar as User Stories
1. Scrum Master prepara o ambiente
2. PO traz as User Stories em cards
3. Um membro do time pega a primeira User Story
1. Lê em voz alta e clara
2. Seleciona o tamanho da User Story
4. Os próximos membros podem:
1. Reestimar as User Stories
2. Estimar uma nova User Story
5. A dinâmica continua até que todas User Stories estejam estimadas
6. O time faz o refinamento
7. A dinâmica se encerra quando todos do time estão de acordo
TEAM ESTIMATION GAME
¡ Vantagens
¡ Possível estimar cerca de 60 Users Stories por hora
¡ As tarefas são estimadas de forma direta
¡ Desvantagens
¡ Pode faltar informações para o time
¡ Não há discussão sobre as tarefas
EXERCÍCIOS
¡ O que é o Grooming?
¡ Story Points
¡ Planning Poker
¡ Estimation Game
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
SPRINT PLANNING
QUAL SERÁ O FOCO?
SPRINT PLANNING
¡ Como funciona a Sprint Planning?
¡ O que fazer?
¡ O que evitar?
¡ Planning 2
¡ Comunicação
COMO FUNCIONA A SPRINT PLANNING?
¡ O PO define o objetivo da Sprint
¡ O time de desenvolvimento determina a capacidade
¡ O PO apresenta as tarefas priorizadas
¡ O time determina se pode se comprometer
¡ Onde a prática diverge a teoria?
¡ Estimar tarefas na Sprint Planning
¡ Criar tarefas durante a Sprint Planning
¡ Objetivos não claros
¡ Spill over Sprint anterior
O QUE FAZER?
¡ O que ajuda a Sprint Planning ser bem executada?
¡ Ter um objetivo claro
¡ Tarefas prontas para serem priorizadas
¡ Tarefas refinadas com o time
¡ Tarefas estimadas
¡ Não ter surpresas com novas tarefas
O QUE EVITAR?
¡ O que atrapalha a Sprint Planning?
¡ Estimar tarefas durante a planning
¡ Criar tarefas durante a planning
¡ Não ter um objetivo
¡ PO não estar preparado
¡ Backlog desorganizado
¡ User Stories antigas
PLANNING 2
¡ O que é a planning 2?
¡ Abordagem técnica é definida
¡ Tarefas são divididas em sub-tarefas
¡ Time define a estratégia
¡ PO deve estar disponível para eventuais dúvidas
¡ O que acontece se não fazer?
¡ O time não terá clareza na execução durante a Sprint
¡ Quanto tempo?
¡ Sprint quinzenal, 2 horas
COMUNICAÇÃO
¡ O PO comunica com todos os interessados
¡ O objetivo da Sprint deve ser visual para o time
¡ Um board físico auxilia a comunicação
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
VALIDAÇÃO DAS TAREFAS
O QUE ESTÁ PRONTO PARA SER ENTREGUE?
VALIDAÇÃO DAS TAREFAS
¡ Responsabilidades do PO
¡ Validação no dia a dia
¡ Quem faz os testes?
¡ Quando a tarefa está pronta para ser entregue?
¡ Qual o papel do PO durante a Review?
RESPONSABILIDADES DO PO
¡ Garantir que a proposta de valor foi atingida
¡ Aprovar tarefas para serem entregues
¡ Validar com os usuários
VALIDAÇÃO NO DIA A DIA
¡ Daily Scrum
¡ Feedback rápido
¡ Ambiente de teste e.g. Staging ou Sandbox
QUEM FAZ OS TESTES
¡ O time garante o funcionamento do 
ponto de vista técnico
¡ Se houver QA, executa os testes 
integrados, regressivos e explorativos
¡ PO valida o atingimento do objetivo
¡ Quem testa primeiro?
QUANDO A TAREFA ESTÁ PRONTA PARA SER ENTREGUE?
¡ Após atingir todos os critérios de aceitação
¡ Após a garantia que as funcionalidades antigas
continuam funcionando
¡ Aprovação do PO
QUAL O PAPEL DO PO DURANTE A REVIEW?
¡ Teoria:
¡ Observar a apresentação do time
¡ Receber feedback dos usuários
¡ Prática
¡ Fazer a apresentação quando o time solicita
¡ Receber o feedback dos usuários
¡ Informar quando o Release será feito
¡ Apresentar qual será o foco do time na próxima Sprint
EXERCÍCIO
Faz uma análise sobre o seu cenário de trabalho e responda as seguintes perguntas:
¡ Qual a frequência que você dá feedback para as tarefas do time?
¡ Quão disponível você é para avaliar as tarefas do time?
¡ Quão acessível você é para responder as dúvidas do time?
¡ Em caso de QA, há casos de conflitos? Se sim, quais e como poderia evitar?
¡ Em seu cenário, a review é feita? Se sim, quem apresenta e qual a frequência? Se não, por que?
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
PREPARAÇÃO DE CONCEITOS
IDENTIFICAR AS NECESSIDADES ALÉM DOS DESEJOS
PREPARAÇÃO DE CONCEITOS
¡ Como a necessidade surge?
¡ Como o PO deve liderar a criação do conceito?
¡ Mapas mentais
¡ Brainstorming
¡ User Journey
¡ Entrevistas
COMO A NECESSIDADE SURGE?
¡ Desenvolvimento de um novo produto
¡ Explorar uma oportunidade
¡ Atender um mercado inexplorado
¡ Otimizar um serviço
¡ Resolver um problema
¡ Evolução de um produto
¡ Necessidade legal
COMO O PO DEVE LIDERAR A CRIAÇÃO DO CONCEITO?
¡ Entender qual é o problema resolvido
¡ Entender qual é o resultado esperado
¡ Definir como medir o resultado
¡ Definir o que é necessário
¡ Garantir o entendimento único entre todos
¡ Definir os releases
¡ Liderar a comunicação
¡ Organizar o time para atingir o objetivo
MAPAS MENTAIS
¡ O que são?
¡ Onde utilizar?
¡ Entendimento detalhado do produto ou serviço
¡ Demonstrar as conexões
¡ Quais são as vantagens?
¡ Fácil utilização
¡ Entendimento simplificado
¡ Visualização em página única
¡ Quais são as desvantagens?
¡ Pode limitar a criatividade se abordado como escopo
MAPAS MENTAIS
BRAINSTORMING
¡ O que é?
¡ Onde utilizar?
¡ Quando se explora oportunidades
¡ Quando se necessidade de diferentes ideias
¡ Pensar fora do contexto
¡ Duração máxima de 1h 
¡ Quais são as vantagens?
¡ Muitas ideias em um curto espaço de tempo
¡ Ideias disruptivas podem ser apresentadas
¡ Quais são as desvantagens?
¡ Pode gerar falsas expectativas¡ Precisa de um ótimo moderador
USER JOURNEY
¡ O que são?
¡ Onde utilizar?
¡ Preparar o conceito baseado nos pontos
de contato com o usuário
¡ Quais são as vantagens?
¡ Clareza onde faz sentido interagir com o 
usuário
¡ Melhor entendimento do usuário
¡ Quais são as desvantagens?
¡ Pode limitar a criatividade
ENTREVISTAS
¡ O que são?
¡ Onde utilizar?
¡ Necessidade de entender o problema do usuário
¡ Quais são as vantagens?
¡ Contato direto com o usuário final
¡ Facilidade do entendimento das dores do usuário
¡ Quais são as desvantagens?
¡ Lentidão no processo
¡ Dependendo do caso, muitas entrevistas são necessárias
EXERCÍCIOS
A minha técnica favorita é a utilização de mapas mentais devido a sua praticidade e resultados, por isso sugiro os
seguintes exercícios:
¡ Para POs: faça um Mind-Map da sua rotina de trabalho, busque encontrar o que pode ser aprimorado
¡ Se você não é um PO: faça um Mind-Map para entender o que é necessário para se torna um PO
¡ Faça um Mind-Map explorando o modelo de negócios de uma empresa digital que você gosta
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
ESTRUTURAS
QUAIS SÃO AS VARIÁVEIS DO AMBIENTE EM QUE O PO TRABALHA?
ESTRUTURAS
HIERARQUIA
QUAIS AS PARTICULARIDADES DE CADA ESTRUTURA?
HIERARQUIA
¡ TI
¡ Negócios
¡ Produto
¡ Híbrida
TI
¡ Pra quem o PO reporta?
¡ Lider Técnico
¡ CTO
¡ Quem é o time?
¡ Líderes técnicos
¡ Quais são os desafios?
¡ Temas técnicos
¡ Distante da área de negócios
¡ Onde fica o foco? 
¡ Geralmente na tecnologia do produto
NEGÓCIOS
¡ Pra quem o PO reporta?
¡ CEO / COO
¡ Área em que representa
¡ Quem é o time?
¡ Gerentes
¡ Analista de negócio
¡ Quais são os desafios?
¡ Alinhar as expectativas
¡ Respeitar as limitações técnicas
¡ Evitar múltiplos projetos em paralelo
¡ Onde fica o foco? 
¡ Negócios
PRODUTOS
¡ Pra quem o PO reporta?
¡ CPO / Head of Products
¡ Líder de produtos
¡ Quem é o time?
¡ UX
¡ UI
¡ Quais são os desafios?
¡ Definir o foco
¡ Respeitar as limitações técnicas
¡ Evitar múltiplos projetos em paralelo
¡ Onde fica o foco? 
¡ Cliente
HÍBRIDA
¡ Pra quem o PO reporta?
¡ Tecnicamente para produtos
¡ Comportalmente para negócios
¡ Quem é o time?
¡ Líder de produtos
¡ Time de negócios
¡ Quais são os desafios?
¡ Conflito de prioridades
¡ Diferentes expectativas
¡ Onde fica o foco? 
¡ Maximizar o valor entregue
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
TIME DE DESENVOLVIMENTO
QUAIS SÃO AS VARIÁVEIS?
TIME DE DESENVOLVIMENTO
¡ Onde o time de desenvolvimento fica?
¡ O time de desenvolvimento entende o negócio?
¡ Onde o PO fica?
¡ Qual a disponibilidade do PO para o time?
ONDE O TIME DE DESENVOLVIMENTO FICA?
¡ Mesmo escritório que o PO
¡ Em outro escritório, mesma cidade
¡ Em outra cidade, mesmo país
¡ Em outro país
O TIME DE DESENVOLVIMENTO ENTENDE O NEGÓCIO?
¡ O time faz parte do quadro de funcionários
da empresa?
¡ O produto ou serviço é comum para todos?
¡ O time é multicultural?
ONDE O PO FICA?
¡ Fisicamente com o time de desenvolvimento
¡ Na área de produtos
¡ Na área de negócios
QUAL A DISPONIBILIDADE DO PO PARA O TIME?
¡ Qual a frequência que conversa com o time?
¡ Diariamente
¡ Apenas em cerimônias do Scrum
¡ Quando o time solicita
¡ Como o time contata o PO?
¡ Pessoalmente
¡ Video-Call
¡ Chat
¡ E-mail
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
AUTONOMIA
QUAL É O NÍVEL DE AUTONOMIA DO PO?
AUTONOMIA
¡ Prioridades
¡ Investimento
¡ Definição das tarefas
¡ Aprovação das tarefas
PRIORIDADE
¡ Quem define as prioridades?
¡ Product Owner
¡ Área de Negócios
¡ Área de Projetos
¡ Board da Empresa
INVESTIMENTO
¡ Como o investimento é definido?
¡ Product Owner
¡ Solicitante através de um Business Case
¡ Board da empresa
DEFINIÇÃO DAS TAREFAS
¡ Quem prepara as tarefas para o time?
¡ Product Owner
¡ Solicitante
¡ É necessário a aprovação da tarefa antes do desenvolvimento?
APROVAÇÃO DAS TAREFAS
¡ Quem determina se a tarefa está pronta?
¡ Product Owner
¡ Solicitante
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
PRODUTOS E SERVIÇOS?
COMO É O PRODUTO QUE O PO TRABALHA?
PRODUTOS E SERVIÇOS
¡ Sistema interno
¡ Software de Prateleira
¡ SaaS (Solution as a service)
¡ Digital B2C
¡ Middleware
SISTEMA INTERNO
¡ Quem é o cliente?
¡ Interno
¡ Qual é o nível de contato do PO?
¡ Frequência alta
¡ Qual o foco?
¡ Melhoria de processos
¡ Qual o formato de trabalho?
¡ Em conjunto com o cliente interno
¡ Exemplo:
¡ ERP desenvolvido internamente
SOFTWARE DE PRATELEIRA
¡ Quem é o cliente?
¡ Usuários do software
¡ Qual é o nível de contato do PO?
¡ Baixo
¡ Qual o foco?
¡ Construção do produto (geralmente Waterfall)
¡ Qual o formato de trabalho?
¡ Liderança entre as áreas para garantir o objetivo
¡ Exemplo:
¡ Microsoft Office
SAAS (SOLUTION AS A SERVICE)
¡ Quem é o cliente?
¡ Empresas ou clientes finais
¡ Qual é o nível de contato do PO?
¡ Frequência média
¡ Qual o foco?
¡ Maximizar o valor entregue
¡ Qual o formato de trabalho?
¡ Evolução iterativa da plataforma
¡ Exemplo:
¡ Dropbox
DIGITAL B2C
¡ Quem é o cliente?
¡ Clientes externos
¡ Qual é o nível de contato do PO?
¡ Frequência média
¡ Qual o foco?
¡ Maximizar o valor entregue
¡ Qual o formato de trabalho?
¡ Evolução iterativa da plataforma
¡ Exemplo
¡ Amazon
MIDDLEWARE
¡ Quem é o cliente?
¡ Público técnico
¡ Qual é o nível de contato do PO?
¡ Frequência alta
¡ Qual o foco?
¡ Garantir o atendimento dos requisitos
¡ Qual o formato de trabalho?
¡ Evolução do middleware facilitando a utilização
¡ Exemplo:
¡ Ferramentas de transformação de dados
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br
RECOMENDAÇÃO PARA LEITURA
SEJA UM ETERNO APRENDIZ
SCRUM
¡ The art of doing twice the work in Half the 
Time – Jeff Sutherland 
¡ Large Scale Scrum, more with LeSS
USER STORIES
¡ User Stories Applied – Mike Cohn
INOVAÇÃO
¡ Creative Confidence – Tom 
Kelley and David Kelley
¡ The art of Innovation – Tom 
Kelley
APRIMORAR A COMUNICAÇÃO
¡ Start with why – Simon Sinek
¡ Drive – Daniel Pink
MEÇA O QUE IMPORTA
¡ Measure what matters – John Doerr
HABILIDADES INTERPESSOAIS
¡ The 7 habits of highly effective people 
– Stephen Covey
MODELO DE NEGÓCIOS
¡ Business Model Generation – Alexander 
Osterwalder & Yves Pigneur
¡ Value Proposition Design – Alexander 
Osterwalder & Yves Pigneur
COMO SER UM PRODUCT OWNER
David Pereira 
david.aurelio@yahoo.com.br