Problem Statements That Survive Review

A problem statement has one job: let a reader agree the problem is worth solving before they know what you plan to build.

Plenty of them fail that job without being badly written. "Users find permissions confusing" is clear, plausible and impossible to disagree with, which is exactly what is wrong with it. A statement nobody can disagree with cannot be checked, and a problem that cannot be checked cannot be held against the solution later.

A reviewer will ask four questions of it: whose problem, how often, what does it cost, and how do you know? Treat each as a test. Below, each one has a failing and a passing version. All of the examples are illustrations, built around one invented feature so you can watch the statement improve.

Before the tests: is it a solution in disguise?

One check comes first, because it disqualifies a statement before the tests apply.

State the problem without naming the feature. "Admins need a bulk permissions editor" cannot be stated that way; take the editor out and nothing is left. It is a solution looking for a justification. "Admins set the wrong permissions on new projects and fix them by hand" survives, because it describes something that happens today whether or not you build anything.

If the statement fails this, the four tests below are measuring the wrong sentence. Rewrite first.

Test 1: Whose problem?

Fails: "Users find permissions confusing."

Passes: "Workspace admins at accounts with more than one team, setting permissions on a new project for the first time."

"Users" describes everyone and therefore designs for no one. The passing version names a role, a kind of account and a moment. The moment matters most, because it is what the design will have to detect and respond to.

The check: could two engineers picture the same person in the same situation? Could you find ten of them in your data by Friday? If not, the "who" is still a demographic rather than a situation.

Test 2: How often?

Fails: "This happens a lot."

Passes: "In August, 30% of new projects at multi-team accounts had their permissions changed within 24 hours of creation."

The passing version has a number, a population, a period and, quietly, a definition: a permission change within 24 hours counts as a mistake. That definition is a choice, and a different choice can move the number a long way.

Our briefing on problem definition covers a study where the same phone-use data gave three different answers depending on what counted as the problem. With the authors' example thresholds, it was 51.4% of sessions when it was defined by behaviour alone, 28.3% by stated intention alone, and 14.9% when it was the gap between the two. Same people, same two weeks.

The check: write the definition next to the number, the same way you would write counting rules for a metric. If a reasonable colleague would define the problem differently and get a very different figure, say so in the statement.

Test 3: What does it cost?

Fails: "This creates a frustrating experience."

Passes: "About a third of these corrections follow a support ticket. Admins in interviews put the clean-up, re-sharing files one by one, at 20 to 40 minutes each time."

Frustration is real, but it cannot be compared with anything. A cost in units can: minutes, tickets, money, renewals at risk, a compliance exposure. Cost to the user and cost to the business are separate lines, and a statement with both is stronger than one with either.

The check: could someone put this cost next to the cost of building the fix and decide? If the cost is written in adjectives, they cannot, and the decision will be made on enthusiasm instead.

Test 4: How do you know?

Fails: "Customers have told us this is a major pain point."

Passes: "Sources: project permission logs for August; 41 tickets tagged 'permissions', June to August; five admin interviews, all from accounts that had filed one of those tickets. The frequency is measured; the time cost is self-reported."

This is the reviewer's first question for good reason. Who asked for this, and how do you know? The passing version answers it, and it also says which parts are measured and which are what people said. That distinction is the subject of the evidence section: a citation tells a reader a source exists, not how much weight it can carry.

The check: could a reviewer find each source in under a minute, and tell what was observed from what was concluded?

All four, together

The problem statement as it often arrives:

Permission management is a major pain point for our users. Customers frequently tell us it is confusing, and it creates a poor experience. We should redesign the permissions screen.

It fails all four tests, and its last sentence is a solution.

The same problem, rewritten:

Workspace admins at multi-team accounts set permissions when they create a project, and often get them wrong. In August, 30% of new projects at those accounts had a permission change within 24 hours of creation (logs; a change in that window is our definition of a mistake). About a third of those changes followed a support ticket (41 tickets, June to August). In five interviews, admins put the clean-up at 20 to 40 minutes each time (self-reported). Unknown: whether single-team accounts have the same problem. Their logs show fewer changes, but they also have fewer people to notice.

Two things to notice. The rewrite never mentions a redesign; the solution gets its own section, as an answer to this one. And it contains the word "unknown". That line is not a weakness. It tells the team where the evidence stops.

What review does with a statement that passes

A problem statement that survives these tests becomes the thing the rest of the spec is checked against. Does the solution help the person named in test 1? Will it reduce the frequency, under the definition in test 2? Does the success metric measure the cost in test 3?

When the answer is no, that is a blocker rather than a style note. A spec whose problem and solution describe different things is the case a reviewer should raise first.

It is also the earliest defence against the well-formed wrong thing. A coherent spec built on a false premise passes every structural check, and the problem statement is the premise, written down where someone can test it.

A note on "why now"

The sections that earn their place pair the problem with why now: what changed to make this the moment. It is not one of the four tests, because a problem can be real and still not be urgent. But if the statement passes all four and nobody can say what changed, ask whether the problem was just as true a year ago, and what made it wait.

FAQ

What makes a good problem statement? A named person in a named situation, a frequency with its definition, a cost in units, and a source.

Is it a solution in disguise? State it without the feature. If nothing is left, it is.

How long? One short paragraph, with the evidence linked.

Numbers? Where you have them, with definitions. Where you don't, write "unknown".