Design Thinking: What's the Problem?
Design Thinking has become the go-to methodology for activating innovation initiatives across any number of businesses, government organizations, and not-for-profits. Some of the tools used in the design thinking process—observational research, rapid prototyping, quick validation techniques—are so popular, they’ve become the near-equivalent of GAAP standards for innovation related work efforts.
Unfortunately, many of these shiny new innovation efforts begin with an internally focused and narrow definition of why the effort is undertaken. Look for the words “we” and “our” in the rationale to begin the effort. As in, we need to grow our market share, we need to expand our product line, we need to figure out how to apply technology X (fill in the blank) to our business, or we need to make our supply chain more efficient. These “we-centered” statements, rather than customer-centered or user-centered statements, typically result in prosaic solutions at best and disappointment at worst.
That doesn’t mean the answer is to simply double down on market research. We’ve all heard the pitfalls associated with traditional market research techniques: customers don’t know what they want, or they can’t articulate their needs when asked. Then again, expert bias, or preconceived notions or solutions can also enter the picture when conducting such research, particularly in mature or commodity businesses. Design thinking research tools can effectively address these shortcomings, and in the process gather large and robust amounts of qualitative customer data. Unbiased and well-crafted interviews, anthropologically based observational research, empathetic activities like walking in the customers’ shoes, and customer co-creation exercises are all outstanding sources of such user-centered data.
A critical, yet often overlooked phase of the design thinking process is translating the data gathered through research into insights and writing a problem statement. Once a problem statement is properly defined, all the remaining steps in the design thinking process can flow naturally, from brain-storming and ideation to prototyping and testing assumptions, to the final refined idea.
The importance of well-crafted problem statements were recently highlighted in my classroom through two industry sponsored projects. The IBM Design organization, headquartered in Austin, TX, has developed a design thinking methodology termed “enterprise design thinking” that places an emphasis on the importance of well-written problem statements.
While their methodology is designed specifically for their large-enterprise clients, they follow many of the principals typical of most design thinking methodologies. They said well written problem statements should avoid (1) “we need to…” phrases, (2) a solution embedded within the context of the problem statement, or (3) lead the team to a pre-determined solution. IBM’s Design team says an effective problem statement should clearly identify “what problem are we solving, for whom, and why?” Our other industry sponsor, Amazon.com takes an approach called “working backwards” to create problem statements.
Innovation efforts at Amazon are organized around small teams, and begin by writing a hypothetical press release announcing a finished product. This dummy press release states how their solution meets the needs of a specific customer and how it is significantly better than the status quo. The press release has all the elements of a real release, including a product name, a few brief paragraphs that describe the product and the problem it solves for a specific customer segment, a quote from a company official and a hypothetical customer, and when the product will be available. And in keeping with current press release practices, it’s followed with a comprehensive FAQ.
In practice, the goal is an easy to read document that can be reviewed by internal stakeholders. It is not intended to be a formal product or system spec. Much like IBM’s iterative design process, Amazon’s working backward process encourages the team to keep iterating the press release, alongside their prototyping and testing activity, until they arrive at a production ready solution.
Both of these approaches can result in a tightly written problem statement that provides real focus for the entire organization. Try incorporating one of these techniques into one of your own new product programs.