编写竞品分析报告，先锁定一个具体的产品决策问题，再据此确定竞品名单和对比维度，按统一字段收集公开信息并标注来源与日期，整理成同口径对照表，提炼差异与机会，最后给出带条件的结论和下一步动作，经评审后归档并定期更新。报告的价值在于支撑决策，篇幅和竞品数量都服从这个目标。下文按立项、选竞品定维度、取证、成文、分工、示例、核对七个环节展开。
要点总览（TL;DR）
- 先锁定一个具体的产品决策问题，再据此确定竞品名单和对比维度，避免写成信息齐全但无法支撑决定的文档。
- 竞品按直接、间接、潜在替代方案分层筛选，对比维度从决策问题反推，区分事实项与判断项并明确取证方式。
- 每个字段记录来源链接、获取日期、原文摘录和信息类型，信息缺口标注未获取，不推断为不支持。
- 报告采用结论先行结构，摘要给出核心发现与建议，对比表同口径呈现，结论写明适用条件与不确定性。
- 定稿前按清单核对决策问题是否被回答、事实是否可追溯、建议是否可执行，并约定更新周期与责任人。
先定决策问题：报告写给谁、要回答什么
竞品分析报告最常见的失败，是从“看看竞品在做什么”开始，最后写出一份信息齐全但无法支撑任何决定的文档。启动前先把这句话转成一个可回答的问题，例如“下个版本是否要增加批量导入功能”“新套餐的定价区间定在什么范围”“某细分场景我们是否还有进入机会”。决策问题越具体，后面的竞品筛选和维度设计越省力。
决策问题确定后，接着明确三件事。读者是谁，决定报告的详略和术语密度：给产品负责人看，可以聚焦功能差异和实现成本；给规划团队看，需要更完整的能力对照；给管理层看，结论和建议要前置，证据放附录。决策时点是什么，决定交付时间，也决定信息收集的截止日期。结论要支撑什么动作，决定报告写到什么程度算完成——是支持一次评审会，还是作为季度规划输入。
范围同样要在立项时写清楚：覆盖哪条产品线、哪个市场区域、哪个时间窗口。范围写得含糊，收集阶段就会不断扩张，最后既写不完也写不深。建议把以下字段填成一页立项说明，作为后续所有工作的基准。
| 立项字段 | 填写要求 | 示例（演示情景） |
|---|---|---|
| 决策问题 | 一句话，可回答，指向一个具体决定 | 下个版本是否投入批量导入功能 |
| 读者与使用场景 | 角色、决策会议、使用方式 | 产品负责人，版本规划评审会 |
| 产品线与市场区域 | 明确边界，避免收集中扩张 | 国内中小企业协同工具 |
| 时间窗口 | 信息截止日期与覆盖时段 | 信息截至本季度末，覆盖近12个月动向 |
| 竞品数量上限 | 按决策需要设定，通常3–6家 | 直接竞品3家，间接竞品1家 |
| 交付时间 | 初稿与评审的时间点 | 两周内出初稿，第三周评审 |
| 结论用途 | 支撑哪个动作，写到什么程度 | 支撑版本范围决策，需给出建议与验证方式 |
这一页立项说明也是后续评审的对照物：报告写完时，逐条回看是否回答了当初的问题、是否在设定范围内。立项说明本身需要有人确认，通常由报告负责人起草、决策使用人确认，避免写完才发现方向不对。
选竞品与定维度：名单和对比口径怎么定
竞品名单从决策问题反推，而不是把市场上听说过的产品都列一遍。先按与目标用户、核心场景的重叠程度分三层：直接竞品解决同一类问题、面向相近用户；间接竞品用不同方式满足相近需求；潜在替代方案包括用户当前的自建方案、通用工具组合或手工流程。每层选几家的判断依据是决策需要——如果决策问题是功能取舍，直接竞品是重点，间接竞品取一两家看替代路径即可；如果决策问题是市场机会，间接竞品和替代方案的权重需要提高。
筛选时可以用三个可判断的标准：目标用户重叠度、核心场景重叠度、市场可见度。前两个决定这家竞品是否值得对比，第三个决定它在用户认知中的位置。三个标准都高的进入核心名单，只有一两个高的放入观察名单，在报告中简要说明即可。名单确定后写进立项说明的竞品数量上限内，中途新增需要说明理由。
对比维度从决策问题反推。决策问题是“要不要做批量导入”，维度就应围绕导入能力展开：支持的数据格式、单次导入量、字段映射方式、错误处理、权限控制、公开价格档位。照搬通用模板（公司背景、融资情况、功能列表）会写出一堆与决策无关的内容。设计维度时把握两点：一是可观察、可取证，能从公开资料中找到依据；二是区分事实项与判断项，事实项如“是否提供开放接口”，判断项如“易用性评价”，后者需要说明判断依据。
| 维度类型 | 写法示例 | 取证方式 |
|---|---|---|
| 事实项 | 支持的数据格式、单次导入上限、价格档位 | 官网功能页、帮助中心文档、公开价格页 |
| 事实项 | 近12个月公开发布的主要更新 | 官方更新日志、应用商店版本记录 |
| 判断项 | 导入流程的步骤数与操作复杂度 | 公开文档描述的操作步骤，逐条计数 |
| 判断项 | 用户对导入功能的集中反馈 | 公开评测、应用商店评论，注明样本范围 |
同时明确不纳入的范围，例如营销投放策略与投放效果评估、渠道政策分析。这些内容与本次决策问题无关，写进去只会稀释重点。范围一旦确定，收集阶段遇到相关但超范围的信息，记入附录备查即可，不展开分析。
信息收集：每个字段怎么取证、怎么标注
收集阶段的目标是让报告里每一个关键事实都能被追溯。可用的公开来源包括：官网的产品与功能页面、公开的帮助中心和技术文档、应用商店的产品信息与版本记录、公开价格页、公开评测文章与用户反馈。来源类型不同，可信度不同，记录时要分开标注。
每个字段按统一格式记录四项内容：来源链接、获取日期、原文摘录、信息类型。原文摘录保留厂商的原始表述，便于后续核对；信息类型分为“已确认事实”“用户说法”“推测”三类。已确认事实指官方公开资料明确写出的内容；用户说法指来自评测或评论的主观反馈，需注明样本范围；推测指根据间接信息做出的判断，必须写明推测依据，并在成文时保留标注。
信息缺口是常态。某家竞品没有公开某项能力的信息时，标注“未获取公开信息”，不要写成“不支持”。厂商宣传语也不能直接当作能力结论，例如“高效处理海量数据”需要落到具体的公开参数或文档描述上，找不到就归入未获取。收集表建议按“竞品×维度”组织，每格填来源与日期，空缺格用统一标记，成文时一目了然。
收集工作通常由多人分担，按竞品或按维度分工都可以，但字段定义必须提前统一，否则合并时口径不一致。收集表本身是过程交付物，评审时需要能随时调出原始来源核对。
成文结构：报告各章节写什么
报告正文建议采用“结论先行”的结构，让读者在前两页就能拿到判断，证据放在后面。各章节的写作要点如下。
摘要与结论。用半页到一页回答立项时的决策问题，给出核心发现和倾向性建议，并注明结论的置信程度。这一节最后写，但放在最前面。
对比表。把收集表整理成同口径的对照表，行是维度，列是竞品，单元格填事实与来源日期。缺失项统一标注，不用空白代替。表格控制在关键维度上，完整数据放附录。
逐家分析。每家竞品写清定位、目标用户、核心能力、商业模式、近期动向五个方面，篇幅服从决策相关性——与决策问题直接相关的竞品写详细，观察名单中的竞品简要带过。
差异与机会。从对照表中提炼两类内容：空白点，即用户需求存在但竞品覆盖不足的地方；威胁点，即竞品已形成明显优势、我方短期难以追平的地方。每一条都要指向表中的具体事实。
结论与建议。建议写成带条件的行动：在什么前提下建议做什么，依据是哪几条事实，还有哪些不确定性需要验证。避免“建议加强投入”这类无法执行的说法。
附录。放来源清单、字段说明、术语表，以及超范围但值得备查的信息。
报告从立项、分工收集、成文到评审归档，涉及多人多轮的任务与文档流转。在ONES中可以把立项说明、收集表、报告初稿作为工作项或文档管理，评审意见与修改记录留在同一处，后续按约定周期更新时能直接找到上一版依据。这一衔接的作用是让报告的过程可追溯，具体配置按团队现有流程安排。
角色分工与交付物：谁写、谁审、谁用
一份能支撑决策的报告通常需要四类角色，小团队可以一人兼多职，但职责要分清。报告负责人对整体质量和进度负责；信息收集人按分配的范围取证并填写收集表；领域评审人通常是熟悉该产品线或该市场的同事，负责核对事实与判断是否站得住；决策使用人是报告的服务对象，在立项时确认问题、在评审时确认结论可用。
| 阶段 | 主要动作 | 参与角色 | 交付物与完成标志 |
|---|---|---|---|
| 立项 | 确定决策问题、读者、范围、数量上限、交付时间 | 报告负责人起草，决策使用人确认 | 一页立项说明，双方确认即完成 |
| 收集 | 按维度分工取证，统一字段填写 | 信息收集人，报告负责人抽查 | 信息收集表，关键字段无空缺或已标注未获取 |
| 成文 | 整理对照表，撰写各章节，结论先行 | 报告负责人主笔，收集人补充 | 报告初稿，对照表与正文一致 |
| 评审 | 核对来源、检查结论是否超出证据、确认建议可执行 | 领域评审人、决策使用人 | 评审记录与修改清单，问题关闭后定稿 |
评审关注四点：来源是否可追溯，每条关键事实能否找到链接和日期；结论是否超出证据，推测是否被写成了确定结论；建议是否可执行，有没有动作、负责人和验证方式；范围是否守住，有没有把超范围内容写成重点。评审意见逐条记录并标注处理结果，未采纳的意见也要写明理由。
示例：一份功能规划类竞品分析报告的片段
以下片段为演示情景，用于说明事实、判断与建议如何分层表达，实际编写时替换为真实收集数据。
决策问题：下个版本是否投入批量导入功能。竞品名单：直接竞品A、B、C，间接竞品D。
| 维度 | 竞品A | 竞品B | 竞品C | 来源与日期 |
|---|---|---|---|---|
| 支持的数据格式 | 表格文件与文本文件 | 表格文件 | 未获取公开信息 | 各官网功能页，本季度初 |
| 单次导入上限 | 公开文档写明上限值 | 未获取公开信息 | 公开文档写明上限值 | 帮助中心文档，本季度初 |
| 字段映射方式 | 手动映射 | 模板预置 | 手动映射 | 帮助中心文档，本季度初 |
| 错误处理 | 逐行报错 | 整批回滚 | 逐行报错 | 公开文档，本季度初 |
结论段写法示例：判断——批量导入已成为直接竞品的普遍能力，我方缺失会在大客户场景形成明显短板。支撑事实——三家直接竞品中两家有公开文档说明导入能力，字段映射与错误处理方式各有差异，说明用户对导入过程的可控性有实际要求。适用条件与不确定性——该判断基于公开资料，竞品C的导入能力未获取公开信息，需在决策前通过其他渠道补充确认；间接竞品D以接口方式满足同类需求，是否构成替代取决于我方客户的技术能力。
建议段写法示例：动作——下个版本纳入批量导入，首期支持表格文件与逐行报错；负责人——产品负责人牵头，研发评估工作量；验证方式——上线后观察大客户场景的导入使用率与报错率，一个版本周期后复盘是否扩展格式支持。建议附带的依据指向对照表中的具体行，评审时可直接核对。
完成检查：报告交付前的核对清单
定稿前逐项核对以下条目，每一条都应能给出明确的是或否，而不是“基本做到”。
- 决策问题在摘要与结论中被明确回答，读者读完前两页能知道建议是什么。
- 每个关键事实都有来源链接与获取日期，抽查任意三条能当场找到原文。
- 对比表同口径呈现，缺失项统一标注为未获取，没有用空白或推测填充。
- 结论区分了事实、用户说法与推测，推测保留了标注和依据。
- 结论写明了适用条件与不确定性，没有把单家竞品的情况推广为普遍结论。
- 建议落到具体动作、负责人和验证方式，能直接进入下一步工作安排。
- 报告范围与立项说明一致，超范围内容只出现在附录。
- 评审意见已逐条处理并记录，未采纳的意见写明了理由。
- 已约定更新周期与责任人，明确下次复核的时间点和触发条件（如竞品重大更新、决策复盘）。
清单全部通过，报告即可归档并交付使用。归档时把立项说明、收集表、初稿、评审记录一并保存，下一次更新从上一版的事实与来源出发，补充新信息、修正过时判断，比从零重写更省力，也更容易看出竞品格局的变化轨迹。
常见问题
竞品分析报告写多长、选几家竞品比较合适？
篇幅和竞品数量服从决策需要，没有统一标准。立项时先设定竞品数量上限，通常直接竞品3家左右、间接竞品1–2家，足以支撑一个具体的功能取舍或定价判断。报告正文控制在能回答决策问题的范围内，完整数据放附录。如果收集过程中发现某家竞品与决策问题关联很弱，放入观察名单简要说明即可，不必展开分析。
公开资料找不到某家竞品的某项能力信息，报告里该怎么写？
标注“未获取公开信息”，不要写成“不支持”或“暂无该能力”。信息缺口是常态，评审时需要能区分“确认没有”和“没有查到”。如果该能力对决策很关键，可以在报告中列为待补充确认项，说明计划通过什么渠道补充，例如试用、客户访谈或公开文档的进一步检索。
报告写完由谁评审、评审重点看什么？
通常由熟悉该产品线或市场的领域评审人核对事实与判断，决策使用人确认结论是否可用。评审重点包括：关键事实是否有来源链接和获取日期；结论是否超出证据，推测是否被写成确定结论；建议是否落到具体动作、负责人和验证方式；范围是否与立项说明一致。评审意见逐条记录并标注处理结果，未采纳的意见写明理由。
竞品分析报告需要多久更新一次？
更新周期按决策节奏和竞品变化速度约定，常见做法是季度或半年复核一次，同时设定触发条件，例如竞品重大版本发布、定价调整或自身决策复盘。归档时把立项说明、收集表、初稿和评审记录一并保存，下次更新从上一版的事实与来源出发，补充新信息、修正过时判断，比从零重写更省力。
小团队人手有限，能不能一个人写完整个报告？
可以一人兼多职，但立项确认和评审两个环节建议保留他人参与。立项时由决策使用人确认问题和范围，避免写完才发现方向不对；评审时至少找一位熟悉该领域的同事核对事实与结论。收集阶段如果只有一人，字段定义仍要提前统一，避免后续补充信息时口径不一致。
