---
title: "Problem Statement Template With PM Examples"
description: "A problem statement template for PMs: decode a feature request into the real problem and a measurable outcome, then fill seven fields. Weak vs strong examples."
canonical_url: "https://builderscamp.com/guides/templates/problem-statement-template"
date_published: "2026-09-26"
date_modified: "2026-09-26"
author: "Andre Albuquerque"
publisher: "Builders Camp"
guide_class: "templates"
---

# Problem Statement Template

**TL;DR:** A useful problem statement separates what was requested from the problem underneath it and the outcome you want to change, then records the segment, context, observable friction, impact, evidence, open assumption and expected outcome. If your problem statement names a feature, it is a solution in disguise, and you should rewrite it before anyone starts building.

## Why start from the problem instead of the request?

A feature request is someone's first guess at a solution, and treating it as the problem locks you into that guess. Clayton Christensen made the point in a 2005 Harvard Business Review article, writing that the marketing professor Theodore Levitt "used to tell his students, 'People don't want to buy a quarter-inch drill. They want a quarter-inch hole!'" The research by [Quote Investigator](https://quoteinvestigator.com/2019/03/23/drill/) traces the adage further back, to Leo McGivena, whom Levitt himself credited. Whoever said it first, the product lesson holds: the drill is the request, the hole is the problem.

Skipping that step is expensive. Pendo's [2019 Feature Adoption Report](https://www.pendo.io/resources/the-2019-feature-adoption-report/) found that 80 percent of features in the average software product are rarely or never used. The analysis covers 615 Pendo customer subscriptions and only the features those customers tagged, so it is not a census of all software, and unused features have many causes besides a bad problem statement. It is still a strong reason to check the problem before committing a sprint to a request.

## How do you decode a request into a problem and an outcome?

Every request you receive can be split into three parts: the request as stated, the underlying problem, and the product outcome you would commit to. The table below shows the split on three original examples from a B2B expense management app. The problem column is a hypothesis to confirm with evidence, not a conclusion.

| Who asked | Request | Underlying problem (to confirm) | Product outcome |
|---|---|---|---|
| CEO | "Add an AI assistant to the app" | Admins can't find where to change policy settings, so they email support | More policy changes completed by admins without contacting support |
| Support lead | "Add an FAQ page about receipt uploads" | Photo uploads fail on slow mobile connections, so employees give up | More receipts attached on the first attempt from mobile |
| Sales, for a large prospect | "Build a bulk approve button" | Finance managers approve many small expenses one at a time at month end, which delays reimbursement | Shorter time from expense submission to approval at month end |

Two of these requests may still turn out to be the right solution. The point of the decoding step is that you choose the solution after seeing the problem, not before.

## What goes in the problem statement template?

The template has seven fields. Fill them in order, and leave a field marked "unknown" rather than inventing an answer.

| Field | The question it answers |
|---|---|
| Segment | Who exactly has this problem? Name a group narrow enough to go and talk to. |
| Context | What are they trying to do, and in what situation, when the problem appears? |
| Observable friction | What gets in the way, described as something you could watch happen? |
| Impact | Why does it matter, for the user and for the business? |
| Evidence | What have you seen or measured that shows the problem is real? |
| Open assumption | What are you believing that nobody has checked yet? |
| Expected outcome change | Which behaviour should change, measured how, in which direction, by when? |

A plain-text version you can paste into a doc:

```
Segment:
Context:
Observable friction:
Impact (user / business):
Evidence:
Open assumption:
Expected outcome change (behaviour, metric, direction, date):
One-sentence problem statement:
```

## How do you fill in the template step by step?

Work from the request back to the problem, then forward to the outcome.

1. Write the request down exactly as it was given, with who asked and when.
2. Ask the requester what they were trying to achieve when they thought of it, and write the answer in the context field.
3. Describe the friction as something observable, not as a feeling or a missing feature.
4. Collect evidence from support tickets, usage data, sales notes or interviews, and move anything you cannot back up into the open assumption field.
5. Write the expected outcome as a behaviour change with a metric, a direction and a date.
6. Compress everything into one sentence that names the segment, the friction and the impact, with no feature in it.

Step 4 is where most statements quietly go wrong. An assumption that nobody labels as one ends up being treated as evidence in the decision meeting, and the [product decision making framework](https://builderscamp.com/guides/other/product-decision-making-framework) is built around keeping those two apart.

## What does a weak versus a strong problem statement look like?

Here is the bulk approve request from the table, written two ways.

**Weak:** "Finance managers need a bulk approve button because approving expenses takes too long."

The weak version names its own solution, uses "too long" without saying for whom or when, and offers no evidence. The only possible response is to build the button.

**Strong:**

- **Segment:** finance managers at customers with more than one approval level.
- **Context:** the last working days of the month, when they clear the approval queue before payroll.
- **Observable friction:** they open, check and approve each small expense one at a time, even when the expenses are routine.
- **Impact:** employees wait longer for reimbursement, and finance teams report month-end closing running late.
- **Evidence:** repeated support tickets and sales call notes mentioning month-end approval backlogs.
- **Open assumption:** that most of the queue is low-risk expenses that do not need individual review.
- **Expected outcome change:** a shorter median time from submission to approval in the last week of the month, measured against the current baseline, reviewed after two month-end cycles.

One-sentence version: "At month end, finance managers at multi-level customers clear routine expenses one by one, which delays reimbursement and closing."

The strong version opens up options the weak one closed. A bulk approve button is one answer. Auto-approving expenses below a policy threshold is another, and it may remove the queue altogether. Grouping expenses by employee is a third. The team can now compare them against the same outcome.

## How do you spot a solution disguised as a problem?

A solution disguised as a problem is a statement that only has one possible answer because the answer is already inside it. "Users need a Slack integration", "customers want a dashboard" and "we need an AI assistant" all read like problems, and all of them are feature requests.

Three quick tests catch most of them. If the statement contains a noun that is a feature (button, integration, dashboard, page), rewrite it. If you cannot name two different solutions that would each solve it, rewrite it. If the person who asked would reject every alternative to their original idea, you have found a preference, not a problem, and it is worth asking why that exact solution matters to them.

The honest limitation: sometimes the request really is the best solution, and a long decoding exercise on an obvious fix wastes everyone's time. Scale the effort to the cost of being wrong. A one-day change needs a one-line problem; a quarter of engineering work needs all seven fields. The underlying habit, asking what a request is for before deciding how to answer it, is what people mean by [product sense](https://builderscamp.com/guides/glossary/product-sense), and the same thinking sits behind [Jobs to Be Done](https://builderscamp.com/guides/glossary/jobs-to-be-done). Once the problem is agreed, a [one-pager](https://builderscamp.com/guides/templates/one-pager-template) is the usual next document.

## How does Builders Camp teach problem framing?

Problem framing is a core topic in the [Product Sense bootcamp](https://builderscamp.com/bootcamps/product-sense): separating requests from real problems and defining what success looks like before choosing a solution. The bootcamp runs 3 live sessions of 90 minutes each over 2 weeks, directed by [Mihaela Draghici](https://builderscamp.com/guides/profiles/mihaela-draghici), and its practical challenge starts with exactly this reframing step. Members also get the bootcamp's Problem Framing Template, a fill-in PDF worksheet that walks the same fields as the template above: who has the problem, what is in the way, why it matters and what evidence backs it up. You can try it on your own situation with the [product sense case study exercise](https://builderscamp.com/guides/challenges/product-sense-thin-data-decision).

Builders Camp runs live and self-paced bootcamps in product management and AI product building. [See the Product Sense bootcamp](https://builderscamp.com/bootcamps/product-sense?utm_source=guide&utm_medium=organic&utm_campaign=problem-statement-template) for the next cohort and the self-paced version.

## Frequently asked questions

### What is a problem statement in product management?

A short description of who is struggling, with what, in which situation, why it matters, and what evidence shows it, written without naming a solution. It is the input to a product decision, so the team can compare several solutions against the same problem instead of debating one feature request.

### What is the difference between a request, a problem and an outcome?

A request is a proposed solution someone brings you, such as a button or an integration. The problem is the friction underneath it that a user actually experiences. The outcome is the measurable change in behaviour you want, with a target and a date. You receive the first, you investigate the second, and you commit to the third.

### What is a solution disguised as a problem?

A problem statement that already contains its answer, for example 'users need a bulk approve button'. It reads like a problem, but the only way to solve it is to build that button, so it closes off every alternative before anyone has looked at them. The test: if your problem statement names a feature, rewrite it.

### How long should a problem statement be?

Short enough to read aloud in under a minute. The seven fields in this template usually fit in one short paragraph per field, and the one-sentence summary at the end should fit on a single line.

### Should a problem statement include a metric?

Yes, in the expected outcome field. Name the behaviour you expect to change, how you will measure it, the direction of change you are aiming for, and a date. A problem with no measurable outcome cannot tell you later whether the solution worked.

### Who should write the problem statement?

Usually the PM, but with input from the person who made the request and from anyone who holds evidence, such as support or sales. Sharing the draft with the requester is useful in itself: it shows you took the request seriously and gives them a chance to correct your reading of the problem.

### How does a problem statement relate to a PRD or a one-pager?

The problem statement comes first and feeds both. A one-pager uses it to pitch whether the problem is worth solving; a PRD uses it as the opening section that every requirement should trace back to.

## Sources

- [Quote Investigator: No One Wants a Drill. What They Want Is the Hole](https://quoteinvestigator.com/2019/03/23/drill/)
- [Pendo: The 2019 Feature Adoption Report](https://www.pendo.io/resources/the-2019-feature-adoption-report/)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.