5  The Five Principles of Lean

Everything should be made as simple as possible, but not simpler. — Albert Einstein

5.1 Why This Chapter Matters

In the last chapter, we learned the basic vocabulary of lean: firm, customer, value and process. But it’s not enough to know firms create value through processes. When we’re trying to improve a process we still need to know:

  • What should we look for?
  • What should better process behavior feel like?
  • What kinds of system design usually support it?

This chapter introduces five core Lean principles that help answer those questions. With these principles, teams will know what they are looking for when they map and measure work. Think of the principles as telling us what kind of system we’re trying to build.

5.2 Learning Objectives

By the end of this chapter, the student will be able to:

  • Lean Six Sigma Principles and Tools Explain the five Lean principles as a sequence for directing process improvement, from defining customer value through pursuing continued improvement Bloom:Understand
  • Lean Six Sigma Principles and Tools Explain the difference between flow and pull by contrasting continuous-flow behavior with batching and pull control with push scheduling Bloom:Understand
  • Lean Six Sigma Principles and Tools Analyze a simple process to identify likely violations of Lean principles and justify each diagnosis with observable process behavior Bloom:Analyze

5.3 Five Principles Overview

There are many methodologies and frameworks for process improvement. At the White Belt level, we will focus on practical fundamentals of the Lean side of Lean Six Sigma. The history of Lean and the production systems that preceded it will have to wait for later. Here, our concern is practical: what direction should process improvement take?

The heart of the Lean methodology can be summarized in five core principles:

  1. Define value from the customer point of view
  2. Map the process1
  3. Create flow
  4. Establish pull
  5. Pursue perfection

The order matters. First, we identify the outcome the customer values; otherwise, we may efficiently produce the wrong thing. Second, we make the process visible so that we can examine how work actually creates that outcome. Third, we improve the movement of work by reducing unnecessary waiting, interruption, and batching. Fourth, we control when work begins so that actual demand and downstream capacity—not arbitrary schedules—govern its release. Finally, we repeat the cycle because customer needs and operating conditions continue to change.

The principles are easy to state but not always intuitive to apply. Premature local optimizations can obstruct system-wide flow. Keeping every person or machine busy can create more work than the process can absorb. Engineering a better process usually involves thinking carefully about tradeoffs just like this. The five principles give us a direction for judging those tradeoffs.

5.4 Defining Value from the Customer Point of View

The previous chapter established that the customer, not the firm, defines value. The practical question is to figure out what the customer values.

At White Belt level, begin by asking. A face-to-face conversation can reveal what outcome the customer seeks, what frustrates them, and what tradeoffs matter most. Surveys, focus groups, complaints, reviews, and interviews provide other ways to listen. In digital services, usage data can also show what customers actually do.

The effort to understand customer needs is often called listening to the Voice of the Customer, or VoC. You may also encounter the voice of the business, the voice of employees, and the voice of the process. The voice of the business identifies financial, strategic, legal, and operational constraints. Employees contribute knowledge about how the work is actually performed. Finally, in many cases, especially in the world of manufacturing, the process itself produces evidence about its own timing, variation, defects, and capacity in the form of event logs, error messages, dashboards, and so on. All four voices matter, but they answer different questions. The customer’s voice remains primary when defining value because the firm exists to deliver an outcome the customer (or somebody acting on his or her behalf) is willing to fund.

Designing rigorous surveys or analyzing behavioral data is beyond the scope of this chapter, but one caution matters now: asking is a starting point, not proof. Customers may struggle to articulate what they need, and what they say may differ from what they choose, use, or reject. Whenever possible, we should compare stated preferences with actual, observable behavior.

Because the Wash n’ Fold case study is fictional, there aren’t any actual customers to talk to. So, instead just try to imagine what you would like your laundry to be like, if you were a customer of this business.

You probably came up with a short list like:

  • clean
  • undamaged
  • dry
  • folded
  • available for pickup no later than 5:00 p.m.

We don’t need a fancy tool or template to do this exercise, but it is good to bring all of these requirements to mind before proceeding, even if the only thing customers are currently complaining about is the pickup time.

Often it is helpful to think of value in terms of customer specifications.

Definition 5.1  

NoteDefinition Customer Specifications

A customer specification is a precise, measurable property the finished good or service needs to have in order to meet the customer’s need.

Usually we have to do a little work to translate vague customer feedback into true customer specifications. Customers want tires that are long-lasting, safe, provide adequate traction, and so on. It’s up to the folks at Michelin to figure out how long, “long-lasting” is and how to measure it. Is it 30,000 miles or 50,000? What does “safe” really entail in terms of stopping distance at 30 mph or 60 mph? Take a step back and ask yourself what are these engineers really doing?

They are trying to understand what the customer values and translate that into a set of specifications they can design the tire to meet.

In our case, the key customer specification is really easy. The laundry just needs to be dry and folded and ready for pickup by 5:00 p.m. At later belt levels, translating customer feedback into explicit specifications becomes less straightforward.

5.5 Mapping the Process

Real processes can be distributed across many different people, systems, departments, and sometimes even different organizations. Each process participant usually sees only their own local piece of that vast complex system. A process map creates an end-to-end model so that the team can examine how those pieces interact.

But what exactly are we looking for from the process map?

In the first place we are looking for what has to happen to deliver the quality the customer expects. What does the firm have to do to create laundry that is clean, undamaged, dry, and folded? We’ll obviously be looking for a “wash” step, a “dry” step, and a “fold” step. But what our map is going to do is help us see what else is taking place in the process outside those obvious steps.

Mapping makes boundaries, sequence, handoffs, queues, decision points, rework, and responsibility visible. By doing so, the map can reveal that an apparent problem in one department is produced by an upstream decision or that improving one step merely moves the queue somewhere else. Strictly speaking, anything we see in our process that isn’t creating value for the customer is waste. In Chapter 10 we will detail eight common kinds of waste and what we do about them. For now, think of waste as anything in the process that isn’t needed to deliver value to the customer.

The process map is a very important tool, but remember it is still only a model. It must be checked against observation, process records, and the knowledge of people who perform the work. Mapping the official procedure without observing the actual process can hide the very behavior we need to improve. This is why we always begin by mapping the work as we observe the staff actually perform it, not just according to some specification or standard operating procedure document.

TipPro Tip

Managers and supervisors often understand a business process based on official documentation or policy. But policies are often ambiguous and rarely fully specify what exactly has to be done. Different offices or even different employees in the same office may have different interpretations of the policy. This is a common source of process variants. So it often comes as a surprise to managers and supervisors to discover that their supposedly “simple” process is being performed differently by different people.

Standardizing a process on the most efficient variant is a common solution to process problems in that case. But we must standardize very carefully.

Why did the employees perform the work in different ways? Were there software limitations that had to be worked around? Are there different local regulations in this location that force changes? All this has to be investigated thoroughly.

At the White Belt level, we begin with a bounded process and a simple mapping method I will call the Simplest Possible Process Map, or SPPM Method. The SPPM captures the information needed for a first improvement cycle. We will learn to create and validate an SPPM in Section 7.1. Then in Chapter 8 we will build an SPPM for the Wash n’ Fold laundry process. More advanced belt levels will introduce additional mapping methods.

5.6 Creating Flow

The third principle concerns the movement of work. Once a process run begins, how directly does the unit travel from one step to the next? Does it move continuously, or does it stop in queues, wait for a batch to fill, return for rework, and compete with other priorities?

In our Wash n’ Fold case, we might investigate whether loads of laundry are batched and if so how much time specific loads of laundry spend in a queue waiting for the next batch to run. Batch queues are a frequent, but usually invisible time suck in a process.

To see why, notice flow depends on more than just the sequence of steps in the process itself. It depends on how the firm coordinates the people, locates and services equipment, stores and retrieves materials, and communicates information needed to perform those steps. That larger arrangement is called the production system.

Definition 5.2  

NoteDefinition: Production System

A production system is the organization of people, processes, machinery, materials, and information necessary to create a product or provide a service.

Batching and continuous flow are two diametrically opposite ways to organize a production system.

Definition 5.3  

NoteDefinition: Batch Processing Production System

A batch-processing production system accumulates multiple units and processes them as a group before releasing the group to the next step.

Definition 5.4  

NoteDefinition: Continuous Flow Production System

In a continuous-flow production system, each unit begins the next step as soon as the preceding step is complete and the next step is available.

Batching can appear efficient. Every time we have to change over from producing one thing to another, we have some overhead. We may have to set up a machine, retrieve tools, clean equipment, or transport material. A larger batch spreads that setup cost across more units. In some cases, batching may even be necessary. Examples include:

  • changing the dies on a mechanical press;
  • firing multiple ceramic pieces in the same kiln; and
  • transporting material when each trip has a substantial fixed cost.

But the local efficiency of a large batch often creates system-level costs. The first completed unit must wait for the rest of its batch before moving forward. Work accumulates between steps, increasing lead time and consuming space. A defect discovered at the next step may already have been repeated across the entire batch. Large batches also make it harder to change priorities or respond quickly when customer demand changes.

For this reason, large quantities of work in progress waiting around for processing are often a red flag for process improvement, as we shall discuss in more detail in Chapter 10.

Continuous flow reduces those delays by moving units forward in smaller quantities. It shortens feedback loops, exposes problems sooner, and makes the current state of the process easier to see. The directional principle is therefore to reduce batch size and interruption as far as practical. Not every process can operate literally one unit at a time, but in general the smaller and more frequent you can make your batches, the healthier and more effective your process will be.

It is helpful to see these principles in action. The following video is optional; the surrounding text contains the instruction needed for the White Belt path. The demonstration uses the term “one-piece flow” for what I’m calling “continuous flow,” but it is the same idea:

NoteOptional Video: One Piece Flow vs. Batch Processing

Watch “One Piece Flow vs. Batch Processing” on YouTube (GEMBA Academy, ~5 min)

This book links to the publisher’s copy; it does not reproduce the video.

NoteMedia Credit

Source: One Piece Flow vs. Batch Processing, YouTube. Publisher and uploader: GEMBA Academy.

Rights: Reference link only; no recording, still, or transcript is redistributed or relicensed by this book.

When examining a process, ask where work stops after it has begun and why. Those stopping points tell us how well the work flows much more accurately than looking to see whether the employees look busy.

In practice, creating flow means removing evidenced obstacles to the next step, preparing handoffs, reducing unnecessary travel and batching, and arranging enough capacity to meet the customer’s required pace. Once we have learned to measure that pace and the actual work, Chapter 11 will show how to draft a small flow-and-pull experiment, including a work limit and a release signal.

5.7 Establishing Pull

Flow and pull solve different problems. Flow concerns how work moves after it begins. Pull concerns what authorizes work to begin or move forward.

In a push production system, work is released according to a forecast, schedule, quota, or other upstream decision. The upstream step sends work forward whether or not the next step is ready to receive it. Because the downstream step has no mechanism for limiting what the upstream step releases, push systems tend to create excess work in process when demand, staffing, or capacity differs from the plan.

In a pull production system, by contrast, new work begins only in response to a signal from actual demand or a downstream step. That signal might be a customer order, an open appointment slot, or the withdrawal of an item from a controlled buffer. A buffer is a designated, limited place where a small amount of completed work waits for the next step. For example, a rack between washing and folding might hold at most five washed loads. When the folder takes one load from the rack, its empty space authorizes the washer to send one replacement rather than another uncontrolled batch. The downstream step takes only what it needs, and the upstream step replaces only what was taken.

The pull rule should also limit the amount of work in progress authorized at any one time. One common method uses a fixed number of kanban, or work signals, such as cards that travel with the work. If the five-load rack has five cards, all five cards are attached to loads whenever the rack is full. No additional load may begin until the folder takes a load and returns its card. This makes the work limit visible and prevents upstream activity from overwhelming downstream capacity.

Batch-and-push systems often begin with reasonable concerns. A setup may be expensive, a forecast may be the best demand information available, and a fixed batch may appear to protect the next step from interruption. The trouble begins when the release decision and the performance incentives ignore what the customer needs and what downstream work can absorb.

Now imagine that Sam, a factory manager, is rewarded with a cash bonus for meeting a monthly production quota. Unfortunately the forecasted demand simply never materializes. Demand falls short of the forecast, but the plant can still make the planned quantity. Stop and think for a minute: what would you expect Sam to do? Will he reduce production because there is no demand to satisfy, or continue production in order to hit the quota? What will the consequences to the firm be, and where do you expect those consequences would appear?

Well, since Sam is still responsible for the same production target and has a financial incentive to hit it, the most likely outcome is he simply plows ahead with production on schedule and the firm ends up with a warehouse full of stuff it can’t sell. The Chief Operations Officer asks Sam, “Why did you keep making a bunch of stuff we can’t sell?”

“I’m just doing what you explicitly told me to do,” Sam replies. “If you’re looking for someone to blame, blame yourself for getting the forecast wrong!”

The instruction and the reward still favor production even after the demand that justified the target has disappeared. People can make individually defensible decisions inside a system that rewards output while exporting delay, rework, risk, stress, and exhaustion to everyone involved.

Flow and pull change the whole operating logic. Work enters in response to actual customer demand, downstream consumption, or available capacity, and a visible work-in-process limit prevents the upstream step from releasing more merely to stay busy. Smaller transfers allow the next step to begin sooner. They also shorten the feedback loop: a defect found on the first unit can be corrected before it is repeated across a large batch.

Pull does not magically make variability disappear. A late supplier can still stop production, a storm can still close the plant, and a staffing loss can still reduce capacity. A queue of customer demand may grow outside the controlled process, and a work limit does not create the missing capacity needed to serve it. What pull does is keep the system from disguising those problems as productive activity. The shortage, blockage, or capacity gap becomes visible, which gives management a chance to address the actual constraint in real time instead of burying it under more work in process.

For now, we can state the expected benefits as hypotheses to test:

  • Shorter delivery time when work no longer waits unnecessarily for a batch.
  • Earlier detection of quality problems because feedback travels across smaller transfers.
  • Lower inventory, storage, and rework costs when the process releases only what demand and capacity authorize.
  • Less discounting and obsolescence when the firm avoids producing unsold finished goods from an inaccurate forecast.
  • More visible overload because a work-in-process limit prevents the active queue from growing without bound.

These benefits depend on the process, its constraints, and how faithfully the method is carried out. The comparison identifies a mechanism worth testing while leaving room for batches and forecasts where the process requires them.

flowchart TB
    subgraph PUSH["Forecast-driven push / batch production"]
        direction LR
        PF["Demand forecast"] --> PA["Process A<br/>Large batch"]
        PA --> PI1[("WIP inventory")]
        PI1 --> PB["Process B<br/>Large batch"]
        PB --> PI2[("WIP inventory")]
        PI2 --> PC["Final assembly"]
        PC --> PFG[("Finished-goods<br/>inventory")]
        PFG --> PCU["Customer"]

        PS["Production scheduled<br/>in advance"] -.-> PA
        PS -.-> PB
        PS -.-> PC
    end

    subgraph PULL["Lean pull production"]
        direction LR
        LA["Process A<br/>Small quantity"] --> LI1[("Small buffer")]
        LI1 --> LB["Process B<br/>Small quantity"]
        LB --> LI2[("Small buffer")]
        LI2 --> LC["Final assembly"]
        LC --> LCU["Customer"]

        LCU -. "Actual demand" .-> LC
        LC -. "Kanban: replace<br/>what was taken" .-> LB
        LB -. "Kanban: replace<br/>what was taken" .-> LA
    end

    PUSH ~~~ PULL

    classDef inventory fill:#A43232,stroke:#A43232,color:#FFFFFF;
    classDef process fill:#FFFFFF,stroke:#CDD5D5,color:#1F2933;
    classDef signal fill:#0B5D5A,stroke:#0B5D5A,color:#FFFFFF;
    classDef endpoint fill:#FFFFFF,stroke:#0B5D5A,color:#1F2933;

    class PI1,PI2,PFG inventory;
    class PA,PB,PC,LA,LB,LC process;
    class LI1,LI2 signal;
    class PF,PS,PCU,LCU endpoint;

    style PUSH fill:transparent,stroke:#8A5A00,color:#1F2933;
    style PULL fill:transparent,stroke:#0B5D5A,color:#1F2933;
Figure 5.1: Forecast-driven mass production compared with kanban-controlled pull production.

5.8 Pursue Perfection

The fifth principle does not claim that a literally perfect process is attainable. Rather, the principle simply says the current process is never final. Customer expectations change, new technology becomes available, competitors improve, and yesterday’s solution creates tomorrow’s constraints. Improvement must therefore be continuous.

Pursuing perfection sends us back through the preceding four principles. Has the customer’s definition of value changed? Does the map still describe the work as it is actually performed? Where does work now wait or return for correction? Are pull signals still aligned with demand and capacity? Each improvement changes the process, so each improvement creates a new current state to observe and question.

This does not mean trying to fix everything at once. Most improvement proceeds through many bounded experiments whose gains accumulate over time. A team identifies a problem, tests a countermeasure, studies the result, and either adopts, revises, or abandons the change. The next chapter introduces a structured cycle for doing that work.

But incremental improvement also has limits. If a process no longer delivers any meaningful value, or if its basic design cannot meet customer needs, tuning the existing steps may be the wrong response. You don’t need to worry about tuning your brakes and shocks for maximum performance if the car is up on blocks and the transmission is sitting on the pavement. The firm may need to redesign the process rather than improve it incrementally. Rebuilding a process from the ground up is known as Business Process Reengineering and Lean Six Sigma provides tools to accomplish that work as well. But those tools are out of scope at the White Belt level.

At this level, the important direction is: improve a functioning process toward a better state, but do not use continuous improvement as an excuse to preserve a process whose basic purpose or design has failed.

5.9 Five Principles, Two Pillars

The five principles tell us what direction improvement should take. The two pillars introduced in Section 4.5 constrain how we pursue that direction. Continuous improvement keeps the principles active over time; respect for people keeps improvement from becoming a pretext for deception, coercion, or exploitation.

Five Lean principles Continuous improvement Respect for people
Define value Continually test what customers truly need Respect customers by defining value from their perspective
Map the process Expose waste and improvement opportunities Involve the people who actually perform the work
Create flow Experiment to remove interruptions and delays Design work that is safe, understandable, and sustainable
Establish pull Use demand signals to improve coordination Avoid burdening people with overproduction and chaotic priorities
Pursue perfection Return to the first four after a change Develop people as capable problem-solvers rather than treating them as interchangeable labor

The practical connection between the principles and the pillars is trust. People who perform the work often know where the delays, workarounds, and recurring failures are hidden. The organization needs that knowledge to define the current state and improve it. If management uses employee knowledge against the people who provide it, future improvement efforts will lose access to the truth. Chapter 4 examined that problem in more detail; here, the point is simply that the five principles cannot be separated from the conditions under which people are asked to apply them.

This dependence on trust also helps explain why transforming a batch-and-push operation is so difficult. Lean changes more than a firm’s tools and terminology; it changes what the firm measures, authorizes, and rewards. A Fortune 500 company cannot merely announce an improvement initiative and expect the whole enterprise to become Lean three months later. Leaders must change how they respond when workers expose problems—and, as the example of Sam the factory manager showed, they may need to replace incentives that reward production no customer needs. The upshot is that an organization is not Lean merely because it uses kanban cards and moves work in small batches. Trust between staff and management and a shared commitment to delivering quality to the customer are indispensable. Kanban cannot repair a culture that punishes candor or rewards unwanted production.

5.10 Conclusion

The five principles describe the direction of Lean improvement. Begin with the outcome the customer values. Make the process visible. Improve how work moves through it. Control the release of work through signals tied to actual customer demand and capacity. Then return to the beginning and ask what should improve next.

These principles do not prescribe one ideal process for every setting. They give us a disciplined way to question the current process and judge proposed changes. The Wash n’ Fold case gives us a continuing example, and we will use this language throughout the White Belt capstone to explain why a problem matters and what better process behavior should look like. The next chapter introduces PDCA, the structured cycle we will use to put this direction into practice.

5.11 Exercises

1. Bloom:Understand Explain why the five Lean principles are presented in this order: define value, map the process, create flow, establish pull, and pursue perfection. For each transition, state why the next principle is needed.

A strong explanation follows the logic of the sequence. We define value first so that improvement has a customer-centered purpose. We then map the process because we need to see how the work currently creates—or fails to create—that value. Once the work is visible, we can improve flow by reducing waiting, interruption, rework, and unnecessary batching. After improving movement, we establish pull so that demand and downstream capacity govern when work enters the process. Finally, we pursue perfection because every change creates a new current state and customer needs and operating conditions continue to change.

2. Bloom:Understand Classify the flow and release logic in each process.

  • A bakery decides each morning to produce 200 loaves from its sales forecast. Once production begins, each loaf moves from shaping to proofing to baking with little waiting.
  • A custom-print shop begins a job only after receiving a customer order, but then holds that job until 50 similar orders accumulate for printing.

For each process, state whether it demonstrates relatively good or poor flow and whether its release is push or pull.

The bakery has relatively good flow after production begins because units move with little waiting, but its release is push because the forecast authorizes production. The print shop uses pull at the initial release because a customer order authorizes the job, but it has poor flow afterward because the job waits for a batch to accumulate. The examples show why flow and pull must be diagnosed separately.

3. Bloom:Analyze A hospital receives referrals throughout the day. Intake staff enter each referral immediately, but at 4 p.m. the system releases every accumulated referral to the scheduling queue, whether or not the scheduling team has capacity. Schedulers begin contacting patients the following morning.

Identify one flow problem and one pull-control problem. State what evidence you would collect before recommending a change.

The referrals wait after intake and again overnight, so the batch release interrupts flow and lengthens response time. At the intake boundary, an actual referral creates demand; at the scheduling boundary, however, the clock pushes the entire accumulated batch forward regardless of downstream capacity. Useful evidence would include referral arrival times, time spent waiting at each stage, scheduler capacity by time of day, queue size, time to first patient contact, and the frequency of incomplete or reworked referrals. That evidence would show whether smaller and more frequent releases could improve flow without overloading the schedulers.

4. Bloom:Analyze Apply all five Lean principles to the Wash n’ Fold case. For each principle, write one diagnostic question and identify one piece of evidence you would seek before proposing a countermeasure.

Answers will vary, but a strong response connects each principle to observable evidence:

  1. Define value: What turnaround time, accuracy, and garment care do customers expect? Examine customer interviews, complaints, repeat business, and promised service levels.
  2. Map the process: What path does an order follow from drop-off until it is staged and the customer is notified that it is ready? Observe the work and record actual steps, handoffs, queues, decisions, and rework.
  3. Create flow: Where does an order stop after processing begins? Measure queue lengths and waiting time without assuming which step is constrained.
  4. Establish pull: What authorizes new work to enter each step, and can downstream capacity absorb it? Compare release decisions with work-in-process levels and available capacity.
  5. Pursue perfection: After a change, what problem or constraint remains? Compare the new results with the baseline, then select the next bounded experiment.

5. Bloom:Apply A team has reduced the average approval time in a functioning service process from five days to two. The service now meets most customer needs, but 10 percent of requests still take more than a week. One manager declares the process fixed; another proposes replacing the entire service immediately.

Using Pursue Perfection, recommend a more disciplined next step.

The team should not treat the current gain as final, but the remaining delay does not by itself justify immediate wholesale replacement. It should study the delayed 10 percent, determine whether those requests share a cause, and test a bounded countermeasure. The team should consider fundamental redesign if the evidence shows that the process’s basic design cannot reliably deliver what customers value. Pursuing perfection means continuing to learn, not changing everything at once.

5.11.1 Journal and Reflect

Write a short paragraph about one place in your own work where one of the five Lean principles challenges or even changes how you think about that process. State which principle it is, what current behavior it makes you question, and what kind of evidence you would want next to test a change.

Imagine that a proposed flow or pull change would improve speed but might transfer more interruption, uncertainty, or physical burden to another person. What would you ask that person, and what guardrail would you include before testing the change?

5.12 Chapter Summary

  • The five Lean principles form a sequence: define customer value, map the process, create flow, establish pull, and pursue perfection.
  • A process map is a model of the actual work and must be checked against observation, records, and the knowledge of the people who perform it.
  • Flow concerns how work moves after it begins; pull concerns what authorizes work to begin or move forward.
  • Smaller batches and pull controls can reduce waiting and excess work in process, but they are directional design principles rather than absolute rules for every process.
  • Pursuing perfection means repeatedly learning and improving within the constraints of continuous improvement and respect for people; it does not mean that literal perfection is attainable.

  1. We take these principles from (Womack and Jones 1996), which names the second principle “identify the value stream.” This book substitutes map the process at White Belt level to establish the underlying observational and modeling skills before introducing fuller Value Stream Mapping practice at later belt levels.↩︎