Book Review: “Lean Enterprise: How High Performance Organizations Innovate At Scale”

Book Review: “Lean Enterprise: How High Performance Organizations Innovate At Scale” (Jez Humble, Joanne Molesky, Barry O’Reilly)


Chapter 1 – Introduction
Starts explaining the importance of management and people and an approach in Toyota Production System. An alternative to command and control and other highlighted topics are:

A Lean Enterprise is primarily a human system:

  • Pathological organizations: are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
  • Bureaucratic organizations: protect departments. Those in the department want to maintain their “turf”, insist on their own rules, and generally do things by the book – their book.

How organizations process information:

Pathological (power-oriented) Bureaucratic (rule-oriented) Generative (performance – oriented)
Low cooperation Modest cooperation High cooperation
Messengers shot Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure leads to scapegoating Failure leads to justice Failure leads to enquiry
Novelty crushed Novelty leads to problems Novelty implemented

The three gaps, and how to manage them:

Effects gap Knowledge gap Alignment gap
What is it? The difference between what we expect our actions to achieve and what they actually achieve The difference between what we would like to know and what we actually know The difference between what we want people to do and what they actually do
Scientific Management Remedy More detailed controls More detailed information More detailed instruction
Auftragstaktik remedy “Everyone retains freedom of decision and action within bounds” “Do not command more than is necessary or plan beyond the circumstances you can foresee” “Communicate to every unit as much of the higher intent as is necessary to achieve the purpose”
Directed opportunism remedy Give individuals freedom to adjust their actions in line with intent Limit direction to defining and communicating the intent Allow each level to define how they will achieve the intent of the next level up, and “backbrief”

The key to the Principle of Mission is to create alignment and enable autonomy by setting out clear, high-level target conditions with an agreed time frame. This principle is applied in multiple contexts:

  • Budgeting and financial management
  • Program management
  • Process improvement


Chapter 2 – Manage the Dynamics of the Enterprise Portfolio

This chapter explain the lifecycle of businesses and how companies can balance the exploration of new business models with the exploitation of proven ones.

Technology adoption lifecycle

Technology adoption lifecycle

Once the market has assimilated a disruptive new technology or idea, a whole range of product offerings gets spawned.

Exploring new opportunities and exploiting existing ones are fundamentally different strategies requiring different structure, competencies, processes, and mindset. It is hard to overemphasize this key point: management practices that are effective in the exploit domain will lead to failure if applied to exploring new opportunities – and vice versa. The difference between these two domains:

Explore Exploit
Strategy Radical or disruptive innovation, new business model innovation Incremental innovation, optimizing existing business model
Structure Small cross-functional multiskilled team Multiple teams aligned using Principle of Mission
Culture High tolerance for experimentation, risk taking, acceptance or failure, focus on learning Incremental improvement and optimization, focus on quality and customer satisfaction
Risk management Biggest risk is failure to achieve product / market fit A more complex set of trade-offs specific to each product / service
Goals Creating new markets, discovering new opportunities within existing markets Maximizing yield from captured market, outperforming competitors
Measure of progress Achieving product/market fi Outperforming forecasts, achieving planned milestones and targets

Exploring New Ideas

Less than 50% of startups are alive five years after they start. The Lean Startup details a method for working in conditions of extreme uncertainty – to discover and operationalize new and potentially disruptive business models, and quickly discard those that will not work.

Every entrepreneur has a vision of their business. And for this vision to become reality, there are two key assumptions that must be tested:

  • Values hypothesis: asks whether our business actually provides value for users by solving a real problem.
  • Growth hypothesis: tests how fast we can acquire new customers and whether we have that.

Investing a fixed amount of time and money to investigate the economic parameters of and idea-be it a business model, product, or an innovation such as a process change-is an example of using optionally to manage the uncertainties of the decision to invest further. We limit our maximum investment loss (“downside”) on any individual idea, with the expectation that a small number of ideas will pay off big time, and offset or negate investment in those that did not.

The principle of optionality
The principle of optionality

The other part in this chapter is related to Enterprise Portfolio – balancing (using an economic model), matrix portfolio management (1. Emerging 2. Growth 3. Mature 4. Decline), managing a portfolio with the three horizons model (1. Current Business 2. High Growth Businesses 3. Growth Options).



Chapter 3 – Model and Measure Investment Risk

Here is presented the principles and concepts that enable us to take a systematic approach to managing the risk of planned work, by gathering information to reduce uncertainty. Model Investment Risk using Business Case or Monte Carlo are discussed in this chapter to verify how useful they are in scenarios of uncertainty.

We should stop using the word “requirement” in product development, at least in the context of nontrivial features. What we have, rather, are hypotheses. In the case of business model and product innovation, the Lean Startup movement provide us with a framework for operating in conditions of extreme uncertainty:

  • Do not spend a lot of time creating a sophisticated business model. Instead, design a simplified business model canvas with captures and communicates the key operating assumptions of your proposed business model.
  • Gather information to determine if you have a problem worth solving.
  • Then, design an MVP (minimum viable product)-an experiment designed to maximize learning from potential early adopters with minimum effort.
  • Throughout this process, update the business model canvas based on what you learn from talking to customers and testing MVPs.

Traditional product lifecycle versus Lean Startup lifecycle:

Traditional project-planning process Lean Startup discovery process
What data do we have to make the investment decision? A business plan based on a set of untested hypotheses and assumptions, backed by case studies and market research Real data based on evidence complied from a working product or service tested with real customers
What happens next? We must create detailed requirements, if we haven’t already, and then starts a project to build, integrate, test, and finally release the system We already have a validated MVP which we can build upon immediately with new features and enhancements based on customer feedback
When do we find out if the idea is any good? Once the project is complete and the product or service is live We already have this evidence based on the data we have collected

Principles for exploration
The OODA loop, a model of how humans interact with their environment which forms the basis of Boyd’s theory of maneuver warfare. OODA stands for observe, orient, decide, act, the four activities that comprise the loop.


Chapter 4 – Explore uncertainty of detect opportunities

In the chapter four, tools and techniques are shared to safely create and test hypotheses to solve real business problems identified and validated in our customer development process. Discovery is a rapid, time-boxed, iterative set of activities that integrates the practices and principles of design thinking and Lean Startup, used intensively at the beginning of the explore phase of a new initiative.

Creating a shared understanding (Dan Pink – Drive):

  1. Success requires a shared sense of purpose in the entire team
  2. People must be empowered by their leaders to work autonomously to achieve the team objectives
  3. People need the space and opportunity to master their discipline, not just to learn how to achieve “good enough”

With workshops, you can co-create ideas aligned to business goals. The process, starting with divergent thinking until convergent thinking can generate multiple ideas for discussion and debate.

Structured exploration with divergent and convergent thinking

Structured exploration with divergent and convergent thinking

The Business Model Canvas can share the understanding about business problem to inform the Business Plan. It includes nine essential components of an organization’s conceptual business model – customer segment, value proposition, channels, activities, resources, partnerships, cost and revenue.

Business Model Canvas

In this chapter, also is covered MVPs and how to accelerate experimentation with them. Cagan defines an MVP “the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available-also known as valuable, usable and feasible”.

MVPMinimum Viable Product: build a slice across instead of one layer at a time

example set of types of MVPsexample set of types of MVPs 02example set of types of MVPs 03
An example set of types of MVPs


Chapter 5 – Evaluate the product/market fit

This chapter discuss how to identify when a product/market fit has been achieved and how to exit the explore stage and start exploiting our product with its identified market. Also, how to use customized metrics to understand whether we are achieving measurable business outcomes while continuing to solve our customers problems by engaging them throughout our development process.

Some examples of vanity metrics and corresponding actionable metrics:

vanity versus actionable metricsExamples of vanity versus actionable metrics

Example innovation scorecardExample innovation scorecard

The pirate metrics helps you to model any service-oriented business. Measuring pirate metrics for each cohort allows you to measure the effect of changes to your product or business model, if you are pivoting. The Votizen’s pirate metrics represents the effect of incremental change and pivots.

AARRR pirates

A story map can help you to tell the narrative of the Runway of our vision. Can be used to plan e prioritize by visualizing the solution as a whole. It provides an effective means to communicate the narrative of our solution to engage the team and wider stakeholders and get their feedback.

A user story map

The five critical enablers of growth when transitioning from explore to exploit are:

  • Market
  • Monetization model
  • Customer adoption
  • Forget “big bang” launches
  • Team engagement



Chapter 6 – Deploy Continuous Improvement

In most enterprises, there is a distinction between the people who build and run software systems and those who decide what the software should do and make the investment decisions. Ultimately, we aim to remove this distinction. In high performance organizations today, people who design, build, and run software-based products are an integral part of business.

In this chapter is described how to achieve the balancing (the work we do to improve our capability against delivery work that provides value to customers) at program and value stream levels, by putting in place a framework called Improvement Kata. The other part, covers practices in CI/CD as branching versus trunk-based development and other. For more details, I recommend to access my blog.

A good example, in the HP LaserJet Firmware Case Study, we can see how allocating costs to the activities the team is performing.

% of costs Activity
10% Code integration
20% Detailed planning
25% Porting code between version control branches
25% Product support
15% Manual testing
~5% Innovation

The Improvement Kata needs to be first adopted by the organization’s management, because it’s a management philosophy that focuses on developing the capabilities of those they manage, as well as on enabling the organization to move towards its goals under conditions of uncertainty. There are four stages that we repeat in a cycle:

The Improvement KataThe Improvement Kata

  • Understand the direction: derived from the vision set by the organization’s leadership.
  • Grasp the current condition: after the direction, we incrementally and iteratively move towards it at the process level.
  • Establish the next target condition: as we continuously repeat the cycle, we reflect on the last step taken to introduce improvement.
  • Iterate toward the target condition

Three years after the initial measurements (in HP LaserJet case), a second activity-accounting exercise offered a snapshot of the results the FutureSmart team had achieved with their approach:

% of costs Activity
2% Continuous integration
5% Agile planning
15% One main branch
10% Product support
5% Manual testing
23% Creating and maintaining automated test suites
~40% Innovation

Chapter 7 – Identify value and increase flow

Most enterprises are drowning in a sea of overwork, much of which provides little value to customers. In the previous chapter was showed how to implement a program-level continuous improvement strategy to improve productivity and quality and reduce costs. In this chapter, the purpose is showing how the five lean principles can be adopted to reduce the cycle time, increasing quality and return on investment.

In high-performing organizations, leadership and management has a sharp focus on the value the organization is creating for its customers.

The value stream map helps to reflect the current condition in a determined product or service we want to evaluate. This exercise must gather people from every part of organization involved in the value stream.

value stream mapOutline of a value stream map showing process blocks

After concluded, we record three key metrics:

  • Lead time: the time from the point a process accepts a piece of work to the point it hands that work off to the next downstream process
  • Process time: the time it would take to complete a single item of work if the person performing it had all the necessary information and resources to complete it and could work uninterrupted
  • Percent complete and accurate (%C/A): the proportion of times a process receives something from an upstream process that it can use without requiring work

Also is presented Kanban concepts to share a comprehensive way to manage the flow of work:

  • Visualize workflow (creating a board)
  • Limit WIP (work in progress)
  • Define classes of service (for different types)
  • Create a pull system (by agreeing on how work will be accepted into each process block when capacity becomes available)

And a Cost of Delay – a framework for decentralizing economic decisions, to identify and prioritize the work with the highest opportunity cost.

cost of delay.png

How do we prioritize Tasks A and B with Cost of Delay? 

Chapter 8 – Adopt Lean Engineering Practices

“Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place”. W. Edwards Deming.

In this chapter there are important concepts to allow the organizations deploy new releases in production frequently, necessary to test ideas with real users and enable effective innovation process (learn and update based on feedback). For more details from other concepts like continuous integration, test automation, continuous deliver and deployment pipeline, access my blog.

Deployment g-forcesDeployment g-forces


Chapter 9 – Take an Experimental Approach to Product Development

Up to now, the others chapters show how to improve the speed at which can deliver value to customer. In this chapter, the focus is to discuss alignment – how to use capabilities we have developed to make sure we are building the right things for customers, users, and our organization.

So, concepts as creating hypothesis, hypothesis-driven development and user research are described to focus on the outcomes we wish to achieve, rather than solutions and features.

user research

Different types of user research

Also for more details, please visit my blog.

Chapter 10 – Implement Mission Command

The organizational and architectural concerns are often the biggest barriers to executing the strategy for moving fast at scale based on the principles of Mission Command (described in Chapter 1). Amazon has a famous memo to technical staff directing them to create a service-oriented architecture:

  • All teams will henceforth expose their data and functionality through service interfaces
  • Teams must communicate with each other through these interfaces
  • There will be no other form of interprocess communication allowed. The only communication allowed is via service interface calls over the network
  • It doesn’t matter the technology they use. HTTP, Corba, Pubsub, custom protocols.
  • All services interfaces, without exception, must be designed from the ground up to be externalizable
  • Anyone who doesn’t do this will be fired

A key principle of service-oriented architecture (SOA) is decomposing systems into components or services. Each component or service provides an interface (also known as an API – application programming interface) so that other components can communicate with it.

Here are some strategies enterprises have successfully applied to create autonomy for individual teams:

  • Give teams the tools and authority to push changes to production
  • Ensure that teams have the people they need to design, run and evolve experiments
  • Ensure that teams have the authority to choose their own toolchain
  • Ensure teams do not require funding approval to run experiments
  • Ensure leaders focus on implementing Mission Command

traditional enterprise organizationExample of traditional enterprise organization

product teamsProduct teams working together, with a service layer for performing deployments

Creating small, autonomous teams makes it economic for them to work in small batches. When done correctly, this combination has several important benefits:

  • Faster learning, improved customer service, less time spent on work that does not add value
  • Better understanding of user needs
  • Highly motivated people
  • Easier to calculate profit and loss



Chapter 11 – Grow an innovation culture

Culture is the most critical factor in an organization’s ability to adapt to its changing environment. The main topics in this chapter are:

  • Model and measure your culture: important to consider layers of organizational culture
    • Artifacts: visible, observable aspects of culture such as organizational structures and processes, and how people dress and behave. Hard to decipher.
    • Espoused values: strategies, goals, philosophies, such as the “value statements” you find in the company lobby
    • Underlying assumptions: unconscious beliefs, perceptions, thoughts, feelings (which ultimately govern values and behavior)
  • Change your culture: Old and new approaches to cultural change – Shook offers his own interpretation of Schein’s model, showing how people normally approach cultural change in contrast to the approach taken at NUMMI.
    Shook Change your culture
  • Make it safe to fail
  • There is no talent shortage: Dweck’s two mindsets, showed through a series of experiments that our mindset determines how you decide your goals, how to react to failure, what are our beliefs about effort and strategies, and what is our attitude towards the success of others.
    two mindsets
  • How Google recruits
    how google recruits.jpg
  • Growing talent: there are many ways in which enterprises can invest in people
    • Help employees create and update personal development plans
    • Separate performance reviews from compensation reviews
    • Facilitate regular feedbacks
    • Give employees access to training funds
    • Give employees time to pursue their own goals
  • Eliminate hidden bias: the effects of implicit gender bias on hiring. Here is a selection of strategies that haven proven useful
    • Ensure equitable pay
    • Create target conditions for recruitment and promotion
    • Monitor tenure, rate of advancement and job satisfaction
    • Regularly review policies, interactions and HR processes

effects on hiring

Chapter 12 – Embrace Lean Thinking for Governance, Risk and Compliance

The chapter is to guide you through the maze that is GRC (Governance – Risk – Compliance), particularly as it relates to managing the concepts and practices required to be a lean enterprise. Governance is about keeping our organization in course. It is the primary responsibility of the board of directors, but it applies to all people and other entities working for the organization. It requires the following concepts and principles to be applied at all levels:

  • Responsibility
  • Authority and accountability
  • Visibility
  • Empowerment
  • Risk management and compliance

Apply Lean Principles to GRC processes: visualizing the value stream, increasing feedback, amplifying learning, empowering teams, reducing waste and delays, limiting work in process, making small incremental changes, and continuously improving to achieve better outcomes.

Good Governance requires everyone to focus on discovering ways to improve value and provide accurate information on which to base our decisions. We start with leadership and direction from the Board and Executives, and rely the ability of employees to embrace their responsibility to make good decisions at work. A culture of openness, trust, and transparency is required for good governance.


Chapter 13 – Evolve Financial Management to drive Product Innovation

Centralized budgeting process are typically used to plan, forecast, monitor and report on the financial position and overall performance of an organization. However, the traditional annual budget cycle can easily:

  • Reduce transparency
  • Remove decision from the people doing the work
  • Direct costs away from value creation
  • Measure performance by the ability to please the boss or produce output

budget purpose
Approaches to achieving the goals of budgeting

The Dynamic Resource Allocation creates more frequent checkpoints for funding decisions, and each decision has less risk associated with it. All decisions are based on the empirical evidence, so they become easier to make. When done correctly, access to funding expands to more teams, gets more frequent, has less associated risk, and brings better results. We thus encourage more innovation and reduce financial risk associate with large initiatives.

dynamic resource allocationDynamic resource allocation

In the other part, the chapter describe:

  • Avoid using budgets as the Basis for performance measurement: bonuses and rewards for good bottom-line financial results work better when they are shared equally. Working teams will eventually cripple the organization by inertia and subterfuge when their contributions are not acknowledged and rewards are based on a process perceived as unfair.
  • Stop basing business decisions on CAPEX versus OPEX: there are tax advantages and positive financial impacts from reporting organization expenditures appropriately in these different buckets, so a lot of attention is paid to it.
  • Modify your IT Procurement Processes to gain greater control over value delivery: this painful, highly detailed contractual process has several negative side effects
    • It’s a poor way to manage the risks of product development
    • It favors incumbents
    • It favors large service providers
    • It inhibits transparency
    • It is inaccurate
    • It ignores outcomes


Chapter 14 – Turn IT into a competitive advantage

This chapter is discussed some strategies to increase the responsiveness of IT to changing business needs, improve the stability of IT services, and reduce the complexity of our IT systems and infrastructure.

Rethinking the IT Mindset: IT has historically been seen as a cost center and an internal enabler of the business, not a creator of competitive advantage. In the 2014 State of DevOps Report, over 9,000 people worldwide were polled about what creates high-performance organizations, whether IT does in fact matter to the business, and what factors impact the performance of IT departments.

rethinking it mindsetWhat business leaders think about the business-IT relationship

The practices most highly correlated with high IT performance (increasing both throughput and stability) are:

  • Keeping systems configuration, application configuration, and application code in version control
  • Logging and monitoring systems that produce failure alerts
  • Developers breaking up large features into small, incremental changes that area merged into trunk daily
  • Developers and operations regularly achieving win/win outcomes when they interact

If we want to compete in a world of ever shorter product cycles, central IT needs to be business unit’s trusted partner, not an order-taking cost center. In turn, IT needs to achieve higher levels of throughput while improving stability and quality and reducing costs. The complexity of existing enterprise IT environments, combined with the amount of planned and unplanned work that must be done to keep them running, are the chief barriers to achieving these outcomes.

Chapter 15 – Start where you are

The biggest barrier to success in changing the way you work is a conviction that your organization is too big or bureaucratic to change, or that your special context prevents adopting the particular practices we discuss. Always remember that each person, team, and business that started this journey was unsure of what paths to take and how it would end. The only accepted truth was that if they failed to take action, a more certain, negative ending lay ahead.

The only path to a culture of continuous improvement is to create an environment where learning new skills and getting better at what we do is considered valuable in its own right and is supported by management and leadership, thus reducing learning anxiety. We can use the Improvement kata (presented in chapter 6) to create this culture and drive continuous improvement.

pdcaContinuous evolution and adaption to change

The process of creating alignment and consensus between levels is critical. In strategy deployment, this process is described as catchball, a word chosen to evoke a collaborative exercise. The target conditions from one level should not be transcribed directly into the direction for teams working at the level below. Catchball is more about translation of strategy, with “each layer interpreting and translating what objectives from the level above mean for it”.

Using catchball to drive strategic alignment of objectives and initiatives

Begin your journey: use the following principles for getting started:

  • Ensure you have a clearly defined direction
  • Define and limit your initial scope
  • Pursue a high-performance culture of continuous improvement
  • Start with the right people
  • Find a way to deliver valuable, measurable results from early on

Creating a resilient, lean enterprise that can adapt rapidly to changing conditions relies on a culture of learning through experimentation. For this culture to thrive, the whole organization must be aware of its purpose and work continuously to understand the current conditions, set short-term target conditions, and enable people to experiment to achieve them.

We then reassess our current conditions, update our target conditions based on what we learned, and keep going. This behavior must become habitual and pervasive. That is how we create a mindset of continuous improvement focused on ever higher levels of customer service and quality at ever lower costs.

DevOps e ligação com Kaizen, Lean, ITIL e Infra as code

Continuando o post anterior sobre DevOps e a ligação com outras práticas, segue abaixo um resumo de Extreme Programming (XP), Lean, Kaizen, Kanban, ITIL e Infrastructure as code.

eXtreme Programming (XP)

É uma metodologia de desenvolvimento de software focada em melhorar a qualidade e a capacidade de resposta à mudanças nos requisitos. Promove lançamentos frequentes.

Entre as principais práticas:

  • Small releases
  • Programação em pares
  • Integração contínua
  • Refatoração
  • TDD (test driven development)
  • 40 horas semanas (sustainable place)




Visa melhorar o desempenho dos processos da empresa, identificando e eliminando o desperdício e a causa raiz do defeitos.

Princípios Lean

  • Produção puxada
  • Melhoria contínua
  • Valor na visão do cliente
  • Fluxo contínuo sem interrupção
  • Fluxo de valor e mapeamento

Gemba: é o local onde as coisas acontecem de verdade – “chão de fábrica”.


Kaizen: melhoria contínua

Kaizen é uma prática cultural que significa mudar para melhor. O foco é analisar o ambiente atual onde o valor é criado ou onde o problema:

▪ Não é reportado; não há métricas
▪ Não há discussão de processo; nem documentação sobre ele
▪ Olhar mesmo o que as pessoas estão fazendo, até revisar código, etc.


▪ Bons processos trazem bons resultados
▪ Providencie ações para controlar e corrigir causas raíz
▪ Gemba (go see for yourself)
▪ Converse com dados, gerencie por fatos
▪ Trabalhe como um time
▪ Kaizen é assunto de todos
▪ PDCA para a resolução de problemas


  • Sistema Kanban (pull | limites | valor): sistema puxado, limitado que permite visualizar o fluxo de trabalho em busca da geração de valor.
  • Método Kanban (transição | kaizen | gestão): abordagem evolutiva e incremental, implementando mudanças evolutivas e incrementais.

O objetivo do Kanban é tornar problemas explícitos e engajar pessoas na mudança. Entre as principais características:

  • Otimização de fluxos de trabalho
  • Melhorar a comunicação e colaboração
  • Transformação do ambiente de trabalho e evolução dos processos
  • Tornar o trabalho mais previsível e estável



  • Visualize
  • Limite o trabalho em progresso (WIP)
  • Meça e gerencie o fluxo
  • Torne as políticas do processo explícitas
  • Implemente mecanismos de feedback
  • Melhore colaborativamente, evolua experimentalmente

WIP (trabalho em progresso)
O trabalho que está em execução naquele determinado ponto do processo. Sinaliza a capacidade de entrega do time. O tamanho precisa ser adequado a expectativa do cliente com a entrega.

É uma métrica que demonstra a quantidade de tarefas entregues em um determinado período de tempo. Com isso, podemos avaliar a performance dos times. O vilão da produtividade são as filas.

Lead Time
É o tempo entre a abertura da requisição e o momento que ela entra em seu estado final. Lembre-se que esforço é diferente de prazo.



Guia completo para os processos de TI, incluindo gestão de incidentes, portfolio, capacidade e catálogo de serviços. É prescritivo e top down framework. Boa parte exige um modelo waterfall (push-drive model) – 5 livros e bem pesado.

  • ITIL: primeiro framework ITSM (IT Service Management)
    • 1ª versão: uma série de diretrizes de como gerenciar serviços (início anos 90)
    • 2001: ITIL v2 foi publicada com a intenção de ser usada por outros usuários
    • 2007: ITIL v3 a última versão (atualizada em 2011) – utiliza uma visão baseada no modelo de processo para controlar e gerenciar serviços.
Fases do ITIL

1- Service Strategy
2- Service Design
3- Service Transition
4- Service Operation



Em 1999 o livro The Visible OPS (100 páginas) publica a implementação do ITIL em 4 passos práticos e auditáveis (2004):

  1. Core do ITIL: possui a maior parte das práticas de sucesso e um roadmap de como implementá-lo;
  2. A ideia é que você pode ter um processo de controle bem definido, auditável e compatível,  mas que pode ser leve e ágil e completamente oposto a maioria das implementações ITIL
  3. A recomendação é utilizar e aprender com o ITIL, mas analise bem antes de implementar um processo específico. Considere o objetivo do processo e como seria realizado com as práticas de DevOps
  4. No CI (do Chaos Monkey) há recomendações para buscar caminhos alternativos para atingir o objetivo esperado

Infraestrutura as

É uma prática importante a ser adotada, caso queira implementar DevOps na sua organização. Também é pré-requisito para o pipeline de implantação. Tratar a infraestrutura de TI como código permite o gerenciamento e provisionamento de infraestrutura por meio de arquivos.

Além disso, a adoção de práticas poderosas como controle de versão, entrega contínua, etc. Habilita a escala, load balance, disponibilidade e performance exigidas por aplicações modernas.


Por fim, vale relembrar algumas práticas recomendadas por Martin Fowler:

  • Utilizar arquivos de definição (shell scripts ou Chef receipts, por exemplo) para evitar mudanças manuais em servidores.
  • Auto documentar sistemas e processos ao invés de instruções.
  • Versionamento de tudo (que for possível) para manter rastreamento e controle.
  • Frequência reduz a complexidade – quanto maior o tamanho do update, mais difícil será detectar o erro, se houver.
  • Manter serviços continuamente disponíveis, com melhorias para evitar  downtimes.


Desafios organizacionais em entrega contínua – time-to-market e exponencial

Organizações Exponenciais
Como a tecnologia acelerada está mudando as organizações… “Uma Organização Exponencial é aquela cujo impacto (ou resultado) é desproporcionalmente grande – pelo menos dez vezes maior – comparado aos seus pares, devido ao uso de novas técnicas organizacionais que alavancam as tecnologias aceleradas”.


A habilitação da empresa p/ informação, entrelaçado c/ o ritmo da inovação acelera ainda mais o crescimento, até que as mudanças passam a ser exponenciais.

Este crescimento exponencial e a relação preço/desempenho dobra a cada um ou dois anos.

PMT – Propósito Máximo de Transformação
É muito comum encontrar o Proposito Transformador Massivo (PTM) em organizações exponenciais. O PTM é uma declaração do propósito da organização, ou seja, o motivo da existência do negócio. Na famosa organização TED, por exemplo, ideias que merecem ser espalhadas.

Este propósito singular é fundamental para desenvolver a capacidade de expandir e o mindset exponencial. Outros aspectos como o uso de tecnologias sociais, criação de equipes multidisciplinares, cultura de experimentação e aprendizado, inteligência artificial, métodos ágeis e práticas DevOps colaboram ao crescimento exponencial.

Existem cerca de 10 atributos comuns, agrupados dois lados:

  • Lado esquerdo: do acrônimo em inglês IDEAS, representa elementos de controle, ordem e estabilidade.
  • Lado direito: do acrônimo em inglês SCALE, representa elementos de criatividade, crescimento e incerteza.


Lean Startup
O Lean Startup adapta os conceitos da lean manufacturing (Toyota – Taiichi Ohno), com base em tamanho de lotes menores e produção justin-time,  evitando construir algo sem valor (validated learning). Value Vs Waste.

Value Vs. Waste – “Lean thinking defines value as providing benefit to the customer; anything else is waste”. So, validated learning is backed up by empirical data collected from real customers, the essential unit of progress for startups. “Success is not delivering a feature; success is learning how to solve the customer’s problem”.

O Build-MeasureLearn loop e a validação de ideias no mercado (variação do usual Kaizen PDCA):

  • Build: foco em criar o MVP
  • Measure: progresso em relação aos objetivos
  • Learning: traz afirmações valiosas sobre a aceitação dos produtos e perspectivas de negócio



Entre os principais benefícios da experimentação:

  • Aprendizado contínuo
  • Investimento direcionado
  • Validação de hipóteses são mais valiosas que previsões de mercado ou business plan

Case Studies
O caso das empresas Zappos e Dropbox foram exemplos do uso da experimentação, onde as empresas interagiram com os clientes e aprenderam sobre suas necessidades.

zappos Zappos (adquirida pela Amazon em 2009): a interação com os clientes e o aprendizado de suas necessidades através de experimentações foram essenciais.

O vídeo demonstrativo de três minutos da tecnologia Dropbox que sincroniza os arquivos, e levou centenas de milhares de pessoas ao site.

Validação da suposição pelo número de inscrições; não porque o disseram em um grupo de foco ou por causa de uma analogia promissora com outro negócio.



Leituras recomendadas: Livros de DevOps e SRE

Há algum tempo, venho recebendo perguntas de algumas pessoas sobre a minha sugestão de leitura para aprofundar os conhecimentos em DevOps. Então, decidi compartilhar um resumo dos principais livros que li nesta minha jornada e assim, facilitar a escolha de qual caminho você pode dedicar seu tempo de estudos.

Segue abaixo minhas leituras recomendadas em DevOps e SRE:


Continuous Delivery
Escrito por Jez Humble e David Farley, considero o melhor livro para compreensão de conceitos DevOps. A parte I descreve configuration management, continuous integration e estratégia de testes. Na parte II, o Deployment Pipeline com Build, deploy e testes automatizados. A parte III aborda a gestão de infra e ambientes, dados, componentes e versionamento. Para iniciar, veja o resumo do livro.


book-the-phoenix-project The Phoenix Project
O livro traz uma história fictícia para apresentar um cenário de TI, considerando a complexidade e o uso do DevOps neste contexto. Ela é centrada em Bill (gerente de TI) que recebe o desafio do CEO para organizar o fluxo de trabalho e simplificar a comunicação entre os departamentos em 90 dias. Também aborda métricas e empresas low / high performers.



The Visible OPS
Publica a implementação do ITIL em 4 passos práticos e auditáveis. 1) Core do ITIL com práticas de sucesso e um roadmap de como implementá-lo; 2) Apresenta processos de controle bem definidos e que pode ser leve e ágil; 3) Aplicabilidade do ITIL e como seria realizado com as práticas DevOps; 4) Buscar caminhos alternativos para atingir o objetivo esperado (Chaos Monkey).


book-devops-handbook The DevOps Handbook
Aborda as melhores práticas pelos líderes do movimento DevOps. É um guia completo com recomendações de como integrar a gestão de produto, práticas DevOps e sistemas.  Também incentiva a competitividade na equipe e rentabilidade da empresa, trazendo a experiência de empresas como Amazon, Etsy e Netflix. Por fim, vale pelo direcionamento de como se tornar relevante no marketplace.


book-effective-devops Effective DevOps
Práticas para alinhamento em DevOps na organização e foco nos quatro pilares fundamentais da cultura com vários estudos de caso. Estas abordagens contribuem na quebra de silos de informação para melhorar a colaboração entre equipes. São elas: colaboração individual | afinidade dos times | ferramentas | DevOps em escala.


book-release-it Release It!
O livro escrito por Michael T. Nygard (programador e arquiteto) visa compartilhar a experiência prática em deploys de aplicações para a produção. O foco é em relação a arquitetura, fator multiplicador (negligência com recursos – usuários, sessão, etc.) e fator limite (custo e prazo com recursos novos).


book-lean-enterprise Lean Enterprise
É um guia prático que apresenta os princípios e padrões Lean e Ágil para conseguir responder rapidamente a mudanças de mercado. A parte I aborda estratégia, cultura e o ciclo de vida das inovações. Na parte II, verificar as ideias (coletando dados) e ser orientado a valor. A parte III foca na exploração das ideias validadas, e a parte IV como as empresas criam ambientes de aprendizado e experimentação.


book-SRE Site Reliability Engineering
Teoria e prática do SRE, compartilhando como o Google trata sistemas em produção. Também aborda a gestão do Google em relação a treinamento, comunicação e reuniões. As ferramentas APM e feedbacks loops são destaques pela contribuição em análises, métricas e identificação de gargalos e lentidões.


book-leading-transformation Leading the transformation
Por conta da importância do desenvolvimento de software nas organizações e as melhorias requeridas neste processo. Cita a transformação digital na Amazon e Google, aplicando Ágil e DevOps e os benefícios obtidos com a entrega mais rápida das aplicações. Foca na eficácia das equipes e na criação de uma estrutura clara para melhorar o desenvolvimento e a entrega.


Plataformas Digitais: Criando produtos e validando hipóteses no mercado com foco UX (experiência do usuário)

Arquivo PDF: 2018 1 Estrutura do TCC – ARTIGO CIENTÍFICO – Leonardo Matsumota

Este trabalho aborda a aplicação das técnicas Lean Inception, Lean UX e Agile (Scrum) para criar um modelo de experimentação enxuto e contínuo afim de validar hipóteses de produtos no mercado. As principais fases da Lean Inception são: escrever a visão do produto, o produto é/não é/faz/não faz, descrever as personas, features, revisão técnica e de negócio, exibir as jornadas de usuário, priorizar as features e construir o MVP Canvas. Com a determinação dos MVPs – features para o sistema de admissão de candidatos, o desenvolvimento do sistema dar-se-á com o uso do Scrum (framework ágil), trabalhando com ciclos adaptativos de forma iterativa e incremental. Este planejamento e inspeção frequentes visam reduzir as incertezas e riscos do projeto, devido a adequação de escopo e frequente validação das entregas. Por fim, utilizamos a Lean UX (user experience) como guia para o processo de experiência do usuário, ajustando o sistema de acordo com o aprendizado obtido com as técnicas Vision, Framing, and Outcomes; Collaborative Design, etc.

Palavras-chave:  MVP. Métodos Ágeis. UX. Lean Inception. Design Thinking.

This paper approach the use of Lean Inception, Lean UX and Agile (Scrum) to create a lean and continuous experimentation model to validate product hypotheses in the market. The main phases of Lean Inception are: writing the product vision, the product is / is / does / does not, describe the personas, features, technical and business review, display user journeys, prioritize the features and build the MVP Canvas. With the determination of the MVPs – features for the candidate in admission system, the development of the system will be through the use of Scrum (agile framework), working with adaptive cycles in an iterative and incremental way. This frequent planning and inspection is intended to reduce project uncertainties and risks, due to the suitability of scope and frequent validation of deliveries. Finally, we use the Lean UX (user experience) as a guide to the user experience process, adjusting the system according to the learning achieved with the techniques Vision, Framing, and Outcomes; Collaborative Design, etc.

Keywords:  MVP. Agile. UX. Lean Inception. Design Thinking.



Com a evolução tecnológica acelerada e a transformação digital nos negócios, os usuários encontram cada vez mais opções de produtos disponíveis e ferramentas que auxiliam na hora da compra, como por exemplo, a avaliação de outros usuários.

Porém, com menos tempo e fidelidade às marcas, os usuários deparam com um alto volume de conteúdo na web, que precisam de relevância para conquistá-los e assim propiciar uma boa experiência ao longo da jornada de compra naquela plataforma. É necessário mostrar o seu valor para o consumidor!

E para isso, as empresas precisam compreender melhor seus pensamentos e atitudes, conectando-se a seus valores. A horizontalização auxilia neste aprendizado sobre o consumo, pois os usuários fornecem informações para a empresa, criando uma relação com os produtos e os serviços que adquire.

O Marketing 4.0 destaca a humanização da marca, o marketing de conteúdo, a experiência omnichannel e a estratégia dos 5 A’s – estratégia de exposição da empresa, desde a atenção até a advocacia da marca (KOTLER, Philip). Veja o modelo proposto na Figura 1.

Figura 1 – 5A’s

Outro ponto é adotar um modelo extremamente dinâmico para criar produtos e validar hipóteses no mercado, como os testes A/B por exemplo. Também viabilizar o time-to-market, trabalhando com entregas contínuas e criando MVPs (Minimum Viable Product) para validar as principais premissas do negócio.

Entre as principais vantagens do MVP:

  • Reduzir riscos de mercado, pois os investimentos vão de acordo com a aceitação dos usuários
  • Validação de hipóteses
  • Experimentação e aprendizado
  • Geração de valor acelerada
  • Avaliar a escalabilidade do produto

O modelo Build-Measure-Learn Feedback Loop é uma efetiva abordagem para desenvolvimento de startup, melhorando continuamente a criação de produtos, serviços e ideias com ótimo custo-benefício (RIES, Eric).

A figura 2 demonstra o ciclo de criação e teste de hipóteses, começando pequeno para clientes potenciais, medindo suas reações e aprendendo com os resultados. O objetivo é evoluir o produto para entregar exatamente o valor esperado para o cliente.

lean-startupFigura 2 – Build-Measure-Learn Feedback Loop

E como ter uma abordagem criativa para criação de produtos? O Design Thinking busca de forma colaborativa (pessoas colocadas no centro do desenvolvimento do produto) encontrar soluções inovadoras para os problemas. O foco é em necessidades do mercado, e não em pressuposições estatísticas.

A abordagem Double Diamond no DT auxilia a compreender os clientes e seus problemas, utilizando dois diferentes tipos de pensamento:

  • Divergente: pensamento amplo, considerando qualquer ideia.
  • Convergente: pensamento estreito, identificando e focando em um ou dois dos principais problemas e soluções.

design-thinking.pngFigura 3The Double Diamond

Boa parte das soluções em plataformas digitais consideram o desenvolvimento de software para construir o produto ou estruturar o suporte do negócio. Operar em nível avançado com práticas DevOps habilita o processo de entrega contínua de valor aos usuários e mantém os ambientes de produção mais estáveis, provendo credibilidade a marca.

Já a governança destes projetos com métodos ágeis, enfatiza a criação de times disciplinados focados em maximizar o valor para o cliente. O modelo ágil difere do tradicional por trabalhar com processos empíricos, realizando uma pequena quantidade de trabalho para adquirir experiência (iteração). Utiliza-se ciclos adaptativos de forma iterativa e incremental.

O processo empírico planeja frequentemente e JIT (just in time). Há inspeção frequente dos resultados. O planejamento tradicional usa técnicas para determinar prazo e custo no início do projeto, porém em um sistema adaptativo complexo, conforme o cone da incerteza (figura 4), quanto mais cedo, maiores são as incertezas.

cone-incertezaFigura 4 – Cone da Incerteza


1   Validação de hipóteses

 Lean Inception

A Lean Inception é utilizada para os times que precisam desenvolver iterativamente um MVP, escolhendo as funcionalidades que tenham valor aos usuários, com base em premissas obtidas em testes. É uma técnica que corrobora o entendimento do que é preciso para criar um produto de sucesso (CAROLI, 2017).

Não substitui sessões de ideação, pesquisa de clientes, revisão de arquitetura ou análise de competitividade. Aplicável a grandes projetos, trabalha orientada a Lean, com iterações e testes, descobrindo funcionalidades que tenham valor aos usuários. Em pequenas organizações, como startups, utilize para validar ideias com MVPs e evoluir para um produto de software.

1.1.1 Write the product vision
Esta atividade auxilia a definir colaborativamente a visão do produto, que é a essência do valor de negócio do produto e a mensagem convincente aos usuários.

  1. Escreva o template de visão do produto em um quadro branco ou flipchart para que o time veja facilmente.
  2. Divida o time em grupos menores e peça que todos preencham os slots disponíveis.
  3. Junte o resultado de cada grupo e consolide as informações.

O roteiro de criação da visão do produto:
For [final client],
whose [problem that needs to be solved],
the [name of the product]
is a [product category]
that [key-benefits, reason to buy it].
Different from [competition alternative],
our product [key-difference].

product-vision.pngFigura 5Product Vision

1.1.2 The product is – Is not – Does – Does not
Explicar o produto descrevendo o que ele não é facilita a exploração e entendimento do que será criado. Esta atividade ajuda a explicar o produto, formando um consenso sobre o produto faz e o que ele não faz.

  1. Divida o flipchart em quatro áreas: Is / Is not / Does / Does not.
  2. Escreva o nome do produto acima dos quadrantes
  3. Incentive os participantes a descreverem o produto com post-its­ nas áreas correspondentes.
  4. Leia e agrupe anotações similares.

product-is-is-notFigura 6The product is – is not – does – does not

1.1.3 Describe the Personas
A persona representa o usuário no sistema, descrevendo seu papel e necessidades. Nosso propósito é criar uma representação realística do usuário, ajudando a descrever as funcionalidades do ponto de vista de quem terá interação com o produto final.

  1. Divida o time em pares ou trios. Entregue um template de personas para cada grupo.
  2. Peça que cada grupo crie uma persona, utilizando o template como referência.
  3. Cada grupo apresenta suas personas para o time inteiro.
  4. Divida novamente o time em diferentes grupos e repita os passos acima.

É importante realizar esta atividade em grupo, repetindo quantas vezes necessário. Se há a criação de muitas personas, podemos combinar e priorizá-las. Os stakeholders que conhecem os objetivos do projeto devem participar ativamente de tudo isso, auxiliando o time a identificar as personas e revisando suas descrições.

persona-AFigura 7Describe the persona A

persona-BFigura 8 – Describe the persona B

1.1.4 Discover the Features
Descreve a interação do usuário com o produto (da forma mais simples possível) ou algumas ações que o produto deve realizar.

  1. Colocar os objetivos do produto como títulos de coluna em um feature canvas único. Priorizar os objetivos da esquerda para a direita, de cima para baixo.
  2. Colocar as personas como títulos de linhas, priorizando de cima para baixo.
  3. Todos devem sugerir funcionalidades e colocá-las nas discussões. Utilize as personas e os objetivos para guiarem a discussão. A principal questão é: “o que o produto precisa fazer para que esta persona alcance seu objetivo”.

discover-features.pngFigura 9Discover the features

* embora o canvas pareça uma matriz, não necessariamente teremos uma funcionalidade para cada combinação de objetivo e persona. Podemos ter várias funcionalidades para uma persona atingir um objetivo específico. Também ter personas que não precisam de uma funcionalidade para um determinado objetivo.

1.1.5. Technical and Business Review
É feita uma avaliação das features em termos de esforço, valor e incerteza. Utilizaremos o canvas que desenvolvemos durante a sessão Discover the Features. Para o esforço e valor do negócio, anotamos as features utilizando marcações na escala de um, dois ou três.

effort-business-valueFigura 10Effort and business value

Figura 11Technical and business review

Classificamos a feature considerando aspectos técnicos de desenvolvimento (technical certainty) e aceitação do negócio (business agreement). Combinamos as duas classificações de acordo com o nível de incerteza: vermelho (alto), amarelo (médio) e verde (baixo). Se a feature estiver na parte inferior esquerda da tabela, marque com um “X”, pois não é aplicável ao MVP.

technical-certaintyFigura 12Business Agreement x Technical Certainty

business-agreeement-technical-certainty.pngFigura 13Business Agreement x Technical Certainty (Admission)

1.1.6 Show the User Journeys
Descreve a sequência de passos que o usuário percorre para atingir seu objetivo. Algum destes passos representam pontos de contato com o produto, demonstrando como o usuário interage com ele. O time levanta questões e alternativas sobre os desejos dos usuários e capacidades do produto.

  1. Selecione a persona
  2. Identifique um objetivo para esta persona.
  3. Escreva em post-it­ e coloque no topo à esquerda do
  4. Defina o ponto de partida e coloque em post-it­ no canvas. Questões de apoio: Como a persona começa seu dia? O que desperta a vontade de atingir seus objetivos?
  5. Descreva cada passo em sequência no post-it e coloque no canvas. Continue planejando os passos até a persona atingir seu objetivo.

user-journeyFigura 14User journey

1.1.7 Display Features in Journeys
Neste ponto temos uma lista de features que o produto deve ter, e as jornadas do usuário indicam como serão as interações com o produto. Integraremos então as duas perspectivas. Coloque as principais jornadas e features visíveis e lado a lado. Faça cada jornada, e para cada etapa, registre as features de que precisa.

features-in-journey.pngFigura 15Features in journey

Algumas jornadas estão faltando features: para isso, criamos cartões de feature, marcando o esforço, valor e incerteza. Algumas features não estão mapeadas na jornada: devemos desafiá-las, realmente precisamos se não participam das jornadas de nossos usuários?

1.1.8 Sequence the Features
Agora temos condições de trabalhar no primeiro MVP e nas iterações seguintes. Fazemos isso, definindo a Features Sequencer.

  1. Crie a Features Sequencer template (geralmente um flipchart com linhas numeradas)
  2. Explique as regras da Features Sequencer *
  3. Lembre todos do objetivo da atividade: definir a sequência de entrega das features do produto. O objetivo do MVP é aprender a cada iteração construindo um MVP que permitirá testar se o business case é efetivo.
  4. Todos devem colocar feature cards no sequencer, movendo eles enquanto exploramos as opções, até chegarmos a um acordo.
  5. O resultado mostra as features para cada iteração do MVP.

* as regras são: uma linha contém no máximo três features; uma linha não pode ter mais de uma feature com cartão vermelho (alta incerteza); cada linha deve ter ao menos um cartão verde (baixa incerteza); a contagem do esforço não pode adicionar mais que 5 Es; a contagem do valor deve somar pelo menos 4 $.

sequence-features.pngFigura 16Sequence the features

1.1.9 Build the MVP Canvas
Agora temos todo o conhecimento para construir o artefato final (MVP canvas) em cada iteração do MVP que definimos em Sequence the Features. O princípio é design centrado no usuário, considerando usuários e suas jornadas. Devemos trabalhar em ações que melhorem ou simplifiquem suas vidas e desenvolvendo hipóteses que podem testar o MVP.

  1. Visão do MVP: o que estamos tentando aprender?
  2. Declaração de resultado: o que acreditamos que este MVP irá alcançar? O que esperamos aprender?
  3. Métrica para validação de hipóteses de negócio: como você sabe quando pivotar e quando perseverar? O que determina sucesso ou falha? Quais dados devemos coletar?
  4. Personas e Plataformas: identificamos um grupo menor de personas que estaremos focando nesta iteração.
  5. Jornadas: revisão dos resultados de Show the User Journeys e Display Features in Journey.
  6. Features: relacionar as features para o MVP.
  7. Custos e prazos: em relação as features do MVP.

mvp-i.pngFigura 17 – MVP I

mvp-ii.pngFigura 18 – MVP II



Utilizamos o Lean UX (user experience) como guia para o processo de experiência do usuário. Trata-se de uma evolução do design do produto, com intensa colaboração e cross-functional. O shared understanding é o engajamento contínuo do time para falar sobre o que funciona (não apenas documentos e features), obtendo feedbacks do mercado. Devemos mensurar o que funciona, aprender e ajustar.

Em geral, Lean UX aborda três frentes:

  • Facilita o entendimento como uma mudança de processo para designers
  • É um mindset que nos permite abordar o trabalho de novas formas
  • Também é um pensamento sobre gerenciamento de software

Entre os princípios do Lean UX estão:

  • Cross-Functional Teams: várias disciplinas envolvidas na criação do produto.
  • Small, dedicated, colocated: manter os times pequenos (até 10 pessoas) dedicados a um projeto para melhorar a comunicação, foco e ambiente de trabalho.
  • Progress = Outcomes, not Output: features e serviços são outputs; atingir os objetivos de negócio são outcomes.
  • ProblemFocused Teams: atribuição de um time, que ao invés de trabalhar em features, ficará dedicado a resolução do problema. Desperta o senso de ownership.
  • Small Batch Size: mantém o inventário baixo e de alta qualidade. Evita um grande inventário de ideias não testadas e não implementadas.
  • Continuous Discovery: processo contínuo de engajamento do usuário durante o processo de design e desenvolvimento.
  • GOOB – The new user-centricity: “getting out of the building” significa que as respostas devem ser buscadas fora do escritório, em marketplace, por exemplo.
  • Shared understanding: conhecimento evoluído (do coletivo) sobre o ambiente, produto e usuários.
  • Anti-pattern: Rockstars, Gurus and Ninjas: Lean UX defende a mentalidade baseada em time. Evite perfis que possam afastar a colaboração.
  • Externalizing your work: utilize quadros, lembretes, etc. para manter um ambiente propício a ideias e inspiração de outras pessoas.
  • Making over analysis: há mais valor em criar a primeira versão de uma ideia do que dedicar metade de um dia debatendo em reuniões.
  • Learning over Growth: foco em aprendizado primeiro; escalar em segundo.
  • Permission to fail: para encontrar a solução do negócio, o time precisa experimentar ideias. Muitas destas ideias irão falhar, por isso crie a cultura da experimentação.
  • Getting out of the deliverables business: documentos não resolvem o problema do usuário, bons produtos sim. O time deve estar focado em trabalhar nas features com maior impacto para os usuários, medindo a reação do mercado em relação a qualidade do produto.

A área de Vision, Framing, and Outcomes descreve como mudamos radicalmente a forma de trabalho, tendo como objetivo a criação de outcomes, e não somente entregáveis. Para isso, algumas ferramentas são utilizadas na confirmação da hipótese, tais como Business Assumptions Worksheet, Hypotheses (utilização do roteiro para confirmação da hipótese), Subhypotheses (quebra da hipótese em partes menores), Outcomes, Personas (uso da Proto-Personas e Persona Format para moldar quem estará utilizando) e Features.

O Collaborative Design aborda o processo de design com técnicas familiares, mas com ênfase no trabalho colaborativo. O objetivo inicial é a velocidade, priorizando o aprendizado e o uso do MVP como ferramenta chave. Entre as principais técnicas estão: Design Studio (coloca o time cross-functional para trabalhar juntos e visualizar potenciais soluções para o problema) e Style Guides (accessible, continually improved e actionable).  

Em MVPs and Experiments, os experimentos são utilizados para validar hipóteses no mercado e criar produtos baseado no aprendizado. E assim trabalhar na criação do MVP com ou sem protótipos. Com protótipos, existe o low-fidelity para expor ao time o senso de como o produto deve funcionar. Já mid and high-fidelity possuem mais detalhes e testam designs em nível de interação, visual e conteúdo similar a experiência do produto final.

Por fim, o Feedback and Research trabalha com inputs dos usuários (contínuos feedbacks) que contribuem para o processo de design, incorporando a iterações de produtos. As principais técnicas são: pesquisa contínua (Continuous Discovery) e colaborativa (Collaborative Discovery), artefatos de teste (Sketches), incorporar a opinião do usuário no ciclo Lean UX (static wireframes, mockups, prototypes), uso de testes A/B e reconciliar feedback de diferentes fontes.



Embora o Lean UX tenha uma recomendação de integração com o Agile, vamos trabalhar com as práticas do framework ágil Scrum para execução do backlog e validação dos produtos que serão desenvolvidos com base nas técnicas citadas anteriormente. O Scrum é fundamentado no empirismo, empregando uma abordagem iterativa e incremental para melhorar a previsibilidade e controle de riscos.

Teremos quatro eventos formais para inspeção e adaptação da Sprint: Planning, daily, review e retrospective. O time será composto do time de desenvolvimento, Product Owner (PO) e Scrum Master (SM). O PO é o responsável por gerenciar o backlog do produto, enquanto o SM é um servo-líder para o time e o time de desenvolvimento realiza o trabalho de entregar uma versão usável do produto (incremento).

A Sprint é um time-boxed de dez dias úteis (em nosso caso) de trabalho para entregar a versão incremental potencialmente utilizável do produto. A Sprint Planning é a reunião colaborativa, que define o backlog a ser feito na Sprint. A Daily possui apenas 15 minutos e serve como inspeção do trabalho desde o dia anterior e o trabalho a ser feito até a próxima Daily.

A Review, executada no final da Sprint, promove a colaboração para identificar ajustes no backlog do produto. E a Retrospective inspeciona o próprio time e cria um plano de melhorias a serem aplicadas na próxima Sprint.

Sendo assim, o backlog do produto relaciona tudo que o produto deve ter, os itens selecionados para a Sprint junto ao plano para entregar o incremento do produto e atingir o objetivo da Sprint são chamados de backlog da Sprint. Por fim, o incremento representa todos os itens completados nas Sprints.

As práticas como burndown e burnup são representações usadas para prever o progresso. Embora muito úteis, não substituem a importância do empirismo e das reuniões mencionadas que contribuem para a inspeção e adaptação do projeto.



A competitividade no mercado digital propõe inúmeros desafios as empresas que precisam adotar um modelo dinâmico de criação produtos, entregando valor ao usuário e uma boa experiência nesta jornada de compra. Neste estudo, avaliamos as técnicas Lean Inception, Lean UX e Agile (Scrum), com o propósito de criar MVPs (Produto Mínimo Viável) e validar hipóteses no mercado. A experimentação e o aprendizado serviram como direcionadores de investimentos no negócio.

As três técnicas em conjunto contribuíram para criar um modelo de experimentação enxuto e contínuo, trabalhando desde a concepção do produto Admission (sistema de captação de candidatos para converter em matriculas) até a implementação de novas funcionalidades em produção. Escrevemos então a visão do produto, o que ele é e o que ele não é, as personas, jornadas, features e priorizamos de acordo com o valor para o negócio e dificuldade técnica.

Considerando a UX (experiência do usuário) e os feedbacks como imprescindíveis para aprender e ajustar a criação, mudança ou adequação de produtos. O gerenciamento ágil efetiva o time-to-market e o produto idealizado é executado em Sprints (time box de 2 semanas), conforme priorização do backlog. O backlog possui as atividades necessárias para desenvolvimento do produto acordado nas sessões. As reuniões diárias (dailys), retrospectiva, review e a demo são utilizadas para inspecionar o progresso do desenvolvimento e ajustes necessários.



CAROLI, Paulo. Direto ao ponto: criando produtos de forma enxuta, 2015.

Design Thinking: ferramenta de inovação para empreendedores. Disponível em: <>. Acesso em: 19 jun. 2018.

Design Thinking 101 –  The Double Diamond Approach. Disponível em: <>. Acesso em: 19 jun. 2018.

GOTHELF, Jeff; SEIDEN, Josh; Lean UX: Applying Lean Principles to Improve User Experience.

Lean Inception. Disponível em: <>. Acesso em: 07 mai. 2018.

Marketing 4.0: do Tradicional ao Digital, passo a passo. Disponível em: <>. Acesso em: 13 mai. 2018.

Marketing 4.0 – Oportunidades e Tendências. Kotler 2017. Disponível em: <>. Acesso em: 15 mai. 2018.

Metodologias Ágeis. Disponível em: <>. Acesso em: 25 jun. 2018.

MVP: entenda as principais vantagens ao utilizá-lo. Disponível em: <>. Acesso em 23 mai. 2018.

MVP: guia completo do Produto Viável Mínimo. Disponível em: <>. Acesso em: 24 mai. 2018.

MVP: O que é e como fazer o produto mínimo viável? Disponível em: <>. Acesso em 24 mai. 2018.

RIES, Eric. Lean Startup. Crown Publishing Group, 2011. Disponível em: <>. Acesso em: 02 jul. 2018.

The Differences: Lean Startup vs Agile Methodology. Disponível em: <>. Acesso em: 14 jun. 2018.

The Lean Startup. Disponível em <>. Acesso em 11 jun. 2018.

UX Canvas. Disponível em: <>. Acesso em: 22 mai. 2018.

Lean UX – Book Summary (Applying Lean Principles to Improve User Experience)

Section I: Introduction and Principles

Chapter 1 – Why Lean UX?

Lean UX is the evolution of product design. It takes the best parts of the designer’s tool kit and recombines them in a way that makes them relevant to this new reality.

  • It’s deeply collaborative and cross-functional
  • We can’t continue to ask our teams to wait for us to figure it all out. We need daily, continuous engagement with our teams if we are going to be effective
  • Instead of talking about features and documents, we can talk about what works, and measure (market feedback) what works, learn, and adjust

Lean UX is three things:

  • It’s easiest to understand as a process change for designers
  • It’s a mindset that lets us approach our work in new ways
  • It’s also a way of thinking about managing software


Chapter 2 – Principles

Lean UX stands on three foundations

1. The Lean principles underlying Lean Startup apply to Lean UX in these ways:

  • They help us remove waste from our UX design process. We move away from heavily documented handoffs to a process that creates only the design artifacts we need to move the team’s learning forward.
  • Second, they drive us to harmonize our “system” of designers, developers, product managers, quality assurance engineers, marketers, and others in a transparent, cross-functional collaboration that brings nondesigners into our design process.
  • Last, and perhaps most important, is the mindset shift we gain from adopting a model based on experimentation. Instead of relying on a hero designer to divine the best solution from a single point of view, we use rapid experimentation and measurement to learn quickly how well (or not) our ideas meet our goals.

2. Design thinking: takes a solution focused approach to problem solving, working collaboratively to iterate an endless, shifting path toward perfection. It works toward product goals via specific ideation, prototyping, implementation, and learning steps to bring the appropriate solution to light.

3. Agile development philosophies: refocuses software development on value. It seeks to deliver working software to customers quickly and to adjust regularly to new learning along the way.

As you explore the Lean UX approach, keep these principles in mind. Think of your experience with Lean UX as a learning journey. Use these principles to keep you and your team on course:

  • Cross-Functional Teams | Small, Dedicated, Colocated | Progress = Outcomes, Not Output | Problem-Focused Teams | Removing Waste | Small Batch Size | Continuous Discovery | The New User-Centricity | Shared Understanding | Anti-Pattern: Rockstars, Gurus, and Ninjas | Externalizing Your Work | Making over Analysis | Learning over Growth | Permission to Fail | Getting Out of the Deliverables Business


Section II: Process

Chapter 3 – Vision, Framing and Outcomes

Describes how Lean UX radically shifts the way we frame our work. The goal is not to create a deliverable, it’s to change something in the world—to create an outcome. And how we can reframe our work in terms of outcomes to search for the best solutions to the problem at hand.

Declaring outcomes, an important process, means to start with the project’s problem statements and then acknowledge our assumptions, then transform these assumptions into hypotheses. Also how to write hypothesis statements that capture intended features, audience, and goals, and that are specific enough to be tested. You’ll end up with statements that will serve as the roadmap for the next step of the Lean UX process: collaborative design.

The hypothesis statement is a way of expressing assumptions in testable form. It is composed of the following elements: Assumptions, Vision, Framing, and Outcomes, Hypotheses, Outcomes, Personas and Features.

And the recommended tools to validate hypotheses are: Business Assumptions Worksheet, Subhypotheses, Outcomes, Personas e Features.


Chapter 4 – Collaborative Design

After written the hypothesis, it’s time to determine what you’ll need to test assumptions.


Describes the shift in the design process. Lean UX uses many techniques familiar to designers but shifts the emphasis of work, becoming more collaborative. We aim for speed first. We prioritize learning. We use a key tool to achieve this: the MVP.

It’s shown how the low-fidelity drawings created in Design Studio sessions can help teams generate many ideas and then converge on a set the entire team can get behind. And practical techniques that can be used to create shared understanding, the fundamental currency of Lean UX.

Using tools such as style guides (accessible, continually improved e actionable), Design Studio (example in image below), and simple conversation, your team members can build a shared understanding that allows them to move forward at a much faster pace than in traditional environments.



Chapter 5 – MVPs and Experiments

Lean UX is based on the idea that we begin our work with an assumption. We use experiments to test our assumptions and then build on what we learn in those experiments. This chapter shows you how to orient your design process around experiments and learning.

In this chapter, we defined the Minimum Viable Product as the smallest thing you can make to learn whether your hypothesis is valid. In addition, we discussed the various forms an MVP can take, took a closer look at prototyping, and discussed tactics for learning that don’t require building prototypes. For example:

Low-Fidelity Prototypes: Paper and Clickable Wireframeslow-prototype.png

Mid- and High Fidelity Prototypes

Hand-coded and live-data prototypes
There are two levels of fidelity for coded prototypes: hand-coded and live data:

  • Hand-coded prototypes: look and function like the end product, but don’t account for any kind of real-time data input, processing, or output. They are still just simulations.
  • Live-data prototypes: will connect with real-time data and process user input. These are often deployed to real customers and offer a level of analytical insight into customers’ usage of the prototype that is not available from hand-coded prototypes. They can also be used when A/B testing certain features or changes to the current workflow.

And finally there are Types of Non-Prototype MVPs as Email, Google Ad Words, Landing Page and the button to nowhere.

Chapter 6 – Feedback and Research

User Experience work in any form requires good input from users. Lean UX puts a premium on continuous feedback to help us guide our design process. This chapter shows techniques that Lean UX teams use to get feedback early and often, and how to incorporate that feedback into future product iterations.

It’s presented many ways to start validating the MVPs and experiments built around hypotheses. The main techniques are: Continuous Discovery, Collaborative Design, Sketches, Onsite Feedback Surveys, incorporate the voice of the customer throughout the Lean UX cycle (static wireframes, mockups, prototypes) and using A/B tests in your research.

And how to build a lean usability-testing process every week and covered what you should test and what to expect from those tests. These techniques, used in conjunction with the processes outlined in Chapters 3 through 5, make up the full Lean UX process loop. Your goal is to cycle through this loop as often as possible, refining your thinking with each iteration.



Section III: Making it work

Chapter 7 – Integrating Lean UX and Agile

Here will be demonstrated the tactics discussed in Section II and show exactly how they fit into a typical Scrum process and how they make it more effective. First of all, read more about Scrum and be familiar with definitions (user story, backlog, sprint, stand-up, retrospective, planning meeting).

Building Lean UX into the Rhythm of Scrum

Themes: many people frown on Scrum meetings, but if you use them as mileposts during your sprint, you can create an integrated Lean UX and Agile process in which the entire team is working on the same thing at the same time.

Kickoff Sessions for Sketching and Ideation: each theme should be kicked off with a series of brainstorming and validation exercises like the ones described in Section II. The point of this kickoff is to get the entire team sketching and ideating together, creating a backlog of ideas to test and learn from.

Iteration Planning Meeting: the output of the kickoff session should be brought to the IPM. You made the artifacts (sticky notes, sketches, wireframes, paper prototypes) together and because of that, you have the shared understanding necessary to extract stories from them. Then evaluate and prioritize the stories.

User Validation Schedule: to ensure a constant stream of customer voices to validate against, plan user sessions every single week. Your team will never be more than five business days away from customer validation but still your ideas will have ample time to react prior to the end of the sprint. Use the artifacts you created in the ideation sessions as the base material for your user tests. Remember that when the ideas are raw, you are testing for value (i.e., do people want to use my product?). Once you have established a desire for your product, subsequent tests with higher fidelity artifacts will reveal whether your solution is usable.


In addition, we can see how cross-functional collaboration allows a team to move forward at a brisk pace and how to handle those pesky stakeholders and managers who always want to know what’s going on.


Chapter 8 – Making Organizational Shifts

In this chapter, we’ll discuss the following changes your organization may need to make in these areas. It’s not just software developers and designers who need to find a way to work together. Product managers, project managers—in short, your whole product development engine—is going to need to change if you want to create a truly Agile organization.

  • Shifting from output to outcomes
  • Moving from limited roles to collaborative capabilities
  • Embracing new skills
  • Creating cross-functional teams
  • Creating small teams
  • Creating open, collaborative workspaces
  • Not relying on heroes
  • Eliminating “Big Design Up Front”
  • Placing speed first, aesthetics second
  • Valuing problem solving
  • Embracing UX debt
  • Shifting agency culture
  • Working with third-party vendors
  • Navigating documentation standards
  • Being realistic about your environment
  • Managing up and out



The Lean Startup – Book Summary

Lean Startup Method

  1. Entrepreneurs are everywhere: a human institution designed to create new products and services under conditions of extreme uncertainty
  2. Entrepreneurship is management: a startup is an institution, not just a product
  3. Validated learning: startups exist to learn how to build a sustainable business, running frequent experiments that allow entrepreneurs to test each element of their vision.
  4. Build-Measure-Learn: turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere (feedback loop).
  5. Innovation accounting: focus on the boring stuff: how to measure progress, how to set up milestones, and how to prioritize work.


The book is divided in three parts:

  • Vision: how the startups are gauging the progress, and using that learning, with scientific experimentation, to build a sustainable business
  • Steer: understand the core Build-Measure-Learn feedback loop to build a MVP (minimum viable product) and validate your assumptions. If that are making progress or deciding to pivot the direction.
  • Accelerate: techniques that enable Lean Startups, lean manufacturing, organizational design and products growth



1. Start

Lean Startup adapts lean manufacturing revolution – developed at Toyota by Taiichi Ohno and Shigeo Shingo, based on shrinking of batch sizes and just-in-time production – to the context of entrepreneurship, using validated learning to track their progress.

“Startups often accidentally build something nobody wants, it doesn’t matter much if they do it on time and on budget. The goal of a startup is to figure out the right thing to build—the thing customers want and will pay for—as quickly as possible”.

Comparing with Ford’s thinking, Startups have a similar engine that is called engine of growth. Every new features, product is an attempt to improve this engine of growth. The Lean Startup method is designed to make constant adjustments with a steering wheel called the Build-Measure-Learn feedback loop.

The chart below shows that while Products change constantly the process of optimization, the Strategy less frequently may have to change (pivot). However, the overarching Vision rarely changes.

2. Define

The difference between “Intrapreneurs” – who operate inside an established organization within special circumstances attend building a startup within a larger company – and Entrepreneur – the whole startup ecosystem regardless of company size, sector, or stage of development.

Also the SnapTax amazing innovation story and the technology developed to compile and file most of the 1040 EZ tax return (taking a picture), instead of having consumers fill out a complex form. What allowed the SnapTax team to innovate was a process deliberately facilitated by Intuit’s senior management.

“Innovation is a bottoms-up, decentralized, and unpredictable thing, but that doesn’t mean it cannot be managed. It can, but to do so requires a new management discipline, one that needs to be mastered not just by practicing entrepreneurs seeking to build the next big thing but also by the people who support them, nurture them, and hold them accountable”.

3. Learn

Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects. It is more concrete, more accurate, and faster than market forecasting or classical business planning. It is the principal antidote to the lethal problem of achieving failure: successfully executing a plan that leads nowhere”.

As example, the IM add-on product that spent too many hours including features and fixing bugs before launching, and that was not talking to customer. The result was a serious frustration: customers wouldn’t even have downloaded the product. And the following changes to validate the user experience.

Value Vs. Waste – “Lean thinking defines value as providing benefit to the customer; anything else is waste”. So, validated learning is backed up by empirical data collected from real customers, the essential unit of progress for startups.

4. Experiment

If you cannot fail, you cannot learn…

…experiment, identify the elements of the plan that are assumptions rather than facts, and figure out ways to test them.

This part of the book mentions the case of Zappos – world’s largest online shoe store and was acquired by Amazon in 2009 – and how the company interacted with customers and learned about their needs. The qualitative learning, applying quantitative testing, was necessary to experiment and provide a clear vision about the customer needs.

“The Lean Startup model offers a way to test these hypotheses rigorously, immediately, and thoroughly. Strategic planning takes months to complete; these experiments could begin immediately. By starting small, Caroline (HP – Hewlett-Packard director) could prevent a tremendous amount of waste down the road without compromising her overall vision”.

The recommendation here is to start breaking down the vision into component parts. Afterwards, the value hypothesis to verify whether a product or service really delivers value to customers. And the growth hypothesis to explore more details during the tests.

As example, the Kodak case and how they worked at early stage, allowing customers to use the prototype and helped the team to refute their hypotheses. The employees were used to being measured on their progress at completing tasks. As Cook says, “Success is not delivering a feature; success is learning how to solve the customer’s problem.”



In Part I we’ve learned: the products a startup builds are really experiments; the learning about how to build a sustainable business is the outcome of those experiments. For startups, that information is much more important than dollars, awards, or mentions in the press, because it can influence and reshape the next set of ideas.

The first step is to enter the Build phase as quickly as possible with a minimum viable product (MVP). The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.

In the Measure phase, the biggest challenge will be determining whether the product development efforts are leading to real progress. Learning milestones are useful for entrepreneurs as a way of assessing their progress accurately and objectively.

Finally, and most important, there’s the pivot. Upon completing the Build-Measure-Learn loop, we confront the most difficult question any entrepreneur faces: whether to pivot the original strategy or persevere. If we’ve discovered that one of our hypotheses is false, it is time to make a major change to a new strategic hypothesis.

5. Leap

Strategy is based on assumptions? Every business plan begins with a set of assumptions and how to achieve the company’s vision. And the assumptions haven’t been proved to be true and in fact are often erroneous, the goal of a startup’s early efforts should be to test them as quickly as possible. Facebook’s early investors was criticized, claiming the social network had “no business model”, but nowadays lots of startups try to apply the lessons of Facebook and the role of strategy that is to help figure out the right question to ask.

6. Test

The Video produced by Dropbox, a simple three-minute demonstration of the technology synchronizing the files, drove hundreds of thousands of people to the website. The MVP validated Drew’s leap-of-faith assumption that customers wanted the product he was developing not because they said so in a focus group or because of a hopeful analogy to another business, but because they actually signed up. Today, Dropbox is one of Silicon Valley’s hottest companies, rumored to be worth more than $1 billion.

Often we are not sure who the customer is. Thus, for startups, consider the following quality principle: If we do not know who the customer is, we do not know what quality is. Even a “low-quality” MVP can act in service of building a great high-quality product. Yes, MVPs sometimes are perceived as low quality by customers. If so, we should use this as an opportunity to learn what attributes customers care about.

This is infinitely better than mere speculation or whiteboard strategizing, because it provides a solid empirical foundation on which to build future products. As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.

7. Measure

Three learning milestones in how innovation accounting works:

  • First, use a MVP to establish real data on where the company is right now. Without a clear-eyed picture of your current status, you cannot begin to track your progress.
  • Second, startups must attempt to tune the engine from the baseline toward the ideal.
  • Third, pivot or persevere.

Cohort analysis, one of the most important tool of startup analytics, looks at the performance of each group of customers that comes into contact with the product independently. Each group is called a cohort. Instead of looking at cumulative totals or gross numbers such as total revenue and total number of customers.

A split-test experiment is one in which different versions of product are offered to customers at the same time (this technique is sometimes called A/B). By observing the changes in behavior between the two groups, one can make inferences about the impact of the different variations.

8. Pivot

David Binetti, the CEO of Votizen, discovered in the first MVP (using cohorts) that 5 percent signed up for the service and 17 percent verified their registered voter status. The numbers were so low that there wasn’t enough data to tell what sort of engagement or referral would occur. It was time to start iterating.

David spent the next two months and another $5,000 split testing new product features, messaging, and improving the product’s design to make it easier to use. Those tests showed dramatic improvements, going from a 5 percent registration rate to 17 percent and from a 17 percent activation rate to over 90 percent. Such is the power of split testing. This optimization gave David a critical mass of customers with which to measure the next two leaps of faith. However, as shown in the chart below, those numbers proved to be even more discouraging: David achieved a referral rate of only 4 percent and a retention rate of 5 percent.

The true measure of runway is how many pivots a startup has left: the number of opportunities it has to make a fundamental change to its business strategy. In other words, the startup has to find ways to achieve the same amount of validated learning at lower cost or in a shorter time.

A pivot is a special kind of change designed to test a new fundamental hypothesis about the product, business model, and engine of growth. There are different types of pivots:

  • Zoom-in Pivot: what previously was considered a single feature in a product becomes the whole product
  • Zoom-out Pivot: what was considered the whole product becomes a single feature of a much larger product
  • Customer Segment Pivot: the product hypothesis is partially confirmed, solving the right problem, but for a different customer than originally anticipated
  • Customer Need Pivot: pivot the way into an entirely different line of business based on the customer intimacy
  • Platform Pivot: a change from an application to a platform or vice versa
  • Business Architecture Pivot: switches architectures, for example, some companies change from high margin, low volume by going mass market
  • Value Capture Pivot: methods like monetization or revenue models
  • Engine of Growth Pivot: change its growth strategy – the engine (the viral, sticky and paid growth)
  • Channel Pivot: is a recognition that the same basic solution could be delivered through a different channel with greater effectiveness
  • Technology Pivot: they are a sustaining innovation, an incremental improvement designed to appeal to and retain an existing customer base. The only question is whether the new technology can provide superior price and/or performance compared with the existing technology


Start Your Engines

The critical first question for any lean transformation is: which activities create value and which are a form of waste? Once you understand this distinction, you can begin using lean techniques to drive out waste and increase the efficiency of the value-creating activities.

9. Batch

Toyota discovered that small batches made their factories more efficient. In contrast, in the Lean Startup the goal is not to produce more stuff efficiently. It is to—as quickly as possible—learn how to build a sustainable business.

Working in small batches ensures that a startup can minimize the expenditure of time, money, and effort that ultimately turns out to have been wasted.

10. Grow

Sustainable growth is characterized by one simple rule: new customer come from the actions of past customers. There are four ways past customer’s drive:

  • Word of mouth – caused by satisfied customer’s enthusiasm for the product
  • As a side effect of product usage
  • Through funded advertising
  • Through repeat purchase or use


11. Adapt

Five Whys provides an opportunity to discover what that human problem might be. Repeating “why” five times, can help uncover the root problem and correct it. And the Five Whys approach acts as a natural speed regulator. The more problems you have, the more you invest in solutions to those problems.

12. Innovate

An Innovation Sandbox is to create a mechanism for empowering innovation teams out in the open and a sustainable culture of innovation over time. The suggested solution is to create a sandbox that contains the impact of the new innovation but not constrain the methods of the startup team:

  • Any team can create a true split-test experiment that affects
    only the sandboxed parts of the product or service. However:
  • One team must see the whole experiment through from end to
  • No experiment can run longer than a specified amount of time
  • No experiment can affect more than a specified number of customers
  • Every experiment has to be evaluated on the basis of a single standard report of five to ten (no more) actionable metrics.
  • Every team that works inside the sandbox and every product that is built must use the same metrics to evaluate success.
  • Any team that creates an experiment must monitor the metrics and customer reactions while the experiment is in progress and abort it if something catastrophic happens.


At the beginning, the sandbox has to be quite small. In the company above, the sandbox initially contained only the pricing page. Depending on the types of products the company makes, the size of the sandbox can be defined in different ways.

Companies trying to bring an entirely new product to market might build the restriction around customers in certain segments. Unlike in a concept test or market test, customers in the sandbox are considered real and the innovation team is allowed to attempt to establish a long-term relationship with them. After all, they may be experimenting with those early adopters for a long time before their learning milestones are accomplished.

13. Epilogue: Waste Not

As Deming taught, what matters is not setting quantitative goals but fixing the method by which those goals are attained. The Lean Startup movement stands for the principle that the scientific method can be brought to bear to answer the most pressing innovation question: How can we build a sustainable organization around a new set of products or services?

In Conclusion

For one thing, everyone would insist that assumptions be stated explicitly and tested rigorously not as a stalling tactic or a form of make-work but out of a genuine desire to discover the truth that underlies every project’s vision.

We would not waste time on endless arguments between the defenders of quality and the cowboys of reckless advance; instead, we would recognize that speed and quality are allies in the pursuit of the customer’s long-term benefit. We would race to test our vision but not to abandon it. We would look to eliminate waste not to build quality castles in the sky but in the service of agility and breakthrough business results.

We would respond to failures and setbacks with honesty and learning, not with recriminations and blame. More than that, we would shun the impulse to slow down, increase batch size, and indulge in the curse of prevention. Instead, we would achieve speed by bypassing the excess work that does not lead to learning. We would dedicate ourselves to the creation of new institutions with a long-term mission to build sustainable value and change the world for the better.

Most of all, we would stop wasting people’s time.