With this chapter we begin the initiative journey at its proper starting point: the problem, which comes before the idea. We trace the sources of opportunity, ways of understanding a problem from the perspective of those who live it, and methods for framing and reframing it, and then the criteria for selecting, from among many problems, those worth investing in.
A government agency was receiving repeated complaints about how long one of its services took to complete. It formed a team to improve the service, and the team started from an assumption that seemed self-evident: the problem lay in the slowness of the online system. Eight months and considerable expense later, a much faster system was launched, and the complaints did not decline. When a new team member sat down with a number of service users and traced their journey step by step, he discovered that most of the delay had nothing to do with the system: a third of all applications were being returned because applicants did not know which documents were required, and they found out only days after applying. The solution that ended most of the complaints was a clear checklist of documents displayed before an application began.
The team had not been negligent; it had efficiently solved the problem it had defined. But it had solved the wrong problem. The subject of this chapter is the step that should have preceded its work and was overlooked: understanding the problem before seeking a solution.
After studying this chapter, the reader should be able to:
Chapter 1 corrected a common belief that innovation begins with ideas, showing that the more accurate starting point is a need, problem, or opportunity, with the idea coming afterward as a hypothesis for a solution. The opening case shows the price of ignoring this: the team began with a solution idea, invested in it, and revisited the problem only after the solution had failed.
This case has many parallels. In a survey of 106 senior executives in 91 public and private organizations across 17 countries, 85 percent said their organizations were poor at diagnosing problems, and 87 percent said this weakness carried significant costs (Wedell-Wedellsborg, 2017). Organizations tend to jump to solutions because a solution feels like productive work, whereas pausing over the problem feels like delay.
Problem finding has a creative dimension that many overlook. In a classic study, Getzels and Csikszentmihalyi followed art students who were asked to produce a drawing from a set of available objects. Students who spent more time exploring and selecting the objects, and who changed their conception as they worked, produced drawings that judges rated as more original, and seven years later they were more successful in their artistic careers (Getzels & Csikszentmihalyi, 1976). How they engaged with the problem before solving it was part of the creativity itself. This is why the innovator's path model, presented in Chapter 7, begins its thinking phase by defining the problem before generating ideas.
Drucker held that systematic innovation rests on an organized search for changes that create opportunities. He identified seven sources of such opportunities, four within the organization or its industry and three in the wider environment (Drucker, 1985), as Figure 11.1 shows.
Drucker observes that the first sources are closer at hand and less risky, while new knowledge, for all its appeal, has the longest road to application and the highest risk. This matters for organizations that equate innovation with new technology; many of the nearest opportunities lie in complaints, recurring errors, procedures that people bypass, and unexpected results whose causes no one has asked about. Chapter 4 linked the wider environment to foresight and the external realities scanning matrix; this chapter focuses on the nearer sources.
One source deserves particular attention: lead users. Von Hippel defined them as people who face a need months or years before most others do, and who expect to benefit significantly from meeting it, so they often innovate solutions for themselves before any provider offers one (von Hippel, 1986). Every organization has lead users: an employee who has built a spreadsheet to shortcut a repetitive task, or a service user who habitually brings a document that was not requested because they know it will be asked for later.
The people closest to problems are those who work with them every day. For example, the student in Chapter 7's opening case noticed a real problem during her field placement that people who had worked at the organization for years had not. Field placements, applied projects in courses, and work with external organizations are all sources of problems that a university can turn into a structured entry point to its innovation system.
If a problem lives in a person's experience, understanding it requires getting close to that experience. This principle is the foundation of design thinking, which begins with a deep understanding of people's lives and needs before moving on to generate solutions (Brown, 2008). Liedtka points out that the value of this approach lies less in its tools than in its capacity to counter well-known biases in thinking, such as the belief that others see the world as we do, settling for the first plausible explanation, and becoming attached to the first solution (Liedtka, 2018).
Understanding a problem relies on three main tools:
Among the most telling indicators of need are workarounds: the ways people devise to cope with a problem no one has solved for them. The employee who keeps a separate notebook because the system does not allow what they need, and the service user who calls a friend working at the agency to learn the status of an application, both point to a real need that people are expending effort to meet. A need that people make no effort to work around may not be as important as it appears.
The jobs to be done framework offers a complementary angle. Christensen and colleagues suggest asking: What is the person trying to accomplish in a particular circumstance? People draw on a service or product to make progress in their lives (Christensen et al., 2016). What the service user in the opening case wants is to complete the transaction in a single visit without surprises, and the system's speed is only a partial means to that end. This difference in framing is what would have changed the team's entire course.
Before your next meeting about a problem in your organization, spend one hour with someone who lives it: an employee who carries out the procedure, or a beneficiary who goes through it. Do not present a solution, and do not ask for their opinion of an idea. Ask them to show you how they work, and write down everything that surprises you.
The way a problem is formulated determines which solutions can be seen. Wedell-Wedellsborg offers a well-known example: the tenants of a building complain that the elevator is slow. If the problem is framed as “the elevator is slow,” solutions turn toward speeding it up or replacing it at great cost. If it is framed as “the wait is annoying,” it may be enough to put a mirror next to the elevator; people waiting become absorbed in looking at it and no longer notice how long they wait (Wedell-Wedellsborg, 2017). This does not mean the second framing is always right; the elevator may really be slow. The point is that a single problem admits multiple framings, and searching for them reveals solutions that were previously invisible. Figure 11.2 illustrates the reframing in the opening case.
“The online system is slow.”
Possible solutions: upgrading the system, adding servers, or replacing it.
“Applicants don't know what they need before they start, so their applications are returned.”
Possible solutions: a clear document checklist, instant verification at submission, or dropping documents that are not needed.
Simple questions can aid reframing. Are we looking at the problem from the perspective of the person who lives it, or of the one who provides the service? What happens before and after the problem? Is it a symptom of a deeper problem? Is there anyone in the same circumstances who does not suffer from it, and why? Asking “Why?” repeatedly until a root cause is reached is a useful tool here, provided it does not turn into a hunt for someone to blame.
In the public sector especially, many problems are of the kind Rittel and Webber called wicked problems: they cannot be given a definitive formulation, their understanding is shaped by the solutions proposed for them, there is no clear rule for knowing when they have been solved, and every attempt to solve them changes the problem itself (Rittel & Webber, 1973). With problems of this kind, framing becomes an ongoing process renewed as the work advances, and small-scale experimentation, the subject of Chapter 14, becomes a tool for understanding the problem as much as for testing the solution.
This stage ends with a clear problem statement on which the team can build. A good statement covers: Who is struggling? In what circumstances? What are they trying to accomplish? What is getting in their way? What is the evidence? It is then turned into a challenge question that opens the way to solutions without prescribing them, usually beginning “How might we…?”, as Chapter 4 showed in moving from search fields to challenge questions.
An organization discovers more problems than it can work on, so it needs a way to choose those worth investing in. Ulwick proposes a simple criterion: measure each need on two dimensions, its importance to the person who lives it and their satisfaction with the current way it is met. The biggest opportunities are important needs whose current solutions leave people dissatisfied (Ulwick, 2002). Figure 11.3 illustrates this logic.
To these two dimensions we add three questions. Does the problem fall within one of the search fields set by the strategy in Chapter 4? How strong is the evidence for its existence and scale? Is there anyone in the organization with the motivation and ability to work on it? An important problem that no one is enthusiastic about, or that falls outside the organization's priorities, may end up in decision limbo however valuable it is.
The time spent understanding a problem is the cheapest and most consequential stage of innovation, even if it looks like a delay to the solution. Changing how a problem is framed at the outset costs nothing; changing a solution after it has been built costs a great deal.
Fill in this card before any discussion of solutions begins. If you find yourself writing a solution in any field, delete it and return to the problem. Ask someone who lives the problem to read the card and tell you whether it describes them.
| Item | Question | Example |
|---|---|---|
| Who is struggling? | Who exactly lives the problem, and in what circumstances? | Service users applying for the service for the first time |
| What are they trying to accomplish? | What job or progress are they seeking? | Completing the transaction in a single visit without surprises |
| What is getting in their way? | Where do they stumble on their journey? | They discover missing documents days after applying |
| Workarounds | What do people do today to cope with the problem? | Calling acquaintances at the agency, or bringing every document just in case |
| Evidence | What demonstrates the problem's existence and scale? | A third of applications are returned for missing documents |
| Alternative framings | Write at least two other framings | “Applications are returned” / “The applicant doesn't know what is required” |
| Importance and satisfaction | How important is the need, and how satisfied are people with its current solution? | High importance, low satisfaction |
| Link to strategy | Which search field does it fall within? | Improving the beneficiary experience |
| Challenge question | How might we…? | How might applicants know everything they need before they start? |