spacezephyr 《Escaping the Build Trap》 · 别用"做了多少功能"衡量成功，用"创造了多少成效"
什么时候用我
- 团队很忙、上线很多，但说不清带来了什么价值 → 用【功能陷阱自检】
- 战略是一堆口号，落不到团队每天做什么 → 用【战略部署四层】
- 想系统性地"选问题→定方向→验证" → 用【产品 Kata】
- 不适合：具体访谈话术（见 pm-method-mom-test）、需求结构化切片（见 pm-method-story-mapping）。本书解决"组织层面为什么在做无用功、怎么转向成效"。
核心框架
框架 1：功能陷阱自检（The Build Trap，第一部分）
适用场景：判断团队/组织是不是在用"产出"冒充"价值"。
步骤：
- 看团队被衡量的是什么：交付的功能数量（output）还是达成的成效（outcome）？
- 看路线图形态：是一串带日期的功能清单，还是一组要达成的业务/用户成效？
- 看需求来源：是老板/销售塞进来的功能，还是从战略与用户问题推导出来的？
- 输出：陷阱程度诊断 + 最该先改的一个信号（衡量方式/路线图/需求来源）
框架 2：战略部署四层（Strategy Deployment，第三部分）
适用场景：把高层战略连到团队每天的工作，消除"战略与执行脱节"。
步骤：
- 愿景（Vision） → 我们最终要去哪
- 战略意图（Strategic Intent） → 当前阶段公司级的少数关键方向
- 产品行动（Product Initiative） → 为实现意图，产品要解决的问题/追的成效
- 选项（Options / Experiments） → 解决问题的候选方案与验证 逐层对齐，每一层都能回答"它服务上一层的什么"。
- 输出：一张从愿景贯穿到具体产品行动的对齐地图
框架 3：产品 Kata（The Product Kata，第二部分）
适用场景：系统性地从"现状"逼近"方向"，用实验而非拍脑袋推进。
步骤（循环）：
- 方向（Direction）：我们要达成的成效是什么？
- 现状（Current Condition）：现在离它多远、数据是什么？
- 下一个目标（Target Condition）：这一步要达到的可度量状态
- 障碍与实验：挡在路上的是什么？下一个最小实验验证什么？
- 跑实验 → 学习 → 回到第 2 步循环
- 输出：一个可反复迭代的"目标—障碍—实验"节奏
决策规则（来源标注）
- 如果团队用"交付了多少功能"衡量成功，则你在功能陷阱里——改用成效指标。（第一部分）
- 如果路线图是"带日期的功能清单"，则重写成"要达成的成效 + 待验证的选项"。（第三部分）
- 如果一个需求答不出"它服务哪个战略意图/解决哪个用户问题"，则暂缓,先补这个连接。（第三部分）
- 如果不确定方案对不对，则用产品 kata 设最小实验去验，而不是直接排期做完。（第二部分）
- 产品经理的角色是"价值交换的管理者"，不是"接需求的项目经理"——用这条校准 PM 的日常。（第二部分）
- 如果战略只有愿景没有中间层，则团队必然各自为战——补齐战略意图与产品行动两层。（第三部分）
- 好战略是"决定不做什么"的框架，不是"什么都要"的清单。（第三部分）
检查清单：跳出功能陷阱（综合全书）
- 团队的成功指标是成效（用户行为/业务结果），不是功能数量
- 路线图表达的是要达成的成效与待验证选项，不是承诺的功能清单
- 每个在做的东西都能连到一个战略意图和一个用户问题
- 团队有明确方向，并用实验（product kata）逼近它
- PM 花在"理解问题与验证"上的时间，不少于"写需求交付"
- 存在从愿景→战略意图→产品行动→选项的完整链条
- 有勇气对"不服务战略的需求"说不
反模式（书中明确警告）
- 功能工厂（feature factory）——把忙碌和交付量当成价值，成效无人负责。（第一部分）
- 把路线图当承诺清单——锁死一堆带日期的功能，丧失按学习调整的能力。（第三部分）
- 项目制思维——做完就散、只对上线负责，不对成效负责。（第二部分）
- 战略只剩口号——有愿景没有中间层，执行层只能自行脑补。（第三部分）
- 靠"英雄式 PM/老板拍板"而非可复制的产品流程与组织能力。（第四部分）
边界声明
- 出版于 2018 年，方法稳定；它诊断的是"组织/战略层面的做无用功"，不提供具体访谈或交付切片的操作细节
- 适用：有一定规模、需要战略—执行对齐的产品组织；对极早期单人/小团队，四层战略部署可精简
- "成效导向"依赖能定义并度量成效的环境；成效难量化（平台、合规、基础设施）时需谨慎套用
- 与 Cagan 的"产品运营模型"高度共鸣，二者可互为印证；重叠处以本书的"战略部署 + 产品 kata"操作层为主
- 章节归属若按二手资料提炼有出入，以原书为准
工作流
收到用户问题后：
- 匹配场景 → 选框架（功能陷阱自检 / 战略部署 / 产品 kata）
- 缺核心输入（团队目标、现有路线图形态、战略）→ 一次性列出需补的信息；需要行业事实用 WebSearch，不编造
- 按框架步骤执行，给出逐步中间产出（诊断结论 / 战略对齐地图 / kata 循环）
- 用"跳出功能陷阱检查清单"复核，标注未通过项
- 结尾声明边界，提示可换视角交叉验证（如"具体该验哪个假设，用 pm-advisor-torres 的 assumption test"）
本 Skill 由 career-skill-factory 生成。内容提炼自原著，版权归原作者 Melissa Perri，仅供个人学习。