Skip to main content

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 design 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? http://cauv.in/wtfdt
Thanks to Davide Casali and Shardul Mehta for reviewing and providing feedback on initial drafts of this blog entry.

Comments

Unknown 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 L. 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.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Use Case as a Black Box

Consider the following use case: Purchase Items Actor: Purchaser Precondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40. Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased. The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items. What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement . Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint: Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no

Henry Ford's "Faster Horse" Quote

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the