Estrategia Lean

Estratégia Lean
o caminho mais rápido e seguro para

inovação e transformação digital
Paulo Caroli e Joaquim Torres

(Joca)
Estratégia Lean
o caminho mais rápido e seguro para
inovação e transformação digital
Paulo Caroli e Joaquim Torres (Joca)

Esse livro está à venda em http://leanpub.com/leanpmo
Essa versão foi publicada em 2020-01-23
Esse é um livro Leanpub. A Leanpub dá poderes aos autores e

editores a partir do processo de Publicação Lean. Publicação Lean
é a ação de publicar um ebook em desenvolvimento com
ferramentas leves e muitas iterações para conseguir feedbacks dos
leitores, pivotar até que você tenha o livro ideal e então conseguir
tração.
© 2015 - 2020 Paulo Caroli e Joaquim Torres (Joca)

Outras Obras Desses Autores
Livros De Paulo Caroli
Fun Retrospectives
Optimizing The Flow
Direto ao ponto
Retrospectivas Divertidas
Fun Retrospectives
DevOps para entrega de produtos enxutos
Lean Inception
7 passos para definir a estratégia do seu time
Enxugando a Máquina
Whisky, Sushi, Systems & Flow
The Lean Product Guide
O Modelo 4 E
MyStartUp
Produktmanagement
Consciência Digital
Transformação digital
Lean Inception
Diagrama de Fluxo Cumulativo
Cumulative Flow Diagram
Management 3.0
Lean Software Engineering
A verdadeira história de um time em formação após a Lean
Inception
Lean Product Development: Guiando a Construção do MVP com
Scrum e Kanban
Livros De Joaquim Torres (Joca)

Product Management
Produktmanagement
Transformação digital
aos amigos do Sicredi, corporação exemplar na busca de mais
agilidade, enquanto mantém o equilíbrio com a estrutura
organizacional.
Conteúdo
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Sobre Paulo Caroli . . . . . . . . . . . . . . . . . . . . . . . . ii
Sobre a Editora Caroli . . . . . . . . . . . . . . . . . . . . . . iii
Sobre este livro . . . . . . . . . . . . . . . . . . . . . . . . . . iv

Sobre o Lean PMO . . . . . . . . . . . . . . . . . . . . . . iv
Simples é diferente de simplório . . . . . . . . . . . . . . . 1

Unidade de Negócio - UN . . . . . . . . . . . . . . . . . . 1
Estratégia, UN, OKR e MVP . . . . . . . . . . . . . . . . . 2
Os três horizones - 3Hs . . . . . . . . . . . . . . . . . . . . . 4

Horizonte 1 – estável . . . . . . . . . . . . . . . . . . . . . 5
Horizonte 2 – emergente . . . . . . . . . . . . . . . . . . 6
Horizonte 3 – experimento . . . . . . . . . . . . . . . . . 7
De H3 para H2 . . . . . . . . . . . . . . . . . . . . . . . . 7
De H2 para H1 . . . . . . . . . . . . . . . . . . . . . . . . 7
Experimento, resultado, receita . . . . . . . . . . . . . . . 9
Os 3Hs e este livro . . . . . . . . . . . . . . . . . . . . . . 9
O ciclo PDCA do Lean Strategy . . . . . . . . . . . . . . . . 11

Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
CONTEÚDO
Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Priorização relativa por VALOR e ESFORÇO . . . . . . . . 15
Definindo VALOR . . . . . . . . . . . . . . . . . . . . . . 16
Compreendendo ESFORÇO . . . . . . . . . . . . . . . . . 18
NOTA da iniciativa . . . . . . . . . . . . . . . . . . . . . . 19
Cálculo de NOTAs, um exemplo . . . . . . . . . . . . . . 19
Várias iniciativas . . . . . . . . . . . . . . . . . . . . . . . 21
Iniciativa NOTA 10 . . . . . . . . . . . . . . . . . . . . . . 23
Sessão colaborativa de preenchimento da tabela de pri-
orização . . . . . . . . . . . . . . . . . . . . . . . . 23
Moedas da organização . . . . . . . . . . . . . . . . . . . 28
Risco ou realidade . . . . . . . . . . . . . . . . . . . . . . 28
Outros modelos para priorização . . . . . . . . . . . . . . . 30

Priorização absoluta . . . . . . . . . . . . . . . . . . . . . 30
Priorização do Hipopótamo . . . . . . . . . . . . . . . . . 30
Priorização por decibéis . . . . . . . . . . . . . . . . . . . 31
Priorização The Flash . . . . . . . . . . . . . . . . . . . . 31
Priorização rapa do tacho . . . . . . . . . . . . . . . . . . 32
Funding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Objetivos de negócio e funding . . . . . . . . . . . . . . . 34
Funding e os 3 Hs . . . . . . . . . . . . . . . . . . . . . . . 35
Funding e capacidade de Negócio . . . . . . . . . . . . . 35
Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
MVP – Produto Mínimo Viável . . . . . . . . . . . . . . . . 37
MVP e o Fluxo de trabalho . . . . . . . . . . . . . . . . . 37
Lean Inception . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Construindo MVP com Scrum . . . . . . . . . . . . . . . . . 39

Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
CONTEÚDO
O MVP nas cerimônias do scrum . . . . . . . . . . . . . . 43
Construindo MVP com Kanban . . . . . . . . . . . . . . . . 45

Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
O MVP no Kanban . . . . . . . . . . . . . . . . . . . . . . 48
Arquitetura Mínima Viável (MVA) . . . . . . . . . . . . . . 60

Micro-serviços de Domínio . . . . . . . . . . . . . . . . . 62
Acompanhamento Lean . . . . . . . . . . . . . . . . . . . . . 63
O entendimento da iniciativa via MVP . . . . . . . . . . 63
O planejamento do produto e seus MVPs . . . . . . . . . 64
O acompanhamento da criação do produto via MVP . . 66
Burn-up de Features do MVP . . . . . . . . . . . . . . . . . 69

Os eixos do burn up . . . . . . . . . . . . . . . . . . . . . 71
O ritmo da construção do MVP . . . . . . . . . . . . . . . 71
Verificando o progresso . . . . . . . . . . . . . . . . . . . 73
A linha de escopo do MVP . . . . . . . . . . . . . . . . . 75
Status report do MVP . . . . . . . . . . . . . . . . . . . . . . 77

Nome do time e ID do MVP . . . . . . . . . . . . . . . . . 78
Nome do MVP . . . . . . . . . . . . . . . . . . . . . . . . 78
Estado atual (verde / amarelo / vermelho) . . . . . . . . . 78
Data atual e data prevista . . . . . . . . . . . . . . . . . . 78
Lista de features do MVP . . . . . . . . . . . . . . . . . . 79
Nível de incerteza da funcionalidade(verde / amarelo /
vermelho) . . . . . . . . . . . . . . . . . . . . . . . 79
Estado e % de completude da funcionalidade . . . . . . . 79
Detalhamento e texto descritivo . . . . . . . . . . . . . . 80
Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Analysis paralysis . . . . . . . . . . . . . . . . . . . . . . 91
CONTEÚDO
Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Objetivos e Resultados Chaves - OKR . . . . . . . . . . . . 94
Planejamento Contínuo . . . . . . . . . . . . . . . . . . . . . 103

Aposta e quantidade de fichas . . . . . . . . . . . . . . . 103
Do OKR ao MVP, estamos alinhados! . . . . . . . . . . . . 105
OKRit - OKR, iniciativas e tarefas . . . . . . . . . . . . . . 107
Sobre Pivotar . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Um caso prático . . . . . . . . . . . . . . . . . . . . . . . . 111
Disclaimer
Eu escrevendo sobre Lean, mas sem colocar limite no WIP, e
escrevendo vários E-Books ao mesmo tempo…
Pois bem, então vou tratar os E-Books como MVPs. Se já tem algo
minimamente viável para passar a ideia, o conceito, então vou
liberar.
Por isso neste E-Book você vai encontrar erros de ortografia,
imagens em versões iniciais, e texto por escrever.
Mas como um bom MVP, estou muito interessado no seu feedback.
Abraços,
Caroli
paulocaroli@gmail.com
Sobre Paulo Caroli
Consultor principal da Thoughtworks Brasil e cofundador da Agi-
leBrazil, Paulo Caroli possui mais de vinte anos de experiência
em gestão e desenvolvimento de software, com passagem em
varias corporações no Brasil, Índia e EUA . Em 2000, conheceu o
Extreme Programming e, desde então, tem mantido seu foco em
processos e práticas de gestão e desenvolvimento ágil. Ingressou
na ThoughtWorks em 2006 e ocupou os cargas de agile coach,
treinador, e Gerente de Projetos. Possui os títulos de Bacharel em
Ciência da Computação e MS em Engenharia de Software, ambos
da PUC -Rio. Autor dos Livros ” Direto Ao Ponto; Criando Produtos
de forma enxuta” , e “Fun Retrospectives; activities and ideas for
making agile retrospectives more engaging”.
Paulo Caroli
Acompanhe Paulo Caroli no seu site e nas redes sociais:

Sobre a Editora Caroli
A Editora Caroli nasceu em 2017, quando Paulo Caroli decidiu
realizar todos os passos desde escrever um livro a impressão e venda
do mesmo. Este livro é O Mistério do Colégio Alipus.
Paulo Caroli segue muito do seu aprendizado no Vale do Silício para
a criação de conteúdo e publicação de livros. Com um estilo Lean
StartUp (construir fazendo) nasceu a Editora Caroli.
Caroli constituiu uma editora para publicar seus livros e para ajudar
a publicar livros de amigos.
WIP (Writing In Progress)
A Editora Caroli apresenta uma nova proposta de trabalho, apro-

ximando autores dos seus leitores desde o início da geração do
conteúdo. Porque esperar o autor terminar de escrever para ver se o
conteúdo é bom? No mundo atual isso não faz mais sentido. Então a
Editora Caroli promove o compartilhamento (gratuito sempre que
possível) do WIP (Writing In Progress) através dos formatos eBook
(pdf, mobi e epub). Desta forma, leitores tem acesso rápido as novas
ideias, e podem fazer parte da evolução da obra. Para os autores,
esse é uma forma efetiva de feedback e motivação para a geração
de conteúdo.
Este e outros eBooks estarão disponíveis no site http:

//caroli.org
Sobre este livro
Este livro vem evoluindo desde 2014, ano em que liderei uma
transformação digital de uma excelente corporação.
Naquela época eu ajudei a diminuir a distância existente entre
dois mundos: metodologias ágeis e o PMO, abreviação para Project
Management Office, em Inglês. Eu percebi que não estava somente
levando algumas práticas ágeis para os projetos e para o PMO, mas
sim estava usando práticas Lean para aproximar esses dois mundos.
Por esse motivo esse trabalho foi nomeado Lean PMO, onde eu
indicava que o P de PMO deveria ser para Produtos, ao invés de
Projetos.
Mas o conteúdo do livro e o feedback recebido pelo mesmo evolui.
E este foi utilizado por diferentes organizações, independente da
estrutura de PMO. Por tal motivo o nome foi alterado de Lean PMO
para Lean Strategy.
Sobre o Lean PMO

PMO (abreviação de Project Management Office em Inglês ou
Escritório de Gestão de Projetos em Português) é uma unidade
organizacional que conduz e dá suporte aos grupos de Gestão de
Projetos.
Desde 2000, os métodos ágeis vem evoluindo e sendo aplicados nas
organizações. Atualmente todas organizações usam alguma coisa
de métodos ágeis. E o PMO já vem se adaptando em relação a isso.
Vide a evolução do PMBOK nos últimos anos, incluindo ágil no seu
vocabulário.
Sobre este livro v
Mas a maior mudança vem da transformação digital que coloca

o cliente no centro do universo. Produtos digitais são criados e
evoluem baseado no feedback real dos seus usuários. E isso que vem
gerando uma reorganização nas empresas, atuando sobre produtos
mais que projetos.
Como conduzir e dar suporte a essas novas empresas? O PMO
tradicional não funciona. Um pouco de agilidade no processo ajuda,
mas ainda não resolve. O novo foco é em Produtos!
Simples, trocamos o P de PMO de Project para Product. Mantemos
a sigla, mantemos a unidade organizacional. Mas ajustamos o
objetivo: conduzir e dar suporte a estratégia e gestão de Produtos.
Eu tenho utilizado muitos conceitos e práticas Lean nesta área. Por
isso criei este eBook com o nome de Lean Strategy, que compartilho
aqui.
Seja parte da criação e evolução deste eBook!
Os conceitos aqui apresentados estão sendo colocados a prova em
várias corporações. Em 2017 os resultados se mostram valiosos. A
partir deles, estou descrevendo o que está funcionando.
Simples é diferente de
simplório
Este livro apresenta um modelo simples para te ajudar com uma
estratégia mais enxuta e efetiva. Mas não confunda simples com
simplório. Para alcançar este modelo simples, alguns anos se passa-
ram na busca e confecção do mesmo. Somente depois de cinco anos
de tentativas e maturidade do mesmo, compartilho este modelo
simples.
Unidade de Negócio - UN
Os conceitos compartilhados neste livro foram aplicados em várias
organizações, desde pequenas StartUps a grandes empresas com
variadas estruturas organizacionais. Por esse motivo decidi descre-
ver neste livro algo prático para ser utilizado por uma unidade de
negócio (UN para abreviação), onde UN rerpesenta uma unidade
de negócio independente com resultados, estratégia, processos,
gestores e equipes distintas.
Simples é diferente de simplório 2
Unidades de Negocio - UN
No caso de uma pequena startUp, a própria compõe a UN. Grandes

corporações são formadas por várias UNs.
Os conceitos apresentados neste livro se aplicam a UNs mais ágeis,
que buscam uma estratégia e processo mais enxuto (Lean) para
suceder com produtos digitais. Considero este livro mais útil para
UNs com maior foco em H2 (do que H1 ou H3, conforme descrito
no capítulo os Três Horizontes).
Estratégia, UN, OKR e MVP

Os OKRs (mais detalhes no capítulo OKR) ajudam a definir o
direcionamento estratégico da UN. Mas precisamos transformar
estratégia em ação. Precisamos priorizar as iniciativas, criá-las e
medir seus resultados.
Para tanto, utilizamos os MVPs (mais detalhes no capítulo MVP).
Iniciativas priorizadas passam por um workshop de Lean Inception
(mais detalhes no capítulo Lean Inception), onde são compreen-
didas e planejadas via MVP, o produto mínimo viável, ou seja,
o mínimo necessário para verificar o direcionamento inicial da
iniciativa.
Dessa forma, o MVP funciona como a ponte entre o estratégico
e o tático, conectando as expectativas estratégicas da UN com a
Simples é diferente de simplório 3
realidade da evolução e inovação dos seus produtos, segundo as

métricas (mais detalhes no capítulo Métricas) de uso dos mesmos.
<imagem MVP como ponte, de um lado a estratégia, do outro o
operacional, quem cria o MVP>
Desta forma o MVP serve como mediador da conversa entre as
pessoas mais estratégicas –correlacionando MVPs com OKRs e
outras iniciativas da UN– e as mais operacionais, que detalham as
funcionalidades e tarefas necessários para a sua criação. Entretanto,
todos comparam o resultado esperado com o resultado atual do
MVP, demonstrado por suas métricas de uso.
A estratégia do negócio passa a ser assunto e responsabilidade de
todos. Todos compreendem os MVPs, bem como esses se relacionam
e auxiliam com os OKRs da UN.
Os três horizones - 3Hs
A estrutura de três horizontes da McKinsey ¹fornece uma nomen-
clatura para: o momento atual (horizonte 1), um futuro próximo
(horizonte 2) e um futuro mais distante (horizonte 3). Empresas
inovadoras distribuem seu portfólio de investimento de acordo com
esses três horizontes.
os 3 Horizontes de crescimento
¹A Alquimia do Crescimento - os Segredos das 30 Empresa que Mais Crescem no Mundo,

por Baghai, Mehrdad; Editora Record 1999
Os três horizones - 3Hs 5
os 3 Horizontes de crescimento
< qual imagem está melhor? >

A McKinsey realizou estudos e pesquisas sobre como as empresas
sustentam o crescimento. Com base nessas pesquisas, criou-se a
estrutura de três horizontes, uma abordagem que ilustra como ge-
renciar para o desempenho atual, entretanto maximizando futuras
oportunidades de crescimento.
Desde o lançamento do meu livro ²sobre a criação de produtos
de forma enxuta, baseado no conceito de MVP –produto mínimo
viável, ou Minimum Viable Product, em inglês– tenho buscado
um melhor esclarecimento sobre experimentos, MVP e produtos
estabelecidos. Encontrei na estrutura dos três horizontes uma boa
forma de expressar o meu entendimento e sugestão sobre a gestão
de portfólio e investimento em produtos e inovação.
Horizonte 1 – estável
No horizonte 1 estão as vacas leiteiras, aqueles produtos já cresci-
dos, estáveis e que estão gerando o sustento da empresa atualmente.
²Direto ao ponto: criando produtos de forma enxuta, Paulo Caroli, Casa do codigo, 2016
Talvez esses já não tenham muito investimento em novo desen-

volvimento. A maior parte do investimento está em operação, em
mantê-lo funcionando e atendendo as necessidades atuais do seu
cliente.
Horizonte 2 – emergente
O horizonte 2 mostra o que está por vir num futuro próximo (em
alguns meses ou anos, dependendo do nicho de mercado). São
os produtos ou features emergentes. Aqueles que requerem mais
investimento em desenvolvimento e criação do que em operação (a
base de usuários e/ou a exposição do produto ainda é pequena).
Invista nas bezerras
O investimento em H2 é o gasto com suas bezerras, aquelas que são

candidatas a futuras vacas leiteiras. Lembre-se que as atuais vacas
leiteiras vão ficar velhas e vão secar. Logo, você precisa investir
nessas bezerras!
Mas nem toda bezerra vai virar uma boa vaca leiteira. Isso faz parte
do negócio. Aprendi isso com meu avô que criava gado leiteiro: ou
segue apostando na bezerra (pois começou a dar leite), ou pivota seu
uso (deixa para reproduzir, talvez gerando alguma vaca leiteira), ou
desiste (pare de gastar com essa bezerra pois ela não vai virar uma
vaca leiteira; bom, nesse caso a pobrezinha ia para o abate).
Prosseguir, pivotar, ou cancelar. Esse é o mantra para os

produtos e as features emergentes.
Horizonte 3 – experimento
O horizonte 3 é um futuro bem distante, anos ou décadas, depen-
dendo do seu nicho de mercado.
E a metáfora da vaca acaba aqui. No horizonte 3 você nem sabe o
que vai estar dando o sustento da fazenda. Simples assim. Pode ser
uma criação de ovelhas de raça, búfalos leiteiros, plantação de soja,
minério, aeroporto para marcianos, etc.
É experimento. Ideias e mais ideias. Algo bem distante. Talvez até
inimaginável com o seu conhecimento atual.
São experimentos, coisas para te fazerem pensar, para te ajudarem
a entender um mundo novo que ainda nem se formou. Talvez até te
tirando da zona de conforto (por exemplo um engenheiro da Kodak
com seus experimentos sobre fotografia digital em 1974).
De H3 para H2
Mas assim como a vaca atual está secando, a bezerra também vai
secar, e lá na frente, você vai precisar de alguma ideia nova. Algo
que brote e possa emergir.
Agora sim, posso ressaltar que o investimento em H2 ou é para
algo próximo ao seu produto atual (uma bezerra que também vai
dar leite) ou é algum experimento que já se mostrou interessante,
ou seja, algo que veio de H3 para H2.
De H2 para H1
O movimento de H2 (emergir) para H1 (estável) é comum nas
empresas. E isso era o suficiente no século passado, para muitos
nichos de mercado.
Mas o mundo mudou. Com o advento da internet, da mobilidade,

das redes sociais, e a computação nas nuvens, tudo ficou acelerado.
O H3 era muito distante, e provavelmente não iria derrubar um
CEO. Ele se aposentaria antes disso.
Agora é diferente. O H3 chega mais rápido. E com ele, a inovação
disruptiva, aquela que altera o seu negócio pela raiz. Que vai
derrubar um CEO após o outro, e tirar a empresa do mercado.
A mensagem é clara: quem não investir em experimentos não vai
sobreviver. É questão de tempo. Quem não se reinventar vai ficar
de fora.
E não é investimento realizado em H1 e H2. Aqueles onde existe
ROI e/ou NPL. São investimentos em experimentos. Sem resultados
esperados. É investimento em H3.
Mas cuidado. No momento que se coloca expectativa de resultado
no experimento, ele deixa de ser um experimento. Em contrapartida
um MVP tem uma expectativa de resultado. Um MVP deve colocar
uma hipótese a prova: será que essa bezerra vai dar leite?
Cuidado, você pode estar se iludindo e chamando H2 de H3. Não
confunda um H3 que entrou para H2 com algo que começa com
H2. MVP é H2. É algo com resultado esperado e com expectativa de
emergir.
H3 são experimentos. Criatividade, liberdade, observação. É pes-
quisa, é experimento, é aprendizado. H3 busca ideia e conheci-
mento. Não busca resultado. Mais que validar uma hipótese, H3
ajuda a formular as hipóteses.
H3 deve gerar muitos dados. Talvez até dados divergentes para
serem analisado de vários ângulos diferentes, para gerar novas
perspectivas. Até que saia dali uma ideia mais evoluída. Algo que
ajude a formar uma hipótese. Algo para o qual possamos elaborar
um MVP, e colocar a hipótese a prova.
Perceba a diferença: em H2 temos um resultado esperado. Podemos
descrevê-lo, colocá-lo num canvas ³, criar, e verificar se estamos

alcançando o resultado esperado. Poderemos decidir entre pivotar,
cancelar ou prosseguir.
Mas em H3 não. Não temos resultado, mas sim um processo para
experimentação: criatividade, liberdade, observação. E depois, se
alguém der sentido de algo que apareça dentre os vários experi-
mentos, formulamos uma hipótese.
Experimento, resultado, receita

Em H1 o foco é na receita. Quando a vaca leiteira começar a secar,
planejamos a sua descontinuação.
Em H2 o foco é no resultado. Melhores resultados indicarão as
melhores vacas leiteiras, onde deveremos dar mais atenção, afinal
de contas, esse será o nosso sustento. Na busca de resultados,
decidimos frequentemente: prosseguir, pivotar, ou cancelar.
Em H3 o foco é no processo de experimentação; Seja de forma mais
defensiva, onde a empresa reconhece a aceleração do seu nicho
de mercado e decide o quanto vai dedicar a experimentos. Seja de
forma mais agressiva, onde a empresa experimenta para atacar (ser
disruptiva) em novos mercados.
Os 3Hs e este livro

Este assunto de 3Hs deve ter despertado seu interesse para repensar
o portfolio de investimento da sua emrpesa.
Como está portfólio de investimento da sua empresa? Está alinhado
com a velocidade deste novo mundo?
³O Canvas MVP para definir a estratégia do Produto Mínimo Viável, por Paulo Caroli;
disponível em www.caroli.org/o-canvas-mvp . Acesso em agosto de 2018.
Espero que você consiga alocar budget para cada um dos 3Hs.
Mas te digo que cada um desses horizontes requer uma forma de
trabalhar distinta. Considero o modelo apresentado neste livro mais
adequado para iniciativas e UNs com maior foco em H2.
O ciclo PDCA do Lean
Strategy
O PDCA do Lean Strategy
Esse é o ciclo do PDCA: Tudo começa a partir de um workshop

de OKR (em Inglês, Objectives and Key Results) para a Unidade de
Negócio (UN).
Workshops de ideação, workshops de discovery, fases de entendi-
mento, pesquisa de mercado, resultado de pesquisa ou trabalho de
agência, lista de desejos, planilha da diretoria; seja lá o estilo da sua
empresa, a lista de iniciativas é compilada. O que não aponta para
um norte identificado pelos OKRs já pode ser descartado.
Então várias iniciativas (candidatas) da UN são consideradas em
um workshop de priorização relativa, onde essas são avaliadas
quantitativamente, considerando o valor e o esforço de cada uma
(PLAN).
O próximo squad disponível puxa a iniciativa priorizada (sistema
O ciclo PDCA do Lean Strategy 12
puxado) para um workshop de Lean Inception, onde todos juntos

(negócio, tecnologia e UX) compreendem e criam o plano para a
criação do MVP. Seguindo as práticas Scrum, Kanban e DevOps, o
squad constrói o MVP (DO).
Assim que o MVP está pronto, este é liberado para os seus usuários
finais. Os dados de uso são coletados e compilados como métricas
a serem analisadas (CHECK).
Comparando o resultado obtido com o resultado esperado do MVP,
decidimos como prosseguir com a iniciativa: pivotar, prosseguir,
ou cancelar. Esta decisão é realizada perante os resultados apre-
sentados por todas as iniciativas em andamento, seus MVPs, a
capacidade, o budget, os investimentos, e o alinhamento com os
OKRs da UN (ACT). Com base nesses parâmetros, decidimos,
estrategicamente, quais iniciativas começar, quais continuar, quais
pivotar, e quais cancelar.
O PDCA do Lean Strategy completa um ciclo no workshop de
Lean Strategy, onde verificar investimentos, OKRs, iniciativas em
andamento, MVPs e novas iniciativas. E depois voltamos para o
início do ciclo com um novo workshop de OKR, seguido pela
listagem das iniciativas, workshop de priorização… até o próximo
workshop de Lean Strategy. Reuniões bissemanais são utilizadas
para acompanhar os OKRs da UN.
O modelo Lean Strategy traz disciplina para priorizar, construir,
medir, e coordenar esforços para alcançar os objetivos estratégicos
do negócio.
Plan
Vamos planejar as ações estratégicas organizacionais para alcançar
nossos objetivos. Para tanto, vamos usar um portfolio dinâmico, que
nos permita compreender e agrupar as iniciativas, permitindo tanto
O ciclo PDCA do Lean Strategy 13
(1) uma priorização, inicial, quanto (2) o redirecionamento baseado

no feedback de cada iniciativa.
Do
Dado uma iniciativa priorizada, vamos compreendê-la, e executá-la
de forma enxuta, ágil e centrada no feedback dos nossos usuários.
Para tanto faremos entregas rápidas e frequentes.
Check
Medimos o uso de cada entrega. Essas métricas são essenciais para
validação de hipóteses e ajustes na evolução de nossas iniciativas,
baseado no feedback de uso.
Act
Decidimos como proceder com cada iniciativa: pivotar, prossegir,
ou cancelar. Vamos rever as hipóteses iniciais (PLAN) e os dodos
de uso dos MVPs (CHECK). Iremos também comparar as diversas
iniciativas perante o orçamento da Unidade de Negócio (UN).
Plan
Priorização relativa por
VALOR e ESFORÇO
“Esta iniciativa é importante?”
Sempre obtive a mesma resposta quando fiz tal pergunta em uma
reunião sobre portfolio. Por isso, não a faço mais. A pergunta mais
relevante para te ajudar a priorizar as iniciativas é:
“Qual dessas duas é mais prioritária?”
Desta forma as iniciativas são priorizadas relativamente umas
às outras. Essa pergunta é muito útil e deve ser utilizada, mas
precisa de uma forma imparcial de responder a pergunta, ou pelo
menos, uma forma objetiva, que auxilie a um grupo de pessoas a
compreender as escolhas.
A forma mais objetiva que conheço é dinheiro. Essa é simples. E
desde que somos bem pequenos sabemos a diferença entre uma nota
de 2 reais e uma de 50 reais.
Por esse motivo eu aconselho uma forma de priorizar baseada
em algo vinculado a valor financeiro. Aliás aconselho uma forma
de trabalhar descrita pelo magnífico Dan Reinertsen no seu livro
Principles of Product Development Flow⁴: Cost of delay e CD3.
Cost of Delay (abreviado como COD) é o valor associado ao custo
de atraso de uma iniciativa; ou seja, qual valor acreditamos estar
deixando de ganhar por tal iniciativa ainda não estar pronta.
Por exemplo, iniciativa A tem um COD de 1000 dólares por mês,
enquanto iniciativa B tem um COD de 2000 dólares por mês.
⁴Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean
Product Development. Celeritas Publishing, 2009.
Priorização relativa por VALOR e ESFORÇO 16
Mas antes que você pense e diga que devamos priorizar iniciativa
B, tem de considerar qual esforço associado para criar tal iniciativa.
Por exemplo, iniciativa A requer um mês de trabalho, enquanto
iniciativa B requer quatro meses de trabalho.
1000 dólares por mês depois de um mês de trabalho vale mais a pena
do que 2000 mil dólares por mês com quatro meses de trabalho.
Logo é melhor fazer primeiro a iniciativa A, depois a iniciativa
B. Essa conta de COD / duração também tem um nome e uma
abreviação: Custo de Atraso por Duração, CD3.
Definindo VALOR
A cálculo do valor de Cost of Delay é complicado. Afinal de contas,
como decidir e afirmar: eu acredito que a iniciativa A vá nos trazer
100.000 dólares por mês; e acredito que a iniciativa B traria 200.000
dólares por mês.
Minha primeira recomendação é não usar valores monetários (como
dólares ou reais), mas somente valores. Assim sendo, definimos a
escala de valores entre 0 e 10. Logo todas iniciativas devem ter um
valor entre 0 e 10. Por exemplo: iniciativa A tem o valor 3 enquanto
iniciativa B tem o valor 6.
Minha segunda recomendação é que esses valores estejam atrelados
a dois tipos de expectativas: (1) expectativa de uso vinculado a tal
iniciativa, e (2) expectativa do negócio vinculado a tal iniciativa.
Para (1), eu gosto dos parâmetros utilizados pelo método RICE⁵,
segundo por Sean Mcbride, gerente de produtos da Intercom. RICE é
um acrônimo para as iniciais de Reach, Impact, Confidence e Effort
(assunto da próxima sessão).
⁵post descrevendo o método RICE, segundo por SEAN MCBRIDE ,PRODUCT MANA-
GER, DA INTERCOM; disponível em https://blog.intercom.com/rice-simple-prioritization-for-
product-managers/ . Acesso em Agosto de 2018
• Reach: quantas pessoas serão impactadas por essa iniciativa?

(Considere para um mesmo período)
• Impact: quanto isso irá impactar cada uma dessas pessoas?
• Confidence: o quáo confiante você está em relação a esses
números?
Para (2), eu gosto dos parâmetros descritos por WSJF (Weighted

Shortest Job First), também vinculada a Dan Reinertsen, e recomen-
dada pelo framework SAFe⁶.
• Business Value: Qual a penalidade potencial ou impacto nega-

tivo se atrasar ou demorar? Quanto está deixando de ganhar
com esa iniciativa?
• Time Criticality: O quão rápido o valor do negócio diminui
ao longo do tempo? Os usuários irão esperar por nós ou
encontrarão uma outra opção?
• Risk Reduction: Qual o risco de postergar esta iniciativa
para o nosso negócio? Esta iniciativa vai abrir/facilitar novas
oportunidades de negócio?
É importante ressaltar que tanto RICE, quanto WSJF recomendam

o mesmo denominador: Effort, assunto da próxima sessão.
Segue a equação recomendada para cálculo de VALOR, baseado em
RICE e WSJD:
VALOR = X + Y, onde X representa valores referentes aos usuários, e
Y valores referentes ao negócio. O cálculo de X é influenciado por
RICE, e o cálculo de Y por WSJD. Tanto X, quanto Y são valores
entre 0 e 5, logo, a resultante de VALOR é algum valor entre 0 e 10.
VALOR = [valores referentes aos usuários] + [valores referentes ao
business]
⁶Scaled Agile Framework – SAFe for Lean Enterprises
http://www.scaledagileframework.com/
VALOR = [Reach x Impact x Confidence] + [ (Business Value +

Time Criticality + Risk Reduction) /3]
Seguem o intervalos de possíveis medidas para os parâmetros:
• Reach (de 0 a 5; 5 significa maior alcance)

• Impact (de 0 a 1; 1 significa maior impacto)
• Confidence (de 0 a 1; 1 significa 100% confiante)
• Business value (de 0 a 5; 5 significa maior valor)
• Time Criticality (de 0 a 5; 5 significa extremamente crítico)
• Risk Reduction (de 0 a 5; 5 significa extremamente necessário
para reduzir risco)
Compreendendo ESFORÇO
No momento de PLAN, temos muitas hipóteses, mas mesmo assim
precisamos transformar tais hipóteses em valores para nos auxilia-
rem a tomar decisões.
ESFORÇO é uma medida da expectativa de trabalho da equipe em
tal iniciativa. Dado que temos uma dada equipe, quanto de esforço
requer a iniciativa A? E a iniciativa B? E as outras? Pronto. Dê um
palpite de esforço, ou seja, uma noção da expectativa do trabalho
necessário para cada uma das iniciativas. Assim você conseguirá
comparar o custo / benefício das iniciativas.
Mas não tente ser perfeito com estimativas, especialmente neste
momento. Estimativa é um assunto muito difícil. E provavelmente
você irá errar, mesmo quando compreender melhor as iniciativas e
detalhar o trabalho para construí-las.
Mas nesse momento, de esclarecimento sobre o portfolio de inici-
ativas, ainda não temos os detalhes das iniciativas. Portanto não
tente ser preciso. Faça a pergunta de forma comparativa:
Para a mesma equipe (assumindo dedicação exclusiva

por iniciativa); qual dessas iniciativas requer mais es-
forço? A, B, C, D…? Qual requer menos esforço?
Esta comparação de esforço não é uma estimativa ou comprome-

timento com datas. É uma comparação entre o trabalho esperado
para as iniciativas, de forma a compará-las, e possivelmente, dar
unidades a cada uma delas; por exemplo: 1, 3 e 8; respectivamente
para a iniciativas A, B e C, indicando que a iniciativa B requer
três vezes mais trabalho que a iniciativa A, enquanto a iniciativa
C requer oito vezes mais. Desta forma o ESFORÇO das iniciativas
é determinado de forma comparativa, sem vínculo com período de
tempo.
Uma UN deve manter a gestão de iniciativas similares em tamanho.
Se uma iniciativa de uma UN for mais de dez vezes maior do que a
menor iniciativa da UN, recomendo que esta seja dividida em duas
iniciativas menores.
Desta forma, o ESFORÇO de cada iniciativa deve variar entre 1E e
10E.
NOTA da iniciativa
Após determinar comparativamente o VALOR e o ESFORÇO de
cada iniciativa, devemos calcular suas NOTAs. Esta conta é rea-
lizada com base na seguinte fórmula para o cálculo da nota da
iniciativa:
NOTA = VALOR / ESFORÇO
Cálculo de NOTAs, um exemplo

Segue um exemplo de cálculo das NOTAs de duas iniciativas.
Iniciativa A: metade dos nossos usuários serão afetados por esta

iniciativa. Reach = 2.5
Iniciativa B: todos nossos usuários serão afetados por esta iniciativa.
Reach = 5
Iniciativa A: o impacto vai ser enorme para cada usuário que
perceber esta iniciativa. Impact = 1
Iniciativa B: o impacto vai ser pequeno para cada usuário que
perceber esta iniciativa. Impact = 0.2
Iniciativa A: temos dados quantitativos que demostram que isso vai
acontecer. Confidence: 0.9
Iniciativa B: não temos dados quantitativos, nem pesquisa com
usuários, mas acreditamos fortemente que isso vá acontecer. Con-
fidence: 0.5
Iniciativa A: vamos receber uma multa altíssima caso não façamos
isso. Business value: 5
Iniciativa B: estamos deixando de expandir mercado por não ter
essa iniciativa funcionando. Business value: 3
Iniciativa A: Se perdemos o time-to-market, nossos usuários irão
migrar para nossos competidores. Time criticality: 5
Iniciativa B: essa iniciativa é importante, mas parece que não iremos
perder essa oportunidade (ainda). Time criticality: 1
Iniciativa A: Essa iniciativa traz um produto bonito, mas não
resolve os problemas de arquitetura que seguimos postergando.
Risk Reduction: 1
Iniciativa B: Essa iniciativa vai dar o start para a nova arquiterura
de todos nossos produtos. Isso vai evitar muitos problemas futuros
. Risk Reduction: 4
Iniciativa A: A equipe considera que precisa de 3 vezes mais esforço
para essa iniciativa, quando comparado com a iniciativa B: 3E
Iniciativa B: A equipe considera que precisa de 3 vezes menos

esforço para essa iniciativa, quando comparado com a iniciativa
A: E
Segue abaixo os cálculos para as NOTAs das iniciativas A e B.
Cálculo da NOTA da iniciativa A:
VALOR A = [2.5 x 1 x 0.9 ] + [ (5 + 5 + 1) / 3]
VALOR A = 2.25 + 3.67 = 5.9
ESFORÇO A = 3
NOTA A = VALOR A / ESFORÇO A
NOTA A = 5.9 / 3 = 1.97
Cálculo da NOTA da iniciativa B:
VALOR B = [5 x 0.2 x 0.5 ] + [ (3 + 1 + 4) / 3]
VALOR B = 0.5 + 2.67 = 3.17
ESFORÇO B = 1
NOTA B = VALOR B / ESFORÇO B
NOTA B = 3.17 / 1E = 3.17
Iniciativa VALOR ESFORÇO NOTA
A 5.9 3 1.97
B 3.17 1 3.17
Várias iniciativas
O exemplo ilustrativo da sessão anterior demonstra iniciativa A e B.
Mas as unidades de negócio, especialmente em grandes corporações
possuem portfolios com muito mais que duas iniciativas. Devemos
colocá-las em uma tabela para demonstrar os númenos.
Segue um exemplo de tabela de priorização com as iniciativas de
uma UN:
Iniciativa VALOR ESFORÇO NOTA
A 5.9 3 1.97
B 3.17 1 3.17
C 8 4 2
D 7.6 5 1.52
E 4.3 3 1.43
F 2.1 2 1.05
Desta forma podemos selecionar as iniciativas mais prioritárias

dado a capacidade da UN. Note que o orçamento da UN deve refletir
a quantidade e tamanho das equipes de produto.
Mais uma vez ressalto que neste momento de planejamento e
priorização do portfólio não estamos interessados em ser precisos
em relação a datas e tamanho absoluto das iniciativas.
O mais importante é compreender o esforço relativo dentre as
iniciativas em uma unidade de negócio. Por exemplo, a iniciativa B
requer cinco vezes mais esforço que a iniciativa A. Para a atividade
de priorização essa informação é mais útil do que dizer que a inici-
ativa A requer um esforço de aproximadamente dois meses e meio
enquanto a iniciativa B requer um esforço de aproximadamente um
ano.
Inevitavelmente, quando utilizamos medidas temporais, como se-
manas ou meses, geramos expectativas sobre o tempo necessário
para realizar uma iniciativa.
Alem disso antecipamos uma conversa sobre a equipe que vai
trabalhar na iniciativa. Qual o perfil da equipe para essa iniciativa?
Precisamos de mais conhecimento em alguma área ou tecnologia
específica? Mas este não é o momento de definir ou escolher a
equipe mais adequada à esta iniciativa. Isso acontece quando está
iniciativa for priorizada, ao entrar na etapa DO.
Depois do planejamento e da priorização das iniciativas, entramos
na fase de DO. Nesta fase começaremos com uma Lean Inception,
onde o time de produto responsável pela iniciativa irá compreender

a iniciativa e criar um plano baseado no conceito de MVP.
Iniciativa NOTA 10
Não sei quanto a você, mas no meu tempo de colégio, 10 era a nota
máxima. Por vezes a nota final era calculada somando e dividindo
alguns números. E o resultado era algun valor entre 0 e 10.
E todos alunos buscavam a nota 10.
Pois bem, o cálculo de NOTA proposto nesse livro gera algum valor
entre 0 e 10, sendo 10 a melhor nota possível.
Nesse contexto, uma iniciativa NOTA 10 seria uma iniciativa que,
comparativamente com as outras iniciativas, gera o máximo de
valor para o negócio (5), o máximo de valor para os usuários (5),
com o menor esforço (1):
NOTA = VALOR / ESFORÇO,
NOTA = (5 + 5) /1
NOTA = 10
Iniciativa NOTA 10!
Sessão colaborativa de
preenchimento da tabela de
priorização
Recomendamos o preenchimento da tabela de priorização de uma
única vez, em uma sessão colaborativa com os representantes das
varias iniciativas. Reserve uma boa sala (local ou virtual, para
reuniões remotas) para o tempo que considerar adequado (isso
depende do número de iniciativas, de participantes, e do nível de

discussão e detalhes para cada iniciativa).
Todos os parâmetros desta tabela consideram valores relativos entre
as iniciativas, por este motivo recomendamos fortemente que os
principais sponsors estejam juntos nesta sessão. Trabalhos prévios
para melhor esclarecimento de cada iniciativa são bem-vindos.
Entretanto alertamos para o possível desperdício de gastar muito
tempo e esforço detalhando uma Iniciativa, para depois descobrir
que esta alcança uma nota baixa e não será priorizada.
Segue um exemplo de tabela de priorização, criada com post-its
em um quadro durante uma sessão colaborativa em uma reunião
trimestral de priorização de iniciativas de uma UN.
preparando a tabela - iniciativas vs quesitos

resultado da tabela de priorização
Segue o passo a passo para facilitar a sessão colaborativa de

preenchimento da tabela de priorização:
1. Listar todas as iniciativas
Lista todas as iniciativas a serem comparadas e priorizadas nesta

sessão. As sessões e o agrupamento das iniciativas devem refletir a
estrutura financeira. Por exemplo: sessão da UN XPTO, sessão das
iniciativas H2 grupo Alpha, sessão iniciativas Mega Blaster - fase 3.
Liste as iniciativas como títulos de linhas em uma tabela (seja em
formato digital, como Excel, ou com post-it em um quadro branco)
1. Faça o pitch de cada iniciativa
Este varia muito de organização a organização, desde pitches muito

curtos (de um a cinco minutos) a pitches mais longos com decks e
apresentações sobre a importância e a relevância de cada iniciativa.
1. Explique e escreva cada quesito

Explique e de um exemplo de cada quesito. Se necessário, imprima

ou projete as perguntas de cada quesito para que fiquem visíveis a
todos.
Escreva cada quesito como títulos de colunas em uma tabela
(exemplo: uma planilha Excel ou post-it em um quadro branco)
1. Compare cada quesito, iniciativa a iniciativa
Selecione um quesito e compare-o iniciativa a iniciativa, de forma

a buscar valores relativos.
Por exemplo:
esforço; olhando para essas iniciativas, qual requer

menos esforço? Chamamos então de 1. Se esta inicia-
tiva tem esforço 1, quanto esforço seria esta outra? E
aquela?
Outro exemplo:
reach; lembrando que reach máximo é 5 e mínimo e

0. Qual o reach da iniciativa A? Se a iniciativa A tem
este reach, quanto seria o reach para a iniciativa B;
maior, menor, o mesmo? E para a iniciativa C?
1. Faça os cálculos
Se está usando um Excel, certifique-se da fórmula:

NOTA = VALOR / ESFORÇO, onde VALOR=[Reach x Impact x
Confidence]+[(BusinessValue + Time Criticality + Risk Reduction)
/3 ]
Se possível escreva a fórmula e deixe-a visível a todos.
Faça o cálculo e demonstre os resultados, indicando as notas de cada
iniciativa.
1. Conversa sobre o resultado
Promova uma conversa sobre o resultado apresentado. Neste mo-

mento a sessão se torna um pouco matemática e gera uma nota
para casa iniciativa, destacando as prioridades relativas. Agora é o
momento de refletir sobre os números e usá-los como base de uma
boa conversa.
Inevitavelmente algumas iniciativas tem notas mais baixas que
outras. Converse sobre o resultado e os passos seguintes antes de
terminar a sessão.
Cuidado com os Outliers

Outlier é uma iniciativa que de alguma forma se destaca
do grupo, e deve ser retirada desta sessão (considere
marcar outra sessão para tratar do outlier).
Outliers acontecem quando estamos comparando coisas muito

distintas. Por exemplo, maçã, laranja, uva, banana e um elefante.
Outro exemplo: um skate, uma bicicleta, uma moto e um transa-
tlântico.
Outliers devem ser identificados antes da sessão de comparação
das Iniciativas, mas caso esses estejam na lista de Iniciativas, tente
identifica-los e separa-los para outra sessão. Isso evita (1) discussões
muito difusas e (2) gerar valores relativos irrelevantes; por exemplo:
• esforço skate = 1
• esforço bicicleta = 1
• esforço moto = 1
• esforço transatlântico = 10;
ao invés disso, recomendamos retirar transatlântico da lista —

outlier— e alcançar algo como:
• esforço skate = 1
• esforço bicicleta = 4
• esforço moto = 10
Moedas da organização
Em uma grande organização que prestei consultoria sobre trans-
formação digital, ao invés de utilizarmos os números gerados pela
tabela de NOTAs de cada UN, criamos o conceito de moedas da
organização.
Por exemplo, considere a organização fictícia: organização JFC.
Para o exemplo anterior NOTA A de 0.98 e o NOTA B de 1.59,
dizíamos que a iniciativa A valia 98 moedas JFC enquanto a
iniciativa B valia 159 moedas JFC.
Ou seja, multiplicávamos o valor NOTA por 100 e utilizávamos a
unidade moeda JFC.
Risco ou realidade
O risco em investir em algo que não vai gerar o resultado es-
perado não deveria nem ser chamado de risco, mas sim de uma
realidade. Formas menos enxutas de trabalhar exigem muito mais
planejamento e controle na tentativa de mitigar tal risco. E, para
piorar, muitas vezes mascaram iniciativas que deram errado por
trás daquela que deu certo.
Aceitar a incerteza da iniciativa reduz a carga emocional e as
inúmeras horas e esforço gastos com planejamento e controles
da iniciativa. Se tal iniciativa recebeu uma nota alta, então não
devemos economizar esforços com ela.
Errado! Mesmo recebendo notas altas, ainda estamos no mundo das

hipóteses. E, somente com dados reais poderemos comprovar que
aquela iniciativa promissora gerou resultados promissores.
O MVP é para isso. Para algo que ainda não está definido. Para
ajudar a converter a hipótese em realidade. Para gerar dados
reais de uso. Para dar direcionamento ao negócio. Para colocar a
iniciativa a prova.
E antes de pensar em qual MVP testar, decidimos qual iniciativa
tem melhores chances (a tabela de priorização das iniciativas). Ou
seja, qual das incertezas são menos incertas? Qual hipótese parece
mais plausível? Onde devemos investir nossos esforços?
Outros modelos para
priorização
O modelo proposto apresenta uma forma efetiva de priorização
relativa, onde consideramos VALOR e ESFORÇO de cada iniciativa,
relativamente entre elas.
Mas existem outras formas de priorização. Segue abaixo algumas
outras formas de priorização que eu já em uso em algumas organi-
zações.
Priorização absoluta
Priorização absoluta é quando uma iniciativa é priorizada isolada-
mente, Independente das outras iniciativas. Isso acontece quando
a decisão sobre priorizar a iniciativa acontece baseado somente em
valores e parâmetros relacionados a própria iniciativa.
Por exemplo um business case detalhado (e muito bem analisado)
da iniciativa que demonstra ROI ou VPL para a iniciativa: “Segundo
os números do business case apresentado gastaremos um milhão em
um ano, para aumentarmos os lucros em 12% em dois anos, geando
um ROI de X”.
Priorização do Hipopótamo
Hipopótamo (Hippo em Inglês, ou do acrônimo Highest Paid People
Opinion) é aquela pessoa com maior salário.
Outros modelos para priorização 31
Brincadeira a parte, geralmente o maior salário reflete anos de

experiência, e tipicamente representa alguma posição de alto poder
na organização. Geralmente o HIPPO influencia a todos, e a sua
iniciativa é priorizada. Entretanto esta forma de priorização inibe a
conversa sobre outros aspectos, outras iniciativas, e outros profis-
sionais que não são HIPPO.
Priorização por decibéis

Reuniões de priorização podem ser longas, cansativas e estressan-
tes. Pior ainda, essas podem acontecer em ambientes de trabalho
nocivos, onde quem fala mais alto acaba decidindo. Esta é a
priorização por decibéis, onde a prioridade é definida por aquele
que fala (ou grita) mais alto.
Priorização The Flash

The Flash, aquele super-herói que corre mais rápido que os outros.
Por vezes organizações tem budget disponível, e aquele que chega
mais rápido terá sua iniciativa priorizada. Nesse caso o Flash acaba
ganhando a iniciativa, independente de como essa se compara com
as outras que não correram tão rápido para serem priorizadas.
Isso me remete aqueles programas de auditório que responde quem
bate em um botão mais rápido. Por vezes o candidato mais rápido
nem sabe a resposta, mas clicou primeiro e vai falar primeiro.
Infelizmente isso acontece em algumas organizações que dão início
a iniciativas por motivo similar: alguém foi mais rápido em apertar
um botão (ou responder um e-mail, enviar alguma planilha ou
plano). E somente algum tempo depois a organização irá perceber
o resultado dessa resposta rápida.
Outros modelos para priorização 32
Priorização rapa do tacho

Rapa do tacho, ou aquela sobra que fica no fundo do recipiente.
Isso acontece quando, próximo da virada do ano financeiro, alguém
percebe que ainda há dinheiro aprovado para ser usado.
Essa é a rapa do tacho. Vão levar o tacho, então é melhor rapá-
lo, pois aquela verba já estava aprovada. Geralmente isso está
relacionado a budgets previamente aprovados. E a organização
decide priorizar algo, não necessariamente por sua priorização
neste momento específico; mas por que a verba já está aprovada
e podemos gastá-la.
Funding
<texto em construção>
Evite o funding de iniciativa
Se possível não faça funding da iniciativa. Ao invés, faça funding

da equipe, do squad, da tribo, ou da UN; ou seja, faça o funding do
grupo responsável por uma (ou várias) iniciativas.
Projetos são aprovados, logo recebem funding. É assim que muitas
organizações trabalham. Mas este livro propõe uma mudança de
paradigma: de projetos para produtos.
Algumas organizações já entenderam esta mudança e estão dando
passos mais largos nessa direção. Outras organizações ainda estão
entendendo essas mudanças, e testando pequenos passos nessa
direção.
Mas, independentemente do apetite que a sua organização tem
para mudança, evite tratar a iniciativa como um projeto. Ao menos
na questão de funding. Pois a forma de tratar o funding pode
ser um grande impulsionador, ou bloqueador para a mudança de
paradigma.
Segue uma proposta para alocar e gerenciar o funding:.
Comesse com uma simples pergunta:
Olhando para indicadores do passado e do futuro

(lagging e leading indicators, em Inglês), o quanto sua
organização deve investir em cada UN?
Funding 34
Por exemplo, considere uma organização, com quatro UNs: UN A,

UN B, UN C e UN D, que tem R$100.000,00 a ser disponibilizado
como funding do próximo período (tipicamente anual ou trimestral,
dependendo da maturidade de Estratégia Lean da organização).
Dado os indicadores do passado e do futuro, decidimos distribuir
os fUndings desta forma:
• R$60.000,00 para a UN C
• R$20.000,00 para a UN B
• R$10.000,00 pata a UN A
• R$10.000,00 para a UN D
Com o funding de R$20.000,00, a UN B mantém três squads, logo as

três iniciativas com maiores notas serão encaminhadas para cada
um desses squads.
Este é um exemplo simplificado, mas que demonstra o relaciona-
mento entre funding, UN, squads e iniciativas.
Objetivos de negócio e funding

Segue uma forma de fazer o funding dos objetivos de negócio: des-
crevemos os objetivos de negócio, verificamos o quanto o business
case de um projeto está alinhado com nossos objetivos, e decidimos
o funding dos projetos, que são encaminhado para suas respectivas
UN.
Agora descrevo outra forma de fazer o funding dos objetivos de
negócio. Descrevemos os objetivos de negócio, decidimos os fun-
dings das UNs, verificamos a priorização relativa das iniciativas por
UN, e decidimos as iniciativas a começar, que são encaminhadas as
respectivas squads das UNs.
São similares, mas com uma diferença essencial: projetos versus
produtos.
Funding 35
Objetivos -> projetos -> aprovação -> funding
Ou
Objetivos -> iniciativas -> priorização relativa -> fun-

ding
Funding e os 3 Hs
O Funding deve refletir o horizonte de atuação da UN. Por exemplo
a UN A recebe um funding de 50000.
Isso significa que a UN ou gera mais de 50000, por isso tem este
funding logo sendo lucrativa, ou a UN gera menos que 50000 e está
recebendo investimento.
Uma UN que tipicamente opera em H2 e H3 recebe investimentos
para tanto. Já uma UN que opera em H1 não deveria receber mais
funding do que gera de receita.
Funding e capacidade de Negócio

<writing in progress>
Do
MVP – Produto Mínimo
Viável
< ainda vou adicionar texto e imagens neste capítulo >
O MVP fatia uma iniciativa em pedaços bem pequenos. Isso ajuda
de duas formas: (1) reduz o risco de insistir em uma iniciativa que
não se provou, ou seja, parecia uma boa iniciativa, mas que não
gerou bons resultados, e (2) maximiza o fluxo de trabalho.
MVP e o Fluxo de trabalho

Para te convencer que trabalhar com MVP, ou seja pequenos
pedaços de trabalho é melhor não somente pelo conceito de MVP,
mas também por ser tratar de pequenos batch sizes, eu vou te contar
a história do meu bar de uísque.
… <ainda estou decidindo se conto aqui a história sobre meu bar de
uísque. Esse história já está no capítulo do CFD, o qual estou em
dúvida de retiro deste livro >
Lean Inception
< capнtulo resumindo a lean inception. Importante ser breve pois
isso jб estб detalhado no livro direto ao ponto. Mas precisa ser muito
claro que o time de produto precisa compreender a iniciativa e criar
i plano para criaзгo do MVP. >
Construindo MVP com
Scrum
Dado que muitas equipes utilizam Scrum, vamos compartilhar
como temos combinado Scrum com a criação de MVPs. Para tanto,
vamos realizar uma introdução básico sobre o Scrum, e, em seguida
demostrar como encaixar Scum com MVP, features e histórias.
Scrum
Scrum é um framework ágil para a conclusão de projetos comple-
xos. Scrum foi inicialmente formalizado para projetos de desenvol-
vimento de software, mas tem sido aplicado para qualquer âmbito
de projetos complexos, e trabalhos inovadores.
O Scrum é especialmente adequado para projetos com requisitos
que mudam rapidamente ou são altamente emergentes.
A Equipe Scrum
Scrum fomenta uma equipe multi-funcional e auto-organizada.

A eficiência do time depende da capacidade dos membros traba-
lharem em conjunto, e fazer o melhor uso das habilidades dos
indivíduos. O time Scrum é auto-organizado pois não deve existir
um líder de equipe que decide quem vai fazer qual tarefa e como.
Tarefas e problemas são levantados por todos, e essas são questões
decididas pela equipe como um todo. Os times Scrum são apoiados
por dois papéis específicos: o Scrum Master e o Produt Owner (PO).
Construindo MVP com Scrum 40
Scrum Master
Scrum Master é alguém experiente com o framework Scrum que

pode ajudar o time a usar o processo para alcançar seus objetivos
de alto nível. Os melhores Scrum Masters são aquelas pessoas que
sentem mais satisfação de facilitar o sucesso dos outros do que
seus próprios. O Scrum Master deve se sentir confortável e seguro
com o framework a ponto de dar todo controle em relação ao
produto para o Product Owner (PO), e todo controle em relação
ao desenvolvimento a sua equipe.
Product Owner
O Product Owner (PO) representa o negócio, os clientes ou usuários,

e orienta a equipe para a construção do produto certo. O PO deve
liderar o esforço de desenvolvimento, através de esclarecimentos e
priorizações sobre o trabalho.
Tipicamente, o PO trabalha com o Product Backlog, a lista mestre
dos requisitos do produto a ser criado. É sua função priorizar o
backlog com base no valor do negócio, e no alinhamento entre as
partes interessadas, tanto internas quanto externas a equipe Scrum.
Como tal, o PO deve estar disponível para a equipe para responder
a perguntas e direcionar o time a cada momento ou indagação.
Esta combinação de autoridade e disponibilidade para a equipe de
desenvolvimento faz com que o PO seja peça chave do framework.
Scrum valoriza a auto-organização e autonomia do time; portanto,
o PO deve respeitar o direcionamento e a capacidade da equipe para
criar o seu próprio plano de ação.
A Sprint
Sprint é uma iteração, um ciclo de trabalho repetitivo no qual o time

Scrum passa por todas as cerimônias do Scrum: planning, review e
retrospectiva. O tamanho da Sprint é fixo e definido pelo time (ou
pela organização) ao começar a implantar Scrum. Duas semanas é

o tamanho de Sprint mais adotado por times de desenvolvimento
de Software.
Cerimônias da Sprint
A equipe Scrum – o Scrum Master, o PO e todos membros do

time (com suas variadas formações) – participam ativamente de
todas reuniões com um alto nível de autonomia, transparência e
comprometimento.
Cerimônias da Sprint
Na Sprint planning, a equipe decide o Sprint backlog, o qual é

acompanhado diariamente (Daily Scrum) e reavaliado na Sprint
review. Através da busca de melhoria continua (salientado nas
retrospectivas), tipicamente o time Scrum performa em níveis ele-
vados de rendimento. Muito disso é alcançado pelo entrosamento
do time, do alinhamento cadenciado via Sprints, e da clareza de
cada papel e reunião.
Daily Sprint
Reunião diária do Scrum, onde basicamente todos os membros

do time ficam de pé (para que a reunião não demore demais) e
respondem a três perguntas, as quais auxiliam o time a se auto-

organizar, buscando o alinhamento diário em relação ao trabalho
da Sprint. As três perguntas são: o que fiz ontem, o que vou fazer
hoje e o que está impedindo o progresso do meu trabalho.
Sprint Planning
Sprint Planning, ou reunião de planejamento do Scrum é uma

reunião de planejamento que acontece no início de cada Sprint. A
reunião de planejamento do Sprint é descrita em termos de metas
e resultado desejado. O resultado desejado é um compromisso com
um conjunto de funcionalidades a serem desenvolvidas no próximo
Sprint. Buscando assim o equilíbrio entre autonomia, flexibilidade
e comprometimento do time. Tal compromisso é revisitado ao final
da Sprint, na reunião de review.
Sprint Review
Reunião realizada ao final da Sprint com o objetivo de apresentar

o estado da arte do produto sendo criado, rever o progresso do
trabalho do time, e comparar com o planejamento apresentado na
Sprint planning.
Retrospectiva
A reunião de retrospectiva Scrum é um momento para a equipe re-

fletir sobre como estão trabalhando, e buscar maneiras de melhorar.
Tipicamente, o time Scrum realiza uma retrospectiva por Sprint.
O MVP nas cerimônias do scrum

Antes da reunião de planejamento, as próximas funcionalidades
devem ter sido analisadas em detalhe e detalhadas em histórias do
usuário.
O planejamento da Sprint
Durante a Sprint
Na reunião de revisão do sprint, a equipe scrum irá rever o trabalho

realizado durante o sprint. Neste momento, a equipe deve revisar
e atualizar tanto as histórias do sprint backlog, quanto as suas
respectivas funcionalidades no canvas MVP.
Revisão da Sprint
Com o canvas MVP atualizado, a equipe pode (e deve) verificar

quanto falta para terminar o MVP . E, se necessário, a equipe de
agir (ACT) para ou (1) alcançar, ou (2) realinhar as expectativas
de entrega do MVP. Tipicamente, as reuniões de retrospectiva
geram action items para o próximo Sprint. Assim que todas as
funcionalidades do MVP estiverem completas, o mesmo deve ser
disponibilizado para os usuários finais.
Construindo MVP com
Kanban
Dado que muitas equipes utilizam Kanban, vamos compartilhar
como temos combinado Kanban com a criação de MVPs. Para
tanto vamos realizar uma introdução básico sobre o Kanban, e, em
seguida demonstrar como encaixar Kanban com MVP, features e
histórias.
Kanban
Kanban é um método formulada por David J. Anderson⁷ para
gestão do fluxo de trabalho de um processo incremental e evolutivo.
Influenciado pelo modelo Toyota Just-In-Iime⁸, o método se baseia
em visualizar o fluxo de trabalho e, a partir disso, atuar no processo
para não sobrecarregar os membros da equipe.
Através de uma abordagem de gestão visual perante a cadeia de
valor, o processo, desde sua etapa inicial até a entrega do trabalho,
é exposto aos membros da equipe. Tipicamente a cadeia de valor é
representada em quadros brancos com post-it ou ferramentas on-
line. Processo, itens de trabalho, bem como os trabalhadores estão
visualmente representados nesses quadros, comumente chamados
de kanban boards, ou kanban (isso mesmo, o método e o nome do
quadro se confundem). A partir do kanban, fica mais fácil para a
equipe decidir o que, por quem, quando, e quanto produzir.
⁷Kanban: Successful Evolutionary Change for Your Technology Business by David Ander-
son, Blue Hole Press Inc (2013)
⁸Ohno, Taiichi. (1988) Toyota Production System. Productivity Press
Construindo MVP com Kanban 46
No desenvolvimento de software, normalmente uma pequena ta-

refa leva de horas à dias para ser concluída. Além disso, você
não consegue visualizar quantos requisitos estão atualmente em
análise; ou quantos requisitos estão atualmente sendo codificados
ou testados. O fato é que não conseguimos “ver” o item de trabalho
relacionado ao software, e como este se move ao longo das etapas
de do processo, até que esteja pronto. Aqui é onde tudo começa:
kanban torna tais itens em construções visíveis!
Visualize o workflow
A ideia principal do kanban é colocar o fluxo de trabalho na frente

de todos. Por exemplo em um quadro branco, ou na própria parede.
Abaixo está uma foto tirada de um kanban de uma equipe de
desenvolvimento de software.
Exemplo de kanban – o workflow visível
Cartões na parede. Simples assim. Cartões (ou post-it) na parede

mostrando o processo e o trabalho da equipe. Uma descrição rápida
do processo e trabalho deste time seria: um item de trabalho está
em etapa In Analysis, cinco itens estão na etapa de Ready For
Dev, três itens estão na etapa In Dev, um outro item está na etapa
Ready for BA, três itens estão na etapa Ready for QA, cinco itens
estão na etapa In QA, e oito itens estão em etapa de Ready for
SAT. Também parece que a equipe usa fotos para representar as

pessoas trabalhando nos itens. Os cartões têm um código de cores
(há três cores diferentes nos cartões na foto). Os cartões também
têm anotações escritas neles, um identificador numérico, e post-it
menores coloridos colados sobre eles.
Como a parede é uma superfície bidimensional, o kanban é apresen-
tado em um formato tabular, onde as etapas de trabalho são títulos
de colunas, e os items de trabalho, as fotos das pessoas, e outras
marcas relacionadas ao trabalho preenchem o espaço na parede.
Estes cartões podem ser organizados em uma linha horizontal ou
não. Tudo depende da equipe e como elas representam e organizam
o seu trabalho na parede.
Limite o WIP
Limitar o trabalho em andamento, ou WIP de work in progress

em Inglês, implica que o kanban segue um sistema puxado. O
trabalho em cada etapa do processo é limitado de forma que
um novo trabalho somente seja “puxado “ para a próxima etapa
quando há capacidade disponível dentro do limite WIP de tal etapa.
As restrições de WIP identificam gargalos e áreas problemáticas
no processo, auxiliando o time a tomar decisões para resolvê-
los. Limitar WIP é o grande diferencial do método Kanban. Tal
artimanha é o divisor de aguas entre task boards, ou quadros visuais
– como eram conhecidos antes da influencia de David Anderson
com a divulgação do método Kanban—e o quadros kanban.
ilustração de kanban com limites
Siga melhorando o fluxo de trabalho
Segundo David Anderson, o ponto principal de implantar um

kanban é criar uma mudança positiva. Antes de criar essa mudança
o time tem que saber o que mudar. O time precisa descobrir isso
olhando como itens de trabalho estão fluindo através do processo,
e analisando as áreas problemáticas em que o trabalho engargala.
Daí sim, realizar no mudanças no processo de trabalho para resolver
tais problemas.
E assim sucessivamente; identificando problemas, e agindo para
resolvê-los. Tudo isso baseado na visualização e limites WIP do
kanban. Melhorando o trabalho e o processo, na busca contínua
de maior eficiência.
O MVP no Kanban
Segue abaixo um sequenciador de features, exemplo de resultado
de uma inception DiretoAoPonto.
Sequenciador de Features
Note no sequenciador apresentado que o MVP 1 é composto pelas

features F1, F2, F3, F4, F5 e F6.
O fluxo de trabalho do MVP é simples. Para cada MVP, temos
as features a serem trabalhadas, as features em construção e as
features prontas. Isso representa o seguinte fluxo, no nível de funci-
onalidade: funcionalidade na fila -> funcionalidade em construção
-> funcionalidade pronta.
Uma vez que uma funcionalidade entra na etapa de funcionalidade
em construção, primeiro precisamos quebrar esta funcionalidade
em pedaços menores (histórias ou tarefas, dependendo do estilo da
equipe). Desta forma teremos um conjunto de itens de trabalho a
ser realizado para cada funcionalidade, e cada um desses itens passa
pelo seguinte fluxo: a fazer -> fazendo -> feito.
Visualizando o fluxo para MVP, features e

itens de trabalho
O fluxo de trabalho do MVP com suas features, e das features com

seus itens de trabalho é representado no kanban abaixo.
Kanban de Features do MVP
Note neste Kanban os dois níveis de trabalho: (1) features do MVP,

e (2) histórias (ou tarefas) de uma funcionalidade. Este kanban
demonstra o workflow de MVP e features, e o progresso de cada
funcionalidade perante o andamento das suas histórias (ou tarefas,
representados pela letra W na figura).
Sugiro manter o sequenciador de funcionalidade próximo ao kan-
ban de features do MVP. Desta forma, todos podem verificar onde
está cada MVP e cada funcionalidade. Se já estão em construção,
prontos, ou ainda esperam na fila.
O Sequenciador de Features, agora sem os cartões das features que foram para
o kanban
Segue uma sequência de imagens, demonstrando o Sequenciador

de features e o kanban, dia após dia.
Kanban no dia 1 – passo 1

Kanban no dia 2
Kanban no dia 3
Kanban no dia 4


Kanban no dia 6

Kanban no dia 8
Kanban no dia 9

funcionalidade WIP
O Kanban apresentado tem um limite de três features no WIP.

Isso está explicitado pela quantidade de linhas neste kanban. Estas
imagens representam um kanban utilizado por um time cross-fun-
cional, com 8 pessoas com perfis e capacitações de desenvolvedor,
testados, ops e UX (User eXperience).
Não é intuito deste livro discutir como decidir o limite WIP de um
kanban, mas somente ilustrar como implementas um kanban para
o MVP e suas features.
Arquitetura Mínima
Viável (MVA)
O MVP permite que a equipe de possa entregar um produto nas
mãos de usuários rapidamente, à um baixo custo. Quanto mais cedo
o produto for utilizado, mais se pode aprender com os usuários
para melhorá-lo. A melhor maneira de aprender e evoluir é ouvir
de usuários que utilizam o software, não de pessoas olhando para
uma folha de papel em branco tentando visualizar como um sistema
deve funcionar.
Um dos desafios que a abordagem MVP apresenta é de que ela
pode levar à falta de uma arquitetura. Quando construindo um
produto do zero, a pressa para entregá-lo pode vir ao custo de uma
arquitetura sustentável. Deve haver balanço entre velocidade de
entrega e qualidade. É necessária uma arquitetura mínima viável⁹.
Então, como definimos qual o MVA? Recomendamos realizar per-
guntas como estas:
• Quantos usuários utilizarão o sistema no lançamento inicial?

Nos primeiros 6 meses? Dentro de um ano?
• Os usuários iniciais serão internos, externos, ou ambos?
• Quantas transações por segundo esperamos no lançamento?
Nos primeiros 6 meses? Dentro de um ano?
• Como os usuários começarão a utilizar o sistema?
• Qual o nível de segurança e auditabilidade exigido no lança-
mento? Dentro de 6 meses? Dentro de um ano?
Há diversas outras perguntas para guiar a discussão. Estas pergun-

tas ajudam a equipe a definir os requisitos básicos para lançar no
⁹Arquitetura Minima Viável (MVA) blog post por Paulo Caroli; Disponível em
http://www.caroli.org/arquitetura-minima-viavel-mva/ ; Acesso em Agosto de 2018
Arquitetura Mínima Viável (MVA) 61
mercado. Embora não entre no mérito de definir uma arquitetura

completa e perfeita para o produto final, isto é diferente de ignorar
a definição de uma boa arquitetura. O foco é no quanto de inves-
timento é necessário para lançar e, em seguida, definir um plano
para evoluir a arquitetura conforme o número de usuários aumenta
e requisitos são adicionados.
Tentar construir o produto perfeito raramente é a abordagem
correta. Vamos dizer que a resposta do dono do produto para estas
perguntas sejam as seguintes:
• Haverá apenas cinco usuários internos nos primeiros três

meses. Seis meses a partir de agora os nossos dois primeiros
clientes externos estarão usando os sistemas em modo piloto.
Um ano a partir de agora lançaremos o sistema para todos os
clientes.
• No lançamento haverá uma quantidade trivial de transações.
Daqui a seis meses o tráfego será moderado. No próximo ano,
o tráfego será extremo.
• Inicialmente, adicionaremos usuários ao sistema através de
uma interface. No futuro, os clientes terão gestão de ID self-
service. Espero que isto aconteça em um ano a partir de agora.
• Nós só precisamos de segurança mínima para a primeira ver-
são. Para o piloto, precisamos de segurança e audit completos.
Com base nessas respostas, muita discussão e definição pode ser

adiada para após o lançamento da primeira versão. Por que gastar
tempo na estratégia de cache agora, quando não vemos a necessi-
dade no horizonte de um ano? Nós podemos colocar fora diversas
tarefas de gerenciamento de ID para mais tarde também. Deve-se
evitar discussões imediatas sobre requisitos que só virão no futuro,
de forma que seja implementado apenas o estritamente necessário
da melhor forma possível. É por isso que o MVA é tão importante.
Esta abordagem depende da disciplina e confiança entre o dono
do produto e da equipe de desenvolvimento, para garantir que
Arquitetura Mínima Viável (MVA) 62
ambas obtenham os resultados desejados: o produto é entregue

rapidamente com um sistema bem arquitetado e com pouca dívida
técnica.
Micro-serviços de Domínio
A abordagem de micro-serviços é um estilo de desenvolvimento no
qual uma aplicação é composta de uma série de pequenos serviços,
cada um rodando em seu próprio processo e se comunicando
através de mecanismos leves (geralmente uma API HTTP). Estes
serviços são construídos em torno de requisitos de negócio, e
devem ser capazes de ir à produção independentemente e de forma
automatizada.
Uma abordagem para definir o escopo de um micro-serviço é
analisar qual a funcionalidade de negócio que ele se propõe a dispo-
nibilizar, e como este serviço se relaciona com outros. Mapeamento
de contexto é uma ferramenta em Domain Driven Design que
auxilia na identificação de diferentes contextos e seus limites. Um
contexto encapsula os detalhes daquele domínio, como o modelo e
os dados, e define os pontos de integração com outros contextos.
Desta forma, há uma relação direta em DDD e mapeamento de
contexto com a definição de micro-serviços, que devem possuir
interfaces bem definidas e se limitarem à uma certa quantidade de
funcionalidades de negócio.
Embora micro-serviços adicionem complexidade operacional para
serem mantidos, eles provêm uma arquitetura forte e flexível, na
qual diferentes contextos têm limites bem definidos e podem ser
implementados da maneira como for mais adequado (com quais
tecnologias e estratégias forem apropriadas).
Acompanhamento Lean
Nesta fase, devemos acompanhar a criação e a evolução das inicia-
tivas segundo o plano de entrega dos MVPs.
MVP, ou Minimum Viable Product em Inglês, é a linguagem comum
entre as quatro etapas do Lean Strategy (PLAN / DO/ CHECK /
ACT). O conceito de MVP é baseado no livro The Lean Startup:
How Today’s Entrepreneurs Use Continuous Innovation to Create
Radically Successful Businesses do Eric Ries ¹⁰.
O entendimento da iniciativa via

MVP
O workshop Lean Inception¹¹ gerou o sequenciador de features, no
qual está mapeado o que o time estará construindo para a entrega
dos incrementos do produto enxuto, baseado nos MVPs.
¹⁰Ries, Eric. (2011) The Lean Startup: How Today’s Entrepreneurs Use Continuous Innova-
tion to Create Radically Successful Businesses. Crown Publishing.
¹¹CAROLI, Paulo. Lean Inception: How to Align People and Build the Right Product, Editora
Caroli, 2017.
Acompanhamento Lean 64
exemplo de evolução de produto de forma enxuta
O planejamento do produto e seus

MVPs
Para cada MVP identificado no sequenciador de funcionalidade é
criado um canvas MVP, o qual responde claramente as indagações
de dois aspectos fundamentais sobre produto e MVP: (1) o que são
as funcionalidades, as personas, as jornadas, a proposta, o custo
e cronograma de entrega do MVP, e (2) que resultado é esperado
quando esse for entregue, e como validaremos tal resultado e
aprendizado.
o canvas MVP
O Canvas MVP é dividido em sete blocos:
1. Proposta do MVP – Qual é a proposta deste MVP?

2. Personas segmentadas – Para quem é esse MVP? Podemos
segmentar e testar este MVP em um grupo menor?
3. Jornadas – Quais jornadas são atendidas ou melhoradas com
este MVP?
4. Funcionalidades – O que vamos construir neste MVP? Que
ações serão simplificadas ou melhoradas neste MVP?
5. Resultado esperado – Que aprendizado ou resultado estamos
buscando neste MVP?
6. Métricas para validar as hipóteses do negócio – Como pode-
mos medir os resultados deste MVP?
7. Custo & Cronograma – Qual é o custo e a data prevista para
a entrega deste MVP?
O planejamento baseado em MVPs difere de planejamento tradi-

cional de produtos por aceitar que a entrega somente sinaliza o
momento em que dados de aprendizado começarão a ser coletados.
Exemplo de Canvas MVP – o MVP1 do EasyBola
Com uma visão mais tradicional, o acompanhamento verifica o

quão próximo estamos de completar a construção das funciona-
lidades de tal MVP. Enquanto, com uma visão mais moderna,
o acompanhamento é baseado no aprendizado, na validação de
hipóteses do negócio, em um estilo mais arrojado, digno das start-
ups do Vale do Silício.
Misturando construção com adaptação, convergência com diver-
gência, controle com experimentação, o planejamento baseado no
Canvas MVP auxilia a criação de produtos enxutos equilibrando
inovação e entrega.
O acompanhamento da criação do
produto via MVP
Devemos fazer o acompanhamento periódico (por exemplo sema-
nal) em relação a criação do produto. Tal acompanhamento deve ser
realizado comparando o estado atual com o que estava planejado

no canvas MVP. Para tanto artefatos devem ser apresentados:
1. Status report do MVP

2. Burn up do MVP em construção
Status report do MVP
modelo de status report do MVP
Uma lista pequena com poucas e visíveis informações. Assim deve

ser um status report efetivo. Por se tratar de features de um MVP,
tal status report não somente é possível, como indicado!
Um status report simples auxilia no entendimento comum sobre
o andamento da criação do MVP. Informações simples e diretas:
Qual nome e o que compõe este MVP? Qual data prevista? Quantas
features já terminaram?
Burn up do MVP em construção
o burn-up de MVP
O Burn-up de funcionalidades do MVP ajuda com o gerenciamento

de tempo e escopo de um MVP. Ter o gráfico burn-up visível para
todos constrói a confiança na gestão do tempo e no progresso das
funcionalidades do MVP.
Ao final do planejamento, o gráfico burn-up demonstra a visão
compartilhada do que deve ser alcançado. E isto fica claramente
visível traçando uma linha horizontal de escopo e uma linha
vertical de data de entrega do MVP. A interseção dessas linhas
representa o resultado no tempo esperado.
O gráfico é atualizado conforme as funcionalidades são construídas:
a data atual, e o total de funcionalidades completas são alterados.
Desta forma permite-se identificar possíveis desvios na duração
esperada para a construção do MVP.
Burn-up de Features do
MVP
O Burn-up de Features do MVP ajuda com o gerenciamento de
tempo e escopo de um MVP. Ter o gráfico burn-up visível para
todos constrói a confiança na gestão do tempo e no progresso das
features do MVP. É uma ferramenta essencial para dar visibilidade
ao planejamento e para realizar o acompanhamento da construção
das features do MVP.
A sequência de imagens mostra um exemplo de burn-up em mo-
mentos diferentes. Começando no dia 30/06, quando o burn-up foi
criado com o planejamento de acordo com o ritmo esperado de
construção das features. Seguindo com instantâneos do burn-up
nos dias 08/07, 18/07 e 28/07, quando todas as features do MVP
terminaram, e o mesmo foi entregue.
burn-up de features do MVP no dia 30/06

Burn-up de Features do MVP 70

Os eixos do burn up
O eixo vertical é a quantidade de features para o MVP, e é medido
em unidades, por exemplo 9 features. O eixo horizontal representa
o tempo, normalmente medido em dias ou semanas.
exemplo de burn-up de MVP iniciado em 30/06 e planejado para 30/07
O ritmo da construção do MVP

A vantagem da gráfico burn-up é a visão compartilhada do que deve
ser alcançado. E isto fica claramente visível traçando uma linha
horizontal de escopo e uma linha vertical de data de entrega do
MVP. A intersecção dessas linhas representa o resultado no tempo
esperado.
Ao desenhar uma linha diagonal a partir do ponto de partida (o
início do tempo para a construção da primeira funcionalidade do
MVP) para o resultado no tempo esperado, você tem uma indicação
do ritmo linear de construção do MVP. Na figura abaixo, este
ritmo está representado como a linha diagonal , representando um
planejamento de ritmo linear.
exemplo de burn-up com ritmo linear
Entretanto o ritmo de término de features de um MVP não é linear.

A figura abaixo demonstra uma curva que melhor representa o
ritmo de entrega esperado.
exemplo de burn-up com ritmo não linear
Equipes ágeis experientes lidam com tal curva de duas formas: (1)
Iteração ou Sprint 0, ou (2) entendimento do tempo de atravessa-
mento inicial.
Iteração ou Sprint 0 é um termo comum utilizado para ressaltar
que não haverá entrega de funcionalidade numa primeira iteração
ou Sprint. O gráfico abaixo demonstra como tal artimanha (Sprint
0) alinha a expectativa de entrega de funcionalidade com o ritmo
inicial ainda por começar.
exemplo de burn-up com Sprint 0
A construção de uma funcionalidade tem um tempo mínimo de

atravessamento (ou lead time, em inglês). Por exemplo, o mínimo
que se leva para criar uma funcionalidade são 5 dias. Por tal
motivo é impossível ter o término de qualquer funcionalidade nos
primeiros cinco dias. Esse fato explica a barriga da curva do ritmo
esperado. Após a entrega das primeiras funcionalidades, o ritmo de
entrega vai ser estabelecido, e a curva tende a virar uma reta na
qual o ritmo de entrega fica estabelecido.
Verificando o progresso
De tempos em tempos você deve verificar a quantidade de features
já construídas e a quantidade total de features planejadas para o
MVP. A distância entre as linhas horizontais marcando as features
atualmente prontas e a última funcionalidade a ser construída é a
indicação da quantidade de features restantes.
features construídas e restantes
Quando as duas linhas se encontram, todas features do MVP estarão

completas. A distância entre essas linhas é uma medida poderosa
de quão perto você está de completar o MVP.
verificando progresso
Verificar regularmente o progresso é uma parte importante da

gestão da construção do MVP. Há duas atualizações básicos para
o burn-up de features do MVP: (1) o tempo mudou; a seta que
representa a data atual deve ser movido para a direita até a posição
que representa a data atual, e a linha da data atual deve ser ajustada;
e (2) terminou a construção de uma funcionalidade; o total de
features completas deve ser alterado, e a linha de total de features
completas deve ser ajustada.
atualizações no burn-up: data atual e funcionalidade construída
Este mecanismo de atualizações do total de features construídas e

da data atual permite identificar de imediato, um desvio na duração
esperada para a construção do MVP. Assim que constatado, este
problema deve ser discutido e ações corretivas devem ser tomadas
ainda em um estágio inicial, e não quando é tarde demais.
A linha de escopo do MVP

Uma informação importante do gráfico burn-up é a linha de escopo
do MVP, a linha horizontal contabilizando o total de features plane-
jadas para o MVP. Essa linha define claramente se e quando novas
features foram adicionados ou removidos durante a construção
do MVP. Ela também permite que você visualize a intersecção
desta linha horizontal para a linha vertical, que representa a data
planejada para a entrega do MVP.
Todas partes a serem construídas para um MVP devem ser features.
Se novas features surgem, elas devem ser adicionados à lista de
features e a linha de escopo deve ser ajustada. Dessa forma, a
nova linha permite identificar facilmente quando features estão
sendo adicionadas, o que poderá afetar o tempo de conclusão do
MVP. O ato de adicionar uma nova funcionalidade é um sinal
importante de que o tempo restante para a construção do MVP deve
ser repensado. A linha de escopo também rastreia onde features

estão sendo removidos para cumprir um prazo fixo. Este cenário
é ilustrado na figura abaixo. Novamente, é importante entender
como a remoção de uma funcionalidade do MVP vai afetar as outras
features, e é algo que precisa e deve ser claramente discutido com
todos.
exemplo de burn-up de MVP após redução de duas features

Status report do MVP
Segue um modelo de status report para acompanhamento e moni-
toramento da criação das features do MVP.
modelo de status report de MVP
Neste modelo você pode verificar as seguintes partes, listadas na

figura abaixo.;
modelo de status report de MVP – todos itens

Status report do MVP 78
Nome do time e ID do MVP

O nome do time a identificador do MVP.
Nome do MVP
O nome do MVP é utilizado dentre várias conversas, desde a sua
concepção, passando pela criação, até a entrega, coleta de feedbacks
e validações de hipóteses. Ter um nome claro e específico é essencial
para evitar quaisquer confusão sobre o MVP em questão.
Estado atual (verde / amarelo /

vermelho)
Qual situação atual deste MVP? Tudo ok para o término das features
do MVP na data prevista? Sim (verde), médio (amarelo), ou não
(vermelho).
Data atual e data prevista

Os relatórios de status report de MVP são úteis para o acompa-
nhamento e decisões atuais, bem como para o histórico da criação
do produto como um todo. Além disso a demonstração de ambas
as datas (atual e prevista) deixa claro o tempo remanescente para
alcançar a entrega na data planejada.
Lista de features do MVP

Uma tabela contendo a lista de features prevista para o MVP, com
as seguintes informações para cada funcionalidade: descrição, nível
de incerteza, estado, e % de completude.
Nível de incerteza da
funcionalidade(verde / amarelo /
vermelho)
Descrição e nível de incerteza da funcionalidade são dados pro-
venientes desde a concepção dos MVPs. O nível de incerteza da
funcionalidade refere-se ao grau em que a funcionalidade é incerta,
a partir do ponto de vista do entendimento de negócio e do
entendimento técnico. Isso é indicado pela cor os quais são verde,
amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza,
respectivamente.
O nível de incerteza da funcionalidade não é alterado. Tal infor-
mação serve para relembrar a todos o entendimento original sobre
tal funcionalidade. Todos e quaisquer riscos ou ações relacionadas
ao MVP devem ser listadas nos campos de detalhamento e texto
descritivo do status report (item 8 abaixo).
Estado e % de completude da
funcionalidade
O estado e % de completude da funcionalidade representam o
estado atual da funcionalidade em relação a sua completude. Esses
parâmetros devem ser alterados nos relatórios, refletindo o estado
atual de cada funcionalidade.
O estado varia entre: não começou -> em construção -> pronto.

O % de completude varia entre 0 e 100%. É comum que times deci-
dam valores arredondados e pré-definidos como 0%, 25%, 50% 75%
e 100%. Alguns times utilizam fórmulas para calcular tais valores,
enquanto outros decidem tais valores com menos matemática. O
importante é que o racional do valor demonstrado seja o mesmo
entre diferentes features.
Detalhamento e texto descritivo

Todas e quaisquer anotações relevantes sobre o MVP e suas fun-
cionalidade que não foram claramente demonstradas nos itens
anteriores. Por exemplo: dependências externas, riscos, problemas,
e ações realizadas.
Check
Métricas
Métricas é um tema tão importante que dediquei 5 capítulos no
meu livro de Gestão de Produtos e mais 6 capítulo no livro Guia da
Startup. Claro que não vou trazer todo o conteúdo que está lá para
cá. Por isso vou seguir o conselho do Paulo e vou buscar ir direto
ao ponto.
Além de conversar com seus usuários e ouvir seu feedback, uma
forma obrigatória de conhecer seu produto e como seus usuários
interagem com ele é por meio dos dados que seu produto gera. Para
poder tirar proveito desses dados, você deverá se transformar em
um data geek, uma pessoa que conhece profundamente os dados
gerados pela sua aplicação e seus significados.
Toda nota de dólar americano tem escrita a frase In God We Trust
(Em Deus Nós Confiamos). É tão grande a importância de usar
os dados como fonte de informação para entendermos melhor as
coisas, que acabou sendo criado o bordão In Data We Trust, ou seja,
“Nos Dados Nós Confiamos”.
William Edwards Deming é um engenheiro, estatístico e professor
americano bastante conhecido pelo seu trabalho no Japão, logo após
a II Guerra Mundial, onde ele ensinou sobre gestão estatística da
qualidade, e ajudou os japoneses a se transformarem em 10 anos na
segunda maior economia do mundo. A ele, é creditada a frase:
“Em Deus nós acreditamos. Todos os outros devem trazer dados.” –
W. E. Deming
Quais dados são importantes?
Todos os dados são importantes, mas, dependendo do que você

está querendo entender, uns são mais importantes do que outros.
Métricas 83
Conhecer seus dados é uma tarefa contínua, pois a cada novo

conhecimento que você adquire, aparecem novas questões, que vão
precisar de mais dados para serem respondidas.
Uma das primeiras informações que você vai querer conhecer é
quantas visitas você recebe no site de seu produto. Para conhecer
esses números, você pode usar algum relatório de estatísticas que
o provedor de hospedagem oferece. Outra opção muita usada é o
Google Analytics.
Com um relatório como esse, você consegue algumas informa-
ções importantes, tais como: quantidade de visitas, quantidade de
visitantes únicos, quantidade páginas vistas (pageviews) e várias
outras. Dependendo do sistema de estatísticas que você estiver
usando, você também conseguirá ver: qual a primeira e a última
página visitadas durante um acesso ao seu site; de onde (que país e
cidade) vêm seus visitantes; se eles acessaram seu site partindo de
uma campanha de Google AdWords, do Facebook, ou de alguma
outra campanha online que você está fazendo; ou se acharam
seu site de forma orgânica, digitando diretamente o endereço; ou
buscando por algo em algum sistema de busca. Vale lembrar que é
importante ter esses relatórios de acesso não só para o seu site como
também para seu produto software.
Cuidado, pois esses sistemas de relatório de visitas normalmente
dão uma quantidade muito grande de informação, e é fácil se perder
nesse mar de dados.
Engajamento
É muito importante encontrar métricas para medir o engajamento.

Por exemplo, em um produto de disparo de e-mail marketing,
algumas métricas de engajamento e uso são quantas vezes por dia
a pessoa acessa, quantas campanhas o usuário dispara por mês,
quantas vezes foi aberta a campanha disparada, quantas vezes
essa campanha foi clicada, quantas mensagens foram disparadas
Métricas 84
com endereço de e-mail incorreto e quantas mensagens geraram

reclamações.
Repare que cada produto tem métricas de engajamento e de uso
diferentes. Cada gestor de produtos deve pensar em que métricas
acompanhar em seu produto. Eventualmente, algumas métricas vão
gerar demandas de desenvolvimento, pois elas podem não estar
sendo medidas e precisam de alguma modificação no produto para
passarem a ser.
Você já parou para pensar quantas vezes por dia você usa o
seu celular? O que você costuma fazer ao acessar seu celular?
WhatsApp? Facebook? Instagram? Dá para se dizer que você está
bastante engajado com essas aplicações?
Fomentar o engajamento deve ser uma das preocupações do gestor
de produtos. Em 2013, foi lançado um livro chamado Hooked: How
to Build Habit-Forming Products, de Nir Eyal, no qual ele explica
a teoria por trás desses produtos que acabam entrando no nosso
cotidiano. É um ótimo livro para entender mais sobre esse tema.
NPS (Net Promoter Score), a métrica da

lealdade
Existem várias maneiras de se medir a satisfação de clientes. Eu

gosto bastante de uma métrica chamada NPS (Net Promoter Score,
ou Índice Líquido de Promotores). Essa métrica surgiu pela primeira
vez em 2003, em um artigo da Harvard Business Review, escrito por
Fred Reichheld, consultor da Bain & Company, renomada empresa
de consultoria americana. Em 2006, Reichheld publicou um livro
chamado A pergunta definitiva (em inglês, The Ultimate Question),
que teve uma segunda edição publicada em 2011, com as lições
aprendidas ao longo dos anos.
O NPS é calculado com base em uma única pergunta que você deve
fazer ao seu cliente:
Métricas 85
NPS
Em uma escala de 0 a 10, quão provavelmente você nos
indicaria para um amigo ou colega?
Zero significa de jeito nenhum, e 10 significa com toda certeza. As

pessoas que deram respostas de zero a 6 devem ser classificadas
como detratores; as que deram 7 ou 8 devem ser classificadas como
neutras; e as que deram 9 ou 10 são promotores.
O cálculo do NPS é bastante simples, basta subtrair o percentual
de detratores do percentual de promotores. Com isso, temos um
número que varia de -100% até 100%. Um número negativo significa
que você tem mais detratores do que promotores, e um número
positivo significa o contrário, que você tem mais promotores do
que detratores.
NPS {w=90%}
Claro que é melhor ter mais promotores do que detratores, prin-

cipalmente se pensarmos no efeito de marketing boca a boca que
tanto detratores quanto promotores podem gerar. Além de falar
bem de sua empresa e seus serviços para os amigos, os promotores
compram mais e são clientes por mais tempo. Isto é, têm lifetime,
e sempre lhe darão ideias e sugestões bastante pertinentes ao seu
negócio.
Métricas 86
Várias empresas usam o NPS para medir a satisfação e a lealdade

de seus clientes. Dentre elas estão Apple, Zappos, Rackspace, Mi-
crosoft, Intuit e Facebook.
Quando medir NPS? Uma vez por ano? Todo trimestre? Todo mês?
Toda semana? A recomendação do livro é medir NPS todos os dias,
de forma contínua. Isso pode ser feito da seguinte forma: todos os
dias você faz a pergunta do NPS para os clientes que estão fazendo
aniversário de X meses ou X anos naquele dia.
Por exemplo, você pode perguntar para seus clientes quando fize-
rem 1 mês desde que se tornaram seus clientes, aí você pode pegar
algum problema de on-boarding. Você também pode perguntar
para seus clientes com 6 meses de casa e, a partir daí, para todo
aniversário de 1 ano do cliente com sua empresa. Você, então,
poderá tirar relatórios de NPS por tempo em que o cliente está com
você, e assim você saberá se está tratando bem tanto o novo cliente
quanto aquele de muito tempo de casa. Para ver como seu NPS está
evoluindo, você tira a média móvel dos últimos 30 dias.
Fechando o loop: da informação a ação
O grande problema é que um número não resolve muita coisa.

Precisamos saber por onde melhorar, o que fazer para que os pro-
motores continuem promovendo nossa empresa e nossos serviços,
e o que motivou os detratores a nos darem a nota baixa. Para obter
essas informações, Fred Reichheld recomenda adicionar mais uma
pergunta à pesquisa:
A segunda pergunta
Qual a principal razão para você nos dar essa nota?
Pronto, com essa resposta você tem o que precisa para ir da

informação para a ação. Ao ler os comentários dos promotores, você
vai entender o que os motivou a dar uma nota alta e manter essas
Métricas 87
ações. Com os comentários das notas baixas, você terá o primeiro

insumo para começar a agir. É muito importante conversar com os
detratores para ouvir mais detalhes sobre suas insatisfações.
A partir do momento em que eles virem que você se importa, a
percepção deles sobre sua empresa já começará a melhorar. Buscar
entender a motivação dos detratores e agir para solucionar os
problemas que geraram sua insatisfação é o único caminho seguro
para aumentar o NPS e, consequentemente, a lealdade de seus
clientes.
Talvez você esteja se perguntando quando deve ser dado esse
feedback. A resposta é bem simples e direta: quanto mais rápido,
melhor. No livro, Fred Reichheld recomenda que se entre em
contato com os detratores em, no máximo, 48 horas. A rapidez é
importante para mostrar que você lê e se importa com o feedback
de seu cliente.
Testes A/B
Você já deve ter ouvido falar dos famosos testes A/B, não? São testes
nos quais colocamos duas ou mais versões de algum determinado
elemento de nosso produto web para ver qual deles dá melhor
resultado em algum determinado indicador do funil de conversão.
Por exemplo, é melhor ter um botão ou um link para chamar o
visitante do seu site a criar um usuário, ou o visitante de uma loja
virtual a comprar um item? Qual a cor de botão que converte mais?
Devo ter um vídeo explicando meu produto web, ou melhor ter uma
foto ilustrativa?
Para responder a essas e inúmeras outras perguntas existe o teste
A/B. Você pode fazer testes A/B sequenciais, ou seja, durante
algumas horas ou dias você usa uma versão e depois publica outra
versão por mais algumas horas ou dias e compara os resultados. Só
tenha cuidado para não fazer esses testes em horários ou dias com
perfil de uso muito distinto, por exemplo, testar uma página durante
Métricas 88
4 dias e outra nos 4 dias seguintes, pois aí você certamente estará

comparando um período com fim de semana, quando normalmente
o perfil de uso de qualquer produto web tende a mudar, com outro
sem fim de semana. Procure comparar um dia útil com outro dia
útil, ou uma semana com outra semana.
Para evitar esse tipo de problema, você pode fazer testes A/B
simultâneos, ou seja, você pode apresentar de forma aleatória para
50% de seus visitantes uma versão da página que você quer testar
e para os outros 50% outra versão. Você pode até fazer testes com
mais de duas versões, caso você queira testar mais hipóteses. Só que,
para fazer isso, você vai precisar de ferramentas para lhe ajudar.
Existem duas ótimas ferramentas para fazer testes A/B, o Visual
Website Optimizer (http://visualwebsiteoptimizer.com) e o Optimi-
zely (http://optimizely.com). Usei o serviço Visual Website Optimi-
zer, que oferece um mês grátis, para testar algumas hipóteses sobre
a home do ContaCal:
Home original do ContaCal
Em menos de 30 minutos, consegui criar 4 variações e comecei a

rodar o teste. Resolvi testar duas coisas. Uma era se a cor do botão
“criar conta” faz diferença na quantidade de pessoas que clicam
nele:
Métricas 89
Variação com botão verde
Variação com botão vermelho
E a outra era se, mudando o vídeo explicativo para uma foto

ilustrativa, aumentava ou diminuía a quantidade de pessoas que
clicam no botão “criar conta”:
Métricas 90
Variação com foto de mulher magra
Variação com foto de família preparando refeição saudável {w=95%}
O resultado foi:
Resultado do teste A/B na home do ContaCal
Ao ver esse resultado, fiquei com a impressão de que, se eu colocasse

botão verde com a imagem da família saudável, eu iria aumentar
Métricas 91
mais ainda a conversão. Resolvi, então, fazer esse teste e o resultado

foi:
Resultado do teste A/B na home do ContaCal com foto de família saudável
Por isso, tome cuidado, as aparências enganam! Faça experiências

antes de tirar conclusões!
Analysis paralysis
Por fim, além desses cuidados, é preciso tomar cuidado com o efeito
analysis paralysis, isto é, ficar o tempo todo analisando dados e não
tomar nenhuma ação. Como bem ilustrado pela figura do xkcd.com
(2014), a analysis paralysis pode custar bem caro:
Métricas 92
Fonte: Efficiency, por Randall Munroe, em https://xkcd.com/1445 {w=70%}
Concluindo
As métricas não são a razão da existência de seu produto. Os

usuários de seu produto, os problemas que ele resolve para esses
usuários e os objetivos estratégicos da empresa que é dona do
software são as razões de sua existência. Métricas são um meio,
e não o fim, o resultado e o objetivo. Por isso, use-as como mais
uma das ferramentas que você tem à sua disposição para ajudá-lo
a guiar seu produto na direção certa.
Act
Objetivos e Resultados
Chaves - OKR
O OKR, Objectives and Key Results em Inglês, ou objetivos e
resultados chaves em Português, é uma estrutura de definição de
metas criada pela Intel nos anos 70 que é utilizada com muito
sucesso pelos VCs do Vale do Silício, portanto, adotada em grandes
empresas como Google¹², Oracle, Twitter, LinkedIn e Dropbox.
Atualmente, os OKRs estão sendo aplicados em todo o mundo desde
startups até grandes organizações.
A ideia principal dos OKRs é que a organização defina um conjunto
de objetivos em cascata. Por exemplo, OKRs devem ser definidos
primeiramente para a organização. Em seguida, OKRs são definidos
para os departamentos e unidades de negócios, e, depois, para as
equipes. E assim por diante, em cascata até atingir os indivíduos,
configurando seus próprios OKRs. Cada entidade (organização,
departamento … individuo) deve ter 4-6 Objetivos e até 5 Resultados
Chave por objetivo.
O seguinte é um modelo para OKR compartilhado por Felipe Castro
¹³:
Nós vamos (Objetivo), conforme medido por (este con-

junto de Resultados Chave).
Felipe então explica que um OKR tem dois componentes, o Objetivo

(o que queremos alcançar e um conjunto de resultados chave (como
sabemos se estamos chegando lá).
¹²Business Insider article about OKRs at Google; http://www.businessinsider.com/googles-
ranking-system-okr-2014-1
¹³Felipe Castro´s article: An introduction to OKR; https://medium.com/the-alignment-
shop/introduction-to-okr-9912085830f0
Objetivos e Resultados Chaves - OKR 95
O objetivo pode ser qualitativo, enquanto os resultados chave de-

vem ser quantitativos. O objetivo define uma meta por um período
de tempo definido, geralmente um trimestre. Os resultados chave
indicam se o objetivo foi atingido até o final do tempo.
Abaixo estão alguns exemplos de OKR segundo alguns artigos e
autores:
OKR - Exemplo 1
Exemplo do artigo BreateHR: Como o Silicon Valley atinge seus
objetivos¹⁴.
Objetivo: Aumentar as vendas diretas em 10% no quarto trimestre
Resultados Chave:
• Introduzir novo método de rastreamento de vendas.

• Realizar o treinamento da equipe no tratamento de objeção.
• Aumentar as vendas repetidas no site em 10%.
OKR - Exemplo 2
Exemplo do artigo de Felipe Castro: uma introdução ao OKR ¹⁵:.
Objetivo: Impressionar nossos clientes
Resultados Chave:
• Visitas recorrentes: média de 3,3 visitas por semana por

usuário ativo.
• Alcançar uma classificação de NPS de 90%.
• Tráfego não pago (orgânico) de 80%.
• Envolvimento: 75% dos usuários completam seus dados de
perfil.
¹⁴breateHR´s article: How Silicon Valley hits its targets; https://breathehr.com/blog/
¹⁵Felipe Castro´s article: An introduction to OKR; https://medium.com/the-alignment-
shop/introduction-to-okr-9912085830f0
OKR - Exemplo 3
Exemplo do artigo de Scott Allison: OKRs - objetivos e resultados
principais¹⁶.
Objetivo: aumentar as vendas em 25% no próximo trimestre
Resultados Chave:
• Contratar 2 novos funcionários para a área de vendas.

• Criar novo guia de apoio a vendas.
• Aumentar a taxa de conversão nas visitas ao site em 10%.
OKR - Exemplo 4
Exemplo do artigo de Christina Wodtke: The Art of the OKR¹⁷.
Objetivo: Lançar um MVP impressionante.
Resultados Chave:
• 40% dos usuários retornam 2X em uma semana

• Pontuação de recomendação de 8
• 15% de conversão
OKR - Exemplo 5
Exemplo do artigo da Emily Bonnie na Wrike.com: se você não
estiver usando OKRs para planejamento trimestral, pare e leia
isso¹⁸.
Objetivo: aumentar o reconhecimento e a consciência da marca
Resultados Chave:
¹⁶Scott Allison´s article: OKRs – objectives and key results
¹⁷Wodtke Christina Wodtke´s article: The Art of the OKR; http://eleganthack.com/the-art-
of-the-okr/
¹⁸Emily Bonnie article: If You’re Not Using OKRs for Quarterly Planning, Stop and Read
This; https://www.wrike.com/blog/okrs-quarterly-planning/
• Aumentar o envolvimento de mídia em 20%.

• Lançar o programa de referência do cliente até 1º de setembro.
• Estender o alcance e a visibilidade das mídias sociais para 2
novos mercados-alvo.
• Expandir o programa de liderança de pensamento ao colocar
artigos de convidados em 4 sites relacionados à indústria com
um ranking de Alexa de pelo menos 30.000.
Liçoes aprendidas
No final de 2015 implementamos OKRs para os times de desenvol-

vimento de produtos da Locaweb. Algumas lições aprendidas:
• Entregas e medições mais frequentes ajudam a atingir

objetivos. Se houver entregas e medições apenas mensais, o
time só terá duas chances no trimestre para testar sua ideia
de como mexer a métrica. Se houver entregas e medições
semanais, são 12 oportunidades de avaliar e mudar o rumo
se necessário.
• Objetivos técnicos podem e devem entrar se necessário.
Alguns times de desenvolvimento de produto podem ter
optado por colocar em seus roadmaps apenas tarefas que
entregam valor para o cliente e preferem não colocar histórias
técnicas como “atualizar versão da linguagem de progra-
mação” ou “rever arquitetura para torná-la mais escalável”.
Esse era o caso da Locaweb. Ao fazermos a transição de
roadmap para OKR, surgiu a dúvida se faria sentido definir
objetivos técnicos, já que tarefas técnicas não entravam nos
roadmaps. Após algumas conversas, todos concordaram que
sim, podemos e devemos colocar objetivos mais técnicos em
nossos OKRs. Por exemplo, ter infra mais robusta e escalável
é um objetivo técnico que pode ter como métricas MTBF,
MTTR, SLA, filas, etc.
• Objetivos e KRs podem ser modificados ou mesmo can-

celados, desde que isso seja de comum acordo. Algumas
vezes, ao começar a trabalhar em alguma métrica nova, que
nunca se trabalhou antes, pode-se descobrir que mexer aquela
métrica é mais difícil ou mais fácil do que inicialmente
imaginado. É possível, nesse caso, mudar a meta daquela
resultado chave, desde que todas as pessoas interessadas este-
jam de acordo. Também pode acontecer de um determinado
resultado chave ou mesmo de um determinado objetivo ser
menos importante do que algo que surge após o planejamento
dos OKRs do trimestre. Também não é problema remover
o OKR para colocar um novo, desde que todas as pessoas
interessadas estejam de acordo.
• Cuidado com interdependências. Tarefas que podem influ-
enciar os KRs e que dependem de outros times que tenham
outras prioridades ou mesmo de fornecedor externo têm
grande risco de atrasar. O ideal é que sejam feitas no início
do trimestre, ou mesmo no trimestre anterior. Em caso de
interdependência onde um time precisa fazer A para que
outro time possa começar a fazer B, pode-se colocar A nos
OKRs do primeiro time em um trimestre e o outro time inclui
B como OKR no trimestre seguinte.
• Cuidado com métricas muito genéricas. Esse é um dos
aprendizados mais recentes. Métricas como NPS e TMA
(tempo médio de atendimento) são muito genéricas, ou seja,
podem ser impactadas por uma quantidade enorme de fato-
res. Por exemplo, o TMA pode ser influenciado por razões tão
distintas quanto o sistema de atendimento é lento, o produto
está com uma usabilidade que deixa o cliente confuso, turn-
over de funcionários de atendimento muito alto e assim por
diante. Nesses casos é recomendável transformar a métrica
em objetivo, por exemplo, “queremos baixar o TMA em 3 mi-
nutos” e definir KRs específicos como, por exemplo, “diminuir
o tempo de carregamento do sistema de 30 segundos para 3
segundos”.
• Cuidado com o excesso de otimismo! Quando se começa

a trabalhar com OKRs e se começa a definir metas para as
métricas, pode acontecer com muita frequência de as pessoas
do time subestimarem o esforço necessário para mover o
ponteiro. Existe uma tendência natural a setar metas muito
otimistas e, na retrospectiva, perceber que mover o ponteiro
é mais difícil do que o imaginado inicialmente. Nesses casos,
na próxima sessão de planejamento de OKRs, pode acontecer
o contrário, ou seja, após ter exagerado no otimismo, o time
pode ficar receoso e acaba colocando metas muito tímidas.
• Réguas claras para os KRs. Um dos pontos que chamou a
atenção na última retrospectiva foram a falta de clareza da
definição sucesso ou insucesso de cada KR. Na tentativa de
criar um padrão de análise igual para todos os KRs, nós os
definíamos sempre com um valor alvo e o critério de sucesso
era definido como sendo o atingimento de 80% ou mais do
valor alvo e o de insucesso era o atingimento de 40% ou menos
do valor alvo. O problema é cada KR tem seu próprio contexto
e sua própria mecânica. Enquanto para um determinado KR o
atingimento de 80% de seu valor alvo pudesse ser considerado
bom, para outro, esse mesmo atingimento de 80% poderia
ser considerado ruim e, para ser considerado bom, seria
necessário o atingimento de 98% do valor alvo. Em função
disso, cada KR terá agora 3 valores, o valor alvo, o valor acima
(ou abaixo) do qual o KR será considerado OK e o valor abaixo
(ou acima) do qual o KR será considerado como não OK.
• KRs semanais. Ao definir KRs, é comum nos depararmos
com métricas de mensuração mensal como, por exemplo,
churn, novas vendas, receita, margem, contatos de suporte e
assim por diante. Como essas métricas são mensais, durante
um trimestre teremos apenas duas oportunidades de avaliar
se o que estamos fazendo está surtindo efeito em mover o
ponteiro. Duas oportunidades é muito pouco, se você erra a
primeira, só tem mais uma. Por esse motivo nós decidimos nos
esforçar em dividir métricas mensais em semanais. A ideia é
fazer isso de forma bem simples, dividindo o valor mensal

por 4. Por exemplo, se o objetivo for 2000 novas vendas por
mês, deveremos ter pelo menos 500 novas vendas por semana.
Assim, se numa determinada semana tivermos 380 vendas,
saberemos que estamos atrás que teremos que compensar de
alguma forma na semana seguinte. Um outro exemplo pode
ser um KR de atingir um churn de 2% ao mês ou menor.
Esse churn de 2% ao mês equivale aproximadamente a 0,5%
de churn por semana. Assim, se numa determinada semana
tivermos 0,3% de churn estaremos bem, mas se tivermos
0,6% de churn estaremos mal. Com KRs semanais é possível
acompanhar de forma fácil e frequente se estamos bem em
relação a um determinado KR e fazer ações apropriadas para
manter ou melhorar o KR sem ter que esperar o fechamento
do mês para ver como estamos.
• Lag measure vs lead measure. A maioria das métricas que
olhamos podem ser chamadas de lag measures ou métricas
históricas. Elas contam o resultado de algo que aconteceu,
mas não contam o que foi feito para esse algo acontecer. Para
que algo aconteça é importante que a gente saiba quais são
as lead measures, ou seja, o que precisa ser feito. Exempli-
ficando, quando uma pessoa emagrece 5 quilos em 3 meses,
a lag measure é emagrecer 5 quilos em 3 meses, mas quais
foram as lead measures feitas para atingir esse resultado?
Provavelmente ela deve ter restringido sua alimentação a um
determinado número de calorias por dia, evitado determinado
tipo de alimentos e se exercitado por uma certa quantidade de
minutos uma certa quantidade de vezes por semana. Essas
são as lead measures que levaram à lag measure de ema-
grecimento descrita. Outro bom exemplo, agora que estamos
próximos das Olimpíadas, são os resultados esportivos. Por
exemplo, determinado país foi líder no quadro de medalhas
dos últimos jogos Olímpicos. Essa é a lag measure. E quais
foram as lead measures para obter esse resultado? Investiu
em formação de atletas e em patrocínio para o esporte. KRs
normalmente são lag measures. NPS, TMA, novas vendas,

receita, custo, churn, quantidade de contatos, etc. Todas essas
métricas são lag measures. Mas quais são suas lead measures?
O que as faz mudar de valor? O que as influencia? É muito
importante conhecer esses influenciadores para saber onde
trabalhar para mexer na métrica. Na Locaweb fizemos um tra-
balho de mapeamento de influenciadores de NPS e de TMA.
Esse trabalho consistiu de algumas sessões de brainstorming
onde procuramos identificar tudo o que influencia o NPS ou o
TMA. Em seguida, para cada item, avaliamos se já o medimos,
se o valor medido parece estar OK e qual o seu impacto,
usando uma escala simples do tipo P, M eG, na lag measure.
Com isso conseguimos um bom guia do que deve ser nosso
foco para podermos melhorar o NPS e o TMA.
• Dashboard visíveis. Outro ponto importante que pode aju-
dar bastante é o conceito de controles à vista. Esse conceito
é bastante difundido nas metodologias ágeis, com os times
tendo um quadro que os permite constante ver como andam
as principais métricas e, em alguns casos, sua evolução his-
tórica. O uso de controles à vista tem origem no sistema de
produção usado em fábricas japonesas conhecido como kan-
ban. Aliás, a palavra japonesa kanban significa, literalmente,
cartaz ou placar. A ideia aqui é criar um placa à vista que
mostre o que são os OKRs e como eles estão progredindo.
Com isso fica mais fácil para todo o time acompanhar a
evolução de cada uma de suas métricas. Contudo, só ter o
dashboard visível não é suficiente. Ele precisa ser constante-
mente atualizado para ser útil. Daí a quinta lição aprendida.
• OKRs weekly standup Mais uma ideia que também está
sendo “emprestada” das metodologias ágeis. Como explicado
acima, não basta só o time criar o seu dashboard visível,
ele precisa ser atualizado. A sugestão é atualizá-lo semanal-
mente, afinal definimos KRs para serem acompanhados se-
manalmente. Uma reunião em pé de 15 minutos para atualizar
os KRs, e cada um contar o que fez na semana passada e o que
pretende fazer na semana atual. Algo bem simples, mas que

ajuda na comunicação e no comprometimento do time.
Planejamento Contínuo
Planejamento contínuo, ou rolling roadmap em ingles, é o termo
que vem sendo usado para esse novo estilo de planejamento apre-
sentado no Lean Strategy.
OKR cycle meeting-> priorização relativa de iniciativas -> Lean
Inception (para as iniciativas com melhor score) -> MVP release ->
pivot or persevere (decisões beyond budget) -> OKR cycle meeting
-> …
Seguindo a cadencia do OKR e Beyond budgeting, pelo menos uma
vez a cada três meses acontece uma OKR cycle meeting. Nessa, são
revisados os OKRs atuais e criados os novos OKRs. Note que os
OKRs são revisados a cada Lean Strategy Sprint. Mas a OKR cycle
meeting é um workshop mais longo que as OKRs review meetings,
tipicamente de 4 horas, onde o grupo verifica todos OKRs e todas
iniciativas em andamento.
A OKR cycle meeting começa olhando os OKRs atuais, seguido por
criar os novos OKRs. O limite do número de OKRs obriga a equipe a
re-priorizar as principal ações estratégicas. Esta re-priorizacao deve
considerar:
• O aprendizado gerado via os MVPs

• Mudanças np mercado desde a última OKR meeting
• A situação financeira atual da UN
Aposta e quantidade de fichas

Lean Enterprise chama de aposta (bet em ingles) as iniciativas de
uma Lean Enterprise. Uma organização que segue o livro Lean
Planejamento Contínuo 104
Enterprise provavelmente está acostumado a trabalhar com com

esse vocabulário — aposta. Mas, na minha experiencia, muitas
organiações não estão prontas para chamar essas iniciativas a serem
validades de apostas.
Estou na dúvida dose sigo usando a palavra iniciativa (mais con-
versador) ou uso a palavra aposta (mais moderna). O que vc acha?
Favor me responder via paulo@caroli.org
Independente do nome, na reunião de OKR cycle meeting, [e o
momento de rever a quantidade de fichas a serem colocadas em
cada aposta existente. São três as possibilidades:
1. Dobra as aposta - o MVP mostrou bom resultado; e a UN

vai dobrar a aposta. Essa iniciativa continua no portfolio
de iniciativas em execução; provavelmente não precisa de
uma lean inception. Talvez algum workshop para realinhar
a equipe e elaborar o próximo MVP.
2. Sai da mesa - o aprendizado gerado [elo MVP demonstra
que não vale a pena continuar. O Squad será liberado para
trabalhar com a próxima iniciativa promissora.
3. Diminui a aposta - o squad vai pivotar, mas sem adicionar
mais investimento. Talvez algumas pessoas do squad sejam
liberadas para entrar em outro Squad que tem apostas mai-
ores. Mesmo assim, parte do squad segue nessa iniciativa,
buscando o product-market fit.
Do OKR ao MVP, estamos
alinhados!
Um aspecto essencial da estratégia Lean é o encadeamento e a
articulação entre os objetivos da UN e o trabalho de cada squad. Isso
acontece através do mapeamento dos OKRs da UN, as iniciativas,
os workshops de Lean Inception e os MVPs elaborados.
Parece óbvio, mas em muitas organizações esse processo é disperso
e gera inúmeras metas desconexas; por exemplo um squad traba-
lhando em algo sem conexão com nenhum OKR. Seja isso de forma
isolada (quando o trabalho de um squad não ajuda nos OKRs), seja
de forma conflitante (quando o trabalho entre os squads distintos
acaba gerando resultados conflitantes e confusos para um mesmo
OKR).
Mas como alinhar OKRs com squads e MVPs?
Aqui entra um elemento fundamental na estratégia Lean: a discus-
são sobre os OKRs se mantém viva, muito além do workshop inicial
de OKR.
A conversa sobre os OKRs não pode ser desvinculada da reunião de
priorização e escolha das iniciativas. Afinal de contas, existe uma
correlação entre VALOR da iniciativa e OKR (vide os parâmetros
do cálculo do vALOR).
Por consequência, a conversa sobre os OKRs será considerada nos
workshops de Lean Inception e da elaboração dos MVPs. Isso acon-
tece, pois, o workshop de Lean Inception é realizado no contexto da
iniciativa escolhida, aquela com melhor NOTA (maior VALOR para
menor ESFORÇO). Logo, o alinhamento do squad sobre o MVP,
indiretamente, está apontando para os OKR.
Do OKR ao MVP, estamos alinhados! 106
Definir OKRs é importante para qualquer UN. Infelizmente, alguns

líderes acham que o trabalho deles acaba aí. Na estratégia Lean,
estabelecer os OKRs é somente parte de um processo de inspeção
e adaptação, no qual o mais importante é criar um ambiente e
condições para que todos explorem suas iniciativas, conectando
expectativas, especulações e hipóteses com aprendizado e resultado
alcançado via MVP, nas mãos dos usuários finais.
OKRit - OKR, iniciativas e
tarefas
OKR é muito útil para criar alinhamento entre os pessoas da UN em
relação aos seus objetivos (e como medir-os com os Key Results).
Todas iniciativas na tabela de iniciativas da etapa PLAN devem
corroborar para os OKRs. Se esse não for o caso, tal iniciativa não
deve estar nesta tabela.
OKRit - OKR, iniciativas e tarefas
Após a reunião de Initiatives Scoring, as iniciativas com maiores

notas passam por uma Lean Inception, onde o squad alinha sobre o
MVP para validar tal iniciativa.
Na Lean Inception o squad gera o Canvas MVP, a partir do qual o
MVP é entendido e pode ser4 decomposto em tarefas.
Este é o acrônimo OKRit: OKR -> iniciativa -> tarefas, que demons-
tra como um OKR acaba influenciando nas tarefas de um squad.
Ao final de um ciclo do Lean Strategy, na etapa CHECK, o apren-
dizado gerado pelo MVP deve ser confrontado com os OKRs da
OKRit - OKR, iniciativas e tarefas 108
UN. Nessa etapa são realizadas as reuniões de OKR Review, Budget

planning e MVP Pivot or persevere, cada uma com um propósito,
mas todas relacionadas a uma UN com seus recursos, suas finanças
e produtos.
Sobre Pivotar
O objetivo de seu produto não é ter maior quantidade de receita
possível, mas sim resolver o problema ou atender a necessidade de
um conjunto de pessoas enquanto atende os objetivos estratégicos
da sua empresa. A receita deve ser vista como uma das formas de
garantir a sustentabilidade do seu produto e de medir o sucesso do
produto.
O problema é que ao longo da vida de seu produto você certamente
terá dúvidas se está no caminho certo ou se é preciso fazer alguma
mudança para atingir os objetivos do seu produto. Essa mudança
para atingir os objetivos do seu produto é o que se chama de
pivotar.
Existem várias maneiras de se pivotar:
1. Mudança na forma de capturar valor: refere-se à mone-

tização ou modelo de receita. Mudanças na forma como
uma empresa captura valor pode ter consequências de longo
alcance para os negócios, produtos e estratégias de marketing.
Vale lembrar que o modelo “grátis” não captura nenhuma
valor.
2. Mudança no motor de crescimento: existem basicamente
3 motores de crescimento: o viral que acontece pela propa-
ganda de boca-a-boca, o engajamento que acontece quando
seu cliente não consegue viver sem seu produto e o pago
que é quando você anuncia para trazer mais clientes. Muito
provavelmente você vai querer fazer uma combinação dos
três. Escolher o modelo e combinação mais apropriados para
o seu produto vai afetar a velocidade e a lucratividade do seu
crescimento.
Sobre Pivotar 110
3. Mudança de arquitetura de negócios: Geoffrey Moore, há

muitos anos, observou que existem duas grandes arquiteturas
de negócios: alta margem com baixo volume (modelo de
sistemas complexos), ou baixa margem com alto volume
(modelo de operações de volume). Você não pode fazer as
duas coisas ao mesmo tempo.
4. App vs plataforma: aconteceu quando mudamos o foco do
produto de ser um app para ser uma plataforma, ou vice-
versa. SendGrid é uma plataforma para disparo de emails.
Recentemente eles decidiram explorar mais um rumo, o de
serem também um app de Email Marketing.
5. Mudança de segmento: pode acontecer de seu produto atrair
clientes, mas não os que você tinha imaginado. Ele resolve
um problema real de um conjunto de pessoas, mas só que é
um conjunto diferente de pessoas, então você deve entender
melhor esse conjunto de pessoas e adequar seu produto a esse
novo público. Por outro lado, é importante entender pq seu
produto não resolveu o problema do público original. você
pode ter aí uma oportunidade de diversificação de portfólio
de produtos.
6. Mudança de necessidade do cliente: você pode descobrir
que o problema que você está resolvendo ou a necessidade que
você está atendendo não é tão importante para o cliente, ao
ponto de ele estar disposto a te pagar por isso. Nesse caso você
pode tentar usar a opção anterior, para ver se existe algum
outro segmento de clientes que se interesse pela sua solução,
ou mesmo alguma das outras opções descritas aqui.
7. Mudança microscópio: nesse tipo de mudança você percebe
que uma funcionalidade de seu produto é um produto valioso
por si mesma. Provavelmente nesse caso você acabou desen-
volvendo mais do que você precisava desenvolver.
8. Mudança panorâmica: é o inverso da situação anterior, nesse
caso você descobre que as features que você fez é pouco para
resolver o problema ou atender a necessidade de seus clientes
e o que você pensava que era o produto nada mais é do que
Sobre Pivotar 111
uma funcionalidade de um produto maior a ser desenvolvido.

9. Mudança de canal de venda: você pode estar tentando
vender seu produto via web, por meio de um site com um
formulário de compra, mas seu produto e o seu cliente alvo
podem requerer uma venda mais consultiva. Nesse caso você
poderá ter que adequar preço e funcionalidades. Você também
pode adotar uma estratégia E ao invés de OU. Ou seja, pode
vender pelos dois canais, sem precisar ter que escolher um ou
outro.
10. Mudança de tecnologia: pode acontecer de você descobrir
uma forma de resolver um determinado problema usando
uma tecnologia completamente diferente, que consegue fazer
com que você ofereça seu produto por um preço bem melhor
ou com uma qualidade muito superior aos competidores.
Está aí uma lista de 10 formas de você mudar o rumo do
seu produto para que você possa atingir os objetivos desse
produto.
Note que algumas dessas maneiras de mudar o rumo de um produto

podem também servir como forma de se expandir o portfólio de
produtos.
Um caso prático
No final de 2012 a Locaweb decidiu investir em uma startup
chamada Eventials (http://eventials.com), uma plataforma para
transmissão de palestras online. Nessa época a Eventials vinha
crescendo em termos de visitantes e número de palestras online e a
equipe decidiu reescrever toda a aplicação para atender a demanda
por novas funcionalidades e evitar gargalos na infra-estrutura. No
início do segundo trimestre de 2013 a nova aplicação foi lançada.
Também nessa época a equipe da Eventials, que era de Blumenau,
decidiu se mudar para São Paulo, para dentro do escritório da
Sobre Pivotar 112
Locaweb. Comecei a ter reuniões semanais com o Thiago Lima,

fundador da Eventials, para que pudéssemos trocar experiências
sobre startups e gestão de produtos.
O modelo de negócios adotado foi o do Freemium com “Pay-
As-You-Go”, ou seja, o palestrante podia criar palestras gratuitas
mas para poder ter todos os benefícios da plataforma (estatísticas,
palestras pagas, palestras privadas, etc.), o palestrante precisava
comprar créditos que eram consumidos quando os visitantes as-
sistiam as palestras. O problema desse modelo era exatamente esse,
a dependência da audiência. Se a palestra não tivesse audiência,
os créditos não seriam consumidos. A inspiração desse modelo de
negócios é o modelo adotado por provedores de infra-estrutura em
cloud como AWS, Rackspace e a própria Locaweb, onde o servidor
é vendido por hora. A diferença é que para os provedores de infra-
estrutura em cloud, o cliente é cobrado desde que o servidor esteja
ligado, tendo ou não uso. Já na Eventials a cobrança só acontecia se
o cliente tivesse audiência.
Pensando nisso, no final de 2013 Thiago resolveu mudar o modelo
de negócios e para venda de planos ao invés de créditos:
Sobre Pivotar 113
Esse modelo está em operação desde janeiro de 2014 e os resultados

foram visíveis. A receita que era mais ou menos flat passou a mos-
trar um padrão de crescimento mais claro. Não houve reclamações
por parte dos clientes antigos, que converteram para o novo modelo
sem queixas. O resultado pode ser visto abaixo:
Sobre Pivotar 114
A forma de pivotar escolhida pelo Thiago foi a mudança na forma

de capturar valor.

Estrategia Lean

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Estrategia Lean

Enviado por

Direitos autorais:

Formatos disponíveis

Estratégia Lean

o caminho mais rápido e seguro para

Paulo Caroli e Joaquim Torres

Paulo Caroli e Joaquim Torres (Joca)

Essa versão foi publicada em 2020-01-23

Esse é um livro Leanpub. A Leanpub dá poderes aos autores e

© 2015 - 2020 Paulo Caroli e Joaquim Torres (Joca)

Livros De Joaquim Torres (Joca)

Sobre Paulo Caroli . . . . . . . . . . . . . . . . . . . . . . . . ii

Sobre a Editora Caroli . . . . . . . . . . . . . . . . . . . . . . iii

Sobre este livro . . . . . . . . . . . . . . . . . . . . . . . . . . iv

Simples é diferente de simplório . . . . . . . . . . . . . . . 1

Os três horizones - 3Hs . . . . . . . . . . . . . . . . . . . . . 4

O ciclo PDCA do Lean Strategy . . . . . . . . . . . . . . . . 11

Outros modelos para priorização . . . . . . . . . . . . . . . 30

Construindo MVP com Scrum . . . . . . . . . . . . . . . . . 39

O MVP nas cerimônias do scrum . . . . . . . . . . . . . . 43

Construindo MVP com Kanban . . . . . . . . . . . . . . . . 45

Arquitetura Mínima Viável (MVA) . . . . . . . . . . . . . . 60

Burn-up de Features do MVP . . . . . . . . . . . . . . . . . 69

Status report do MVP . . . . . . . . . . . . . . . . . . . . . . 77

Planejamento Contínuo . . . . . . . . . . . . . . . . . . . . . 103

Do OKR ao MVP, estamos alinhados! . . . . . . . . . . . . 105

OKRit - OKR, iniciativas e tarefas . . . . . . . . . . . . . . 107

Sobre Pivotar . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Acompanhe Paulo Caroli no seu site e nas redes sociais:

WIP (Writing In Progress)

A Editora Caroli apresenta uma nova proposta de trabalho, apro-

Este e outros eBooks estarão disponíveis no site http:

Sobre o Lean PMO

Mas a maior mudança vem da transformação digital que coloca

No caso de uma pequena startUp, a própria compõe a UN. Grandes

Estratégia, UN, OKR e MVP

realidade da evolução e inovação dos seus produtos, segundo as

¹A Alquimia do Crescimento - os Segredos das 30 Empresa que Mais Crescem no Mundo,

< qual imagem está melhor? >

Talvez esses já não tenham muito investimento em novo desen-

Invista nas bezerras

O investimento em H2 é o gasto com suas bezerras, aquelas que são

Prosseguir, pivotar, ou cancelar. Esse é o mantra para os

Mas o mundo mudou. Com o advento da internet, da mobilidade,

descrevê-lo, colocá-lo num canvas ³, criar, e verificar se estamos

Experimento, resultado, receita

Os 3Hs e este livro

O PDCA do Lean Strategy

Esse é o ciclo do PDCA: Tudo começa a partir de um workshop

puxado) para um workshop de Lean Inception, onde todos juntos

(1) uma priorização, inicial, quanto (2) o redirecionamento baseado

• Reach: quantas pessoas serão impactadas por essa iniciativa?

Para (2), eu gosto dos parâmetros descritos por WSJF (Weighted

• Business Value: Qual a penalidade potencial ou impacto nega-

É importante ressaltar que tanto RICE, quanto WSJF recomendam

VALOR = [Reach x Impact x Confidence] + [ (Business Value +

• Reach (de 0 a 5; 5 significa maior alcance)

Para a mesma equipe (assumindo dedicação exclusiva

Esta comparação de esforço não é uma estimativa ou comprome-

Cálculo de NOTAs, um exemplo

Iniciativa A: metade dos nossos usuários serão afetados por esta

Iniciativa B: A equipe considera que precisa de 3 vezes menos

Desta forma podemos selecionar as iniciativas mais prioritárias

onde o time de produto responsável pela iniciativa irá compreender

depende do número de iniciativas, de participantes, e do nível de

preparando a tabela - iniciativas vs quesitos

resultado da tabela de priorização