竞争性拆解 是做什么的？
输出是一个决策，而非功能清单。每个差距都会获得一个排名、一个工作量估算，以及一个“构建或忽略”的裁决。
方法
-
研究竞争对手的当前状态 —— 定价、定位、过去6个月发布了什么、他们的用户在抱怨什么。为每一项声明标注日期；大多数类别变化的速度比分析报告的存活时间要快。
-
审计自身代码库中已存在的功能。 这一步会改变答案。反复地，所谓最高价值的“差距”往往是代码库中已存在但未被调用的废弃框架，或者一个随功能标志发布但无人开启的功能。在断定任何功能缺失前，先进行 grep 搜索。
-
以实际用户为过滤条件。 明确指出你的产品服务于谁，并针对那个人来评判每个差距。一个在企业演示中令人印象深刻的功能可能对个人用户毫无价值，反之亦然。指出每个差距服务于谁——如果答案是“我们不卖给的人”，那么这就是裁决。
-
根据用户价值进行排序，附带粗略的工作量估算，并说明为什么该功能开发成本低廉或昂贵。
结构
# <竞品> vs <我们> —— 竞争差距分析 (YYYY-MM-DD)
<一行说明使用的研究模式。>
## 提要
<他们真正的优势是什么——通常不是他们市场营销的那个点。>
## 排序后的差距
1. **<差距>** (~工作量) —— 来自代码库的证据，为什么这对我们的用户重要，以及需要构建什么。
## 明确不值得复制的功能
<明确指出，并附上原因。>
## 战略解读
<持久的经验教训，与功能列表无关。>
“明确不值得复制”部分是必需的
正是这个部分保证了产品待办列表的诚实。没有它，拆解就会变成一份让你感到落后的任务清单。
那些演示效果好但通常对用户无用的功能包括：自定义对象、可视化工作流画布、看板（Kanban）面板、单用户产品上的协作表面，以及针对你不销售的买家的数据丰富。要明确指出它们并附上原因，这样下一次拆解就不会再提出它们。
渠道优于功能
当竞争对手规模更大时，威胁通常在于他们如何触达用户——捆绑销售、默认集成、现有合作关系——而非他们的功能集。要明确考量这一点。只对比功能的拆解会推荐错误的工作。
持续约束
保留一份先前裁决的简短列表，这样拆解就不会重新讨论已经解决的问题：领导层已决定不构建的功能、已被排除的定位主张，以及不在讨论范围内的结构性赌注。随着裁决的做出，将其添加到该列表中。
将它们记录在项目自身的这份技能副本中——关键在于，竞争对手做某事本身并不足以成为推翻先前决定的论据。
对比页面
如果需求包括营销文案，请匹配已存在的内部模板风格，而不是自创体系。对竞争对手的所有事实性声明必须注明日期并有来源——这些页面是公开的，过时的声明是一种风险。
保留为草稿。未经人工明确批准，不得发布对比页面。
输出
将分析写入项目保存研究资料的地方。如果拆解改变了策略，请在相关的决策中枢或计划中添加一个带日期的章节——不要悄无声息地覆盖先前的裁决。