Problem Framing Canvas

问题框架画布 (Problem Framing Canvas)

版本：v1.0.0
创建：2026-03-09
作者：Elatia 🌀 (基于 Product-Manager-Skills 提炼)
许可：MIT
类型：Interactive Skill

📋 技能描述

面向场景: 复杂问题需要系统分析、团队对问题理解不一致、需要结构化问题拆解
目标用户: 产品经理、战略顾问、项目负责人
核心价值: 使用结构化画布全面分析问题，避免片面理解，建立系统性认知

🎯 核心能力

1. 九宫格问题框架

覆盖问题的 9 个关键维度：

• 问题描述（What）
• 用户/客户（Who）
• 影响范围（Scale）
• 根本原因（Why）
• 现有方案（Current）
• 成功标准（Success）
• 约束条件（Constraints）
• 利益相关者（Stakeholders）
• 风险假设（Risks）

2. 交互式填写

引导式问题填写每个象限：

• 逐层深入的问题
• 示例参考
• 质量检查

3. 框架完整性检查

自动识别缺失或薄弱的维度：

• 空白警示
• 模糊描述提醒
• 逻辑一致性验证

🔧 使用方式

方式 1: 交互式引导（推荐）

/problem-framing-canvas

画布填写流程:

1. 问题描述 (What)

用一句话清晰描述问题

• 问题是什么？
• 不是什么？（边界）

2. 用户/客户 (Who)

谁受到这个问题影响？

• 主要用户：[角色]
• 次要用户：[角色]
• 决策者：[角色]

3. 影响范围 (Scale)

问题的规模和严重程度

• 影响人数：[量化]
• 业务影响：[量化]
• 紧急程度：[高/中/低]

4. 根本原因 (Why)

使用 5 Why 分析法

• 表层原因：[直接原因]
• 深层原因：[根本原因]

5. 现有方案 (Current)

当前如何应对这个问题

• 内部方案：[现有做法]
• 外部方案：[市场竞品]
• 方案局限：[为什么不够]

6. 成功标准 (Success)

如何判断问题已解决

• 定量指标：[可衡量的指标]
• 定性指标：[可感知的变化]

7. 约束条件 (Constraints)

解决问题的限制因素

• 时间约束：[deadline]
• 资源约束：[预算/人力]
• 技术约束：[技术限制]
• 政策约束：[合规要求]

8. 利益相关者 (Stakeholders)

谁会受影响/谁能影响结果

• 支持者：[谁会支持]
• 反对者：[谁会反对]
• 中立者：[谁需要争取]

9. 风险假设 (Risks)

需要验证的假设和潜在风险

• 关键假设：[需要验证的]
• 潜在风险：[可能出问题的]

方式 2: 快速模式

/problem-framing-canvas quick \
  --problem "销售方案生成效率低" \
  --users "销售人员，销售总监" \
  --impact "每周 20 小时/人，成单率 15%" \
  --goal "30 分钟内完成方案，成单率 25%"

📝 输出模板

# Problem Framing Canvas: [问题名称]

## 📋 画布总览

| 维度 | 内容摘要 |
|------|----------|
| What | [一句话问题描述] |
| Who | [主要用户/客户] |
| Scale | [影响范围] |
| Why | [根本原因] |
| Current | [现有方案] |
| Success | [成功标准] |
| Constraints | [约束条件] |
| Stakeholders | [利益相关者] |
| Risks | [风险假设] |

## 详细分析

### 1. 问题描述 (What)
**问题是什么**:
[详细描述]

**问题不是什么** (边界):
- [范围外 1]
- [范围外 2]

### 2. 用户/客户 (Who)
**主要用户**:
- [角色 1]: [描述 + 痛点]
- [角色 2]: [描述 + 痛点]

**决策者**:
- [角色]: [关注点]

### 3. 影响范围 (Scale)
**量化影响**:
- 影响人数：[数据]
- 时间成本：[数据]
- 金钱成本：[数据]

**业务影响**:
- [影响 1]
- [影响 2]

**紧急程度**: [高/中/低]  
**重要程度**: [高/中/低]

### 4. 根本原因 (Why)
**5 Why 分析**:
1. Why: [问题 1] → [答案 1]
2. Why: [问题 2] → [答案 2]
3. Why: [问题 3] → [答案 3]
4. Why: [问题 4] → [答案 4]
5. Why: [问题 5] → [答案 5]

**根本原因**:
[总结]

### 5. 现有方案 (Current)
**内部现有做法**:
- [做法 1]: [效果 + 局限]
- [做法 2]: [效果 + 局限]

**市场现有方案**:
- [竞品 1]: [优势 + 不足]
- [竞品 2]: [优势 + 不足]

**为什么现有方案不够**:
- [原因 1]
- [原因 2]

### 6. 成功标准 (Success)
**定量指标**:
- [指标 1]: [当前值] → [目标值]
- [指标 2]: [当前值] → [目标值]

**定性指标**:
- [指标 1]: [期望状态]
- [指标 2]: [期望状态]

**时间框架**:
- 短期（1 月）: [里程碑]
- 中期（3 月）: [里程碑]
- 长期（6 月+）: [里程碑]

### 7. 约束条件 (Constraints)
**时间约束**:
- [约束描述]

**资源约束**:
- 预算：[金额]
- 人力：[人数/角色]

**技术约束**:
- [技术限制]

**政策/合规约束**:
- [合规要求]

### 8. 利益相关者 (Stakeholders)
**支持者** (Who wants this to succeed):
- [角色 1]: [利益点]
- [角色 2]: [利益点]

**反对者** (Who might resist):
- [角色 1]: [担忧点]
- [角色 2]: [担忧点]

**中立者** (Who needs to be convinced):
- [角色 1]: [关注点]
- [角色 2]: [关注点]

### 9. 风险假设 (Risks)
**关键假设** (需要验证):
- ⚠️ 假设 1: [描述] - 验证方法：[方法]
- ⚠️ 假设 2: [描述] - 验证方法：[方法]

**潜在风险**:
- 🔴 高风险: [风险描述 + 应对]
- 🟡 中风险: [风险描述 + 应对]
- 🟢 低风险: [风险描述 + 应对]

## 框架完整性检查

| 维度 | 完整度 | 质量 |
|------|--------|------|
| What | ✅ 完整 | 🟢 清晰 |
| Who | ✅ 完整 | 🟢 清晰 |
| Scale | ⚠️ 部分 | 🟡 需量化 |
| Why | ✅ 完整 | 🟢 清晰 |
| Current | ✅ 完整 | 🟢 清晰 |
| Success | ✅ 完整 | 🟢 清晰 |
| Constraints | ✅ 完整 | 🟢 清晰 |
| Stakeholders | ⚠️ 部分 | 🟡 需补充 |
| Risks | ✅ 完整 | 🟢 清晰 |

## 下一步行动

### 立即行动 (本周)
- [行动 1]: [负责人]
- [行动 2]: [负责人]

### 验证行动 (本月)
- [验证假设 1]: [方法 + 时间]
- [验证假设 2]: [方法 + 时间]

### 决策点
- [日期]: [需要做的决策]

📚 示例

示例：销售方案效率问题

# Problem Framing Canvas: 销售方案生成效率低

## 📋 画布总览

| 维度 | 内容摘要 |
|------|----------|
| What | 销售人员每次从零开始写方案，平均耗时 2 小时，效率低质量不稳定 |
| Who | 销售人员（15 人）、销售总监、客户 |
| Scale | 每周 30 小时/团队，成单率 15%，人力成本高 |
| Why | 缺乏模板和知识库，依赖个人经验 |
| Current | 个人经验 + 历史方案复用，效果有限 |
| Success | 30 分钟/方案，成单率 25%，满意度≥4/5 |
| Constraints | 预算 50 万，3 个月上线，不能影响现有业务 |
| Stakeholders | 销售团队支持，IT 部门中立，财务关注 ROI |
| Risks | 假设销售愿意用新工具，风险是 adoption rate 低 |

## 详细分析

### 1. 问题描述 (What)
**问题是什么**:
销售人员每次拜访客户后，需要从零开始撰写解决方案 PPT，平均耗时 2 小时/份，且质量依赖个人经验，导致：
- 新人产出慢且质量差
- 资深销售重复劳动多
- 整体成单率仅 15%

**问题不是什么** (边界):
- 不是 CRM 系统问题（客户管理已有系统）
- 不是销售能力问题（核心是工具支持不足）
- 不是合同/报价问题（那是后续流程）

### 2. 用户/客户 (Who)
**主要用户**:
- 销售人员（15 人）: 需要快速生成高质量方案，减少加班
- 销售新人（5 人）: 需要模板和指导，快速上手

**决策者**:
- 销售总监张经理：关注成单率和团队效率

**间接受益者**:
- 客户：获得更专业、更及时的方案
- 公司：提升整体销售业绩

### 3. 影响范围 (Scale)
**量化影响**:
- 影响人数：15 人销售团队
- 时间成本：2 小时/方案 × 10 方案/周 = 20 小时/人/周
- 团队成本：300 小时/周 ≈ 7.5 人天/周
- 成单率：15%（行业平均 25%）

**业务影响**:
- 人力成本高：大量时间用于重复劳动
- 机会损失：成单率低，年损失约 500 万
- 团队士气：加班严重，流失率高

**紧急程度**: 高  
**重要程度**: 高

### 4. 根本原因 (Why)
**5 Why 分析**:
1. Why: 为什么方案生成慢？ → 每次从零开始
2. Why: 为什么从零开始？ → 没有可复用的模板
3. Why: 为什么没有模板？ → 没有系统沉淀最佳实践
4. Why: 为什么没有沉淀？ → 缺乏知识管理意识和工具
5. Why: 为什么缺乏？ → 过去业务增长快，忽视了效率优化

**根本原因**:
业务快速增长期忽视了知识沉淀和工具建设，导致销售方案能力无法规模化复制。

### 5. 现有方案 (Current)
**内部现有做法**:
- 历史方案复用：找类似客户的方案修改 → 耗时且可能不匹配
- 资深销售带新人：口传心授 → 不可规模化
- 个人模板：每人有自己的模板 → 质量参差不齐

**市场现有方案**:
- PPT 模板网站：通用模板多，行业化不足
- 方案代写服务：质量好但成本高（5000 元/份）
- CRM 内置方案模块：功能简单，不够灵活

**为什么现有方案不够**:
- 不够行业化：通用模板不适合 B2B 销售场景
- 不够智能：不能根据客户需求自动推荐内容
- 不够易用：学习成本高，销售不愿意用

### 6. 成功标准 (Success)
**定量指标**:
- 方案生成时间：2 小时 → 30 分钟
- 成单率：15% → 25%
- 销售满意度：2.5/5 → 4/5
- 新人上手时间：3 月 → 2 周

**定性指标**:
- 销售感到"有支持，不孤单"
- 客户感到"方案专业，懂我需求"
- 管理层感到"可预测，可管理"

**时间框架**:
- 短期（1 月）: MVP 上线，10 个模板
- 中期（3 月）: 全团队使用，覆盖 80% 场景
- 长期（6 月+）: AI 智能推荐，持续优化

### 7. 约束条件 (Constraints)
**时间约束**:
- 3 个月内必须上线（Q2 结束前）

**资源约束**:
- 预算：50 万（含开发 + 运营）
- 人力：2 个开发 +1 个产品 +1 个设计

**技术约束**:
- 必须与现有 CRM 系统集成
- 支持 PPT 导出（.pptx 格式）

**政策/合规约束**:
- 客户数据不能出境
- 符合公司信息安全规范

### 8. 利益相关者 (Stakeholders)
**支持者**:
- 销售团队：直接受益，减少加班
- 销售总监：成单率提升，业绩好

**反对者**:
- 资深销售：担心"被替代"，不愿分享经验
- IT 部门：担心增加维护负担

**中立者**:
- 财务部门：关注 ROI，需要数据说服
- HR 部门：关注培训成本

### 9. 风险假设 (Risks)
**关键假设** (需要验证):
- ⚠️ 假设 1: 销售愿意使用新工具生成方案 → 验证：MVP 测试，跟踪 adoption rate
- ⚠️ 假设 2: 模板化方案不会降低客户感知 → 验证：A/B 测试，对比成单率
- ⚠️ 假设 3: 30 分钟目标是可行的 → 验证：原型测试，计时验证

**潜在风险**:
- 🔴 高风险: 销售 adoption rate 低 (<50%) → 应对：早期深度参与，激励机制
- 🟡 中风险: 模板质量不够 → 应对：资深销售审核，持续迭代
- 🟢 低风险: 技术延期 → 应对：MVP 范围可控，有 buffer

## 框架完整性检查

| 维度 | 完整度 | 质量 |
|------|--------|------|
| What | ✅ 完整 | 🟢 清晰 |
| Who | ✅ 完整 | 🟢 清晰 |
| Scale | ✅ 完整 | 🟢 清晰 |
| Why | ✅ 完整 | 🟢 清晰 |
| Current | ✅ 完整 | 🟢 清晰 |
| Success | ✅ 完整 | 🟢 清晰 |
| Constraints | ✅ 完整 | 🟢 清晰 |
| Stakeholders | ✅ 完整 | 🟢 清晰 |
| Risks | ✅ 完整 | 🟢 清晰 |

## 下一步行动

### 立即行动 (本周)
- 访谈 5 个销售，收集历史方案：产品经理
- 竞品分析（3 家）：产品经理

### 验证行动 (本月)
- 验证假设 1: 制作低保真原型，找 3 个销售试用
- 验证假设 2: 收集 20 个历史方案，分析共性

### 决策点
- 3 月 15 日：是否立项（基于 MVP 测试结果）

🎯 质量标准

好的问题框架画布

• ✅ 九个维度完整（没有明显缺失）
• ✅ 描述具体（有数据有细节）
• ✅ 逻辑一致（各维度相互支撑）
• ✅ 假设明确（标注需要验证的）
• ✅ 可执行（有下一步行动）

常见陷阱

• ❌ 维度缺失（跳过某些象限）
• ❌ 描述模糊（"提升效率"太抽象）
• ❌ 逻辑矛盾（成功标准与约束冲突）
• ❌ 假设隐藏（把猜测当事实）
• ❌ 没有行动（分析完就结束了）

🔗 与其他技能的关系

📈 成功指标

🔖 版本历史

📄 许可

MIT License

基于 Product-Manager-Skills by Dean Peters · CC BY-NC-SA 4.0
适配 OpenClaw 标准：Elatia 🌀