pm-method-build-traplisted

> **在顾问团里的位置**：本技能是 `pm-advisory-board`（顾问团总控）的成员之一（《Escaping the Build Trap》方法论）。 > 通常由 board 路由进来或被拉进多专家评审会；也可被用户直接点名。 > 判断出结论后要产出交付物 → 回 `pm-master` 按单点路由或流程走，本技能不产出文档。 # 《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. 产品经理的角色是"价值