竞品分析为什么不该从参数表开始

很多竞品分析都从一张表开始。

左边列产品，右边列功能、价格、性能、尺寸、模型和渠道。格子越多，报告看起来越完整；勾选越密，产品似乎越有竞争力。

但这张表经常跳过一个更早的问题：用户究竟在做什么选择？

一个团队采购项目管理软件时，比较对象可能不只是另外三款项目管理软件，还包括 Excel、微信群、邮件、内部系统，以及继续维持现状。一个家庭购买清洁机器人时，比较对象也不只是其他机器人，还包括吸尘器、保洁服务、已有设备和暂时不买。

如果没有先定义用户、情境、任务和现有方案，参数表比较的只是“看起来相似的产品”，不一定是用户会互相替换的方案。

更麻烦的是，软件和硬件虽然都能列参数，却遵循两套不同的竞争逻辑。

软件竞争往往围绕工作流、数据状态、组织采用和持续变化展开；硬件竞争还要面对物理约束、批量一致性、生产交付、生命周期与售后网络。智能硬件则同时运行着两只时钟：软件持续更新，硬件版本却要经过更长的设计、验证、生产和库存周期。

所以，竞品分析要先回答：

谁会在什么时刻，为了完成什么任务，从哪个现有方案切换过来；获得的收益，是否足以覆盖切换成本与采用风险？

参数表仍然有用，但它应该出现在分析的后半段，而不是第一页。

一、参数表为什么总是开始得太晚

参数表默认了三个前提：比较对象已经正确，指标已经重要，指标之间可以直接比较。

现实里，这三个前提经常都不成立。

第一，品类相同，不等于互为竞品。 同样叫“AI 助手”的产品，可能分别服务个人写作、企业客服和开发运维；它们共享技术名词，却不争夺同一个用户、预算和任务。

第二，可测量，不等于会影响选择。 上下文长度、摄像头像素、峰值算力和电池容量容易写进表格，但用户可能更在意首次配置是否成功、团队权限是否清楚、设备会不会发热、戴一小时是否难受，以及出故障后由谁处理。

第三，指标不是彼此独立的。 硬件的重量、续航、散热、结构强度和成本相互牵制；软件的自动化程度、可控性、学习成本和权限风险也会互相影响。单独比较每个格子，很容易得到一台“每项都更强”、整体却不好用的纸面产品。

参数表会把一个选择问题过早地变成产品问题。

二、起点：用户的选择集合

更可靠的竞品分析，应先建立一个最小的“决策契约”：

目标用户：是谁在用，谁在买，谁会否决；
触发情境：什么变化让他开始寻找方案；
目标任务：他想完成什么结果；
当前流程：今天怎样完成，哪里不满意；
决策范围：市场、价格、地区、渠道和时间；
分析目的：这次分析要改变哪个产品或商业决策。

有了这些边界，比较对象才能按用户的真实选择进入四个集合。

选择类型	定义	常见例子
直接竞品	相近产品服务相近用户、任务与购买情境	同类 SaaS、同价位机器人、同形态穿戴设备
替代方案	不同产品或流程完成同一个任务	表格代替专业软件，人工服务代替机器
非对称选择	更便宜、更简单、已捆绑或自行建设的方案	套件内置功能、内部工具、租赁、二手设备
不行动	延后购买，继续忍受现状	维持旧流程、继续使用已安装设备

只有直接竞品，很容易把分析做成“同行抄了什么”；加入替代方案，才能看见现有工作流和真实切换门槛；加入非对称选择与不行动，才能理解为什么一款功能更少的产品、一个免费内置能力，甚至什么都不做，仍然可能赢。

最终的比较关系可以写成一个简单的不等式：

用户感知到的增益 > 切换成本 + 采用风险

竞品分析的任务，就是把不等式两边具体化，而不是证明自家参数更多。

三、软件竞品分析：比较的是一条持续运行的工作流

软件没有固定在某个版本。功能可以按周甚至按天变化，界面截图和功能勾选会迅速过期。DORA 用变更前置时间、部署频率、失败部署恢复时间等指标描述软件交付能力，也说明软件产品的竞争不只发生在某个静态版本，还发生在持续改进与恢复能力上。

因此，软件竞品分析应以一条端到端工作流为基本单位。

例如，比较几款企业知识助手，不能只看是否支持问答、模型名称和连接器数量。更值得比较的是：

谁能把现有资料接入系统；
权限能否沿用，敏感内容会不会越权出现；
用户能否得到带来源、可检查的答案；
找不到答案时，系统如何暴露不确定性；
团队怎样纠错、补充和维护知识；
退出产品时，数据与配置能否迁移。

一项功能只有进入完整流程，才会成为用户价值。软件比较至少要进入以下层面。

1. 时间到价值：多久拿到第一次可信结果

从注册到第一次获得可信结果，需要多少配置、导入、培训和跨部门协调？一个能力强但部署三个月的产品，未必能赢过当天即可进入工作的较简单方案。

2. 工作流适配：省下的时间有没有转嫁给别人

产品是否嵌入用户已经使用的工具、角色和审批关系？如果节省了个人五分钟，却给管理员增加了权限维护，或者迫使上下游重复录入，它可能只是把成本转移了。

3. 数据与上下文：用户积累的状态能不能带走

软件会逐步积累文档、历史、规则、模板、成员关系和自动化配置。这些状态既构成产品价值，也构成迁移成本。分析必须看清用户要带走什么、重新配置什么、丢失什么。

4. 协作与治理：谁使用、谁购买、谁会否决

面向组织的软件，购买者、管理员、使用者、安全团队和财务往往不是同一个人。个人觉得好用，不代表组织能够部署；组织容易采购，也不代表一线愿意改变习惯。

5. 可恢复性：失败后能否继续工作

自动化是否可暂停、撤销、审计和重放？外部系统异常、模型出错或权限变化时，用户能否理解发生了什么并恢复工作？失败处理常常比成功演示更能解释长期留存。

软件竞争要看谁能以更低成本进入真实工作流，承接用户已有状态，并在持续变化中保持可靠。某个版本多一个功能，很难单独决定结果。

四、硬件竞品分析：比较的是一个被交付到现实世界的系统

硬件也有功能与规格，但它首先是一个物理系统。

它需要在特定重量、体积、功耗、散热、材料、结构、成本和生产条件下工作。每增加一项能力，都可能改变其他部分。更大的电池增加续航，也可能增加重量和充电时间；更高性能带来更强能力，也可能带来温升、噪声和成本；更轻的结构可能影响强度、维修方式和寿命。

所以硬件参数不能逐项独立“拉满”，竞品分析必须进入系统包络与真实环境。

NASA 的系统工程方法区分验证与确认：前者检查产品是否符合设计要求，后者确认产品在预期环境中是否满足预期用途。这个区别对消费硬件同样重要。实验室里达到某项指标，不代表用户在日常环境里能完成任务。

硬件比较至少还要增加六层。

1. 物理体验

重量分布、握持、佩戴压力、噪声、温度、材质、按钮位置和安装空间，很难被一串规格完整表达。它们必须在代表性的时间、动作和环境中体验。

2. 约束耦合

不要分别问“续航是否更长”“性能是否更高”，而要问产品在目标体积、重量、温度和价格下，能否持续完成任务。系统表现比单点峰值更重要。

3. 批量一致性与可靠性

媒体评测的一台工程样机不能代表用户收到的每一台量产机。材料、供应商、装配、运输和环境差异都会影响结果。NIST 对制造生命周期的描述覆盖设计、工艺规划、生产工程、制造、使用与服务、报废和回收，也提醒分析不能停在样机阶段。

4. 安装、学习与维护

是否需要上门安装、空间改造、耗材、校准、清洁和定期维护？用户买下的不只是设备，还接受了一套长期行为。

5. 渠道、库存与服务

产品在哪里试用和购买，多久到货，故障后是换新、寄修还是上门，备件能供应多久？FTC 对消费品保修的说明把覆盖期限、维修范围、处理流程和运输成本都列为购买时应检查的内容。售后本身就是硬件长期价值的一部分。

6. 全生命周期成本

购买价格只是起点，还要计算配件、耗材、订阅、维修、闲置、残值和替换周期。对于企业硬件，还可能包括部署、培训、场地、安全和停机成本。

硬件竞争要把足够一致、可靠、可维护的系统交付给大量用户，并对它的整个生命周期负责。最好看的样机，只完成了很前面的一步。

五、同一个词，在软件和硬件里不是同一种证据

软件和硬件可以共享比较框架，但证据不能直接套用。

比较维度	软件产品	硬件产品
基本比较单位	端到端工作流	现实环境中的系统任务
产品状态	数据、配置、权限、历史与集成	设备、固件、配件、环境与服务系统
迭代方式	可持续部署，版本快速变化	设计冻结、验证、生产与库存形成长周期
性能证据	真实数据下的完成率、延迟、错误与恢复	代表性环境、时长和批次下的持续表现
失败处理	回滚、重试、人工接管、审计	安全降级、停机、维修、召回或更换
切换成本	数据迁移、集成重做、培训与流程改变	购买、安装、空间、配件、折旧与旧设备处置
一致性	不同账号、权限、数据与版本	不同批次、部件、装配与使用环境
交付能力	部署、运维、支持与持续改进	供应链、良率、渠道、库存与售后
使用周期	可以持续改版，用户状态不断累积	设备在外多年，维护承诺跨越多个版本
主要替代	通用工具、人工流程、内部系统、捆绑功能	旧设备、不同形态设备、人工服务、租赁与不购买

这里最容易犯的错误，是用软件思维分析硬件：看到原型可用，就认为产品已经成立；或者用硬件思维分析软件：看到某版功能较少，就认为竞争结论已经固定。

智能硬件还要多做一层交叉检查。它的体验可能依赖 App、云服务、模型和订阅，但物理载体无法像软件一样随时改版。分析既要看硬件生命周期内的软件是否持续可用，也要看软件升级是否会被算力、电池、连接和旧设备所限制。

六、把参数表放回正确的位置

参数表要保留，但生成顺序需要改变。

第一步：先画出当前流程

记录用户从触发需求到完成结果的每一步，包括等待、切换工具、人工补救、失败和放弃。没有流程，就不知道参数在哪一步产生价值。

第二步：按选择逻辑建立竞品集合

每个方案都要说明为什么进入或退出比较：是否重叠了目标用户、触发情境、任务、预算、渠道、流程或风险。不要仅凭外形和品类名称纳入。

第三步：从真实决策推导指标

把指标分为三类：

门槛项：不满足就不会被选择；
差异项：能够明显改变结果或成本；
低敏感项：容易展示，但很少改变选择。

只有观察到的行为或明确决策依据，才适合给出权重。证据不足时，精确到小数点的评分只是在制造确定感。

第四步：把每个主张标成事实、推断或假设

事实来自官方资料、实测、交易、行为观察或可归属访谈；推断是对多个事实的解释；假设则必须进入验证。找不到的数据应标为未知，而不是填入一个看似合理的估算。

第五步：用代表性任务做并行测试

软件要用同一组真实数据、权限和上下游完成整条流程；硬件要在相同环境、时长、动作与维护条件下完成同一任务。测试成功路径，也测试中断、错误和恢复。

第六步：最后才压缩成表格

这时参数表不再是一份资料汇总，而是决策模型的摘要。每一行都能追溯到用户任务，每一个结论都有证据或明确的不确定性。

七、两种产品，应该做两种最小验证

竞品分析最后必须进入可证伪的测试，否则它只是一套漂亮解释。

软件：验证用户是否愿意迁移一条真实流程

选择少量代表用户，把真实数据、权限和协作关系带入产品，连续完成一个高频任务。观察：首次价值时间、独立完成率、人工修正、失败恢复、团队采用，以及用户是否愿意把下一次任务继续交给产品。

如果优势只在演示数据里成立，一接入真实权限就消失；如果个人效率提高，但组织部署成本超过收益；如果试用后仍回到原工具，原有差异化就应被推翻。

硬件：验证用户是否愿意在真实环境里持续使用

使用接近量产状态的设备，在代表性的空间、温度、网络、时长与动作中完成任务。观察：成功率、舒适性、误操作、清洁与维护、故障恢复、他人影响，以及数日或数周后的持续使用。

如果优势依赖实验室条件；如果续航提高却因重量让用户提前摘下；如果功能成立但安装、维修或服务成本无法承受，同样应该停止强化纸面参数。

两种验证都在回答同一件事：用户感知到的结果，是否真的大于完整的切换成本与风险。

结语：参数表应该是结论，不是起点

竞品分析的对象，从来不只是竞争公司的产品，而是用户面前所有能够完成任务的选择。

软件要比较工作流、数据、协作、治理、迁移与持续交付；硬件还要比较物理体验、约束耦合、批量一致性、生产交付、维护与售后。智能硬件则要同时处理两套逻辑，不能只看 App，也不能只看机器。

一份能进入决策的竞品分析，最终应当回答四个问题：

哪类用户在什么情境下会考虑切换；
他今天使用的方案是什么；
新产品在哪个完整任务上产生了可感知、可信的优势；
什么证据会证明这个判断错了。

先回答这四个问题，再打开参数表。