Understanding how Design Thinking, Lean and Agile Work Together "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 18 May 2020 False Agile, Culture, Design, Design Thinking, Lean, Lean Startup, Product Design, Product Development, Product leadership, Mind the Product Mind the Product Ltd 1378 Product Management 5.512

Understanding how Design Thinking, Lean and Agile Work Together

The ideas of Agile are great. It’s the way it has been codified into rituals and certifications, and rolled out mindlessly that misses the point.

When people talk about Lean, the conversation often ends at process optimization, waste, and quality, and misses so much of what the Lean mindset offers.

Design Thinking is held high as the new magic trick of design facilitators.

That’s three mindsets corrupted by the unthinking masses, who’ve grabbed onto a tantilising promise of something better, and followed the steps without really thinking it through. People have a real need to change, but they get stuck following rules or process without really understanding why.

Figure 1. Three mindsets of product development

Design Thinking is how we explore and solve problems; Lean is our framework for testing our beliefs and learning our way to the right outcomes, and Agile is how we adapt to changing conditions with software.

Design Thinking is about ability and learning. Carissa Carter, head of teaching at Stanford Design School, brilliantly describes some of the abilities that make designers great. Abilities like dealing with ambiguity, empathetic learning, synthesis, and experimentation, among others. A designer’s ability to make meaning, frame a problem, and explore potential solutions are key. Donald Norman, author of The Design of Everyday Things, describes a designer’s discontent with the first idea. Ask yourself, when was the last time that your first idea was your best idea? Meaning and new ideas emerge when we explore things. Design Thinking is simply how we explore those problems and solutions. Everyone designs, whether it’s conscious or not. If you’re solving a problem, you’re designing a solution. Design Thinking is a mindset that helps us do it better.

Lean started out as a response to scientific management practices in manufacturing. Organisations sought efficiency through process, rules, and procedures and management was mostly about control. But in modern business, control is a falsehood. Things are too complex, too unpredictable, and too dynamic to be controlled. Lean offers a different mindset for managing any system of work. It’s fundamentally about exploring uncertainty, making decisions by experimenting and learning, and empowering people who are closest to the work to decide how best to achieve desired outcomes. Lean says be adaptive, not predictive.

Agile is related to Lean. The differences are mostly about what these mindsets are applied to, and how. In conditions of high uncertainty, Agile offers ways to build software that is dynamic and can adapt to change. This isn’t just about pivoting. It’s also about scaling and evolving solutions over time. If we accept that today’s solution will be different from tomorrow’s, then we should focus on meeting our immediate needs in a way that doesn’t constrain our ability to respond when things change later. The heart of Agile is adapting gracefully to changing needs with software.

Figure 2. Comparing and contrasting Lean and Agile

The real benefit comes when we bring all three mindsets together. Too often, the question is “lean or agile?”. The answer is “and”, not “or”: it’s Design Thinking, Lean, and Agile. That’s easy to say, but how do we do it, and what does it look like in practice? Here’s some lessons learned from applying Design Thinking, Lean, and Agile in the wild.

Purpose, Alignment, and Autonomy

“Be stubborn on the vision, but flexible on the details.”
—Jeff Bezos

Building a product is a lot like a combat mission. A team of skilled people operate in conditions of high uncertainty; a commander sets clear outcomes with some guiding principles; but we expect the unexpected; and, we’re trained to take best action, responding to new information as the situation unfolds.

All of that takes discipline. And practice.

In military operations, it’s called disciplined initiative, and soldiers train so they can practise the movements of combat. In Mike Rother’s Improvement Kata, it’s called deliberate practice, and it’s how we practise the movements of scientific thinking. This is how product teams can align to purpose, explore uncertainty, and learn their way to achieving desired outcomes.

Pro tip: Try visualising the whole end-to-end process, from aspirations and hypotheses to design experiments and feedback on a big product wall, so that the whole team can play along together.

Figure 3. A product wall

Measure Things That Matter

“If a measurement matters at all, it is because it must have some conceivable effect on decisions and behavior.”
—Douglas W. Hubbard

How will you measure outcomes?
When will you know you’ve achieved it?
Will your metrics help you make a decision?

We all know that vanity metrics – like total page views, or total new customers – are pointless. But knowing what not to measure doesn’t make measuring the right things any easier. Even with the right motives, there are lots of ways we get it wrong. Suppose you’re operating an online store selling tens of thousands of unique items to all kinds of buyers. Making it easier for them to find what they’re looking for is one of your goals. Now try breaking that goal down into metrics that help you know if you’re on the right track.

Figure 4. The good and bad of goal-based measurements

Pro tip: Structure your metrics around future decisions you want to make. Only measure things that indicate progress toward your goal. Hypothesis Driven Development offers a way to frame outcomes, beliefs, and metrics in a simple, repeatable format. It gives some structure for finding the right metrics, and makes it easy to communicate to others.

Make Decisions Based on Learning

“Don’t look for facts or answers — look for better questions. It’s the questions we ask, and the meaning we explore, that will generate the insights most useful to strategy.”
—Dr Jason Fox

Why do we learn? To make better decisions. Many solutions fail because they solve no meaningful problem, and we tend to fall in love with our ideas and let our biases get the better of us. Even when we try to de-risk our decisions by testing our ideas and running experiments, we don’t always get it right. One trap is to conflate a good prototype test result with strong affinity for the problem, or customer demand for the solution. Each of those – problem, solution, demand – are separate concerns, and they require different learning approaches.

We don’t need to be scientists to learn the right things, and, insight doesn’t have to belong only to the research team. If we think through our approach, it can help us make better decisions. We can start by:

  1. Defining our beliefs and assumptions (so that they can be tested)
  2. Deciding the most important thing to learn
  3. Designing experiments that will deliver learning

Pro tip: The Problem-assumption Model is an easy way to get started. It’s a way of helping us ask: What’s the problem? How might we solve it? What assumptions have we made? How will we test our assumptions?

Figure 5. The Problem-Assumption Model, created by Jonny Schneider and Barry O’Reilly

Many Mindsets, one Team

Most important of all, it’s about working together and achieving together. Learning is a team sport, and collaboration is key if we’re going to find our way to the place we want to be. There is no one correct way, nor is one single mindset enough. But all together, elements of each mindset help us to find our way forward.

Figure 6. How the three mindsets overlap

Instead of focusing on applying a process, teams ought to challenge how they think and try new things, embrace the things that work, and learn from the things that don’t. This right way will be different for each team in their own specific context. Success is about how teams develop new ability, learn by doing, and adapt to what is learned.

Pro-tip: Try Jeff Patton’s Dual Track Development. It describes how teams can bring product discovery and product development closer together into one collaboration.

Comments 13

What is missing in your model is that design thinking process/design processes in general start with user research/studies that translate to user needs that will streamline all the other processes in Lean (production) and Agile (development) if used in parallel. Exploring problems and alternatives is true, but its inspired by user needs. Always. As a professional designer I see Agile and Lean synonymous to design since we do the same things but in different ways. I think the benefit of Agile and Lean is to externalize the process of designing which is in traditional design very hard fully describe/understand for non-designers and is too focused on individual designer.

Great post – it was neat to get those three concepts unpacked in contrast to one another. I come from manufacturing, where lean is emphasized heavily, as you mention, and I currently work in medical device product development. I could definitely see how an embrace of those three methodologies in concert (or at least an awareness of them) could really benefit the hardware product development process, but I don’t hear them talked about much. Any thoughts on how these methodologies translate outside of the software world?

There is an open source version of a methodology integrating the three in a extremely successful flow: theservicestartup.com.
Additionally, you can train and certify on it at designsprintschool,com
It’s been used anywhere from social innovation challenges to enterprise services in companies like GE, Cisco, Deutsche Bank, Telstra, etc.

Thanks for the tip. I suspect you’re not entirely neutral 😉 but I appreciate a tried and tested method that I can use and adapt or compare with my ‘learnt through trial and error’ approach.
The order has been placed…

Very helpful article. I am using Test & Learn which I believe to be the same as Hypothesis Driven Development. Unfortunately the link in your article leads back to this article!

Brilliant post that clearly brings out the differences between Design Thinking, Lean and Agile. But much more importantly the similarities and how they come together for innovative product development. Loved it Jonny! Thanks.

Methodologies are great. But they are only as good (or bad) as the org / team that implements them. The theory is easy and obvious, as this article so nicely explains. However, the process too often fails when its exposed to reality, to the human element. It would be helpful if this article moved from theory to practical usage. How do we make these things work and keep them working? That’s the hard part. The really really hard part.

Totally agree that it’s people, not process that is usually the hard part. And importantly, the ‘right’ way will look different for each team, evolving as they learn what works for them and adapt their approach accordingly. In terms of doing and sustaining the work, check out my free eBook from O’Reilly Media called “Understanding Design Thinking, Lean, and Agile”. It includes loads of ways to get started, and unpacks some of the nuts and bolts behind this high-level summary article. Cheers, -Jonny

In the end it boils for to:

Listen + Think + Do + Test + Repeat

The labels and steps you can slap on that process is endless. Put another way: Don’t just solve a problem, solve the right problem. A solution to the wrong problem is no solution at all.

The disconnect, again and again, is caused by “human error.” For example, leadership setting unrealistic deadlines, management then looking for shortcuts (of which there are none), and the team juggling that sure-to-backfire context.

Long to short, flavor of the moment methodologies can’t save ya from stupid 🙂

Join the community

Sign up for free to share your thoughts

About the author

The ideas of Agile are great. It’s the way it has been codified into rituals and certifications, and rolled out mindlessly that misses the point. When people talk about Lean, the conversation often ends at process optimization, waste, and quality, and misses so much of what the Lean mindset offers. Design Thinking is held high as the new magic trick of design facilitators. That’s three mindsets corrupted by the unthinking masses, who’ve grabbed onto a tantilising promise of something better, and followed the steps without really thinking it through. People have a real need to change, but they get stuck following rules or process without really understanding why. [caption id="attachment_12114" align="aligncenter" width="748"] Figure 1. Three mindsets of product development[/caption] Design Thinking is how we explore and solve problems; Lean is our framework for testing our beliefs and learning our way to the right outcomes, and Agile is how we adapt to changing conditions with software. Design Thinking is about ability and learning. Carissa Carter, head of teaching at Stanford Design School, brilliantly describes some of the abilities that make designers great. Abilities like dealing with ambiguity, empathetic learning, synthesis, and experimentation, among others. A designer’s ability to make meaning, frame a problem, and explore potential solutions are key. Donald Norman, author of The Design of Everyday Things, describes a designer’s discontent with the first idea. Ask yourself, when was the last time that your first idea was your best idea? Meaning and new ideas emerge when we explore things. Design Thinking is simply how we explore those problems and solutions. Everyone designs, whether it’s conscious or not. If you’re solving a problem, you’re designing a solution. Design Thinking is a mindset that helps us do it better. Lean started out as a response to scientific management practices in manufacturing. Organisations sought efficiency through process, rules, and procedures and management was mostly about control. But in modern business, control is a falsehood. Things are too complex, too unpredictable, and too dynamic to be controlled. Lean offers a different mindset for managing any system of work. It’s fundamentally about exploring uncertainty, making decisions by experimenting and learning, and empowering people who are closest to the work to decide how best to achieve desired outcomes. Lean says be adaptive, not predictive. Agile is related to Lean. The differences are mostly about what these mindsets are applied to, and how. In conditions of high uncertainty, Agile offers ways to build software that is dynamic and can adapt to change. This isn’t just about pivoting. It’s also about scaling and evolving solutions over time. If we accept that today’s solution will be different from tomorrow’s, then we should focus on meeting our immediate needs in a way that doesn’t constrain our ability to respond when things change later. The heart of Agile is adapting gracefully to changing needs with software. Figure 2. Comparing and contrasting Lean and Agile The real benefit comes when we bring all three mindsets together. Too often, the question is “lean or agile?”. The answer is “and”, not “or”: it’s Design Thinking, Lean, and Agile. That’s easy to say, but how do we do it, and what does it look like in practice? Here’s some lessons learned from applying Design Thinking, Lean, and Agile in the wild.

Purpose, Alignment, and Autonomy

“Be stubborn on the vision, but flexible on the details.” —Jeff Bezos Building a product is a lot like a combat mission. A team of skilled people operate in conditions of high uncertainty; a commander sets clear outcomes with some guiding principles; but we expect the unexpected; and, we’re trained to take best action, responding to new information as the situation unfolds. All of that takes discipline. And practice. In military operations, it’s called disciplined initiative, and soldiers train so they can practise the movements of combat. In Mike Rother’s Improvement Kata, it’s called deliberate practice, and it’s how we practise the movements of scientific thinking. This is how product teams can align to purpose, explore uncertainty, and learn their way to achieving desired outcomes. Pro tip: Try visualising the whole end-to-end process, from aspirations and hypotheses to design experiments and feedback on a big product wall, so that the whole team can play along together. [caption id="" align="aligncenter" width="729"] Figure 3. A product wall[/caption]

Measure Things That Matter

“If a measurement matters at all, it is because it must have some conceivable effect on decisions and behavior.” —Douglas W. Hubbard How will you measure outcomes? When will you know you’ve achieved it? Will your metrics help you make a decision? We all know that vanity metrics - like total page views, or total new customers - are pointless. But knowing what not to measure doesn’t make measuring the right things any easier. Even with the right motives, there are lots of ways we get it wrong. Suppose you’re operating an online store selling tens of thousands of unique items to all kinds of buyers. Making it easier for them to find what they’re looking for is one of your goals. Now try breaking that goal down into metrics that help you know if you’re on the right track. [caption id="" align="aligncenter" width="728"] Figure 4. The good and bad of goal-based measurements[/caption] Pro tip: Structure your metrics around future decisions you want to make. Only measure things that indicate progress toward your goal. Hypothesis Driven Development offers a way to frame outcomes, beliefs, and metrics in a simple, repeatable format. It gives some structure for finding the right metrics, and makes it easy to communicate to others.

Make Decisions Based on Learning

“Don't look for facts or answers — look for better questions. It's the questions we ask, and the meaning we explore, that will generate the insights most useful to strategy.” —Dr Jason Fox Why do we learn? To make better decisions. Many solutions fail because they solve no meaningful problem, and we tend to fall in love with our ideas and let our biases get the better of us. Even when we try to de-risk our decisions by testing our ideas and running experiments, we don’t always get it right. One trap is to conflate a good prototype test result with strong affinity for the problem, or customer demand for the solution. Each of those - problem, solution, demand - are separate concerns, and they require different learning approaches. We don’t need to be scientists to learn the right things, and, insight doesn’t have to belong only to the research team. If we think through our approach, it can help us make better decisions. We can start by:
  1. Defining our beliefs and assumptions (so that they can be tested)
  2. Deciding the most important thing to learn
  3. Designing experiments that will deliver learning
Pro tip: The Problem-assumption Model is an easy way to get started. It’s a way of helping us ask: What’s the problem? How might we solve it? What assumptions have we made? How will we test our assumptions? [caption id="" align="aligncenter" width="728"] Figure 5. The Problem-Assumption Model, created by Jonny Schneider and Barry O’Reilly[/caption]

Many Mindsets, one Team

Most important of all, it’s about working together and achieving together. Learning is a team sport, and collaboration is key if we’re going to find our way to the place we want to be. There is no one correct way, nor is one single mindset enough. But all together, elements of each mindset help us to find our way forward. [caption id="" align="aligncenter" width="728"] Figure 6. How the three mindsets overlap[/caption] Instead of focusing on applying a process, teams ought to challenge how they think and try new things, embrace the things that work, and learn from the things that don’t. This right way will be different for each team in their own specific context. Success is about how teams develop new ability, learn by doing, and adapt to what is learned. Pro-tip: Try Jeff Patton’s Dual Track Development. It describes how teams can bring product discovery and product development closer together into one collaboration.