Book Notes #46: The Lean Machine by Dantar P. Oosterwal

Title: The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development
Author: Dantar P. Oosterwal
Year: 2010
Pages: 272

Most companies say they want to develop products faster—but what if the real problem isn’t speed at all? What if the biggest bottleneck is how little we actually know when we make key decisions?

The Lean Machine tells the story of how Harley-Davidson transformed its entire approach to product development—not by pushing harder, but by learning smarter.

Through real examples and fresh thinking, the book shows how to shift from firefighting to flow, from rigid plans to systems that adapt, and from isolated teams to shared understanding.

As a result, I gave this book a rating of 8.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read The Lean Machine

Book Overview

Have you ever worked on a product or project that looked great on paper—until the last minute, when everything started to fall apart? The deadlines slip. The teams scramble. The energy turns from excitement to panic.

It’s called firefighting, and if you’ve been in product development long enough, you know exactly what it feels like.

In The Lean Machine, Dantar P. Oosterwal invites us behind the scenes of Harley-Davidson to explore why this chaos happens—and how they learned to fix it not by working harder, but by learning smarter.

Harley-Davidson, once teetering on the edge of bankruptcy, reinvented itself to become one of the most iconic brands in the world.

But this rebirth wasn’t powered by marketing alone—it was driven by radical changes in how the company developed its products.

Oosterwal, a former executive and head of product development, shares how Harley moved away from rigid, outdated processes and embraced a completely new way of working.

The result? A fourfold increase in throughput, product development time cut in half, and consistent growth of over 10% a year. Not bad for a company that once struggled just to stay alive.

At the heart of this transformation was a shift from execution to learning. Oosterwal explains that most organizations treat product development like a checklist—define the specs, design the thing, build it, test it, launch it. But this mindset ignores the reality of uncertainty.

In the real world, we don’t always know what customers want, what designs will succeed, or what tradeoffs matter most.

So instead of pretending we do, Harley leaned into that uncertainty.

They treated development as a knowledge-building process, with a focus on learning cycles, experimentation, and shared insight.

One of the most striking ideas in the book is the concept of “false positive feasibility.” It’s when everything appears to be working—each team hits their milestones, the reports are green, the charts look good—but when the pieces come together, the system fails. This isn’t about incompetence.

It’s about a flawed model that rewards local optimization and early decisions rather than collaboration and learning.

To fix it, Harley introduced “integration points,” where teams intentionally brought their work together early—not to validate success, but to uncover problems while they were still cheap to solve.

That’s just one of many real-world examples in the book that challenge how we usually think about speed, planning, and leadership.

Take the idea of cadence and flow, inspired by Toyota. Instead of constantly starting new projects and overwhelming teams, Harley adopted a rhythm—a series of fixed entry points for new work, like waves on a beach.

This steady pacing reduced chaos, helped teams stay focused, and allowed the entire system to breathe.

The book also introduces the “Oobeya”—a deceptively simple but powerful practice of visualizing work on the walls. Instead of drowning in emails and PowerPoints, teams could actually see what was happening.

They spotted problems early, aligned around shared goals, and made better decisions—not because of better data, but because they could finally make sense of it together.

What makes The Lean Machine especially compelling is how human the story feels. This isn’t a book about buzzwords or process worship. It’s about leaders sitting down together and admitting: what we’re doing isn’t working. And from there, it becomes a journey of curiosity, humility, and learning.

Through concepts like set-based design, pull events, and knowledge-based development, the book builds a new mental model for what great product development looks like—one that’s less about control, and more about clarity.

But the lessons don’t stop at product development. The ideas in this book ripple out to how we manage teams, make decisions, and even structure our days.

Do we start too much, too fast? Do we commit before we’ve learned enough? Are we creating space for insight—or just sprinting toward deadlines with blinders on?

The Lean Machine makes you reflect, not just on systems, but on mindset.

By the end of the book, it’s clear that Harley-Davidson’s turnaround wasn’t a lucky break. It was the result of deliberate changes to how people worked together, how knowledge flowed, and how leadership showed up—not as command and control, but as curious learners.

They didn’t just fix a broken process. They rebuilt the way they thought about work from the ground up.

Packed with stories, examples, and just enough frameworks to take action, The Lean Machine is part business memoir, part how-to guide, and part cultural wake-up call.

Whether you’re in manufacturing, tech, healthcare, or any field where complexity, speed, and quality collide, this book offers a path forward that feels both refreshing and real.

In the end, the big lesson is simple: the best organizations don’t just build great products.

They build great learning systems. And once you do that, everything else—speed, quality, innovation—gets a whole lot easier.

Chapter by Chapter

Chapter 1 – Working Hard

The book opens with a scene that many professionals in product development will find familiar: a manager listens to a recorded message reporting poor performance—missed deadlines, budget overruns, and cancelled projects. The suggested solution? Work harder. But the author, already stretched thin, starts to question whether effort is really the issue—or if something deeper is broken.

A Moment of Reflection

Set in the author’s office near Charles de Gaulle Airport, the narrative uses a quiet, reflective moment to highlight an important observation. Watching planes land with perfect rhythm and cadence, he wonders why something as complex as air traffic can be so predictable, while product development at his company feels chaotic and reactive. This contrast plants the seed for a bigger idea: maybe it’s not about working harder, but smarter—by improving the system, not just the effort.

The Limits of the CCPDP Process

He reflects on the company’s development process, which had recently undergone a major overhaul. The new approach, called the Concurrent Corporate Product Development Process (CCPDP), was designed by top engineers to streamline product launches and reverse a slide in competitiveness. The process was packed with over 800 specific steps, laid out across a four-year timeline, using a traditional phase-gate approach. It was methodical and structured, and the company hoped it would bring clarity and consistency.

But when a critical opportunity arises—to win back lost business in just 30 weeks—the rigid CCPDP process shows its limits. There’s no way to compress a four-year, highly structured plan into seven months. This is the author’s first wake-up call: the system they’ve created, for all its order and checklists, can’t respond to real-world demands.

A Breakthrough in Thinking

The chapter then dives into a vivid case study. A new product design has failed late-stage crash testing. With only two weeks to fix the problem or lose the customer, the author assembles a team over the weekend. What follows is a classic firefighting session—but something different happens. Instead of just tweaking designs, the team starts looking at data differently. A simple graph, plotting test angles against energy absorption, reveals a critical insight: the design fails at angles slightly outside the original range. This visualization leads them not only to a fix, but also to a deeper understanding of why the failure happened in the first place.

The irony is that the team’s breakthrough comes not from following the 863 steps in the CCPDP manual, but from stepping back, thinking critically, and collaborating to understand the problem. Yet when the author presents this work to his boss, the response is telling: he’s scolded for wasting resources on tests beyond the immediate fix. It’s a glimpse into a culture that values speed and control over learning and insight.

A Systemic Problem

By the end of the chapter, the author is confronted with the limits of the system he’s part of. Even when his team does something truly smart—understanding a failure and preventing future ones—they’re seen as going off-script. The boss just wants the product out the door. And while they do win the contract, problems re-emerge later in development, proving that the surface-level fix wasn’t enough.

This chapter lays the groundwork for the rest of the book. It’s a personal story, but it carries a powerful message: working harder doesn’t solve systemic problems. If product development is going to improve, it needs a different mindset—one that values learning, adaptability, and smarter systems, not just longer hours and more checklists.

Chapter 2 – The Harley-Davidson Environment

After the frustrations at Roaring Motors, the author shifts focus to a completely different environment: Harley-Davidson. What he finds there is more than a change in company—it’s a change in philosophy, culture, and approach to work.

Reflections on Old Beliefs

He begins by reflecting on the beliefs he grew up with: that loyalty, hard work, and commitment to a company would lead to success and security. That mindset had defined his career at Roaring Motors. But over time, it became clear that despite the dedication of its people, Roaring Motors was struggling. The products weren’t competitive anymore, customers were leaving, and the company’s leadership remained stuck in industrial-era thinking. The organization was trying to survive a new reality by holding onto old beliefs, and it wasn’t working.

A Contrast in Organizational Culture

The real turning point for the author came when he began to see how deeply his own environment had shaped his assumptions. At Roaring Motors, hierarchy, control, and strict processes ruled. Promotions came with office furniture upgrades. Authority was tied to title, and innovation often got crushed under layers of rules and routines. Even product development followed rigid structures, disconnected from real customer needs and rapid market shifts.

In contrast, Harley-Davidson felt alive. From the moment he arrived, he could sense it was different—not just in how it looked or how people dressed, but in how people thought and behaved. The energy was palpable. People were engaged, passionate, and deeply connected to the brand and its mission. Leadership wasn’t distant—it was involved. Executives didn’t just sit in meetings; they rode motorcycles, talked to customers, and immersed themselves in the culture.

The Power of Purpose

The contrast between the two companies was more than cosmetic. At Roaring Motors, decisions were often top-down and slow. At Harley-Davidson, there was a sense of shared ownership. Employees weren’t just doing jobs—they were contributing to something they believed in. While Roaring Motors clung to hierarchy, Harley valued collaboration. While one demanded conformity, the other encouraged people to be themselves. The cultural difference was massive, and it had a direct impact on how work got done.

What stood out most was Harley-Davidson’s focus on purpose. Their slogan, “We fulfill dreams,” wasn’t just a marketing phrase—it shaped how people thought about their work. Instead of simply making motorcycles, they were creating experiences and lifestyles. That purpose united people across roles and levels. It created alignment in ways that rigid systems and top-down control at Roaring Motors never could.

The Role of Environment in Shaping Success

This chapter isn’t just about company culture—it’s about mindset. The author begins to see that environment plays a huge role in shaping what people believe is possible. At Roaring Motors, he had internalized the idea that hard work and following the system were the only paths to success. But at Harley-Davidson, he starts to realize that success can also come from empowering people, nurturing passion, and encouraging learning.

It’s a quiet but powerful shift. And it sets the stage for what’s to come in the book. If the problems at Roaring Motors stemmed from a culture of control and outdated thinking, the solution might lie in what he’s starting to experience at Harley-Davidson: a culture of purpose, learning, and connection.

Chapter 3 – Harley-Davidson’s Product Development Leadership Learning Team

This chapter introduces the beginnings of a powerful transformation at Harley-Davidson—one that didn’t start with tools or systems, but with people sitting down together to learn. It’s here that the Product Development Leadership Learning Team, or PDL²T, takes shape. But the story isn’t about a formal initiative launched from the top. Instead, it begins with a question: how can we do better?

The Need for Change

Harley-Davidson had reached a point where its traditional ways of managing product development—ways that had worked in the past—were no longer good enough. The company wasn’t failing, but the cracks were showing. Projects took too long, resources were stretched thin, and firefighting had become the norm. There was a sense that everyone was doing their best, but the outcomes weren’t matching the effort.

A New Approach: Learning Together

The author paints a picture of a group of leaders who came together not because they were told to, but because they saw the need to step back and reflect. This was the start of the PDL²T. It wasn’t a typical committee. There were no mandates, no urgent deadlines—just a shared desire to learn and improve. They didn’t begin by trying to fix specific problems. Instead, they focused on understanding how the whole system worked—or didn’t.

Product Development as a System

A key idea in this chapter is that product development isn’t just a process—it’s a system of people, decisions, interactions, and assumptions. Most organizations look at development as a sequence of steps to be managed. But the PDL²T started to see it differently. They wanted to understand the patterns beneath the chaos, the deeper reasons why projects struggled, even with good people and clear intentions.

The Power of Learning and Reflection

This shift in thinking was influenced by several outside sources. The team connected with thought leaders in organizational learning, systems thinking, and lean product development. People like Peter Senge and Allen Ward became important guides. The group wasn’t just looking for quick wins—they were going deep into concepts that challenged the very foundations of how development was understood.

What’s striking is how much time the PDL²T spent learning together. They didn’t rush to implement solutions. They studied. They talked. They questioned their own assumptions. In a corporate world that often rewards speed and certainty, this was unusual—and powerful. It created a safe space for reflection and real change.

Transformation Starts with Awareness

One of the biggest lessons from this chapter is that transformation doesn’t start with action. It starts with awareness. The leaders at Harley-Davidson began to see their development struggles not as isolated issues, but as symptoms of deeper system dynamics. And they realized that fixing those problems would require more than tools and processes. It would require new ways of thinking, new conversations, and a commitment to learning.

This chapter marks the beginning of that journey. It’s a quiet start, but one that carries big implications. Instead of forcing change from the top or reacting to crisis, Harley-Davidson began its transformation by creating space for thoughtful, shared learning among its leaders. That’s the foundation the rest of the book builds on—and it’s what makes this story so different from the usual corporate change tale.

Chapter 4 – The PDL2T

This chapter goes deeper into the work of the Product Development Leadership Learning Team—now officially called the PDL2T—and how their quiet, intentional learning began to ripple across Harley-Davidson’s product development system.

A Different Approach to Change

At its core, the PDL2T wasn’t created to implement change. It existed to understand. The group was made up of experienced leaders who didn’t come together to solve a crisis, but to explore what was really happening beneath the surface of their organization. They recognized that something felt off: product development cycles were dragging, teams were constantly fighting fires, and success seemed to depend more on heroics than on a well-functioning system.

Rather than diving straight into new tools or restructuring teams, the PDL2T committed to a deeper approach. They started with the assumption that most problems in product development are not caused by individual people failing—they’re caused by the system. And systems, by nature, are made up of patterns. So if they could learn to see those patterns, they might be able to influence the system in smarter ways.

The Focus on Learning

The team’s meetings weren’t tactical or filled with project updates. They were grounded in shared learning. They studied systems thinking, they examined the nature of knowledge creation, and they explored what makes organizations truly effective at learning. This wasn’t just academic—these concepts were deeply connected to their real struggles at Harley.

One of the most valuable tools they used came from Donella Meadows’ framework of leverage points in systems. It showed that most organizational change efforts focus on the least effective levers—things like tweaking processes or adding more documentation. But the real power lies in shifting mindsets, goals, and system structures. That’s where the PDL2T chose to focus.

Managing Complexity, Not Eliminating It

Another important insight was that complexity in product development can’t be eliminated—it has to be managed. The team began to see that traditional methods, like phase-gate systems and rigid timelines, actually made it harder to deal with uncertainty. Instead of helping, these methods created a false sense of control and often pushed teams into late-stage crisis mode. What the PDL2T wanted to understand was how to create a development system that could absorb complexity and still move forward smoothly.

Humility and Open Learning

The chapter also highlights something subtle but important: the role of humility. The leaders in the PDL2T didn’t claim to have all the answers. They were open to learning, to being challenged, and to questioning long-held beliefs. This mindset—uncommon in many leadership teams—allowed them to explore real change, not just surface-level improvements.

The Seeds of Cultural Transformation

Over time, the PDL2T became more than just a discussion group. It turned into a force for cultural transformation. By creating a space where learning was valued, and where leaders could be vulnerable and curious, they began to shift the tone across the broader organization. People started asking better questions. They began seeing the system, not just the symptoms.

This chapter reminds us that meaningful change doesn’t come from quick fixes or top-down mandates. It comes from committed people who are willing to pause, learn, and think differently—especially when they’re in positions of influence. The PDL2T didn’t fix Harley-Davidson’s problems overnight. But they planted the seeds for a different kind of product development—one based on knowledge, systems thinking, and true leadership learning.

Chapter 5 – Firefighting and the Tipping Point

This chapter zooms in on a frustrating yet all-too-familiar pattern in product development: firefighting. At Harley-Davidson, as in many organizations, firefighting had become a way of life. Teams were constantly reacting to problems—rushing to meet deadlines, fixing late-stage issues, and putting out one fire after another. But what’s striking is how normal this had started to feel. People were working incredibly hard, yet still falling behind. And few questioned why this had become the norm.

The Cycle of Firefighting

The chapter opens with a clear illustration: during the product development process, many projects looked fine early on. The phase reviews showed green lights, plans were progressing, and everything seemed on track. But as the launch date got closer, things would fall apart—crashes in testing, redesigns, missed integration points. Suddenly, teams were scrambling. This was the firefighting zone.

A Systemic Problem

The author introduces a critical insight here: this cycle wasn’t caused by laziness, incompetence, or poor planning. It was systemic. Projects followed a pattern of looking successful early on but hiding real risks beneath the surface. These hidden risks would then explode late in the game, creating the chaos everyone dreaded. And the standard response? Push harder, work longer, throw more resources at the problem.

But this reaction only reinforced the cycle. Instead of fixing the system, firefighting became the system. In fact, in many cases, the people who saved the day—those who pulled off heroics in the eleventh hour—were celebrated. This created a culture where being in crisis was almost seen as a badge of honor. Ironically, the more fires you fought, the more valuable you appeared.

The Unsustainable System

The author explains that this kind of system is deeply unsustainable. It drains energy, demoralizes teams, and leads to mediocre outcomes. Worse, it hides the true health of the development process. Teams might deliver on time by cutting corners or skipping learning steps, but that only pushes problems downstream—into manufacturing, quality, or customer experience.

The Tipping Point

The tipping point came when Harley-Davidson began to see just how widespread this pattern was. A study showed that the company had more than twice the number of products in development as it could realistically support. This overload meant that every team was stretched thin, and no one had enough time to work strategically or improve the system. The result was chronic stress and underperformance, even from the best teams.

This realization marked a turning point. The PDL2T began to understand that if they wanted better outcomes, they couldn’t just work harder or manage more aggressively. They had to break the cycle of firefighting. That meant stepping back, rethinking how projects were planned and resourced, and making space for learning earlier in the process—before the fires started.

A Wake-Up Call

This chapter is a wake-up call. It shows how organizations can fall into reactive habits that feel productive but are actually damaging. And it challenges the myth that last-minute heroics are a sign of strength. Instead, the real strength lies in designing a system that prevents fires in the first place—through better learning, more realistic planning, and a culture that values prevention over panic.

Chapter 6 – Cadence and Flow, Bins and Swirl

After exposing the exhausting cycle of firefighting, this chapter shifts gears and explores what it might look like to work with rhythm, focus, and flow. It starts with a simple but powerful idea: cadence. Just like a metronome sets the pace in music, cadence can guide how work progresses in product development. But for that to happen, the system needs clarity and control—not in a rigid, top-down way, but in how work is introduced and managed.

The Overloaded Pipeline

At Harley-Davidson, there was a growing realization that the product development pipeline was overloaded. The company had far more projects in motion than it could reasonably handle, which meant people were constantly switching gears, juggling priorities, and losing momentum. This wasn’t just inefficient—it was draining. And most importantly, it kept the organization in a state of swirl.

The Swirl Problem

Swirl is the term used to describe the chaotic, unfocused activity that results when too many projects compete for the same resources. It’s what happens when people are pulled in multiple directions, unable to give anything their full attention. The result is a lot of motion, but very little progress. Sound familiar?

Introducing Bins

To fight this, Harley-Davidson introduced a concept called bins. Bins were essentially time-bound slots—structured points in the year when new projects could be initiated. Instead of launching projects whenever a business case was ready or a VP pushed for it, the company created specific entry points. This gave teams breathing room and reduced the chaos of constantly shifting priorities.

The logic was simple: if you know when projects will start, and you limit how many can be in process at once, you can align teams better and focus resources. It creates cadence. Projects move forward in a predictable rhythm, and people can plan more effectively. The swirl calms down.

Respecting Flow

But the chapter makes it clear that cadence isn’t just about timing—it’s about respecting flow. Flow is what happens when work moves steadily through the system without bottlenecks or distractions. When teams aren’t overburdened, and when they can concentrate on solving real problems, flow becomes possible. That’s when innovation happens.

Lean Thinking and Performance

This chapter draws inspiration from lean manufacturing principles, especially those used in Toyota’s production system. In factories, flow is everything. But applying this thinking to product development—where uncertainty and learning are central—is more complex. Still, the underlying lesson holds: too much work-in-progress kills flow, and without flow, there is no sustainable performance.

Shifting Mindsets

The chapter ends by reinforcing a key shift in mindset. Most organizations focus on individual project success. But Harley-Davidson started looking at the health of the entire development system. That meant sometimes saying no to new projects, even promising ones, if it would overload the pipeline. It meant creating a system that could learn and adapt—one that wasn’t constantly starting over.

This is where the transformation becomes visible. The company began to recognize that speed doesn’t come from rushing. It comes from rhythm. It comes from working on fewer things with more focus. And it comes from building a system where teams can do great work without being trapped in constant swirl.

Chapter 7 – Supply and Demand

This chapter goes right to the heart of one of the biggest disconnects in product development: the imbalance between supply and demand. In manufacturing, the idea of aligning supply with demand is well understood. You don’t build more cars than customers want, and you don’t promise delivery if the factory can’t produce. But in product development, this logic often gets thrown out the window.

Overloaded Systems

At Harley-Davidson, the product development system had been running beyond capacity. The demand for new projects—often driven by well-intentioned business units pushing for market opportunities—far exceeded what the development organization could realistically handle. The result was overloaded teams, missed deadlines, and, as seen earlier, a culture of constant firefighting.

The Manufacturing Parallel

The author draws a compelling parallel to manufacturing. Imagine if a factory accepted unlimited orders without considering whether it had the machines, materials, or people to fulfill them. It would be chaos. Yet in product development, this kind of overcommitment was business as usual.

A New Approach to Capacity

To bring sanity back to the system, Harley-Davidson began applying a more disciplined approach: measuring and managing development capacity just like production capacity. This meant getting real about how many projects the organization could handle at one time—and, more importantly, being willing to say “not now” to work that would exceed that limit.

The Shift in Decision-Making

This was a big shift. In many organizations, new projects get greenlit for all sorts of reasons—competitive pressure, executive sponsorship, emotional excitement. But rarely is there an honest conversation about whether the organization has the capacity to execute them well. By introducing clearer visibility into both supply (developer capacity) and demand (requested projects), Harley-Davidson created a foundation for more strategic decision-making.

Transparency and Insight

One of the practical tools they used was a simple visual representation of demand versus capacity. When this was shown to executives, the reaction was immediate and powerful. For the first time, it was crystal clear that the system was being pushed beyond its limits—not because of incompetence or laziness, but because of too much demand relative to available supply.

Aligning Work with Capacity

This kind of transparency shifted the conversation. Instead of blaming teams for late deliveries, leaders could now see the upstream decisions that were overwhelming the system. And with this insight, they could begin making better choices—not just about which projects to do, but when to do them.

The Key Message

The key message in this chapter is that product development is not immune to the laws of supply and demand. If you want consistent delivery, predictable outcomes, and a culture of learning and innovation, you have to match what the system is capable of doing with what it’s being asked to do. When that balance is off, quality drops, timelines stretch, and people burn out.

Seeing the System Clearly

This chapter reinforces a recurring theme: working smarter starts with seeing the system clearly. Once leaders understood how demand was overwhelming the pipeline, they could finally begin to fix it—not by working harder, but by aligning the flow of work with the organization’s true capacity.

Chapter 8 – A Left Turn: Implementing Lean Principles in Product Development

This chapter marks a turning point—not just for Harley-Davidson, but for the way the organization understood product development itself. After uncovering the underlying issues of overload, swirl, and misaligned priorities, the company didn’t just tweak the existing system. It made what the author calls a “left turn”—a deliberate shift away from traditional approaches and toward lean thinking, applied not to manufacturing, but to product development.

A Shift in Mindset

The core idea here is that most companies try to control product development through planning and process. They build detailed roadmaps, layer on governance, and assume that with enough discipline, they can manage complexity. But Harley-Davidson began to see that development isn’t just about control—it’s about learning. It’s a fundamentally different kind of work than manufacturing. While production aims for repeatability and efficiency, product development deals with uncertainty and discovery.

Reinterpreting Lean for Product Development

The PDL2T recognized that applying lean principles to product development couldn’t be a copy-paste job from the factory floor. Instead, they needed to interpret those principles in a new way. For example, lean manufacturing focuses on reducing waste and optimizing flow. In development, this translates to minimizing rework, improving knowledge transfer, and avoiding decisions based on incomplete or premature information.

Influence of Allen Ward

A major influence at this stage was the work of Allen Ward, whose insights into lean product development—particularly from his study of Toyota—reshaped the team’s thinking. Ward emphasized the idea that traditional development systems are too linear. They push decisions early, lock in designs before learning is complete, and rely on phase-gate checkpoints that often give a false sense of progress.

Instead of clinging to those old models, Harley-Davidson began experimenting with new approaches. They tested smaller batch sizes of work, delayed decisions until teams had gathered more knowledge, and focused more on learning cycles than fixed timelines. These weren’t huge organizational changes—they were thoughtful shifts designed to reduce risk and improve flow.

The Cultural Barrier

This chapter also highlights a key cultural barrier: the belief that acting quickly is always better. In many organizations, making decisions fast—even without complete information—is seen as bold and decisive. But the Harley team started to question that assumption. What if waiting to decide, until you’ve truly learned, actually creates better outcomes? That kind of thinking went against the grain, but it began to take hold.

Rethinking the System

The left turn described here isn’t just about tools or processes—it’s about mindset. It’s about shifting from a control-based approach to one that respects complexity, values learning, and accepts that not everything can be predicted or forced into a schedule. That’s a big leap for most companies, especially those used to rigid planning and top-down management.

In the end, this chapter shows that real change doesn’t come from fixing broken pieces of a system—it comes from stepping back and rethinking the system entirely. Harley-Davidson wasn’t trying to optimize the old way of working. They were charting a new path, rooted in lean principles but adapted for the messy, unpredictable reality of product development. And that’s what made all the difference.

Chapter 9 – The Product Development Limit Curve

This chapter introduces a concept that fundamentally changes how Harley-Davidson—and any organization—can understand its product development capacity: the product development limit curve. While earlier chapters explored the overload and chaos in the system, this chapter gets more technical. It gives a way to visualize and measure the limits of what the system can actually do.

Understanding System Limits

The idea is borrowed from physics, where systems have limits—like how fast a car can go before it loses traction. Similarly, product development systems have a natural limit to how much work they can handle before performance breaks down. But unlike in physics, most companies don’t know what that limit is. They just keep piling on more projects, assuming that with enough pressure or motivation, teams will deliver.

Mapping the True Capacity

At Harley-Davidson, the team wanted to move away from this guessing game. So they started looking for a way to map their system’s true capacity. They began plotting a curve—tracking the number of projects in the system against how quickly those projects moved through it. And what they saw was eye-opening.

Up to a certain point, as you add more projects, the system can handle them. Things flow reasonably well. But past a certain threshold, adding more projects causes everything to slow down. Delivery times stretch out, delays pile up, and productivity crashes. This is the “limit curve”—a point beyond which the system simply can’t cope.

The Hidden Risks of Overload

One of the most important lessons here is that overloading the system doesn’t just reduce efficiency—it actually increases risk. Teams rush decisions, skip learning cycles, and make compromises that show up later as defects, delays, or rework. And the kicker is: most companies only realize they’ve crossed the line when it’s too late.

Smarter Questions, Smarter Decisions

With this new understanding, Harley-Davidson began asking smarter questions. Instead of “How many projects can we launch this year?” they asked, “How many projects can we complete successfully, without overloading the system?” That’s a different kind of thinking—less reactive, more strategic.

Shifting the Conversation

The chapter also shows how visualizing the limit curve changed the conversation inside the company. Leaders could see, in simple terms, that their system had a breaking point. This made it easier to justify saying no to new projects, or at least deferring them. It wasn’t about lack of ambition—it was about respecting the limits of a complex system.

Clarity and Alignment

The product development limit curve became a tool for alignment. It helped leaders, planners, and development teams speak the same language. Instead of debating opinions or reacting to pressure, they could use real data to guide decisions. And that data helped the organization prioritize—not just what to do, but when to do it.

Clarity is Power

This chapter reinforces one of the book’s key themes: clarity is power. When teams and leaders can see how the system behaves, they can make better choices. The limit curve doesn’t solve all problems, but it creates a shared understanding—and that’s the first step toward building a healthier, more sustainable development process.

Chapter 10 – Integration Points and False Positive Feasibility

The author explains that one of the most dangerous assumptions in product development is that if individual parts are progressing well, the whole system must be on track. This chapter challenges that idea by focusing on a subtle but powerful failure mode: false positive feasibility. It’s when everything appears to be working fine—until the pieces come together and suddenly, they don’t.

The Issue with Component-Based Progress

At the heart of the issue is how companies structure their development work. Projects are often broken into components, and those components are handed off to different teams. Each team makes progress in isolation, checking off milestones and hitting internal deadlines. But what no one sees—until it’s too late—is whether those parts will actually work together.

The Danger of Phase-Gate Models

The author argues that traditional phase-gate models contribute to this problem. They create a false sense of security by using reviews and checklists that focus on task completion, not system integration. So a product can look like it’s moving smoothly through development, even as serious misalignments are brewing under the surface.

The Project That Seemed Fine

One of the most interesting parts of this chapter is how the author describes a project that seemed perfectly on track. All the individual functions—engineering, design, testing—had met their goals. But once the product reached final integration, nothing worked as expected. The teams had each optimized their own piece, but they hadn’t learned enough about how their decisions would interact. The failure wasn’t technical—it was systemic.

A Shift in Thinking: Integration as a Learning Opportunity

Instead of relying on sequential handoffs and delayed integration, the author suggests a different approach: using integration points as learning opportunities. These are planned moments where the system comes together—not just to prove that it works, but to uncover what still needs to be learned. The goal isn’t to validate a perfect design. It’s to expose uncertainty early and reduce risk.

Testing as Discovery

This idea challenges how many organizations think about testing. In traditional models, testing is about verification—proving that something is complete. But in this lean approach, testing is about discovery. It’s a way to learn what you didn’t know you didn’t know. And the earlier you do that, the less expensive and disruptive it is to fix.

The Importance of Early Alignment

A big takeaway from this chapter is that early alignment and real integration are essential. Without them, teams end up making decisions in isolation, which can lead to delays, rework, and failed launches down the road. The author makes a strong case that if we want to improve product development, we need to stop treating integration as a final step—and start treating it as a source of learning from the very beginning.

Rethinking the Development Process

In short, this chapter lays the groundwork for more adaptive and resilient development systems. It shows that the problem isn’t usually the people or the parts—it’s how and when we bring them together. And it reminds us that a smooth-looking process isn’t always a healthy one. Sometimes, the warning signs are hiding in plain sight.

Chapter 11 – Learning Cycles

The author explains that most traditional product development systems are built around the idea of execution—following a plan, meeting deadlines, and delivering results. But in complex, uncertain environments, that mindset doesn’t always serve us well. This chapter shifts the conversation by introducing a different foundation: learning cycles.

Product Development as Discovery

At its core, the chapter argues that product development should be treated as a process of discovery, not just delivery. Especially in the early stages, the goal isn’t to check boxes—it’s to figure things out. That means testing assumptions, exploring options, and learning what works before locking in decisions. But in many organizations, learning is seen as a luxury—something that slows things down or gets pushed to the side when timelines get tight.

Execution vs. Learning Cycles

One of the most interesting parts of this chapter is how the author breaks down the difference between execution cycles and learning cycles. Execution cycles are all about getting things done. Learning cycles, on the other hand, are about reducing uncertainty. They don’t follow a fixed schedule—they follow the pace of understanding. And when you skip learning or compress it into unrealistic timelines, you don’t eliminate risk—you just delay it.

Building Space for Learning

The author describes how, at Harley-Davidson, development teams began to structure their work differently. Instead of racing through early phases just to hit a gate review, they built in space for focused learning cycles. This meant running simulations, building early prototypes, and conducting tests specifically designed to answer critical questions. The goal wasn’t to prove they were right—it was to uncover what they didn’t know.

The Illusion of Speed

This approach challenged the conventional view of productivity. In most organizations, success is measured by how quickly teams move from concept to production. But the author makes the case that this kind of speed is often deceptive. When you rush through the unknowns, you’re just pushing problems downstream. True speed comes from learning early, so you don’t have to redo things later.

Planning for Learning

Another key idea in this chapter is that learning isn’t accidental—it has to be planned. Teams need to define what they’re trying to learn, how they’ll learn it, and how they’ll act on that knowledge. It’s a more intentional and disciplined process than most people realize. And it requires leaders to reward curiosity and reflection, not just quick wins.

Investing in Learning for Long-Term Gains

A big takeaway from this chapter is that high-performing development systems don’t just execute well—they learn well. They invest time up front to reduce risk later. They ask better questions, explore more options, and make decisions based on evidence, not assumptions. And over time, this creates not only better products, but more resilient teams.

Reframing Product Development

In short, this chapter reframes product development as a knowledge problem, not just a scheduling problem. It challenges the belief that faster is always better, and makes a strong case for building systems that value learning just as much as delivery. Because in environments filled with uncertainty, the best competitive advantage isn’t how fast you go—it’s how quickly you learn.

Chapter 12 – Set-Based Design

The author explains that one of the most limiting habits in traditional product development is the rush to pick a solution early. Most teams are pressured to decide quickly, lock in a design, and move forward with execution—even when there’s still a lot of uncertainty. This chapter introduces a very different approach: set-based design.

Exploring Multiple Options

Instead of selecting one path and hoping it works, set-based design encourages teams to explore multiple options in parallel. The idea is to keep several alternatives open for as long as possible—testing, learning, and gradually narrowing the field based on real data. It’s not about indecision or delay. It’s about being deliberate, curious, and disciplined in how decisions are made.

Point-Based vs. Set-Based Design

One of the most interesting parts of this chapter is how the author contrasts set-based design with the more common “point-based” approach. In point-based design, teams choose a single concept early and build everything around it. If that concept turns out to be flawed or incomplete, it often leads to costly rework. In contrast, set-based design acknowledges that we don’t know everything up front—and that the smartest path is to learn our way to the best decision.

The Uncomfortable Shift

This mindset shift can be uncomfortable, especially for organizations used to fast decisions and tight schedules. But the author argues that set-based design doesn’t slow things down—it actually speeds things up in the long run. By front-loading the learning and exploring options systematically, teams avoid the big surprises that often show up late in the process.

Real Results at Harley-Davidson

At Harley-Davidson, this approach started showing real results. Teams began defining critical design parameters and then exploring a range of feasible options, instead of forcing premature alignment. They created boundaries within which innovation could happen—focusing not just on what would work, but why. As they gained more knowledge, they were able to eliminate less promising options and converge on a solution with far more confidence.

Purposeful Exploration

A key point in this chapter is that set-based design isn’t about endless exploration. It’s structured, purposeful, and guided by learning. The goal is to make decisions when they’re ready to be made—not before, and not too late. This creates a more stable development process, with fewer reversals and less firefighting.

Encouraging Collaboration

The author also notes that this approach leads to better collaboration. Instead of teams competing over whose idea will win, they become partners in learning. They share data, challenge assumptions, and collectively work toward the best outcome. That cultural shift—from defending ideas to exploring them—is one of the most powerful parts of the transformation.

Making Smarter Decisions

A big takeaway from this chapter is that choosing later isn’t the same as delaying. It’s about making smarter decisions by embracing uncertainty and designing systems that help teams learn quickly. This challenges the traditional notion that good development is about having the answers early. Instead, it suggests that good development is about asking the right questions—and being willing to explore before committing.

A Resilient Way Forward

In short, this chapter shows that if we want better outcomes, we need to let go of the need to be “right” from the start. Set-based design offers a more resilient and knowledge-driven way forward—one that respects complexity, encourages collaboration, and leads to stronger, more thoughtful products.

Chapter 13 – Leadership Learning and Pull Events

The author explains that real change in product development doesn’t come just from tools or processes—it comes from how leaders think and behave. This chapter dives into the idea that if you want to shift a development culture, leadership must go first. And not just in giving approval or writing memos, but by engaging in the hard, reflective work of learning.

Leadership as the Starting Point

At Harley-Davidson, this leadership learning became a deliberate strategy. The Product Development Leadership Learning Team (PDL2T) realized that if they wanted to introduce lean principles into the organization in a lasting way, they had to start by changing how they themselves saw the system. That’s where pull events came in.

What Are Pull Events?

Pull events are focused, intentional learning experiences designed to help leaders step into the world of product development from a new perspective. The author describes them as structured opportunities to dig into real problems, challenge assumptions, and explore lean principles in action—not in theory, but in the messy, real-world context of Harley’s own work.

Deep, Shared Reflection

One of the most interesting parts of the chapter is how these pull events created space for deep, shared reflection. Instead of being passive recipients of training or change directives, leaders became students of the system. They asked hard questions, revisited long-held beliefs, and started to see the invisible forces—like overloaded pipelines, premature decisions, and false certainty—that were holding the organization back.

The Importance of Leadership Learning

The author argues that this kind of leadership learning is essential. Without it, any attempt to improve development will eventually hit a wall. Leaders set the tone for how teams behave. If they continue to reward speed over learning, or firefighting over flow, no amount of lean training will fix the system. But if they model curiosity, patience, and respect for knowledge, the culture begins to shift.

Voluntary Participation and Organic Change

Another key point in this chapter is that pull events are voluntary. No one is forced to attend. The idea is to attract leaders who are ready to learn—who are curious and open to change. And over time, as these leaders begin to think differently, their influence spreads. They start asking better questions in meetings, challenging old assumptions, and supporting teams in new ways.

A Different Approach to Change Management

This approach flips the script on traditional change management. Instead of pushing change onto people, it pulls in those who are ready—and builds momentum from there. It’s slower, but more authentic. And it creates a foundation of shared understanding that can support deeper, more sustainable transformation.

Leadership Development as System Change

A big takeaway from this chapter is that leadership development isn’t just about personal growth—it’s about system change. When leaders learn to see the system, they stop blaming individuals and start improving conditions. They shift from managing people to shaping environments. And that, the author argues, is where real improvement begins.

Cultural Transformation Starts at the Top

In short, this chapter reinforces the idea that cultural transformation starts at the top—not with control or pressure, but with learning. When leaders are willing to examine how their own thinking contributes to the problems they see, they can begin to create the kind of organization where lean product development can truly thrive.

Chapter 14 – Quickening Product Development

The author explains that most companies want to speed up product development—but they often go about it the wrong way. They cut corners, add more meetings, or push teams to move faster without changing the underlying system. This chapter shows a very different path: accelerating development by improving how knowledge is created and used.

Reframing Speed

One of the most interesting parts of this chapter is how it reframes the idea of speed. Traditional thinking says that if we want to move faster, we need to work harder or eliminate steps. But the author argues that what really slows development down isn’t effort—it’s rework, late-stage surprises, and poor decisions made too early. So instead of rushing, the goal should be to learn faster and smarter.

Focusing on Flow and Knowledge

At Harley-Davidson, the teams began applying this idea by focusing on flow. They mapped how knowledge moved through their development system—not just deliverables, but understanding. They looked at where decisions were made prematurely, where handoffs caused confusion, and where teams were forced to redo work because the system didn’t allow for proper learning upfront.

Reducing Friction, Not Compressing Timelines

The key insight was that speed doesn’t come from compressing the timeline—it comes from reducing friction. When teams have clarity, shared understanding, and the ability to make informed decisions, things move naturally and efficiently. There’s less swirl, less waiting, and fewer painful resets.

Better Alignment at Integration Points

One of the strategies they used was better alignment at integration points. Instead of letting teams operate in isolation and then discovering conflicts late, they created moments where cross-functional collaboration happened early and often. This helped catch potential problems while they were still small—and more importantly, before they were expensive.

The Importance of Pacing

Another important idea in this chapter is pacing. The author introduces the concept of setting a development rhythm that matches the organization’s true capacity. Instead of overloading the system with too many parallel efforts, they chose fewer, more focused initiatives that could flow through smoothly. That didn’t just improve delivery—it improved quality, morale, and predictability.

Cultural Change in How Success Is Measured

This shift in pacing required a cultural change. In many organizations, success is tied to how much you’re doing—how many projects you’ve launched or how many balls you’re juggling. But Harley-Davidson began to reward clarity and focus instead. They asked: Are we learning? Are we making decisions based on knowledge, not guesses? Are we moving with purpose?

The Real Path to Speed

A big takeaway from this chapter is that quickening product development isn’t about urgency—it’s about design. When the system is built to support learning, collaboration, and flow, teams don’t have to be pushed. They accelerate naturally. And that’s a much more sustainable way to improve speed.

Smarter Systems, Not Shorter Timelines

In short, this chapter challenges the instinct to push harder and instead shows the power of removing the things that slow us down. The path to faster development isn’t shorter timelines—it’s smarter systems. And that requires a shift in how we define progress, success, and the role of leadership in enabling both.

Chapter 15 – Oobeya

The author introduces a powerful but simple concept borrowed from Toyota: the Oobeya. Literally meaning “big room” in Japanese, Oobeya isn’t just a physical space—it’s a mindset. It represents a way of working that brings people together, aligns efforts, and makes the invisible visible. In this chapter, Harley-Davidson begins to use the Oobeya approach to strengthen communication, improve decision-making, and reduce delays in product development.

The Traditional Approach vs. Oobeya

One of the most interesting parts of the chapter is how the author describes the contrast between traditional communication methods and what happens in an Oobeya. In most companies, information is buried in slides, emails, and spreadsheets. People spend time preparing reports instead of solving problems. Meetings are often disconnected from real work. But in the Oobeya, the work is on the walls—literally. Teams visualize the status of projects, current problems, key milestones, and learning cycles all in one place.

The Power of Visibility

The power of this approach is in what it reveals. Instead of relying on filtered updates or abstract dashboards, the Oobeya allows everyone—engineers, leaders, cross-functional partners—to see what’s really happening in real time. Issues can be spotted early. Conversations become more focused. And alignment improves because the entire team is looking at the same truth.

Oobeya as a Learning Space

The author explains that the Oobeya isn’t a command center—it’s a learning space. It encourages collaboration, not control. People don’t come in to be told what to do. They come in to share insights, identify roadblocks, and make decisions based on shared understanding. That’s a big shift from how most teams operate.

Implementing Oobeya at Harley-Davidson

At Harley-Davidson, implementing Oobeya started small. Teams created dedicated spaces with whiteboards, charts, and sticky notes showing the flow of work. At first, it felt uncomfortable—especially for leaders used to relying on reports. But over time, the benefits became clear. Teams started solving problems faster. Cross-functional coordination improved. And trust grew because people were no longer operating in silos.

Shifting Leadership Roles

What’s especially compelling is how the Oobeya changed the role of leadership. Instead of reviewing performance from a distance, leaders became active participants in the work. They could see issues as they emerged, support decisions with better context, and coach teams based on what was actually happening—not just what was being reported.

Visibility Drives Alignment

A big takeaway from this chapter is that visibility drives alignment. When teams can see together, they can think together. And when they think together, they make better decisions. The Oobeya isn’t about technology or tools—it’s about creating an environment where learning and action happen side by side.

Clarity in Complexity

In short, this chapter shows that communication isn’t just about talking—it’s about seeing. The Oobeya brings clarity to complexity, helping teams navigate uncertainty and work more effectively. It’s a small change in setup with a huge impact on culture, flow, and results.

Chapter 16 – Knowledge-Based Product Development

The author brings everything together in this final chapter by introducing the concept of knowledge-based product development. It’s not a new process or a set of tools—it’s a different way of thinking about how work gets done. Throughout the book, the message has been clear: what slows development down isn’t just complexity or resource constraints—it’s the lack of usable knowledge at the right time. This final chapter reframes product development as a knowledge creation system.

The Task-Based Mindset vs. Knowledge-Based Development

The traditional mindset sees development as a series of tasks: design, build, test, deliver. But the author argues that this task-based view misses the most important element—learning. When teams don’t know enough early on, they make guesses. Those guesses often lead to rework, delays, and expensive failures. So if we want better outcomes, we need to focus less on doing and more on knowing.

Intentional Knowledge Creation

One of the most important insights in this chapter is that knowledge must be intentionally created and made accessible. It’s not enough for individuals to have insights buried in their heads or in scattered files. Knowledge needs to be shared, structured, and used to guide decisions. That requires discipline, not just inspiration.

Shifting Focus at Harley-Davidson

The author describes how Harley-Davidson began making this shift. Teams stopped rushing into design decisions and instead focused on defining what they needed to learn first. They used set-based design, Oobeya rooms, and pull-based planning not just as lean techniques—but as ways to accelerate learning. They asked better questions, shared discoveries earlier, and captured lessons in ways that could be reused across projects.

Data vs. Knowledge

One of the most compelling parts of this chapter is the contrast between information and knowledge. Most organizations are drowning in data, but starved for insight. Reports are generated endlessly, but rarely answer the questions that matter. Knowledge-based product development flips that. It starts with what decisions need to be made and what knowledge is required to make them well—then it organizes the work around creating that knowledge.

Embracing Uncertainty

The author also makes it clear that this approach doesn’t eliminate uncertainty—it embraces it. Instead of pretending the future is predictable, knowledge-based development builds systems that can adapt as learning occurs. This makes the process more resilient, and ultimately, more effective.

Sustainable Speed Through Learning

A big takeaway from this chapter is that sustainable speed, quality, and innovation don’t come from pushing harder—they come from learning faster. And that learning must be intentional, visible, and shared. Knowledge becomes the fuel that drives decisions, alignment, and progress.

Final Thoughts on Knowledge-Based Development

In short, this final chapter ties together all the ideas in the book with a clear message: product development isn’t about executing a plan—it’s about building knowledge. And organizations that invest in learning as a core capability will be the ones that consistently deliver better products, faster, with less stress and fewer surprises.

4 Key Ideas from The Lean Machine

6 Main Lessons from The Lean Machine

My Book Highlights & Quotes

“… The creation of reusable knowledge comes from the Wright brothers, lean principles from Henry Ford and Taiichi Ohno, development cadence from Thomas Edison, learning cycles from John Dewey, and P-D-C-A from W. Edwards Deming. These principles are the beginning rather than the end of improving product development productivity…”

“… The five disciplines of a learning organization are 1. Systems thinking. 2. Personal mastery. 3. Mental models. 4. Building shared vision. 5. Collective team learning…”

“… The intent of the multiple sets was not to produce multiple alternatives for design solutions, but rather to create varied design parameters to explore specific attributes needed to close the knowledge gap…”

“… Now, it is not only necessary to do the right thing but to do it in the right way and the only problem you have is what is the right thing to do and what is the right way to do it…”

“… You are a product of your environment. So choose the environment that will best develop you toward your objective. Analyze your life in terms of its environment…”

“… It’s not the test information you collect that’s important, but how it’s digested and made visible to create reusable knowledge that’s important…”

“… We tend to focus on the parts that are visible rather than seeing the whole, and in turn, we fail to see the organization as a dynamic organism. Systems thinking argues that a better appreciation of the system leads to more appropriate action…”

“… The knowledge-based development system that creates reusable knowledge is built on two pillars: (1) cadence and flow and (2) set-based design…”

“… Rather than react to the present, learning organizations seek to create their future…”

Conclusion

In the end, The Lean Machine isn’t just about motorcycles or manufacturing—it’s about how we build anything in a complex, fast-moving world.

It reminds us that better outcomes don’t come from working more—they come from working differently.

When we treat product development as a system of learning, collaboration, and knowledge creation, we unlock real speed, real quality, and real impact.

And maybe that’s the biggest takeaway: if we want to move fast, we have to start by slowing down—just enough to truly understand what we’re doing and why it matters.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: