Define the Problem: The First Principle of Decision-Making
Defining the problem accurately is the critical first step in decision-making. It involves identifying the desired outcome and obstacles, and focusing on root causes rather than symptoms to avoid solving the wrong problem.
THE IDEA
Define the Problem
The first principle of decision-making is that the decider needs to define the problem.fn1 If you’re not the one making the decision, you can suggest the problem that needs to be solved, but you don’t get to define it. Only the person responsible for the outcome does. The decision-maker can take input from anywhere—bosses, subordinates, colleagues, experts, etc. However, the responsibility to get to the bottom of the problem—to sort fact from opinion and determine what’s really happening—rests with them.
Defining the problem starts with identifying two things: (1) what you want to achieve, and (2) what obstacles stand in the way of getting it.
Unfortunately, people too often end up solving the wrong problem.
Perhaps you can relate to this scenario, which I’ve seen thousands of times over the years. A decision-maker assembles a diverse team to solve a critical and time-sensitive problem. There are ten people in the room all giving input about what’s happening—each from a different perspective. Within a few minutes someone announces what they think the problem is, the room goes silent for a microsecond … and then everyone starts discussing possible solutions.
Often the first plausible description of the situation defines the problem that the team will try to solve.fn2 Once the group comes up with a solution, the decision-maker feels good. That person then allocates resources toward the idea and expects the problem to be solved. But it isn’t. The first plausible description can miss the underlying problem, leaving it unresolved.
What’s happening here?
The social default prompts us to accept the first definition people agree on and move forward. Once someone states a problem, the team shifts into “solution” mode without considering whether the problem has even been correctly defined. This is what happens when you put a bunch of smart, type A people together and tell them to solve a problem. Most of the time, they end up missing the real problem and merely addressing a symptom of it. They react without reasoning.
Many of us have been taught that solving problems is how we add value. In school, teachers give us problems to solve, and at work our bosses do the same. We’ve been taught our whole lives to solve problems.
But when it comes to defining problems, we have less experience. Things are often uncertain. We seldom have all the information. Sometimes, there are competing ideas about what the problem is, competing proposals to solve it, and then lots of interpersonal friction. So we’re much less comfortable defining problems than solving them, and the social default uses that discomfort. It encourages us to react instead of reason, in order to prove we’re adding value. Just solve a problem—any problem!
Treating symptoms can bring immediate relief while leaving the source of a problem in place. Repeated emergencies then consume the time needed to investigate why they keep happening.
The best decision-makers know that the way we define a problem shapes everyone’s perspective about it and determines the solutions. The most critical step in any decision-making process is to get the problem right. This part of the process offers invaluable insight. Since you can’t solve a problem you don’t understand, defining the problem is a chance to take in lots of relevant information. Only by talking to the experts, seeking the opinions of others, hearing their different perspectives, and sorting out what’s real from what’s not can the decision-maker understand the real problem.
Understanding a problem makes it easier to judge which solutions address it, even when choosing and implementing a solution remains difficult.
These two principles follow the example of the best decision-makers:
THE DEFINITION PRINCIPLE: Take responsibility for defining the problem. Don’t let someone define it for you. Do the work to understand it. Don’t use jargon to describe or explain it.
THE ROOT CAUSE PRINCIPLE: Identify the root cause of the problem. Don’t be content with simply treating its symptoms.
I once took over a department where the software would regularly freeze. Solving the problem required physically rebooting the server. (The drawback of working in a top secret facility was our lack of connectivity to the outside world.)
Almost every weekend, one of the people on my team would be called into work to fix the problem. Without fail, he’d have the system back up and running quickly. The outage was small, the impact minimal. Problem solved. Or was it?
At the end of the first month, I received the overtime bill to sign. Those weekend visits were costing a small fortune. We were addressing the symptom without solving the problem. Fixing the real problem required a few weeks of work, instead of a few minutes on the weekend. No one wanted to solve the real problem because it was painful. So we just kept putting out flames and letting the fire reignite.
A handy tool for identifying the root cause of a problem is to ask yourself, “What would have to be true for this problem not to exist in the first place?” Here’s another example of this tool put to use:
The ASPCA is one of the largest animal-welfare groups in the United States. The account cites its estimate that more than 3 million dogs enter shelters each year and are put up for adoption. It reports roughly 1.4 million successful adoptions, leaving more than 1 million not adopted in those figures.fn3
There are only so many people willing to adopt a pet, and only so many pets a given family can handle, so the question facing most shelters is, “How can we get more people to adopt?” More adoptions can help, but that question alone leaves the reasons dogs enter shelters unaddressed.
One shelter took a different approach. The founder of Downtown Dog Rescue in Los Angeles, Lori Weise, asked instead, “What would have to be true for there to be fewer dogs to adopt in the first place?”1 Weise dug into the data and found that 30 percent of dogs entering a shelter were owner surrenders—pets voluntarily given up by their owners. She found that many times caring owners surrendered their pets because they couldn’t afford to feed them and thought someone else could better care for the animal. With this insight, a better and more permanent solution became apparent.
Weise started a new program: Whenever a family came in to surrender a pet, the staff asked if they would prefer to keep the pet. If the answer was yes, the staff used their network to help resolve the problem—whether it was just a matter of a ten-dollar rabies shot, or long-term access to pet food. Weise and her team found that it was actually cheaper to help a family feed and keep a pet than to house it at the shelter. The account reports that 75 percent of families who came in intending to surrender pets were able to keep them instead.
Identifying the root cause of a problem applies in business too. A company might think that its problem is getting too few new sales, so it marshals resources to get new leads. But what if getting new sales isn’t the root of the problem? What if there’s an issue with, say, the product itself? If customers are leaving because the product disappoints them, generating leads alone will not address the cause. Keeping existing customers satisfied may matter as much as acquiring new ones. The way you define a problem changes what you see.
Your defaults are always present, and despite your efforts to follow the Definition Principle and the Root Cause Principle, it’s still possible to get sidetracked.
When to use it
Business: When sales decline, instead of immediately increasing ad spend, investigate if the product meets customer needs.
Personal productivity: alongside immediate relief from stress, examine recurring pressures such as workload, unclear priorities, or interruptions that you may be able to change.
Team leadership: Facilitate problem definition sessions where input is gathered before any solution is proposed.
IT systems: restore service during an outage, then investigate recurring failures so that temporary patches do not become the only response.
FROM THEORY TO EVERYDAY LIFE
In practice
Server Overtime Symptom
Repeated software freezes were handled by physically rebooting the server on weekends, at a growing overtime cost. The account contrasts this temporary remedy with a repair that required weeks of work; it does not specify the technical cause of the freezes.
Downtown Dog Rescue Redefining the Problem
Instead of asking only how to increase adoptions, Lori Weise asked how fewer dogs could end up needing them. The account reports that support such as food and vaccinations cost less than sheltering the pets and helped 75% of families intending to surrender them keep them instead.
The First Problem Definition Trap
A team quickly accepts the first plausible problem statement and jumps to solutions, missing the real underlying issue. This social default leads to solving symptoms rather than root causes.
A MOMENT TO REFLECT
Put it to work.
How can you identify whether you are addressing a root cause or a symptom of a problem?
Recall a time when you solved a problem quickly but it kept recurring. What might have been the real issue?
What processes can you set to ensure you define problems accurately before jumping to solutions?
CONTINUE THE CONVERSATION
Source texts
- Clear Thinking Turning Ordinary Moments into Extraordinary Results (Shane Parrish)