竞品功能分析的依据要能回答三个问题：这个功能是否存在、对谁有用、凭什么判断。可用的依据分为四层：可核验的一手材料，如官方文档、帮助中心、更新日志、定价页和公开演示；可观察的产品行为，如试用环境中的操作路径、角色权限、数据流转和异常提示；外部佐证，如公开客户案例、应用市场评价、行业报告和用户访谈；内部锚点，如自家产品规划、目标客户需求记录和销售反馈。功能判断以一手材料与实测为主，二手信息作为线索使用。每项依据都应记录来源、获取日期、获取方式和可信度，让结论可以被他人复核。
要点总览（TL;DR）
- 竞品功能分析的依据分四层：一手公开材料、产品行为观察、外部佐证、内部锚点；功能存在性以一手材料和实测为主，二手信息只作线索。
- 动手取证前先定竞品清单、功能颗粒度（模块、功能点、操作路径）、结论使用方和版本时间口径，避免不同版本、不同颗粒度的信息混在一起。
- 执行按五步走：建功能清单与对比框架、逐项取证登记来源、试用环境验证关键功能点、交叉核对与差异归因、形成结论与建议。
- 取证、客户场景判断和技术判断需要分工：产品经理定问题并主持评审，分析师取证登记，售前提供客户反馈，研发评估实现难度。
- 提交评审前逐项核对：来源与日期完整、依据性质已区分、未确认项有验证计划、结论回应决策问题；前四项为阻断项。
先明确分析对象与判断口径
竞品功能分析常见的返工，来自分析开始前没有约定范围：不同人拿不同版本、不同颗粒度的信息拼在一起，结论自然对不上。动手取证之前，先用一页纸把四件事定下来。
竞品清单与入选理由
把竞品分为三类并写明入选理由：直接竞品是目标客户在同类采购中会同时比较的产品；间接竞品是解决同一问题但产品形态不同的方案；潜在替代包括客户自建、开源方案或相邻品类延伸过来的产品。每类控制在可维护的数量内，避免清单过长导致取证深度不足。入选理由要落到具体依据，例如“近半年在销售丢单记录中出现频次最高”，而不是笼统的“行业知名”。
功能颗粒度：模块、功能点、操作路径
建议统一到三层颗粒度：模块层用于搭建对比框架，例如权限管理、报表、集成；功能点层用于逐项判断是否存在、是否可用，例如“按角色分配数据行权限”；操作路径层用于记录完成一个任务需要几步、涉及哪些角色和设置项。三层的关系是逐层下钻：模块层保证覆盖面，功能点层支撑结论，操作路径层解释差异原因。分析范围说明中应写明本次下钻到哪一层，哪些模块只做模块层扫描。
结论使用方与决策问题
同一份分析给产品规划、售前和管理层看，需要的详略完全不同。产品规划关心功能差距和实现路径，售前关心客户会问到的对比点和应答口径，管理层关心投入优先级。分析开始前把使用方和对应的决策问题写清楚，例如“本季度规划是否需要补齐审批流中的条件分支能力”，后续取证才有取舍标准。
时间窗口与版本口径
约定统一的观察时间窗口和版本口径，例如“以某月某日可访问的公开版本为准”，并在证据表中记录每个来源对应的版本或更新日期。竞品更新频繁时，跨版本对比会得出错误结论，因此版本口径要写在分析范围说明的显眼位置，后续新增证据也按同一口径登记。
本节的交付物是一份分析范围说明，包含竞品清单及入选理由、功能颗粒度定义、结论使用方与决策问题、版本时间口径四项内容。范围说明经使用方确认后，再进入取证阶段。
四类依据及其取用方式
四类依据的可信度和适用结论不同，混用会让分析看起来材料很多、结论却站不住。下面的分类表给出每类依据的典型来源、能支撑的结论和可信度定位。
| 依据类型 | 典型来源 | 可支撑的结论 | 可信度定位 |
|---|---|---|---|
| 一手公开材料 | 官方文档、帮助中心、更新日志、版本说明、定价页、公开演示 | 功能是否存在、官方如何描述其范围和限制、版本演进方向 | 高，作为功能存在性的主要依据 |
| 产品行为观察 | 试用环境中的操作路径、角色权限设置、数据导入导出、异常提示 | 功能实际可用程度、操作成本、边界条件下的表现 | 高，用于验证和补充文档 |
| 外部佐证 | 公开客户案例、应用市场评价、行业报告、用户访谈 | 功能的使用场景、用户痛点、市场关注点 | 中低，作为线索，不直接下存在性结论 |
| 内部锚点 | 自家产品规划、目标客户需求记录、销售与支持反馈 | 功能对目标客户的价值权重、差距的优先级 | 中，用于判断重要性，不用于判断竞品能力 |
一手公开材料的取用与记录
官方文档和帮助中心是判断功能是否存在的第一依据，更新日志和版本说明用于判断功能的新旧和演进方向，定价页反映功能与套餐的对应关系，公开演示用于观察官方展示的标准操作路径。取用时逐条记录来源地址、获取日期、对应版本，并摘录关键原文，避免只写“文档中提到”这类无法复核的描述。需要注意，文档描述的是官方宣称的能力，实际可用程度仍需试用验证。
产品行为观察的记录方式
在试用环境中按任务走完整操作路径，记录入口位置、所需角色与权限、数据如何流入流出、异常情况下系统给出什么提示。每条观察附截图或操作日志，并注明试用账号的版本和获取时间。观察能回答“能不能用、用起来多费力”，但受试用环境配置影响，结论应写明前提条件，例如“在管理员角色下可完成，普通成员角色未见入口”。
外部佐证的定位
客户案例、应用市场评价、行业报告和用户访谈适合发现问题线索：用户反复抱怨的点、案例中强调的场景、报告归纳的趋势，都可以转化为待验证的功能点。这类信息受样本和表述立场影响，不能直接作为功能存在性或能力高低的结论，引用时标注“线索”并附上后续验证计划。
内部锚点的作用
自家产品规划、目标客户需求记录和销售支持反馈，用来给功能差距排优先级。同样一个功能差距，对目标客户高频场景影响大，就值得优先跟进；只在边缘场景出现，可以记录后观察。内部锚点不用于判断竞品能力，只回答“这个差距对我们重不重要”。
按步骤完成一次功能分析
五步流程把范围说明转化为可复核的分析报告，每一步都明确输入、动作、输出和完成标志。
步骤一：建立功能清单与对比框架
输入是分析范围说明。动作是把选定模块拆成功能点清单，按统一颗粒度命名，并为每个功能点写明判断标准，例如“存在且可配置”“存在但需特定套餐”“未发现”。输出是功能点清单和对比框架表。完成标志是所有使用方确认清单覆盖了他们关心的决策问题。常见返工点是功能点命名颗粒度不一，导致后续无法横向比较。
步骤二：逐项取证并登记来源
输入是功能点清单。动作是针对每个功能点查找一手公开材料，登记来源、获取日期、版本和关键摘录，同时标记需要试用验证的项。输出是证据登记表。完成标志是每个功能点至少有一条一手材料或明确的“未找到”记录。常见返工点是只记结论不记来源，复核时无法追溯。
步骤三：在试用环境验证关键功能点
输入是待验证清单。动作是按操作路径实际走一遍，记录角色权限、数据流转和异常提示，附截图或日志。输出是验证记录。完成标志是关键功能点均有验证结论，且写明验证时的环境和角色前提。常见返工点是试用环境配置不全就下“不支持”的结论，应改为“在当前配置下未验证通过”并注明待确认。
步骤四：交叉核对与差异归因
输入是证据登记表和验证记录。动作是比对文档描述、实测结果和外部线索，找出冲突并分析原因：是版本差异、套餐限制、角色权限，还是文档与实现不一致。输出是差异说明，逐条写明冲突点、判断依据和处理方式。完成标志是每处冲突都有归因结论或明确的待确认标记。
步骤五：形成结论与建议
输入是差异说明。动作是按使用方的决策问题组织结论，区分已确认、待确认和不适用三类表述，并给出对产品规划的建议和优先级依据。输出是分析报告。完成标志是结论能直接回应分析范围说明中列出的决策问题，且每条结论可回溯到证据表中的记录。
取证项分配、证据表沉淀和结论评审记录需要团队共同维护时，可以在项目协作工具中把每个功能点作为工作项分配负责人和截止时间，证据表以文档形式集中存放并保留修改记录，评审意见附在对应工作项下，形成从取证到结论的完整链路。ONES 的项目与文档协作能力可以承载这类流程，具体配置按团队现有协作方式确定。
角色分工与交付物
竞品功能分析涉及取证、客户场景判断和技术判断，单人凭印象填表容易遗漏关键证据。下表给出常见角色分工，团队规模较小时可由一人兼任多个角色，但交付物仍需分开留存。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 产品经理 | 定义分析问题与范围，主持结论评审 | 分析范围说明、评审结论 | 范围确认后移交取证；报告初稿完成后组织评审 |
| 产品分析师/市场研究 | 逐项取证、登记来源、整理证据表、执行试用验证 | 证据登记表、验证记录、差异说明 | 证据表完成一轮后交产品经理抽查；差异说明提交评审 |
| 售前或解决方案 | 提供客户侧反馈、真实使用场景和常见对比问题 | 客户场景清单、对比问题清单 | 范围确认阶段提供输入；结论阶段校验表述是否符合客户语境 |
| 研发或技术负责人 | 判断功能实现难度与技术约束，评估差距补齐成本 | 技术评估意见 | 差异说明形成后参与评估；结论评审时提供优先级建议 |
交接节点要落到具体产物：范围说明确认后取证才开始，证据表完成一轮后进入验证，差异说明完成后才写结论。每个节点留下确认记录，避免结论评审时才发现范围或证据口径不一致。
示例：一次权限管理功能分析
以下为演示情景，用于说明依据如何取用和结论如何表述，不指向任何具体产品。
背景与待验证功能点
某团队在规划中考虑补齐“按组织架构继承数据权限”的能力，需要判断竞品是否提供、对目标客户是否重要。待验证功能点定为：是否支持按部门层级自动继承数据访问权限；继承规则是否可按角色覆盖；变更组织架构后权限如何生效。
取证过程
一手材料方面，帮助中心文档描述了角色与数据范围的配置方式，更新日志显示某版本新增了组织架构同步相关条目，但未明确说明权限继承规则。试用观察方面，在管理员角色下创建两级部门并分配数据范围，发现下级部门成员可访问上级分配的数据，但单独为某成员设置例外权限时入口较深，需要多步操作。客户反馈方面，售前记录显示两位客户在选型时问过组织调整后的权限生效问题，属于线索，提示该功能点值得深入验证。
冲突处理
文档描述与实测结果存在一处不一致：文档称权限变更即时生效，实测中组织架构调整后需要重新登录才看到变化。处理方式是记录版本和操作步骤，标记为待确认，并列入下一轮验证计划，而不是直接判定文档错误或功能缺陷。
结论表述
最终结论按三类表述：已确认——支持按部门层级继承数据范围，实测可完成；待确认——组织架构变更后的生效时机与文档描述存在差异，需在指定版本下复验；不适用——按角色覆盖继承规则的细粒度配置，在当前试用套餐中未见入口，暂不作为差距结论。这样的表述让产品规划能直接使用，也保留了后续验证的入口。
可迁移的做法有三点：功能点先写成可判断的问题；文档、实测、客户反馈分别登记并标注性质；冲突不急于下结论，转为待确认项并安排复验。
完成检查：分析结果是否可用
报告提交评审前，用下面的清单逐项核对。前四项为阻断项，未通过则报告不能用于规划决策；后两项为质量项，影响报告的可复用程度。
| 检查项 | 通过标准 | 类型 |
|---|---|---|
| 来源与日期完整 | 每个功能结论都有来源、获取日期和版本口径，可回溯到证据表具体记录 | 阻断项 |
| 依据性质已区分 | 一手材料、实测记录与二手信息分别标注，二手信息未被当作存在性结论 | 阻断项 |
| 未确认项有验证计划 | 所有待确认项写明复验条件、负责人和时间 | 阻断项 |
| 结论回应决策问题 | 每条结论对应分析范围说明中的决策问题，无孤立结论 | 阻断项 |
| 证据表可被复核 | 他人按登记信息能独立找到来源并复现验证步骤 | 质量项 |
| 结论表述分级清晰 | 已确认、待确认、不适用三类表述使用一致，无模糊措辞 | 质量项 |
检查通过后，报告连同证据表一并归档，作为下一轮分析的基线。竞品版本更新或客户场景变化时，从待确认项和差异说明出发增量更新，不必每次从头取证。
常见问题
试用环境里没找到某个功能入口，可以直接判定竞品不支持吗？
不建议直接下“不支持”的结论。试用账号的套餐版本、角色权限、租户配置都可能限制入口可见性，实测结果只能说明“在当前配置下未验证通过”。
更稳妥的处理是：记录试用账号的版本、角色和操作步骤，附截图，标记为待确认项，写明复验条件（例如换管理员角色、换更高套餐、查阅对应版本的更新日志），再安排下一轮验证。这样既保留了实测证据，也避免因环境差异得出错误结论。
官方文档写的能力和实测结果对不上，以哪个为准？
两者都保留，分别登记，不急于判定谁对谁错。冲突的常见原因包括版本差异、套餐限制、角色权限不同，以及文档更新滞后于实现。
处理方式是记录冲突点、对应版本和操作步骤，归因后转为待确认项，列入复验计划。如果复验后仍不一致，在报告中同时呈现文档表述和实测结果，并注明验证前提，让使用方自己判断。直接采信文档或直接否定文档，都会让结论失去可复核性。
客户案例、应用市场评价这类外部信息，在分析里怎么用才不越界？
这类信息适合发现问题线索，不适合直接支撑功能存在性或能力高低的结论。样本有限、表述立场不同，都会影响其代表性。
可行的用法是：把用户反复抱怨的点、案例中强调的场景、评价里提到的操作细节，转化为待验证的功能点，进入试用验证清单。引用时标注“线索”性质，附上后续验证计划。这样外部信息起到了提示方向的作用，结论仍然建立在一手材料和实测之上。
团队规模小，一个人兼做取证和评审，怎么保证分析质量？
角色可以兼任，交付物建议分开留存。取证的人同时写结论，容易把验证过程中的假设带进结论，所以至少让另一位同事做一次抽查。
具体做法：证据登记表完成一轮后，由未参与取证的人按登记信息独立找到来源、复现关键验证步骤；结论评审时重点看每条结论能否回溯到证据表记录、待确认项是否都有复验计划。抽查不必覆盖全部功能点，优先覆盖影响规划决策的关键项。
竞品更新频繁，上一轮的分析报告还能继续用吗？
可以作为基线增量更新，不必每次从头取证。报告归档时连同证据表一并保存，下一轮从待确认项和差异说明出发，优先复验受版本更新影响的功能点。
触发更新的信号包括：竞品发布新版本或更新日志出现相关条目、客户在选型中提出新的对比问题、自家规划方向调整。更新时沿用同一套版本口径和登记格式，保证新旧证据可以横向比较。
