Problem Statement Framework
A simple four-part sentence structure that forces clarity about who has a problem and why it matters
8 min · Popularised through Design Thinking and lean startup practice
What is this framework?
A problem statement is a single sentence built from four parts: the customer, the problem, the situation that triggers it, and the consequence if it isn't solved. Writing it this way stops founders from jumping to solutions before they've proven the problem is real and painful.
Many student ventures fail not because the solution was poorly built, but because the founders never precisely defined the problem in the first place. A vague statement like "students struggle with food" is almost useless because it doesn't say who, when, or why it matters enough to act on.
The four-part structure — [Customer] experiences [problem] when [situation], resulting in [consequence] — forces specificity at every stage. Naming a precise customer segment stops you designing for 'everyone'. Naming the triggering situation grounds the problem in a real moment rather than an abstract complaint. Naming the consequence proves the problem is costly enough to be worth solving.
A well-written problem statement is also solution-neutral: it says nothing about apps, platforms or features. This matters because a statement that already contains a solution ('students need an app') quietly shuts down better alternatives before you've explored them.
What problem does it help solve?
- Force yourself to name a specific customer instead of a vague general audience
- Ground abstract complaints in a concrete triggering situation
- Prove the problem has a real, costly consequence worth solving
- Avoid smuggling a solution into what should be a neutral problem definition
- Create a shared, testable reference point for the whole founding team
The framework
Combine the four columns into one sentence: [Customer] experiences [problem] when [situation], resulting in [consequence].
Every part explained
Customer
A specific, narrowly defined group of people who share this problem — not 'everyone' or 'students' in general.
Ask: Exactly who has this problem?
Example: Second-year students with back-to-back lectures and a 40-minute lunch break.
Problem
The core difficulty or unmet need, described in the customer's language, without mentioning any solution.
Ask: What specifically are they struggling with?
Example: They cannot get an affordable hot meal within their break.
Situation
The concrete moment or trigger when the problem shows up, making it vivid and testable rather than abstract.
Ask: When and where does this problem actually occur?
Example: Right after their 12pm lecture ends, with class resuming at 12:40pm across campus.
Consequence
What happens if the problem stays unsolved — the cost in money, time, health, or emotion.
Ask: So what? Why does this problem matter enough to fix?
Example: They skip lunch or eat unhealthy snacks, causing energy crashes in afternoon classes.
Worked example — CampusEats
The CampusEats team rewrote three vague complaints into one precise, solution-neutral problem statement.
Initial vague complaint
"Students hate the food situation on campus."
Customer
Second-year students with 40-minute lunch breaks between back-to-back lectures.
Problem
They cannot get an affordable, filling hot meal within their break.
Situation
Immediately after their midday lecture ends, with the canteen already crowded.
Consequence
They skip lunch or eat vending-machine snacks, leading to poor focus in afternoon classes.
Final problem statement
Second-year students with 40-minute lunch breaks experience an inability to get an affordable hot meal when their midday lecture ends and the canteen is already crowded, resulting in skipped meals and afternoon energy crashes.
Contrast: solution statement (avoid)
"Students need a mobile app to order food." — this smuggles in a solution and stops exploration of other options.
How to use it
- 1Gather raw observations and quotes from real potential customers.
- 2Narrow the customer to a specific, describable segment.
- 3Write the problem in the customer's own words, with no solution mentioned.
- 4Identify the exact situation or trigger moment when the problem appears.
- 5State the real consequence of leaving the problem unsolved.
- 6Combine all four parts into one sentence and read it aloud for solution-neutral language.
- 7Test the statement with the actual customer segment to check it rings true.
Try it yourself
Build your own problem statement one part at a time.
Problem statement builder
Your work stays on this device. Nothing is uploaded, so use the same browser to come back to it.
When to use it
- Right after initial customer discovery interviews, before ideating solutions
- When a team disagrees about what problem they're actually solving
- Before writing a pitch, to check the problem is specific and provable
- Whenever a solution isn't gaining traction, to revisit whether the problem was real
When not to rely on it
This framework does not prove:
- • It does not prove the problem is widespread enough to build a business on
- • It does not validate that customers will pay to solve it
- • It does not generate or evaluate solutions
- • A well-written statement can still be based on a wrong assumption if research was weak
Common mistakes
- Writing a solution instead of a problem ('customers need an app')
- Defining the customer so broadly it includes almost anyone
- Leaving out the situation, making the problem feel abstract and unfalsifiable
- Skipping the consequence, so it's unclear why the problem is worth solving
Connections
Related concepts
Related frameworks
Quick check
Which of the following is a properly written problem statement rather than a solution statement?
Remember this
If your problem statement already contains an app, it isn't a problem statement yet.