名称：问题框架画布 描述：“通过结构化问题引导产品经理使用MITRE的问题框架画布，覆盖内省、外视和重构阶段，以产生清晰、无偏见的问题陈述。” 类型：交互式
目的
指导产品经理通过MITRE问题框架画布流程，通过在三个阶段提出结构化问题：内省（检查自己的假设和偏见）、外视（理解谁体验问题和谁不体验）、重构（将见解综合成可操作的问题陈述和“How Might We”问题）。使用这个工具确保在跳入解决方案之前解决正确的问题——避免确认偏见、被忽视的利益相关者和解决方案优先思维。
这不是解决方案头脑风暴——它是一个问题框架工具，拓宽视角、挑战假设，并产生清晰、以公平为导向的问题陈述。
关键概念
什么是MITRE问题框架画布？
问题框架画布（MITRE创新工具包，v3）是一个结构化框架，帮助团队在提出解决方案之前全面探索问题空间。它分为三个区域：
- 内省 — 检查自己的假设、偏见，以及你如何可能是问题的一部分
- 外视 — 理解谁体验问题、谁从中受益，以及谁被遗漏
- 重构 — 将见解综合成清晰、可操作的问题陈述和“How Might We”问题
画布结构
┌─────────────────────────────────────────────────────────────────┐
│ 内省 │
│ - 问题是什么？（症状） │
│ - 为什么我们还没有解决它？（新问题、难度大、优先级低等） │
│ - 我们如何是问题的一部分？（假设、偏见） │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 外视 │
│ - 谁体验这个问题？何时/何地/后果？ │
│ - 谁还有这个问题？谁没有？ │
│ - 谁被遗漏了？ │
│ - 谁在问题存在/不存在时受益？ │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ 重构 │
│ - 换一种说法，问题是：[重述] │
│ - 我们如何能够[行动]以实现[目标]？ │
└─────────────────────────────────────────────────────────────────┘
为什么这有效
- 拓宽视角： 迫使你超越自己的假设
- 以公平为导向： 关注边缘化声音，询问“谁被遗漏了？”
- 挑战偏见： 要求在框架问题前明确检查假设
- 可操作输出： 产生HMW陈述，准备进行解决方案探索
反模式（这不是什么）
- 不是解决方案头脑风暴： 画布框架问题；解决方案随后产生
- 不是功能请求列表： 关注根本问题，而非表面症状
- 不是单人练习： 需要多样化视角以挑战群体思维
何时使用
- 开始新计划的探索发现
- 重新框架现有问题（怀疑你在解决错误的事情）
- 在构建解决方案前挑战假设
- 跨职能团队就问题定义达成一致
何时不使用
- 当问题已经很好理解并验证
- 用于战术性的bug修复或技术债务（无需深度框架）
- 当利益相关者已承诺解决方案（先解决对齐问题）
引导来源
使用workshop-facilitation作为此技能的默认交互协议。
它定义了：
- 会话预告 + 进入模式（引导式、上下文转储、最佳猜测）
- 单问题回合与简单语言提示
- 进度标签（例如，上下文问题x/8和评分问题x/5）
- 中断处理和暂停/恢复行为
- 决策点的编号推荐
- 常规问题的快速选择编号响应选项（包括
其他（指定），当有用时）
此文件定义了领域特定评估内容。如果冲突，遵循此文件的领域逻辑。
应用
使用template.md获取完整的填充结构。
此交互式技能遵循三阶段流程，在每个阶段提出自适应问题。
步骤0：收集上下文（在问题前）
代理建议：
在框架您的问题之前，让我们收集上下文：
问题上下文：
- 初始问题陈述或利益相关者请求
- 您观察到的症状（支持票、流失数据、用户投诉）
- 现有研究（用户访谈、调查、分析）
- 您对问题的假设
利益相关者上下文：
- 谁受此问题影响？（用户、客户、内部团队）
- 谁要求解决此问题？（高管、销售、客户）
- 谁可能被忽视？
您可以直接粘贴此内容，或简要描述问题。
阶段1：内省
目标： 检查自己的假设、偏见，以及你如何可能是问题的一部分。
问题1：问题是什么？（描述症状）
代理询问： “您目前理解的问题是什么？描述症状。”
提供4个编号选项：
- 客户痛点 — “客户在[特定任务/结果]上挣扎”（例如，“客户找不到他们需要的功能”）
- 业务指标问题 — “我们看到[指标下降]”（例如，“上季度流失增加15%”）
- 利益相关者请求 — “利益相关者说我们需要[功能/更改]”（例如，“销售团队说我们需要更好的报告”）
- 观察到的行为 — “我们注意到[模式/趋势]”（例如，“用户在步骤3放弃入门”）
或描述您的问题/症状。
用户响应： [选择或自定义]
代理提取：
- 问题（初始框架）： [用户描述]
问题2：为什么我们还没有解决它？
代理询问： “为什么这个问题还没有被解决？”
提供6个编号选项（可多选）：
- 它是新的 — “问题最近出现”
- 它很难 — “技术上复杂或资源密集”
- 它优先级低 — “其他倡议优先”
- 缺乏资源 — “预算、人员或时间不足”
- 缺乏权限 — “无法做出决定或获得支持”
- 系统性不平等 — “问题不成比例地影响边缘化群体，被忽视”
或描述您自己的原因。
用户响应： [选择或自定义]
代理捕获：
- 解决障碍： [原因列表]
问题3：我们如何是问题的一部分？（假设和偏见）
代理询问： “您（或您的团队）如何可能是问题的一部分？您带来哪些假设或偏见？”
提供4个编号选项：
- 假设我们知道客户想要什么 — “我们没有与真实用户验证”（确认偏见）
- 为自己优化，而非用户 — “构建对我们容易的，而非对他们有价值的”（内部偏见）
- 忽视特定用户细分 — “关注多数用户，忽视边缘案例或边缘化群体”（幸存者偏见）
- 解决方案优先思维 — “在理解根本问题前跳到‘我们需要[功能X]’”（过早收敛）
或描述您的特定假设/偏见。
用户响应： [选择或自定义]
代理捕获：
- 要挑战的假设： [偏见列表]
阶段2：外视
目标： 理解谁体验问题、谁从中受益，以及谁被遗漏。
问题4：谁体验这个问题？（何时、何地、后果）
代理询问： “谁体验这个问题？何时和何地他们体验它？他们面临什么后果？”
代理提示用户描述：
- 谁： 特定角色、用户细分或角色
- 何时： 触发事件或上下文（例如，“在入门期间”、“在月末结算时”）
- 何地： 物理或数字位置（例如，“移动应用”、“企业部署”）
- 后果： 对用户的影响（例如，“每周浪费2小时”、“错过截止日期”、“流失”）
适应： 使用上下文中的角色（原型角色、JTBD、客户研究）
用户响应： [详细描述]
代理捕获：
- 谁体验它： [角色/细分]
- 何时/何地： [上下文]
- 后果： [影响]
问题5：谁还有这个问题？谁没有？
代理询问： “谁还有这个问题？（同事、竞争对手、其他领域？）谁没有？”
代理提示：
- 谁还有它： 其他公司、行业或领域有类似问题
- 他们如何处理： 变通方法、解决方案或适应
- 谁没有它： 避免问题的用户/公司（他们有什么不同？）
用户响应： [详细描述]
代理捕获：
- 谁还有它： [示例]
- 谁没有它： [反例]
问题6：谁被遗漏了？谁受益？
代理询问： “谁在对话中被遗漏了？谁在问题存在或不存在时受益？”
代理提示：
- 谁被遗漏了： 边缘化声音、边缘案例、被忽视的利益相关者
- 谁在问题存在时受益： 谁从现状中获益？
- 谁在问题不存在时受益： 谁在问题解决时受损？
示例：
- “入门坏了时谁受益？” → “销售团队无需支持复杂工作流；工程无需构建引导流程”
- “谁被遗漏了？” → “非技术用户、国际客户（仅英文入门）”
用户响应： [详细描述]
代理捕获：
- 谁被遗漏了： [列表]
- 谁受益（问题存在）： [列表]
- 谁受益（问题解决）： [列表]
阶段3：重构
目标： 将见解综合成清晰、可操作的问题陈述和“How Might We”问题。
问题7：重述问题
代理说： “基于我们探索的一切，让我们以新方式重述问题。”
代理使用阶段1-2的见解生成精炼的问题陈述：
模板： “问题是：[谁]挣扎于[完成什么]，因为[根本原因]，导致[后果]。这影响[特定细分]，并因[阶段1的偏见/假设]而被忽视。”
示例（SaaS入门）： “问题是：非技术小型企业主在入门期间难以激活我们的产品，因为我们使用术语密集的UI且缺乏引导工作流，导致24小时内60%放弃。这不成比例地影响没有技术支持的单人创业者，并因我们的团队为有IT部门的企业用户优化而被忽视。”
代理询问： “这个重述捕捉了核心问题吗？应该精炼吗？”
用户响应： [批准或修改]
问题8：创建“How Might We”陈述
代理说： “现在让我们用‘How Might We’陈述使其可操作。”
模板： “我们如何能够[行动以解决问题]以实现[目标/期望条件]？”
示例（SaaS入门）： “我们如何能够通过简单语言提示引导非技术用户完成入门，以实现激活率从40%提高到70%？”
代理询问： “这个HMW陈述设置了正确的解决方案空间吗？应该调整吗？”
用户响应： [批准或修改]
输出：问题框架画布 + HMW陈述
完成流程后，代理输出：
# 问题框架画布：[问题名称]
**日期：** [今天日期]
---
## 阶段1：内省
### 问题是什么？（症状）
[来自Q1的描述]
### 为什么我们还没有解决它？
- [来自Q2的障碍1]
- [障碍2]
- [障碍3]
### 我们如何是问题的一部分？（假设和偏见）
- [来自Q3的假设1]
- [假设2]
- [假设3]
**这些中哪些可能被重新设计、重新框架或移除？**
[对要挑战的偏见的反思]
---
## 阶段2：外视
### 谁体验这个问题？
**谁：** [来自Q4的角色/细分]
**何时/何地：** [上下文]
**后果：** [对用户的影响]
**生活体验变化：** [不同用户如何不同体验]
### 谁还有这个问题？
**谁还有：** [来自Q5的示例]
**他们如何处理：** [变通方法]
### 谁没有它？
[来自Q5的反例]
### 谁被遗漏了？
[来自Q6的边缘化声音]
### 谁受益？
**当问题存在时：** [现状的受益人]
**当问题不存在时：** [解决时谁受损]
---
## 阶段3：重构
### 换一种说法，问题是：
[来自Q7的精炼问题陈述]
### How Might We...
**我们如何能够** [来自Q8的行动] **以实现** [来自Q8的目标]？
---
## 下一步
1. **与用户验证：** 使用`skills/discovery-interview-prep/SKILL.md`用客户测试重新框架的问题
2. **生成解决方案：** 使用`skills/opportunity-solution-tree/SKILL.md`探索解决方案空间
3. **创建问题陈述：** 使用`skills/problem-statement/SKILL.md`为PRD/路线图形式化
4. **识别机会：** 使用HMW陈述头脑风暴解决方案想法
---
**准备好探索解决方案了吗？让我知道如果您想精炼问题框架或转向解决方案生成。**
示例
查看examples/sample.md获取完整问题框架示例。
迷你示例摘录：
**内省：** 入门更改后流失激增
**外视：** 新SMB用户受影响最大
**重构：** 我们如何能够为首次用户减少入门摩擦？
常见陷阱
陷阱1：跳过“内省”（假设你是中立的）
症状： 团队直接跳到“外视”，没有检查偏见
后果： 群体思维持续，假设未挑战
修复： 强制明确讨论假设和偏见（Q2-Q3）
陷阱2：忽视“谁受益”问题
症状： 画布完成时没有探索谁从问题存在中受益
后果： 错过政治动态、变革阻力
修复： 总是问“谁在问题解决时受损？”（Q6）
陷阱3：通用问题陈述
症状： 重新框架的问题模糊（“改进用户体验”）
后果： HMW陈述不可操作
修复： 使问题具体化（谁、什么、何时、后果、根本原因）
陷阱4：HMW陈述太窄
症状： “我们如何能够添加移动应用？”
后果： 将解决方案空间限制为一个想法
修复： 保持HMW宽泛：“我们如何能够让移动优先用户在任何设备上访问核心工作流？”
陷阱5：单人练习（无多样化视角）
症状： PM单独填写画布
后果： 偏见持续，边缘化声音仍被遗漏
修复： 与跨职能团队 + 客户输入引导画布研讨会
参考
相关技能
skills/problem-statement/SKILL.md— 将重新框架的问题转换为正式问题陈述skills/opportunity-solution-tree/SKILL.md— 使用HMW陈述生成解决方案选项skills/discovery-interview-prep/SKILL.md— 用客户验证重新框架的问题
外部框架
- MITRE创新工具包，“问题框架画布v3”（2021） — 画布起源，以公平为导向的设计思维
- 斯坦福d.school，“How Might We”陈述 — 可操作问题框架
Dean的工作
- [如果Dean有问题框架资源，链接此处]
技能类型： 交互式
建议文件名： problem-framing-canvas.md
建议位置： /skills/interactive/
依赖项： 使用skills/problem-statement/SKILL.md