Silicon Valey Is Here

NDICE
Introduo............................................................................................3
Prticas, Papis e Plataforma..................................................................25
O dilema da agilidade digital ..................................................................4
Silicon Valley is coming ........................................................................27
Os 10 maiores erros da abordagem de fbrica de software..........................6
OKR (Objectives and Key Results) *por Felipe Castro.................................33
Anti-patterns: por que pessoas inteligentes tomam decises erradas..........9
Transformao digital............................................................................35
Lean Startup e Lean Innovation...............................................................11
Presente e Futuro...................................................................................36
No fazemos projetos, desenvolvemos produtos!......................................17
Introduo
H 15 anos, exatamente enquanto a Concrete Solutions nascia, um grupo de ve-
e como essa viso nos mostrou o trip Lean Product Management, OKR e Enge-
teranos em desenvolvimento de software se reunia para criar o Manifesto gil,
nharia gil, que consideramos o estado da arte no desenvolvimento de software
documento que tinha por objetivo melhorar o desempenho dos projetos de tec-
atualmente. Entretanto, vale lembrar que o desenvolvimento de software um
nologia. Sendo assim, no por acaso que acompanhamos a evoluo da agi-
ambiente complexo e catico, em constante transformao. Essas nossas ideias
lidade por todo esse tempo, seguindo seus princpios, iterando e aprendendo a
mudam a todo momento, pois tudo o que fazemos emprico, iterativo e incre-
cada novo cliente e produto desenvolvido.
mental. Logo, pode ser que pouco depois de ler esse livro ns j tenhamos tido
Neste livro, pretendemos contar parte dessa histria. Como passamos do escuro
do waterfall para a luz do Scrum, como identificamos as melhores prticas, os
uma nova epifania que faa sentido ou um aprendizado que nos traga coisas
novas, quem sabe baseados no seu feedback.
papis ideais e uma plataforma que fizesse sentido nesse contexto, como en-
Esperamos que esse livro te ajude a entender melhor o ambiente de tecnologia
tendemos que o que fazamos era gerenciamento de produtos digitais
no Brasil e te ajude a dar mais um passo no caminho do sucesso.
Boa leitura!
Silicon Valley is here - Como usar a agilidade corporativa para competir
Capitulo 1
O dilema da agilidade digital

Nosso mundo mudou. Precisamos tomar decises difceis sobre sistemas complexos digitais que vo
afetar o futuro das nossas empresas. Estas decises juntas, ao longo do tempo, deveriam ser uma busca
pela evoluo para uma cultura de agilidade digital.
Neste primeiro captulo, pretendo sintetizar a mensagem central e atual que gostaria que ficasse deste
livro. O que posso trazer aqui no uma frmula a ser aplicvel sem mudana no seu contexto, mas
uma trajetria de aprendizado com experimentos aninhados ao longo de 15 anos para que talvez voc
no precise cometer o enorme nmero de erros que ns cometemos. Se servir para isso, o esforo de
compilar essas ideias j serviu seu propsito. A partir do segundo captulo eu busco manter uma ordem
cronolgica, e muitas vezes datada, do nosso processo de aprendizado.
Atualmente, o nexus competitivo brasileiro uma combinao de um voltil ambiente de negcios
formado por uma crise sem precedentes do nosso capitalismo e a vinda de novos competidores digitais
do Vale do Silcio. Alm deste novo ambiente, o nosso cliente mudou. Agora ele quer uma relao de
autosservio mobile com nossos produtos no mesmo patamar de qualidade dos aplicativos do Vale e
com a presena ubqua da nuvem.
Juntando essas variveis temos trs dilemas competitivos: queremos mudar nossa cultura e implantar
uma estratgia de execuo digital nos moldes do Vale; queremos descobrir novos modelos de negcio
que alavanquem as capacidades da empresa por meio de importantes ganhos operacionais; e queremos
disruptar nosso prprio negcio antes que algum o faa.
Implantao de uma cultura de execuo digital
Peter Drucker disse uma vez que cultura come estratgia no caf da manh. Ns acreditamos que
a nica estratgia que importa a implantao de uma cultura de execuo digital. Isso implica em
entender que temos que ser iterativos, empricos e incrementais quando lidamos com sistemas dinmicos
complexos, e isso tem que ser lentamente inoculado no DNA da empresa.
Essa agilidade digital global implica em aplicar e evoluir frameworks geis no como fazer, no o que
fazer e, finalmente, no como gerir a corporao. Para ns, isso se traduz em gil em escala, Lean Product
Management e OKR, itens que sero melhor descritos ao longo desse livro. O principal termmetro deste
processo o nvel de maturidade de agilidade digital em que est o seu principal canal de autosservio
para seus clientes. Se ele est mal, voc est mal.
O processo de implantao que parece funcionar tambm emprico, iterativo e incremental. Se implanta
uma pequena estrutura de produtos operando o primeiro esquadro gil que vai sofrer o diabo com as
dependncias departamentais e com o waterfall do resto da organizao. Se esse time tiver o suporte
executivo no nvel adequado, ele vai entregar uma primeira vitria que vai permitir comear a hackear
a cultura.
Neste ponto, o time deve escalar em uma estrutura de mltiplos times coordenados por algo parecido
com um Nexus da Scrum.org ou algo que obedea aos mesmos princpios. Esses times lentamente
vo assimilando as dependncias e se tornando feature teams com cada vez mais participantes que
tm todas as capacidades necessrias para entregar o produto. Finalmente, voc engloba os sistemas
core.
Este processo cria uma estrutura supra departamental iterativamente, com o apoio da cultura. Isso
porque ao contrrio do inferno anterior, ele entrega. A cultura afeta os times e os times afetam a cultura
e essa abordagem e framework de implantao de agilidade digital pode ser repetido ad nauseum,
alterando toda a corporao.
Descobrindo novos modelos de negcio digitais no seu negcio atual
Este problema uma variao do anterior, mas o nvel de complexidade do sistema maior. Ento,
temos que adicionar processos empricos de ciclo rpido para reduzir o cone de incerteza. Por exemplo,
se voc tiver o desafio de criar uma rea de inovao, a abordagem acima precisa de duas variaes
adicionais no como fazer e no o que fazer e de uma estratgia de funding ou alocao de oramento
diferente, inspirada no modelo de venture capital.
Os times sempre devem comear com ciclos de Product Discovery seguidos de um aumento de
capacidade at que tenha pelo menos todos os papis. Neste momento, passados de dois a quatro
sprints, se temos validaes claras e quantitativas das nossas hipteses de negcio e dos primeiros
features de produto o nvel de complexidade do sistema cai e podemos utilizar a abordagem exposta
anteriormente para escalar o produto.

Se, por outro lado, parte do produto continua muito complexa ou catica, podemos utilizar estratgias
de Dual Lane Scrum (conceito de Jeff Patton) ou de Sprints de Discovery (de Marty Cagan) em paralelo
ao desenvolvimento dele.
Em relao alocao de capital e oramento, estes times devem ter portes de aprovaes autogeridos
no incio seguidos de ciclos semestrais de mantm, investe mais ou mata o produto. Dentro de um
ambiente limitado, isso significa algumas vezes que para atender ao oramento teremos que forar
darwinianamente a realocao do capital e dos times estveis para os melhores produtos.
A implantao desta cultura de execuo digital tem que sempre levar em conta as condies de
contorno e o estado do sistema no qual o produto est inserido e ter agilidade digital para usar o modelo
mental e o ferramental correto.
Disruptando a si mesmo
Esse um tema que tenho muito menos experincia, mas acredito que a deciso entre estratgias
de corporate venturing, investimentos, aquisies e aceleradoras corporativas, apesar de vlidas e
potencialmente de muito sucesso, muitas vezes esconde o problema de que a corporao patrocinadora
no comeou o seu prprio processo de mudana.
Me parece que, no longo prazo, ser capaz de ter sua prpria capacidade de execuo digital como
alternativa a estes modelos equilibra o sistema e permite aos executivos tomar decises de alocao
capital pelo motivo certo e de forma tima, garantindo a sobrevivncia de longo prazo da corporao
nesse admirvel mundo digital novo.
Capitulo 2
Os 10 maiores erros da abordagem

de fbrica de software
L em 2001, logo que a empresa foi fundada, fizemos alguns projetos usando waterfall. Foi rpida,
porm, a mudana para gil. Isso porque descobrimos diversos erros na abordagem em cascata. Vamos
falar um pouco sobre quais foram eles.
Se voc procurar a definio do termo fbrica de SW no Wikipedia brasileiro temos a seguinte definio:
Fbrica de software um conjunto de recursos (humanos e materiais), processos e metodologias
estruturados de forma semelhante queles das indstrias tradicionais, utilizando as melhores prticas
criadas para o processo de desenvolvimento, testes e manuteno dos softwares. Utiliza em sua
operao indicadores de qualidade e produtividade em cada etapa do ciclo de desenvolvimento de
software, bem como busca maximizar a reutilizao de componentes anteriormente desenvolvidos.
Tornou-se uma prtica comum com o objetivo de massificar a produo de software pela reduo de
custos.
Apenas com base nessa definio livre da Wikipedia, podemos comear a listar os maiores erros
relacionados ao uso desta abordagem.
1. Fbrica de Software um conjunto de recursos humanos e materiais
Fazer software um trabalho criativo, no qual as diferenas de produtividade podem chegar a 10 vezes
de diferena entre trabalhadores do conhecimento, ou seja, pessoas que precisam ser motivadas e
remuneradas para que produzam o seu melhor e tenham seus interesses alinhados com o cliente.
Tratar o desenvolvedor como um recurso no s infantilizar como desumanizar um tipo de profissional
extremamente sofisticado e escasso. Inserir este profissional em uma forma arcaica e ineficiente de
fazer software atrai o que h de menos produtivo para sua linha de montagem.
2. Os recursos so estruturados de forma semelhante a uma indstria tradicional
Novamente recorrendo Wikipedia, temos como definio para o termo linha de montagem:
As linhas de montagens so utilizadas no processo de produo em srie, para que o produto em
fabricao seja deslocado ao longo de postos de trabalho, mas a sua eficincia depende da combinao
de quatro condies indispensveis: componentes estandardizados, movimento mecnico, equipamento
de preciso e processos padronizados

Fazer software tem mais semelhanas com o processo de criao do primeiro produto, que evolui
iterativamente de um conceito para um prottipo e chega a uma primeira verso comercial. No se trata
de produzir a mesma coisa em srie repetidas vezes. Os componentes so feitos individualmente e de
forma criativa para resolver um determinado problema, e o nvel de padronizao baixssimo. Preciso
e repetio foram eliminadas desta equao h muito tempo, so feitas pelos compiladores e linkers.
3. utilizando as melhores prticas criadas para o processo de desenvolvimento, testes e
manutenes dos softwares
A primeira fbrica de software foi criada em 1969, na Hitachi, e o processo waterfall baseado em uma
malfadada leitura de um artigo de Winston Royce de 1970, no qual ele usou a clebre frase proftica: but
the implementation described above is risky and invites failure. A criao de processos seriais de engenharia
leva a uma falta de feedback total, no s entre as reas, mas principalmente com o cliente. O produto
tardiamente testado, tem pouca chance de sucesso e o investimento e alocao de despesas feita
sob estimativas sem nenhum embasamento.
Alm disso, a criao de silos de requisitos, arquitetura, desenvolvimento, testes e operao e
manuteno leva a um desalinhamento de interesses. Apesar de ningum saber o que fazer (como no
testado em campo), um tratado extenso de requisitos feito para um problema que ningum sabe
exatamente qual nem muito menos como resolv-lo.
Quem testa tem conflito de interesse com a ida de algo para produo e finalmente quem cria o produto
(se ele eventualmente for para produo) no quem d manuteno a ele.
Estes silos geram uma natural necessidade de burocratizao dos pontos de interface e uma gesto de
mudana catica e impraticvel.
4. reutilizao de componentes anteriormente desenvolvidos
A grande dificuldade do reso, que observei nos ltimos 17 anos, a combinao de dois fatores:
a necessidade de padronizao de definio de uma forma clara de descrever aquele domnio e a

incapacidade da organizao de prever o futuro e prescrever a priori o que de popular o seu catlogo.O
nvel de reuso dentro de uma mesma organizao baixssimo, pois o catlogo malformado. Em um
ambiente open source, ao contrrio, toda uma comunidade elege o que um ativo reusavel de forma
livre (na prtica regida pelas leis de mercado).
Em uma amostra pequena, cada projeto ou iniciativa tende a cobrir um pedao do espao do problema
que no ser visitado desta forma novamente. As iniciativas de SOA, por exemplo, tentavam prescrever
o futuro sobre quais seriam os servios reusveis de uma organizao e, pior, gerava um ciclo waterfall
dentro de outro ciclo waterfall, o que aumentava enormemente a complexidade e acabava tornando
um projeto com 13% de chance de sucesso (segundo o CHAOS Report) um projeto impossvel.
5. tornou-se uma prtica comum com o
objetivo de massificar a produo de software
pela reduo de custos
Warren Buffet uma vez disse que no existe
desperdcio maior do que produzir com perfeio
alguma coisa que ningum quer. Quando
analisamos processos produtivos como o
mtodo Toyota de Taichi Ono ou leituras como a
Teoria das Restries de Eliyahu Goldratt, vemos
similaridades na busca da otimizao global com
frameworks de melhoria continuada. Se no
analisarmos e otimizarmos o sistema como um
todo, podemos (via otimizao local) criar falsas
economias de escala e gerar desperdcio de duas
formas: produzindo a quantidade errada da coisa
errada.
Se analisarmos o trabalho de Steve Blank e Eric
Identify the
constraint
Ries, que reflete o estado do conhecimento do Vale do Silcio sobre como fazer produtos e empresas
digitais, entendemos que o maior desperdcio no fazer errado, mas principalmente fazer a coisa
errada. Esse erro aumentado pela prescrio e pelo processo waterfall de lanamento de produto.
Blank cita inclusive que o desenvolvimento de novos produtos uma busca, e no uma execuo.
A produo de software uma criao iterativa e incremental que busca materializar uma necessidade
de um cliente que voc ainda no sabe qual , se um problema que vale a pena ser resolvido e muito
menos como voc vai resolv-lo.
Pensar em uma linha de montagem para atacar um problema deste tipo a mesma coisa que utilizar
cavalaria e guerra de trincheiras no ambiente militar contemporneo ou, mantendo a metfora militar,
tentar prescrever a invaso da Normandia. Esses cinco pontos por si s, tirados da Wikipedia, j nos
deixa desconfortveis para usar watefall. Mas ainda temos mais cinco outras crenas que vale a pena
desconstruir.
6. Voc sabe qual o problema que voc tem que resolver e como vai resolv-lo, por isso podemos
prescrever o processo. O processo de trabalho rgido
No primeiro captulo de The Toyota Way, Fujio Cho faz a seguinte abertura:
Repeat the
process
Exploit the
constraint
Elevate
performance of
the constraint
Subordinate and
synchronize to
the constraints
Goldratt, teoria das restries
We place the highest value on actual implementation and taking action. There are many things one
doesnt understand and therefore, we ask them why dont you just go ahead and take action; try to do
something? You realize how little you know and you face your own failures and you simply can correct
those failures and redo it again and at the second trial you realize another mistake or another thing you
didnt like so you can redo it once again. So by constant improvement, or, should I say, the improvement
based on action, one can rise to the higher level of practice and knowledge.
Traduo livre: Ns colocamos o maior valor na implementao e aes reais. H muitas coisas que
no entendemos e, portanto, perguntamos ao cliente se devemos seguir em frente e realizar essas
aes ou tentamos fazer algo. Voc percebe o quo pouco voc sabe, enfrenta seus prprios fracassos
e pode simplesmente corrigir essas falhas e refazer tudo de novo. Em uma segunda tentativa voc
percebe outro erro ou outra coisa que voc no gosta e pode refazer mais uma vez. Assim, por meio da
melhoria contnua, pode-se subir ao mais alto nvel da prtica e do conhecimento.

Colocando isso no domnio de software, processos que buscam melhoria continuada e desenvolvimento
de produtos de sucesso tm que ser iterativos, pois se tratam de uma jornada de aprendizado focada
no cliente.
Esta jornada deve ser feita com a ajuda de times multidisciplinares que se mantm juntos, trabalhando
em um mesmo domnio e mesmo cliente e, mais importante, prximos ao cliente. Essa estratgia leva a
um aumento contnuo da fluncia gil, ou seja, fazer de forma cada vez mais eficiente. Criamos msculo
intelectual pelo aprendizado baseado na prtica.
7. Conseguimos estimar corretamente o esforo de um produto por meio de tcnicas top down ou
bottom up ou de uma regresso e interpolao linear simples (pontos de funo ou UC Points)
Primeiro ponto a ser considerado aqui a discusso sobre
comportamento passado explicando comportamento futuro, o que neste caso especialmente no se aplica. Em
segundo lugar, a amostra no
aplicvel, ou seja, no existe uma srie histrica vlida
a no ser que eu tenha o mes@Scott Adams Inc./Dist by UFS, Inc. www.dilbert.com
mo time, no mesmo ambiente
de negcio e tecnologia, fazendo a mesma coisa. Em 18 anos de experincia, nunca vi isso acontecer.
A criao de uma taxonomia que sirva para criar uma srie (e um modelo de previso)
para descrever um fenmeno to amplo como desenvolvimento de software, ignorando a
necessidade de condies de contorno estritas, simplesmente e completamente desprovida
de rigor, seja pela viso da academia ou pela viso da comunidade que faz software (practitioners).
Pior do que a inacuracidade da abordagem a falsa sensao de previsibilidade que ela d para
celebrao de contratos na esfera privada e governamental.
8. Conseguimos prever o futuro, criando um grfico de Gantt detalhado sobre os eventos que
ocorrero nos prximos n meses
Fazendo um paralelo, como se um gestor de fundo de investimento mandasse uma lista detalhada
de todos os trades que ele vai fazer nos prximos seis meses, ignorando o mercado, e, com isso, te
garantisse o nvel de retorno desta estratgia. E VOC ACREDITASSE NISSO.
9. Documentao e modelos ajudam a construir um produto digital de forma profissional
Fazendo um paralelo com projeto de construo civil, Glenn Vanderburg traou na sua palestra Craft
and SW Engineering a seguinte relao: o cdigo o projeto de arquitetura e o binrio a casa. O
trabalho de baixo valor agregado e repetitivo de executar o plano feito pelo compilador e como este
trabalho virtualmente gratuito, no faz sentido fazer modelos e simulaes.
Modelos s precisam ser feitos em ambientes em que a construo do produto em si muito cara,
como na indstria aeronutica e militar, para que a iterao em espiral seja mais eficiente e menos
custosa no incio. Em software, o cdigo o melhor modelo e o nico que vai representar uma soluo
real para aquele problema naquele ambiente dinmico e complexo. O software consequentemente o
prprio produto que deve ser usado nas iteraes de aprendizado.
10. Conseguimos definir corretamente o escopo, estimar o esforo e executar em um prazo
determinado com qualidade, passando a informao com sucesso entre todos os departamentos
da fbrica.
Se analisarmos o processo de criao do produto como uma cadeia de valor eficiente, gostaramos
que ela tivesse integrao perfeita entre os praticantes, estoque zero e transferncia instantnea de
informao em um fluxo perfeito de trabalho Just in Time, no qual cada participante especialista fizesse
seu trabalho melhor que uma empresa s. A melhor representao disto no nosso contexto um time
multidisciplinar trabalhando junto, dentro de um framework emprico em qualquer de desenvolvimento
de produto. Ficou claro que waterfall no o caminho? Ento vamos falar de gil!
Capitulo 3
Anti-patterns: por que pessoas inteligentes

tomam decises erradas
A adoo de metodologias geis garante o aumento da chance do seu produto, mas no que essa
chance chegue a 100%. O desenvolvimento de software uma rea complexa, tratada por seres
humanos, e os erros so frequentes e devem continuar sendo. Apostamos em hipteses, que devem ou
no ser validadas, e seguimos em frente com o aprendizado que adquirimos em cada sprint. Entretanto,
podemos enxergar os erros que cometemos (ou que outros cometeram) e entend-los para que eles
no voltem a ocorrer.
Nos ltimos quinze anos, criamos e trabalhamos em quase vinte startups. Nelas, alguns erros se
repetem vrias vezes. Por isso, resolvi organiz-los em um diretrio de anti-patterns que permita que
os prximos empreendedores digitais no precisem cair nos mesmos buracos que ns camos. Estes
padres emergiram naturalmente, pois parecem ser uma predisposio natural do empreendedor. Sem
nenhuma ordem particular, seguem os erros mais comuns e graves que normalmente se repetem por
falta de reflexo adequada:
1. Maximum Viable Product ou La Sagrada Familia
Essa ideia prega que o produto precisa de todas as funcionalidades de um
backlog mutvel, feito dentro do escritrio e sem nenhum embasamento
emprico (validao das hipteses de negcio com clientes reais).
Funcionalidades empurradas (no sugeridas pelos clientes potenciais) levam
a data de lanamento para as galxias e, normalmente, quebram a empresa.
O arquiteto Antoni Gaud fez um projeto to ambicioso e fluido para a catedral
de Barcelona (La Sagrada Famlia) que est em execuo desde 1882 e deve
ficar pronto em 2026.
Barcelona - La Sagrada Familia
O encouraado Yamato era o maior navio da 2 Guerra Mundial, com canhes de 500 mm. Ele foi
mandado para uma ltima misso sem combustvel para voltar. Startups s tm uma mtrica financeira
3. The Queen of Hearts

Cortem-lhe a cabea! Se, por algum motivo, as
travas emocionais relacionadas demisso so
diminudas (em um contrato de terceirizao de
mo-de-obra, por exemplo), ou a punio do erro
alta demais, todo o ciclo de Build, Measure and
Learn sabotado. Quando se encontra um eventual insucesso, ao invs de se invalidar uma hiptese ruim, h uma busca de um bode expiatrio
prontamente eliminado, o que elimina o aprendizado. Isso normalmente gera o aparecimento de Yes
Mans ou pessoas que reforam o pensamento vigente e que tm esse comportamento bonificado.
Em mdio prazo, isso mata a startup, pois elimina
Rainha de Copas - Alce no Pas das Maravlhas
a convergncia para um modelo de negcios que
funcione e gera um grupo homogeneamente apontado para a direo errada.
4. The luv for Awesome
A frase clssica desse erro : no podemos entrar em produo sem todas

essas features ou com menos do que a concorrncia
2. Yamato
que interessa: qual o meu burn rate (perda de caixa mensal), acompanhada pela quanto tempo eu
ainda levo para quebrar. Uma gesto de produto que ignore essas questes afunda startups por causa
da falta de combustvel.
Um dos maiores (talvez poucos) desservios que Zuckerberg prestou comunidade foi a falcia de que
ele trabalha buscando o awesome. O Facebook entende profundamente seus clientes e oferece, aos
poucos, novas funcionalidades para atender seus problemas mais relevantes. Awesome uma droga
geek que fica no caminho do pronto e, portanto, do aprendizado, do empirismo e do mtodo cientfico.
Ou seja, o awesome inimigo do bom. Nada mata to gloriosamente uma startup como a busca de
uma inatingvel beleza tcnica ou uma viso de produto to avassaladora que nos fora a uma atitude
home run or die.
5. Claptrap
Transcrevendo um arquivo brilhante do Wall Street
Journal que cita Richard Feynman:
Monitor yourself for vehemence. If you find yourself tempted to ridicule anyone who tells you are
wrong, you probably are wrong. The philosopher
Bertrand Russell wisely warned that the less evidence someone has that his ideas are right, the
more vehemently he asserts that there is no doubt
whatsoever that he is exactly right
Traduo livre: Monitore voc mesmo para a
veemncia. Se voc est tentado a ridicularizar
qualquer um que diz que voc est errado, voc
provavelmente est errado. O filsofo Bertrand
Russell sabiamente advertiu que quanto menos
evidncias algum tem de que suas ideias esto
certas, mais veementemente ele afirmar que no
h dvidas de quanto ele est certo.
Se o seu ninja tcnico muito assertivo, o go
to guy para quase tudo e vira noites o tempo todo,
mate ele a pauladas (figurativamente).
6. Barrel rider meets mediocre
O processo waterfall, com compra via RFP, criou uma lgica de meritocracia reversa em TI muito
semelhante ao que ocorre em um estado comunista clssico. Sem entrar no mrito ideolgico, o que
induz o comportamento do sistema comunista a criao de controles, a inimputabilidade e a criao
de uma nova ordem dirigente na qual quem tem mais poder no quem produz, mas quem controla. Em
longo prazo, ningum mais quer produzir, a no ser um grupo cada

vez mais caro de mercenrios que inexoravelmente a empresa no
vai mais conseguir pagar.
7. Atlas Shrugged
Quando o anti-pattern anterior acontece, as pessoas que produzem
e que levam o mundo nas costas desistem, do de ombros e vo
embora. Quando as palavras dissonantes comeam a ficar em
silncio, no final tudo converge para um pacto de mediocridade
tcito.
8. Hulk
Ns resolvemos tudo na fora bruta porque temos funding,
no importa se nosso anel de Cassandra no teve dois dias de
planejamento antes de entrar em produo. Dbito tcnico
inserido em uma taxa cada vez mais alta com horas e horas de
trabalho extra em uma esperana bem-intencionada de que o
sistema vai se estabilizar quando de fato ele est morrendo. Outra
frase clssica No consigo testar nosso cenrio de produo. Nestes casos, a fora bruta entra e
servidores e desenvolvedores so inseridos at que algo realmente grave acontea e a organizao
saia do transe.
9. O bom, o mau e o feio
Uma startup precisa de trs perfis: o Hacker, o Hustler (vendedor) e o Designer, e muito raramente eles
esto em uma pessoa s. Tentar fazer bootstrap sem um hacker no time suicdio, bem como colocar
um tech co-founder brilhante como CEO na fase subsequente uma frmula clssica para imploso
do time. Alm disso, as aes devem ser pensadas como um pagamento antecipado de 24 meses de
salrio, e devem ser vestidas ao longo deste perodo. Caso contrrio, voc ter uma empresa com
scios zumbis at um deles aceitar uma proposta e ir para Nova York antes de dar sua quota de suor.
10
Capitulo 4
Lean Startup e Lean Innovation

Finalmente, todo contrato no Brasil precisa de clusulas de sada e/ou resoluo de conflito. Se for
para o Tribunal, uma competio de nado sincronizado em concreto: voc se move vagarosamente e,
quando ele secar
Tempos depois, ele publicou esse cartoon:
A maior referncia que temos sobre negcios digitais est no Vale do Silcio, onde so criados os principais
sucessos. Foi l que surgiu a metodologia Lean Startup para desenvolver startups digitais, que agora
est sendo aplicada tambm em grandes corporaes.
No primeiro captulo, falamos sobre como a utilizao de waterfall a principal causadora de insucesso
em produtos e empresas de tecnologia. Depois do aprendizado da primeira bolha, Steve Blank enxergou
um padro nas startups de sucesso que resumiu no livro The Four Steps to the Epiphany. Segundo ele,
tais startups eram capazes de enxergar que tanto o problema quanto a soluo eram desconhecidos
no incio da jornada. Neste caso, no adiantava elaborar grandes ciclos de planejamento e encontrar o
cliente tardiamente com uma soluo no testada em campo.
Alm disso, estes empreendedores visionrios eram capazes de tratar estas etapas de validao de
problema e soluo como ciclos de validao de hipteses de negcio, que poderiam ser validadas ou
no.
Ele formalizou assim uma heurstica para validao de modelo de negcio:
Fonte: www.steveblank.com
Fonte: Banks
11
Mas o que Lean Startup?

O conceito foi criado por Eric Ries baseado no trabalho de Steve Blank, e parte do princpio de que o
objetivo de uma startup validar um modelo de negcios e no execut-lo com eficincia. Ou seja, o
negcio deve ser tratado como um conjunto de hipteses que precisam ser validadas ou abandonadas
rapidamente.
No contexto digital, a prtica une mtodos geis, desenvolvimento de cliente (ou Customer Development)
e alguns conceitos de Lean, como lotes pequenos.
Para desenvolvimento de produto, os mtodos geis so os mais usados mundialmente, e sua adoo
est aumentando cada vez mais no Brasil. Com eles, os projetos no tm escopo rgido e cada etapa
construda de forma evolutiva, com cliente e fornecedor atuando conjuntamente. Porm, como dizia
Peter Drucker, no existe desperdcio maior do que executar com perfeio algo que ningum quer.
Mtodos geis, apesar de enderearem o espao da soluo, no ajudavam a entender o problema, que
era validar o modelo de negcio. Por isso, a metodologia teve de adotar tambm o desenvolvimento do
cliente (Customer Development).
Tal abordagem no garante o sucesso da empreitada, mas aumenta muito sua chance de sucesso
eliminando o desperdcio e o crescimento precipitado (no sustentvel). Com isso, hoje podemos criar
startups de tecnologia com investimentos iniciais de menos R$ 500 mil, o que na poca da primeira
bolha era de cerca de R$ 10 milhes.
Empreender continua precisando de paixo, mas os fundos precisam de dados reais obtidos de mtricas
vindas do que Ries chamou de contabilidade de inovao, isto , de dados mais especficos para
acompanhar e principalmente aprender com a evoluo da startup e o engajamento dos seus clientes.
O dinheiro vir ao serem atingidos os patamares de aprendizado.
O maior desastre da histria das startups uma prova por absurdo de que a abordagem de Lean Startup
a mais indicada. A Iridium destruiu US$ 5,2 bilhes porque durante os onze anos que comprou 15
foguetes e colocou mais de 75 satlites em rbita o mercado de comunicao mvel mudou. Ao invs
dos 42 milhes de clientes esperados, a empresa teve apenas 30 mil no seu pico. O plano de negcios
foi seguido com preciso at o precipcio, enquanto que o processo de Customer Development teria
trazido alarmes antecipados disto.
Podemos dizer mais que os modelos de open source e de cloud computing democratizaram o espao
de competio, eliminando a necessidade de investimentos na infraestrutura computacional e dando
uma adaptabilidade fluida a esta estrutura, que se molda perfeitamente ao negcio. Assim, as melhorias
so visveis em qualidade, velocidade e custo, o que faz da prtica Lean Startup, associada ao uso de
ferramentas open source e cloud computing, a melhor forma de estruturar um novo negcio.
Lean Innovation (Lean Startup em corporao)
Mas e para as empresas j estabelecidas, que no so mais startups? A mesma viso pode ser aplicada.
Novos projetos tm caractersticas similares a uma startup e, por isso, interessante que todas as
iniciativas sejam desenvolvidas empiricamente, assim como prega a Lean Startup. Nesse contexto,
quatro macro processos precisam ser adaptados: a validao de modelo de negcios, a criao de
produtos, a criao de clientes e o ciclo de financiamento.
Entretanto, h algumas diferenas entre a aplicao em startups e em corporaes, e a primeira delas
est ligada estrutura organizacional. Enquanto a startup formada inicialmente apenas por scios,
empresas maiores tm uma hierarquia j preestabelecida. Por isso, a implantao de Lean Innovation
deve comear por determinadas reas, normalmente ligadas inovao, produto ou tecnologia.
Os times durante os primeiros sprints tm uma estrutura Hacker, Hustler, Designer, mas depois se
estruturam como times geis com viso de customer development e escalam de forma matricial, com
alguns papis novos como o PO Fundador e a necessidade de estruturas horizontais focadas em
uma determinada prtica chamadas de captulos. Esta estrutura escala de forma parecida com uma
aceleradora e os times so chamados de esquadres pois tm mais mandato e saem do escritrio.
O oramento destinado ao projeto tambm deve ter tratamento diferente. Startups no foram feitas
para gerar retorno financeiro no incio, mas maximiz-lo no futuro, e projetos inovadores tambm no
deveriam.
As mtricas clssicas como Retorno sobre Investimento no se aplicam fase inicial (seis meses) e
12
algumas vezes tambm no se aplicam nos primeiros anos da startup. O Retorno sobre Capital Investido
(ROIC) deveria ser medido em um espao de 6 a 7 anos (ciclo de abertura e fechamento de um fundo).
Apesar disso, as mtricas de sucesso sero rapidamente quantitativas como volume de clientes,
converso, likes, engajamento, reteno, recomendao e depois faturamento. Estranhamente no
buscamos lucro a curto prazo.
A Lean Innovation diz que o investimento deve ser feito de acordo com patamares de aprendizado.
Para isso, necessrio um comit de investimento, formado por pessoas de diversas reas que, juntas,
geram apoio e alocam recursos de forma progressiva. Ou seja, se a iniciativa atingir os objetivos de
aprendizado, recebe mais investimento.
O veculo sobre o qual a iniciativa est sendo feita pode ser outbound (comea dentro da empresa
e depois vira uma LTDA.) ou inbound (comea numa empresa externa de consultoria e depois
internalizado (na entidade me ou como empresa do portflio).
Investir de forma Lean
Burn rate mensal at atingir um objetivo de aprendizado ou uma hiptese
de negcio previamente validada
O nico controle que necessrio o gasto mensal de caixa e a quantidade
de meses disponveis
O mercado tem que ser grande
Manter como projeto interno ou montar uma LTDA ou S/A depois de
validar o problema (talvez depois de validar soluo)
Por fim, para adotar Lean Innovation a grande empresa no pode se restringir aos padres de processos
e ferramentas. O que vale para a parte madura pode no ser adequado para iniciativas inovadoras.
Novos meios surgem todos os dias e preciso estar atualizado para se manter competitivo.
Normalmente estamos falando de inovao de borda (no limite da corporao) e gradualmente se
demanda a criao de APIs dos servios de negcio da corporao que permitam um ambiente de
inovao aberta. Alavancar estas capacidades muitas vezes doloroso, mas crucial pois muitas vezes
as corporaes tm vantagens competitivas no copiveis que a diferenciam de uma startup.
Ferramentas como open source e cloud computing, por exemplo, eliminam a necessidade de altos
investimentos, tornando-os despesas variveis. Uso extensivo de SaaS para os servios comoditizados
como landing page, atendimento e mtricas permite que a iniciativa se aparelhe muito rapidamente e de
forma gil. O que deve ser desenvolvido sobre IaaS o produto mnimo vivel evoludo continuamente.
A juno de tudo isso constitui a melhor forma de desenvolver um negcio ou projeto digital atualmente,
que pode no garantir o pleno sucesso, mas aumenta consideravelmente a chance de xito.
Esta adaptao um processo contnuo de mudana cultural que tem, na nossa experincia, oito reas
de trabalho:
1. Estabelecimento do ciclo de build, measure, learn;
2. Estabelecimento de mtricas para gerir o portflio e se comunicar com os stakeholders;
3. Criar uma estrutura oramentria que aloque despesas de forma a maximizar os objetivos do portflio
de iniciativas;
4. Permitir o uso de ferramentas open source, cloud computing ou qualquer outra adequada para o
produto, e no necessariamente uma padronizada;
5. Alterar a estrutura organizacional (times matriciais);
6. Criar uma estrutura de governana que permita avaliar o sucesso das iniciativas (baseado em
aprendizado validado), sem comprometer a natureza do portflio;
7. Gerenciar as relaes com as reas e stakeholders externos envolvidos;
8. Dar segurana jurdica e poltica para todos os stakeholders e pacificar a rea jurdica e de suprimentos.
Ou seja, os projetos comeam quando a maioria dos stakeholders acha que acabou.
13
Aprendizados
Alguns conceitos e ferramentas tm uma combinao perigosa de abrangncia, poder e simplicidade
conceitual que levam a uma reflexo imediata de praticantes das mais variadas reas assim que os
aprendem. So comuns frases como Isso tambm pode ser aplicado em... (preenchendo com o domnio
conceitual em que eles esto mais confortveis). Esta reflexo acontece antes que o conceito tenha
sido corretamente entendido e eventualmente fora das condies de contorno nas quais o modelo foi
criado. Isto aconteceu na minha experincia com coisas bem variadas como Mapa de Foras de Porter,
Matriz BCG, SCRUM, Opes Reais e, recentemente, Customer Development & Lean Startup.
O problema dessa abordagem no bvio, mas muito srio. Antes de voc generalizar um modelo,
necessrio um conhecimento profundo dele. Na minha experincia, esse conhecimento no vem
de uma reflexo isolada sobre o tema, mas da aplicao repetitiva em um ciclo de aprendizado que
alimente um mesmo grupo de praticantes. Esse grupo acumula a experincia e reflexes passadas
iterativamente at que se crie msculo intelectual (reflexes validadas e ortogonais) e no gordura
(entendi a superfcie).
Ns passamos por Waterfall em 2000, RUP em 2003, SCRUM em 2007 (depois Kanban), Customer
Development e BMG no final de 2010, Lean Startup, Lean Analytics e AARRR + Inbound Marketing (Web)
2011, Marketing Digital Mobile e Lean Innovation (Lean Startup em corporaes) em 2012.
Quando comeamos a generalizar o modelo de Lean Startup em 2012, tnhamos a nosso favor um
grupo que fazia software junto, como empresa, h 14 anos, e um site SCRUM com cinco anos de
maturidade. O resto era muito recente para ns e para o mercado, ento a trajetria de aprendizado
foi extremamente emprica. Depois desse grande aviso de cuidado, l vo as maiores reflexes que
fizemos neste perodo.
O primeiro ponto que o inimigo sempre interno. Os motivos de falha dos produtos digitais nunca so
externos, a competio irrelevante. Utilizando a metfora da Idea Maze do Chris Dixon, a busca da
validao do modelo de negcio de sucesso como achar a sada de um labirinto: o bom fundador
aquele que consegue, apesar da desorientao natural, tomar boas decises de caminho baseadas em
cada caminhada anterior. Competio s sinal de que tem mais gente no labirinto e que voc deve
estar prximo de alguma coisa. Estendendo a metfora, o minotauro o burn rate, que pode te pegar
antes de voc encontrar a sada.
Existe uma enorme necessidade de facilitao interna com as reas que eventualmente podero receber
o modelo de negcio validado e as reas com poder de veto. O foco tem que sair de funcionalidades
e ir para resultados de negcio, que devem ser comunicados exausto, naturalmente gerando um
empuxo at os tomadores de deciso.
No livro Lean UX, Jeff Gothelf fala shift the conversation of the leadership from features, to outcomes.
Product managers and product owners must determine which business metrics require their attention.
In turn, have conversation around outcomes with managers, this way the shift will inevitably go to the
highest levels of the organization.
Em traduo livre: transforme a conversa entre os lderes em features, em resultados. Product owners
e gerentes de produto devem determinar quais mtricas de negcio requerem sua ateno. Por sua
vez, conversar sobre resultados com os gerentes faz com que, inevitavelmente, as ideias cheguem aos
nveis mais altos da organizao.
Outro ponto que observamos que a principal causa de insucesso e mortalidade de iniciativas a
penalizao do erro. preciso que haja uma mudana cultural drstica na rea de produtos e inovao,
e que os POs e fundadores sejam encorajados a tomar risco. Afinal, com os erros que iteramos e
aprendemos para chegarmos ao sucesso.
Temos que implementar uma nova viso do que gerao de valor e entender conceitos como
contabilidade de inovao e o que aprendemos at agora. Gerar novos intraempreendedores to
importante quanto desenvolver produtos, por exemplo. Uma maneira de precificar essa importncia
procurar casos de fuso e aquisio, precificando esse processo de inovao como uma alternativa a
esses investimentos.
Alm disso, o fracasso uma profecia autorrealizvel. Os times de TI criados em um ambiente waterfall
foram selecionados de forma natural pela sua capacidade de sobreviver a desastres. Com um mtodo
14
de desenvolvimento de produto que tem 14% de chance de sucesso, difcil no entender a posio
deles. Quando o projeto comea a se materializar, fica claro que o pior resultado vai acontecer. Se o
time de negcios (business owners ou analistas) se colocar como cliente do fracasso de terceiros,
viver para fracassar uma nova vez (live to fail another day). Se o time de negcios e dono da viso
se comportarem dessa forma, o fracasso uma
Waterfall
Agile
profecia autorrealizvel.
Ento, pea desculpas, no pea permisso.
Coloque em produo, gere conhecimento
validado e divida isso com o time. Treine, no
espere que o time do cliente se comporte como
POs maduros se eles no viveram isso antes e
nem foram treinados formalmente como tais.
Aprendemos tambm que os produtos mnimos
viveis poucas vezes so realmente mnimos.
O custo poltico de fazer a coisa realmente
9%
29%
57%
49%
42%
14%
Successful
Challenged
Failed
Fonte: The chaos manifesto, The Standish Group
iterativa e emprica no desenvolvimento de produto

percebido como alto demais. O que acontece, na
maioria das vezes, um desenvolvimento gil sem
Customer Development no incio, o que gera no time
uma busca paranoica de ir para produo o mais
rpido possvel. Aqui vale a mxima o projeto comea
quando os stakeholders acham que ele terminou,
ou seja, os primeiros releases em produo. A partir
da primeira verso em produo o PO ou fundador
precisa chavear mentalmente para CustDev e o time
trabalhar com sprints de uma semana ou Kanban.
Faa o projeto numa empresa de propsito especfico, diminua o risco de marca. Consiga o mandato
para implementar um MVP menor e validar proposies centrais no longo prazo. Crie o ambiente para
que o cliente entenda as bases dos processos lean e BMG de validao de problema para que as vises
a virarem MVP venham com nveis melhores de validao de problema.
O mundo com Lean Innovation continua guiado por oramento, mas de forma diferente. O ideal levar em
conta o MVP poltico (gordo) que dificilmente levar menos do que trs ou quatro meses. Depois disso,
podemos usar mtricas de validao de modelo de negcio de startup como base para o oramento.
Por outro lado, o oramento via burn rate com trs linhas (time, cloud e marketing) funciona bem. Por
fim, acredito que o prazo mnimo de burn rate deve ser 12 meses e potencialmente 18, se necessrio.
Para ciclos de validao mais curtos, necessrio um mandato para o time de sair do escritrio no
dia zero, implementar MVPs realmente pequenos e eventualmente decidir sobre pivot, persevere or
close, ou seja, pivotar (mudar a direo), perseverar ou fechar. No ltimo caso, o de fechar, o time e os
recursos dessa iniciativa so realimentados no portflio.
Outro aprendizado: preciso estruturar o time para lidar com a estrutura de governana. Com o tempo,
emergiu a necessidade de uma mentoria adicional aos SMs (Scrum Masters) e POs (Product Owners)
para lidar com os nveis hierrquicos mais altos, que esto longe da ao. O time um eletrom de
msseis polticos, porque est naturalmente exposto a risco. Essa mentoria precisa blindar esse risco.
No fim, os objetivos so duplos: fazer o produto e desenvolver times e esquadres. Se o PO ou fundador
for externo, a corporao vai detectar um DNA de fora e rejeitar o produto quando ele tiver que ser
reinserido no ambiente corporativo para seus novos pais. To importante quanto validar o modelo de
negcios formar POs e fundadores, e esse processo de aprendizado contnuo.
Importante lembrar tambm que voc s deve inserir de volta na corporao produtos com modelos
de negcio validados.
Alm disso, valuation para ativos digitais no uma cincia bvia. A ferramenta habitualmente utilizada
para justificar investimento em corporaes o Fluxo de Caixa Descontado, que busca taxas de retorno
maiores que o WACC (custo de capital mdio ponderado) da empresa. Nesse contexto, avaliaes por
15
paralelo, uso de sries histricas de classes de ativo semelhantes e, talvez, opes reais so mais
indicadas. Tratar o processo de tomada de risco como se a classe de ativo fosse um negcio sem
incerteza ir levar a uma alocao errada de recursos. Se por outro lado a estratgia de investimento
Spray & Pray de Venture Capital americano no aplicvel, existe, na minha opinio, a necessidade de
espalhar risco em um portflio de inovao.
Por fim, aprendemos que o jogo de estrutura e cultura. Deve existir uma estrutura fatorada com
representantes das reas de negcio (futuras receptoras) em comits. Continuo advogando o conceito
de aceleradora corporativa, semelhante estrutura de gil em larga escala explicada pelo pessoal do
Spotify que vamos falar mais para a frente. Tem que haver condies para aparecimento de uma cultura
de tomada de risco e de ownership, na qual curto e longo prazo possam conflitar, mas que a busca de
conceitos necessrios como trao e validao de modelo e aprendizado no sejam mortos em uma
busca prematura de monetizao ou materializao de um produto.
16
Capitulo 5
No fazemos projetos, desenvolvemos produtos!

Consideramos que existem poucas grandes escolas de
desenvolvimento de produtos digitais no Brasil, e esto
concentradas em mdia e em empresas que evoluram
de um datacenter para um portflio de produtos em
nuvem. So companhias que tiveram um imperativo
de inovao claro: lanar produtos digitais de sucesso
ou trocar de negcio.
Se a Globo.com nos levou a ter uma Engenharia gil de
primeira linha e a trazer UX como prtica de primeira
importncia, a Locaweb nos trouxe o Marty Cagan
como referncia. Eric Ries popularizou o conceito
de Lean Startup, mas Marty Cagan e o Silicon Valley
Product Group se tornaram referncia de conhecimento
validado duro sobre desenvolvimento de produtos
digitais. Lean Startup como um livro de divulgao
cientfica, Inspired The Real Deal.
1. Engenharia gil e Cloud

Voc vai ter que aprender a fazer
software direito e gastar pelo menos
20% do seu oramento para mantlo direito (refatorando o produto)
sob pena de se encontrar com
tanto dbito tcnico que o produto
vai parar de evoluir. Isto implica
em inmeras subprticas, mas
destaco as trs mais relevantes, na
minha opinio:
- Desenvolvimento gil (com Scrum,
XP ou Kanban)
- Integrao e Entrega contnuas
- Cloud e Open Source
1
Engenharia
gil
UX
Governana e
Portflio
Grooming
8
Cultura e
Organizao
3
Descoberta
Cliente Produto
Prticas
Desenvolver Produtos digitais

de sucesso requer inmeras
competncias.
Growth
Hacking
4
Execuo
de Produto
As nove prticas
2. UX
As reflexes do resultado de todos os estgios por quais passamos at aqui nos leva a uma reflexo
muito importante: fazer produtos digitais de sucesso uma tarefa herclea, composta de muitas prticas
organizadas sob uma cultura focada no modelo de pensar e de executar do Vale do Silcio. Ao longo da
nossa trajetria, os anti-padres se empilharam e pediram solues que implicavam em novos papis
e novas competncias. Com o desenvolvimento de produtos internos e as subsequentes tentativas de
aplicar Lean Startup em corporao, entendemos que a causa mortis principal dos projetos no era
mais falta de agilidade e engenharia de software, mas a falta de gesto de produto.
Mtricas
Q.A
loucura tentar fazer um produto
sem algum de experincia de
usurio e design. As pessoas tm
que amar seu produto, e esse ponto chave. Acreditamos que o processo de UX tem que obedecer
alguns princpios influenciados por trs escolas: UX tradicional, desenvolvimento gil e lean startup.
preciso focar em resultados (no em entregas); entregar iterativamente solues que organizem a
informao e a experincia de uso de forma rpida; e analisar junto ao time o resultado de negcio
destas entregas. Tambm preciso pouca documentao intermediria, ou seja, nenhum paperware, e
trabalho junto com o time multidisciplinar, saindo do escritrio e focado no problema do cliente. Lotes
pequenos, menos anlise prvia e muito conhecimento validado.
A partir dessa concluso, entendemos que desenvolver produtos digitais de sucesso significa implantar
nove prticas que devem ser aplicadas por ns ou por nossos clientes, com times mistos e sem a cultura
do medo. uma trajetria difcil, mas possvel.
17
3. Product and Customer Discovery

Antes de comear, voc precisa validar o problema que seu cliente quer resolver, o tamanho do
mercado e que tipo de produto voc precisa. Nesta fase, Alex Osterwalder, Steve Blank e Eric Ries
ajudam muito, mas novamente quem tangibiliza melhor o processo o Marty Cagan. Voc descobre e
desenvolve seu cliente descobrindo o problema a ser resolvido e a viso inicial do produto que depois
evolui iterativamente.
Apesar de parecer um processo serial em primeira anlise, Customer e Product Discovery so trabalhos
contnuos e devem ser paralelos execuo de produto feita pelo PO. As novas hipteses que entram
no backlog tm que ser geradas da forma mais cientfica possvel e prxima do cliente, ou seja, juntando
a anlise das evidncias com a proximidade dos clientes (grupos de clientes-chave ou conselhos de
produto). Estas hipteses so validadas com prottipos com dados reais (live data prototypes), que
podem ser de jogar fora ou o embrio do produto. A experincia de uso destes pr-produtos alimenta
o PO e evitam o processo, antes desordenado, de alimentao de novas features no backlog.
Algumas vezes, a descoberta de produto ou o processo de aprender como materializar a nossa proposta
de valor fcil. Em outros casos, extremamente difcil. Considerando nossa experincia, a questo
mais difcil no descobrir quem seu cliente, qual o problema que deve ser resolvido e validar uma
oportunidade de mercado. Na maior parte das vezes mais complicado descobrir a soluo para este
problema, o que independe de quo talentoso seja seu time. Alguns problemas so difceis de resolver,
mas muitos desses problemas difceis so os que valem a pena serem resolvidos.
Esses processos valem para qualquer tipo de empresa, mas devemos destacar que, quando falamos
de grandes corporaes, temos dois postulados no negociveis:
a) se estamos em um ambiente competitivo, precisamos continuar descobrindo novos produtos. Alguns
setores e seus principais participantes tm barreiras competitivas e no competitivas no copiveis, e
neste caso o imperativo da inovao menor pelo motivo errado. A resposta para barreiras de entrada
no copiveis a disrupo do setor e, no Brasil, o trabalho de influncia no arcabouo regulatrio pode
impedir a disrupo.
b) precisamos fazer esse processo de forma responsvel, ou seja, protegendo nossos clientes, receitas
atuais, funcionrios e marca. Apesar do nosso foco em deployment contnuo, existe uma preocupao
com o chamado deployment gentil, ou seja, garantir que as novas verses sejam aceitveis pelo
mainstream, que est acostumado com as antigas. As linhas de receita atuais tm que ser protegidas e
as foras de vendas e operao tm que ser, alm de protegidas, preparadas para a mudana. Produtos
inovadores testam hipteses arriscadas. As estratgias de segmentao (usar grupos pequenos de
usurios) maior ou menor ou empresas de propsito especfico podem ajudar para que eventuais
deslizes no afetem a marca principal.
Para criar um novo produto, precisamos descobrir problemas relevantes em mercados de grande
potencial e de uma validao de oportunidade curta e em srie. Esta avaliao no pode ser feita fora
de contexto, pois estamos falando de um portflio e no de um produto isolado. Se o cliente existe e a
oportunidade deve ser feita, esta etapa deve ser seguida de um processo contnuo de descoberta de
produto, buscando tangibilizar o produto mnimo vivel por meio de prottipos de alta fidelidade para
validao de hipteses. Muito rapidamente, esse processo dever ocorrer em paralelo com o tambm
contnuo de desenvolvimento de produto.
A ideia do Customer Discovery descobrir e desenvolver um grupo de clientes referncia em paralelo
com descobrir e desenvolver o produto. A definio est bastante prxima do customer development
de Steve Blank, no qual voc tem uma base de clientes/usurios efetivos ou em potencial que voc
aborda sistematicamente para saber se suas ideias so vlidas de alguma forma, se so problemas que
valem a pena serem resolvidos ou novas dores relacionadas ao seu produto.
Nesta etapa, duas atividades principais devem ser executadas: descobrir quem nosso cliente e se
estamos envolvidos em um mercado grande o suficiente para alocar investimento. A pergunta-chave
: estamos resolvendo um problema relevante que algum pagaria para que fosse resolvido? E as
respostas para esta pergunta voc s pode conseguir conversando com seus possveis clientes.
Em resumo, voc deve criar uma proposio de valor clara e uma sucesso de Canvas (Lean/Business
Model Generation Canvas) que representem as validaes e invalidaes de hipteses que sero feitas
por meio de diferentes interaes com nosso pblico-alvo. Tais interaes podem ser feitas de forma
18
barata e rpida, por exemplo, por meio de entrevistas, grupos no Facebook e pesquisas. Durante algum
tempo este processo acontece ao mesmo tempo que a Descoberta de Produto, na qual prottipos
com dados vivos cada vez mais sofisticados tentam descobrir como resolver o problema e se esta
soluo vivel.
Com uma viso clara do que o produto mnimo vivel (MVP) e inputs contnuos do processo de
descoberta de produto, temos que desenvolver o produto digital em si, utilizando todas as nove prticas
que estamos evidenciando nesse captulo. Algumas so mais especficas de produto, enquanto as em
azul dizem respeito ao portflio de produto e organizao.
Em empresas estabelecidas, a deciso pivot (mudar de estratgia sem mudar a viso) ou perseverar
feita por meio de prticas de governana de portflio peridicas que decidem investir mais, manter
ou matar determinados produtos. Dentro dessas decises, ainda temos uma diviso que investir
preservando a viso e a estratgia (evoluo natural dos fluxos contnuos de descoberta de produto e
desenvolvimento de produto) ou investir mantendo a viso, mas com outra estratgia, o que seria um
paralelo do pivot do modelo de customer development clssico.
4. Execuo de produto
Da mesma forma que acreditamos que a escolha em startups pivot, persevere ou feche, em corporao
desligue, mantenha, invista seguindo a viso e a estratgia (fluxo normal) ou invista na viso, mas
pivote.
O Product Discovery, por sua vez, vem em seguida: uma vez que j temos as informaes sobre os
problemas e necessidades dos nossos clientes, buscamos o mnimo produto vivel criando prottipos
e executando testes consecutivos para validar o conceito. a partir da que determinamos o conjunto de
caractersticas e interaes e definimos qual produto vamos colocar no backlog para que o time construa.
Time esse formado por trs pessoas: o Product Owner (o dono/CEO do produto), um engenheiro snior
(Tech lead) e um designer de experincia de usurio snior (UX designer).
Com o tempo (normalmente quatro semanas), o trabalho comea a alimentar o backlog do produto e o
time multidisciplinar que est desenvolvendo. Os prottipos funcionais podem ou no ser dispensveis,
mas sempre tm dados reais (vivos) e so a principal ferramenta de comunicao com o time de
desenvolvimento de produto. Esses prottipos representam de forma clara e no contraditria, e devem
responder se a construo do produto vivel.
Deste processo tambm participam os grupos de usurios que melhor representem o pblico-alvo
(subconjunto de clientes com caractersticas em comum) e depois o conselho de usurios (que melhor
represente os heavy users do produto).
Algum vai ter que entender como funciona

o trabalho de gerente/dono de produto. O
Product Owner o CEO, a pessoa que vai
conseguir traduzir a viso e a estratgia em
hipteses e depois em funcionalidades que
sero colocadas no produto. Este trabalho vai ser
organizado em um backlog e em um roadmap
de produto de longo prazo. Os fundamentos
esto na formao do PO dos times geis, mas
rapidamente precisa ser contaminado com a
viso de ciclagem rpida de hipteses que
geram aprendizado. Os ciclos so chamados
de construa, mensure e aprenda pelo Eric Ries
no livro The Lean Startup. A experincia mostra
que o ciclo deveria ser construa, mensure,
analise e aprenda.
Ideas
Learn
Build
Minimize total time
through the loop
Data
Code
Measure
Quando estamos fazendo um teste de DNA do

fracasso no seu produto, ou seja, o que procurar
no seu projeto para tentar preventivamente antecipar grandes desastres, a primeira recomendao
descobrir quem e quo maturo o seu Product Owner. No importa o quanto seu time de engenharia
seja bom, seu pessoal de UX brilhante, seu time de marketing de produto experiente. Se voc no der
a eles algo relevante para fazer, no existe chance de sucesso.
19
Saindo do escopo do projeto e pensando na empresa que mantm e patrocina um portflio de produtos,
a pergunta se generaliza rapidamente para onde encontramos POs?. Este, infelizmente, o recurso
mais importante e mais escasso do ecossistema brasileiro de tecnologia. No livro Inspired, quando
confrontado por esta pergunta, Marty Cagan responde categoricamente: eles j esto na sua empresa,
pedindo para serem encontrados. Com o benefcio do retrovisor, olhando de onde saram os grandes
POs, Cagan parece ter razo. Eles j estavam l, disfarados e escondidos nas mais variadas formas.
Se isto verdade, temos aqui que tentar chegar primeiro nos atributos deste profissional e depois
em como estes atributos se refletem em caractersticas individuais que podem ser procuradas na
sua empresa. Depois de encontrados, temos a parte mais controlada: como medir, treinar, evoluir ou
abandonar estas pessoas. Se o PO o CEO do produto, no h espao para concesses. A partir disso,
seguem algumas dicas a partir de nossas experincias:
- Procure os Border Collies, ou os hypomaniacs apaixonados: depois de um trabalho cientfico extenso,
mostrou no seu livro The Hypomanic Edge: The Link Between (a Little) Craziness and (a Lot of)
Success in America, John Gartner uma correlao entre empreendedores de sucesso e os chamados
Hypomaniacs. Este tipo de perfil obcecado, apaixonado e incansvel quando se trata do objetivo
sua frente. Ele faz o paralelo com a raa de cachorros Border Collies que, apesar de frgil quando
comparada com um Rottweiler, reconhecidamente a mais inteligente e precisa estar fazendo alguma
coisa o tempo todo, ou literalmente come a moblia. POs so hiperativos, apaixonados, esto sempre
rodando pela empresa, so obsessivos com seu trabalho, sempre overworking. Devem ser muito
inteligentes, mas so frgeis contra a truculncia.
- Pessoas com grande empatia com o mercado alvo: a distino aqui, segundo Cagan (novamente),
feita por meio de uma sequncia de perguntas para saber se o seu PO potencial consegue se identificar
e solidarizar com o seu cliente. Tente procurar sinais de infantilizao ou da projeo pretenciosa de
que ele quer iluminar ou trazer luz para aquele nicho de clientes. Isto especialmente importante em
projetos que so ou sero internacionalizveis.
- No traga especialistas de domnio: um PO inteligente consegue entender um domnio novo entre
30 e 60 dias. Um especialista de domnio, apesar de tentador para este projeto porque talvez te faa
economizar algum tempo, pode rapidamente se deformar em um Proxy Customer. Ou seja, ele no
consegue mais aprender porque ele acha que no precisa, ele o cliente e entende mais do mercado
que o cliente. Grandes erros podem advir destas boas intenes.
- Resista tentao de transformar seus Lead devs e seus Senior UX Designers em POs: Ao tentar
trazer seus funcionrios percebidos como os mais competentes para esta posio voc cometer
dois erros crassos: primeiro vai desguarnecer um flanco igualmente importante (Dave Mclure falou de
Hacker, Hustler e Designer e no ou) ou vai fazer com que eles, devido ao seu perfil, performem mal
e se sintam miserveis. Um ambiente sem POs de ofcio s vezes no fica catico porque estes dois
profissionais esto salvando o dia, e pelo menos a casa no est caindo. Tirando uma das fundaes a
histria diferente. Provavelmente, em uma simplificao, os POs que vm de engenharia so melhores
para produtos digitais, mas no so os que eram os melhores engenheiros.
- The smartest kids: este perfil precisa de neurnios. Sem rodeios, isso a. Mas o pacote no pode ser
s esse, ele tem que passar na NO JERK RULE. Steve Jobs era um babaca, mas foi o maior babaca de
todos os tempos no que tange a product management e era CEO da empresa, no do Produto. O custo
do profissional inteligente mas desagregador alto demais para o time. Mande-o para o inferno o mais
rpido possvel. Ser inteligente e se achar inteligente so coisas diferentes. Caso o seu potencial PO
ache que ele a cura para a malria e requeira uma carga de gesto enorme para seu ego, mande-o
para o RH.
A boa notcia que empresas digitais esto cheias de pessoas inteligentes. Voc s tem que bater com
um taco de baseball (no sentido figurado) nos babacas assertivos e separ-los dos que simplesmente
no tm saco para seguir as discusses com eles. Procure aquele olhar de esquece, deixa ele morrer
no deserto, no de derrota.
- tica, integridade: qualquer que seja sua viso de tica e valores, tenha certeza que esta pessoa a
represente bem. No final do dia, fora restries de oramento, ele vai transgredir, improvisar, forar o
envelope da empresa e voc vai esperar isso. Uma pessoa com este tipo de mandato e a bssola moral
apontando para o lugar errado pode gerar prejuzos de marca e custos cveis muito srios.
- Entendimento da empresa e capacidade de comunicao e articulao: alm de tudo o que j foi
20
falado, seu PO tem que ser um articulador, capaz de conseguir que a empresa colabore, ajude, informe
e ensine seu time para que seu produto tenha sucesso. Essa uma qualidade rara, algo como um lder
colaborativo ou algo do gnero.
Onde eles se escondem? Pensei muito se escrevia ou no este pargrafo, mas vamos l: hora de ser
franco. Procure os paradoxos. Se sua empresa elitista, procure o garoto brilhante que reprimido
pelo seu colarinho azul. Se ela sexista, procure aquela mulher que tem brilho nos olhos mas escolheu
deixar esta briga para outro dia porque me solteira. Se sua empresa uma ditadura de vendedores
ou marqueteiros, ache o ltimo engenheiro. Se sua empresa de esquerda, procure um liberal. Em
resumo, a antimatria do PO o assertivo truculento. Seu trabalho como lder destravar potencial,
se ele no estivesse travado este PO potencial j seria PO e eventualmente estaria em seu lugar. Lide
com isso. A boa notcia que este tipo de gente leal e vai entender o valor do julgamento cuidadoso
que voc fez.
E como treinar e desenvolver POs? Apesar de focado na prtica de gesto/execuo de produto, o PO
deve tambm ser um generalista. Ele deve entender profundamente engenharia gil e ter experincia
prvia relevante em times geis. Sugiro fortemente treinamento formal em CSM e CSPO (ou equivalentes).
A leitura dos livros de Steve Blank, Eric Ries, Alex Osterwalder e Marty Cagan so a base, mas ele
precisa ainda buscar conhecimento em analytics, marketing e finanas. Analytics pode ser endereado
por literatura (Lean Analytics) e pelo material de treinamento do Google para web analytics. Analytics
Mobile parece ser um mundo parte e devemos nos aprofundar em ferramentas como Flurry e IDX.
Finanas um domnio por si s, mas ele deve saber o valor do dinheiro no tempo, contabilidade e
fluxos de caixa descontados. Marketing digital tambm tem diferenas srias entre web e mobile, mas
pelo menos o bsico de PPC, PPI, PPM, Mail e redes sociais para se relacionar corretamente com o time
de marketing, alm do marketing de produto, necessrio. Recomendo fortemente o workshop do
Marty Cagan (How to Develop Products People Love).
No existe um desafio de gesto de pessoas maior que esse, na minha opinio singela. O ecossistema
brasileiro de tecnologia ainda cheio de waterfoleiros retardados e os POs potenciais (como aquela cena
do primeiro Matrix, na qual as crianas entortavam colheres) tm que ser achados, testados e evoludos.
Mas se voc CEO, diretor/VP de produto de uma empresa que por algum motivo arcano tem o imperativo
de inovao e desenvolvimento contnuo de produtos nesse nosso capitalismo desenvolvimentista
de laos, no existe nada mais importante do que isso. Se voc acredita em meritocracia, trata-se da
gesto silenciosa do seu processo sucessrio.
5. Mtricas
O mundo de mtricas depende um pouco do modelo de negcios e do canal usado. Existe um modelo
bsico proposto pelo Dave McClure chamado AARRR e que representa seu funil de vendas, mas outras
referncias muito boas so o livro Lean Analytics e, para negcios SaaS, o blog do David Skok.
Em relao a ferramental web temos, alm do Google Analytics, o Kissmetrics, e o MixPanel. Para mapas
de calor o CrazyEgg funciona bem. Se seu produto mobile, por outro lado, o Flurry muito bom, mas
d para passar com o Google Analytics tambm. importante procurar material sobre como estruturar
segmentao de clientes (cohorts, em ingls) para evitar a sndrome do valor mdio e para que os
nmeros te digam alguma coisa.
Micro- Economics
(per customer
profitability)
CAC
LTV
Revenue
Profitability
Overall
Profitability
(Accounting)
Expenses
MRR
Services
Revenue
COGS
Revenue per
Employee
Profitability per
Employee
Expenses per
Employee
21
6. Quality Assurance
Garantir a qualidade de qualquer produto mobile essencial, e por isso QA uma prtica imprescindvel
para o desenvolvimento de produtos digitais. A agilidade prega que os testes sejam realizados a todo
momento, como forma de validar as hipteses que estabelecemos. Em mobile, especificamente, o QA
ainda mais crtico. Isso porque importante fazer tudo o que for possvel para que um erro no aparea
depois que o aplicativo j estiver disponvel na App Store. Neste sentido, todos os testes, sejam unitrios,
funcionais ou de integrao, devem ser feitos em nmeros adequados para garantir a qualidade.
7. Growth Hacking e Product Marketing
Neste momento, voc est buscando trao para seu produto. Ento, ter que utilizar seu oramento
de marketing com sabedoria. A palavra-chave que toda campanha tem que ser medida, tem que ter
uma hiptese de negcio relacionada e tem que ter oramento limitado. Com o resultado medido de
cada campanha, voc monta um portflio iterativo e continuamente otimizado de apostas que devem
aprender com as aes anteriores.
f) Para mobile temos duas modalidades principais: ou voc compra instalaes PPI e conta com a
inteligncia da empresa para posicionar seus anncios como JAMPP em mais de 400 redes de anncio,
ou faz isso voc mesmo;
g) Viralidade: gosto muito do Neil Patel e do material que ele produz sobre a anatomia da viralidade no
blog Quicksprout;
h) E-mail marketing: ferramentas como Mailchimp podem te atender durante muito tempo;
i) Fora de vendas: ferramentas como o Pipedrive ou Salesforce funcionam bem, procure literatura
especfica sobre o que funciona no seu setor.
8. Cultura e Organizao
a) PPC, pagar por click em redes sociais como LinkedIn ou buscadores como o Google. Vale estudar
como funciona a questo de remarketing (marcao do cliente e uso de peas direcionadas);
Alm da questo direta de como implementar uma estrutura matricial centrada nos times e seus POs,
o tema central aqui tambm Cultura. Se no eliminarmos a cultura do medo no conseguiremos fazer
produtos. Definidos os papis, existe uma problemtica de desenvolvimento pessoal na qual a mistura de
treinamento e mentoria continuada chave. Essas pessoas, alm de organizadas em times, estaro em
outra estrutura ortogonal que organiza conhecimento e participantes com responsabilidades comuns
(captulos ou reas). Isto pode ser to amplo como juntar toda a engenharia, infra/devops, QA, UX,
Mtricas e Marketing de Produto em grupos ortogonais aos times, mas muito dependente de cada
situao. Podemos simplificar em alguns temas:
b) PPM, banners e contedo;
- Papis e responsabilidades;
c) Redes sociais, aes de engajamento orgnico via contedo e promoes de posts no Twitter,
Facebook e outros;
- Capacidades e habilidades;
Para cada tipo de modelo de negcio voc tem ferramentais mais adequados. Mas em uma viso geral
temos:
d) Marketing de contedo: pode fazer muito sentido ter um blog, um canal no Youtube e uma presena
forte no Pinterest. O sucesso neste caso proporcional a trs fatores: a utilidade, a qualidade e o quo
inusitado o contedo.
e) SEO e SEM: otimizao de mecanismos de busca so importantes tanto para buscadores quanto
para as app stores. Entender os algoritmos chave;
- Cultura de inovao (pessoas podem errar?)

- Estrutura organizacional (dedicada, multidisciplinar, empowered, times autnomos)
A maturidade dos times e das empresas pode ser medida pelas perguntas que so feitas. Quando voc
para de perguntar o que fazer e como fazer e v que a pergunta certa por que fazer, talvez voc
esteja comeando a entender a extenso da trajetria do que ignoramos.
22
Temos um ecossistema de engenharia de software de primeira linha (pequeno, mas de classe mundial),
temos investidores maduros que entendem como ningum como lidar com volatilidade e temos um
mercado grande e quase virgem.
meses e geravam muito papel, material que tentava antecipar tudo que o sistema deveria ter e de
que maneira. Depois do cdigo implementado, ainda tnhamos as fases de testes integrados e no fim,
quando entrava em produo, muitas vezes o projeto no atendia o que o usurio final precisava.
Nosso calcanhar de Aquiles uma incrvel incapacidade de entender como se faz produtos digitais,
como ciclar rpido e produzir coisas como o Whatsapp, o Netflix e o Google Glass ou como manter
times realmente multidisciplinares trabalhando de forma tima durante 24 ou 26 meses at produzir
produtos que as pessoas amem. O desafio enorme, mas o prmio tambm .
Esse problema tinha duas causas principais: ou demorou muito para ficar pronto e o negcio mudou
ou o projeto no previu determinado cenrio. Resumindo, o nvel de sucesso era baixssimo. Com o
surgimento do movimento gil, adotamos mais agilidade no desenvolvimento e decidimos que o time
no deveria ficar preso a vrios processos que s faziam o desenvolvimento das solues ser mais
burocrtico.
9. Governana, portflio e grooming

Este tema tambm bastante complexo. O trabalho de portfolio grooming tem que ser complementado
com ciclos de inspeo e comunicao na estrutura de produto da empresa e mais acima, nos nveis de
diretoria e board. Esse processo de grooming tem algumas sub-prticas principais:
- Avaliao de ativos digitais e intangveis;
- Innovation Accounting: foco em aprendizado validado e trao;
- Gesto e otimizao de portflio e alocao de recursos como uma startup (rounds);
- Oramento para novos produtos;
- Gesto do burn rate e portes peridicos de avaliao de deciso de investimento;
- Reunies semanais e mensais com os POs e PMs e trimestrais com a diretoria e board;
Mas, enfim, qual a diferena entre projeto e produto?
Um produto comea quando um projeto termina: essa frase resume muito bem a diferena entre os
dois conceitos, mas vamos voltar um pouco no tempo para explicar com mais detalhes. J falamos um
pouco no incio desse livro que projetos so abordados de maneira waterfall, ou seja, s se seguia
para a prxima fase quando terminava a anterior. Esses projetos demoravam muito tempo at ter algum
cdigo disponvel. Era necessrio passar por fases de requisitos e design que muitas vezes demoravam
O gil trouxe uma nova abordagem aos projetos, passamos a entregar mais rpido e o nvel de sucesso
aumentou consideravelmente. Entretanto, uma coisa ainda no estava endereada: estvamos
entregando softwares que realmente agregavam valor ao cliente final?
essa a pergunta que a abordagem de produto que defendemos atualmente responde. Buscamos
muitas referncias sobre o assunto, praticamos, aprendemos e chegamos concluso de que na viso
de produto o que interessa entregar software em produo, rpido e com algo que faa sentido para
seu stakeholder.
Um produto digital s comea quando entra em produo, pois apenas nesse momento que podemos
colher dados e ver qual direo os clientes apontam para seu avano. Por isso, preciso colocar um
produto em produo o quanto antes, e a fase de projeto deve ser a mnima possvel. Facebook, Amazon,
Google e todas as gigantes do mundo digital trabalham dessa maneira, e inegvel o nvel de sucesso
que elas apresentam. As entregas de projetos muitas vezes no so aderentes aos clientes justamente
por essa falta de mtricas e testes.
Os projetos costumam ter incio, meio e fim, ou seja, uma viso de longo prazo com previses do que
pode acontecer no meio do caminho. Os produtos, diferentemente disso, evoluem a todo momento.
Cada avano do produto baseado em muita mtrica colhida de seus clientes. Afinal, ningum melhor
para dizer a direo que o produto deve tomar do que as pessoas que realmente vo utilizar.
23
Enquanto o escopo de um projeto fixo, o escopo de um produto varivel. Enquanto no projeto

normalmente voc define qual time trabalhar, quanto voc vai gastar e em quanto tempo ele estar
pronto, em um produto a viso de longo prazo. O ideal ter um time trabalhando e evoluindo aquele
produto pelo tempo que o produto existir. Costumamos dizer que em software s conseguimos controlar
duas dentre as variveis tempo, custo e escopo. Se no quisermos abrir mo da qualidade, preciso
variar o custo ou o tempo de entrega.
Por fim, vale lembrar que um projeto fica pronto em algum momento. Isso no acontece com um produto,
que est sempre em evoluo. Melhoramos, adicionamos features, vemos que determinada funo no
adequada e assim vamos tornando um produto cada vez melhor. A evoluo constante.
24
Capitulo 6
Prticas, Papis e Plataforma

Atualmente, os produtos digitais so bem representados por aplicativos mobile. Isso porque essa rea
se tornou imprescindvel para qualquer negcio digital. Em 2016, faz 10 anos desde que fizemos nosso
primeiro projeto mobile. Neste perodo, passamos pelo surgimento do smartphone, pela criao do
iPhone, pela transformao do touchscreen em regra e agora estamos vivendo a internet das coisas, o
surgimento dos wearables e nos dando conta de que o mobile est comendo o mundo. Essa trajetria
nos proporcionou muitos aprendizados interessantes.
Comeamos desenvolvendo para WAP (Wireless Application Protocol), em um longnquo 2005, e
passamos pelo web mobile adaptativo antes de chegar finalmente aos aplicativos mobile e design
responsivo. Tambm aprendemos, considerando nossa expertise em e-commerce, que a experincia
multicanal era uma demanda importante, e por isso criamos a CloudRetail, que tem o objetivo de oferecer
a melhor experincia mobile para o varejista.
1. As prticas
A partir dessa experincia, chegamos concluso de que nove prticas so essenciais em
desenvolvimento mobile. Ns j falamos sobre elas em um captulo anterior: engenharia gil, porque o
modelo que mais funciona para entregar o produto certo no tempo certo; UX, porque preciso entender
a experincia do usurio para ter sucesso com um aplicativo mobile; descoberta de cliente e produto,
porque antes de comear voc precisa validar o problema que seu cliente quer resolver, o tamanho do
mercado e que tipo de produto voc precisa; execuo de Produto (ou BML Build, Measure e Learn),
pois preciso traduzir a viso e a estratgia em hipteses e depois em funcionalidades que sero
colocadas no seu aplicativo, com uma viso mais geral e estratgica; growth hacking, porque voc
tem que buscar trao para seu produto e usar seu oramento de marketing com sabedoria; mtricas
porque toda campanha tem que ser medida, tem que ter uma hiptese de negcio relacionada e tem
que ter oramento limitado; cultura e a organizao da empresa, que devem estar alinhadas com a
governana. Se no eliminarmos a cultura do medo e organizarmos a estrutura das equipes considerando
conhecimento e responsabilidades, no conseguiremos fazer produtos. E o trabalho de governana, ou
portfolio grooming, tem que ser complementado com ciclos de inspeo e comunicao na estrutura
de produto da empresa e, mais acima, nos nveis de diretoria e board.
Por fim, em mobile, especificamente, o QA (Quality Assurance) torna-se essencial. Isso porque importante
fazer tudo o que for possvel para que um erro no aparea depois que o aplicativo j estiver disponvel
na App Store. Neste sentido, todos os testes, sejam unitrios, funcionais ou de integrao, devem ser
feitos em nmeros adequados para garantir a qualidade.
2. Os papis
Para garantir que essas prticas funcionem, precisamos de um PO (Product Owner), que tem a viso
estratgica e geral do produto organizando o backlog e o time e sobre o qual j falamos no captulo
anterior; um Scrum Master, que garante que o framework scrum seja aplicado corretamente e que as
prticas e as regras de um time gil estejam ocorrendo, alm de remover impedimentos que o time
encontre e garantir a governana adequada para o cliente; um Devops, responsvel pela arquitetura em
nuvem infraestrutura do projeto; e um ou mais Devs, que vo efetivamente desenvolver o aplicativo.
Alm destes, so importantes tambm o profissional de QA (Quality Assurance), que como o prprio
nome diz vai garantir a qualidade do aplicativo por meio dos testes automatizados em emuladores e
devices; o de UX (User Experience), responsvel pelo design e por garantir que a experincia do usurio
seja excelente; e o Growth Hacker, que vai cuidar da aquisio, ativao de usurios, analisar as mtricas
e fazer o marketing do seu aplicativo.
Esses sete papis so complementares e devem trabalhar juntos na elaborao do produto. Reunies
dirias e frequentes inspees e validaes de hipteses geram aprendizado e agilidade para desenvolver
o aplicativo certo.
PO
UX
QA
Devs
Growth
Hacker
DevOps
Scrum
Master
25
3. A Plataforma
Por fim, a tecnologia! Para garantir a qualidade e a funcionalidade de um app mobile, preciso contar
com um arsenal de ferramentas. Aqui na Concrete Solutions desenvolvemos uma plataforma aberta de
desenvolvimento de aplicativos mveis (OMADP), que junta o que consideramos de melhor em cada
rea com mdulos desenvolvidos na Concrete. A plataforma est um pouco resumida nos quadros
abaixo. Lembrando que somos uma empresa agnstica e no temos preconceito com nenhuma das
tecnologias.
Entretanto, sempre bom lembrar que fazer o produto mobile certo do jeito certo uma trajetria de
aprendizado dinmica, aprendemos todos os dias. Alm disso, o cenrio mobile mundial muda a cada
perodo, com novidades a qualquer momento. por isso que consideramos que a forma adequada de
fazer mobile hoje pode mudar amanh, e estamos atentos a qualquer fator que altere o que aprendemos.
Jenkins, Maven,
Bots, cocoapods,
GIT
Mobrelease,
Estao
MacOS de CI
Junit,
Specta,
Cucumber,
calabash,
TestCloud,
estaes de
QA IOS,
Android
Newrelic
Jmeter,
crashlitics, GA
Jmeter
Integrao
deployment
contnuo,
controle de
dependncias,
build
automatizado,
versionamento
Testes
unitrios
Testes
funcionais
automatizados
em emuladores
e devices
Testes de
performance e
robustez
Testes de
integrao
Jira,
greenhopper,
TS, Google docs,
confluence
Invision
Parse,
(MBaaS),
GA, ADX,
Google tag
manager,
Crashlitics,
Newrelic
Hubspot,
Adx/Flurry,
Distimo,
Appannie
Invision,
Guidelines
de UX
Gesto de
portflio,
Gesto
de produto,
Governana
Product
discovery
Monitor:
Converso,
Crash,
Atribuio,
performance
Aquisio,
Ativao,
Reteno,
Appstore
optimization
Mobile UX
Dashboard, Relatrios, anlise de causas raiz, indicadores
Dashboard, Relatrios, anlise de causas raiz, indicadores
26
Capitulo 7
Silicon Valley is coming

Nos ltimos anos, o movimento gil foi abraado com grande interesse no Brasil, e agora comea a
encontrar desafios mais complexos relacionados implantao de gil em escala. Grandes escalas
trazem consigo a necessidade de organizar novas estruturas de produto, com mudanas radicais de
cultura e governana, o que vai ser um desafio de grande complexidade para os prximos cinco ou dez
anos no Brasil corporativo.
Dimenso econmica
Acredito que estamos passando por um momento de esgotamento de um modelo competitivo no
Brasil. Recentemente, Luis Stuhlberger pontuou que a carga de tributos governamentais subiu 15%
sobre o PIB desde a Constituio de 1988, tendo sido canalizada para distribuio de renda de um lado
e financiamento subsidiado de longo prazo no outro. Este modelo gerou algum crescimento econmico
relacionado ao aumento de consumo, mas se esgotou e parece que teremos agora que sobreviver a
um ajuste de contas pblicas associado a uma tentativa de reativao do mercado de crdito de longo
prazo privado.
Os efeitos deste modelo econmico geraram um cenrio de estagflao que poder levar vrios anos
para se desfazer. Questes como a dificuldade do reequilbrio fiscal, a iminente quebra do mercado
imobilirio (como descrito pela pesquisa da Empriricus Research, devido ao esvaziamento da caderneta
de poupana como lastro do financiamento e o paradoxo da impossibilidade de aumento do valor da
taxa referencial) nos levam a uma anlise nada otimista dos prximos anos.
Dimenso competitiva
Este modelo competitivo com grande participao do Estado, seja na matriz de financiamento ou no
estabelecimento de polticas de proteo regulatrias e tarifrias, se esgota ao mesmo tempo em que
enxergamos uma enxurrada de incumbentes e players estrangeiros estabelecidos em reas como
mdia (Google), economia do compartilhamento (UBER, EasyTaxi, AirBnb), financial technology e financial
services unbundling (Paypal, Nubank).
Usando a frase clebre de Marc Andreessen, software is eating the world e sua atualizao feita por Ben
Evans, mobile is eating Software, como prefcio, o que acontece com nossa capacidade competitiva
no cenrio de estresse descrito acima se no sabemos fazer software?

Se precisamos reagir com agilidade a alteraes no cenrio externo e que a economia est se
digitalizando, uma hiptese que para competir no ambiente de tecnologia precisamos criar
organizaes de aprendizagem, como disse Peter Senge. Se isto for verdade, uma maneira de comparar
a competitividade seria medir a distncia que estamos da concorrncia em anos. Podemos dizer ento
que, sob essa tica, estamos em algum lugar como:
a) 70 anos de distncia, se medirmos o tempo entre a gnese do Vale do Silcio na 2 Guerra Mundial;
b) 48 anos, se levarmos em conta quando foi publicado o artigo Como Desenvolver Software de Larga
Escala?, de W Royce, que a base para a metodologia waterfall que predomina no pas;
c) 15 anos, se levarmos em conta o Manifesto gil.
Proposta
Uma das dificuldades para analisar o DNA do Vale do Silcio seu silncio. Os incentivos do Vale esto
na criao de unicrnios (empresas de USD 1 bilho), e no em explicar como isso feito. Depois da
euforia inicial, livros como The Lean Startup so s para cincia, ou seja, idiotizados o suficiente para
que sem muito esforo tenhamos a sensao de uma epifania.
Juntando as peas, a hiptese simplificadora que trabalhamos que o DNA do Vale uma juno de
quatro fatores principais que podem influenciar a competitividade brasileira: estrutura de financiamento
baseado em Venture Capital e amplas possibilidades de sada, Mtodos geis, Lean Product
Management e OKR (Objectives and Key Results).
A assertividade da proposta no o objetivo. Ela s uma soluo inicial a partir da qual podemos criar
um processo de melhoria emprico no sistema que, a longo prazo, leve a otimizaes reais.
Como no podemos fazer muito sobre a estrutura de financiamento, pois no enxergamos uma
diminuio do Estado na economia e sua consequente obliterao da criao de estruturas privadas de
financiamento e sada no futuro prximo, devemos focar nos outros trs fatores. A proposio de valor
da Concrete Solutions desenvolver produtos digitais de sucesso para seus clientes e ser um vetor
27
indireto de mudana cultural. O hacking cultural causado pela criao de casos de sucesso dentro das
corporaes, quando associado a um apoio executivo claro, pode criar um gradiente de mudana a ser
perseguido internamente pela organizao cliente.
contexto. Scrum tem quase dez anos, Lean Product Management como uma evoluo natural de Agile
Product Management tem cinco e OKR s um. J falamos bastante nesse livro sobre como gerenciar
produtos e viso de produtos. Agora, vamos focar um pouco em gil em escala e OKR.
Hoje, na Concrete Solutions, temos um framework amplo de abordagens iterativas e incrementais que
enderea Como Fazemos (Scrum), O que fazemos (Lean Product Management) e, mais recentemente,
em que escala fazemos (Spotify/Nexus/SPS) e com quais objetivos e mtricas geis (OKR).
gil em escala
Como natural, crescemos consideravelmente nestes ltimos 15 anos. Recentemente, fizemos algumas
alteraes na estrutura organizacional e emergiram melhoras de fluxo e cultura nos times que afetaram
positivamente o sistema, criando um surto de crescimento no segundo semestre de 2014 e culminando
no crescimento de 165% no ano fiscal de 2015. Neste cenrio, chegamos ao desafio de como escalar
uma estrutura gil de desenvolvimento de software que consiga abranger mais de 50 times, seja autoorganizada e tenha poucos nveis hierrquicos, sem interferir na qualidade e na cultura.
Com esse desafio, fomos procurar as opes j estudadas pelo mercado e encontramos algumas
iniciativas, como essas que foram comparadas por Richard Dolman e Steve Spearman ( http://www.
infoq.com/news/2014/07/compare-agile-scaling ). A tabela deles fala, no mnimo, de sete mtodos:
Scrum of Scrums (SoS), Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Disciplined Agile
Delivery (DAD), Drive Strategy Deliver More (DSDM), Recipes for Agile Governance (RAGE), Scrum at
Scale e, por fim, a que mais nos interessou, chamada de Spotify Model. Nossa percepo a de que os
outros seis modelos propostos tm uma teoria bem fundada, mas so pouco prticos. Para ns, o que
serviu de inspirao foi o modelo do Spotify, que vamos explicar em detalhes mais frente.
Lembrando que os ciclos de mudana tiveram velocidades muito diferentes e foram afetados pelo
Assim que comeamos, nossa prtica era baseada em times de engenharia que respondiam diretamente
a um scio. Neste experimento, o papel de Product Owner (dono do produto) ficava a cargo de nossos
clientes. Oferecamos o time multidisciplinar e o cliente coordenava esse time e o produto a ser
desenvolvido. Entretanto, a falta de uma estrutura de produto formal na maior parte das empresas
acabou se tornando um desafio, porque sobrecarregava o scio que tinha que manter inmeros backlogs
alm de desempenhar o papel de Scrum Master. Neste perodo passamos tambm a ter mais contato
com algumas referncias de produto e chegamos concluso de que a nossa funo a gesto gil
de produtos, no apenas a organizao de times multidisciplinares.Era a hora de adotar o papel de PO e
trabalhar com ele dentro do time. Passamos, ento, da prtica de engenharia a uma prtica de produto.
28
Experimento 1
Scio
Scio
Experimento 2
Scio
Scio
PO
Scio
PO
Scio
PO
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
Scrum Master
UX
UX
UX
UX
UX
UX
Devs
Devs
Devs
Devs
Devs
Devs
QA
QA
QA
QA
QA
QA
DevOps
DevOps
DevOps
DevOps
DevOps
DevOps
O modelo funcionou bem at determinado nmero de pessoas. Com o aumento do time e o surgimento
de cada vez mais novos projetos, as figuras dos POs e dos scios ficaram sobrecarregadas com tantos
reports e com a necessidade de apoiar a melhoria continuada das pessoas e dos times e tivemos que
procurar uma forma de escalar a estrutura at chegarmos no modelo do Spotify, que detalhamos a
seguir.
Em linhas gerais, o experimento 1 mostrou uma escalabilidade de clulas de at 20 pessoas e o
experimento 2 de at 50. Uma varivel que tambm foi modificada no segundo experimento foi a quase
totalidade de times com integrao e deployment contnuo e o uso extensivo de testes automatizados.
Essa melhoria de fluxo e diminuio do lote tambm permitiu que a estrutura o experimento 2 escalasse
mais.
As clulas base da Concrete atualmente so quatro prticas, determinadas por domnio tecnolgico ou
critrio geogrfico (uma vez que temos escritrio no Rio e em So Paulo). So elas: Cloud, Web/API So
Paulo, Web/API Rio e Mobile. A ideia que cada uma dessas clulas tenha uma rea de produto e uma
rea de engenharia. Os membros de cada clula no precisam necessariamente estar no mesmo lugar,
so razoavelmente auto-organizados e autogeridos e usam as mesmas tecnologias.
No contexto atual da Concrete, todas
as clulas tm pelo menos um scio
responsvel pela rea de produto
e/ou engenharia. Note que a clula
de Cloud no dividida e isso
acontece porque cloud computing
no gera um produto, mas ajuda no
desenvolvimento dele.
Produto
Produto
Produto
Engenharia
Engenharia
Engenharia
Web/API SP
Web/API RJ
Mobile
Engenharia
Cloud
A Concrete Solutions vende times multidisciplinares que tm o objetivo

de desenvolver e evoluir um produto para um cliente. Para que
possamos ser efetivos nesse posicionamento, temos que garantir que
um conjunto mnimo de papis esteja sempre includo no time. Esse time
pode sofrer algumas variaes dependendo da necessidade ou no de
desenvolvimento de uma API ou de tecnologias envolvidas. Ao lado,
segue um exemplo de time mobile padro. Dentro do possvel, tentamos
manter os times trabalhando juntos durante um longo perodo de tempo
(times estveis).
Considerando que as prticas so divididas em Produto/Engenharia,
(Web/API SP, Web/API RJ e Mobile), surgem dois papis de gerenciamento para cada uma delas. O primeiro deles o Product Manager (PM),
que o responsvel por gerir todos os POs da prtica e a rea de produto como um todo. O Head de Engenharia cuida do restante do time,
formado pelos desenvolvedores, Scrum Master, DevOps, UX e o QA.
Clula
Mdia
Product Owner (PO)
50%
User Experience (UX)
Scrum Master (SM) 50%
iOS
Desenvolvedores
Windows
Android
QA
DevOps 25%
29
O grupo de pessoas que desenvolvem

a mesma funo formam um captulo,
grupo horizontal, que tambm se
relaciona entre si e tem seus processos
de desenvolvimento. Normalmente
temos o captulo de UX, de QA, de
desenvolvedores em geral (Android,
iOS, etc), de Scrum Master e de DevOps
(este ltimo representado pela prtica
de Cloud/Devops).
Dentro do captulo geralmente surge
uma ou mais figuras de destaque,
chamadas de chapter leads, que so
aqueles que tm mais fluncia em
uma rea tcnica do domnio do grupo,
compartilham conhecimento e nivelam
todos os membros. Por exemplo, nos
nossos times mobile temos um chapter
lead de Android, um chapter lead de
iOS, etc. Este papel tem um carter de
professor, mas no de gerente.
PM
Produto
PM/ Head
de produto
PM
PO
PO
PO
PO
PO
Engenharia
PO
PO
(...)
PO
PO
PO
(...)
Head Engenharia
(...)
UX
UX
UX
UX
UX
UX
(...)
UX
UX
UX
UX
Devs
Devs
Devs
Devs
Devs
Devs
(...)
Captulo
Devs
Devs
Devs
Devs
(...)
QA
QA
QA
QA
Captulo
Head
Engenharia
QA
QA
QA
QA
QA
QA
(...)
DevOps
DevOps
DevOps
DevOps
DevOps
DevOps
(...)
DevOps
DevOps
DevOps
DevOps
Scrum
Master
Scrum
Master
Scrum
Master
Scrum
Master
Neste ponto, lembramos que existe

uma prtica de DevOps, que chamamos
de Cloud, na qual o lder de captulo
o Head de Engenharia. Outro lembrete que vale a pena destacar o papel de UX, que na prtica
responde tanto para a rea de produto (uma vez que participa dos processos de Product e Customer
Discovery) como para a rea de engenharia.
Scrum
Master
Chapter
Lead
Scrum
Master
Scrum
Master
Scrum
Master
Scrum
Master
Scrum
Master
Time
No prximo passo, o PM responde para um Head de Produto, que fica um nvel hierrquico acima, mas
comanda tambm um grupo de POs. Finalmente, como escalar? Basicamente, a escalabilidade uma
questo simples de nmeros. Com essa estrutura definida, podemos chegar at a 8 POs para um PM.
Informalmente, chamamos nossos times de times de pizza, aqueles que podemos alimentar com uma
pizza (ou seja, oito posies). Se um PM chega at oito POs, com at 10 pessoas nos times abaixo de
30
cada PO, so cerca de 80 pessoas abaixo de um PM. Na estrutura mencionada acima, a entrada de um
Head de Produto permitiria que a prtica tivesse em torno de 16 product owners e consequentemente
at 160 pessoas. Entretanto, destacamos que o nmero de dezesseis times abaixo de um Head de
Engenharia pode ser um pouco alto, o que ainda no foi validado. Vai depender do nvel de fluncia
de cada time, de quo bem funcionem os Chapter Leads e do nvel de heterogeneidade tcnica dos
produtos sendo feitos nessa prtica. Entretanto, nosso clculo nos leva a um limite terico de 80 a 160
pessoas por prtica, o que na Concrete equivale a um total entre 300 e 500 pessoas nas quatro prticas
atuais.
Quando chegarmos a esse nmero ser a hora de criar novas prticas, novos sites e as figuras de diretor
de produto, que ser o responsvel por todos os PMs, e do diretor de engenharia, que cuidar dos
heads de engenharia. Acreditamos que o ltimo nvel seria a criao de um VP de produto, afinal nossa
preferncia manter poucos nveis hierrquicos.
Fluncia dos times
Com base na evoluo e aprendizado dos nossos prprios times, chegamos a um modelo de maturidade
que se aplica na companhia como um todo, time a time, para tentar manter a garantia de qualidade.
Chamamos esse modelo de 4Ps: Prticas, Papis, Plataforma e Produto. J falamos de cada um desses
tpicos anteriormente, mas agora a inteno mostrar como avaliar a fluncia em cada um deles.
Para medir o nvel de fluncia dos times, aplicamos o modelo de maturidade de forma peridica. Primeiro,
avaliamos os papis. O time tem todos os papis? Os papis tm nveis de senioridade adequados?
um questionrio simples e fazemos quase que intuitivamente. Depois, hora de avaliar se as prticas
esto sendo cumpridas, e prticas e plataforma so acertadas ao mesmo tempo, em paralelo. Afinal,
no tenho como testar sem saber fazer integrao contnua, deployment contnuo, etc. Todas essas
variveis geram uma nota, ou um nvel de fluncia, que vai de zero a quatro.
Mas claro que cada membro do time avaliado de forma individual, considerando tambm o modelo
de maturidade. Dois exemplos que valem a pena serem ressaltados so a avaliao do Product Owner,
que passa por seis reas, e do Scrum Master, avaliado em cinco instncias. Enquanto o primeiro
medido pela fluncia na rea de domnio, marketing & analytics, UX e engenharia, alm de gil e lean,
Engenharia
gil
Governana
Portflio
Grooming
User
Descoberta de Mtricas
Experince produto/cliente
Growth
Hacking
QA
Cultura e
Organizao
Execuo
de Produto
Prticas
Quality
Assurance
Prossional
DevOps
Product
Owner
Scrum
Master
User
Experience
Prossional
Descobrir
Monitorar
Integrar
Build
Desenvolver
Deployar
Produto
Growth
Hacker
Coder
Testar
Papis
Plataforma
Engenharia
Engenharia
UX
Lean
gil
PO
gil
rea de
conhecimento
Framework
Scrum
(Facilitao)
Marketing UX
&
Analytics
PO
Remoo de
Impedimentos
Governana
& Poltica
SM
31
o Scrum Master avaliado considerando engenharia, capacidade de facilitao do framework Scrum,

remoo de impedimentos e governana e poltica, alm, claro, de gil.
Desafios
Ainda estamos conversando bastante sobre as atividades de sincronizao e gesto da interdependncia
de projetos. Afinal, temos clientes com portflios de produtos web e mobile, que misturam times, POs
e Heads de engenharia. No nvel em que estamos, ainda conseguimos manter muitas conversas one
to one, tanto entre os mesmos papis quanto entre os gestores. Mas ao chegar em um nmero mais
elevado de pessoas pode ser que esse esquema no funcione mais.
Tambm temos uma questo importante de cultura. Quando os captulos so menores mais fcil passar
conhecimento por meio de Hangouts, eventos, conversas informais e at em happy hours. Conforme
o time vai crescendo essa facilidade vai diminuindo pouco a pouco e teremos que pensar em novas
prticas para compartilhar conhecimento e nivelar os times.
Para as excees, em especfico quando estamos falando de produtos com mais de cinco times,
recomendamos a adoo de prticas de SPS (Scaled Professional Scrum) da Scrum.org, com a criao
de um time de integrao e um Nexus.
O aumento de escala levou a uma dificuldade de comunicao e alinhamento de objetivos e mtricas,
o que estamos comeando a enderear com OKR.
32
Capitulo 8
OKR (Objectives and Key Results)

*por Felipe Castro
A princpio, parece que OKR um componente crtico, sem o qual no conseguimos lidar com os
paradoxos de autonomia e caos, autonomia e alavancagem e autonomia e misso, como expostos por
Marty Cagan nos seus artigos recentes.
O tradicional processo de planejamento anual todos ns sabemos como funciona: h um retreat
corporativo no qual o planejamento estratgico acontece e as metas da companhia so definidas.
Ento, nas prximas semanas as metas so cascateadas pela organizao, criando um plano detalhado
e fixo para o ano para a companhia como um todo. comum a previso de revisar o plano em seis
meses, mas a maioria das empresas no o faz, pois levaria tempo demais.
Se os seus times esto trabalhando em iteraes (ou sprints) de uma a quatro semanas, saindo do
prdio para falar com clientes, testando hipteses e aprendendo o que funciona e o que no funciona,
como voc pode usar um conjunto esttico de metas? A resposta : voc no pode.
Nassim Taleb, autor do The Black Swan, compara este modelo com os planejadores centrais do Kremlin,
que criavam planos quinquenais acreditando que eles podiam prever o futuro. Tem que haver outro
caminho. No artigo para a MIT Sloan Management Review Should You Build Strategy Like You Build
Software?, Keith R. McFarland escreveu: (traduo livre)
Como a estratgia s pode capturar o melhor pensamento da companhia em um determinado ponto
no tempo, ela (assim como um software) precisa ser refinada e melhorada na medida em que as pessoas ganham e distribuem novas experincias e conhecimento. Dada essa realidade, um processo slido de desenvolvimento de estratgia deveria permitir que uma companhia crie e adapte a estratgia
rapidamente e iterativamente, e aloque recursos em ambientes em mutao.
Neste contexto, surge OKR (Objectives and Key Results), um framework para definio de metas criado
pela Intel e adotado por Google, Oracle, Twitter, LinkedIn and Dropbox, entre outros. Um OKR possui
dois componentes: o Objetivo (o que queremos atingir) e um conjunto de Key Results (como sabemos
se estamos chegando l). Um exemplo:
Objetivo: Encantar os clientes
Key Results:
* Visitas Recorrentes: mdia de 3.3 visitas por semana por usurio ativo.
* Alcanar um Net Promoter Score de 90%.
* Trfego no pago (orgnico) de 80%.
* Engajamento: 75% dos usurios possui um perfil completo.
Ao invs de planejamento esttico com metas fixas anuais, OKR trabalha em ciclos de definio de
metas trimestrais (ou menores), permitindo uma abordagem gil e iterativa.
Um dos pontos que eu mais gosto em OKR o conceito de critrios de sucesso compartilhados. O
que sucesso? Todo o grupo deve responder esta questo. Como ns, como um grupo, vamos nos
considerar bem-sucedidos? Para alguns, o sucesso pode ser criar a prxima empresa bilionria. Para
outros, deixar sua marca no universo. Pode ser uma grande contribuio tcnica ou simplesmente
um projeto que os realiza. De fato, cada projeto, empreendimento ou iniciativa precisa responder esta
pergunta. crucial para criar o alinhamento necessrio, e a que OKR ajuda. Ele permite a criao de
critrios de sucesso compartilhados. Em um processo muito simples, OKR gera alinhamento sobre o
que esperado e sobre onde queremos ir.
Alm disso, OKR traz disciplina para o aprendizado validado. Steve Blank escreveu em um de seus
artigos (traduo livre):
Use o Business Model Canvas para definir hipteses, Customer Development para sair do prdio e testar hipteses e Engenharia gil para construir o produto de maneira iterativa e incremental.
Mas como voc sabe se voc est tendo sucesso? O que voc considera uma hiptese validada?
Ns precisamos de claros critrios de sucesso compartilhados para aprendizado validado. Ento, eu
adicionaria a este trecho:
e OKR para acompanhar se voc est indo na direo certa.
33
Vale dizer ainda que OKR define Critrios de Sucesso alm de features. Projetos geis so normalmente
avaliados pela velocidade com a qual eles entregam features (com qualidade). Mas um time que
entrega features e falha em alcanar os resultados de negcio desejados nunca ser considerado bemsucedido. A coach de OKR Christina Wodtke tem um tweet excelente sobre sucesso: (traduo livre)
Sucesso no marcar uma caixinha. Sucesso ter impacto. Se voc completa todas as tarefas e nada
melhora, isso no sucesso.
De fato, entregar features que no afetam positivamente as mtricas selecionadas (os Key Results em
OKR) pode gerar resultados negativos. O novo cdigo pode ter bugs, ter que ser mantido e o produto
nem ser mais complexo. Marty Cagan tem um post obrigatrio sobre o assunto (assim como diversos
outros), do qual destaco o trecho abaixo (traduo livre). Se voc no leu o livro e o blog dele, voc deve.
por isso que estou to feliz em ver o retorno dos OKRs. Quando utilizados apropriadamente, eles
ajudam a reestruturar a situao de output (features em um roadmap) para outcome (resultados de
negcios).
OKR ainda pode ajudar a evoluir o Manifesto gil. Depois de 15 anos, acredito que hora de evoluir em
um dos seus princpios: Software funcional a medida primria de progresso. A medida primria de
progresso deve ser resultado de negcios, e no somente software funcional. E OKR o framework
certo para isto.
definir um norte para a organizao. Voc tem que dar para os times um direcionamento claro. Um
conjunto de OKRs para cada time far exatamente isso, e ainda conectar o time ao negcio e seus
clientes.
Isso porque muito fcil para os times se perderem em tecnicalidades para escrever cdigo ou design.
Mas quando voc comea a falar de resultados de negcios em um processo bottom-up, voc faz
com que os membros do time comecem a se perguntar por que eles esto fazendo o que eles esto
fazendo. Se voc continua falando sobre entregar features, como voc espera que o time pense no
usurio? Ou no negcio?
Por fim, OKR tambm pode complementar Scrum. Especificamente:
- OKR acaba com o problema do Proxy Owner. Em algumas empresas o Product Owner chamado
de Proxy Owner, uma vez que ele/ela simplesmente leva e traz a lista de features que foi priorizada
pela diretoria. Como podemos dar para ele/ela o mandato para gerenciar o produto? Como podemos
ter certeza de que o time tem autonomia?
Se o papel do time entregar as features que o cliente/diretoria quer isso nunca vai acontecer. A
mentalidade tem que ser o papel do time alcanar os critrios de sucesso como descritos pelos Key
Results e acordados com o cliente/diretoria. Vamos dar autonomia a ele para fazer isto.
OKR tambm ajuda a evitar o problema da temperatura do chuveiro. Se voc ficar rodando a torneira do
chuveiro, a gua nunca ficar na temperatura que voc quer. Voc precisa esperar para que a mudana
tenha efeito. A mesma coisa acontece com inovao: se voc continua pivotando o tempo todo, voc
nunca chegar onde quer.
- OKR ajuda a priorizar o backlog de produto. Ainda que voc deva focar em entregar resultados de
negcios, voc ainda precisa priorizar o backlog de produto. Mas como esperamos que o Product Owner
faa isto? esperado que ela/ele use valor percebido como o critrio, mas isso ainda subjetivo. OKR
pode ser a pea que falta, um framework simples e claro para decidir em quais features trabalhar. Como
Cagan escreveu sobre product scorecards, que ele mesmo substituiu por OKRs (traduo livre):
O uso de ciclos de metas mais curtos ajuda a evitar esse problema. Claro que coisas daro errado, mas
como o ex-VP de Produto da Zynga Jon Tien disse em um vdeo muito bom da Spark Capital sobre OKR:
Problemas acontecem, mas isso no quer dizer que voc no deve usar a mesma disciplina.
Um dos meus benefcios favoritos que eles podem usualmente ajudar a eliminar boa parte do seu
backlog/roadmap. Se uma feature no afeta diretamente um dos principais KPIs [Key Results] no
product scorecard [OKRs], geralmente est fora da lista.
Outra caracterstica do framework que ele permite times autogerenciados. Para ter uma organizao
horizontal, com alto alinhamento e alta autonomia, formada por times autogerenciados, voc tem que
34
Capitulo 9
Transformao digital
Criar produtos para seus clientes diferente de criar produtos para seus funcionrios. No recente artigo
Product For Legacy Companies, Marty Cagan taxativo:
For most companies, establishing a true customer technology competency is the single most important
thing for them to be doing to ensure their survival, yet remarkably some of them dont even realize they
have a problem.
Traduo livre: Para a maioria das empresas, estabelecer uma verdadeira competncia de tecnologia
para o cliente a nica coisa importante para garantir a sua sobrevivncia, mas claramente alguns
deles nem sequer percebem que tm um problema.
Essa afirmao se baseia no fato de que apesar de todos os setores estarem sendo afetados por
tecnologia, poucos entendem que fazer produtos para seus clientes muito diferente de fazer software
para seus funcionrios. Aplicar os mesmos mtodos, estrutura, pessoas e incentivos para um desafio
que muito maior, portanto, um erro.
Os motivos dessa diferena so muitos:
- seus funcionrios so pagos para usar seus sistemas legado, voc pode trein-los e obrig-los a usar;
- seus funcionrios so milhares, seus clientes so milhes;
- a barra na qual o seu cliente julga seus produtos digitais muito mais alta, afinal ele espera que a
qualidade da experincia seja a mesma que a do app do Facebook que ele deve ter acabado de usar;
- seu cliente pode desinstalar seu app e ir para a concorrncia, seu funcionrio no;
- se a qualidade uma porcaria e o uptime baixo, voc pode usar um procedimento alternativo, mas
o procedimento alternativo do seu cliente deixar de ser seu cliente;
- e, por fim, seu cliente espera que voc evolua seu produto na mesma velocidade que o mundo dele
muda, ou seja, que os dez apps preferidos dele, que so feitos no Vale de Silcio, mudam, e no a cada
dois anos quando seu ERP preferido vai para produo cheio de problemas.
Para piorar, o nexus de foras de disrupo parece ignorar o fato de que temos uma das mais fechadas
economias do mundo, alm de um modelo de capitalismo que evitou at hoje a competio aberta.
Estas diferenas so bvias, mas a esmagadora maioria do Brasil corporativo ainda no entendeu a
gravidade do problema. Quem entendeu parece estar buscando uma nova bala de prata chamada
transformao digital, quando na verdade o que necessrio uma profunda mudana cultural e de
estrutura, alm da implantao de uma estratgia de execuo digital que signifique a materializao
de agilidade corporativa em todos os nveis.
Os processos clssicos de desenvolvimento de software cascata, as estruturas departamentais, o
processo anual de oramento, a definio de incentivos e medio foram utilizados historicamente
para fazer sistemas que habilitavam o funcionamento de nossas empresas. Fazer produtos de sucesso
para seus clientes em um ambiente voltil afetado pela tecnologia requer uma leitura crtica do DNA
do Vale do Silcio e a implantao de um programa longo de mudana cultural por meio de agilidade
corporativa.
Essa agilidade pode, por exemplo, significar a utilizao de engenharia gil, estrutura de produto e lean
product management e incentivos e metas geis com um framework como OKR. O caminho para esta
transformao longo e rduo, e o principal termmetro do seu estgio a maturidade do seu produto ou
canal de autosservio mobile. Se ele no evolui rapidamente e tem como barra de comparao os apps
do Vale do silcio, voc tem um problema. Ele como um termmetro do seu nvel de competitividade
digital e um sinal de que voc talvez no consiga ser competitivo nesse novo mundo.
- se seu sistema legado sai do ar, seu funcionrio obrigado a lidar com isso, mas se seu produto digital
sai do ar isso afeta receita, imagem e provavelmente
seu CEO vai ficar sabendo;
- seu cliente vai te acessar pelo mobile, seu funcionrio pelo desktop;
35
Capitulo 10
Presente e Futuro
H algum tempo, a proibio do Uber pela Cmara Municipal de So Paulo colocou mais lenha em
uma fogueira que vem sido discutida h algum tempo no Brasil: o movimento acelerado de entrada
de empresas do Vale do Silcio no mercado nacional. Uber, Whatsapp, Netflix, Spotify e AirBnb, alm
da brasileira Nubank e diversas outras, chegaram com o objetivo de resolver ineficincias e conquistar
o pblico com um servio muito bem executado, que j era oferecido em outros pases e funcionava
muito bem. Como bem resumiu recentemente o CEO do banco JP Morgan Jamie Dimon, Silicon Valley
is coming.
A questo que, aqui no Brasil, essas startups esbarram no capitalismo de laos brasileiro, ou seja,
na relao de dependncia entre o governo e o empresariado. essa relao que protege a nossa
economia, que a mais fechada do G20, de acordo com a Cmara Internacional do Comrcio. Nossa
taxa de abertura est na ordem de 23%, abaixo dos pases do BRICs, Chile e Mxico, por exemplo.
Mesmo com a alta taxa tributria no Pas, essas empresas chegam com grande competitividade por
oferecerem melhores opes ao consumidor.
Tudo isso comeou com o prprio Google e o setor de mdia. Enquanto antes usvamos a TV, o rdio
e os jornais impressos para nos informar, hoje em dia basta uma pesquisa no Google para ter qualquer
informao de forma rpida, completa e eficiente. O Twitter tambm contribui para essa mudana. Antes,
era preciso ir at uma banca de jornal, verificar as manchetes e comprar um exemplar que fosse do seu
interesse. Hoje, basta um clique nessa manchete e a informao est a seu alcance, gratuitamente. Ainda
no setor de mdia, mais recentemente, o Netflix abalou a estrutura de grandes produtoras e empresas
de TV oferecendo um contedo rico e melhor produzido por um preo bem menor, e o Spotify chegou
oferecendo um catlogo impressionante de msicas por um preo bem mais acessvel do que o da
indstria fonogrfica, que j estava abalada com a possibilidade de downloads de mp3.
Recentemente, os mais polmicos. Com o Whatsapp, voc no precisa mais gastar com envios de
SMS e ligaes, o que gerou reclamaes das operadoras de telefonia. O AirBnB j est causando
alguns prejuzos aos mantenedores de hotis e pousadas. O Uber desestabilizou o mercado de txis
e ainda est gerando muitos protestos, reclamaes e discusses nas Cmaras de Vereadores. E, por
fim, os investimentos estrangeiros na brasileira NuBank prometem transparncia, custos menores e a
possibilidade de resolver qualquer pendncia de banco pela internet.

Quem ganha nessa briga entre o capitalismo de laos brasileiro e o Vale do Silcio? Aposto minhas fichas
em quem tem a melhor arma: o consumidor. A populao brasileira j est percebendo os benefcios do
uso dessas novas ferramentas, e a tendncia que o uso e conhecimento sobre elas aumente cada vez
mais, uma vez que o uso do smartphone e da Internet, que o que possibilita esses novos negcios, s
aumenta (ainda bem).
Para o Brasil corporativo existem algumas reaes para a disrupo. Uma delas acreditar que o problema
s o custo Brasil e insistir em usar Braslia para impor aos novos entrantes a mesma canga regulatria
que eles levam. Outra hiptese que este um problema complexo no qual existe uma ineficincia
causada pelo excesso de fechamento da economia e interferncia no processo de autolimpeza do
mercado. Este tema pode ser resolvido com aquisies, mas os poucos ativos disponveis vo ser caros
levando o retorno que era do acionista brasileiro para o investidor de capital de risco americano.
Como reagir grande disrupo
digital?
Chamo de Grande Disrupo a
perda de relevncia que empresas brasileiras de diversos setores tm quando so atacadas
por competidores digitais mais
aptos, que conseguem ultrapassar as barreiras do chamado capitalismo de laos, seja o
prprio custo Brasil ou questes
regulatrias. Em suma, o capitalismo de laos no vai proteger o Brasil do Vale do Silcio.
36
Alm disso, observamos que a Grande Disrupo parece seguir reas de grande ROC (retorno sobre
capital). Levando em conta que s conseguimos competir em ambientes extremamente fechados ou
protegidos pelo governo, podemos dizer que sofremos de uma ineficincia crnica em desenvolvimento
de produtos digitais. Como hiptese, acreditamos que essa ineficincia tenha como uma das causas
fundamentais a aplicao de um modelo mental errado (planejamento centralizado e controle) que
tenta modelar o problema de desenvolvimento de produtos digitais. Esse modelo leva incapacidade
de entender a dinmica do fenmeno e, consequentemente, otimizar um sistema.
Considerar que o problema nossa frente se comporta como um sistema linear talvez seja uma atitude
ligada condio humana de averso volatilidade. Este bias levaria utilizao de bom senso, reduo
sucessiva para resoluo de problemas e planejamento centralizado, mesmo quando estivermos
lidando com paradoxos e sistemas dinmicos complexos. Entretanto, como disse Albert Einstein, o
senso comum a coleo de preconceitos adquiridos aos 18 anos.
O problema que desenvolvimento de produtos digitais se comporta como um sistema dinmico
complexo, no linear. Isso significa que as implicaes individuais dos integrantes deste sistema so
aleatrias e no previsveis. Os sistemas evoluem no tempo com um comportamento desequilibrado e
aperidico, que faz com que seu estado futuro seja extremamente dependente de seu estado atual. Ou
seja, as alteraes radicais s so possveis a partir de pequenas mudanas no presente.
Para este tipo de sistema, a aplicao de aes baseadas em planejamento centralizado, instintos,
crenas, ideologias e senso comum no produz melhorias sustentveis. Craig Larman, citando Forrester,
disse uma vez que a maior parte das pessoas tem um julgamento fraco sobre como melhorar sistemas
em seu nvel fundamental, normalmente aplicam senso comum e solues rpidas que no geram
melhorias sistmicas de longa durao.
Quando encaramos um problema, assumimos que precisamos elencar opes, escolher a melhor e
executar. Entretanto, essa abordagem assume que sabemos a priori as relaes de causalidade e por
isso podemos estabelecer algum processo para eliminar e escolher a melhor opo. Sistemas que
podem ser modelados de forma efetiva desta maneira so chamados de sistemas ordenados.
A grande maioria dos problemas de negcio que nos deparamos todos os dias, porm, so sistemas
no ordenados que precisam de uma abordagem coerente com sua natureza. Esta viso de modelagem
de sistemas, chamada de Cynefin, uma evoluo de um framework de tomada de deciso proposta
inicialmente pela HBS, em novembro 2007:
Assumindo que trabalhamos todos os dias no quandrante de sistemas que so complexos ou caticos,
temos duas grandes abordagens de tomada de deciso que podem levar a otimizaes reais e produtos
de sucesso.
Na nossa experincia, deparando-se com um sistema catico, a tomada de deciso dever seguir o
caminho de mover o ambiente para um espao mais ordenado, ou de tomar decises rpidas em busca
de espalhamento de risco e deteco de padres. O ambiente de venture capital e statups se comporta
desta forma, e quando as empresas mostram alguma trao podemos considerar que o ambiente deixou
de ser catico, se tornou complexo e, portanto, temos que mudar o framework de trabalho.
As relaes de causalidade de ambientes complexos so multivariadas e s podem ser conhecidas
depois do fato ocorrido. Ento, estratgias de experimentao sucessivas baseada em aprendizado
tendem a funcionar, conforme Greg Brougham props no livro An introduction to complexity and the
Cynefin Framework,
Quando estava pesquisando para escrever este captulo, os primeiros resultados foram relacionados
a uma velha disputa na economia entre Friedrich Hayek e John Maynard Keynes. Em uma grande
simplificao, o primeiro acha que a economia um sistema no-linear dinmico, que deve ter liberdade
para se ajustar. Segundo ele, os agentes econmicos devem se comunicar via formao de preos e o
planejamento centralizado leva servido (The Road to Serfdom). Keynes, por sua vez, considera que o
Governo pode induzir centralizadamente o crescimento econmico por meio de gastos governamentais
e medidas anticclicas.
A principal prova emprica de que o planejamento centralizado falho a relao direta entre liberdade
econmica nos pases e prosperidade. No livro Heritage Foundation, de Terry Miller e Anthony Kim, por
exemplo, eles afirmam que existe uma relao direta entre perda de liberdade econmica e a perda de
liberdade poltica em movimentos focados no planejamento centralizado como o Nazismo, Facismo,
Socialismo e Comunismo.
37
De novo trazendo o assunto para software, at mesmo quando tentamos mudar o modelo mental e
utilizar mtodos empricos (Agilidade, Lean, Customer Developement) e auto-organizao dentro de
estruturas de produto autogerenciadas, a busca por previsibilidade em um ambiente catico gera
uma criao natural de controles, cargos de gesto e engessamento. A longo prazo, o resultado que
ningum mais consegue produzir porque no h incentivos para produzir (criar software), apenas para
estar no corpo de controle.
6) Mais rpido mais devagar;
Monica de Bolle usou a alegoria das sombras na caverna de Plato para metaforizar o mesmo problema.
Quem est na caverna acha que as sombras so a realidade e ignora que elas so projetadas por uma
luz vinda de uma fogueira no mundo externo. Qualquer um que sasse da caverna e voltasse para falar
que aquilo tudo era uma iluso corria risco de morte.
10) Dividir um elefante ao meio no gera dois pequenos elefantes;
A metfora que esse erro de interpretao da realidade e animosidade com quem pensava diferente
levou novamente aplicao de um modelo errado para otimizar o sistema econmico. Nesse caso, o
planejamento centralizado do novo desenvolvimentismo, que j tinha produzido hiper-inflao, baixo
crescimento e perda de liberdade (destruio do sistema) na poca dos militares, foi novamente usado.
Liberais e populistas, planejadores centralizados e pensadores sistmicos raramente discordam do
objetivo a ser atingido (que muitas vezes bem intencionado), mas discordam diametralmente dos
meios para se chegar l e na interpretao da realidade.
7) Causa e efeito no esto relacionados entre eles no tempo e espao;

8) Pequenas mudanas podem causar grandes resultados... mas as reas com a maior influncia
frequentemente so as menos bvias;
9) Voc pode ter seu bolo e com-lo tambm, mas no os dois ao mesmo tempo;
11) No h culpa.
Outro conjunto de princpios simtricos foi definido por Don Reinertsen no livro Principles of Product
Development Flow. Na lista do autor, so onze os problemas na atual ortodoxia no desenvolvimento
de produtos:
1) Falha em medir corretamente sob o ponto de vista econmico;
2) Falta de capacidade de enxergar filas;
3) Adorao pela eficincia;
4) Hostilidade em relao variabilidade;
Peter Senge, no livro The Fifth Discipline, criou um conjunto de leis para materializar o que ele chamou
de pensamento sistmico, o que nos ajuda a conectar algumas reflexes que pareciam ser desconexas:
5) Institucionalizao de tamanhos grandes de lotes;
As Leis:
7) Gesto de cronogramas, e no de filas;
6) Subutilizao de Cadncia;
1) Os problemas de hoje vm de solues de ontem;
8) Falta de controle de WIP (trabalho em andamento);
2) Quanto mais fora voc emprega ao empurrar, com mais fora o sistema empurra de volta;
9) Falta de flexibilidade;
3) Comportamento cresce melhor antes de crescer pior;
10) Controle de fluxo no econmico;
4) O caminho mais fcil geralmente leva para trs;
11) Controle centralizado.
5) A cura pode ser pior que a doena;

38
Eliyahu M. Goldratt, no livro A Meta, tambm ressalta o problema de otimizao local, ou seja, o aumento
de produtividade de uma etapa do processo pela super-ocupao das mquinas versus a otimizao
global ou o retorno sobre capital investido. Se voc produz estoques ou filas invisveis em uma etapa
especfica com rateio de custo indireto, na verdade voc no est produzindo lucro. o que o autor
chama de falsa eficincia ou otimizao local.
No livro The Mythical Man Month, Fred Brooks define que adicionar mo de obra a um projeto atrasado
o torna ainda mais atrasado, teoria chamada de Lei de Brooks. Isso porque o bom senso educado
defende a lei com uma equao matemtica simples na qual o ganho de produtividade linear e os
problemas de comunicao gerados pela adio de novos profissionais quadrtico. N*(N-1), ou seja,
todas as pessoas devem falar com todas as outras, ou N2, se voc fala com as vozes na sua cabea.
Mas essa premissa (no possvel escalar times sem perder produtividade) parece sofrer de um bias
de planejamento centralizado e lida com experincias empricas do contrrio, como o desenvolvimento
em larga escala de software open source (Linux, por exemplo) ou os times de produto do Google, Apple
e Amazon.
O problema no est na adio de novos coders isoladamente, mas na adio de novos coders e na
aplicao de um modelo mental que identifica erroneamente as variveis a serem otimizadas e v falsas
relaes de causalidade, o que faz com que qualquer ao gerencial que busque melhorias seja muito
parecida com uma criana brincando de fazenda de formiga.
Como disse Daniel Kahneman no livro Thinking Fast & Slow, nossa predileo pelo pensamento causal
nos expe a erros srios quando avaliamos eventos realmente randmicos (de comportamento aleatrio).
O ser humano tem averso incerteza e, quando confrontado por um sistema complexo, aplica
naturalmente uma modelagem linear e comea a tentar otimiz-lo utilizando reduo de problemas,
planejamento centralizado, bom senso e ortodoxia.
O resultado deste processo a desarticulao do sistema com resultados no previstos, que so
causados por medidas de supostas melhorias, o que leva destruio do sistema em longo prazo. A
reao dos agentes de controle normalmente de negao, o que leva imposio de mais controle
e diminuio da eficincia do sistema como um todo.
Por outro lado, se criarmos uma cultura de pensamento sistmico e de liberdade, podemos otimizar e
escalar continuamente a nossa capacidade de desenvolvimento de produtos digitais com experimentos
e gerao de aprendizado validado empiricamente. Essa mudana de modelo mental aplicada permite
que as empresas se apropriem de uma vantagem competitiva que muito dificilmente de ser copiada.
Afinal, o que fica aparente so sintomas de melhoria, e no o modelo mental que as viabilizou.
Minha concluso, portanto, que a soluo vivel abraar a disrupo e esquecer o pacto de
mediocridade imposto pelo capitalismo de laos. Devemos fazer uma engenharia reversa do Vale do
Silcio e apostar na implantao de uma cultura de execuo digital baseada nele. Deixar o setor de
Venture Capital brasileiro criar algumas opes de aquisio locais, mas principalmente focar em uma
estratgia de execuo digital focada no nexus cultural do Vale, com agilidade, gesto de produtos Lean,
culturas autogeridas e auto-organizadas baseada em dados e, principalmente, meritocracias digitais.
Ou seja, o mercado de tecnologia brasileiro precisa se inspirar no Vale do Silcio e focar em oferecer
melhores servios ao consumidor para enfrentar de frente a concorrncia do prprio Vale.
Existe um vis humano de falsa causalidade. Em ambientes de produto, a maioria das relaes de
causa e efeito multidimensional e no bvia, o que faz com que voc no se depare com problemas,
mas com paradoxos.
O ponto central que se voc aplica um processo de modelagem e melhoria continuada correto, com
estruturas autogeridas e organizadas, pesos e contrapesos entre produto e engenharia e uma cultura
de empirismo e aprendizado, a escalabilidade incrivelmente maior, sem um teto conhecido.
39
dese
www.concretesolutions.com.br
blog.concretesolutions.com.br
Rio de Janeiro Rua So Jos, 90 cj. 2121

Centro (21) 2240-2030
So Paulo - Rua Sanso Alves dos Santos, 433

4 andar - Brooklin - (11) 4119-0449

Silicon Valey Is Here

Enviado por

Dados do documento

Título original

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

Silicon Valey Is Here

Enviado por

Direitos autorais:

Formatos disponíveis

NDICE

Prticas, Papis e Plataforma..................................................................25

O dilema da agilidade digital ..................................................................4

Silicon Valley is coming ........................................................................27

Os 10 maiores erros da abordagem de fbrica de software..........................6

OKR (Objectives and Key Results) *por Felipe Castro.................................33

Anti-patterns: por que pessoas inteligentes tomam decises erradas..........9

Lean Startup e Lean Innovation...............................................................11

No fazemos projetos, desenvolvemos produtos!......................................17

H 15 anos, exatamente enquanto a Concrete Solutions nascia, um grupo de ve-

teranos em desenvolvimento de software se reunia para criar o Manifesto gil,

nharia gil, que consideramos o estado da arte no desenvolvimento de software

atualmente. Entretanto, vale lembrar que o desenvolvimento de software um

nologia. Sendo assim, no por acaso que acompanhamos a evoluo da agi-

ambiente complexo e catico, em constante transformao. Essas nossas ideias

cada novo cliente e produto desenvolvido.

Esperamos que esse livro te ajude a entender melhor o ambiente de tecnologia

tendemos que o que fazamos era gerenciamento de produtos digitais

no Brasil e te ajude a dar mais um passo no caminho do sucesso.

Silicon Valley is here - Como usar a agilidade corporativa para competir

O dilema da agilidade digital

Silicon Valley is here - Como usar a agilidade corporativa para competir

anteriormente para escalar o produto.

Silicon Valley is here - Como usar a agilidade corporativa para competir

Os 10 maiores erros da abordagem

Silicon Valley is here - Como usar a agilidade corporativa para competir

de preciso e processos padronizados

a necessidade de padronizao de definio de uma forma clara de descrever aquele domnio e a

Goldratt, teoria das restries

Silicon Valley is here - Como usar a agilidade corporativa para competir

melhoria contnua, pode-se subir ao mais alto nvel da prtica e do conhecimento.

Silicon Valley is here - Como usar a agilidade corporativa para competir

Anti-patterns: por que pessoas inteligentes

Barcelona - La Sagrada Familia

Silicon Valley is here - Como usar a agilidade corporativa para competir

3. The Queen of Hearts

A frase clssica desse erro : no podemos entrar em produo sem todas

Silicon Valley is here - Como usar a agilidade corporativa para competir

longo prazo, ningum mais quer produzir, a no ser um grupo cada

Lean Startup e Lean Innovation

Tempos depois, ele publicou esse cartoon:

Silicon Valley is here - Como usar a agilidade corporativa para competir

Mas o que Lean Startup?

Silicon Valley is here - Como usar a agilidade corporativa para competir

Silicon Valley is here - Como usar a agilidade corporativa para competir

Silicon Valley is here - Como usar a agilidade corporativa para competir

Fonte: The chaos manifesto, The Standish Group

iterativa e emprica no desenvolvimento de produto

Silicon Valley is here - Como usar a agilidade corporativa para competir

Silicon Valley is here - Como usar a agilidade corporativa para competir

No fazemos projetos, desenvolvemos produtos!

1. Engenharia gil e Cloud

Desenvolver Produtos digitais

Silicon Valley is here - Como usar a agilidade corporativa para competir

3. Product and Customer Discovery

Silicon Valley is here - Como usar a agilidade corporativa para competir

Algum vai ter que entender como funciona

Quando estamos fazendo um teste de DNA do

Silicon Valley is here - Como usar a agilidade corporativa para competir

Silicon Valley is here - Como usar a agilidade corporativa para competir

b) PPM, banners e contedo;

Silicon Valley is here - Como usar a agilidade corporativa para competir

- Cultura de inovao (pessoas podem errar?)