Q2.17.2Competitive analysis as convention mapping设计研究
竞品分析发现的是行业惯例而非用户需求
别名: 行业惯例 · 竞品清单 · 惯例误当作需求
概念解释
竞品分析（competitive analysis）系统对照其他产品在功能、流程、信息结构和视觉上的做法，产出的是行业惯例地图：这一类产品通常把设置放在哪里、结账有几步、默认开哪些权限。惯例是市场当前的解法分布，不是用户需求的观察。三家都做了某入口，只说明该入口已成为品类标配，不说明目标用户需要它，也不说明没有它会失败。把“竞品都有”写成需求来源，是把供给侧描述误当成需求侧证据。
机制
产品互相可见，设计团队、组件库和评审清单会把已存在的模块当成必须项。频率因此在供给侧自我增强：出现得多的被抄得更多，空白处显得像疏漏。用户需求的证据来自目标、障碍和替代行为，这些不会自动出现在别人的界面截图里。截图还能被成功案例偏置——活着的产品被拿来分析，已撤下的失败方案不在样本里，于是惯例显得比实际更“经过市场检验”。分析越完整，越容易产生“我们已经知道用户要什么”的错觉，因为空白被填成了功能表。
怎么研究
把竞品编码得到的“常见做法”清单与独立收集的用户目标、失败事件对照，计算重合、竞品有而用户未表现、用户有而竞品皆无三类。重合不能解释为互相验证，需要第三种材料（行为、工单、现场）才能升级。追踪某惯例进入需求文档的引用链：若溯源止于“竞品截图”，将其标为惯例而非需求。也可以比较新进入市场的产品与长尾产品，看惯例是否只是头部玩家的共同包装。
边界
采购决策、渠道准入和合规检查会把某些惯例变成真实约束，这时“竞品都有”是市场条件，仍不是终端用户需求，但可以作为必须满足的外部规格。全新品类几乎没有可对照的惯例，分析会空洞，应改去相邻任务。内部竞品（旧版、兄弟业务）反映的是组织惯性，与外部品类惯例不同，应分开编码。
怎么落地
- 竞品表增加一列“证据类型”，默认填“惯例”；只有另有用户证据时才改成需求。
- 评审中禁止把“三家都有”当作立项理由；要求补上没有该做法时用户会如何失败。
- 输出两份清单：建议对齐的惯例、需要用研究确认或否定的惯例，避免混进同一张需求表。
- 抽查需求文档中的竞品引用：溯源不到用户观察的条目降级为待验证假设。