Sunday, January 04, 2015

What Is Design Thinking?

The Context

Over the years, various product management and development methods have come into vogue, most notably agile and lean startup methods. Agile methods addressed requirements, architecture, and development risks using frequent iterations. Lean startup methods take it a step further, iterating on the entire product strategy, including the unique value proposition, the target market, revenue and cost structure, and marketing and sales channels.

Recently, you may have heard more and more chatter about "design thinking". I certainly have. What is it, and how does it differ from agile and lean startup methods? How can companies leverage it to innovate and develop better products?

The Definition

If you do some web searches, you'll notice a lot of vague references to design thinking and a diversity of views about what it is. After exploring some definitions, I'll borrow from various descriptions and accounts of design thinking to form what I believe is a coherent explanation of what it is.

Let's see how Tim Brown, CEO of IDEO, defined "design thinking" in his seminal article in Harvard Business Review:
"[Design thinking is] a methodology that imbues the full spectrum of innovation activities with a human-centered design ethos."
Clear as mud, eh?


My former colleague, Davide Casali, defines it as follows:

This definition is concise and nicely aligns with the plain meanings of the words. It leads us to the key question: what are the characterizing activities of design thinkers? Indeed, Wikipedia states:

Hmm. I'm not sure about the "design-specific" part of this definition, but let's look at the activities that characterize design thinking.

The Activities

Note: these activities characterize design thinking but do not necessarily come in any particular sequence or imply a particular "process".
  • Explore the problem domain. Interview prospective customers and users. Observe and experience the problem and its context first hand.
  • Define the problem you are trying to solve. Half of the battle in designing a great solution is to clearly define the problem you're solving.
  • Ideate to generate perspectives on the problem and ideas for solving it. Set aside analytical thinking and engage your right brain.
  • Hypothesize about the problem, solution, and business model. What would have to be true for the problem to resonate with prospects and for the solution to solve the problem? How would you know that your hypotheses and assumptions are false?
  • Experiment to test your hypotheses and assumptions. Employ prototypes and confront prospects with real and concrete choices.
  • Learn from all your other activities, especially from exploration and experiments. Design thinking isn't (merely) about "creativity" and having a sense for the "right" solution. It's about learning and discovery.
Key Concepts

Design thinkers leverage key concepts that differentiate the solutions that emerge from their activities.
  • Holism. In design thinking, the product is a set of experiences, not of features, that provide value. The nature and value of the experiences depends on a larger ecosystem, such as the one Apple created with iTunes.
  • Iteration. You almost never get it right the first time, and you shouldn't spend a lot of time trying. While design thinkers don't necessarily employ a particular process, they iterate in their approaches to understanding the problem, the customer, and the solution.
Final Thoughts

Some product managers, agile teams, and lean startup practitioners engage in some of the same activities, and apply some of the same concepts, as designer thinkers. In particular, iteration has long been a core part of agile processes. Lean startup practices are iterative and also incorporate hypothesizing, experimenting, and learning in a build-measure-learn loop. The best product managers learn about markets by interviewing and observing prospective customers and users.

But agile and lean startup methods differ from design thinking in several ways:
  1. Though certain activities and concepts characterize design thinking, it's not a "process".
  2. While agile methods are iterative and include some hypothesizing, experimenting, and learning, they don't necessarily include other design thinking activities or a holistic view of the product.
  3. Open-ended exploration is not part of lean startup methods, though they arguably incorporate all other design thinking activities. (I'll address this controversial topic in a future blog entry. UPDATE: Read how the "customer development" concept in lean startup methods, at least according to Steve Blank, does NOT include open-ended exploration.)
  4. You can employ lean startup methods without a holistic view of what constitutes a "product".
Many product teams suffer from tunnel vision, which stifles innovation. The tunnel vision stems from paying insufficient attention to raw exploration and obsessing over "validating" their preconceived ideas. And most of them treat products as collections of features instead of holistic sets of experiences. Product managers can up their game by leveraging all aspects of design thinking.

UPDATE: I covered design thinking at ProductCamp Austin 14. The title of my session was "WTF Is Design Thinking". You can get a link to the slides by tweeting this blog entry. Send this tweet:
What Is #designthinking?
Thanks to Davide Casali and Shardul Mehta for reviewing and providing feedback on initial drafts of this blog entry.


Centurion said...

Quality piece. Really appreciate the way you drew out the differences between the methodologies at the end.

I have found many product commentators don't do fully understand the methodologies or think about them deeply enough to really understand the differences between them e.g. Lean, Agile, Lean UX, Design Thinking etc.

So they instead treat them completely independently, which is inaccurate.

Roger Cauvin said...

Thanks, Centurion.

There is both a great deal of overlap and confusion among the different methods and approaches.

Combining the best of each approach, tailored to the circumstances of the particular product effort, is probably the way to go.