通用产品竞品分析的能力维度，建议围绕“用户完成任务所需的能力”来搭建：先固定核心功能覆盖与深度、性能与稳定性、易用性与学习成本、集成与开放性、数据与安全合规、可扩展与定制、服务与支持、成本结构这组基础维度，再按本篇产品的关键购买因素增删并赋权。每个维度都要落到可观察的判定项、证据来源和统一评分口径，形成可复用的对比表，用于产品规划判断。
要点总览（TL;DR）
- 通用产品竞品分析可先固定八项基础维度：核心功能覆盖与深度、性能与稳定性、易用性与学习成本、集成与开放性、数据与安全合规、可扩展与定制、服务与支持、成本结构。
- 维度应从目标用户任务和关键购买因素推导，功能清单只作素材；基础维度保持稳定，特有维度按产品类型增删。
- 每个维度要拆成可观察的判定项，并记录证据来源与获取时间；无法确认的信息标注为待验证，不混入已确认评分。
- 权重按关键购买因素分配，所有竞品使用同一张评分表和同一套刻度，评分人先独立打分再合议。
- 框架定稿前逐项核对维度与任务对应、证据充分性、待验证项闭环和更新机制，确保他人能凭框架和对比表复现主要结论。
先定维度框架：从用户任务到能力维度
竞品分析的维度框架应从目标用户要完成的任务推导，功能清单只能作为素材。具体做法是先写出目标用户在典型场景中的任务链，例如“导入数据—配置规则—协同处理—导出结果—复盘”，再逐段追问：用户完成这一步需要产品具备什么能力，哪些能力会直接影响购买决策。任务链上的每个关键动作，都可能对应一个待比较的维度。
推导时可以把信息来源分成三类：一是用户访谈和售前反馈中反复出现的关注点，二是产品规划中已确定的方向，三是竞品公开资料中反复强调的能力。三类信息交叉出现的内容，通常值得进入维度框架；只在单一来源出现的内容，先记为候选维度，不急于纳入正式对比。
维度需要分层。基础维度适用于大多数通用产品，保证不同竞品之间可以横向比较；产品特有维度来自本篇产品的业务场景和关键购买因素，用来解释差异。例如协作类产品可能增加权限粒度与审计能力，硬件相关产品可能增加兼容性与部署环境要求。分层的好处是：基础维度保持稳定，特有维度可以随产品阶段调整，不会每次分析都推倒重来。
维度数量控制在可执行范围。建议基础维度保留六到八个，特有维度控制在三到五个；每个维度下再设三到五个判定项。维度过多会导致证据收集成本上升、评分失去区分度；维度过少则容易漏掉关键购买因素。完成标志是：框架草案能覆盖主要用户任务，每个维度都能说清“为什么用户在意它”。
通用能力维度的判定项与证据来源
维度只有拆成可观察的判定项，才能避免“功能强”“体验好”这类无法比较的描述。下表给出一组建议口径，实际使用时可按产品类型调整判定项，并在表头注明口径版本。
| 能力维度 | 可观察判定项 | 主要证据来源 |
|---|---|---|
| 核心功能覆盖与深度 | 关键任务是否可完整完成；边界场景是否支持；操作步骤数量；结果可配置程度 | 产品文档、公开演示、试用记录、客户访谈 |
| 性能与稳定性 | 典型数据量下的响应时间；并发或批量处理表现；故障恢复方式；公开的性能说明 | 试用压测记录、公开技术文档、客户反馈 |
| 易用性与学习成本 | 首次完成核心任务所需时间；帮助文档完整度；默认配置合理性；常见任务的操作路径 | 试用观察、文档浏览、用户访谈 |
| 集成与开放性 | 是否提供公开接口；支持的数据导入导出格式；与常见系统的连接方式；扩展开发文档 | 开发者文档、公开资料、试用验证 |
| 数据与安全合规 | 权限模型粒度；数据加密与备份说明；审计日志；公开的合规声明 | 官方文档、合规页面、法务或安全团队确认 |
| 可扩展与定制 | 字段、流程、界面的可配置范围；二次开发支持；定制交付周期 | 产品文档、售前说明、客户案例 |
| 服务与支持 | 支持渠道；响应时效说明；实施与培训方式；知识库质量 | 服务条款、公开资料、客户访谈 |
| 成本结构 | 计价方式；包含项与额外项；迁移和培训的隐性投入 | 公开报价资料、售前沟通记录 |
证据来源要按可信度分级。公开文档和试用记录可复核，优先级较高；客户访谈能反映真实使用感受，但需要多个样本互相印证；销售材料和宣传页面适合发现线索，不宜直接作为结论依据。每条证据都应记录获取时间、版本或环境，避免后续引用时口径漂移。
无法确认的信息统一标注为“待验证”，并写明验证方式和责任人。例如“竞品是否支持批量导入，待试用验证”，而不是直接写成支持或不支持。待验证项在汇总评分时单独列出，不混入已确认结论，这样差距说明才能区分事实和推测。
按产品类型增删维度并设置权重
基础维度提供比较骨架，权重决定比较结果向哪一侧倾斜。识别关键购买因素可以从三个问题入手：用户在选型时最先问什么；哪些能力缺失会直接导致放弃；哪些差异在续约或扩容时被反复提及。把访谈、售前记录和流失原因中的高频关注点整理出来，与基础维度对照，就能判断哪些维度需要提高权重、哪些需要补充特有维度。
增删维度要有判断标准。出现以下情况时考虑新增维度：该能力直接影响核心任务完成；用户愿意为它单独付费或单独评估；竞品之间存在明显差异。出现以下情况时考虑合并或删除：多个维度指向同一判断；证据长期无法获取；该能力对本篇产品的目标用户不构成选择差异。删除的维度记录在框架说明中，便于后续复盘时恢复。
权重分配建议采用百分制或总分十分制，先按关键购买因素排序，再分配数值。评分刻度要事先统一，例如一分代表“缺失或明显不足”，三分代表“满足主要场景”，五分代表“覆盖完整且有明显优势”；中间分值的含义也要写清楚。所有竞品使用同一张评分表和同一套刻度，评分人先独立打分再合议，减少口径不一致。
| 维度 | 权重 | 评分刻度说明 | 加权得分 |
|---|---|---|---|
| 核心功能覆盖与深度 | 25% | 1–5分，按关键任务完成度打分 | 评分×权重 |
| 易用性与学习成本 | 15% | 1–5分，按首次完成任务耗时和文档完整度打分 | 评分×权重 |
| 集成与开放性 | 15% | 1–5分，按接口覆盖和验证结果打分 | 评分×权重 |
| 数据与安全合规 | 15% | 1–5分，按已确认的权限与审计能力打分 | 评分×权重 |
| 性能与稳定性 | 10% | 1–5分，按试用记录打分 | 评分×权重 |
| 可扩展与定制 | 10% | 1–5分，按配置范围和交付周期打分 | 评分×权重 |
| 服务与支持 | 5% | 1–5分，按支持渠道和响应说明打分 | 评分×权重 |
| 成本结构 | 5% | 1–5分，按总投入可预期程度打分 | 评分×权重 |
上表是模板示例，权重数值需按本篇产品的关键购买因素重新分配，不能直接套用。权重确定后应经过一次评审，确认评分口径与业务判断一致，再开始批量收集证据。
角色分工与交付物
维度框架能否落地，取决于每个环节是否有人负责、有明确产出。角色分工可以按下表组织，团队规模较小时一人可兼多个角色，但职责边界仍需写清。
| 角色 | 主要任务 | 输入 | 交付物 |
|---|---|---|---|
| 产品经理 | 推导用户任务与关键购买因素，确定维度集合和权重 | 用户访谈、路线图、售前反馈 | 维度框架草案、权重表 |
| 市场研究 | 收集公开资料，组织竞品信息归档 | 公开文档、行业资料 | 证据清单与来源记录 |
| 技术或售前 | 试用验证集成、性能、扩展等判定项 | 试用环境、技术文档 | 验证记录与待验证项清单 |
| 法务或合规 | 确认安全合规相关表述的准确性 | 合规声明、合同条款 | 合规确认意见 |
| 评审人 | 审核维度、权重和评分口径的一致性 | 框架草案、对比表 | 评审意见与定稿版本 |
各环节的交接以文档状态为准：框架草案完成后进入评审，评审通过后冻结为本期口径；证据收集阶段只补充记录，不随意改动维度；对比表定稿后由产品经理维护版本，市场研究负责更新公开资料变化。建议每季度或产品重大版本前复核一次，复核内容包括维度是否仍对应主要用户任务、待验证项是否已闭环、权重是否仍反映购买因素。
维度框架、证据记录和对比结论适合沉淀在同一处文档中，并与后续的产品需求工作项关联。以ONES为例，团队可以在文档中维护维度框架和对比表，评审意见留在文档讨论中；对比结论形成的改进项可以直接建立为需求或任务工作项，指派负责人并跟踪状态，让竞品分析的结论进入规划流程，而不是停留在一次性报告里。
示例：一张竞品能力对比表怎么填
以下示例为演示情景，竞品名称以A、B代替，评分仅用于说明填写方式，不代表真实产品结论。
| 维度 | 判定项 | 竞品A | 竞品B | 证据与状态 |
|---|---|---|---|---|
| 核心功能覆盖与深度 | 关键任务能否完整完成 | 4分：主流程完整，边界场景需人工处理 | 3分：主流程可用，部分步骤缺失 | A依据试用记录；B依据公开文档，待试用验证 |
| 集成与开放性 | 是否提供公开接口及导入导出 | 4分：接口文档完整，已验证两类连接 | 2分：仅支持固定格式导出 | A依据开发者文档和试用；B依据公开资料 |
| 易用性与学习成本 | 首次完成核心任务所需时间 | 3分：约半天，文档较完整 | 4分：约两小时，默认配置合理 | 两人分别试用后合议 |
| 数据与安全合规 | 权限粒度与审计日志 | 4分：支持细粒度权限和操作日志 | 待验证 | B的合规声明未覆盖该点，待法务确认 |
填写时先写判定项，再写评分和一句依据，最后标注证据状态。评分相同的判定项也要保留依据，便于复核时判断是否口径一致。待验证项不参与加权汇总，单独列在表尾。
从表格读差距时，先看加权总分，再看单项差距是否集中在高权重维度。例如上表中竞品A在集成开放性上领先，且该维度权重较高，说明这一差距对规划判断影响较大；竞品B在易用性上占优，但若目标用户更看重集成能力，则该优势不足以改变结论。差距结论应写成“在什么任务、什么条件下存在差距”，并对应到具体判定项和证据，避免只给一句“整体更强”。
完成检查：维度框架是否可用
框架定稿前，用以下清单逐项核对，全部通过再用于产品规划讨论。
- 维度与用户任务对应：每个维度都能指向至少一个用户任务或关键购买因素，没有与任务无关的凑数维度。
- 判定项可观察：每个判定项都能用“是/否、数量、耗时、覆盖范围”等方式描述，不出现无法验证的形容词。
- 证据充分：高权重维度的判定项有可复核证据；仅有宣传材料的结论已标注来源和局限。
- 待验证项清晰：每条待验证信息写明验证方式、责任人和计划完成时间，且未混入已确认评分。
- 权重与评分口径一致：所有竞品使用同一张评分表、同一套刻度，权重合计为100%，评分人已合议。
- 结论可追溯：差距说明能对应到具体判定项和证据记录，不出现无依据的整体判断。
- 更新机制明确：指定了框架维护人、复核周期和触发条件，例如产品重大版本发布或关键购买因素变化。
通过检查的标志是：另一位未参与分析的同事能仅凭框架说明和对比表复现主要结论，并指出哪些结论仍待验证。达到这一状态，维度框架就可以作为本期竞品分析的稳定口径，并在下一次分析中复用和迭代。
常见问题
基础维度已经固定，还需要为每个产品单独设计特有维度吗？
需要，但数量要克制。基础维度保证不同竞品之间可以横向比较，特有维度用来解释本篇产品所在场景的差异。判断是否新增特有维度，可以看三点：该能力是否直接影响核心任务完成；用户是否愿意为它单独评估或付费；竞品之间是否存在明显差异。建议特有维度控制在三到五个，每个维度下设三到五个判定项，避免证据收集成本过高。
竞品公开资料很少，判定项的证据怎么补？
公开资料不足时，可以按可信度分层补充证据：优先使用可复核的试用记录和开发者文档；客户访谈需要多个样本互相印证；销售材料和宣传页面只作为线索。对确实无法确认的判定项，统一标注“待验证”，写明验证方式、责任人和计划完成时间，并在加权汇总时单独列出，不混入已确认评分。这样差距说明能区分事实和推测。
权重应该由谁定，定完之后还能调整吗？
权重通常由产品经理根据用户访谈、售前反馈和流失原因中的高频关注点提出，再经评审确认与业务判断一致。权重确定后，本期分析应保持稳定，避免中途调整导致不同竞品口径不一致。遇到产品重大版本发布或关键购买因素明显变化时，可以启动复核并更新权重，同时记录调整原因和生效范围，便于后续对比时理解口径差异。
对比表里出现多个待验证项，还能用于规划讨论吗？
可以，但要把待验证项与已确认结论分开呈现。建议在表尾单列待验证清单，说明每项对结论的影响程度：如果待验证项集中在低权重维度，可以先基于已确认部分讨论；如果高权重维度存在待验证项，应优先安排试用或访谈补齐，再给出规划判断。讨论记录中注明哪些结论依赖待验证信息，后续闭环后更新对比表。
框架多久复核一次比较合适？
常见做法是每季度复核一次，并在产品重大版本发布或关键购买因素变化时触发临时复核。复核内容包括：维度是否仍对应主要用户任务；待验证项是否已闭环；权重是否仍反映当前购买因素；证据记录是否需要更新版本和时间。复核由指定的框架维护人组织，评审意见和定稿版本留在同一处文档中，保证下一次分析可以直接复用。
