菜单
Write a user-centered problem statement with who is blocked, what they are trying to do, why it matters, and how it feels. Use when framing discovery, prioritization, or a PRD.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/deanpeters/Product-Manager-Skills --skill problem-statement命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Understand the PM-to-Director transition through altitude and horizon thinking. Use when diagnosing scope, time-horizon, or leadership-level gaps.
Create a company research brief with executive quotes, product strategy, and org context. Use when preparing for interviews, competitive analysis, partnerships, or market-entry work.
Plan a VP or CPO 30-60-90 day diagnostic onboarding path. Use when entering a new executive product role and avoiding premature change.
基于 SOC 职业分类
正在显示 SKILL.md
| name | problem-statement |
| argument-hint | [user and their struggle] |
| description | Write a user-centered problem statement with who is blocked, what they are trying to do, why it matters, and how it feels. Use when framing discovery, prioritization, or a PRD. |
| intent | Articulate a problem from the user's perspective using an empathy-driven framework that captures who they are, what they're trying to do, what's blocking them, why, and how it makes them feel. Use this to align stakeholders on the problem before jumping to solutions, and to frame product work around user outcomes rather than feature requests. |
| type | component |
| theme | discovery-research |
| best_for | ["Framing a problem before anyone proposes a solution","Getting a team to agree on who is blocked and why it matters","Turning a vague complaint into something a team can act on"] |
| scenarios | ["The team keeps jumping to solutions and we've never written down the actual problem","I need a crisp problem statement for a PRD that a skeptical exec will read"] |
| estimated_time | 10-20 min |
Articulate a problem from the user's perspective using an empathy-driven framework that captures who they are, what they're trying to do, what's blocking them, why, and how it makes them feel. Use this to align stakeholders on the problem before jumping to solutions, and to frame product work around user outcomes rather than feature requests.
This is not a requirements doc—it's a human-centered problem narrative that ensures you're solving a problem worth solving.
Works best with: Who the user is and what they're struggling to do. Also useful: What's blocking them, why it matters, how it feels, and supporting evidence.
Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.
Arriving empty-handed? That works too. The skill asks for the user and their goal first — a problem statement without a specific 'who' is a solution looking for cover.
Example invocation: Problem statement: clinic schedulers double-book exam rooms because the calendar doesn't show equipment availability.
Based on Jobs-to-be-Done and empathy mapping, the framework structures problems as:
Problem Framing Narrative:
Context & Constraints:
Final Problem Statement:
Use template.md for the full fill-in structure.
Before drafting, ensure you have:
skills/jobs-to-be-done/SKILL.md)skills/proto-persona/SKILL.md)If missing context: Run discovery interviews, contextual inquiries, or user shadowing. Don't fabricate problems.
Fill in the template from the persona's point of view:
## Problem Framing Narrative
**I am:** [Describe the key persona, highlighting 3-4 key characteristics]
- [Key pain point or characteristic 1]
- [Key pain point or characteristic 2]
- [Key pain point or characteristic 3]
**Trying to:**
- [Single sentence listing the desired outcomes the persona cares most about]
**But:**
- [Describe the barriers preventing the persona from achieving outcomes]
- [Job-to-be-done or outcome obstruction 1]
- [Job-to-be-done or outcome obstruction 2]
- [Job-to-be-done or outcome obstruction 3]
**Because:**
- [Describe the root cause empathetically]
**Which makes me feel:**
- [Describe the emotions from the persona's perspective]
Quality checks:
## Context & Constraints
- [Enumerate geographic, technological, time-based, or demographic factors]
- [e.g., "Must work offline in rural areas with limited connectivity"]
- [e.g., "Used by non-technical users unfamiliar with complex software"]
- [e.g., "Time-sensitive: decisions must be made within 24 hours"]
Quality checks:
Synthesize the narrative into one powerful sentence:
## Final Problem Statement
[Single, concise statement that provides a powerful and empathetic summary]
Formula: [Persona] needs a way to [desired outcome] because [root cause], which currently [emotional/practical impact].
Example: "Enterprise IT admins need a way to provision user accounts in under 5 minutes because current processes take 2+ hours with manual approvals, which causes project delays and frustrated end-users."
Quality checks:
See examples/sample.md for full examples (good and bad problem statements).
Mini example excerpt:
**I am:** A software developer on a distributed team
**Trying to:** Communicate in real-time with my team without losing context
**But:** Email is too slow and IM is ephemeral
**Because:** No tool combines real-time chat with searchable history
**Which makes me feel:** Frustrated and disconnected
Symptom: "The problem is we don't have [specific feature]"
Consequence: You've predetermined the solution without validating the problem.
Fix: Reframe around the user's desired outcome, not the feature. Ask "What are they trying to achieve?"
Symptom: "Users want to increase our revenue" or "The problem is our churn rate"
Consequence: These are company problems, not user problems. Users don't care about your metrics.
Fix: Dig into why users churn or what would make them spend more. Frame it from their perspective.
Symptom: "I am a busy professional trying to be more productive"
Consequence: Too broad to be actionable. Every product claims to help "busy professionals."
Fix: Get specific. "I am a sales rep managing 50+ leads manually in spreadsheets, trying to prioritize follow-ups without missing high-value opportunities."
Symptom: "Because the UI is confusing"
Consequence: You're describing a symptom, not the underlying issue.
Fix: Ask "Why is the UI confusing?" Keep asking "why" until you hit the root cause (e.g., "Because users have no mental model for how the system works").
Symptom: "Which makes me feel empowered and delighted"
Consequence: These sound like marketing copy, not real user emotions.
Fix: Use actual quotes from user interviews. Real emotions: "frustrated," "overwhelmed," "anxious," "stuck."
skills/jobs-to-be-done/SKILL.md — Informs the "Trying to" and "But" sectionsskills/proto-persona/SKILL.md — Defines the "I am" personaskills/positioning-statement/SKILL.md — Problem statement informs positioningskills/user-story/SKILL.md — Problem statement guides story prioritizationprompts/framing-the-problem-statement.md in the https://github.com/deanpeters/product-manager-prompts repo.Skill type: Component
Suggested filename: problem-statement.md
Suggested placement: /skills/components/
Dependencies: References skills/jobs-to-be-done/SKILL.md, skills/proto-persona/SKILL.md