CHAPTER 4

Know What Problem You’re Solving

A problem well-stated is a problem half-solved.¹

—CHARLES KETTERING, AMERICAN ENGINEER,
HOLDER OF 186 PATENTS, INVENTOR OF THE ELECTRICAL
STARTING MOTOR, LEADED GASOLINE, AND FREON REFRIGERANT

Extreme poverty is one of the globe’s most important and damaging problems. As a society we have made great progress: In 1990, 37% of the world’s population (or 1.95 billion people) lived on less than $1.90 per day. By 2012, that number dropped to 12.7%, representing 900 million people lifted from poverty using this definition. That’s an incredible change, but there are still almost a billion people living in extreme poverty. And while the modern economy has been a miracle to many regions, such as East Asia and South America, places like sub-Saharan Africa have been largely left behind: 42.6% of people there remain in extreme poverty.

Between individual donors, nongovernmental organizations (NGOs), national governments, and the United Nations, hundreds of billions of dollars have been thrown at sub-Saharan Africa to alleviate poverty through massive infrastructure projects, donations of food or goods, or underpriced loans. But poverty has remained stubborn, and some believe that these aid programs have actually backfired and suppressed growth in high-poverty areas.

Paul Polak started a group called International Development Enterprises, which has brought 17 million people out of poverty by improving their productivity. He believes that those large-scale programs have failed because they were working on the wrong problems. In his book, Out of Poverty, he calls the approaches based on projects, loans, and donations “The Great Poverty Eradication Myths,” and demonstrates quite decisively that they have all failed.²

Polak’s approach to poverty reduction is an example of really incredible problem-solving, and his organization demonstrates many of the behaviors of great problem-solvers. One great example from his book is how he smelled the problem so thoroughly. Instead of attempting to determine from a conference room in New York what solutions poor families needed, Polak has invested the vast majority of his time up-front in smell mode. Polak himself has “talked with over 3,000 poor families,” and “walked with them through their fields” to understand what life was like for them on the ground.³ He understood end-to-end how they acquired seed stock, planted it, cultivated it, harvested it, and brought it to market, in each specific area. He learned the market pressures that each region faced, individually.

Doing this helped him to make a radical breakthrough in understanding the problem itself: The amount and type of crops they produce does not provide enough value for them to escape poverty. By accurately defining the problem of poverty as low labor productivity, Polak was able to focus on improving lives by solving the specific root causes of that low labor productivity in different regions. He had found that most of his clients were one-acre farmers that grew low yields of cheap crops during peak season. To increase the value of their labor, he found that, in each specific market, his clients could instead grow higher yields of higher-value crops in the off-season, where the prices are higher. To do this, they needed a steady supply of more water, so he produced simple irrigation systems powered by foot-driven treadle pumps to supply that water.

It was Polak’s years of smelling the problem, on site, with the families he was trying to help, that enabled him to define the problem correctly and solve it with a cheap, elegant solution that has lifted millions out of poverty.

That’s the difference between knowing what problem you’re working on, and not. Perhaps many aid organizations make assumptions about the problem they are solving, and throw hundreds of billions of dollars at the problem to little or no effect. Polak, by defining the problem correctly, has created an effective, permanent, and self-funding process that continues to bring people out of poverty.

Successfully solving hard problems requires knowing what problem you’re solving. You should put great care into defining the problem in an accurate and precise way, as a direct and measurable observation of the problem. It must be clear how solving it translates directly to your goals. And it must absolutely not be an assumption or jump-to-conclusion.

THE DANGER OF BAD PROBLEM DEFINITIONS

A bad problem definition is a particularly insidious form of guessing. When a “problem definition” is an assumption about the solution, it puts blinders on the problem-solver’s eyes, and they gallop straight toward the entirely wrong cause with unjustified confidence. This leads to investing resources—our time, money, emotional energy—into something that won’t solve our problem at all, or might make it worse.

You may have observed some bad problem definitions in your business or your life. You might have an asset that starts to break or put out bad product at high speeds, and the operators may say that the problem is that “the machine is running too fast.” That’s not a problem: A problem is what’s happening when it runs too fast, and that’s a problem that you can solve. The only way to solve “it’s too fast” is to slow it down, and that prohibits solving the problem at all.

This happens all the time in problems of personal conflict, too. How many times have you heard two people declare that the other one is a jerk, or otherwise badly intentioned? You can’t solve the problem of your colleague or family member being a terrible person. You can solve a problem that involves a misunderstanding, miscommunication, or misalignment.

Great problem-solvers avoid being trapped into solving the wrong problem by defining the problem without prejudice or assumption (see Table 4.1). They define the problem that they see, and in the scope of the measurable or tangible thing that they want. Consider our case of “dinosaur hair”: what the organization wanted was nozzles that didn’t clog, so the nozzle clogging was the problem. By calling it a “dinosaur hair” problem, the company got stuck with a seemingly unsolvable situation that didn’t exist at all.

It’s probable that you and others around you are misdefining problems all the time, and it keeps you from even beginning to solve them. Great problem-solvers keep checking whether they have defined the problem incorrectly by letting assumptions or prejudices creep in.

DEFINING THE PROBLEM AS A VARIABLE

Perhaps the most useful approach for defining the problem well is structuring it as a measurable variable. With this, we view the problem as something we can measure objectively, and we remove the guessed solution and a lot of emotion. We know that we have a problem when this variable is not in the range we want (that is, “out of spec”), and we don’t have a problem once it’s brought into a range that’s acceptable (“in spec”).

Defining the problem as a variable helps us be specific about what the problem really is. If we have insufficient pressure in our shower head, defining the problem as “low water pressure” rather than “a broken shower” immediately sets us on a more helpful path to solving it. Same goes for, “our accountant turnover rate is too high,” rather than “we have an HR problem.” A “low in-full on-time percentage” is a better problem definition than “our distribution network is a mess.” Defining the acceptable and unacceptable ranges for this variable means that the problem definition is objective and immune to opinion.

Without a measurable variable, we might end up taking the wrong approach, even if we’re not guessing. Your friends say they want to be in better shape, but that means different things to different people. One might want to lose weight by reducing body mass, another increase strength by increasing muscle mass, and another increase endurance for a long distance race. You would measure these with different variables, and approach these problems differently.

In some less technical problems, you may not be able to measure the primary variable with as much rigor. For instance, perhaps your problem is “I am too angry in X situations,” and you’ll need to use your judgment to measure anger in a consistent way. So perhaps you just write in a notebook how angry you feel, on a 1 to 10 scale. Developing the skill to do this takes time, but once the behavior is ingrained it will be second nature.

This is like Goldilocks: There’s a porridge that’s too hot and too cold, and we want the one that’s just right.

GETTING A GREAT PROBLEM DEFINITION

In the end, even with a measurable variable at hand, the problem-solver will use the context around them to determine the right way to define the problem they’re working on. Doing this poorly will be frustrating, but doing it well will usually accelerate the team toward quicker victory. As you develop your skills, having a strong problem-solving method to guide you in problem definition will be very helpful. I’ve got some guidance for you to choose a helpful approach in Chapter 10, “How to Choose Your Method.” You may even find that you redefine the problem as you smell it out more. This is fine.

I’ve found that getting a well-defined, measured problem definition can help people understand where a problem exists when they were previously blind to it. Let’s take a look at an issue that many parents encounter: Kids often spend too much time on their electronics. This can end up as a debate that goes a bit like this:

“You’re spending too much time on electronics.”

“YOU DON’T UNDERSTAND ME, DAD!”

Angry stalemate ensues.

This topic came up recently with my eldest son. I’ve gotten to know my son fairly well in the time I’ve been his dad, and I realized that arguing back and forth about how much time was right to spend on electronics was not going to be productive. He’s a smart guy, and coming to him to say, “You’re doing too much of X” without any data wasn’t going to cut it, so I tried another tack.

One day I asked him if he had a personal target for how much time he wanted to spend on electronics per week, because the first level of this problem was that we weren’t aligned on such a target. You can imagine this approach was better received. He thought about it for a bit and gave me a number. I thought this was a little high, but was a step in the right direction, so that problem was quickly solved. We now had a new problem that we were both aligned on—“We don’t know how much time he was using electronics per week”—so we had to measure it.

I suggested he start logging his electronics time so we could see how he was doing versus his target. He came up with the great idea to simply look at the data in his Steam gaming account. He was shocked with what he found, as he was spending far more hours a week gaming than he thought was reasonable. It turns out that a 5-minute traffic jam can feel like an hour and an afternoon on the computer can seem like 10 minutes. Then we were both aligned on the “too much time” problem, which is critical, as he was in the best position to fix it. My son is smart, motivated, and not much interested in self-deception. When he got to grips with this issue, he set a plan in motion to change things. Better understanding of the problem that needed to be solved, and then simply measuring the current state, were enough to help in many ways, including enhancing my relationship with my teenage son!

So how do you know for certain that you have the right problem definition? Ultimately, there’s no recipe for this: It requires skill that you need to develop by practicing this behavior. As we’ve seen in some examples above, sometimes you may miss the mark and have to shift.

Sometimes you’ll get it wrong, and that’s fine. This is a behavior you’re using constantly, so at some point when really smelling the problem you’re going to find that you misdefined the problem, and that’s a moment where you’ve made progress. You learned, and that puts you a step closer. You’ll get better at this with practice. But there are two critical pitfalls to avoid in this process: leaving your scope and making assumptions during the problem definition.

KEEPING IN YOUR SCOPE

I’ve frequently seen teams define problems as too broad or out of their scope. Doing so will confuse the problem-solver or team, and cause delays in one of three ways:

• They consider and study a range of variables that is too wide

• They work on problems that are outside of their power, skills, or authority

• They’re actually running away from the problem in some way

Let us consider almost any problem in a publicly owned business. Ultimately, the goal of the business is some form of socially responsible return to its shareholders. If your team is trying to reduce the business’s carbon footprint, the problem definition for the team is the business’s carbon footprint, not global warming. This is a fairly obvious example, but defining the problem properly keeps the team from wandering into purely academic discussions about the business possibly investing in electric cars or solar power. Similarly, a team tasked with improving supply-chain logistics shouldn’t focus on “business profit,” because it could begin similarly distracting discussions about marketing strategy.

Looking outside of our scope can be a way of running away from a problem. Subconsciously, a problem-solver or team may want to take the heat off themselves, and may point to another business unit that is underperforming, and say, “we should really be focusing there!”

When the price of oil dropped in 2015, I remember many of our petrochemical clients saying that their problem was that the price of oil was low. This is a great example of a problem definition that is too high in the clouds: What could they do to affect it? Go to OPEC meetings and make a persuasive speech? Start an international incident that cuts off the Strait of Hormuz? This is all possible in Hollywood but not practical elsewhere.

A better problem definition is one in the problem-solver’s wheelhouse: They had the ability to control their operating costs. They could all reduce their marginal cost per barrel, reduce their overhead, and improve the value of their capital projects—and focusing there is the only way they could have reliably reduced the pain they and their shareholders felt. As some of my Canadian friends have told me: “There is no such thing as bad weather; just the wrong clothes.” This is particularly important in a commodity business: The slowest impala in the herd is the one that gets eaten, and you can’t run fast when you are busy thinking about things you can’t impact.

Great problem-solvers avoid this by defining the problem as something that’s in their sphere of influence. They understand the context of the problem and how solving it relates directly to those higher-level goals of the business by engaging leadership and those close to the problem and financials.

AVOIDING ASSUMPTIONS

One of the most dangerous—and most pervasive—mistakes when creating a problem definition is letting some assumption about the key drivers sneak in before really understanding the full scope of the problem.

I’ve seen a lot of asset-reliability problems in my time, in which some critical piece of equipment breaks down, and the downtime costs productivity. It could be a conveyor or a computer. I’ve frequently seen the maintenance or IT department focusing on improving response time. So they’ll work on improving their ticketing system, or creating a cart for tools, rather than focusing on overall downtime of the asset and solving the problem that’s making the thing break in the first place. This broad approach can drive some results, though it requires a significant change effort that often erodes with time. However, by looking at it in a one-dimensional way the root cause of the downtime is frequently ignored. Fix the problem!

Many years ago as a young consultant, when I had a little less problem-solving experience, I was working with a food packaging company that made nutritional bars. They were facing an operating loss each quarter, spending more money than they made. The customer liked the product so this business could sell more if they could make it. We were tasked with increasing throughput using the existing assets to meet customer demand. We found the plant bottleneck and were able to greatly increase its output by solving a number of neat problems.

When the monthly results came back, we were a little surprised to see that the plant financials were worse against budget than the month before. This was strange, since the extra production shipped should have improved profit by quite a bit.

We spent a few hours digging through the profit and loss (P&L) details with the plant staff and realized after a while that the business’s total marginal costs were higher than their marginal revenues: They were losing money on every bar they made. The more we made, the more money was drained—something I had not appreciated when we got going on the production problem.

Some further investigation showed that the facility was making the bars overweight. Had we taken the time to learn this before getting to work, we would have worked on this problem first, and been profitable the last quarter. We had worked on the wrong problem, based on a baked-in assumption. Let me tell you, this was painful and a lesson I have taken to heart: Always check that you are operating at the right level and get the facts to confirm that, even when you are not invited to do so!

NOW: KNOW WHAT PROBLEM YOU’RE SOLVING

It’s time to go back to the problem you’re working on and make sure you really know what it is. Clear your mind of prejudices and assumptions, and look to define the problem as something you can objectively measure to determine whether the problem is happening or not.

Ask yourself these questions when considering your problem definition:

• Is it defined as a measurable variable?

• Does it clearly translate to your higher-level goals?

• Is it within your sphere of influence, or are you overreaching and need help?

• Does your definition include any assumptions about what is causing the problem?