PM Skills Repo 精华提炼：对我真正有用的三个框架¶
来源： deanpeters/Product-Manager-Skills 整理时间： 2026-03-24 背景： 我同时在跑多个个人项目（求职备考、爱好调研、女性主义AI项目等），需要一套轻量的项目管理思维。这个 repo 被广泛称赞，但大多数内容是执行工具（PRD、user story、roadmap），对我没用。真正有价值的是以下三个框架——它们不是"PM工具"，而是把我已有的方法论原教旨主义打包成了更严谨的操作协议。
为什么这三个？¶
我已经有的：质疑问题定义、research 方法论（Research Hacker）、hypothesis-driven 思维。
我缺的：在投入之前的验证纪律——即"我到底在测什么假设""这个假设怎么用最小代价证伪"。
这三个框架补的正是这个缺口。
框架一：Problem Framing Canvas（MITRE）¶
来源文件： skills/problem-framing-canvas/SKILL.md
核心价值： 在"我们要解决什么问题"上达成真正的共识，而不是跳进解决方案
三阶段结构¶
┌────────────────────────────────────────────┐
│ LOOK INWARD（向内看） │
│ - 问题的症状是什么？ │
│ - 为什么还没被解决？ │
│ - 我们自己怎么成为了问题的一部分？ │
└────────────────────────────────────────────┘
┌────────────────────────────────────────────┐
│ LOOK OUTWARD（向外看） │
│ - 谁有这个问题？什么时候？后果是什么？ │
│ - 谁没有这个问题？（反例） │
│ - 谁被忽视了？ │
│ - 当问题存在/消失时，谁受益？ │
└────────────────────────────────────────────┘
┌────────────────────────────────────────────┐
│ REFRAME（重新定义问题） │
│ - 换一种说法，问题是：[重新表述] │
│ - How Might We [行动] as we aim to [目标]? │
└────────────────────────────────────────────┘
最关键的一步：Look Inward 里的第三问¶
"我们自己怎么成为了问题的一部分？"
这是 Research Hacker 没有显式要求的。常见的自我嵌入偏见： - 我们以为自己知道用户要什么（confirmation bias） - 我们在为自己的方便而优化，不是用户的价值（internal bias） - 我们聚焦了大多数用户，忽略了边缘群体（survivorship bias） - 我们已经在心里锁定了解决方案（premature convergence）
对女性主义 AI 项目的直接意义： AI 工具本身可能复制性别偏见。"我们自己是问题的一部分"这一步，在这个项目里不是可选项，是必选项——要在问题定义阶段就强制回答。
常见陷阱¶
| 陷阱 | 症状 | 修复 |
|---|---|---|
| 跳过 Look Inward | 直接从"用户有什么问题"开始 | 强制先讨论自身假设和偏见 |
| 忽略"谁受益于问题存在" | 没问"解决问题之后谁会反对" | 必问：谁在现状中获益？ |
| 问题陈述太模糊 | "改善用户体验" | 要有 who / what / when / consequence / root cause |
| HMW 太窄 | "我们能不能加一个移动端 App" | HMW 应该保持解空间开放，不要锁定方案 |
输出模板¶
# Problem Framing Canvas: [问题名称]
## Look Inward
**问题症状：** [描述]
**为什么还没解决：** [原因]
**我们的假设和偏见：** [列表]
## Look Outward
**谁有这个问题：** [Persona / 群体]
**什么时候 / 哪里：** [情境]
**后果：** [影响]
**谁没有：** [反例，以及为什么]
**谁被忽视了：** [边缘群体]
**谁在现状中获益：** [既得利益方]
## Reframe
**换一种说法，问题是：**
[Who] 在 [情境] 下难以 [做什么]，因为 [根本原因]，导致 [后果]。
这对 [特定群体] 影响最大，长期被忽视是因为 [偏见/假设]。
**How Might We：**
我们如何能 [行动]，同时实现 [目标]？
框架二：Proof of Life Probe（PoL Probe）¶
来源文件： skills/pol-probe/SKILL.md
核心价值： 在投入之前，用最小代价测试最关键的假设
什么是 PoL Probe？¶
不是 MVP，不是 pilot，是侦察任务。
"最贵的测试方式是直接做生产级软件。" — Jeff Patton
PoL probe 的设计原则是：做完即扔。如果一个原型精致到舍不得删，它就不是 probe，而是 prototype theater（原型剧场）。
5 个必须满足的特征¶
| 特征 | 含义 | 为什么重要 |
|---|---|---|
| Lightweight | 小时/天，不是周 | 贵了就不敢砍 |
| Disposable | 明确计划删除 | 防止沉没成本效应 |
| Narrow Scope | 只测一个假设 | 宽泛实验 = 模糊结论 |
| Brutally Honest | 主动寻找反驳，不是验证 | 礼貌的数据没有价值 |
| Tiny & Focused | 侦察，不是攻占 | 小 = 快速学习循环 |
PoL Probe vs MVP¶
| 维度 | PoL Probe | MVP |
|---|---|---|
| 目的 | 用窄假设消除风险 | 最小可交付产品 |
| 范围 | 单一问题、单一风险 | 最小可上线功能集 |
| 生命周期 | 小时到天，然后删除 | 几周到几月，然后迭代 |
| 受众 | 内部团队 + 极小用户样本 | 真实用户，生产环境 |
| 结论 | 学到什么不可行 | 学到什么可行 |
关系： PoL probe 是 MVP 之前的侦察。你先跑 probe 来决定要不要做 MVP。
5 种 Probe 类型¶
| 类型 | 核心问题 | 时长 | 适用场景 |
|---|---|---|---|
| Feasibility Check | 技术上能做到吗？ | 1-2 天 | 技术风险未知、依赖第三方 |
| Task-Focused Test | 用户能顺畅完成任务吗？ | 2-5 天 | 关键流程节点（填表、决策、跳出点） |
| Narrative Prototype | 这个方向能获得认同吗？ | 1-3 天 | 需要"讲故事"而不是"测功能"时 |
| Synthetic Data Simulation | 不用生产数据能模拟结果吗？ | 2-4 天 | 边界情况探索、未知风险挖掘 |
| Vibe-Coded PoL Probe | 这个解法在真实用户接触中能存活吗？ | 2-3 天 | 需要用户反馈但不做生产代码 |
黄金法则： 用能说出最刺耳真相的最便宜方式。如果结果不让你难受，它可能只是剧场。
PoL Probe 模板¶
# PoL Probe: [描述性名称]
## 假设
[一句话：我相信……]
示例："如果我们把注册表单缩减到3个字段，完成率会超过80%。"
## 正在消除的风险
[这个 probe 针对什么具体风险或未知？]
## Probe 类型
- [ ] Feasibility Check
- [ ] Task-Focused Test
- [ ] Narrative Prototype
- [ ] Synthetic Data Simulation
- [ ] Vibe-Coded PoL Probe
## 目标用户/受众
[谁来参与这个 probe？样本多大？]
## 成功标准（必须刺耳）
- **Pass：** [通过条件]
- **Fail：** [失败条件]
- **Learn：** [无论结果如何，想观察什么]
## 工具/方法
[用什么来做？]
## 时间线
- Build: [X天]
- Test: [X天]
- Analyze: [X天]
- **Disposal date: [具体日期]** ← 必须写
## 处置计划
[什么时候、怎么删除这个 probe？]
## 状态
- [ ] 假设已定义
- [ ] Probe 已构建
- [ ] 用户已招募
- [ ] 测试完成
- [ ] 学习已记录
- [ ] Probe 已删除
什么时候不用 PoL Probe¶
- 想让高层看了印象深刻 → 那是 prototype theater
- 已经知道答案只是想要验证 → 那是 confirmation bias
- 假设太宽泛（"用户会喜欢吗？"）→ 先把假设说清楚
- 用它来逃避做决定 → 不行
框架三：Epic Hypothesis（史诗假设）¶
来源文件： skills/epic-hypothesis/SKILL.md
核心价值： 把每个项目/倡议写成可证伪的 if/then 假设，而不是承诺
核心结构¶
If we [具体行动 / 解法]
for [目标用户 / 受益人]
Then we [可测量的结果，不是功能]
We will test our assumption by:
- [实验 1：轻量、快速]
- [实验 2]
We know our hypothesis is valid if within [时间窗口]
we observe:
- [量化指标]
- [质化指标]
为什么这个结构有力¶
- Hypothesis-driven： 强迫你说清楚你相信什么（以及你可能错在哪）
- Outcome-focused： "Then we will" 是用户/受益人的结果，不是功能输出
- Falsifiable： 有明确成功标准，才能真正"砍掉"一个坏想法
- Treats projects as bets： 项目是你在押注，不是承诺
好 vs 坏的 Epic Hypothesis¶
| 坏的写法 | 为什么不行 | 好的写法 |
|---|---|---|
| "做一个 dashboard" | 这是功能，不是假设 | "如果我们做实时任务状态 dashboard，PM 每周花在追进度上的时间会减少 50%" |
| "用户会喜欢它" | 不可测量 | "80% 的受访用户表示他们愿意为此付费" |
| "一年内收入增长" | 太慢太模糊 | "4周内激活率从40%上升到50%" |
| "我们承诺Q2交付" | 把假设变成了承诺 | 在做出承诺之前先跑 epic hypothesis |
实验类型（Tiny Acts of Discovery）¶
不需要做生产代码。可以用： - Prototype + user testing： 可点击原型，测5-10个用户 - Concierge test： 手动为几个用户完成那个"功能"，看他们是否重视 - Landing page test： 描述该功能，测量注册量或兴趣 - Wizard of Oz test： 对用户呈现"自动化功能"，但后台手动完成 - A/B test： 轻量版 vs 对照组
对多项目管理的实际用法¶
我现在同时在跑的项目（近似）： - 求职备考（Sr MLE/AIE 方向） - 女性主义 AI 项目（与小伙伴合作探索） - 调研爱好（Research Hacker、论文研读） - content-moderation-sim（ABM 仿真）
对每个项目用 Epic Hypothesis 写一句话，立刻就知道哪个还没有清晰假设，哪个根本没有验证路径：
## 求职备考
If we complete 12-week MLE/AIE prep plan
for me transitioning from Senior DS to Senior MLE/AIE
Then I will be competitive for Tier 1 recsys roles (Meta, Google, TikTok)
→ Validation: 至少拿到一个 Tier 1 final round
## 女性主义 AI 项目
If we [??? — 这里还没有清晰的行动]
for [??? — 目标用户还没定义]
Then we will [??? — 还没有可测量结果]
→ 诊断：这个项目需要先做 Problem Framing Canvas
这个练习的价值在于：假设写不出来 = 项目定义还没想清楚。不是执行问题，是问题定义问题。
附：Jobs-to-be-Done（JTBD）— 备用工具¶
来源文件： skills/jobs-to-be-done/SKILL.md
什么时候用： 女性主义 AI 项目做用户研究时
JTBD 把用户需求拆成三层：
Customer Jobs（用户在试图完成什么） - Functional jobs：任务层（"我要做什么"） - Social jobs：社会认同层（"我想被怎么看待"） - Emotional jobs：情感层（"我想感受到什么 / 避免感受到什么"）
Pains（障碍） - Challenges：阻碍完成任务的障碍 - Costliness：时间、金钱、精力上的代价 - Common mistakes：可预防的常见错误 - Unresolved problems：现有方案的盲区
Gains（收益） - Expectations：超出预期的部分 - Savings：节省时间/金钱/精力 - Adoption factors：促使切换的因素 - Life improvement：生活质量如何提升
核心洞见： Social 和 Emotional jobs 往往比 Functional jobs 更驱动采用。问"你希望别人怎么看你？"和"解决了这个问题你会有什么感受？"往往比"你想要什么功能"更有价值。
陷阱： 不做用户访谈就填 JTBD 模板 = 猜测不是发现。先采访，再填框架。
三个框架的使用顺序¶
新项目启动时：
1. Problem Framing Canvas
→ 确保问题被正确定义，且你自己不是问题的一部分
2. Epic Hypothesis（用 JTBD 辅助填充 "for [persona]" 和 "then we will"）
→ 把项目写成可证伪的赌注
3. PoL Probe
→ 用最小代价测试最高风险的假设
→ 确认可以投入更多之后，才真正开始
与我已有工具的关系¶
| 已有工具 | 这三个框架补充了什么 |
|---|---|
| Research Hacker（调研方法论） | Problem Framing Canvas 的 Look Inward 是 RH 没有显式要求的 |
| 方法论原教旨主义（先质疑问题定义） | Epic Hypothesis 把这个内化为项目管理的操作协议 |
| content-moderation-sim（ABM） | PoL Probe 可以用来在完整实现前先跑 Feasibility Check |
| 女性主义 AI 项目（探索期） | 三个框架都适用，且顺序很重要 |
来源 repo： https://github.com/deanpeters/Product-Manager-Skills 整理人： Cindy / Claude Sonnet 4.6