problem-statement
by deanpetersThe problem-statement skill helps you turn a vague product ask into a user-centered problem statement. It captures who is blocked, what they are trying to do, why it matters, and how it feels. Use it for discovery, prioritization, PRDs, and Technical Writing workflows when you need to frame the problem before solutioning.
This skill scores 78/100, which means it is a solid listing candidate for directory users who want a reusable way to frame product problems from the user’s perspective. The repo gives enough structure, examples, and framing rules to reduce guesswork versus a generic prompt, though it still lacks some adoption aids like an install command or companion docs.
- Clear triggerability: the frontmatter says to use it when framing discovery, prioritization, or a PRD.
- Operational guidance is concrete: it provides a problem-framing narrative with I am / Trying to / But / Because / Which makes me feel plus context and constraints.
- Good agent leverage: the template and sample example show how to turn a vague issue into a single concise problem statement.
- No install command or support files, so users must rely on the SKILL.md and template alone.
- The repository is narrowly scoped to problem framing, so it helps at the discovery/definition stage but not downstream PRD or solution design work.
Overview of problem-statement skill
The problem-statement skill helps you turn a vague product ask into a user-centered problem statement that explains who is blocked, what they are trying to do, why it matters, and how it feels. It is most useful when you need alignment before solutioning: discovery, prioritization, PRDs, and stakeholder reviews.
What problem-statement is for
This problem-statement skill is designed for framing, not feature design. It helps you describe the problem from the user’s perspective so teams can judge whether the work is worth doing before debating implementation.
Best fit readers
Use this if you write product briefs, technical specs, research summaries, or roadmap notes and you need a cleaner problem narrative. It is a strong fit for Technical Writing workflows when you need to translate messy input into a concise, empathetic statement.
What makes it different
The skill centers the problem framing framework: I am, Trying to, But, Because, and Which makes me feel, plus context and constraints. That structure is more decision-useful than a generic prompt because it forces you to capture both the functional blockage and the human impact.
How to Use problem-statement skill
Install and inspect the skill
Install it with:
npx skills add deanpeters/Product-Manager-Skills --skill problem-statement
Then read skills/problem-statement/SKILL.md first, followed by template.md and examples/sample.md. This is the fastest way to understand the expected shape, the final output, and what a good completed problem statement looks like.
What to provide in your prompt
For good problem-statement usage, give the skill a rough but specific input: the user type, the task they want to complete, the blocker, and any constraints. If you only provide a feature request, the output will drift toward solution language instead of a real problem.
A stronger input looks like this:
- Persona: “new support agents on mobile”
- Goal: “resolve tickets without switching tools”
- Blocker: “they lose context between CRM and chat”
- Constraints: “high volume, low training time, remote-first team”
Suggested workflow
Start with a short draft, then tighten it into the five-part narrative. Use the template as a checklist: if Because sounds like a solution, go back and ask what is actually causing the pain. If Which makes me feel feels generic, replace it with a real user emotion tied to the workflow.
Files to read first
Prioritize SKILL.md, template.md, and examples/sample.md. The example file is especially useful because it shows both a good framing pattern and an anti-pattern, which helps you avoid writing a disguised solution instead of a problem statement.
problem-statement skill FAQ
Is problem-statement just a prompt template?
No. The problem-statement skill is a reusable framing method, not just a fill-in-the-blanks prompt. The value is in forcing clarity about the user, the blockage, and the root cause before you write a PRD or propose a fix.
When should I not use it?
Do not use problem-statement if you already have a well-scoped requirements doc or if you are documenting an implementation detail. It is also a poor fit when the goal is to brainstorm solutions; this skill is about defining the problem first.
Is problem-statement beginner-friendly?
Yes, if you can describe a user and a pain point in plain language. The template is simple, but the quality depends on whether you can separate the user’s problem from your preferred solution.
How does it fit Technical Writing work?
For Technical Writing, the skill is useful when you need to clarify audience pain, support a doc request, or frame a content gap before writing. It helps you keep the document outcome-focused instead of drifting into feature narration.
How to Improve problem-statement skill
Give the skill evidence, not slogans
The best problem-statement results come from concrete observations: what the user tried, where they got stuck, what they used instead, and what broke. “Users are confused” is weak; “first-time admins cannot finish setup because the UI hides the required API key field” is much better.
Separate the problem from the solution
A common failure mode is smuggling in a fix. If your draft says “users need a dashboard,” rewrite it as “users cannot compare account health across services because status signals are scattered.” That keeps problem-statement focused on the actual barrier.
Add constraints that change the answer
Include anything that affects the shape of the problem: device, team size, time pressure, compliance, experience level, or platform limitations. These details make the problem statement more credible and help the final output support better prioritization.
Iterate from draft to decision-ready
After the first output, check whether the statement is specific enough to survive stakeholder review. If not, tighten the persona, make the Because more causal, and ensure the final sentence can be read without extra explanation.