Skip to content
FunCoding

pm-method-build-trap

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

Star
1,122
Last commit
Jul 9, 2026

pm-advisory-suite/pm-method-build-trap/SKILL.md

View on GitHub

《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,仅供个人学习。

Similar Skills

research

MAmattpocock/skills288k10,178 new stars in the last 7 days

benchmark-methodology

AFaffaan-m/ECC278k4,046 new stars in the last 7 days

investigate

GAgarrytan/gstack136k883 new stars in the last 7 days

banner-design

NEnextlevelbuilder/ui-ux-pro-max-skill135k1,864 new stars in the last 7 days

brand

NEnextlevelbuilder/ui-ux-pro-max-skill135k1,864 new stars in the last 7 days

Official

email-marketing

NEnexu-io/open-design101k1,126 new stars in the last 7 days