Home > Community> Gemba Coach> But when should we use design thinking or lean thinking?

But when should we use design thinking or lean thinking?

Michael Ballé
Permalink   |   2 Comments   |   Post a Comment   |  
  |   RSS

Dear Gemba Coach

I read your latest and very interesting Gemba Coach column comparing design thinking and lean thinking. But when should we use each?

Hmm … I’m going to go out on a limb here and give a very personal answer – no doubt many design thinkers will disagree. Lean thinkers as well probably.

To make a long story short the two main differences between design thinking are about where to look for solutions and what path to follow:

  • Design thinking starts with the mind and applies solutions to the world. You start by defining the problem and gathering people’s opinions, you formulate a design, and then you apply it. Lean thinking starts with the world: you observe and improve in order to understand the problem with others, so that you and they progressively figure out what the root cause is (through repeated kaizen) and get agreement on where the calculation has to change, and then you come up with a new design in your mind – taking into account their ideas.
  • Design thinking looks to design a complete, static, systemic solution. Lean thinking is about exploring through repeated try-and-see, try-and-see until a path appears to resolution. If one promising avenue doesn’t pan out, you try another until you’ve got a clearer understanding of the territory, your path to a better outcome, and the limits of your considered countermeasure. Design thinking is about the shortest path to the complete solution. Lean thinking is about progressing step-by-step until we’re familiarized with the problem and the solution emerges.

As a lean guy I’ll go back where lean starts – at the Gemba. I was yesterday visiting Alliance-MIM, in a greenfield plant built three years ago. I’ve known the CEO for a long time and he had turned around his company in his old brownfield plant when his major (and huge) client went bust and suddenly he had to rebuild an order book for very technical parts from scratch.

He is a passionate metallurgist building additive parts rather than machining them. Traditionally, metal parts are cut out of a bar of metal, which his hugely wasteful. He makes parts by starting with an iron and plastic mix powder, injecting the part through a mold in a plastic injection press, cooking the parts in high-tech ovens in order to get rid of the plastic and bind the metal atoms with additional elements and gasses, creating a specific microstructure and compositions, and then finishing, calibrating and polishing the result. Here’s JC Bihr presenting lean and green as his strategy.

It's not an obvious process because it involves two batch stages: injection (change of mold) and ovens (trays of parts). In the brownfield plant, he turned the situation around through quality first, and then the flexibility of the injection process. As he went looking for new applications, from medical to aeronautics, he suddenly multiplied the number of molds by an order of magnitude, and so the need to reduce injection batch size drastically. He also learned to mix the trays in the ovens, which was a horrific technical problem, and thankfully the guy is a real genius when it comes to metals.

He says it himself: lean saved the company. But although he had set up a truck preparation area and was building customer orders in several goes, trying to get closer to producing every part every day (reducing the every-part-every-interval), he’d never really got the hang of kanban, even though his production manager was experimenting repeatedly with cards between processes. The old plant was separated in two buildings and parts had a courtyard to cross … it was not easy.

When the company started growing again, it could no longer fit in the old buildings and the CEO decided to build a greenfield plant.

He used a 3P approach, and what I considered design thinking. He gathered his top people and they started drawing alternate maps of the best way to optimize flows. They clearly explained the flow problem to many people, and then worked through three criteria:

  • What we want to achieve: as fluid a production flow as we can, with the easiest work possible;
  • What can realistically be done: how do you organize injection presses and huge ovens in a way that makes sense, considering the issues of molds and pipes and tricky gasses being pumped through the floor;
  • How can we make sure this will work in practice and has space to grow in the future; with any high-tech sensitive process, this surfaced yet another huge batch of constraints.

In the end, having done all the prep work, building the plant was relatively smooth and on time, production was interrupted for a shorter time than anticipated, and well, it worked – everyone got engaged and overcame the unexpected issues, such as the outside covering of the building blocking mobile reception and other total surprises.

Score one for how I understand design thinking: clearly explain what you’re trying to do, put people first, bring them on board, and come up with a better design solution.

And, then, in the new plant, the production manager got started with kanban in earnest. Here is the production manager, Johan Guvier, discussing the leveling board with the rest of the management team.

The first thing that appeared was that with a huge – and variable – product mix, with new molds coming in almost every week, the product/process matrix wasn’t stable. It also became obvious that it was possible to create some cells in a different way than envisaged with the design – but now pipes were sunk in the ground.

Then, following the lead-time on the kanbans, it turned out that issues were not where they’d previously appeared to be.

So, following the problems revealed by the kanbans, the CEO and production manager started solving one-by-one all sorts of issues, starting with difficulties people had with the new plant, training, exploring, scratching their heads, moving stuff around. Step-by-step improvements.

The resulting – and evolving – design is nothing like what was envisioned at first. Kanbans don’t lie, and reality, or “friction” as it was called in XIXth century strategic thinking, strikes back:

  • Some minor, overlooked, details go wrong creating big unexpected problems;
  • Some things we simply don’t know and have to discover when they bite us;
  • Everyone has an opinion and whenever we assume people understand things the same way we later discover they have widely differing interpretations.

Lean thinking with visualizing the process, focusing on abnormalities, clarifying standards, marking progress gets you much closer to dealing with reality than any design thinking method that I know (and I used to draw systems thinking feedback maps and computer simulations for a living, so I know something about designing smart models).

With Dan Jones, Jacques Chaize and Orry Fiume we tried to capture that vast gap in thinking by describing lean thinking as 4F:

  1. Find problems by visualizing the flow and looking at waste;
  2. Face the biggest challenges by setting quantifiable goal posts;
  3. Frame these challenges in ways everyone can grasp, the more visual the better;
  4. Form organic answers from people’s initiative to shape a collective response.

As opposed to traditional thinking which is essentially about 4Ds:

  1. Define the problem on paper;
  2. Decide what to do on the main choice points;
  3. Drive the execution through an action plan;
  4. Deal with the situation when unexpected consequences turn up.

The main difference between design thinking and lean thinking is neither about creativity or people involvement – both approaches seek both. It’s about the source of information. The most basic psychological law uncovered by the last 30 years of cognitive and behavioral research is that what you pay attention to becomes important with respect to everything else. Anything on top of your worry list feels incredibly important, because it’s on top of your worry list, not because it is important.

Ìn traditional thinking, we define what we worry about out of what is in our heads. In lean thinking, we worry about kanban cards, which makes them very important, and the lead-time associated with each card, the abnormalities and delinquents, which makes real-life problems stand out, and involving people in solving them becomes very important. As a result, we attack different issues, at a very different granular level (like making metal from powder, not cutting it from iron bars) – a granularity that can’t be attacked with engineering and engineers, but needs cooperation between hands-on operators and engineers. It’s a completely different way of approaching the world when you use kanbans as a discovery method and learning what just-in-time teaches you, step-by-step.

The resulting solutions are just radically different, as we can see from how Toyota turned around the NUMMI Fremont plant in the eighties, from the worse performing GM plant to the best, and how Tesla has turned back the very same plant, now that they’re in it, in a quality and delivery mess that simply doesn’t get the production out.

To answer your question, I doubt that we can ever stop using design thinking – this is our default mode. In lean we use design thinking in what we call “helicopter thinking” – looking at the big picture, with tools such as material and information flow analysis and so on. But at the very granular detail of reality, we use “look with your feet, think with your hands” lean thinking by following the kanban cards and always trying to get closer to one product by one product, one customer by one customer, one team member by one team member and treat everything with respect to their individuality. Therefore we always use both. Start from lean thinking, write down the big picture with overall designs and models, bring it back down to the kanban level and so on.

When you think of a practical solution, ask yourself: what general principles are at play here? When you’re thinking in generalities, ask yourself: what should we do in practice for the next step?

2 Comments | Post a Comment
Ted Toussaint February 12, 2018

My understanding and experience with design thinking is quite different than how you have described it here. Design thinking starts with the the customer, not with the designer's mind... the goal is to develop a deeper understanding of the customer than ever before to uncover needs. If you can meet those needs you are on the path to a winning solution. This different than a production focus where end-customer needs are already defined and the aim is to reduce waste.

I also don't think that lean thinking and design thinking should be separated into mutually exclusive camps. I don't see them as either/or. For example, the use of genchi gembutsu in lean development offices, where designers literally live as the customer lives, in the customer's gemba, is similar to the empathize portion of the design thinking process. Great lean companies use design thinking principles, though they might not always give it that label, just like Toyota didn't come up with the term lean. 

Jay Bitsack February 12, 2018

Hi All,

HERE WE GO AGAIN!!!!  Another perfect example of black or white thinking in action.  The reality of the difference between design thinking and lean thinking is that there is NO place for or value in creating and EITHER/OR contention between them.  And the example of the design thinking that went into design a production facility DOES NOT and SHOULD NOT represent the quintessential example of how the best design thinking can be put into effect.

Rather, a much better example can be found in how ROBUST or SET-BASED DESIGN ENGINEERING is optimally conducted.  In this case, a finalized solution design is "DEFERRED" as a result of multipe design considerations being spread out across various options; each of which demonstrates a different balance/mix of specification priorities (aka trade-offs) and subsequently tested against overall SYSTEM performance requirements.  Needless to say, this mode of design thinking is iterative in nature as opposed to being a BIG BANG-like approach to developing a solution.  And at its heart is the notion of FAILING-FAST and FAILING OFTEN (aka hands-on, trial and error, experience/experiment-based LEARNING).

That said, there should be little to no difference in the sort of design thinking that goes into ROBUST PRODUCT DESIGN than one would expect should go into ROBUST PROCESS DESIGN.  Both the product and the process - in TRUE LEAN THINKING AND BEHAVING (ala the NPPD/I process) - MUST perform to a higher-order standard in order for the overall SYSTEM to have any chance of demonstrating [in the market place to customers and competitors alike] superior overall capabilities.  Ergo, the BEST DESIGN THINKING AND BEHAVING is really inherent  (i.e., existing in something as a permanent, essential, or characteristic attribute) as a enterprise CORE/DISTINCTIVE COMPETENCY within the overall context of the SYSTEM's TRUE LEAN THINKING AND BEHAVING capabilities.

Other Michael Ballé Related Content

Gold Mine Master Class



  • How do I fix our main delivery processes -- again?
    Dear Gemba Coach,
    I’m part of a large logistics organization and our on-time-delivery is simply disastrous. We’ve done a first value-stream map to improve our main delivery processes, and it surfaced so many issues. We had projects to fix some, but things seem worse. We’re about to start again – any ideas on how to get it right?
  • Are Design Thinking and Lean Thinking the Same?
    Dear Gemba Coach,
    As a practitioner and advocate of design thinking, I’ve been curious about lean, but it seems to me we’re talking about the same thing: essentially developing a PDCA mindset in people. Isn’t that the case?
  • What would "process points" be in software development?
    Dear Gemba Coach,
    Thank you for your previous column that has raised profound questions for me to work on with my software development teams. For example, what are our "process points"? How do we as lean managers enable thinking deeper together about them? What are the behaviors that encourage "better people to work better with each other to create better processes"?