竞品分析只看功能，常见成因有四类：分析目标被简化成“对方有什么功能”，缺少要回答的产品决策问题；功能清单和界面截图最容易获取，用户场景、商业模式与服务生态信息采集成本高；团队模板和评审口径把竞品分析做成功能对照表；时间压力下用功能对比快速交差。判断属于哪一类，要看分析产出是否真正用于定价、路线取舍或目标客户判断。下文按症状自查、原因假设与验证、按成因处置、效果验证与复发预防的顺序展开。
要点总览（TL;DR）
- 竞品分析退化成功能罗列，常见成因有四类：分析目标没绑定决策问题、功能信息易得而场景与商业信息难采、模板与评审只考核功能覆盖、时间压力下快速交差。
- 判断成因不能凭感觉：先看分析产出是否触发了定价、路线取舍或目标客户判断，再看信息来源结构，最后对照模板与评审记录。
- 纠正的主线是先写清本次分析要支持的决策问题与验收标准，再把功能清单降为其中一栏，补充用户场景、替代方案、定价打包与服务生态证据。
- 时间紧时可以做最小可行版本，但要把未覆盖的维度和证据缺口显性写出来，避免被当成完整结论使用。
- 改进是否生效看分析结论有没有被具体决策引用；用交付后复盘、季度模板维护和复发预警信号维持效果。
只看功能的典型表现与影响范围
“只看功能”指竞品分析的产出停留在功能有无与参数高低，没有回答“这对我们的产品决策意味着什么”。它可能出现在整份报告里，也可能只出现在某个章节，程度不同，处置力度也不同。
症状自查清单
逐条对照最近的竞品分析产出，符合三项以上，基本可以判定功能罗列占了主导：
- 报告主体是功能对照表，行是功能项，列是竞品名称，单元格填“有/无/部分支持”。
- 证据以界面截图和参数页为主，缺少用户使用场景、任务流程和替代方案的描述。
- 结论段落写“竞品A功能更全”“我们缺少X功能”，没有说明这对哪类客户、哪个定价档位或哪条路线产生影响。
- 没有记录竞品的定价结构、打包方式、服务承诺和生态合作情况。
- 报告交付后，没有对应的需求取舍、定价调整或目标客户判断被触发或修改。
- 分析范围只覆盖直接竞品的功能，未纳入用户当前用其他方式解决问题的替代方案。
影响哪些产品决策
功能对照表能回答“对方有没有”，难以回答“我们该不该做、为谁做、以什么价格做”。受影响的决策主要有四类：
| 决策类型 | 只看功能时的典型缺口 | 可能后果 |
|---|---|---|
| 路线取舍 | 不清楚功能背后的用户任务与使用频率 | 按竞品功能清单排优先级，资源投向低频功能 |
| 定价与打包 | 缺少竞品定价结构、版本分层与增值服务信息 | 定价缺少参照，打包方式与客户付费意愿脱节 |
| 目标客户判断 | 未区分竞品功能服务的客户类型与场景 | 误判市场空位，进入并不存在的差异化区间 |
| 机会识别 | 未采集用户未被满足的需求与替代方案 | 错过服务、交付、生态层面的机会 |
区分局部与整体程度
局部只看功能，通常表现为报告有场景和商业分析，但某一章节退化为功能清单，例如某个模块的对比。整体只看功能，则是分析目标本身就没定清楚，所有章节围绕功能覆盖度组织，结论也只能落在“补功能”上。前者调整章节结构即可，后者需要回到分析目标重新设计。
成因假设：为什么分析会退化成功能罗列
四类成因是待验证的假设，不能直接当作结论。每类假设都有可观察的证据，排查时按“先看产出被用于什么决策，再看信息采集方式，最后看模板与评审口径”的顺序推进，避免把表象当根因。
原因假设与验证证据对照
| 成因假设 | 可观察证据 | 排查方式 |
|---|---|---|
| 目标假设：分析没有绑定具体决策问题 | 任务说明只写“分析竞品X”，没有写要支持哪个决策；报告结论无法对应到任何待定事项 | 调取分析任务的下达记录，访谈提出分析需求的人，确认当时要回答的问题 |
| 信息成本假设：功能信息易得，场景与商业信息难采 | 报告引用来源集中在官网功能页和截图；访谈、试用记录、定价页、客户案例等来源缺失 | 核对报告的信息来源清单，统计各类来源的采集耗时与可得性 |
| 流程与模板假设：模板和评审只考核功能覆盖 | 模板固定为功能对照表；评审意见集中在“漏了哪个功能”，很少追问场景与商业维度 | 调取最近三次的模板与评审记录，统计评审意见的类型分布 |
| 组织与时间假设：临时交差、单人承担、缺少复盘 | 分析任务由一人短期完成；交付后无复盘；同类分析反复从零开始 | 查看任务排期与人力安排，确认是否有复盘环节和沉淀机制 |
排查顺序与判断依据
第一步看产出与决策的关联。如果分析交付后没有任何决策被触发或修改，目标假设成立的概率最高，此时补维度、改模板都难以解决根本问题。第二步看信息来源结构。如果来源高度集中在功能页，信息成本假设成立，需要评估团队实际能投入的采集资源。第三步对照模板与评审记录。如果评审意见几乎只谈功能覆盖，流程假设成立。第四步看人力与节奏。临时交差、单人承担往往与前几类成因叠加出现，单独存在时表现为“知道该做但没时间做”。
排查时注意区分相关与因果。例如“模板是功能对照表”与“分析只看功能”同时出现，不代表模板是唯一原因；需要确认换成更完整的模板后，分析是否真的改善。可以用一次小范围试点来验证：选一个明确的决策问题，按扩展后的维度做一次分析，观察产出是否被采用。
按成因处置：把功能对比扩展为决策支撑
处置动作对应已确认的成因，不必全部同时上。先处理目标假设，再补信息维度，最后调整模板与评审口径，顺序颠倒容易做成形式上的完整报告。
先写清决策问题与验收标准
在采集任何竞品信息之前，用一段话写明本次分析要支持的决策，例如“为下季度是否推出面向中小团队的低价版本提供依据”。同时写验收标准：结论需要回答哪几个问题、由谁使用、在哪个会议上讨论。验收标准可以写成三条以内，例如目标客户是谁、竞品在该客户群的价格带、我们进入需要补齐的能力。没有明确决策问题的分析任务，先退回需求方澄清，再启动采集。
补充场景、替代方案与商业维度取证
功能清单保留为其中一栏，其余维度按以下方式取证：
- 用户场景：通过客户访谈、销售记录、公开评测和社区讨论，还原竞品功能被用在什么任务里、频率如何。
- 替代方案：列出用户当前不用该类产品时的做法，包括手工流程、通用工具组合和外包服务，判断竞品的真实竞争对象。
- 定价与打包：采集公开定价页、销售报价区间和版本分层，标注信息获取时间与可信度。
- 服务与生态：整理实施服务、培训、集成伙伴和开放能力，判断竞品靠什么留住客户。
取证时标注来源类型与可信度：公开信息、客户访谈、销售反馈、个人推测分开记录，推测不写成事实。涉及客户访谈和销售数据的部分，遵守公司数据使用规范，不对外披露可识别客户的信息。
调整模板与评审口径
把模板从单一功能对照表改为分栏结构：决策问题、目标客户与场景、功能对比、定价与打包、服务与生态、结论与建议。功能对比降为其中一栏，篇幅占比控制在三分之一以内。评审清单增加三类问题：结论对应哪个决策、证据来源是否标注、有哪些信息缺口。评审时对“漏了某个功能”的意见降级处理，优先追问结论是否可执行。
时间紧时的最小可行做法
时间压力真实存在时，可以只做最小版本，但要标注证据缺口：选定一个决策问题，功能对比只覆盖与该决策相关的功能项；用两到三次客户访谈或销售反馈补充场景信息；定价信息从公开页面采集并注明时间；结论部分明确写出“本分析未覆盖服务与生态维度，相关判断需补充取证”。最小版本的价值在于让决策有场景依据，同时把缺口显性化，避免被当成完整结论使用。
验证改进效果与防止复发
改进是否生效，不看报告页数或维度数量，看分析结论是否被用于具体决策。验证与防复发需要固定节点和责任人，否则一两个项目之后容易退回功能罗列。
验证信号
- 分析结论在路线评审、定价讨论或目标客户判断中被引用，并留下了采纳或否决的记录。
- 决策记录中能追溯到具体的竞品证据，而不是笼统的“参考竞品”。
- 报告中标注的信息缺口在后续被补充，或明确说明不影响本次决策。
- 需求方在下次提出分析任务时，主动写明要支持的决策问题。
复盘节点与责任人
在分析交付后的第一次相关决策会议结束时，安排十分钟复盘：结论是否被使用、哪些证据起了作用、哪些维度缺失。复盘由分析任务的提出方主持，分析执行人记录。每季度汇总一次，统计分析产出被引用的比例和常见缺口类型，作为下一季度模板调整的依据。
模板与知识沉淀的维护
指定一名模板维护人，负责收集复盘中的缺口类型，每季度更新一次模板栏目和评审清单。把验证有效的分析样例归档为参考案例，标注当时的决策问题和证据结构，供后续任务复用。沉淀的重点是决策问题与分析结构的对应关系，功能清单只是其中一部分。
复发预警信号
出现以下信号时，说明分析可能正在退回功能罗列：新任务说明只写竞品名称不写决策问题；模板被简化回功能对照表；评审意见重新集中在功能覆盖度；连续两次分析交付后没有决策被触发；分析执行人长期单人承担且无复盘。发现预警后，回到成因排查的第一步，确认是目标缺失还是时间压力导致，再决定处置力度。
竞品分析的需求、结论和决策记录需要在任务与文档之间流转时，可以用ONES把分析任务建成工作项，关联对应的需求或路线议题，把结论文档与决策记录放在同一处，复盘时直接追溯哪次分析支撑了哪个决策。这样做的条件是团队已经在ONES中管理需求与迭代；分析结论本身的质量仍取决于决策问题是否写清、证据是否标注来源。
常见问题
团队规模小、没有专职竞品分析人员，怎么避免分析退回功能罗列？
小团队的关键是把分析任务和具体决策绑定，而不是追求报告维度齐全。可以由提出分析需求的人先写清要支持的决策问题，例如是否调整某个版本的功能范围或价格档位，执行人只围绕这个问题取证。功能对照表保留，但只覆盖与该决策相关的功能项，其余维度用两到三次客户访谈或销售反馈补充场景信息。交付时明确写出未覆盖的维度和证据缺口，让结论在限定范围内使用。
分析结论在评审会上没有被采用，是否说明这次竞品分析失败了？
不一定。结论被否决也是决策被触发的信号，前提是评审中留下了否决理由和依据。真正需要警惕的是分析交付后没有任何讨论、没有任何决策被引用。复盘时可以区分两种情况：结论方向对但证据不足，需要补充取证；结论与决策问题不匹配，说明分析目标没写清。把否决理由记录下来，下一轮分析的目标和证据结构会更准确。
公开渠道拿不到竞品的定价和服务信息，分析还能做吗？
可以做，但要标注信息缺口和可信度。定价信息可以从公开定价页、销售报价区间和客户反馈中拼出大致区间，注明采集时间；服务与生态信息可以从官网文档、合作伙伴页面和客户访谈中获取。拿不到的部分在结论中写明“该维度未覆盖，相关判断需补充取证”，不要把推测写成事实。涉及客户访谈和销售数据时，遵守公司数据使用规范，不对外披露可识别客户的信息。
把功能清单降为其中一栏后，报告篇幅变长，评审时间不够怎么办？
可以按决策相关性裁剪，而不是按维度平均分配篇幅。评审材料先给一页结论页：本次要回答的决策问题、核心结论、关键证据和主要缺口，详细维度放在附录。评审会上优先讨论结论是否可执行、证据是否支撑，功能覆盖度的意见降级处理。这样既保留了场景与商业维度的分析，也控制了评审时长。
怎么判断改进已经稳定，而不是靠一两次项目碰巧做对了？
看三个持续信号：新任务说明中是否主动写明决策问题；评审意见中场景与商业维度的讨论是否成为常态；分析结论在决策记录中是否可追溯。再配合每季度一次的汇总复盘，统计被引用的分析比例和常见缺口类型。如果连续两个季度模板没有被简化回功能对照表、评审意见没有重新集中在功能覆盖度上，可以认为改进基本稳定。
