How to write a problem statement in one line

If you have ever tried to fix something and found yourself arguing about what the problem even is, the trouble started with the first sentence. Learning to write a problem statement in one line is the cheapest skill in problem solving. One clear line tells you what to measure, what counts as fixed, and whether you have seen this problem before. This guide gives you a four-part formula, the mistakes to avoid, and three before-and-after examples you can copy.

What a problem statement is, and what it is not

A problem statement describes a gap: what is happening now, next to what should be happening. The Lean Enterprise Institute defines problem solving as "identifying and closing gaps between current and target conditions" (Lean Enterprise Institute, Problem Solving). Your statement names that gap. Nothing more.

It is not:

• A cause. "The printer driver is broken" is a guess about why. You do not know that yet.
• A solution. "We need a new printer" skips the problem and jumps to a purchase.
• A feeling. "Printing is a nightmare" is true for you, but nobody can check it or know when it stops.

Keeping the cause and the fix out of the first line matters because both can be wrong. If they are baked into the statement, you stop looking.

How to write a problem statement in one line: four parts

A useful one-line statement has four parts. You do not need all four for every small problem, but the more you include, the easier the rest becomes.

1. What happens. The thing you can see or hear, in plain words. "The report goes out late", not "the reporting process is inefficient".
2. Where or when. The place, the day of the week, the step in a task. This alone often points at the cause.
3. How much or how often. A count from real days: 3 of 5 mornings, 4 of the last 6 weeks, 2 of 10 runs. If you do not have a count, write down the next few times it happens before you go further.
4. Versus what should happen. The target. "We need to leave by 7:55." Without it, nobody can say when the problem is solved.

The Lean Enterprise Institute asks problem solvers to base everything, starting with "the problem itself", on "verifiable facts, not assumptions and interpretations", and to keep asking "How do you know that?" (Lean Enterprise Institute, Problem Solving). The count in part 3 is how you answer that question in one line.

Five mistakes that make a problem statement useless

• Hiding a cause inside it. "The team is lazy about the report" blames before anyone has looked. Write what happens and let the cause come later.
• Hiding a solution inside it. "We do not have a project tool" is a fix wearing a problem's clothes. Ask what goes wrong without one.
• Making it too big. "Our house is chaos" is ten problems. Pick the one that hurts most this week. Our guide on breaking a big problem into smaller problems shows how to split it.
• Using words nobody can check. "Often", "always", "a mess" and "slow" mean different things to different people. Replace each with a number or a time.
• Writing it for the wrong reader. A statement full of private shorthand will mean nothing to you in three months. Write it so you could search for it later, using the words you would type.

Worked example: three problems, before and after

Here are three made-up complaints rewritten with the four parts. Each sits in a different area of life, which is how Problem Graph sorts problems too.

Each rewrite says what happens, when, how often, and what should happen instead.

1. Personal. "Mornings are a mess" became "We leave home after 8:05 on 3 of 5 school days; we need to leave by 7:55." Now you know the gap is ten minutes or more, on most days but not all. The next question writes itself: what is different on the two good days?
2. Work. "The weekly report is always late" became "The weekly sales report went out after 10:00 on Monday in 4 of the last 6 weeks; it is due by 10:00." "Always" turned out to be four times in six, which is a real problem but not the one people were arguing about.
3. Expert. "The test suite is flaky" became "The checkout test fails on 2 of 10 runs of the same code; it should pass every time." The vague version blamed every test. The one line points at one.

Notice what is missing from all three: no cause and no fix. Those come next, and they come faster because the gap is clear.

Turn the line into your first step

A good statement does three jobs straight away.

• It tells you what to look at. In the morning example, the two good days are the first place to look. Our 5 whys example shows how to dig from a clear statement to a cause you can change.
• It tells you when you are done. If you leave by 7:55 on 5 of 5 days for two weeks, the problem is solved. No debate.
• It becomes the top of a bigger record. The Lean Enterprise Institute describes the A3 report, a one-page problem solving sheet, as starting from "the current situation" and "the nature of the issue" before any countermeasure (Lean Enterprise Institute, A3 Report). Your one line is that opening, small enough to write in a minute.

Once you have the line, write the first thing you will try under it, and later what happened. That is the habit our steps of problem solving guide walks through in full.

Write problem statements in Problem Graph

Problem Graph is a problem and solution journal that draws itself as a map, and it starts exactly where this guide does: with one line.

How it works, from Problem Graph's home page.

• You write the problem down in one line and put it in a lane: personal, work, expert or scientific. It lands on the graph the moment you press Enter.
• Under it, you add solutions as ideas, mark the one you are trying, and record the outcome: worked, partly or failed.
• You link problems that belong together, even across lanes, so the late report and the missed Monday meeting can sit side by side.
• Your problems are private by default: nobody else sees them.
• When other people share problems, Problem Graph shows you similar ones and which of their solutions worked.

Frequently asked questions

How long should a problem statement be?

One sentence is enough for most everyday and work problems. If it needs a paragraph, it is probably several problems, so split it.

Should a problem statement include the cause?

No. Write what happens and what should happen instead. The cause is something you find next, and putting a guess in the statement can stop you from looking.

What if I do not have numbers yet?

Write the line without them, then count the next few times the problem happens. Even "3 of the last 5 times" is far more useful than "often".

Is a problem statement the same as a goal?

Not quite. A goal says where you want to be; a problem statement says where you are now and where you want to be, so the gap between them is clear.

Get started

Pick one thing that annoyed you this week. Write it as what happens, when, how often, and what should happen instead, in one line. Then write the first thing you will try under it.

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try.