Define a Problem Worth Solving

You just saw where the course is heading. Now we take the first real step of the method, and it is the one almost everyone skips: saying clearly what the problem actually is. Get this right and everything after it, finding the cause and mapping the system, gets easier. Get it wrong and you spend your energy solving the wrong thing. In this chapter you will learn to tell a real problem apart from a vague complaint, and to write it down in a structure you can reuse on any problem you meet.

What Makes a Problem Different from a Complaint?

We complain all the time, and complaining can feel a little like naming a problem. It is not. A complaint is an expression of frustration: “this is a mess,” “nothing ever works here,” “it’s so annoying.” A problem, in the sense we will use all course long, is something more precise: a specific, observable, bounded thing you can actually work on.

Two plain tests separate the two.

The first test checks whether something is observable, meaning you could point to it happening in the real world. Ask: could someone else watch it happen? “The room is a disaster” is a judgment; no one can watch “a disaster.” “Finished laundry is left sitting in the machines for hours” is observable; anyone standing there could see it.

The second test checks whether something is bounded, meaning it has a clear edge, so you know what counts as part of the problem and what does not. Ask: do you know what’s in and what’s out? “Everything about our building is broken” has no edge; it could mean almost anything. “The four shared washing machines on the ground floor” has an edge you can point to.

A complaint fails both tests. A problem passes both. That is the whole distinction, and it is the difference between spinning your wheels and getting somewhere.

Why Does Jumping Straight to a Fix Backfire?

When something bothers us, the natural urge is to fix it right now. The laundry room annoys you, so you print an angry sign and tape it to the door. It feels productive. A week later, nothing has changed.

The trouble is that a fix chosen before the problem is defined is really just a guess. You are reacting to whatever caught your attention first, which is usually a symptom, not the thing actually causing the trouble. So you spend real time, effort, and sometimes goodwill on a solution, and the problem quietly comes back, because you never touched what was producing it.

Defining the problem first is not slower in the end. It is the thing that stops you from solving the wrong problem twice.

What Are the Four Parts of a Problem Statement?

Once you can tell a problem from a complaint, you write it down as a problem statement: a short, structured description that anyone could read and understand the same way. A good one has four parts.

• The felt pain and who has it. What actually hurts, and who notices it? The people affected by a problem are its stakeholders, meaning anyone who feels the problem or has a say in it. Naming them keeps the problem grounded in real experience.

• One specific statement. A single sentence, passing the observable test, that says what is happening. Not three problems bundled together, just one.

• The scope. The scope is the edge of the problem: what is inside it, and what is deliberately left outside. Stating what is out is as useful as stating what is in, because it stops the problem from quietly growing.

• What a good response must achieve. A plain description of what any decent solution would have to do, so you can later tell whether a fix actually worked.

Reuse This Problem-Statement Frame

You do not have to invent the structure each time. Here is a fill-in frame that carries all four parts. Copy it into whatever you write in, and complete each blank.

This is the same structure you will reuse whenever you define a problem, so practicing it here builds a habit you can apply anywhere. Fill it in loosely first, then tighten each blank until it passes the observable and bounded tests.

Turn One Gripe into a Workable Statement

Let us take one everyday gripe all the way through, from a vague grumble to a statement you could act on.

The gripe. In a small apartment building, a resident says: “The shared laundry room is a disaster and nobody cares.”

Make it observable. “A disaster” and “nobody cares” are judgments, not things you can watch. What can you actually see? Finished loads left sitting in the machines long after the cycle ends, so the machines stay occupied. That is observable.

Give it an edge (bounded). In scope: the four shared machines on the ground floor and the residents who use them. Out of scope: the building’s paid weekly cleaning, and laundry people do inside their own flats. Now the problem has a clear edge.

Write the four-part statement. Putting it in the frame:

Residents who need to wash experience blocked machines when other people leave finished loads sitting in the machines for hours; in scope: the four shared ground-floor machines and the people who use them; out of scope: the building’s paid weekly cleaning; a good response must get finished loads out of the machines promptly and keep them usable, without adding cost.

Compare that with where we started:

• Weak: “The laundry room is a disaster and nobody cares.” It names no one, describes nothing observable, has no edge, and sets no target.

• Strong: the framed statement above. It names the stakeholders, states one observable thing, sets a scope, and says what success looks like.

Same annoyance, two completely different starting points. Only the strong one tells you what to investigate next.

Your Turn!

Now work on a fresh gripe, using the one above as your model.

Scenario. A parent grumbles: “Pickup at school is total chaos every afternoon and it stresses everyone out.”

Your task. 1. Rewrite this gripe as a workable problem: something observable and bounded. Say what someone could actually watch happening, and set a clear scope (what is in, what is out). 2. Draft a four-part problem statement using the frame from this chapter: who has the felt pain, one specific statement, the scope, and what a good response must achieve.

Write it in your own working document, and do the thinking yourself. Turning a vague gripe into a defined problem is the exact skill this course is building, so resist the urge to hand it to an AI tool to write for you.

Then check your answer against the model solution found at the end of this chapter.

Let’s Recap!

• A complaint expresses frustration; a problem is a specific, observable, bounded thing you can work on.

• Two tests tell them apart: could someone else watch it happen, and do you know what’s in and what’s out.

• Jumping to a fix before defining the problem usually solves the wrong thing, so define first.

• A problem statement has four parts: the felt pain and who has it, one specific statement, the scope, and what a good response must achieve.

• Stating what is out of scope matters as much as stating what is in, because it stops the problem from quietly growing.

With a clear, bounded problem in hand, the next question is what is really causing it. In the next chapter, you will dig past the symptom you first noticed and trace the problem down to its root cause.

Model Solution

Here is one strong way to handle the school-pickup gripe. Yours does not need to match word for word; it needs to pass the same tests.

Made observable. What someone could actually watch: in the half hour after the bell, cars queue from the school gate back into the main road, children wait outside past dismissal, and some parents double-park to get closer.

Given an edge (bounded). In scope: the school gate and car line during the after-bell pickup window (roughly 3:15 to 3:45), and the families and staff involved. Out of scope: the morning drop-off, and the town’s wider traffic planning.

Four-part problem statement.

Families and staff at afternoon pickup experience long, unsafe queues when the pickup line backs up from the gate into the main road during the after-bell window; in scope: the gate, the car line, and the roughly 3:15 to 3:45 window; out of scope: morning drop-off and the town’s wider traffic plan; a good response must clear the line safely within the window without needing paid traffic wardens.

Compare that with the weak version, “pickup is chaos and it stresses everyone out”: it names no one specific, describes nothing you could watch, has no edge, and sets no target. The framed version tells you exactly what to look into next.