Problem Statement

A problem statement is a short, clear description of a problem - written in the plainest possible terms. It sounds simple, but most teams skip it. They jump from "something's wrong" to "here's what we'll do about it" without ever agreeing on what the problem is. A good problem statement slows that down just enough to make the solution worth pursuing.

What is a Problem Statement?

A problem statement takes a messy, contested, emotionally charged situation and turns it into something a group of people can look at together and say: yes, that's what we're trying to solve.

It's not a diagnosis. It's not a solution. It's not a project plan. It's the thing that comes before all of those - the moment where you get precise about what's going on, who it's affecting, and why it matters enough to do something about.

The discipline is deceptively hard. Most groups who think they're aligned discover, when they try to write a problem statement together, that they're each solving a different problem. One person is worried about morale. Another is focused on process. A third has a theory about leadership. The problem statement forces those different perspectives into one shared frame.

The model below uses a five-zone hourglass structure that moves from broad understanding through a sharp moment of definition and back out into action.

How a Problem Statement works

The hourglass shape reflects how good problem framing works in practice. You start broad - gathering context and evidence from the world around the problem. You narrow to a sharp point of definition - the problem statement itself. Then you widen back out into approach and action.

The narrowing is where the real work happens. Everything before it feeds the definition. Everything after it flows from it.

Context

Before you can define a problem, you need to understand the landscape around it. Context is about gathering the facts, conditions, and evidence that surround the issue - not jumping to what's causing it, but mapping what's happening.

This means looking at data where it exists (survey results, performance metrics, complaint volumes), but also at softer signals: what are people saying in meetings? What's changed recently? What used to work that doesn't any more?

An Empathy Map can be useful here if the problem is people-centred - it helps you capture what the people affected are saying, thinking, doing, and feeling before you try to define the problem on their behalf.

The goal at this stage is breadth, not precision. You're casting a wide net.

Impact

Once you've gathered context, the next question is: who's affected by this, and what's at stake?

Impact moves you from "here's what's happening" to "here's why it matters." It's the difference between "customer complaints have increased by 30%" and "customer complaints have increased by 30%, affecting 2,400 tenants, with the longest-standing cases now exceeding 90 days."

This is where you start to feel the weight of the problem. Impact isn't about dramatising things - it's about being specific enough that the people who need to act can see why this can't wait.

If the problem is layered - with surface symptoms and deeper structural causes - the Iceberg Model can help you separate what's visible from what's driving it underneath.

Define

This is the pinch point - the sharpest, most constrained moment in the hourglass. Everything you've gathered in Context and Impact now gets distilled into one clear statement. The discipline is this: can you name the problem in one sentence?

That single sentence is the moment of clarity. It's where a room full of people with different perspectives, different priorities, and different theories about what's going wrong arrive at a shared description of the problem they're solving together.

A reliable way to get there is the 5Ws framework:

• Who is affected by this problem?
• What is the problem, in the simplest terms?
• Where does it show up - which teams, locations, processes?
• When did it start, or when is it at its worst?
• Why does it matter - what happens if nothing changes?

A strong problem statement reads like something a group can point to and say: that's what we're solving. It doesn't contain the solution. It doesn't assign blame. It's specific, evidence-based, and honest about what you know and what you don't. If you can't get it into one sentence - or close to one - you probably haven't finished narrowing.

For example: "Tenant complaint resolution times have increased from 14 days to 47 days over the past two quarters, affecting 2,400 households. The three teams involved - repairs, allocations, and customer service - each follow different processes with no shared view of case progress. Tenants are contacting us multiple times about the same issue, and satisfaction scores have dropped from 72% to 58%."

That's a problem statement. It tells you what's happening, who's affected, where it's showing up, and why it matters. It doesn't tell you what to do about it - that comes next.

Approach

With the problem clearly defined, the instinct is to jump to solutions. Resist it.

The Approach zone is about agreeing how you'll investigate the problem further - not what you'll fix. You know what the problem is. You probably don't yet know everything about why it's happening, or which interventions would work.

Ask:

• What information are we still missing?
• Who else needs to be involved in understanding this?
• Are there related problems we should look at alongside this one?
• What have we already tried, and what did we learn?

If your problem has multiple possible root causes, the 5 Whys technique can help you trace symptoms back to their origins. For problems that feel tangled or resistant to straightforward analysis, the Cynefin Framework can help you understand what kind of problem you're dealing with - and therefore what kind of response it needs.

The output of this zone is a plan for investigation, not a plan for action.

Action

Now you're ready to move. Action is about choosing a direction and taking the first concrete steps - not building a 40-page implementation plan.

Three things to decide:

Direction of travel. Based on everything you've learned, where do you need to head? This doesn't need to be a detailed destination - just a clear sense of what "better" looks like.

Three things to start. What are the smallest, most immediate steps you can take this week to begin moving? Keep them specific and achievable. "Talk to the repairs team lead about their triage process" is better than "improve cross-team communication."

Three things to stop. What's currently making the problem worse or preventing progress? These are the anchors you need to release. Again, specific and small beats ambitious and vague.

How to use a Problem Statement

You can work through a problem statement alone, but it's more useful as a team exercise. The conversation it generates is often as valuable as the document it produces.

In a session, allow 60-90 minutes. Start with Context - have the group share what they know, what data exists, and what they've observed. Capture it visibly so everyone can see the same picture building.

Move to Impact together - this is where energy often rises, because people start to feel the urgency of the problem they're describing.

Then write the Define statement as a group. This is the hardest part. Expect to draft it three or four times. The first version will be too broad, too vague, or too focused on solutions. Keep refining until the group can point to it and agree: that's the problem.

Approach and Action can follow in the same session or a separate one, depending on how complex the problem is.

As a standalone document, a problem statement works well as the opening page of a project brief, a change proposal, or a funding bid. It grounds everything that follows in a shared understanding of what you're trying to solve.

A clear problem statement is the foundation of the Define phase in DMAIC - without it, improvement efforts tend to drift.

Example

Greenfield Housing Association has seen tenant satisfaction scores drop for three consecutive quarters - from 72% to 58%. Complaints about repairs and allocations have increased, and the average resolution time has nearly tripled.

The executive team initially framed this as a "customer service problem" and proposed retraining frontline staff. But when the operations director suggested working through a problem statement first, a different picture emerged.

Context: The drop coincided with a restructure six months earlier that merged three previously separate teams (repairs, allocations, and customer service) into a single "tenant experience" function. Each team still uses its own tracking system. No shared dashboard exists. Handoffs between teams happen by email, with no standard process.

Impact: 2,400 tenant households are affected. The longest unresolved complaints are now at 90+ days. Frontline staff report feeling blamed for delays they can't control. Two experienced team members have resigned in the past quarter, citing frustration.

Define: "Since the restructure in Q1, tenant complaint resolution times have increased from 14 to 47 days across repairs, allocations, and customer service. The three teams have no shared case management system or handoff process, meaning tenants contact us multiple times about the same issue. Satisfaction has dropped from 72% to 58%, and staff retention is falling."

Approach: Map the current handoff process across all three teams. Interview frontline staff about where delays happen. Review whether a shared case management view is feasible within the existing systems.

Action: Start by shadowing the complaints process for a week to see where cases get stuck. Stop routing complex cases through the generic email inbox. Begin weekly cross-team stand-ups to surface blocked cases early.

The retraining idea wasn't wrong - but it was premature. The problem statement revealed that the issue was structural, not a skills gap. Without it, Greenfield would have spent time and money on a solution that didn't match the problem.

Limitations

Not every problem needs a formal statement. If the problem is clear, contained, and everyone agrees on what it is, writing a formal problem statement adds process without value. Use your judgement about when the discipline is earning its keep.

Problem statements can become stalling tactics. In organisations that are anxious about making decisions, the process of endlessly refining a problem statement can become a way of avoiding action. Set a time limit and commit to a "good enough" version.

They work less well for wicked problems. Some problems are genuinely resistant to clear definition - they shift as you engage with them, involve competing values, and don't have a single "right" framing. A problem statement can still help, but hold it lightly. Expect to revisit and rewrite it as your understanding develops.

Group dynamics matter. If the loudest voice in the room gets to define the problem, you'll end up with their problem statement, not the group's. Facilitation matters - make sure quieter perspectives are heard, especially from the people closest to the problem.

Getting started

Pick a problem your team is currently navigating - ideally one where you suspect people aren't fully aligned on what the issue is. Set aside 90 minutes and work through the hourglass together, starting with Context.

You don't need a perfect statement on the first attempt. The value is in the conversation: hearing different perspectives, surfacing assumptions, and arriving at a shared understanding of what you're trying to solve.

If you'd like support working through complex problem framing with your team, our operational effectiveness consultancy can help you move from diagnosis to action with clarity and confidence.