产品边界划分要解决的是“一个产品到哪里为止”的问题：把产品定义成可独立演进、可独立交付、可独立核算的单元，并写清它与相邻产品在用户、场景、功能、数据和责任上的分界。落地时通常走三步：先确定划分依据，再用边界判定表逐条比对候选产品，最后把结果沉淀为产品清单与边界说明，并指定负责人。边界会随产品集合演进，需要定期复核。
要点总览（TL;DR）
- 产品边界划分先定口径：选一条主依据（如核心业务场景）决定大方向，再选一条校验依据（如责任主体）检查切分是否可执行，并把口径写成一句话。
- 用边界判定表逐条比对候选产品，重叠功能必须给出归A、归B、共用能力或暂缓决定四种结论之一，避免“两边都做”。
- 划分结果沉淀为产品清单和每款产品的边界说明，写清做什么、明确不做什么、与相邻产品的交接点，以及共用能力的维护方。
- 产品负责人提出并维护边界主张，产品线负责人或产品委员会裁决跨产品争议，研发与交付角色确认依赖和交接点可执行。
- 用完成检查清单验收：唯一负责人、一句话定位、重叠项归属、变更记录与复核周期、遗留争议的责任人和时限。
先定划分依据：产品边界按什么切
动手列表格之前，先确定切分口径。口径不清，后面每个重叠功能都会变成主观争论。常见的划分依据有五类，各有适用条件。
| 划分依据 | 适用条件 | 可能带来的问题 |
|---|---|---|
| 目标用户群 | 不同用户群的需求差异大，购买决策和使用方式明显不同 | 同一用户群被多个产品重复覆盖 |
| 核心业务场景 | 场景之间流程差异大，一个产品难以同时做好 | 场景交叉处出现功能重叠 |
| 交付与发布节奏 | 各部分迭代频率、上线窗口差异明显，互相牵制严重 | 按节奏切分可能割裂用户体验 |
| 数据与权限边界 | 数据敏感级别、合规要求或权限模型不同 | 共用数据时边界难以维持 |
| 责任与核算主体 | 需要独立核算投入产出，或由不同团队长期负责 | 组织调整会带动边界频繁变动 |
单一依据容易切错。例如只按用户群切，可能把同一场景拆到两个产品，导致用户要在两处完成一件事；只按交付节奏切，可能让共享能力无人负责。实践中通常选一条主依据决定大方向，再选一条校验依据检查切分结果是否可执行。常见组合是“核心业务场景为主、责任主体为校验”，或“目标用户群为主、数据与权限为校验”。
把口径写成一句话，作为后续判定表的统一判断标准。例如：“本业务线以核心业务场景作为主依据划分产品，以责任主体作为校验依据；同一场景内的能力归入同一产品，跨场景共用的能力单独约定归属。”这句话要能直接回答“两个候选功能该不该放在一起”，写不进这句话的依据，说明还没想清楚。
本节的产出是一份划分口径说明，包含主依据、校验依据、一句话表述，以及选择该依据的理由。它需要经过产品线负责人或产品委员会确认，避免后续比对时口径被临时更改。
边界判定表：逐条比对候选产品
判定表的作用是把划分依据转成可逐条执行的比对动作。建议字段如下，每个候选产品一行。
| 字段 | 填写要求 |
|---|---|
| 产品名（暂定） | 候选产品的临时名称，允许后续调整 |
| 目标用户 | 具体到角色或客户类型，避免写“所有用户” |
| 核心场景 | 列出该产品要解决的前两三个场景，按重要性排序 |
| 关键功能 | 支撑核心场景的功能集合，不必穷举 |
| 依赖的其他产品 | 需要调用或被调用的能力，注明方向 |
| 负责人 | 唯一的产品负责人，暂缺时标注待定 |
| 重叠项与归属结论 | 与其他候选产品重复的功能，标注归A、归B、共用能力或暂缓决定 |
判定规则与划分口径对应：主依据不同，倾向拆分为两个产品；主依据相同但交付节奏或责任主体不同，评估拆分，并说明拆分后交接成本由谁承担；主依据相同且节奏、责任一致，倾向合并。规则的作用是让讨论有共同起点，最终结论仍要结合依赖关系和交接成本判断。
重叠项是判定表的核心。对每个重叠功能，先判断它服务哪个产品的核心场景，再判断由谁维护更合理。归属结论只有四种：归A、归B、作为共用能力由指定一方维护、暂缓决定并记录原因和决策时限。“两边都做”和“先放着”都不算结论，会在后续迭代中反复引发争议。
比对时建议一次只处理一条产品线或一个产品集合，避免范围过大导致表格失控。每轮比对结束，把有争议的行单独列出，交给有裁决权的角色处理，其余行直接定稿。
输出产品清单与边界说明文档
判定表是过程工具，划分结果需要沉淀成可被引用的文档，否则新人入职、需求评审、跨团队协作时仍会各说各话。至少产出两份材料。
产品清单：每个产品一行，包含产品名称、一句话定位、负责人、上游依赖与下游消费方。一句话定位要说明服务谁、解决什么场景，例如“面向一线客服的工单处理产品，覆盖受理到关闭的主流程”。清单是后续所有讨论的索引，名称和负责人变更都要同步更新。
边界说明：每个产品一份，包含三部分。本产品做什么，按核心场景列出；本产品明确不做什么，写成具体条目，例如“不承担客户主数据维护”“不提供对外报表导出”；与相邻产品的交接点，说明在哪个环节、以什么形式把结果交给对方，例如“工单关闭后向数据分析产品推送事件”。
共用能力要单独写清归属与维护责任。共用能力常见于账号权限、消息通知、基础数据等，边界说明中应注明由哪个产品团队维护、其他产品以什么方式接入、变更时如何通知使用方。归属不清的共用能力，往往在出问题时才发现两边都以为对方在管。
这些文档需要放在团队日常协作的位置，而不是一次性交付后束之高阁。以 ONES 为例，产品清单和边界说明可以作为团队文档维护，产品线信息与跨项目的工作项属性可以在 ONES Plan 中管理，使边界说明与实际项目数据保持对应；边界变更记录则可以随相关工作项流转，便于回溯。具体承载方式依团队现有工具配置而定。
角色分工：谁定边界、谁维护边界
边界划分失败，多数时候不是方法问题，而是没有人对结果负责。划分过程涉及四类角色，职责和交接物要提前明确。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 产品负责人 | 提出本产品的边界主张，说明核心场景与不做什么；日常维护边界说明 | 边界主张、边界说明文档 |
| 产品线负责人或产品委员会 | 确认划分口径，裁决跨产品归属争议 | 口径确认结论、争议裁决记录 |
| 研发与交付角色 | 确认依赖关系与交接点是否可执行，评估拆分带来的改造成本 | 依赖确认意见、交接点可行性结论 |
| 边界变更提出人 | 发起变更申请，说明原因、影响范围和涉及的产品 | 变更申请记录 |
争议裁决要有明确路径：先由相关产品负责人协商，协商不成提交产品线负责人或产品委员会裁决，裁决结论写入边界说明并通知受影响方。裁决权集中在一处，可以避免争议在两个团队之间来回。研发与交付角色的意见不直接决定边界，但拆分方案如果交接成本过高，应作为重新评估的依据。
边界变更流程建议保持轻量：提出变更申请，说明触发原因（如新场景出现、组织调整、用户反馈），由产品线负责人评审，通过后更新产品清单与边界说明，并记录变更时间和影响范围。变更记录的价值在于，当边界反复调整时能看出趋势，判断是划分依据本身需要修订，还是个别产品定位不清。
示例：一条业务线的边界划分过程
以下为方法演示情景，不对应任何真实企业数据，具体结论需依企业实际调整。
某业务线规划了三个候选产品：客户管理、工单处理、数据分析。初步梳理后发现，工单处理中包含客户信息查看功能，数据分析中包含工单统计报表，客户管理与工单处理都能录入客户联系方式，出现明显重叠。
该业务线确定口径：以核心业务场景为主依据，以责任主体为校验依据。按此逐条比对：客户管理的核心场景是客户信息维护与跟进，工单处理的核心场景是问题受理到关闭，数据分析的核心场景是跨产品指标汇总与呈现。三者主依据不同，倾向拆分为三个产品。
重叠项处理如下：客户信息查看归客户管理，工单处理通过接口读取，不在本产品内维护客户主数据；工单统计报表归数据分析，工单处理只提供事件数据；客户联系方式录入归客户管理，工单处理在受理时引用已有客户记录，不重复建档。三项均形成明确归属，没有留“暂缓决定”。
输出清单片段：客户管理，定位为“面向销售与客服的客户信息维护与跟进产品”，负责人甲，下游消费方为工单处理与数据分析；工单处理，定位为“面向一线客服的工单受理到关闭产品”，负责人乙，上游依赖客户管理，下游向数据分析推送事件。边界说明中写明工单处理“不维护客户主数据、不生成跨产品统计报表”，交接点为“工单关闭后推送事件至数据分析”。
这个示例说明的是比对顺序和结论写法：先定口径，再逐条比对，重叠项逐一给出归属，最后落到清单和边界说明。实际划分中，候选产品数量、重叠程度和争议点都会不同，判定规则不变。
完成检查：边界划分是否可用
划分结果是否可以交付使用，用以下清单逐项核对。全部通过再进入日常执行，未通过项指定责任人和完成时间。
- 每款产品都有唯一负责人，没有两个产品共用一位负责人却未说明分工的情况。
- 每款产品都有一句话定位，能说明服务谁、解决什么场景。
- 所有重叠功能都有明确归属，或已约定为共用能力并写明维护方。
- 边界说明中的“不做什么”有具体条目，不是笼统的“不涉及其他领域”。
- 相邻产品的交接点写明了环节、形式和责任方。
- 存在边界变更的记录方式，并确定了复核周期，例如每季度或产品规划节点复核一次。
- 遗留争议项有责任人和解决时限，没有无主争议。
- 产品清单与边界说明已放在团队可访问的位置，相关角色已知晓。
检查通过后，边界划分进入维护阶段。复核时重点看三件事：重叠项是否重新出现、争议数量是否上升、变更记录是否集中在某一类原因。如果争议反复出现在同一处，通常说明划分依据需要调整，而不是继续在个案上裁决。
常见问题
划分依据选错会有什么后果，发现后怎么调整？
依据选错通常表现为边界反复调整：同一处重叠功能刚裁决完，过一段时间又出现归属争议，或者变更记录集中指向同一类原因。这时继续在个案上裁决收效有限，应回到划分口径，检查主依据是否与业务实际不符。
调整时先修订口径说明，写明新的主依据和校验依据，再重新跑一遍边界判定表，重点复核此前争议集中的行。口径变更需要产品线负责人或产品委员会确认，并同步更新产品清单与边界说明，避免新旧口径并存。
共用能力由谁维护，接入方需要承担什么？
共用能力应在边界说明中指定唯一维护方，常见于账号权限、消息通知、基础数据等。维护方负责能力本身的演进和变更通知，接入方按约定方式接入，并承担自身使用侧的适配工作。
需要写清三件事：维护方是谁、其他产品以什么方式接入、变更时如何通知使用方。归属不清的共用能力，往往在出问题时才发现两边都以为对方在管，因此这一项要作为完成检查的必查内容。
边界变更频繁，是流程问题还是划分问题？
先看变更记录集中在哪类原因。如果集中在组织调整、新场景出现等外部触发，属于正常演进，保持轻量流程即可；如果反复出现在同一处功能归属上，通常说明划分依据需要调整，而不是继续逐案裁决。
复核时可以关注三个信号：重叠项是否重新出现、争议数量是否上升、变更是否集中在某一类原因。任一信号持续出现，就应重新审视口径说明，而不只是更新单款产品的边界说明。
候选产品还没定负责人，能先做边界划分吗？
可以先做，但要在判定表中把负责人标注为待定，并在完成检查时把“每款产品都有唯一负责人”列为未通过项，指定补齐责任人和时间。
负责人缺位会影响两件事：边界主张由谁提出、日常由谁维护边界说明。划分结果可以先用于讨论和比对，进入日常执行前需要补齐负责人，否则边界说明容易停留在文档层面。
边界说明和产品清单放在哪里，怎么保持与实际一致？
放在团队日常协作可访问的位置，而不是一次性交付后归档。产品清单是后续讨论的索引，名称、定位和负责人变更都要同步更新；边界说明随产品演进修订，变更记录保留时间和影响范围。
以 ONES 为例，产品清单和边界说明可以作为团队文档维护，产品线信息与跨项目的工作项属性可以在 ONES Plan 中管理，使边界说明与实际项目数据保持对应；边界变更记录可以随相关工作项流转，便于回溯。具体承载方式依团队现有工具配置而定。
