第7章 02：竞争对手不需要更好的产品——只需要你脚下的开关#

你的竞争对手不需要更好的营销、更好的定价或更好的团队。他们只需要拥有你的业务所依赖的那个东西——然后把它抽走。

这是大多数创始人永远看不到的致命一击。他们把时间花在研究卖类似产品的竞争对手上，为一场可能永远不会发生的正面交锋做准备。而真正的威胁安静地坐在下面：你整个业务所依赖的平台、API、分销渠道、数据源。当那个地基移动时，大楼不是倾斜——是坍塌。

失去脚下土地的三种方式#

这个模式在不同行业和时代重复出现，遵循三种不同的剧本。

切断连接。 你在别人的API上构建产品。你从他们的系统拉数据，或者通过他们的平台分发。某天他们改变条款——速率限制、定价、审批要求——或者完全撤销访问权限。你的产品理论上还能用。但没有数据可处理，没有用户可触达，没有管道可流通。水管关了。你干了。

这不是假设。Twitter 2023年的API定价变更一夜之间杀死了数百个分析和机器人工具。应用商店算法更新在一个周期内蒸发了卖家的自然流量。平台并不是针对他们。只是为自身利益优化，而他们的利益不在考量范围内。

复制功能。 你构建了一个成功的工具，扩展了平台的功能。平台注意到你的增长，然后原生构建了相同功能。他们不需要做得更好——只需要做出来就行。他们的版本是集成的、免费的、默认的；你的是外部的、付费的、可选的。用户不是因为竞争对手更优秀而切换，而是因为替代品就在他们每天使用的产品里面，切换成本降到了零。

这就是"平台吸收"模式。平台让百花齐放，观察哪些吸引了蜜蜂，然后在你旁边种上自己的版本——只不过他们的花自动获得阳光和水。你做了概念验证，他们做了最终产品。

改变规则。 你在一套使你的业务可行的法规、标准或市场规范下运营。一个更大的玩家——通常有游说能力或市场影响力——推动改变这些规则，使其有利于他们的模式而不利于你。新的合规要求吃掉你30%的收入。新的行业标准恰好匹配他们的技术架构。新的法规在你必须通过的地方设置壁垒。

规则变更是最难防御的，因为它们看起来合理合法。没有人违反合同，没有人违反条款。游戏只是变了——恰好变向有利于对游戏设计影响力最大的那个玩家。

依赖审计#

如果这些威胁是结构性的，应对也必须是结构性的。你需要一个系统化的方法来识别、评估和缓解依赖关系，在它们变得致命之前。

第一步：列出每一个外部依赖。 遍历你的整个运营——产品、分销、数据、基础设施、支付、合规——列出每一个你依赖第三方的点。要穷举。包括明显的（云托管、支付处理器）和不明显的（产品构建所依赖的开源库、客户要求的行业认证）。

第二步：评估替换成本。 对每个依赖，估算替换所需的时间、金钱和精力。有些很简单：换支付处理器几天就行。有些几乎不可能：从一个你已经搭建了两年定制基础设施的云平台迁移，可能需要六个月，成本超过年收入。

第三步：标记致命依赖。 一个依赖是致命的，如果：替换成本高（30天以上或20%以上的资金跑道）且不存在可行替代方案。这些就是你的生死开关。别人握着它们。

第四步：评估触发概率。 并非所有致命依赖同样危险。云服务商关闭你的账户——如果你在付费，可能性不大。平台因为要推出竞品而撤销你的API访问——这有充分的先例记录。把缓解精力集中在触发概率中高的致命依赖上。

降低致命依赖的四种策略#

识别出你的生死开关后，有四个选项。没有一个是免费的。但都比死掉便宜。

自建。 用内部能力替代外部依赖。最贵，最安全。如果你的业务依赖特定数据源，能自建数据采集机制吗？如果依赖分发平台，能建直接客户渠道吗？成本高，但结果是结构性独立。

陷阱：试图什么都自己建。你做不到。目标不是零依赖——是零致命依赖。只对可能杀死你的那些自建。

多元化来源。 不要依赖一个平台、一个供应商、一个渠道——分散到多个。如果一个切断你，其他的让你活着。依赖管理的组合策略。

关键指标是集中度。如果任何关键输入（流量、收入、数据、分发）超过50%来自单一来源，你就是集中的。单一来源低于30%是合理目标。

绕道。 重新设计商业模式，彻底消除依赖。不是替换供应商——是移除这个步骤。能否改变模式使脆弱环节不再必要？绕过分销商直达客户？用不需要相同基础设施的不同技术？

这是最有创造力的选项，往往也是最强大的。它迫使你从第一性原理重新思考架构。

结盟。 如果无法自建、多元化或绕道，与共享相同依赖的其他企业组建联盟。集体谈判力强于个体。平台提供者不太可能切断代表其生态系统15%的群体，而不是一个占0.1%的小玩家。

联盟脆弱且缓慢。但面对垄断平台，有时是唯一可行的选择。

依赖思维的陷阱#

合同的虚假安全感。 三年合同不能保护你免受续约时的涨价、功能弃用导致的价值侵蚀、或者供应商质量的持续下降。合同是法律文件，不是战略保障。

渐进主义陷阱。 依赖是逐步增长的。一个API集成。然后第二个。然后依赖平台特定能力的定制功能。每一步看起来都很小。累积效应是深度依赖——像爬进墙里的藤蔓，容易种下，几乎不可能拔除。

该担心依赖的时候是做架构决策时，不是它变成危机时。每一个增加对单一外部实体依赖的决策都应该触发：“如果这个消失了会怎样？”

“他们也需要我们"的幻觉。 创始人经常用关系是互利的来合理化依赖——“我们给他们平台带去流量，所以他们不会切断我们。“几乎总是错的。平台和单个应用之间的不对称是巨大的。他们损失一个四舍五入的误差。你失去一切。在结构性不对称的关系中，永远不要假设对称。

30天测试#

以下是应该让你失眠的练习。

拿出你的依赖清单。对每一个，回答一个问题：如果这个依赖明天消失——完全消失，没有预警——你的业务还能运转多少天？

要诚实。不是"多少天找到变通方案”——是"多少天后业务停止运转”。没有收入，没有产品，没有服务。

少于30天的依赖是结构性脆弱点。少于7天是紧急情况。零天——业务瞬间停止——是定时炸弹。

你有多少颗定时炸弹？

大多数第一次做这个练习的创始人发现数量超出预期。这就是目的。这个练习不是为了让你安心，是为了让你准确。

你无法消除所有依赖。每个企业都依赖电力、互联网、法律体系。但你可以识别出那些既致命又可控的——有人握着能关闭你的开关，而你有现实的选择来降低暴露。

存活下来的创始人不是没有依赖的那些。而是清楚知道依赖在哪里、每一个有多危险、以及当——不是如果——其中一个出问题时该怎么做的那些。