product-operations-and-governance

产品运营与治理

定义并运行定期产品治理体系：由谁决定什么、依据什么证据、按什么节奏进行，以及当决策受到质疑或证据缺失时如何处理。这项技能负责产品层面的运营模式——连接产品战略、组合选择、实验、采用和生命周期学习的纽带。它不负责高管治理或技术交付关卡。

治理边界（请先阅读）

这项技能负责产品治理：用于受理、组合评审、路线图决策、实验评审、发布决策以及生命周期／健康状况评审的定期体系。产品治理要回答：我们要构建什么、按什么顺序、依据什么证据、由谁评审、按什么节奏进行？

这项技能明确不负责：

• 高管治理——资本分配、组织结构、公司层面的战略押注、并购评估。有关决策备忘录和高管办公室方法，请转至 chief-of-staff-methodology；有关战略规划框架，请转至 strategy-frameworks。
• 技术交付关卡——CI/CD 流水线、发布审批工作流、部署检查清单、基础设施变更评审。有关发布机制，请转至 release-engineering；有关规格阶段关卡，请转至 spec-driven-development。

产品、高管和交付这三个治理层次彼此不同。产品治理决策（“批准此实验进入发布评审”）既不是高管决策（“向支付平台拨款 200 万美元”），也不是交付关卡（“部署流水线必须通过集成测试”）。有关完整的边界分析，请参阅 references/discovery-brief.md。

核心框架

两种运营模式

这项技能支持两种模式；每次启用时都要明确选择一种。模式决定证据要求、评审的正式程度和升级阈值。

维度	轻量模式	高保证模式
团队规模	小型（≤15 名工程师、≤3 个产品团队）	任何规模，但承担监管或安全义务
评审正式程度	异步书面更新；仅对有争议的决策进行同步评审	进行同步评审，并记录法定人数
最低证据要求	假设 + 定性信号或单一量化指标	统计证据、风险分析、合规签字确认
例外跟踪	团队 Wiki 或决策日志	正式例外登记册，注明重新审查日期
升级路径	直接提交给负有问责责任的高管	正式升级链，并记录处理结果
节奏	每两周或每月	每周或按发布周期
工件留存	轻量（电子表格、共享文档）	可审计（带版本的记录、不可变日志）

模式是一种配置选择，而非成熟度等级。构建非监管类消费应用的初创公司采用轻量模式。拥有 8 人的医疗器械团队采用高保证模式。拥有 200 人的平台团队可以对其部分产品组合采用轻量模式，其他部分则采用高保证模式。

可配置的治理模式

不强制采用某一种组织架构或治理模型。该技能提供可配置的模式，可按需选择和调整：

模式	适用场景	主要特点
单一责任人	小型团队、单一产品	由一人决策；评审仅提供建议
产品委员会	多团队、多产品	跨职能小组，设有明确的投票或共识规则
分级评审	风险各异的产品组合	低风险事项采用轻量流程；受监管事项采用高保证流程
授权决策并逐级升级	规模化组织	按类别预先下放决策权；仅在例外情况下升级

每种模式都要求提供相同的产出：决策权责图、包含证据标准的评审频率，以及升级路径。使用 templates/operating-model.md 记录所选模式及其配置。

决策权责

决策权责图针对每类决策回答以下五个问题：

1. 谁来决策？ 指明具体角色（不能写“工程”或“领导层”——必须是明确承担责任的负责人）。
2. 必须咨询谁？ 决策前必须征求其意见的角色或个人。
3. 必须通知谁？ 决策后需要收到通知的角色或个人。
4. 需要哪些证据？ 此类决策所需的最低证据标准（因模式而异）。
5. 升级路径是什么？ 当责任人无法决策或决策存在争议时，由谁负责解决。

该技能涵盖的决策类型：

决策类型	典型频率	轻量级证据	高保证证据
受理／拒绝需求	每个请求（持续进行）	问题陈述 + 一项信号	问题陈述、延迟成本、战略契合度评分、产能检查
产品组合优先级排序	每月或每季度	附理由的相对排名	根据延迟成本、战略契合度、产能模型和风险评估排序
路线图承诺	每个规划周期	假设 + 成功标准	假设、实验结果或市场证据、依赖关系图、置信区间
实验继续／停止	每个实验	护栏检查 + 定性信号	统计分析、护栏验证、伦理评审、决策规则
发布通过／不通过	每次发布	就绪清单 + 利益相关方签字确认	完整的就绪证据包、风险接受签字确认、已验证的回滚计划
生命周期：继续／投资／收割／退役	每个评审周期	使用情况与结果数据、团队建议	使用情况、财务、竞争及风险数据；多方利益相关者评审

使用 templates/decision-rights-map.md 为特定产品或产品组合记录决策权责图。

评审节奏

六项定期评审构成产品治理的节奏。每项评审都有明确的目的、参与者、输入、输出和决策权限。

评审	目的	典型参与者	关键输入	关键输出	决策权限
需求接收 / 机会评审	决定哪些新工作进入产品体系	产品负责人、工程负责人、设计负责人（因模式而异）	问题陈述、战略一致性、粗略估算	接受 / 拒绝 / 延后决定、指定负责人	产品负责人（或委员会投票）
产品组合评审	对产品组合中的工作排序并分配资源	产品委员会或领导团队	投注记录、产能模型、战略优先事项	排序后的产品组合、资源分配、延后事项	产品委员会或负有最终责任的高管
路线图评审	承诺、调整或延后路线图事项；审查证据更新	产品负责人、工程负责人、关键利益相关者	已更新的投注记录、新证据、依赖项状态	已更新的 Now/Next/Later、继续 / 暂停 / 终止决定	产品负责人（征求利益相关者意见）
实验评审	决定实验结果是否支持继续推进、迭代或停止	产品负责人、数据 / 科学负责人、工程负责人	实验结果报告、护栏指标报告、决策建议	继续 / 停止 / 转向决定、已更新的投注记录	产品负责人（参考科学方面的意见）
发布评审	确认是否已做好发布准备；接受剩余风险	产品负责人、工程负责人、QA、安全、支持、市场营销	准备情况证据包、风险登记表、回滚计划	发布 / 不发布 / 延后决定、已接受的风险	产品负责人（发布 / 不发布）；接受风险可能需要高管批准
生命周期 / 健康状况评审	评估产品健康状况；决定继续 / 投资 / 收割 / 退役	产品负责人、工程负责人、支持、财务（高保证要求）	使用数据、成果指标、成本数据、竞争情报	生命周期决策、已更新的投资水平、退役时的迁移计划	产品委员会或负有最终责任的高管

使用 templates/review-cadence.md 为特定运营模式配置评审节奏。路线图评审机制请参阅 product-roadmapping-and-portfolio，实验评审方法请参阅 product-experimentation，生命周期 / 健康状况评审证据请参阅 product-lifecycle-learning（说明文档——同一发布批次的技能，目录尚未创建）。

证据标准

每种决策类型都有最低证据标准。该标准会根据运营模式调整。在每份文档中，证据均分为四类：

• 观察所得——经过测量、验证且可复现的数据。
• 推断所得——基于观察数据得出的结论，并注明假设和置信度。
• 主张所得——尚未验证的利益相关者主张；视为假设。
• 已承诺——可能带来撤销后果的决策；记录负有责任的负责人和复审触发条件。

缺少必需证据并非跳过评审的理由，而是升级处理的理由。在缺少必需证据时仍继续进行的评审，必须生成例外记录，不能默许通过。

例外与升级处理

例外记录

豁免或延期执行治理要求时，应记录该例外。没有记录，例外就会成为新的默认做法。

字段：例外内容、原因、批准人、批准日期、复审时间（具体日期或触发条件），以及用于替代被豁免要求的证据（如有）。

使用 templates/exception-record.md。

升级记录

如果某项决策无法在指定层级解决——因为缺少证据、相关方陷入僵局，或负责的所有者无法做出决定——就应升级。升级并不代表失败，而是治理系统按设计运作。

字段：升级事项、升级对象、较低层级无法解决的原因、解决方案、解决日期和结项证据。

使用 templates/escalation-record.md。

加载指南

只加载与当前任务相关的文件。不要一次性加载所有文件。

文件	加载时机
references/discovery-brief.md	需要了解治理边界、所有权以及技能间的路由方式时
templates/operating-model.md	从头设计或配置产品运营模式时
templates/decision-rights-map.md	为产品或产品组合梳理决策权时
templates/review-cadence.md	配置评审频率、目的、参与者、输入和输出时
templates/exception-record.md	记录被豁免或延期的治理要求时
templates/escalation-record.md	记录通过治理系统进行的升级时

工作方法

1. 选择运营模式

每次合作开始时，都要选择轻量级或高保证模式。不要默认选用其中一种。请问：该产品是否受监管、是否属于安全关键产品，或是否受外部合规义务约束？如果是，选择高保证模式。如果团队规模较小且产品不受监管，则选择轻量级模式。

2. 选择治理模式

从单一负责所有者、产品委员会、分层评审或授权并配合升级机制中选择。根据实际情况调整，不要照搬。将选择记录在运营模式模板中。

3. 梳理决策权

对于范围内的每种决策类型，填写决策权地图：谁做决定、征询谁的意见、通知谁、需要哪些证据，以及应向何处升级。使用 templates/decision-rights-map.md。

4. 配置评审频率

为每次评审设定目的、参与者、输入、输出和决策权限。根据运营模式调整频率。使用 templates/review-cadence.md。

5. 建立证据标准

根据运营模式，为每种决策类型定义最低证据标准。将标准记录在决策权地图中。证据标准不是理想目标，而是决策的门槛。

6. 记录例外和升级

每项例外和升级都应有一份注明日期的记录，其中包含负责的所有者和重新审视的触发条件。例外记录可防止因疏忽而默认豁免。升级记录则让治理系统可观测、可改进。

路由表

当你需要……	加载此技能
产品愿景、北极星、竞争定位	product-strategy
战术优先级排序（RICE、MoSCoW）、决策日志、规格说明	product-methodology
结果导向的路线图、战略押注、组合排序	product-roadmapping-and-portfolio
多项目技术协调、共享产能、项目收益、转型交付	technical-program-management
实验设计、方法选择、护栏、结果解读	product-experimentation
发布后学习、生命周期决策、假设更新	product-lifecycle-learning（文档内容——同一波次的技能）
高管决策备忘录、CoS 方法、董事会材料	chief-of-staff-methodology
战略规划、资本配置、OKR 框架	strategy-frameworks
发布机制、部署流水线、回滚计划	release-engineering
规格阶段关卡、验收标准、任务规划	spec-driven-development

不适用场景

以下情况不要加载此技能：

• 高管治理。 资本配置、组织架构决策、公司层面的战略押注或并购评估——请转至 chief-of-staff-methodology 或 strategy-frameworks。
• 技术交付关卡。 CI/CD 流水线、发布审批工作流、部署检查清单或基础设施变更评审——请转至 release-engineering 或 spec-driven-development。
• 强制推行通用组织架构。 治理模式是可配置的模板，而非强制结构。如果需求是从零开始设计组织架构，此技能并不适用。
• 没有常设机制的单次决策。 如果你需要做出一项决策（而非设计随时间推移做出决策的系统），请使用 product-methodology 编写决策日志，或使用 adr-authoring 处理架构决策。