产品功能取舍要解决的是把一份越列越长的功能清单，收敛成有依据的功能布局和版本规划范围。做法是先明确产品定位与目标场景，再按功能架构分层，用共性差异、覆盖人群、投入与维护成本、依赖关系四个口径逐项判断，最后把结论落成可评审的规划范围。本文给出判断标准、操作步骤、角色分工、评审示例和完成检查。
要点总览（TL;DR）
- 功能取舍先定四个判断口径：产品定位与目标场景、功能架构层级、共性或差异、投入与依赖是否可承受，每个功能按同一套问题过一遍。
- 按“整理清单—分层归类—逐项评估—形成初步结论—收敛为规划范围”五步推进，每步明确输入、动作、输出和完成标志。
- 产品负责人主导取舍，业务代表提供场景依据，研发负责人评估成本与依赖，设计负责人判断体验一致性，三类交付物对应清单、评估表和范围说明。
- 评审时先对齐口径再逐项过争议功能，结论落到保留、合并、延后、砍掉四种去向并附理由，延后项记录回看条件。
- 完成检查看每条功能是否有唯一去向和理由、范围是否与定位一致、延后与砍掉是否有记录、结论是否同步并进入规划。
先定取舍口径：功能布局要回答的四个问题
功能取舍容易变成“谁声音大谁的功能先做”，根源是缺少统一的判断口径。开始逐项判断之前，先把四个问题定下来，后面每个功能都按同一套问题过一遍，结论才有可比性。
问题一：产品定位与目标场景是否要求做这个功能
产品定位决定了功能范围的上限。一个面向中小团队协作的产品，和一个面向大型组织流程管控的产品，即使功能名称相同，做到什么深度也完全不同。判断时先问：这个功能服务于哪类用户、在什么场景下被使用、这个场景是否属于产品当前要重点覆盖的范围。如果场景与定位偏离，即使需求真实存在，也应进入延后或砍掉的讨论，而不是直接排进当前版本。
问题二：功能处在哪一层架构
把功能清单按三层归类，能让取舍有结构可依：
- 核心链路：不做产品就无法成立的功能，用户完成主要任务必须经过它。这类功能优先保留，取舍重点在做到什么程度，而非做不做。
- 支撑能力：保障核心链路可用的能力，例如权限、通知、数据导出、基础配置。它们不直接产生差异化，但缺失会让核心链路不可用或不安全。
- 扩展能力：面向差异场景或增量人群的能力，例如特定行业模板、高级自动化、第三方集成。这类功能最需要严格判断，也最适合延后。
分层之后，取舍的讨论对象就清楚了：核心链路讨论深度，支撑能力讨论必要性，扩展能力讨论时机。
问题三：是共性功能还是差异功能
区分依据是目标用户重叠度和场景一致性。多数目标用户共用、使用场景一致的功能，倾向作为共性功能保留并做扎实；只有少数用户需要、且场景差异较大的功能，倾向延后，或作为扩展能力单独规划。这里要防止一种常见误判：把某个大客户提出的定制需求当成共性需求，结果为一个客户拉高了整体复杂度。
问题四：结论去往哪里
每个功能最终只能落到四种去向之一，并且必须附理由：
| 判断问题 | 判断依据 | 结论去向 |
|---|---|---|
| 是否符合产品定位与目标场景 | 目标用户、使用场景、与定位的一致性 | 符合则进入下一问；偏离则延后或砍掉 |
| 处在哪一层架构 | 核心链路、支撑能力、扩展能力 | 核心链路保留；支撑能力按必要性保留；扩展能力从严判断 |
| 是共性还是差异 | 目标用户重叠度、场景一致性 | 共性功能保留或合并；差异功能延后或作为扩展规划 |
| 投入与依赖是否可承受 | 研发投入、长期维护成本、与现有功能的依赖关系 | 可承受则保留；成本过高则延后；与已有功能重复则合并 |
四种去向的含义要统一：保留指进入当前规划范围；合并指并入相近功能，减少重复入口和重复维护；延后指记录触发条件和回看时间，条件满足再启动；砍掉指记录原因，避免同一需求反复被提出、反复讨论。
功能取舍的操作步骤：从清单到规划范围
口径确定后，按固定顺序推进，每一步都有明确输入和输出，取舍才不会停留在会议讨论层面。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 整理功能清单 | 需求池、用户反馈、竞品观察、销售与客户成功转来的诉求 | 逐条登记功能名称、来源、提出人、目标用户、原始场景描述 | 一份去重后的功能清单 | 每条功能都能说清来源和目标用户，重复条目已合并 |
| 2. 按架构分层归类 | 功能清单、产品定位说明 | 把每条功能归入核心链路、支撑能力或扩展能力 | 带层级标签的功能清单 | 每条功能都有层级归属，无归属的单独列出讨论 |
| 3. 逐项评估 | 带层级标签的功能清单 | 按覆盖人群、使用频次、投入与维护成本、依赖关系四项打分或标注 | 功能取舍评估表 | 每条功能四项评估均有结论，争议项已标记 |
| 4. 形成初步结论 | 功能取舍评估表 | 为每条功能给出保留、合并、延后、砍掉之一，并写明理由 | 带结论和理由的评估表 | 每条功能只有一个去向，理由可被他人复核 |
| 5. 收敛为规划范围 | 带结论的评估表、版本节奏 | 把“保留”和“合并”的功能排入版本，明确本期范围与边界，延后项登记回看条件 | 版本规划范围说明 | 范围说明通过评审，相关角色确认无遗漏 |
第三步的评估要落到具体判断上，避免笼统打分。覆盖人群看的是目标用户中有多少比例会用到；使用频次看的是高频日常操作还是低频偶发操作；投入与维护成本不仅看开发工时，还要看上线后的配置、支持和迭代负担；依赖关系看的是这个功能是否依赖尚未建设的能力，或是否与已有功能重叠。四项评估中任何一项明显不利，都应在结论理由中写明。
第五步收敛范围时，要同时写清边界：本期做什么、不做什么、延后项在什么条件下重新评估。范围说明是后续排期和验收的依据，写得越具体，执行中的争议越少。
角色分工与交付物：谁来做取舍、产出什么
功能取舍由产品负责人主导，但结论需要多方输入才能站得住。把职责和交付物对应清楚，可以避免取舍变成单人拍板，也避免评审会上各方各说各话。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 产品负责人 | 维护产品定位与目标场景说明，主导取舍判断，收敛结论，组织评审 | 功能清单、取舍评估表、规划范围说明 |
| 业务/客户代表 | 提供真实使用场景、目标人群依据、需求来源与业务影响 | 场景说明与人群依据，补充到功能清单和评估表 |
| 研发负责人 | 评估研发投入、长期维护成本、技术依赖与实现风险 | 成本与依赖评估意见，写入评估表对应字段 |
| 设计负责人 | 评估体验一致性与交互成本，判断合并功能的可行性 | 交互成本与合并建议，写入评估表 |
三类核心交付物各有用途：功能清单是取舍的输入底稿，保证讨论对象完整且去重；取舍评估表是决策过程记录，每条功能带层级、四项评估、结论和理由；规划范围说明是决策结果，明确本期范围、边界和延后项的回看条件。
评审与决策记录要能回看。建议在评估表中保留争议点、各方意见和最终决策依据，评审结论同步给所有相关角色。功能清单、评估表和范围说明如果在工作项与文档中流转，评审意见和状态变更会自然留痕。ONES 支持用工作项承载功能条目、用文档沉淀评估表与范围说明，并通过评审状态记录决策过程，适合把上述交付物放在同一处维护，减少版本散落和口头传达。
示例：一次功能取舍评审怎么开
以下为演示情景，用于说明流程如何落地，不代表真实项目数据。
示例背景与功能清单片段
某协作工具处于版本迭代期，产品定位是服务中小团队的日常任务协作。本期收集到六条功能诉求：任务看板视图优化、批量导入历史任务、自定义字段、移动端离线编辑、面向某行业的合规报表、与某第三方日历的双向同步。
按口径逐项判断
- 任务看板视图优化：属于核心链路，多数目标用户高频使用，投入可控，结论为保留，进入本期范围。
- 批量导入历史任务：属于支撑能力，新用户迁移时集中使用，频次不高但影响开通体验，投入中等，结论为保留，但限定在标准格式导入。
- 自定义字段：属于扩展能力，覆盖部分有结构化需求的团队，与现有字段体系存在依赖，结论为延后，触发条件为同类需求累计达到一定数量。
- 移动端离线编辑：属于扩展能力，投入与维护成本高，依赖移动端架构改造，结论为延后。
- 行业合规报表：仅单一客户提出，场景与当前定位偏离，结论为砍掉，记录原因并说明可另行评估。
- 第三方日历双向同步：与已有单向同步功能重叠，结论为合并，在现有同步能力上扩展，不新增独立入口。
评审会上如何收敛分歧
评审先对齐判断口径，再逐项过有争议的功能。示例中争议集中在自定义字段：业务代表认为多个客户提到过，研发负责人指出字段体系改造会影响现有数据结构。处理方式是回到评估表，补充覆盖人群的实际情况和改造成本，确认当前证据不足以支撑本期投入，结论维持延后，并写明回看条件。最后确认本期范围为看板视图优化、批量导入和日历同步扩展，其余功能记录去向和理由，评审结论同步给相关角色。
完成检查：取舍结论是否可执行
取舍工作是否完成，不看会议开了几次，而看结论能否直接支撑排期和验收。按以下清单逐项核对：
- 功能清单中的每条功能都有明确去向，且去向只有一种，理由可被他人复核。
- 每条功能的层级归属、覆盖人群、使用频次、投入与维护成本、依赖关系均有记录。
- 本期规划范围与产品定位和目标场景一致，范围说明写清了做什么和不做什么。
- 延后功能记录了触发条件和回看时间，砍掉功能记录了原因，后续可查。
- 合并功能已明确并入哪个现有功能，避免出现重复入口。
- 评审结论已同步给产品、业务、研发、设计等相关角色，并已进入版本规划。
- 争议点和决策依据已留存，后续复盘时可以还原当时的判断过程。
需要说明本文的边界：单条需求的价值评分方法属于需求优先级与价值评估的范畴，功能方案如何表达和评审属于产品方案与原型评审的范畴，本文聚焦功能布局与规划范围的取舍。把取舍结论稳定地落到清单、评估表和范围说明上，并让评审记录可回看，功能规划才能从一次讨论变成可重复执行的工作方式。
常见问题
功能取舍时，业务方坚持要做某个功能，但评估结论是延后，怎么处理？
把分歧拉回评估表，补充覆盖人群的实际数据和改造成本，确认当前证据是否足以支撑本期投入。如果证据不足，结论维持延后，同时写明触发条件和回看时间，让业务方知道什么条件下会重新评估。评审记录保留各方意见和最终决策依据，后续复盘时可以还原判断过程。
功能清单里有些条目说不清归属层级，怎么办？
把无归属的条目单独列出，在评审中优先讨论。判断方法是问：不做这个功能，用户能否完成主要任务？不能则归核心链路；能完成但缺少保障会出问题，归支撑能力；只影响部分差异场景，归扩展能力。讨论后仍无法归类的，通常说明场景描述不完整，需要补充目标用户和使用场景再判断。
延后的功能过了一段时间，怎么判断该不该重新启动？
延后时就要记录触发条件，例如同类需求累计数量、依赖能力上线、目标客户签约等。回看时先核对触发条件是否满足，再按原评估口径重新过一遍覆盖人群、频次、成本和依赖。条件满足且评估结论支持，才进入规划范围；条件未满足则继续延后并更新回看时间。
合并功能时，怎么避免合并后体验变差或入口混乱？
合并前由设计负责人评估交互成本和体验一致性，明确并入哪个现有功能、保留哪些入口、去掉哪些重复入口。合并方案要写进评估表，评审时确认不会造成主要任务路径变长或操作步骤增加。合并后如果发现体验问题，按原评估记录回看，而不是重新开一轮取舍讨论。
功能取舍的结论需要同步给哪些人，同步到什么程度？
至少同步给产品、业务、研发、设计四类角色。同步内容不只是结论，还包括每条功能的去向和理由、本期范围边界、延后项的触发条件。同步后确认相关角色无遗漏，结论进入版本规划。如果后续范围调整，更新范围说明并重新同步，避免口头传达造成信息不一致。
