I've sat in a lot of rooms where someone has written a problem statement on a whiteboard and everyone nods, and then six months later the project has quietly drifted into solving something completely different. That's not a planning failure, usually. It's a language failure. The problem statement was written in a way that let everyone agree without actually agreeing. It felt like alignment but it was just shared ambiguity. I've been doing diagnostic work across public agencies, mid-size private companies, and a few nonprofits for long enough now to notice that the organisations who get this right tend to use a surprisingly specific kind of sentence structure — and the ones who get it wrong tend to make the same three or four mistakes. This piece is my attempt to write down what I know, with the caveat that I'm still refining this and would not claim it's a complete theory.
why most problem statements are decorative ¶
The honest answer is that most problem statements are written to end a conversation, not to start useful work. Someone in a leadership meeting gets uncomfortable with ambiguity, asks for a problem statement, and a week later a document arrives with a sentence like 'we need to improve customer satisfaction across our service channels.' Everyone signs off. The sentence is not wrong exactly, but it does no work. It doesn't tell you what to look at first, what success looks like at a granular level, or where the boundary of the problem is. It's a flag planted in fog. I think the reason this happens is that writing a genuinely clear problem statement requires you to say something contestable — and contestable things are uncomfortable to put in front of senior stakeholders. So the language gets softened until it's safe, and safe language is usually useless language.
the structural test I use before anything else ¶
Before I look at the content of a problem statement, I apply a quick structural test. I ask: can I find the who, the what, the where or when, and the consequence? Not as a checklist template — I'm not a fan of fill-in-the-blank frameworks — but as a diagnostic. If any of those four things are absent or vague, the statement is probably decorative. Take this example I encountered in a local government housing team: 'There are challenges in the allocation process that affect residents.' Four things wrong. No specific population of residents. No specific stage of the allocation process. No timeframe. And 'challenges' is doing enormous epistemic lifting with no evidence behind it. Compare that to: 'Households in Band C are waiting an average of 14 months for a first offer, against a policy target of 9 months, and around 40 percent of those offers are refused — which resets the clock.' That's still not a complete problem statement, but it's the beginning of one. It tells you where to look.
the language patterns that create false alignment ¶
There's a family of words I've started mentally flagging whenever I see them in a problem statement draft. Words like 'improve', 'optimise', 'enhance', 'streamline', 'better', and 'inefficient'. I call these consequence-avoiders. They gesture at a direction without committing to a claim. 'We need to streamline the onboarding process' sounds precise because 'streamline' is a technical-feeling word, but it contains no information about what the process currently does, who it fails, or what streamlined would look like when achieved. The other pattern I see constantly is the use of passive constructions to hide disagreement. 'It has been identified that...' or 'concerns have been raised about...' — these are ways of noting that something is contested without making anyone responsible for the claim. When I see passive voice in a problem statement, I now read it as a signal that the room hasn't finished arguing yet, and the document is papering over that.
what the sentence structure of a usable problem statement actually looks like ¶
After a lot of iteration across different client contexts, the structure I come back to most often is something like: [specific group] is experiencing [specific observable condition] because of [hypothesised mechanism], and this matters because [consequence for the organisation or its stakeholders]. The hypothesised mechanism part is the one people resist most. They don't want to commit to a cause before they've done the analysis. But I'd argue you have to put a hypothesis in there — clearly labelled as a hypothesis — otherwise the problem statement gives you no grip. It doesn't tell you what to investigate. One thing I learned from a diagnostic engagement with a mid-size logistics firm: they had a beautiful problem statement that described the symptom in forensic detail but contained zero hypothesis about cause. The team spent four months collecting data that confirmed the symptom they already knew about. The hypothesis is the rudder.
the alignment meeting you actually need to run ¶
Writing a good problem statement is not a solo task you do before the meeting. It's a thing you arrive at through a specific kind of conversation. The exercise I find most useful is to put a draft in front of the key stakeholders and ask two questions separately: first, 'what does this leave out that you think is important?' and second, 'what does this include that you'd push back on?' I keep them separate because inclusion and exclusion feel psychologically different, and people are more willing to name disagreement through the second question. I ran a version of this with a central government policy team earlier this year. We had six senior people in a room, and by asking those two questions in sequence we surfaced a genuine disagreement about whether the problem was located in the policy design or the implementation — a disagreement that had been politely invisible for months. The problem statement draft didn't survive the meeting, but the project got a lot better.
boundary conditions: the part almost everyone skips ¶
A problem statement isn't complete without some explicit boundary-setting — what is in scope and what is deliberately not. I know that sounds like project management boilerplate, but I mean something more specific. The boundary I care about is epistemic: what are you claiming to understand, and what are you flagging as genuinely uncertain? The best problem statements I've seen include a short sentence like 'we don't yet know whether this is driven by X or Y — that's one of the things this work needs to establish.' That kind of epistemic honesty changes the culture around a project. It stops people from defending a false certainty they were never actually sure about. It also makes it much easier to update the problem statement mid-project when you learn something that shifts your understanding — because you've already normalised the idea that the statement is provisional.
a note on length and where the statement lives ¶
People often ask me how long a problem statement should be. My honest answer is: one paragraph for most problems, maybe two if the context genuinely requires it. The impulse to write three pages is almost always a sign that the problem isn't yet understood. I've also started caring more about where the statement lives in a project. A problem statement buried in an appendix of a project initiation document is not a living artefact — it's an archive. The organisations I've seen use problem statements most effectively tend to keep them visible: printed on the wall of the team space, referenced at the start of every steering meeting, actively reviewed at the halfway point of the work. The statement is doing its job if people disagree with it, update it, or quote it to each other. If no one mentions it after week two, it was decorative.
I don't think there's a perfect template for this. Every problem statement I've written or helped write has been slightly different, because the organisational context, the level of existing evidence, and the political dynamics all shape what language will actually hold. But the underlying discipline — be specific, name a hypothesis, set a boundary, and make it contestable — has held up across every sector I've worked in. If you're working on one right now and it's not quite landing, I'm happy to take a look. Sometimes a second pair of eyes is all it takes to find where the ambiguity crept in.