The question sounds rhetorical and isn't: the two paths bring different documents into the meeting and produce different decisions.
When someone is asked to put a problem in writing, something else almost always ends up on the page: the goal to reach, the visible effect, or the intervention already chosen.
A problem statement is the written description of a gap: what is happening, where and since when, how much it's worth, who bears the effect, and what lies outside it.
The step applies to a professional with two team members, to a fifteen-person family business and to a hundred-person organization: what changes is who holds the pen, not the temptation to skip it.
In 2022, 80.9% of Italian companies with at least three employees were controlled by one person or one family [5]: the person who sees the problem and the person who decides the intervention are often the same, and the written statement is the point where the two come apart.
A well-written problem doesn't say what you want to achieve or who got it wrong: it measures the distance between how the work is going and how it should be going, and states where it stops.
This article walks through the three swaps that empty a problem statement, the five elements that make it verifiable, the four steps to write it, three before-and-after rewrites, the test that closes it, and the most common mistakes.
What a problem statement puts in writing, and what to keep it apart from
Is writing what isn't working the same act as writing what you'd like to achieve?
It isn't, and to notice it you only need to reread the line you just wrote: if it contains a future-tense verb or an action to launch, that line doesn't describe the problem.
A problem statement is the written description of a gap: what is happening, where and since when, how much it's worth, who bears the effect, and what lies outside it.
The verb already states the work it asks for: define comes from the Latin definire, "to limit," derived from finis, "boundary" [6].
To define is to determine by setting limits, as in the phrase "to define precisely the terms of a question" [6].
In everyday use, "problem" means any situation that presents difficulties, obstacles or drawbacks to deal with [7]: it's the broad word, and the statement is the act that narrows it.
The distinction that matters isn't with opposites, which are easy to spot, but with the four things that take the problem's place at the moment of writing.
It isn't the goal, which says where you want to get, not what keeps you from being there already.
It isn't the visible effect — the complaint, the reminder call, the emergency meeting — which signals the problem without saying where to look.
It isn't the cause, which is the result of the analysis and not its starting point.
It isn't the request for intervention, which often arrives phrased as a lack and already names the answer.
The value of this distinction has a long history: "a problem well put is half-solved" is how Dewey, in 1938, opens his analysis of inquiry, adding that getting the problem wrong makes all the inquiry that follows irrelevant or off track [1].
The act that comes before the statement is noticing that a problem exists, and it's covered in problem finding; the act that comes after is the search for causes.
When there are many known problems and the question is which one to start with, the choice is made before writing, ranking them by weight with the Pareto chart: the statement then covers a single item.
The technical name for the intermediate phase is problem setting (short definition in the glossary): the problem statement is what that phase produces.
With the gap written down, it remains to understand why something else ends up on the page.
Goal, effect, intervention: the three swaps that empty a problem statement
On a sheet that asks you to write the problem, what actually gets written?
Usually one of the three things the problem is not, and the swap happens without the writer noticing.
A well-written problem doesn't say what you want to achieve or who got it wrong: it measures the distance between how the work is going and how it should be going, and states where it stops.
The swap has a measured root: in Nutt's study of 356 decisions made in medium-sized and large organizations in the United States and Canada, 37% of cases started from a ready-made idea, treated as a direction to impose, and the responses born this way were fully adopted in 42% of cases [2].
In more than 26% of cases the starting point was instead a problem definition, but the author observes that the definition is often hasty and misleading: symptoms get analyzed while more important issues are left out, and the full adoption rate stops at 44% [2].
The European Commission's methodological guidance for impact assessments names the same swap as the most common mistake: concluding that a problem exists because a tool, a regulatory framework or a database is missing — when those "lacks" are possible responses to a problem that hasn't been defined yet [3].
The same guidance also has a name for the second move, backward engineering: an analysis conducted with the intervention already chosen in mind, which comes out confirming it because that was the starting point [3].
The three swaps can be recognized by the shape of the line, even before its content.
| The swap | How it sounds | Why it doesn't hold up | How to recognize it |
|---|---|---|---|
| The goal in place of the problem | "get on-time deliveries to 95% by June" | it says where you want to get, not what keeps you from being there | the line contains a numeric target and a future-tense verb |
| The effect in place of the problem | "customers are complaining" | it's the visible consequence: whoever reads it doesn't know where to look | the line names a reaction — complaint, reminder, return — rather than a measurable internal fact |
| The intervention in place of the problem | "we lack a management system," "we need more training" | it's already an answer, and it closes the search before opening it [3] | the line starts with "we lack," "we need," "we have to" |
The cost of all three swaps is the same: the analysis starts from a sentence that can't be checked, and so it produces conclusions that can't be checked.
Whoever reads the line a month later, or in another department, finds an intention rather than a fact.
The remedy isn't writing more: it's writing the right elements.
The five elements of a problem statement, one by one
What separates a line you can check from a line you can only comment on?
Five elements, and their absence is visible to the naked eye: where the number is missing, an impression remains; where the boundary is missing, a debate remains.
The elements aren't an editorial invention.
The problem framing tool the Asian Development Bank uses in the projects it supports asks for four pieces of information: the areas affected, the value of the impact, quantified where possible, the period over which the problem has persisted, and how often it occurs [4].
The European Commission guidance adds the target, meaning who is affected by the problem and who produces it through their behavior, and asks for the current situation to be described before any proposal [3].
The fifth element — what the problem is not — is the one the etymology of the verb define calls for on its own [6], and it's also the one companies write down least.
| Element | The question it answers | What it looks like once written |
|---|---|---|
| 1. Who is affected | who bears the effect, who produces it, who would need to change something [3] | "the two customers who pick up on a fixed schedule" instead of "the market" |
| 2. Current situation and desired condition | how things are going today, how they should go according to a rule, an agreement or a template | "inspection is done on 6 parts out of 10; the template calls for 10 out of 10" |
| 3. Where, when, how much | in which stretch of the work, in what period, how often [4] | "at the packaging line, over the last three months, 9 times in 60 batches" |
| 4. Impact | what the gap costs in hours, delays, rework or money [4] | "about 9 hours of rework and two rescheduled deliveries" |
| 5. What the problem is not | which nearby facts stay outside the scope | "it doesn't concern catalog orders, which follow a different flow" |
Causes don't appear on the list, and that's a boundary choice: the same European guidance treats them as the next step of the analysis, after the problem has been established [3].
If you write the cause into the statement, you get an analysis that confirms the cause you already wrote.
The fifth element deserves an extra line because it's the one that saves the most time.
Stating what stays out keeps the next meeting from widening to everything that resembles the problem, and lets whoever searches for causes know when they're drifting away.
The same element, taken to its most formal degree, is the "is / is not" template of the Kepner-Tregoe method: there the scope is built column by column, while here a single line stating what stays out is enough.
The template is compact by design: five lines, not a page.
The next step is putting them in the order in which they actually get written.
How to write a problem statement in four steps
Who writes the statement, and how much time does it really take?
It's written by whoever holds the decision, and in owner-run businesses that's both the advantage and the risk.
In Italy, for example, in 2022 there were 826,953 companies with at least three employees controlled by an individual or a family, 80.9% of the total, and in these businesses management was entrusted to an internal or external manager in only 1.4% of cases, falling to 0.8% among those with 3 to 9 employees [5].
The advantage is that there are few steps between whoever sees the problem and whoever decides: a business owner in a machining company who splits time between the office and the shop floor can write the statement the same day the event occurred.
The risk is the other side of the same coin: whoever decides comes to the page with the intervention already in mind, and the statement risks being born as a justification.
The four steps exist to keep the two apart.
- Gather facts before sentences. The documents that already exist are enough — work reports, inspection templates, delivery notes, payment schedules, complaint records — plus three weeks of observation, not three months.
- Write the first version in a single sentence, in the present tense, with no names of people and no future-tense verbs: the first version is usually vague, and should be treated as a draft to validate against the data gathered [4].
- Add the coordinates: scope, period, frequency and value of the impact, with the figures obtained in step 1 [4].
- Draw the boundaries and have the people who do the work reread it, stating what stays out; if the data contradict the statement, the statement changes, not the other way around [4].
The reread by the people who do the work isn't a formality: the guidebook used in projects supported by the Asian Development Bank recommends looking for other ways to state the same problem, because word choice changes the perspective of whoever will read it [4].
When the problem crosses two departments, the statement is written by the one that bears the effect downstream and reread by the one that produces it upstream; the case where more than two departments are involved belongs to organizational problems, which need a map before they need a template.
Writing time is twenty to forty minutes, excluding fact gathering: it's an editorial rule of thumb, not a measured figure.
The sheet stays minimal — a problem template with five lines and an evidence column next to each — and it's worth as much as the facts it contains.
How a line changes as it goes through these four steps is easier to see on a case.
Three problem statement examples, before and after the rewrite
Does the same sentence rewritten with five elements produce the same meeting?
It produces a different meeting, because it shifts the discussion from opinions to the documents you need to go get.
The three cases below are hypothetical and built for this article: they're meant to show the procedure, not to estimate a result.
Case 1 — family-run machine shop, 22 employees.
Before: "deliveries are running slow."
Everything that could be checked is missing: how many deliveries, in what period, for which customers, with what effect.
After:
Over the last three months, 14 of 96 orders shipped after the confirmed date, with an average delay of four days; the effect falls on the two customers who pick up on a fixed schedule, who have rescheduled two pickups. It doesn't concern subcontract work, which runs on a different flow.
Case 2 — professional practice, three people.
Before: "clients keep calling to find out where we are."
The line describes an effect — the phone call — and leaves out the internal fact that produces it.
After:
Over the last eight weeks, 31 of 54 files went more than ten days past the deadline communicated to the client at engagement, and in 22 cases the client called before an update arrived. Files waiting on documents from the client, tracked separately, are excluded.
Case 3 — purchasing office of a 60-person company.
Before: "we need a new management system."
Here the line doesn't describe a problem but names an intervention, and it's the case the European guidance flags as the most common mistake [3].
After:
In the first half of the year, 37 of 210 orders were issued at a price different from the last agreed price list, for a total discrepancy of about €11,000; the figure comes from comparing orders with signed price lists. It doesn't concern off-contract purchases, which are authorized individually.
The three rewrites share the same shape: a counted fact, a period, a scope, an effect and a boundary line.
The three rewrites don't name a person and don't name an intervention.
The time between "before" and "after" isn't writing time but gathering time: the figures come from documents the company already had.
At this point the statement is ready for the search for causes, which begins where this page ends — with the 5 whys technique when the chain is linear, with the Ishikawa diagram when there are many plausible causes.
Before moving on to causes, though, it pays to check that the statement holds up.
The five-question test to see if the statement holds up
When can a problem statement be considered finished?
When two people who weren't present at the events read it and understand the same thing, and when every line can be checked against a document or a number.
The test is five questions, asked out loud over the sheet you just wrote.
- Does every claim have evidence you can reach within the day? The European Commission guidance observes that problems and their causes are often not backed by tangible evidence, and that stakeholder opinions are a particular kind of evidence, to be used with caution because they reflect interests [3].
- Is there a number and a period, or are there still adverbs like "often" and "lately"?
- Does the line describe an internal fact or an external reaction?
- Does a person's name appear, or the point in the work where the event happens?
- Is it stated what stays out?
If an answer is missing, the statement isn't wrong: it's incomplete, and the step to redo is the first one, fact gathering.
The stopping rule is the absence of new information: when one more question doesn't change the line, the statement is closed and the work moves on to the search for causes.
The reverse also holds, and it's the part that costs most: if during the analysis the data contradict the statement, the statement gets rewritten [4].
The reason this check pays off is as old as the study of inquiry: the way the problem is conceived decides which hypotheses are considered and which are dismissed, which data are selected and which are rejected [1].
A narrow, verifiable statement doesn't make the search for causes easier: it makes it possible, because it shows where to look.
From here the work changes tools, and the available methods are compared in the guide to business problem solving; when the question becomes "why is this happening," the next step is root cause analysis.
What remains are the mistakes that empty a statement even when the procedure has been followed.
The most common mistakes in defining a problem, and how to avoid them
Can a statement respect the form and still be unusable?
It can, and it happens for six recurring reasons, recognizable from the written line even before the outcome.
A person's name inside the statement. Nutt's study observes that those inclined to frame everything as a problem fail to see that problems invite blame: team members' energy shifts from looking for answers to defending their own position [2].
The fix is to replace the name with the point in the work where the event happens — not "the operator doesn't check," but "at product changeover, no step confirms the parameter."
The statement with no number. "Often," "lately," "too many times" describe the speaker's feeling and change meaning from one person to the next.
The fix is to count for three weeks on a document that already exists before rewriting the line.
The scope that keeps widening. "Internal communication isn't working" isn't a statement but a family of problems.
The fix is what the European guidance calls decomposition: breaking a complex problem into simpler problems that can be tackled separately, while stating the links between them [3].
The statement written after choosing the intervention. This is the backward engineering already mentioned: the analysis confirms the choice because that's where it started [3].
The fix is to date the sheet and have the statement come before any quote.
The claim without evidence. A line no document can confirm can't be disproved either, and the same guidance asks for tangible evidence, gathered with verifiable methods from neutral sources [3].
The fix is the evidence column next to each line of the template: where evidence is missing, the line is a hypothesis.
The statement that never gets updated. The first version is vague by design, and treating it as closed means carrying the error into the analysis [4].
The fix is the second version, written after the data have been gathered and dated.
The six mistakes share one trait: they save ten minutes of writing and cost much more in the search for causes, where you end up working on a line that can't be checked.
When the statement concerns a deviation from a written rule or a specification, the formal register it ends up in is nonconformity management.
Limits and conditions of applicability
The decision study cited here covers 356 decisions made in medium-sized and large organizations in the United States and Canada, observed up to 1999 [2].
Its numbers describe a method risk — the hasty definition, the intervention chosen first — not a frequency measured in Italian companies.
The European Commission guidance [3] and the guidebook used in projects supported by the Asian Development Bank [4] were developed for public policy and development cooperation projects: the writing criteria transfer, the scales and consultation procedures don't.
The three before-and-after cases are hypothetical and built for this article: the figures are there to show the shape of the rewrite, not to estimate results.
A well-written statement doesn't by itself reduce how often an event occurs: it makes possible the analysis that reduces it, and the outcome is verified later.
When what's happening is an emergency — safety, a line stoppage, a blocked delivery — you contain first and define afterward: the order is reversed for practical reasons, not because the statement is less useful.
FAQ
What is a problem statement?
It's the written description of a gap between how the work is going and how it should be going, with scope, period, frequency, impact and boundaries.
It serves to make checkable against documents what would otherwise remain a shared impression.
What's the difference between a problem statement and a goal?
The goal states where you want to get; the problem statement describes what keeps you from being there already.
Written together they blur: the European guidance for impact assessments flags the "lack of" a tool as precisely the most common mistake, because that lack is a possible answer and not a problem [3].
How do you define a problem in a single sentence?
With a present-tense sentence that contains the counted fact, the period, the scope and who bears the effect, with no names of people and no future-tense verbs.
A one-line problem statement example: "over the last three months, 14 of 96 orders shipped after the confirmed date, with an average delay of four days, and the effect falls on the customers who pick up on a fixed schedule."
What's the difference between problem setting and problem solving?
Problem setting gives the problem its shape — scope, measure, target — and produces the statement; problem solving chooses among alternatives and checks the outcome.
The problem setting glossary entry gives the short definition, while the distinction among the three acts is developed in problem finding.
Practical summary
A problem statement starts from facts gathered from documents the company already has, not from sentences spoken in a meeting.
The first version is written in a single sentence, in the present tense, with no names of people and no future-tense verbs.
The coordinates are added to the sentence: the stretch of work involved, the period, the frequency and the value of the impact.
Then you state what stays out, because the boundary is the part that saves the most time in later meetings.
The finished line is read to the people who do the work, and rewritten if the data contradict it.
The closing test is five questions: reachable evidence, number and period, internal fact rather than external reaction, point in the work rather than a person's name, stated boundaries.
When one more question doesn't change the line, the statement is closed and the work moves on to the search for causes.
Conclusion
Defining a problem isn't the prelude to the work: it's the part of the work that decides everything else, because it measures the distance between how the work is going and how it should be going and states where it stops.
Five elements, four steps and a five-question test: the procedure fits on one page, and the time it takes is almost entirely fact-gathering time, not writing time.
The three rewrites on this page apply unchanged to a practice with two team members and to a twenty-person machine shop, because the elements to put in writing don't depend on the industry.
When the problem has yet to be noticed — because the signals are there but haven't been named — the step before is problem finding.
When instead the line is written and the question becomes "why is this happening," the map of available methods is in the guide to business problem solving, and the search proper begins with root cause analysis.
After a few months of statements written this way, the meeting changes subject: you discuss what the documents say, not what each person remembers.
The time once spent reconciling different versions becomes available again.
And analyses that start from a verifiable line stop leading back to the starting point, because they point to a place in the work where you can intervene.
Sources and references
[1] Dewey, J., "Logic: The Theory of Inquiry", Henry Holt and Company, New York, 1938, ch. VI "The Pattern of Inquiry", p. 108. Full text consulted on Internet Archive: https://archive.org/details/JohnDeweyLogicTheTheoryOfInquiry
[2] Nutt, P. C., "Surprising but true: Half the decisions in organizations fail", Academy of Management Executive, vol. 13, no. 4, 1999, pp. 75-90, DOI 10.5465/AME.1999.2570556 (study of 356 decisions in medium-sized and large organizations in the United States and Canada). Publisher's page: https://journals.aom.org/doi/10.5465/AME.1999.2570556 — full-text copy consulted at: https://cebma.org/assets/Uploads/Nutt-1999-gecomprimeerd.pdf
[3] European Commission, "'Better regulation' toolbox", December 2025 edition, Tool #13 "How to analyse problems", pp. 90-93. Available at: https://commission.europa.eu/law/law-making-process/better-regulation/better-regulation-guidelines-and-toolbox_en — PDF: https://commission.europa.eu/document/download/9c8d2189-8abd-4f29-84e9-abc843cc68e0_en?filename=BR%20toolbox%20-%20December%202025.pdf
[4] Asian Development Bank, "Problem Solving: Guidebook for ADB-Assisted Projects", Mandaluyong City, 2016, "Tool 1c: Problem Framing Tool", pp. 17 and 26, ISBN 978-92-9257-329-4 (PDF). Available at: https://www.adb.org/sites/default/files/institutional-document/180614/problem-solving-guidebook.pdf
[5] ISTAT, "Censimento permanente delle imprese 2023: primi risultati", press release, November 14, 2023, Table 2, p. 4 (reference year 2022; 826,953 companies with at least 3 employees controlled by an individual or a family, equal to 80.9%; managerial leadership in 1.4% of these individually or family-controlled companies and 0.8% among those in the 3-9 employee class). Available at: https://www.istat.it/comunicato-stampa/censimento-permanente-delle-imprese-2023-primi-risultati/ — PDF: https://www.istat.it/it/files/2023/11/REPORTCensimprese.pdf
[6] Treccani, "definire", Vocabolario on line, Istituto della Enciclopedia Italiana. Available at: https://www.treccani.it/vocabolario/definire/
[7] Treccani, "problema", Vocabolario on line, Istituto della Enciclopedia Italiana (sense 3.a). Available at: https://www.treccani.it/vocabolario/problema/