Writes the client's problem as a point of view in their words (who, needs, because), with impact in their own figures, why now, constraints, what is out of scope and one How Might We question. Use for "run disc-problem-statement", "write the problem statement", "frame their problem", "what is their real problem", "my proposal talks about us not them", "point of view statement", "how might we", part of the Claude for Winning Proposals Pack by Polar Bear.
Scanned 10/5/2026
npx -y skills add polar-bear-org/claude-skills --skill disc-problem-statement --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Disc Problem Statement?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/polar-bear-org-disc-problem-statement)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
name: disc-problem-statement
description: Writes the client's problem as a point of view in their words (who, needs, because), with impact in their own figures, why now, constraints, what is out of scope and one How Might We question. Use for "run disc-problem-statement", "write the problem statement", "frame their problem", "what is their real problem", "my proposal talks about us not them", "point of view statement", "how might we", part of the Claude for Winning Proposals Pack by Polar Bear.
---
# Problem Statement
## When To Use
Your proposals describe your firm, not their problem. Run this after the call and the recap, before any options or prices. It answers one question: what is this client's problem, in words they would sign?
## When Not To Use
If the client is asking where an answer could be wrong, or you need the causes laid out, use Issue Tree after this. If you have not had a call yet, a statement written from the brief alone is a guess; run Discovery Call Questions first.
## Inputs
- Your Discovery Call Record (verbatim, facts, figures) and the client's reply to your recap, if any.
- Your Cost of Inaction Worksheet for the impact line, and the brief they sent for constraints and stated scope.
If you have none of this, I start from your own summary of the call, leave impact blank, and mark the statement as a first draft to test.
## Approach
The point of view statement and How Might We question come from the Stanford d.school (POV overview, web.stanford.edu/class/me228; How Might We, dschool.stanford.edu): a user group plus an insight into its need, then a question that opens options. The judgment is in the "because". Without an insight from the call, the statement becomes a slogan any firm could put in its proposal, and the client reads it as your sales copy, not their problem.
## Workflow
1. Ask three questions: which role or group in the client feels the problem most; which line from the call surprised you; has the client confirmed or corrected your recap.
2. Write the point of view as [who] needs [need, as a verb] because [insight]. Who is the client's role or group, never your service. The need is a verb ("to decide", "to stop losing"), never a feature or a deliverable. The insight comes from the verbatim or fact bins, with the line it came from.
3. Write impact in the client's figures only, copied from the worksheet with who gave them. Blanks stay blank with the question to ask. Nothing is rounded up or extrapolated.
4. Add why now, constraints and out of scope, each tied to a line in the notes or the brief. Out of scope is what they said they do not want, plus what you will not cover.
5. Write one How Might We question that opens several possible approaches and does not name yours. Too narrow ("how might we run a workshop") and it is your offer; too broad ("how might we grow") and it is nobody's.
6. Run the rival test: could this statement sit unchanged in another firm's proposal? If yes, put more of the client's words and constraints into it until it could not.
## Output Format
```markdown
# Client Problem Statement
Client: [role or team] | Call: [date] | Recap confirmed: [yes / corrected / no reply]
## Point of view
[Who] needs [need, as a verb] because [insight].
Source: [verbatim line or fact from the call record]
## Impact, in their figures
| Consequence | Figure and unit | Period | Who said it |
|---|---|---|---|
| [consequence] | [figure, or blank] | [period] | [role] |
## Why now
- [Deadline or trigger, as they stated it] | Source: [line]
## Constraints
- [Budget, people, time, systems, decisions already made] | Source: [line]
## Out of scope
- [What they do not want / what you will not cover]
## How might we
How might we [question that opens options]?
## Rival test
[Passes / fails, and what was changed]
## Decision
[You] decide by [date] whether this statement goes to the client as written or back for one more question.
```
## Done When
- The insight in the "because" traces to a specific line in the call record.
- Every figure is the client's, with who said it; blanks are blank.
- The How Might We question does not name your approach.
- The statement fails the rival test only after you saw why and fixed it.
## Quality Bar
- "Who" is a role or group, never a named person's flaws or competence.
- Plain words the client used, not your firm's vocabulary; one page, or it is still two problems.
- Their words and their figures; nothing invented to make the problem bigger.
## Next
Run disc-issue-tree (Issue Tree) to show where the answer could be wrong before you propose one.
## About the makers
This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!