Problem Statement Examples (With a Seven-Part Template)

A good problem statement says what you are solving, why now, what is in and out of scope, and what a good answer looks like, in one page or less. Most weak ones skip at least three of those. This page gives you a seven-part template, five worked examples with invented companies, and the checks that turn a vague request into a question you can finish.
What a problem statement is for
A problem statement is the agreement between you and whoever asked. When a disagreement appears three weeks into the work, it is the page you point to. When a new person joins, it is what they read first. Writing it takes about ten minutes and prevents most scope arguments.
It is not a description of the solution, a history of the issue, or a list of symptoms. It names a question that can be answered with evidence.
The seven-part template
| Part | Question it answers |
|---|---|
| Context | What is the background, in one or two sentences? |
| Trigger | What changed that makes this urgent? |
| Key question | What exactly must be answered? |
| Scope | What is in, and what is explicitly out? |
| Success criteria | What does a good-enough answer look like? |
| Constraints | What are the limits on time, budget, data or access? |
| Decision owner | Who will use the answer? |
Each row prevents a specific kind of trouble. Without a trigger, nobody can judge urgency. Without scope, the work quietly doubles. Without success criteria, you cannot tell when to stop. Without a decision owner, you produce an answer nobody has the authority to act on.
Five problem statement examples
All companies below are fictional.
1. Rising returns at an online bike shop
- Context: Northwind Bikes sells through twelve stores and a web shop.
- Trigger: Web-shop returns doubled over two seasons.
- Key question: Which two causes explain most of the rise in web-shop returns of adult bikes, and what is the lowest-cost first action against each?
- Scope: In: web-shop returns of adult bikes. Out: store returns, accessories.
- Success criteria: A ranked list of causes with evidence, and one recommended first action for each of the top two.
- Constraints: Four weeks, existing order data only, no new software.
- Decision owner: Head of e-commerce.
2. Slow support replies
- Context: A software company handles all support email in-house.
- Trigger: Ticket volume doubled in a year and first response time grew from four hours to nineteen.
- Key question: What combination of staffing and self-service would bring first response under eight hours by the end of next quarter?
- Scope: In: email tickets. Out: chat, phone, billing disputes.
- Success criteria: Two costed options and a recommendation.
- Constraints: Hiring budget for two people at most.
- Decision owner: Head of customer support.
3. Falling margin at a coffee roaster
- Context: Lantern Coffee Roasters sells online through subscriptions and one-time orders.
- Trigger: Operating profit fell for three quarters while order counts stayed flat.
- Key question: Is the fall in profit coming from revenue per order or cost per order, and which single change would recover most of it?
- Scope: In: online business only. Out: wholesale.
- Success criteria: The cause located to a specific cost or price line, with a sized fix.
- Constraints: Five working days.
- Decision owner: The owner.
4. A staffing-or-booking question
- Context: A regional clinic group has one site with long waits.
- Trigger: Average wait reached 38 minutes against a 20-minute target.
- Key question: Does the wait come from staffing levels or from how appointments are booked?
- Scope: In: the main site, weekday mornings. Out: other sites, weekends.
- Success criteria: A clear answer to the either-or question, with the data that supports it.
- Constraints: Two weeks, existing booking data.
- Decision owner: Operations director.
5. A decision with a deadline
- Context: A manufacturer buys packaging from one supplier.
- Trigger: The supplier announced a price change effective next quarter.
- Key question: By the end of the month, should we renegotiate, add a second supplier or redesign the packaging?
- Scope: In: the three main packaging lines. Out: shipping cartons.
- Success criteria: A recommendation among the three options with the main risk of each.
- Constraints: Two weeks, procurement data only.
- Decision owner: Head of procurement.
How to check your key question
The key question is the part most often written badly. Test it against five letters.
| Check | A failing question | A better version |
|---|---|---|
| Specific | How can we improve customer experience? | Which three steps in the returns process cause the most customer contacts? |
| Measurable | Why is morale low? | Which factors do staff cite most often as reasons for leaving? |
| Actionable | Why is the market changing? | Which two market changes should change our pricing this year? |
| Relevant | What is the history of our returns policy? | Does our returns policy cause the increase in returns? |
| Time-bound | Someday we should know why. | By the March meeting, which causes explain most of the increase? |
Also check that the question is a single question. "Why did returns rise and what should we do about our supplier?" is two. Separate them or pick the one you will answer now.
Write success criteria about the answer, not the business
Success criteria describe the quality of your answer. You can promise a ranked list of causes with evidence. You cannot promise that the company's results will improve, because that depends on decisions and events outside your analysis. Imagine the final meeting and ask what the decision owner would need to see for it to go well. That is your success criterion.
Common mistakes
- Solution disguised as a problem. "We need a new CRM" is an answer, not a problem.
- No out-of-scope list. Scope grows through small, reasonable-sounding additions. Name at least two things you will not do.
- A question about the work, not the decision. "What analysis should we run?" is not what the decision owner is asking.
- No decision owner. An answer with no user tends to be filed and forgotten.
From statement to structure
Once the question is sharp, the next step is to split it into parts you can investigate. The issue tree guide shows how, and the MECE framework explains the rule that keeps the split clean. When the work becomes a formal project, the statement usually becomes a section of the project charter.

Use the worksheet
The first guide in The Consultant's Playbook covers exactly this step. It walks through the situation, complication and question, the seven parts above and the SMART test, then applies them in one complete worked case. It includes two printable worksheets, SCQ and Problem Statement and SMART Question Check, so you can fill in your own version rather than copy an example.
Educational content. It is not legal, financial or tax advice.