产品差异分析的依据，要能回答三个问题：差异是否真实存在、差异对目标用户是否有意义、差异能否被持续验证。可用的依据分为四类：产品自身可观察的事实、用户侧证据、市场侧证据和内部规划依据。每类依据都要标注来源、获取时间、口径和可信度，形成可复核的证据表，再据此写出差异判断。下文按“定口径—采依据—下结论—分角色—看示例—做核对”的顺序展开。
要点总览（TL;DR）
- 差异分析先定口径：写清分析对象是整体产品、功能模块还是细分场景，选定功能覆盖、使用流程、定价结构、集成与部署、服务与支持等维度，并说明结论用于路线图取舍、定位描述还是销售话术。
- 依据分四类采集：产品事实（公开文档、版本记录、定价页、帮助中心、演示环境）、用户侧（访谈、工单、流失与续约原因、行为数据）、市场侧（行业报告、招投标公告、渠道反馈）、内部规划（路线图、资源约束、战略目标）。
- 每类依据统一进证据表，记录编号、来源、获取时间、口径、可信度和支撑的差异判断；关键差异至少用两类独立依据交叉验证，单点证据只列为待验证线索。
- 差异结论按四要素写：差异描述、支撑证据编号、对目标用户的影响、置信度，并区分真实差异、表述差异和待验证差异，待验证项写明验证方式与负责人。
- 交付前逐项核对：依据是否可追溯、关键差异是否交叉验证、待验证项是否落实、结论是否与用途匹配、是否设定复核与更新时点。
差异分析先定判断口径：分析对象、比较维度和结论用途
差异分析最常见的返工原因，是依据收集了不少，却无法支撑任何一条结论。问题往往出在收集之前：没有说清分析什么、比什么、结论给谁用。开始采集前，先用一页纸把这三件事定下来。
第一，明确分析对象。整体产品、某个功能模块、某个细分场景，三者的证据范围差别很大。分析对象写成“协作模块在跨部门审批场景中的表现”，比写成“我们的产品”更容易界定该收哪些文档、访谈哪些用户。
第二，确定比较维度。建议从功能覆盖、使用流程、定价结构、集成与部署方式、服务与支持五个维度中选择，并给每个维度写出可观察的定义。维度定义要具体到能判断“有或没有、深或浅”，例如“集成方式”定义为“是否提供开放接口、是否支持单点登录、部署形态有哪些”，而不是笼统写“集成能力强”。
第三，说明结论用途。用于路线图取舍时，证据要能说明投入产出与用户规模；用于定位描述时，证据要能支撑对外可讲的差异点；用于销售话术时，证据要经得起客户当场追问。用途不同，对证据强度和交叉验证的要求也不同。
| 维度 | 定义要点 | 典型证据形式 | 证据强度要求 |
|---|---|---|---|
| 功能覆盖 | 某场景下必须具备的能力是否具备、覆盖到什么程度 | 公开文档、演示环境、版本记录 | 文档事实加演示核对 |
| 使用流程 | 完成一个任务需要几步、角色如何交接 | 演示录屏、用户访谈、工单 | 至少两类独立依据 |
| 定价结构 | 计费单位、套餐分层、增项收费方式 | 公开定价页（记录获取日期） | 以官方页面为准，注明日期 |
| 集成与部署 | 接口开放程度、部署形态、实施条件 | 公开文档、售前技术确认 | 技术角色核对 |
| 服务与支持 | 支持渠道、响应约定、培训与迁移协助 | 服务条款、客户反馈 | 条款加用户实际体验 |
这张维度定义表就是后续证据归档的统一口径。每一条证据进入证据表时，都要标明它对应哪个维度，避免同一份材料在不同章节被解读成不同含义。
四类依据的采集方法与证据表字段
口径确定后，按四类来源分头采集。每类来源的采集动作和记录重点不同，但最终都汇入同一张证据表。
产品事实类依据
来源包括公开文档、版本更新记录、定价与套餐页、帮助中心、演示环境。采集时记录获取日期和页面口径，例如“定价页，2025年某月某日抓取，按年付费口径”。版本更新记录尤其要注意时间线：旧版本的能力描述不能当作现状使用。演示环境适合核对流程类差异，操作一遍并截图留存，比只读文档更可靠。
用户侧依据
来源包括访谈记录、工单分类、流失与续约原因、使用行为数据。访谈要附提纲和样本说明，例如访谈了几类角色、各几人、如何抽样；工单按主题分类统计，给出时间段和总量；流失原因区分用户自述与推断。用户侧依据的价值在于回答“差异对目标用户是否有意义”，但个别反馈不能代表整体，样本量和抽样方式必须写清。
市场侧依据
来源包括公开行业报告、招投标公告、渠道与合作伙伴反馈。记录报告发布方、发布时间和统计口径，区分第三方结论与厂商自述。招投标公告能反映采购方写进标书的要求，是判断“哪些能力被市场当作门槛”的实用材料。渠道反馈属于一线观察，标注反馈人角色和反馈时间即可，不夸大为行业结论。
内部规划依据
来源包括路线图、资源约束和战略目标。这类依据决定差异结论能否落地，记录时要说明决策层级：是部门已确认的方向，还是个人判断。把个人判断写成组织结论，会让后续路线图讨论失去基础。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 依据编号 | 按类别加序号，全文唯一 | F-03、U-07、M-02、I-01 |
| 类别 | 产品事实／用户侧／市场侧／内部 | 用户侧 |
| 来源 | 具体到文档名、访谈批次、报告名或公告编号 | 某季度客户访谈第二批 |
| 获取时间 | 精确到日期 | 某月某日 |
| 口径 | 统计范围、版本、样本说明 | 5名管理员角色，抽样自续约客户 |
| 可信度 | 高／中／低，附一句理由 | 中：样本小但反馈一致 |
| 支撑的差异判断 | 对应差异结论编号 | D-02 |
证据表建议由产品经理维护主表，各来源负责人提交条目后统一编号。采集与汇总如果分散在聊天记录和本地文件里，复核时很难追溯，可以把采集任务作为工作项分派到人，把证据表和口径说明放在同一份协作文档中持续更新。ONES 的工作项与文档可以承载这种“任务分派—条目提交—文档汇总”的流程，让每条依据的来源和提交人有记录可查。
从证据到差异判断：筛选、交叉验证与结论写法
证据收齐后，先按维度归并，再逐条判断。归并时剔除两类条目：口径与本次分析不一致的，例如用旧版本资料描述现状；来源不可追溯的，例如只有一句“听说”而没有记录人和时间。
对关键差异，至少用两类独立依据交叉验证。文档事实加用户访谈是常用组合：文档说明能力存在，访谈说明用户是否感知、是否在用。只有单点证据的，先列为待验证线索，不写成结论。
判断时把差异分成三种状态：真实差异，指两类以上依据一致支持；表述差异，指双方能力接近但对外描述不同，这类差异对定位有用，对路线图意义有限；待验证差异，指证据不足或相互矛盾，需要写明验证方式和负责人，例如“安排三次客户演示核对流程步骤，由产品经理在某日期前完成”。
结论按固定四要素写：差异描述、支撑证据编号、对目标用户的影响、置信度。差异描述用可观察的事实，例如“审批流程中支持按金额分级设置审批人”，避免“体验更流畅”这类无法核对的表述。置信度分为高、中、低，并附一句依据说明。
| 差异编号 | 差异描述 | 支撑证据 | 对目标用户的影响 | 置信度 |
|---|---|---|---|---|
| D-01 | 审批流程支持按金额分级设置审批人 | F-02、U-03、U-05 | 财务审批场景减少人工转交 | 高：文档与访谈一致 |
| D-02 | 移动端审批入口层级较深 | U-07、工单统计 | 外勤角色提交频率下降 | 中：待演示核对 |
角色分工与交付物：谁采集、谁判断、谁复核
差异分析涉及多个信息来源，分工不清会导致证据重复采集或无人认领。按来源划分职责，比按章节划分更清楚。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 产品经理 | 定义分析口径与维度，汇总证据表，撰写差异结论 | 口径说明、证据表主表、差异结论表 |
| 市场或竞品研究角色 | 采集公开信息与市场侧依据，维护来源记录 | 公开资料条目、报告与公告摘录 |
| 用户研究或客户成功 | 组织访谈，整理工单分类与流失续约原因 | 访谈记录与样本说明、工单统计 |
| 研发或售前 | 核对功能事实与技术口径，确认集成与部署描述 | 技术核对意见 |
| 复核人 | 检查证据与结论的对应关系，确认待验证项已落实 | 复核意见与签署后的结论表 |
各环节的交接点要明确：证据条目提交后由产品经理统一编号入库；差异结论初稿完成后交复核人逐条核对证据编号；复核通过后结论表才进入路线图讨论或对外材料。复核人建议由不参与采集的人担任，避免自己核对自己。
示例：一次模块级差异分析的依据组织
以下为演示情景，用于说明依据如何支撑一条差异结论，不涉及任何具体产品的真实能力或价格。
分析对象定为“协作模块在跨部门审批场景中的表现”，比较维度选使用流程和服务与支持两项，结论用途是路线图取舍。采集阶段获得三类依据：公开帮助文档中关于审批设置的条目两条（F-01、F-02）；针对管理员角色的访谈五份，其中三份提到审批人调整需要人工转交（U-03、U-05、U-06）；近一个季度的工单分类统计显示，审批相关咨询占该模块工单的一定比例（U-09）。
推导过程：文档证实分级审批能力存在（F-02），访谈说明部分用户在实际流程中仍需人工转交（U-03、U-05），工单统计显示相关咨询集中（U-09）。三类依据指向同一方向，形成结论 D-01“审批流程支持按金额分级设置审批人，但部分用户未配置使用，导致人工转交”，置信度定为高。另一条线索“移动端审批入口层级较深”只有访谈和工单两类用户侧依据，缺少演示核对，列为待验证项，验证方式为安排三次客户演示观察操作路径，负责人为产品经理。
进入路线图讨论时，D-01 的用法是：能力已具备，优先事项是配置引导与模板化设置，而非新功能开发；待验证项在下一轮演示完成后更新结论。这样一条差异结论同时回答了“差异是否存在”“对用户是否有意义”“如何继续验证”三个问题。
完成检查：差异分析交付前的核对项
交付前逐项核对以下清单，全部通过再进入评审或对外使用。
- 每条差异是否至少有一类可追溯依据，关键差异是否完成两类独立依据的交叉验证。
- 证据表是否记录来源、获取时间、口径和可信度，编号是否全文唯一。
- 待验证项是否写明验证方式、负责人和完成时点。
- 结论是否与用途匹配：路线图用途是否说明了用户规模与投入判断，对外用途是否经得起追问。
- 结论中事实与推断是否分开表述，推断部分是否标注置信度。
- 是否设定复核时点与更新触发条件，例如版本发布后、季度复盘时重新核对定价与能力描述。
- 复核人是否已逐条核对证据编号与结论的对应关系并签署。
核对中发现证据缺口时，回到证据表补充采集，不直接在结论里用推断填补。差异分析的价值在于结论可复核，一份经得起逐条追溯的证据表，比一份写得漂亮但来源模糊的报告更有用。
常见问题
分析对象只写“我们的产品”会带来什么问题？
对象过宽会让证据范围无法界定：该收哪些文档、访谈哪类角色、看哪些竞品页面都说不清，最后容易变成材料堆砌。把对象收窄到可界定的范围，例如“协作模块在跨部门审批场景中的表现”，采集动作和证据归档才有统一标准，结论也能对应到具体的规划讨论。
用户访谈和工单数据应该采多少才算够？
没有统一的数量门槛，关键是写清样本说明：访谈覆盖了哪几类角色、各几人、如何抽样；工单统计的时间段和总量是多少。样本小但反馈方向一致时，可以作为中等可信度依据，并与文档事实交叉验证；样本大但集中在单一客户类型时，结论适用范围要相应收窄。个别反馈只作为线索，不直接写成整体结论。
公开定价页和版本记录这类信息，记录时要注意什么？
这两类信息会随时间变化，记录时必须带获取日期和页面口径，例如“按年付费口径”“某版本更新说明”。版本记录要看清时间线，旧版本的能力描述不能当作现状使用。定价页建议留存页面截图或存档链接，后续复核时能对照当时的口径，避免用当前页面解释几个月前的结论。
两类依据交叉验证后结论仍相互矛盾，该怎么处理？
先检查口径是否一致：文档描述的是能力是否存在，访谈反映的是用户是否感知和实际使用，两者矛盾往往说明能力存在但落地不足，这本身就是一条有价值的差异。若口径一致仍矛盾，把该条列为待验证差异，写明验证方式（如安排客户演示核对操作路径）、负责人和完成时点，不强行合并成一个结论。
差异分析多久需要复核一次？
建议设定明确的更新触发条件，而不是固定周期：竞品版本发布后、自家版本发布后、季度复盘时，重新核对定价、能力描述和用户反馈数据。复核时重点看结论所依赖的证据是否仍然成立，失效的条目更新或标注，结论置信度随之调整。复核人由不参与采集的人担任，逐条核对证据编号与结论的对应关系。
