# Pm Method Build Trap

> 《Escaping the Build Trap》方法论。把 Melissa Perri 的成效导向产品管理转化为可执行框架， 用于：判断团队是否陷入"功能工厂"、把战略拆成可落地的成效、用产品 kata 系统性验证。 每条规则标注原书章节，可追溯。 触发词：「Escaping the Build Trap」「跳出功能陷阱」「功能工厂」「build trap」「outcome over output」 「product kata」「产品运营模型」「战略部署」及"忙着做功能但不知道有没有用"类场景。

- Skill: `spacezephyr/pm-method-build-trap` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add spacezephyr/pm-method-build-trap`
- Raw SKILL.md: https://api.skillmd.com/api/skills/spacezephyr/pm-method-build-trap/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: spacezephyr (https://skillmd.com/u/spacezephyr)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/spacezephyr/pm-method-build-trap

---


# 《Escaping the Build Trap》 · 别用"做了多少功能"衡量成功，用"创造了多少成效"

## 什么时候用我

- 团队很忙、上线很多，但说不清带来了什么价值 → 用【功能陷阱自检】
- 战略是一堆口号，落不到团队每天做什么 → 用【战略部署四层】
- 想系统性地"选问题→定方向→验证" → 用【产品 Kata】
- 不适合：具体访谈话术（见 pm-method-mom-test）、需求结构化切片（见 pm-method-story-mapping）。本书解决"组织层面为什么在做无用功、怎么转向成效"。

## 核心框架

### 框架 1：功能陷阱自检（The Build Trap，第一部分）

适用场景：判断团队/组织是不是在用"产出"冒充"价值"。

步骤：
1. 看团队被衡量的是什么：交付的功能数量（output）还是达成的成效（outcome）？
2. 看路线图形态：是一串带日期的功能清单，还是一组要达成的业务/用户成效？
3. 看需求来源：是老板/销售塞进来的功能，还是从战略与用户问题推导出来的？
4. 输出：陷阱程度诊断 + 最该先改的一个信号（衡量方式/路线图/需求来源）

### 框架 2：战略部署四层（Strategy Deployment，第三部分）

适用场景：把高层战略连到团队每天的工作，消除"战略与执行脱节"。

步骤：
1. **愿景（Vision）** → 我们最终要去哪
2. **战略意图（Strategic Intent）** → 当前阶段公司级的少数关键方向
3. **产品行动（Product Initiative）** → 为实现意图，产品要解决的问题/追的成效
4. **选项（Options / Experiments）** → 解决问题的候选方案与验证
   逐层对齐，每一层都能回答"它服务上一层的什么"。
5. 输出：一张从愿景贯穿到具体产品行动的对齐地图

### 框架 3：产品 Kata（The Product Kata，第二部分）

适用场景：系统性地从"现状"逼近"方向"，用实验而非拍脑袋推进。

步骤（循环）：
1. 方向（Direction）：我们要达成的成效是什么？
2. 现状（Current Condition）：现在离它多远、数据是什么？
3. 下一个目标（Target Condition）：这一步要达到的可度量状态
4. 障碍与实验：挡在路上的是什么？下一个最小实验验证什么？
5. 跑实验 → 学习 → 回到第 2 步循环
6. 输出：一个可反复迭代的"目标—障碍—实验"节奏

## 决策规则（来源标注）

1. 如果团队用"交付了多少功能"衡量成功，则你在功能陷阱里——改用成效指标。（第一部分）
2. 如果路线图是"带日期的功能清单"，则重写成"要达成的成效 + 待验证的选项"。（第三部分）
3. 如果一个需求答不出"它服务哪个战略意图/解决哪个用户问题"，则暂缓,先补这个连接。（第三部分）
4. 如果不确定方案对不对，则用产品 kata 设最小实验去验，而不是直接排期做完。（第二部分）
5. 产品经理的角色是"价值交换的管理者"，不是"接需求的项目经理"——用这条校准 PM 的日常。（第二部分）
6. 如果战略只有愿景没有中间层，则团队必然各自为战——补齐战略意图与产品行动两层。（第三部分）
7. 好战略是"决定不做什么"的框架，不是"什么都要"的清单。（第三部分）

## 检查清单：跳出功能陷阱（综合全书）

- [ ] 团队的成功指标是成效（用户行为/业务结果），不是功能数量
- [ ] 路线图表达的是要达成的成效与待验证选项，不是承诺的功能清单
- [ ] 每个在做的东西都能连到一个战略意图和一个用户问题
- [ ] 团队有明确方向，并用实验（product kata）逼近它
- [ ] PM 花在"理解问题与验证"上的时间，不少于"写需求交付"
- [ ] 存在从愿景→战略意图→产品行动→选项的完整链条
- [ ] 有勇气对"不服务战略的需求"说不

## 反模式（书中明确警告）

1. 功能工厂（feature factory）——把忙碌和交付量当成价值，成效无人负责。（第一部分）
2. 把路线图当承诺清单——锁死一堆带日期的功能，丧失按学习调整的能力。（第三部分）
3. 项目制思维——做完就散、只对上线负责，不对成效负责。（第二部分）
4. 战略只剩口号——有愿景没有中间层，执行层只能自行脑补。（第三部分）
5. 靠"英雄式 PM/老板拍板"而非可复制的产品流程与组织能力。（第四部分）

## 边界声明

- 出版于 2018 年，方法稳定；它诊断的是"组织/战略层面的做无用功"，不提供具体访谈或交付切片的操作细节
- 适用：有一定规模、需要战略—执行对齐的产品组织；对极早期单人/小团队，四层战略部署可精简
- "成效导向"依赖能定义并度量成效的环境；成效难量化（平台、合规、基础设施）时需谨慎套用
- 与 Cagan 的"产品运营模型"高度共鸣，二者可互为印证；重叠处以本书的"战略部署 + 产品 kata"操作层为主
- 章节归属若按二手资料提炼有出入，以原书为准

## 工作流

收到用户问题后：
1. 匹配场景 → 选框架（功能陷阱自检 / 战略部署 / 产品 kata）
2. 缺核心输入（团队目标、现有路线图形态、战略）→ 一次性列出需补的信息；需要行业事实用 WebSearch，不编造
3. 按框架步骤执行，给出逐步中间产出（诊断结论 / 战略对齐地图 / kata 循环）
4. 用"跳出功能陷阱检查清单"复核，标注未通过项
5. 结尾声明边界，提示可换视角交叉验证（如"具体该验哪个假设，用 pm-advisor-torres 的 assumption test"）

> 本 Skill 由 career-skill-factory 生成。内容提炼自原著，版权归原作者 Melissa Perri，仅供个人学习。