problem-statement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Purpose

目的

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.

使用以共情为导向的框架，从用户视角阐述问题，涵盖用户身份、他们试图完成的事项、遇到的阻碍、阻碍原因以及由此带来的感受。在着手解决方案之前，使用该框架让利益相关方就问题达成共识，并围绕用户成果而非功能需求来规划产品工作。

这不是需求文档——它是以人为中心的问题叙事，确保你正在解决一个值得解决的问题。

Key Concepts

核心概念

The Problem Framing Framework

问题框架构建框架

Based on Jobs-to-be-Done and empathy mapping, the framework structures problems as:

Problem Framing Narrative:

I am: [Describe the persona experiencing the problem]
Trying to: [Desired outcomes the persona cares about]
But: [Barriers preventing the outcomes]
Because: [Root cause of the problem]
Which makes me feel: [Emotional impact]

Context & Constraints:

[Geographic, technological, time-based, demographic factors]

Final Problem Statement:

[Single, concise, empathetic summary]

基于Jobs-to-be-Done和共情地图，该框架将问题结构化如下：

问题框架叙事：

我是： [描述遇到问题的用户画像]
试图： [用户画像关注的期望成果]
但： [阻碍成果达成的障碍]
因为： [问题的根本原因]
这让我感到： [情感影响]

背景与约束：

[地理、技术、时间、人口统计因素]

最终问题陈述：

[简洁、共情的单一总结]

Why This Structure Works

该结构为何有效

Persona-centric: Forces you to see the problem through the user's eyes
Outcome-focused: "Trying to" emphasizes desired results, not tasks
Root cause analysis: "Because" pushes past symptoms to underlying issues
Emotional validation: "Makes me feel" humanizes the problem and builds empathy
Contextual: Constraints acknowledge real-world limitations

以用户画像为中心： 迫使你站在用户的视角看待问题
成果导向： "试图"部分强调期望的结果，而非任务
根本原因分析： "因为"部分引导你超越表象，找到潜在问题
情感验证： "这让我感到"部分让问题更具人情味，建立共情
情境化： 约束条件考虑了现实世界的局限性

Anti-Patterns (What This Is NOT)

反模式（框架不适用于以下情况）

Not a solution in disguise: "The problem is we lack AI-powered analytics" = sneaking in a solution
Not a business problem: "Our revenue is down" isn't a user problem (it's a symptom)
Not a feature request: "Users need a dashboard" isn't a problem (what are they trying to do?)
Not generic: "Users want better UX" is too vague to be actionable

并非伪装的解决方案： "问题是我们缺乏AI驱动的分析"= 悄悄植入解决方案
并非业务问题： "我们的收入下降"不是用户问题（这是表象）
并非功能需求： "用户需要一个仪表盘"不是问题（他们试图完成什么？）
并非泛泛而谈： "用户想要更好的UX"过于模糊，不具备可操作性

When to Use This

适用场景

Kicking off discovery or problem validation work
Aligning stakeholders before solutioning
Socializing a problem with engineering, design, or exec teams
When you have feature requests but unclear underlying problems
Pitching why a problem is worth solving

启动探索或问题验证工作时
着手解决方案前让利益相关方达成共识时
与工程、设计或高管团队沟通问题时
收到功能需求但不清楚背后的问题时
说明某个问题值得解决时

When NOT to Use This

不适用场景

When you haven't done any user research yet (don't guess—interview first)
For internal operational problems (this is for user-facing problems)
As a substitute for a PRD (this frames the problem; PRD defines the solution)

尚未开展任何用户研究时（不要猜测——先进行访谈）
内部运营问题（该框架适用于面向用户的问题）
替代PRD（该框架用于构建问题框架；PRD用于定义解决方案）

Application

应用方法

Use

template.md

for the full fill-in structure.

使用

template.md

获取完整的填空式结构。

Step 1: Gather User Context

步骤1：收集用户背景信息

Before drafting, ensure you have:

User interviews or research: Direct quotes, observed behaviors, pain points
Jobs-to-be-Done insights: What users are "hiring" your product to do (reference
```
skills/jobs-to-be-done/SKILL.md
```
)
Persona clarity: Who specifically experiences this problem (reference
```
skills/proto-persona/SKILL.md
```
)
Constraints data: Geographic, tech, time, demographic limitations

If missing context: Run discovery interviews, contextual inquiries, or user shadowing. Don't fabricate problems.

在起草之前，确保你拥有：

用户访谈或研究： 直接引用、观察到的行为、痛点
Jobs-to-be-Done洞见： 用户"雇佣"你的产品来完成什么（参考
```
skills/jobs-to-be-done/SKILL.md
```
）
用户画像清晰度： 具体是哪些用户遇到了这个问题（参考
```
skills/proto-persona/SKILL.md
```
）
约束条件数据： 地理、技术、时间、人口统计限制

如果缺少背景信息： 开展探索性访谈、情境调查或用户跟访。不要编造问题。

Step 2: Draft the Problem Framing Narrative

步骤2：起草问题框架叙事

Fill in the template from the persona's point of view:

markdown

undefined

从用户画像的视角填写模板：

markdown

undefined

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:**
- **"I am" specificity:** Can you picture this person? Or is it generic ("busy professionals")?
- **"Trying to" clarity:** Is this an outcome (measurable) or a task (activity)?
- **"But" depth:** Are these real barriers or just inconveniences?
- **"Because" honesty:** Is this the root cause or just a symptom?
- **"Makes me feel" authenticity:** Do these emotions come from research or assumptions?

---

我是： [描述核心用户画像，突出3-4个关键特征]

[关键痛点或特征1]
[关键痛点或特征2]
[关键痛点或特征3]

试图：

[列出用户画像最关注的期望成果的单句描述]

但：

[描述阻碍用户画像达成成果的障碍]
[Jobs-to-be-Done或成果阻碍1]
[Jobs-to-be-Done或成果阻碍2]
[Jobs-to-be-Done或成果阻碍3]

因为：

[共情地描述根本原因]

这让我感到：

[从用户画像的视角描述情感]


**质量检查：**
- **"我是"的具体性：** 你能清晰想象出这个人吗？还是泛泛而谈（如"忙碌的专业人士"）？
- **"试图"的清晰度：** 这是可衡量的成果还是一项任务？
- **"但"的深度：** 这些是真实的障碍还是仅仅是不便？
- **"因为"的真实性：** 这是根本原因还是仅仅是表象？
- **"这让我感到"的真实性：** 这些情感来自研究还是假设？

---

Step 3: Document Context & Constraints

步骤3：记录背景与约束条件

markdown

undefined

markdown

undefined

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:**
- **Relevance:** Do these constraints directly impact the problem?
- **Specificity:** Are they concrete enough to inform design decisions?

---

[列举地理、技术、时间或人口统计因素]
[例如："必须在网络连接有限的农村地区离线使用"]
[例如："由不熟悉复杂软件的非技术用户使用"]
[例如："时间敏感：必须在24小时内做出决策"]


**质量检查：**
- **相关性：** 这些约束条件是否直接影响问题？
- **具体性：** 它们是否足够具体，能为设计决策提供信息？

---

Step 4: Craft the Final Problem Statement

步骤4：撰写最终问题陈述

Synthesize the narrative into one powerful sentence:

markdown

undefined

将叙事整合成一句有力的话：

markdown

undefined

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:**
- **One sentence:** If it requires multiple sentences, the problem isn't crisp yet
- **Measurable:** Can you tell if you've solved it?
- **Empathetic:** Does it resonate emotionally?
- **Shareable:** Could you say this in a meeting and have stakeholders nod?

---

[简洁、共情的单一有力总结]


**公式：** `[用户画像] 需要一种方法来 [期望成果]，因为 [根本原因]，而目前这会导致 [情感/实际影响]。`

**示例：** "企业IT管理员需要一种能在5分钟内完成用户账户配置的方法，因为当前流程需要2个多小时的手动审批，这会导致项目延迟和终端用户不满。"

**质量检查：**
- **单句：** 如果需要多句话，说明问题还不够清晰
- **可衡量：** 你能判断问题是否已解决吗？
- **共情：** 它能引发情感共鸣吗？
- **可分享：** 你能在会议中说出这句话，让利益相关方点头认可吗？

---

Step 5: Validate and Socialize

步骤5：验证与推广

Test with users: Read it aloud to people who experience the problem. Do they say "Yes, exactly!"?
Share with stakeholders: Product, engineering, design, exec. Does it align everyone?
Iterate based on feedback: If anyone says "I don't think that's the real problem," dig deeper.

与用户测试： 向遇到该问题的人朗读。他们会说"对，正是如此！"吗？
与利益相关方分享： 产品、工程、设计、高管。它能让所有人达成共识吗？
根据反馈迭代： 如果有人说"我认为这不是真正的问题"，请深入挖掘。

Examples

示例

See

examples/sample.md

for full examples (good and bad problem statements).

Mini example excerpt:

markdown

**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

查看

examples/sample.md

获取完整示例（优质和劣质问题陈述）。

迷你示例节选：

markdown

**我是：** 分布式团队中的软件开发人员
**试图：** 与团队实时沟通且不丢失上下文信息
**但：** 电子邮件太慢，即时通讯内容易消失
**因为：** 没有工具能将实时聊天与可搜索的历史记录相结合
**这让我感到：** 沮丧和脱节

Common Pitfalls

常见陷阱

Pitfall 1: Solution Smuggling

陷阱1：植入解决方案

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?"

症状： "问题是我们没有[特定功能]"

后果： 你在未验证问题的情况下就预先确定了解决方案。

解决方法： 围绕用户的期望成果重新构建，而非功能。问自己"他们试图达成什么目标？"

Pitfall 2: Business Problem Disguised as User Problem

陷阱2：将业务问题伪装成用户问题

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.

症状： "用户希望增加我们的收入"或"问题是我们的客户流失率"

后果： 这些是公司问题，不是用户问题。用户不关心你的指标。

解决方法： 深入挖掘用户流失的原因或让他们增加消费的因素。从用户的视角构建问题。

Pitfall 3: Generic Personas

陷阱3：泛化的用户画像

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."

症状： "我是一名忙碌的专业人士，试图提高工作效率"

后果： 过于宽泛，不具备可操作性。每个产品都声称能帮助"忙碌的专业人士"。

解决方法： 具体化。"我是一名销售代表，手动在电子表格中管理50多个潜在客户，试图在不遗漏高价值机会的情况下优先跟进客户。"

Pitfall 4: Symptom Instead of Root Cause

陷阱4：关注表象而非根本原因

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").

症状： "因为UI令人困惑"

后果： 你描述的是表象，而非潜在问题。

解决方法： 问"为什么UI令人困惑？"持续问"为什么"，直到找到根本原因（例如："因为用户对系统的工作方式没有心理模型"）。

Pitfall 5: Fabricated Emotions

陷阱5：编造情感

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."

症状： "这让我感到充满力量和愉悦"

后果： 这些听起来像营销文案，而非真实的用户情感。

解决方法： 使用用户访谈中的真实引用。真实情感："沮丧"、"不堪重负"、"焦虑"、"陷入困境"。

References

参考资料

Related Skills

External Frameworks

外部框架

Clayton Christensen, Jobs to Be Done — Origin of outcome-focused problem framing
Osterwalder & Pigneur, Value Proposition Canvas — Customer pains/gains/jobs
Dave Gray, Empathy Mapping — Emotional framing techniques

Clayton Christensen, Jobs to Be Done — 成果导向问题框架的起源
Osterwalder & Pigneur, Value Proposition Canvas — 客户痛点/收益/任务
Dave Gray, Empathy Mapping — 情感框架技术

Dean's Work

Dean的作品

[Link to relevant Dean Peters' Substack articles if applicable]

[如有适用，链接到Dean Peters的Substack相关文章]

Provenance

来源

Adapted from

prompts/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

改编自

prompts/framing-the-problem-statement.md

，来自

https://github.com/deanpeters/product-manager-prompts

仓库。

技能类型： 组件 建议文件名：

problem-statement.md

建议存放位置：

/skills/components/

依赖项： 参考

skills/jobs-to-be-done/SKILL.md

、

skills/proto-persona/SKILL.md

problem-statement

Original

Translation

Purpose

目的

Key Concepts

核心概念

The Problem Framing Framework

问题框架构建框架

Why This Structure Works

该结构为何有效

Anti-Patterns (What This Is NOT)

反模式（框架不适用于以下情况）

When to Use This

适用场景

When NOT to Use This

不适用场景

Application

应用方法

Step 1: Gather User Context

步骤1：收集用户背景信息

Step 2: Draft the Problem Framing Narrative

步骤2：起草问题框架叙事

Problem Framing Narrative

问题框架叙事

Step 3: Document Context & Constraints

步骤3：记录背景与约束条件

Context & Constraints

背景与约束条件

Step 4: Craft the Final Problem Statement

步骤4：撰写最终问题陈述

Final Problem Statement

最终问题陈述

Step 5: Validate and Socialize

步骤5：验证与推广

Examples

示例

Common Pitfalls

常见陷阱

Pitfall 1: Solution Smuggling

陷阱1：植入解决方案

Pitfall 2: Business Problem Disguised as User Problem

陷阱2：将业务问题伪装成用户问题

Pitfall 3: Generic Personas

陷阱3：泛化的用户画像

Pitfall 4: Symptom Instead of Root Cause

陷阱4：关注表象而非根本原因

Pitfall 5: Fabricated Emotions

陷阱5：编造情感

References

参考资料

Related Skills

相关技能

External Frameworks

外部框架

Dean's Work

Dean的作品

Provenance

来源