Práticas para Operação do Produto

Prof. Thiago Trevisan

2022
SUMÁRIO
Capítulo 1. Quem é o PM ............................................................................................... 5

1.1 Perfil do PM ............................................................................................................................. 6

1.2 Estratégia ................................................................................................................................. 9

1.3 Perfis da empresa (Eficiência, Qualidade ou Consumidor) ............................ 10

1.4 Básico de TI para ser um PM........................................................................................ 12

1.5 Liderança ............................................................................................................................... 16

Capítulo 2. Gerenciamento de portfólio .............................................................. 21

2.1 Diferença entre projeto, programa e portfólio ..................................................... 21

2.2 Estruturas de uma organização.................................................................................. 22

2.3 Cadeias de valor ................................................................................................................. 24

Capítulo 3. Ágil Escalado ........................................................................................... 27

3.1 Era digital .............................................................................................................................. 27

3.2 Estabelecer o time ............................................................................................................ 29

3.3 Construção de soluções em times ágeis ................................................................ 31

3.4 PI Planning........................................................................................................................... 32

Capítulo 4. Lean Agile.................................................................................................. 35

4.1 Principais Valores .............................................................................................................. 35

4.2 Pensamento Lean ............................................................................................................. 36

4.3 Manifesto Ágil ..................................................................................................................... 38

4.4 Princípios Lean-Agile ....................................................................................................... 39

Capítulo 5. Integração ................................................................................................ 42

5.1 PO Sync e Scrum of scrums.......................................................................................... 42

5.2 Direção e gestão (o que é necessário formalizar) .............................................. 43

Capítulo 6. Ferramentas de Discovery ................................................................. 46

6.1 Pesquisa, Entrevista, Observação, Benchmarking ............................................. 46

2
 6.2 Matriz CSD, Personas, Mapa de Empatia................................................................ 47

6.3 Design Thinking ................................................................................................................. 49

Capítulo 7. Engenharia de Valor ............................................................................. 52

7.1 Matriz SWOT ........................................................................................................................ 52

7.2 Priorização de Backlog .................................................................................................... 53

Capítulo 8. Cultura do Feedback ............................................................................ 57

8.1 Métricas de Satisfação.................................................................................................... 57

8.2 NPS (Relacional e Transacional) ................................................................................ 58

8.3 Times Customer Centricity ........................................................................................... 59

Referências ......................................................................................................................... 60

3
1
Capítulo 1. Quem é o PM
O Product Manager (PM) é o profissional facilitador do trabalho de
sua equipe, porque ele é responsável por estruturar o trabalho de forma
eficiente, garantir as entregas dentro dos critérios estabelecidos, bem como
conectar a experiência do cliente, Tecnologia e Negócios.

A imagem a seguir apresenta uma referência bastante comum e

amplamente utilizada para demonstrar o perfil do PM:

Figura 1 − Perfil do PM

Fonte: Medium

Dentro do contexto de negócios, espera-se que o PM tenha uma

visão de gestão de produto muito relacionada ao retorno que este trará para
organização, pois o que ele está produzindo junto ao time deve ser rentável
e habilitar novas capacidades para o negócio.

O PM é um profissional também de tecnologia, dado que estamos

no meio de uma era digital. Dessa forma, vale citar uma frase do Dean
Leffingwell, criador do Scaled Agile Framework (SAFe), a qual diz o seguinte:
“neste momento, toda empresa é uma empresa de software. Alcançar um

5
estado de Agilidade nos Negócios significa que toda a organização − não
apenas desenvolvimento − está continuamente envolvida e entregando
negócios inovadores de forma proativa, assim como apresentando soluções
mais rápidas do que a concorrência.” Nesse sentido, nota-se a importância
de se ter a visão tecnológica que irá direcioná-lo à forma de desenvolver os
produtos digitais.

Com relação a User Experience (UX) ou Customer Experience (CX),

é fundamental que o PM compreenda conceitos de usabilidade e princípios
de design, pois é sua função conectar o produto com o cliente e assegurar
que ele tenha uma experiência que o faça utilizar o produto.

Não é necessário que o PM seja um profundo especialista nessas

áreas, porque habitualmente, no time que compõe um produto, existem os
Subject Matter Expert (SME) − os especialistas de negócios −, o time de
tecnologia, os arquitetos, os desenvolvedores, os analistas de qualidade,
assim como o time de experiência do cliente, que pode ser composto pelos
Product Design (PD) e consultores de Customer Experience (CX). Vale
destacar que essas funções ainda são relativamente novas para a maioria
das organizações, então é muito comum que sejam confundidas com cargos
ou até mesmo tenham nomes e interpretações distintas.

1.1 Perfil do PM
De acordo com a Mckinsey (2017), o PM deve ser um mini CEO,
partindo do princípio que o papel do Product Manager está se expandindo
devido à crescente importância dos dados na tomada de decisões, ao maior
foco no cliente e no design e à evolução das metodologias de
desenvolvimento de software.

6
 Figura 2 − Perfil do PM

Fonte: Mckinsey

Os perfis acima foram destacados com base em entrevistas feitas

pela Mckinsey. Mesmo sabendo que tem o seu viés, é importante lembrar
que o PM atua na interseção entre negócios, tecnologia e CX.

O PM com o perfil tecnológico tende a assumir mais riscos com

relação às soluções técnicas a serem implementadas, enquanto o perfil
generalista, que possui conhecimentos técnicos e experiência de negócios,
tende a desenvolver produtos em que a experiência do cliente seja o
principal foco. O PM com perfil de negócios, por sua vez, tem a maximização
dos resultados como foco maior.

Para ser um excelente PM, as competências vão muito além das

habilidades técnicas. Se você espera ser um gerente de produto, é
fundamental que tenha conhecimentos em OKR, KPIs, marketing, design,
agilidade, pesquisa, usabilidade etc., uma vez que são competências básicas
para executar tecnicamente a função e expandir o conhecimento. No
entanto, vale destacar que isso não é o suficiente e talvez seja a parte menos

7
importante. Nesse sentido, as principais características que compõem um
excelente PM referem-se à sua habilidade de relacionamento, à sua
inteligência emocional ou softskill, à sua capacidade de entendimento do
contexto de atuação, à influência a ser exercida nas diversas áreas em que
há a necessidade do estabelecimento de pontes para a evolução do seu
produto, ao momento e à cultura da empresa. À vista disso, destacamos
abaixo alguns dos atributos que devem integrar o seu perfil:

Empatia: uma das definições possíveis é a capacidade de se

identificar com outra pessoa, de querer o que ela quer ou até mesmo de
sentir o que ela sente. Em outros termos, ter empatia é conseguir estar no
lugar do outro.

Liderança por influência: liderar é dirigir pessoas, isto é, conseguir

influenciá-las e inspirá-las para que gerem melhores resultados. É muito
comum que o termo “liderança” esteja associado a uma posição formal de
chefia dentro das organizações, mas isso nem sempre é realidade para um
PM.

Estrategista: o estrategista é uma pessoa responsável pela criação

e aplicação de uma estratégia. Ela geralmente engloba ações, metas e
prazos para que o objetivo seja atingido.

Orientado ao Business: a orientação ao negócio é a capacidade que

uma pessoa tem para focar na concretização dos objetivos da empresa,
entender a estratégia e traçar metas para que seu produto gere resultado.

Decisor: o ato de aprender a tomar decisões pode ser equivalente a

compreender quem você é e o que deseja para sua carreira. Ter coragem de
errar e assumir a consequência é essencial. Para o PM, o mais importante
consiste em decidir com base em dados, aprender e ajustar rapidamente o
caminho. Além disso, é fundamental estar bem-informado. Nesse contexto,
de acordo com o fundador da Amazon, “a maioria das decisões devem ser

8
feitas com cerca de 70% das informações que você deseja ter, pois, se
esperar até conseguir 90%, na maioria dos casos, vai se atrasar” (BEZOS
apud ANDERSON, 2020, p. 111).

Comunicativo: é preciso comunicar sua estratégia com facilidade e

garantir que todas as partes interessadas entendam o que será feito.
Somado a isso, você precisa ser um excelente contador de histórias.

Esse grupo de competências fazem parte das habilidades essenciais

de um PM e precisam ser treinadas. Além disso, são, em grande parte, muito
complexas para medirmos, mas um alinhamento com a liderança imediata
pedindo feedbacks pode ajudar na evolução contínua e no progresso quanto
à função de gerente de produto.

1.2 Estratégia
É inimaginável um PM que não tenha clareza acerca da estratégia da
empresa. Desse modo, torna-se crucial possuir conhecimento sobre onde
querem chegar, qual é o propósito, visão, missão, ambição, valores, objetivos
e metas. Ademais, muito antes de ter a estratégia concebida para o seu
produto, o PM deve conhecer o mercado em que atua e o impacto que a
organização em que trabalha gera à sociedade.

Sob uma perspectiva mais abrangente, é necessário conhecer o

contexto político e econômico do mercado em que se está atuando. Neste
momento, estamos atravessando uma pandemia mundial, e, dessa forma,
torna-se fundamental responder a algumas questões, tais como: qual a
relação disso com o posicionamento da empresa em o PM atua? Qual o
impacto que isso trará para o meu produto? Como eventualmente a
economia mundial interfere na criação de novas features? Há pouco tempo,
passamos por uma crise considerada por muitos como uma das piores que
já tivemos. A crise financeira de 2008 ocorreu por causa de uma bolha
imobiliária, nos Estados Unidos, que não foi acompanhada por um aumento

9
de renda da população. Nesse sentido, se as pessoas estão sem dinheiro,
como poderão pagar pelo meu produto? Este é o momento certo de lançar?

Nesse viés, conhecer o contexto cultural da população que irá

consumir nosso produto é outro fator essencial. Por exemplo, se estou
desenvolvendo algo para um Americano, é necessário o entendimento do
que aquele público valoriza. Na cultura estadunidense, aprecia-se muito o
que é prático, basta observarmos o sucesso das grandes redes de fast food.
Em contrapartida, quando pensamos em um produto para o público europeu
− identificado por atribuir maior valorização ao que é sofisticado −,
verificamos o sucesso e a repercussão mundial acerca das culinárias
francesa e italiana, todavia vale destacar que isso não se trata de uma regra
e certamente há público para estes exemplos mencionados. Nesse sentido,
o fit cultural entre o produto e o público fará a diferença se temos a ambição
de produtos globais.

As empresas quebram porque o comportamento de consumo muda

e as suas estratégias não são capazes de reagir rapidamente. Temos
diversos exemplos: taxis x Uber, blockbuster x Netflix, xerox x pdf etc. Então,
é importante levar em consideração que minha estratégia depende do que o
cliente quer.

1.3 Perfis da empresa (Eficiência, Qualidade ou Consumidor)

É muito importante para gestão eficiente do produto que o PM
entenda o perfil da empresa em que atua e compreenda qual é o momento
e a proposta de valor. Existem diversos perfis de empresa que se adequam à
estratégia para competir no mercado.

Algumas empresas são focadas em qualidade do produto que

oferecem, temos como exemplo a Apple, que se posiciona por ser icônica e
inovadora. Desse modo, o posicionamento da marca é “a ação de projetar a
oferta e a imagem da empresa para que ela ocupe um lugar diferenciado na
mente do público-alvo.” (KOTLER; KELLER, 2012, p. 294).

10
 Existe um outro grupo de empresa que se posiciona no mercado por
sua eficiência operacional. Um ótimo exemplo disso é o Walmart, dado que
sua eficiência resulta em melhores preços para os seus clientes, com boa
qualidade de produtos. Segundo Walton, fundador do Walmart, “só existe
um chefe: o cliente. E ele pode demitir todas as pessoas da empresa, do
presidente ao faxineiro, simplesmente levando o seu dinheiro para gastar
em outro lugar.” Nesse contexto, em um treinamento que ele mesmo
conduziu para seus funcionários, o perfil de eficiência ficou ainda mais nítido
quando disse:

Eu sou o homem que vai a um restaurante, senta-se à mesa e

espera pacientemente, enquanto o garçom faz tudo, menos
anotar o meu pedido. Eu sou o homem que vai a uma loja e
espera calado, enquanto os vendedores terminam suas
conversas particulares. Eu sou o homem que entra num posto
de gasolina e nunca usa a buzina, mas espera pacientemente
que o empregado termine a leitura do seu jornal. Eu sou o
homem que explica sua desesperada urgência por uma peça,
mas não reclama quando a recebe somente após três
semanas de espera. Eu sou o homem que, quando entra num
estabelecimento comercial, parece estar pedindo um favor,
implorando por um sorriso ou esperando apenas ser notado.
Você deve estar pensando que sou uma pessoa quieta,
paciente, do tipo que nunca cria problemas. Engana-se. Sabe
quem eu sou? Eu sou o cliente que nunca mais volta
(WALTON, [19–]).

Outro perfil de empresa refere-se àquelas que são centradas no

consumidor. Essas são as empresas de grande destaque, e como estamos
também vivendo a era do cliente, fica claro que as empresas que não
colocam o cliente no centro de sua estratégia terão grandes dificuldades em
sobreviver. Um grande exemplo desse perfil de empresa é a Amazon, posto
que sua cultura se caracteriza pela obsessão pelos clientes, de forma a

11
construir soluções que eles queiram ou até mesmo nem saibam que
queiram.

Entendendo qual é o perfil da sua empresa, ficará mais claro como

construir o seu produto que tenha fit cultural com seu público e esteja
alinhado à visão que a companhia almeja.

1.4 Básico de TI para ser um PM

Como já vimos, uma parte importante do perfil do PM passa por
conhecimentos técnicos. Não é necessário saber programar para ser um
gerente de produto, no entanto alguns conceitos básicos de construção de
um ativo digital são importantes para conseguir definir sua estratégia e o
roadmap do produto.

• Cliente Servidor: de forma mais simples, é um sistema instalado em

um servidor no qual os usuários consomem a partir do sistema
instalado nas estações clientes.

Figura 3 – Cliente Servidor

Fonte: Ctrlzeta

• Servidor: local onde instalamos nossas aplicações, pode ser físico,

virtualizado ou até mesmo container.

12
• Serviço: um cliente faz a solicitação, e o serviço responde. Pode
chamar outros serviços internos ou externos, toda lógica de negócio
está nele e foi escrito em alguma linguagem de programação. O mais
comum é que utilizem protocolo de comunicação HTTP.

Figura 4 – Serviços

Fonte: softwell

• DNS: como se fosse nossa agenda telefônica. Em vez de todos

saberem o número de telefone de todos, é registrado um nome
atrelado a este endereço. Os servidores DNS (Domain Name System)
traduzem os endereços dos sites que digitamos nos navegadores
para endereços IP.

• Database: onde os serviços guardam as informações que recebem e

processam, preocupação grande com proteção e backup. Um banco
de dados é uma coleção organizada de informações ou dados
habitualmente estruturados.

• API: padroniza como todos interagem com o serviço, é um conjunto

de rotinas que um serviço deve oferecer. Utilizam mais comumente
JSON ou XML para definição das regras.

13
 Figura 5 – JSON x XML

Fonte: Canal TI

• Rest: são boas práticas para utilizar solicitações web realizadas por
uma API, similar à utilização de um padrão.

• Deploy: quando o desenvolvimento de uma feature é concluído, ele

é integrado ao código principal ou branch máster e aplicado aos
servidores de produção. Esse deploy pode ser manual ou idealmente
automatizado. Se for alguma atualização em um APP, depende de
validação das lojas (Apple e Google) para que possa ser utilizado.

• DEVOPS: em um time devops, os próprios desenvolvedores fazem

deploy, mensuram problemas e performance, bem como cuidam da
gestão dos servidores. São práticas para integração de times de
desenvolvimento e operação.

• Legado: uma missão sempre complexa é integrar os novos ativos

digitais aos sistemas mais antigos da empresa, por isso esta
expressão “sistemas legados” faz parte do dia a dia de um PM.
Legado podem ser sistemas inteiros ou apenas parte do código de
um ativo.

14
• Microsserviço: um microsserviço é uma pequena porção de software
que roda de maneira independente, focada em um único e pequeno
conjunto de atividades dentro de um conjunto de serviços muito
maior, formando uma arquitetura de microsserviços.

• Débito Técnico: se você não for um PM oriundo da área de tecnologia,

sofrerá ainda mais com essa expressão. Um estudo feito pela
OutSystems relata que 69% dos líderes de TI identificam o débito
técnico como uma grande ameaça da capacidade das empresas em
inovar. De forma mais simplista, podemos pegar um exemplo
daquela feature que precisa ser lançada em 15 dias, mas o time sabe
que, para fazer de acordo com todas as boas práticas, eram
necessários 30 dias. Nesse sentido, normalmente são realizadas
soluções alternativas para cumprir a data, gerando débito técnico
que, em algum momento, deverá ser revisitado e reconstruído parcial
ou totalmente.

Figura 6 – Débito Técnico

Fonte: Até o momento

15
 • Infraestrutura:

– MainFrame: são computadores de grande porte que,

normalmente, suportam um volume muito grande de
transações. São frequentemente utilizados para suportar
sistemas legados.

– Máquina Virtuais: são ambientes de software que simulam

umahardware. Para que funcione, é preciso que um conjunto
de sistemas esteja instalado em uma máquina física.

– Container: a tecnologia de container é uma metodologia

utilizada para empacotar aplicações para que possam ser
executadas/disponibilizadas com o seu subset de
dependências de maneira isolada e eficiente, com intuito de
segregar e facilitar a portabilidade dessas aplicações

Toda essa “sopa de letrinhas” de TI não só deve ser dominada pelo

time técnico, mas também compreendida pelo PM.

1.5 Liderança
Existe ainda um debate sobre o papel do PM em relação a ser ou não
uma liderança formal. Em algumas empresas, todo time reporta para o PM e,
em outras organizações, somente os times de negócio. Existe também a
situação de que somente POs são reports do PM, e, em outros casos, o PM é
considerado uma função, e não um cargo, ou seja, não há report formal.
Todavia, não nos restam dúvidas de que o PM precisa ser um líder para o
time, bem como tem a missão de inspirar e conduzir os squads que
compõem o produto.

No conceito de Golden Circle do autor Simon Sinek, evidencia-se a

importância da motivação no que se refere a inspirar e a atrair seguidores.
Sinek descobriu que todos os líderes inspiradores pensam, comunicam e
agem da mesma forma. Observando isso, desenvolveu o “O Círculo Dourado”,

16
que aponta três simples níveis: Why, How e What. Destaca-se a relevância
do time em entender o porquê, pois é isso que trará a motivação para cada
membro. O PM deve ter a capacidade de inspirar as pessoas com uma visão
convincente de futuro, garantindo-lhes uma direção clara em que todos
possam trabalhar com o mesmo propósito.

Somado a isso, é missão do PM entender o relacionamento e o

momento de cada stakeholder, sendo estas pessoas do seu time, de áreas
parceiras ou até mesmo externos a sua organização. De acordo com PMBOK,
existem diversos tipos de interesse dos stakeholders, alguns deles que se
destacam para um gerente de produto são:

• Desinformado: sem conhecimento do produto e dos impactos

potenciais;

• Resistente: resiste às mudanças e conhece os impactos do produto;

• Neutro: sabe do produto e não dá apoio, no entanto não gera

resistência;

• Apoio: ciente do produto e dos impactos potenciais e dá apoio às

mudanças;

• Liderança: ativo e engajado. Age direcionando todas as ações para

que o produto alcance seu objetivo.

Após identificar, analisar e classificar os stakeholders, o gerente de

produto deve desenvolver um plano para gerenciá-los. Este plano pode
conter:

• Níveis de engajamento atual e desejado;

• Inter-relação entre os stakeholders;

• Qual é a forma de preferência de comunicação;

17
 • Estratégia de gerenciamento para cada stakeholder;

• Método/Periodicidade de atualização deste plano.

Algumas dicas para tornar a vida do PM mais fácil passam por fazer uma boa
gestão dos stakeholder. O engajamento envolve diálogos de interesse mútuo nos quais
as pessoas buscam compreensão e solução dos problemas. Os Stakeholders chaves
devem ser convidados para participar ativamente das cerimônias de gestão de
produto, e não simplesmente comparecer. O PM deve se reunir e alinhar com os
stakeholders antes das principais reuniões e, dependendo da cultura da empresa, estes
alinhamentos prévios são mandatórios. O Gerente de produto precisa exercer
liderança além do seu próprio time e, ao fazer a gestão das áreas pares, torna-
se a melhor ferramenta que ele possui para proteger a produtividade das
suas squads.

Um bom PM exerce, durante todo ciclo de vida de seu produto,

diversos tipos de liderança, dado que o líder se adapta diante de certas
situações, avalia a maturidade do liderado e o contexto. Não existe um estilo
de liderança único para todas as situações, mas há ocasiões e estilos
diferentes de gestores. Abaixo, estão listados alguns estilos de liderança:

• Diretiva ou Autoritária: os times recebem ordens detalhadas e

conhecem com precisão o que precisa ser feito;

• Apoio: existe uma preocupação genuína do líder em garantir

proximidade da equipe;

• Participativa/Consultiva: existe um ambiente de troca entre o líder

e o time, mas é o líder quem toma as decisões finais;

• Orientada a Entregas: o líder estabelece os objetivos, e os liderados

são estimulados a alcançá-los por meio de suas capacidades.

18
 Figura 7 – Líder x Chefe

Ser chefe só está na moda para a atribuição de cargos executivos

(CIO, CTO, CEO etc.), porque este estilo de liderança não se pratica há muito
tempo. No mundo colaborativo em que vivemos, esse tipo de gestão não tem
mais espaço, todavia isso não significa que, para determinadas pessoas e
momentos, não seja necessário um estilo mais diretivo, visto que tudo é uma
questão de contexto no qual o PM precisa planejar, adequar e revisitar.

19
2
Capítulo 2. Gerenciamento de portfólio
O Project Management Institute (PMI) possui uma boa definição
sobre o que é gerenciamento de projetos:

O gerenciamento de portfólios tem o intuito gerenciar os

vários projetos de uma empresa de forma integrada. Todo e
qualquer tipo de empresa atuante no mercado precisa,
constantemente, elaborar estratégias e planos de ação
eficientes, que gerem resultados positivos aos negócios de
uma forma geral. A gestão de portfólio tem o objetivo de
encontrar a melhor combinação possível de recursos para
ajudar uma organização a atingir suas metas com a execução
de seus projetos (PMI, 2017, online).

2.1 Diferença entre projeto, programa e portfólio

“O projeto é um esforço temporário empreendido para criar um
produto, serviço ou resultado único. Portfólio é um conjunto de projetos,
programas, subportfólios e operações, gerenciados em grupo, para alcançar
objetivos estratégicos” (PMI, 2017, p. 4).

Essa relação fica clara a partir de um planejamento estratégico,

desdobrado em diversas iniciativas estratégicas, que deverão ser
implementadas através de inúmeros, programas e projetos, gerando
resultados.

21
 Figura 8 – Programas, projetos e portfólio

Fonte: Inspirado no PMBOK

Os projetos podem criar um ou mais produtos, em algumas

organizações os projetos estão sendo substituídos pela criação de produtos.
Lembrando que, de acordo com o PMBOK, um projeto é um esforço
temporário empreendido para criar um produto, serviço ou resultado único,
enquanto um produto:

É qualquer coisa que possa ser oferecida a um mercado para

atenção, aquisição, uso ou consumo e que possa satisfazer a
um desejo ou necessidade. Em administração e marketing, é
um conjunto de atributos, tangíveis ou intangíveis,
constituído através do processo de produção para o
atendimento de necessidades reais ou simbólicas, e que pode
ser negociado no mercado, mediante um determinado valor de
troca, quando, então, converte-se em mercadoria, portanto
não tem um fim pré-determinado (ARMSTRONG; KOTLER,
2000, p. 200).

2.2 Estruturas de uma organização

As empresas são organizadas de diversas formas e isso pode
impactar totalmente na gestão de produtos, pois, dependendo de como a
estrutura organizacional está formada, o PM tem mais ou menos poder sobre
a gestão do produto.

Segundo o PMBOK, existem alguns tipos de estruturas:

22
• Funcional

– Funcionários têm um superior único, definido e reconhecido

na empresa;

– Os membros da equipe são agrupados por especialidade

(produção, marketing, engenharia etc.) e não trabalham no
mesmo andar/setor/local físico;

– O fluxo de comunicação segue uma estrutura rígida e

definida;

– As áreas trabalham por conta própria em seus projetos.

• Matriz: Fraca, Balanceada e Forte

• Projetizada

– A grande maioria dos recursos da organização são alocados

em projetos/produtos;

– Os membros das equipes frequentemente trabalham juntos,

num mesmo local físico;

– Os gerentes do projeto ou gerente de produto têm grande

autoridade e independência;

– As áreas se reportam diretamente ao gerente de projeto ou

gerente do produto.

23
 Figura 9 – Estrutura Organizacional

Fonte: PMBOK

2.3 Cadeias de valor

A cadeia de valor é um método que permite à empresa organizar
todos os seus processos, observando os elos e como cada um deles pode
gerar valor ao cliente. O conceito pode ser apresentado em um fluxograma
das etapas essenciais para agregar valor ao produto de uma empresa.

Um grande desafio das empresas é fazer o correto mapeamento de

suas cadeias de valor e demostrar o fluxo de um fornecedor ao consumidor
através de toda organização. Por exemplo, o valor que uma empresa de
software entrega a seus consumidores são as soluções de software e todos
os recursos contidos nela, no entanto existem diversos fluxos de valor
contidos dentro de uma cadeia. Pensando num comércio eletrônico ou e-
commerce, temos de forma muito simplificada o catálogo de produtos,
pagamento, logística de entrega, todos são fluxos, porém o que gera valor
de fato ao consumidor é receber seu pedido em casa.

Entender as cadeias de valor poderá acelerar muito o processo de

digitalização das empresas e consequentemente a construção de produtos
para cada cadeia existente, facilitando o desenho da estratégia de cada PM,
isto é, alinhando a estratégia corporativa.

24
 Existem diversos exemplos de cadeias de valor que são públicas, um
deles é o mapeamento que a secretaria do estado de Goiás fez sobre os seus
serviços, conectando a missão e a visão para impactar a sociedade.

Figura 10 – Cadeias de Valor

Fonte: Secretaria do Estado de Administração

Neste exemplo da Secretaria de Goiás, podemos ver o quanto

possuir o mapeamento das cadeias facilita na criação da estratégia de cada
produto, no caso da cadeia de gerir serviços para sociedade, todo e qualquer
produto que gere este valor ficará sob gestão do responsável por esta cadeia,
estabelecendo limites entre as fronteiras, facilitando a gestão de
indicadores e a criação de produtos.

Existe um esforço grande das organizações que querem acelerar sua

transformação digital para estarem organizadas em cadeias de valor. Esse
movimento irá abrir cada vez mais espaço para o gerente de produto,
portanto passa a ser necessário a habilidade do PM em entender como
mapear essas cadeias.

25
3
Capítulo 3. Ágil Escalado
A cultura ágil auxilia os profissionais a serem capazes de executar
rotinas de forma a eliminar entregas de longos prazos e alto risco,
substituindo-as por entregas menores e incrementais capazes de mitigar
riscos e permitir o aprendizado e a correção de rota durante o percurso. Nos
dias de hoje, a velocidade em que as mudanças ocorrem nem nos
surpreendem mais, pois já sabemos que a mudança é certa, e que o
consumidor irá alterar o que prefere. Por isso, a agilidade corporativa torna-
se uma ferramenta importante para que toda organização tenha a habilidade
de se mover rapidamente.

3.1 Era digital

Estamos atravessando a Era Digital, conhecida também como Era da
Informação, que é momento em que tecnologia e informação passaram a ser
essenciais para todas as pessoas. A Era Digital é a sequência da Era
Industrial e se iniciou logo após a Primeira Revolução Industrial, no final do
século 20.

Todas as empresas do futuro serão de software. Hoje, em

montadoras de carro de alto padrão, como BMW, mais da metade do trabalho
é direcionada ao desenvolvimento de software.

Para sobreviver a essa era, alguns frameworks de trabalho, como o

SAFe, estabeleceram foco em 7 competências de uma empresa ágil.

27
 Figura 11 – Competência Organização Ágil

Fonte: Framework SAFe

Cada competência é um conjunto de conhecimentos, habilidades e

comportamentos relacionados, que juntos permitem que as empresas
estejam mais preparadas para Era Digital. Abaixo, estão elencadas cada uma
delas:

• Entrega de Soluções Empresariais: esta competência destaca como

aplicar os princípios e as práticas Lean-Agile, desde a especificação
passando por desenvolvimento, implantação até a operação e a
evolução de sistemas complexos.

• Entrega de Produto Ágil: uma abordagem centrada no cliente para

definir, criar e liberar produtos e serviços que gerem valor. Isso
permite que a organização forneça soluções que encantem os
clientes e reduzam os custos de desenvolvimento.

28
 • Time e Agilidade Técnica: destaca os princípios e as práticas Lean-
Agile utilizados pelos times de alto desempenho na criação de
soluções de alta qualidade para seus clientes.

• Liderança Lean-Ágil: descreve como os líderes Lean-Agile

conduzem e sustentam a mudança organizacional, capacitando
indivíduos e equipes a atingir seu maior potencial. Isso é feito por
meio da liderança pelo exemplo, adotando uma mentalidade Lean-
Agile e trazendo uma nova forma de trabalhar

• Cultura de Aprendizagem Contínua: esta competência destaca

uma organização que aprende além de um conjunto de valores e
práticas que incentivam os indivíduos e a empresa como um todo a
aumentar continuamente o conhecimento, a competência, o
desempenho e a inovação.

• Agilidade Organizacional: descreve como pessoas com o

pensamento Lean e as equipes Ágeis otimizam seus processos de
negócios, desenvolvem estratégias com novos compromissos claros
e decisivos e os adaptam rapidamente a organização.

• Gerenciamento do Portfólio Lean: descreve a importância do

alinhamento da estratégia e da execução aplicando abordagens do
pensamento Lean e sistêmico. Esse alinhamento acelera o
desenvolvimento e o senso de propósito dos times.

3.2 Estabelecer o time

O PM tem a missão de montar seu time e, para isso, exige-se, muitas
vezes, grande habilidade de negociação para conseguir os melhores
recursos disponíveis para construção do produto, e as pessoas chegam ao
time de algumas maneiras:

29
 • Pré-designação: em alguns casos, existe a predefinição a respeito
dos recursos que serão utilizados naquele produto.

• Contratação: caso a organização executora não disponha de todos

os recursos humanos necessários para criação ou evolução do
produto e/ou faça a opção de terceirizar uma parte, será necessário
recorrer à contratação de mão de obra externa.

• Equipes virtuais: a disponibilidade de comunicação eletrônica, como

e-mail, chat ou aplicativos de conversar além de videoconferência,
viabilizou a existência dessas equipes, especialmente o período de
distanciamento social fez com que este tipo de time se formasse.

Outra atividade importante do PM refere-se ao desenvolvimento do

seu time, isso inclui treinamentos ou qualquer atividade planejada para
aumentar as competências da equipe. É muito importante lembrar que o
investimento nessas atividades faz parte do custo do produto, por isso
devem ser orçadas com os reconhecimentos e a promoção dos integrantes
do time. Somado a isso, vale ressaltar que o benefício deste produto deverá
sustentar estes custos.

Por fim, para a montagem do time é importante lembrar dos

aspectos que envolvem diversidade, pluralidade de ideias, múltiplas
habilidades e áreas de conhecimento. Embora os squads sejam
caracterizados por reunir profissionais de diversas áreas, a formação de
departamentos não é o foco. Convém destacar que, nessa estrutura, não
existe líder, e os envolvidos têm autonomia para se organizar. Além disso,
esse modelo não prevê a divisão de tarefas, nem mesmo entregas
individuais.

30
3.3 Construção de soluções em times ágeis
Um time ágil constrói soluções baseadas principalmente numa dor
de seu cliente. Dessa forma, deve-se entender as razões pelo qual alguém
pagaria por um produto que resolveria algum problema.

Para construção de times ágeis escalados, devemos levar em

consideração 3 tópicos:

1. Times Ágeis: são times formados para gerar valor a cada duas
semanas. Em algumas situações, podemos ter sprints maiores desde
que não ultrapassem 4 semanas. São compostos por squads de 5 a
11 pessoas de rodam com SCRUM ou KANBAN, que definem e
testam suas estórias e papéis importantes, tais como scrum máster
e product owner − são efetivos dentro de uma estrutura como essa.

2. Construção com qualidade: não é possível escalar código ruim,

defina os critérios de qualidade, automação de testes, programação
em pares, Test Driven Development (TDD), definição de Work In
Progress (WIP) do time.

3. Organizar os times em cadeias de valor: são compostos por 5 a 12

times, totalizando aproximadamente 50 a 125 pessoas, segundo
SAFe. Esses times são sincronizados a partir de cerimônias de
planejamento e contam com papéis, como Release Tem Manager
(RTM), para organizar os SMs, os Arquitetos, os Business Owner,
System Team, que organiza os processos do time de TI, e o PM, que
garante a sincronia e a priorização de todo backlog. Somado a isso,
todas as áreas que precisam ser envolvidas, tais como jurídica,
infraestrutura, segurança, são membros do time e devem ser
consideradas no orçamento do produto.

Nem todas as situações em uma organização podem ser resolvidas

com uma estrutura ágil composta por PM, PO, SM etc. Nesse sentido,

31
segundo John P. Kotter, para esses casos, a solução não consiste em jogar
no lixo o que sabemos e começar de novo, mas, em vez disso, reintroduzir
um segundo sistema − aquele que seria familiar para a maioria
empreendedores de sucesso, isto é, precisamos ter cautela, dado que nem
todas as situações de um ambiente empresarial exigem a formação de times
em formato de gestão de produto, pois isso depende de um contexto,
envolvendo o que precisa ser resolvido, bem como a cultura da empresa e a
capacidade do time em trabalhar neste formato.

3.4 PI Planning
A Program Increment (PI) Planning é um evento baseado em
cadência que serve como o coração do (ART), que é um acrônimo para Agile
Release Train. ART é um time de times ágeis responsável por entregar e
integrar os incrementos de programa de maneira cadenciada e sincronizada
entre os times que o compõem. O momento para alinhar todas as equipes
do ART, com uma missão e visão compartilhadas, ocorre durante a PI.

A PI Planning é um evento de dois dias e acontece a cada 8 a 12

semanas, para que todos planejem juntos. O gerente de produto é o dono
das features, e o RTE é o organizador da cerimônia. Nesse encontro, faz-se
necessário possuir uma visão do que se espera em relação ao produto junto
às principais features, e, ao final do encontro, é preciso que os times estejam
formados, organizados com os objetivos e cientes das interdependências.
Ademais, nesse encontro, também são definidos os Uncommited Objectives
ou objetivos não compromissados − correspondem a situações com grande
grau de incerteza e que eventualmente podem ser movidas, mas é
importante destacar que são consideradas dentro do capacity.

Abaixo, temos a lista dos principais tópicos de uma PI Planning:

• Cada time deve informar a sua capacidade;

32
 • Com as features e estórias já definidas, cada time informa suas
interações;

• Cada time destaca seus PI Objectives e os Riscos, assim como

objetivos não compromissados;

• Os SMs se reúnem a qualquer tempo, no entanto existe uma

cerimônia específica para o alinhamento entre eles;

• No final do primeiro dia da gestão, reúnem-se para avaliação

(negócio, visão, mudanças, alinhamento de times);

• O Business Owner (BO) indica uma nota de 0-10 para cada PI

objetive;

• O Program Board será construído. Trata-se de um resumo visual dos

recursos ou objetivos, prazos e quaisquer dependências entre
equipes, e deve ser entregue pelo Agile Release Train. Ele é
arquitetado na sessão de PI, que toda a ART planeja, com o objetivo
de estimar e priorizar recursos;

• Cada grupo apresenta como suas interações ficarão;

• O Plano final é revisto e recebe ou não o aceite do BO;

• São apresentados todos os riscos, e os donos precisam ser

indicados;

• Existe a sensação do Confidence Vote, em que todo time vota de 1 a

5 para falar o quanto se sente confiante com plano (não pode ter 1-
2). Enquanto isso ocorre, o plano precisa ser revisto ou esclarecido
para quem votou de 1 a 2.

Por fim, é realizada uma pequena retrospectiva destacando o que

cada integrante identificou (Gostou, Aprendeu, Sentiu Falta e Esperava por).

33
4
Capítulo 4. Lean Agile
O Lean Agile é uma junção da filosofia Lean com a metodologia Agile.
Nesse contexto, o Lean nasceu no século passado, no Japão das fábricas da
Toyota, enquanto o Agile emerge do manifesto ágil, publicado no início deste
século. À vista disso, o Lean Agile mistura elementos dessas duas bases,
gerando valor para quem compreende e aplica seus conceitos.

4.1 Principais Valores

De acordo com a SAFe, existem 4 valores principais para uma
liderança Lean-Agile:

1. Alinhamento:

a. Comunique a missão, a visão e a estratégia;

b. Forneça briefings e participe do planejamento de PI;

c. Participe da revisão e da preparação do backlog;

d. Organize em torno de fluxos de valor.

2. Transparência:

a. Visualize todos os trabalhos relevantes;

b. Assuma a propriedade e a responsabilidade por erros;

c. Admita seus próprios erros;

d. Apoie outras pessoas que reconhecem e aprendem com

seus erros.

3. Construção com qualidade:

35
 a. Recuse-se a aceitar trabalho de baixa qualidade;

b. Apoie os investimentos na redução da dívida técnica;

c. Garanta UX, arquitetura, operações e segurança;

d. A conformidade com as leis e regras da empresa fazem

parte do fluxo de trabalho.

4. Execução do programa:

a. Participe como um dono;

b. Comemore a alta qualidade e a previsibilidade da

entrega;

c. Tenha dedicação para a remoção dos impedimentos.

4.2 Pensamento Lean

No pensamento Lean, preserva-se a busca contínua pela entrega de
valor ao cliente no menor tempo possível. O Lean Thinking ou “o
pensamento enxuto” é uma filosofia que deve ser incorporada à cultura
organizacional da empresa, o que implica criar processos para identificar
constantemente as oportunidades, com a intenção de “enxugar” os
desperdícios.

Nesse sentido, é uma filosofia destinada às estratégias

empresariais, cujo foco está no fluxo do valor para o cliente, possuindo
grande empenho em aumentar a eficiência operacional, de forma a
despender o mínimo de recurso possível. A mentalidade de pensamento
Lean está incorporada ao SAFe House of Lean, conforme a imagem abaixo:

36
 Figura 12 – House of Lean

Fonte: Framework SAFe

• Valor: gerar valor de forma sustentável no menor tempo possível

– Gerar valor e qualidade para todos;

– Satisfação do cliente, segurança e alta moral do time.

• Respeito pelas pessoas e pela cultura

– Cultura de aprendizado;

– São as pessoas que fazem todo o trabalho;

– Seu cliente é qualquer um que consome seu trabalho;

– Construir relacionamentos de confiança e parceria de longo

prazo;

– Para mudar a cultura, você tem que mudar a organização.

• Fluxo

– Otimizar valor de forma sustentável;

37
 – Construir com qualidade;

– Compreender, explorar e gerenciar as opções;

– Mudar de projetos para produtos.

• Evolução contínua

– Viver em sinal de alerta;

– Otimizar o todo, e não somente silos;

– Cultura de solução de problemas;

– Avaliação dos principais marcos, baseando-se em dados e

fatos.

• Liderança

– Lidere pelo exemplo;

– Adote uma mentalidade de crescimento;

– Desenvolver pessoas;

– Lidere a mudança;

– Promover a segurança psicológica do time.

4.3 Manifesto Ágil

O manifesto para Desenvolvimento Ágil de Software, disponível em
diversos idiomas no site https://agilemanifesto.org, foca em conceitos
extremamente simples de se entender, mas que são muito complexos para
se aplicar. Abaixo, destacado na integra:

Estamos descobrindo maneiras melhores de desenvolver

software, fazendo-o nós mesmos e ajudando outros a fazerem
o mesmo. Através deste trabalho, passamos a valorizar:

38
 Indivíduos e interações mais que processos e ferramentas,
Software em funcionamento mais que documentação
abrangente, Colaboração com o cliente mais que negociação
de contratos, responder a mudanças mais que seguir um
plano, ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda (BEEDLE, Mike. et al,
2021, online).

4.4 Princípios Lean-Agile

Os 12 princípios do Manifesto Ágil são comum e amplamente
divulgados. Com estes princípios, constata-se que o objetivo do Manifesto
Ágil é servir como um guia para times ágeis, visando a potencializar seus
resultados. A seguir, estão listados todos os princípios do Manifesto Ágil:

1. Satisfação do cliente;

2. Mudança a favor da vantagem competitiva;

3. Prazos curtos;

4. Trabalho em conjunto;

5. Ambientação e suporte;

6. Falar cara a cara (hoje em dia, entende-se que uma videoconferência

é o novo cara a cara);

7. Funcionalidade;

8. Ambiente de sustentabilidade;

9. Padrões altos de tecnologia e design;

10. Simplicidade;

11. Autonomia;

12. Reflexões para otimizações.

No entanto, o desafio de construção de softwares cada vez mais

complexos e em escala levou o SAFe a construir dez princípios Lean-Agile,

39
que são imutáveis. Esses princípios e conceitos econômicos inspiram e
informam os papéis e as práticas da SAFe.

Figura 13 – Princípios Lean-Agile

Fonte: Framework SAFe

1. Tenha uma visão econômica;

2. Aplique o pensamento sistêmico;

3. Assuma a Variabilidade e preserve as opções;

4. Construa de forma incremental, com ciclos de aprendizagem rápidos

e integrados;

5. Baseie os marcos na avaliação objetiva dos sistemas de trabalho;

6. Visualize o limite do WIP, reduza os tamanhos dos lotes e gerencie

o tamanho das filas;

7. Aplique cadência e sincronize com planejamento de todos;

8. Destrave as motivações intrínsecas de conhecimento do time;

9. Descentralize a tomada de decisão;

10. Organize-se em cadeias de valor.

40
5
Capítulo 5. Integração
Um processo de integração realizado da forma certa gera benefícios
para a empresa como um todo em diversos aspectos, por isso é importante
termos a visão do todo. Isso garante que as partes envolvidas sejam ouvidas
e, caso seja possível, levem em consideração para criação ou evolução do
produto.

Existem, portanto, cerimônias e um conjunto mínimo de

formalização que facilitam o processo de integração, como já vimos nos
capítulos anteriores, caracterizando uma das principias tarefas do PM.

5.1 PO Sync e Scrum of scrums

A Product Owner Sync ou PO Sync “é uma reunião similar a SoS, com
o propósito de prover visibilidade do ART (Agile Release Train) em relação
aos objetivos do PI. É uma ótima oportunidade de avaliar ajustes de escopo
e elencar problemas no desenvolvimento de features” (SCALED AGILE,
2021, online). Abaixo, estão elencadas algumas de suas principais
características:

• Visibilidade do progresso, ajustes de escopo e prioridades;

• Facilitado pelo RTE ou PM;

• Participantes: PM, POs e SMEs caso seja necessário;

• Ocorre semanalmente ou com mais frequência, caso seja necessário,

com duração de 30 a 60 minutos

O Scrum of Scrums ou SoS tem o objetivo de coordenar equipes

menores e independentes. As equipes que aplicam o Scrum de Scrums não
só coordenam a entrega, mas também garantem um produto totalmente

42
integrado no final de cada sprint. A seguir, estão elencadas algumas de suas
principais características:

• Visibilidade do progresso e impedimentos;

• Facilitado pela RTE;

• Participantes: Scrum Masters, membros da equipe e SMEs caso seja

necessário;

• Ocorre semanalmente ou com mais frequência, caso seja necessário,

com duração de 30 a 60 minutos.

5.2 Direção e gestão (o que é necessário formalizar)

Atualmente, temos a certeza de que as coisas irão mudar, sabemos
que as formalizações em excesso não resolvem problemas e muitas vezes
só servem para identificar os culpados. Porém, todo extremo é perigoso, e
nenhuma formalização pode causar problemas de alinhamentos, de forma
especial, quando buscamos investimentos, sejam nos comitês executivos,
sejam nas fontes externas, como investimentos.

Nesse sentido, é importante para o PM ter o registro de pontos de

decisão, pois estes são essenciais para garantir o sucesso ou a
sustentabilidade do seu produto, além de garantias de investimentos
capazes de proteger o time, para que continue trabalhando de forma
produtiva e sem a perda de aprendizados que o trabalho em equipe
proporciona.

Abaixo, estão elencados alguns exemplos de formalizações

importantes que o PM precisa se preocupar:

• Verba para o seu produto, quais são os desembolsos previstos, sejam

investimentos ou despesas, e durante quanto tempo ela estará
disponível;

43
 • Retorno previsto, quem lhe financiou espera um retorno, seja
financeiro, seja benefício para o negócio;

• Premissas e riscos, na gestão tradicional de projetos, toda premissa

é um forte candidato a virar um risco, isso porque naturalmente
premissas são hipóteses que consideramos como verdade.

• Time do produto, eventualmente dentro das organizações são

alocados recursos part-time, um acordo bem-feito é necessário para
não perder conhecimento importante durante a jornada de criação
ou evolução do produto;

• Acompanhamentos do produto, sejam estes resultados do produto

− como quantidade de vendas, views, cliques etc. − ou resultado
financeiro;

• Propósito e visão do produto;

• Contratos com parceiros e fornecedores;

• Indicadores de performance que geram bonificação.

Esses são exemplos de formalizações importantes que o PM precisa

garantir. Os registros podem ocorrer desde a concepção até o fim do produto
e protegem o time de alinhamentos dúbios que podem gerar o fracasso do
produto.

44
6
Capítulo 6. Ferramentas de Discovery
O Discovery é uma etapa crítica no processo de design do produto,
pois, nesta fase, realiza-se todo o planejamento de forma direcionada, isto
é, da maneira certa para o público certo, reduzindo, assim, a incerteza em
torno da solução que será criada.

O product discovery é um conjunto de atividades que executamos

com a intenção de nos auxiliar a responder melhor às perguntas de onde,
quando e se devemos evoluir nosso produto. Para isso, existem diversas
ferramentas e técnicas, e, neste capítulo, separamos algumas das principais.

6.1 Pesquisa, Entrevista, Observação, Benchmarking

Um bom mindset para utilizar as ferramentas de Discovery depende
de que elas sejam capazes de destruir uma ideia, ou seja, se o PM e o time
acreditam em uma hipótese de solução, é preciso que façam uso dessas
ferramentas com o objetivo de tentar quebrar esta hipótese e, caso isto não
aconteça, pode-se pensar que a hipótese esteja no caminho certo. Então,
vamos aos exemplos:

• Pesquisa é um conjunto de ações que visam à descoberta de novos

conhecimentos em uma determinada área. Uma parte importante de
qualquer pesquisa é o recolhimento de dados, por isso a pesquisa
deve ser feita de forma imparcial, ou seja, sem viés. Habitualmente
recebemos pesquisas através de google forms ou outras.

• Entrevista é um diálogo entre duas ou mais pessoas em que o

principal objetivo é extrair declarações e informações, neste caso,
sobre a hipótese do produto.

• Observação é uma técnica que utilizamos frequentemente em nosso

dia a dia, neste caso, quando estamos na etapa de Discovery,

46
 podemos observar como o cliente ou possível cliente utiliza o
produto, e, caso ele ainda não exista, notamos como as pessoas
resolvem o problema que estamos dispostos a solucionar com nosso
produto.

• Benchmarking compara práticas e métricas de negócios com

concorrentes, empresas similares ou até mesmo áreas pares, a fim
de avaliar se os resultados que estão sendo obtidos estão melhores
em contextos equiparáveis.

6.2 Matriz CSD, Personas, Mapa de Empatia

Ainda existem outras ferramentas mais específicas da etapa de
Discovery que também podem ser utilizadas para definir o seu público,
entender o que gera valor e o que já sabemos sobre nosso produto ou
público:

• A Matriz CSD é um método utilizado para iniciar projetos. Sua sigla

significa Certezas, Suposições e Dúvidas. Seu objetivo é justamente
reunir todas as certezas, suposições e dúvidas entre os membros da
equipe para que todos estejam cientes das informações disponíveis

Figura 14 – Matriz CSD

Fonte: UX Collective

47
• Persona é um personagem fictício que representa o cliente ideal de
um negócio. Baseia-se em características de clientes reais,
destacando seus comportamentos, problemas, dados demográficos,
objetivos e desafios.

Figura 15 – Persona

Fonte: Alura

• O mapa de empatia é uma ferramenta capaz de permitir aos

Gerentes de Produto enxergarem os clientes com mais detalhes,
compreendendo o que eles sentem, quais suas necessidades,
desejos e problemas mais íntimos.

48
 Figura 16 – Mapa de empatia

Fonte: Blog FCamara

6.3 Design Thinking

Segundo Tim Brown CEO da IDEO, o Design Thinking (DT) é uma
abordagem inovadora que se baseia em processos de design com o objetivo
de integrar as necessidades das pessoas, as possibilidades da tecnologia e
os principais requisitos para o sucesso empresarial. Em outras palavras, o DT
nos dá o processo que precisamos com o intuito de ajudar a desenhar
soluções para as pessoas.

O DT nos ajuda a fazer conexão entre tecnologia ou o que seja

tecnicamente viável, entre pessoas ou o que elas desejam, e entre negócio
ou o que é financeiramente viável. Pode ser aplicado em qualquer área, uma
vez que é uma abordagem que se utiliza em equipe, encoraja o pensamento
inovador, garante que o resultado e atenda à necessidade do usuário.

O DT tem como principais valores: ser centrado no usuário, ser

interativo, ter foco na experimentação e abranger a colaboração que gera a

49
criatividade. Portanto, não é recomendável utilizar o design nas seguintes
situações:

• Otimizar e não inovar;

• Quando as pessoas são vistas apenas como recursos;

• Quando não se promove colaboração interna;

• Quando se espera que as pessoas se adaptem à tecnologia, e não ao

contrário;

• Quando já tem um resultado esperado.

Nesse contexto, o DT é menos sobre pensar e mais sobre fazer, dessa

forma, o fracasso é uma parte necessária ao processo, pois ele é
particularmente útil para resolver problemas complexos e, atualmente,
existem diversos modelos de design thinking, o mais comum é o da Stanford
School, envolvendo 5 etapas: Empatia, Definição, Ideação, Prototipação e
testes (é a abordagem conhecida como duplo diamante).

Figura 17 – Duplo Diamante

Fonte: Medium

O Duplo Diamante é um diagrama formado por quatro triângulos

conectados para retratar as fases do processo para levar à inovação. Ele
demonstra como as convergências e divergências de pensamento
acontecem no caminho da solução.

50
7
Capítulo 7. Engenharia de Valor
A engenharia de valor tem a ver com um estudo realizado para
prevenir ou diminuir custos antes da criação ou evolução do produto. São
métricas aplicadas ainda na etapa de concepção de um produto para apoiar
na decisão do que fazer primeiro, que irá ativar valor ao cliente, com menor
esforço possível.

7.1 Matriz SWOT

A Análise SWOT é uma ferramenta de gestão que engloba a análise
de cenários para tomada de decisões. Em português, é conhecida como
FOFA, um acrônimo para forças, oportunidades, fraquezas e ameaças. São
essas as características que são avaliadas na matriz.

Essa matriz é amplamente utilizada pelas empresas durante o

planejamento estratégico e para novos projetos. Além disso, ela também
pode ser usada pelo PM, com o objetivo de entender o posicionamento do
seu produto no ambiente interno e externo.

Figura 18 – Matriz SWOT

Fonte: Portal Gestão

52
 Já é conhecido que o orçamento do produto funciona muito melhor
quando está alinhado ao Planejamento Estratégico da organização. Nesse
contexto, a análise SWOT pode ajudar muito, e é fundamental que a
companhia “se conheça” muito bem, de forma a compreender exatamente
quais são suas principais forças e fraquezas, bem como o contexto em que
está sendo posicionada, identificando as oportunidades e as ameaças do
cenário em que se encontra inserida, para garantir o alinhamento do seu
produto com a estratégia corporativa e o momento do mercado.

7.2 Priorização de Backlog

O backlog do seu produto é uma lista de todas as tarefas
relacionadas ao produto que a equipe precisa desenvolver ou concluir para
criação ou evolução do produto, por isso ela deve estar sempre atualizada,
ter alguma definição de importância, o grau de conhecimento e as incertezas
envolvidos.

A priorização do backlog é habitualmente um trabalho do PO, no

entanto, quando existem diversos times trabalhando juntos, passa também
a ser uma responsabilidade do PM. Uma boa forma de conviver nesse
contexto consiste em realizar uma organização de modo que os POs sejam
responsáveis pelas estórias, e os PMs pelas features, assim como um
Business Owner pelo portfólio de produtos.

Existem diversas ferramentas que nos apoiam para realizar a

priorização do backlog, no caso do PM, uma alternativa válida refere-se a
uma ferramenta chamada Weighted Shortest Job First (WSJF) ou em
português trabalho mais curto ponderado primeiro. No SAFe, o WSJF é
estimado como o Cost of Delay (CoD) ou Custo do Atraso dividido pelo
tamanho do trabalho. Os trabalhos que podem entregar o maior valor na
duração mais curta fornecem o melhor retorno econômico.

Para montar a WSJF, outras informações são necessárias, como:

53
 • User Business Value ou Valor para o usuário − Qual é o valor para o
cliente? Nossos usuários preferem isso? Qual é o impacto da receita
em nosso negócio? Existe uma penalidade potencial ou outros
efeitos negativos se atrasarmos?

• Time Criticality ou Criticidade de tempo − Como o valor do usuário /

negócio diminui com o tempo? Existe um prazo fixo? Eles vão
esperar por nós ou mudar para outra solução? Existem marcos no
caminho crítico impactado por isso?

• Risk Reduction and/or Opportunity Enablment (RR/OE Value) ou

Valor da oportunidade ou de redução de riscos − O que mais isso faz
por nossos negócios? Isso reduz o risco desta ou de uma entrega
futura? Existe valor nas informações que receberemos? Esse recurso
possibilitará novas oportunidades de negócios?

As equipes comparam os itens do backlog em relação uns aos outros

usando os mesmos números da sequência de Fibonacci, que é uma
sequência numérica em que cada número seguinte é a soma dos dois
anteriores, iniciando por 0. Assim: 0 – 1 – 1 – 2 – 3 – 5 – 8 – 13 – 21 – 34 –
55 – 89 – 144 e assim por diante.

O próximo item na equação, o denominador no WSJF, é o Job Size

ou a duração do trabalho. Isso também pode ser muito difícil de determinar,
especialmente no início, quando é difícil dizer quem fará o trabalho ou qual
alocação de capacidade pode ser aplicada.

54
 Figura 19 – Exemplo de WSJF

Fonte: Framework SAFe

A escala de Fibonacci também é utilizada para preencher os valores

do WSJF, para todos os campos que devem ser preenchidos, escolha o
menor item para selecionar como 1, toda coluna deve ter ao menos um item
listado como 1. Com todos esses valores em mãos, o PM terá a lista de seu
backlog priorizada olhando por diversas visões, o maior WSJF é o item que
deve ser feito primeiro.

55
8
Capítulo 8. Cultura do Feedback
A cultura do feedback para gestão de produtos nada mais é do que
criar um ambiente aberto ao diálogo com os clientes do seu produto, em que
exista o hábito de coletar os pontos de melhoria e os pontos positivos.

8.1 Métricas de Satisfação

As métricas de satisfação são especialmente úteis para avaliar os
resultados da experiência do cliente em contato com seu negócio ou
produto. Elas ajudam a entender se o produto que está sendo utilizado está
dentro das expectativas de quem está consumindo.

Existem diversas métricas de satisfação disponíveis para entender o

comportamento do seu produto. A seguir, estão elencadas as 5 principais:

1. NPS: O Net Promoter Score é a métrica de satisfação do cliente mais

usada em todo o mundo. O NPS mede a lealdade de um cliente em
relação à sua empresa, com apenas uma pergunta definitiva
elaborada pelo “Fred Reichheld” consultor da Bain & Company: “Em
uma escala de 0 a 10, o quanto você recomendaria a Empresa X para
um amigo ou colega?” Para fazer o cálculo, é necessário subtrair o
percentual de detratores (clientes que deram nota de 0 a 6) do
percentual de promotores (clientes que deram nota 9 e 10).

2. Churn Rate: Para saber o Churn Rate do serviço ou produto, temos

que seguir a seguinte fórmula: quantidade de clientes que
cancelaram dividido pelo total de clientes ativos. Exemplo: se você
perdeu 10 clientes de 100 = 10% de churn rate.

3. Customer Effort Score (CES): O Customer Effort Score mede o

esforço do cliente para alcançar um objetivo na jornada. No caso, a
escala numérica é calculada da seguinte forma: somam-se as notas

57
 e divide-se pela quantidade de pessoas que responderam à
pesquisa. Uma nota maior do que 3,5 (na escala de 1 a 5) aponta um
CES satisfatório

4. Custo de retenção de clientes (CRC): É mais caro conquistar do que

reter clientes. A retenção precisa ser calculada e, para isso, basta
dividir a despesa de retenção pelo número de clientes retidos.

5. Customer Satisfaction Score (CSAT): O CSAT mensura a satisfação

do cliente a partir de uma interação dele com o serviço. Uma
pergunta do tipo “como você avaliaria a sua satisfação com o serviço
XYZ?” ajudam o time a compreender onde estão as possíveis
insatisfações dos clientes e, consequentemente, fazer as correções
necessárias. Para calcular o CSAT, precisamos do número de clientes
satisfeitos que será dividido pelo número total de pessoas que
responderam à pesquisa multiplicado por 100.

As métricas de satisfação precisam fazer parte do planejamento do

produto e muitas vezes estabelecer metas para o time a partir desta visão.
Quando elas estão definidas, é mais fácil visualizar o impacto do produto
para seus clientes.

8.2 NPS (Relacional e Transacional)

O Net Promoter Score (NPS) é uma das métricas de satisfação mais
utilizadas no mundo. Ele é tão completo que pode ser usado tanto para obter
resultados processuais, com o NPS Transacional, quanto para medir
resultados mais abrangentes, com o NPS Relacional.

Não é complexo entender a diferença entre eles:

• O NPS relacional serve para avaliar a experiência global com a marca;

• NPS transacional avalia um determinado processo, de forma

pontual.

58
 O NPS Relacional mede a experiência completa, enquanto o NPS
Transacional avalia a experiência do cliente em determinadas etapas da
jornada.

Entender essa diferença é importante para o PM, pois o seu produto

faz parte da empresa, então o NPS relacional pode ou não ser impactado
pelo seu trabalho. O NPS transacional, por sua vez, pode medir diretamente
o resultado do seu produto, ou seja, a experiência que o cliente teve ao
utilizá-lo.

8.3 Times Customer Centricity

Times customer Centricity significa colocar o cliente em primeiro
lugar e no centro de tudo o que você faz. Dessa forma, organizações
centradas no cliente tomam medidas para entender o cliente e agir de
acordo com esse entendimento, criando uma cultura que capacita os
funcionários a tomarem as melhores decisões para o cliente e para a
empresa ao mesmo tempo.

Nesse sentido, fazer com que todos do time tenham um pensamento

de centralidade no cliente, garantir eficiência operacional e ao mesmo
tempo oferecer a melhor experiência possível aos seus consumidores
compõem alguns dos maiores desafios de um gestor de produto.

As diversas práticas, os frameworks e as filosofias de trabalho mais

modernas, como Design Thinkin, Agile, Lean, têm como valores, pilares ou
princípios o cliente no centro ou a geração de valor para o cliente em
primeiro lugar. Dessa forma, caso o PM e o seu time entendam de pessoas e
de suas reais necessidades, é possível que tenham muito mais chances de
produzir produtos de sucesso.

59
Referências
ANDERSON, Steve. As cartas de Bezos. Tradução de Débora Fleck. Rio de
Janeiro: Sextante, 2020.

BEEDLE, Mike et al. Manifesto for Agile Software Development. [S.I.], 2001.
Disponível em: https://agilemanifesto.org/. Acesso em: 07 abr. 2022.

GNANASAMBANDAM, Chandra et al. Product managers for the digital world.

McKinsey&Company. [S.I.], 24 maio. 2017. Disponível em:
https://www.mckinsey.com/industries/technology-media-and-
telecommunications/our-insights/product-managers-for-the-digital-world.
Acesso em: 07 abr. 2022.

KOTLER, Philip; Armstrong, Gary. Princípios de marketing. Tradução de

Alexandre S. Martins. Rio de Janeiro: Prentice/Hall do Brasil, 2000.

KOTLER, Philip; KELLER, Kevin Lane. Administração de marketing.

Tradução de Sônia Midori Yamamoto. 14. ed. São Paulo: Pearson Education
do Brasil, 2012. 794 p.

OUTSYSTEMS. The Growing Threat of Technical Debt. Boston, [20-?].

Disponível em: https://www.outsystems.com/1/growing-threat-technical-
debt/. Acesso em: 07 abr. 2022.

PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em

Gerenciamento de Projetos: Guia PMBOK. 6. ed. Newtown Square, 2018.
756 p.

RAPAILLE, Clotaire. The Culture Code. New York: Broadway Books, 2007.
213 p.

60
REINERTSEN, Donald G. The Principles of Product Development Flow.
Redondo Beach: Celeritas Publishing, 2009. 304 p.

SCALED AGILE. Framework SAFe. [S.I.], 2021. Disponível em:

https://www.scaledagile.com. Acesso em: 07 abr. 2022.

61