做海外 SaaS 增长时，我们会不会有一种“经验惯性”？
最近我在做一些海外 Growth 的事情，同时也在看 SaaS、API、MCP 和 developer tools。
然后我突然想到一个问题：
我们做海外增长的时候，会不会很容易把自己熟悉的增长逻辑直接搬过去？
以前我对增长的理解，很自然会想到内容、社交媒体、SEO、投放、KOL、社群、平台算法。
这些当然都没有问题。
但最近看了越来越多 SaaS 之后，我突然发现，有一类东西我们经常会把它理解成“产品功能”，而不是 Growth：
API、Integration、Plugin、Marketplace、Webhook、SDK。
比如一个 SaaS 接入 Slack。
最直接的理解当然是：方便用户使用。
但换一个角度来看，它其实也意味着，这个产品进入了 Slack 用户原本的工作流。
如果一个产品做了 Shopify App，它就进入了 Shopify 的生态。
如果接入 Zapier、Make、n8n，它就开始出现在那些原本就在寻找自动化解决方案的用户面前。
如果提供 API，甚至可能会有开发者基于这个产品构建新的使用场景。
所以我最近开始想：
Integration 本身，会不会也是一种 Distribution？
我和 GPT 聊这件事情的时候，我们聊到了一个挺有意思的区别。
中国互联网过去很多增长经验，都是在研究如何从一个大平台里获得流量。
比如研究算法、内容、账号运营、达人、投流、私域。
但很多 SaaS 的增长，好像还有另外一套逻辑：
不是只想着“用户在哪里，我去那里宣传”。
而是思考：
用户已经在使用哪些软件？
我的产品能不能直接进入他们现有的 workflow？
这两个思路其实差别挺大的。
一个是在外面寻找流量。
另一个是在想办法让自己的产品成为别人软件生态中的一个节点。
这也让我开始思考一个问题：
国内产品做海外市场时，会不会存在一种“增长经验惯性”？
我们会很自然地想到做账号、发内容、追热点、找 KOL、投广告、研究平台算法。
但如果做的是 SaaS、AI Tool、DevTool 或 B2B 产品，也许有时候新增一个关键 Integration，比连续发一个月社交媒体内容更接近真实增长。
举个简单的例子。
假设做的是一个 AI Marketing Tool。
一种 Growth 做法，是不断在 X、LinkedIn、Reddit 上发布内容，希望 HubSpot 用户看到你。
另一种做法，是直接完成 HubSpot Integration，然后做一个很具体的使用场景：
“如何使用 AI 自动处理 HubSpot Leads”
围绕这个 Integration，可以继续做 Demo、Landing Page、SEO 内容、教程，甚至进入相关 Marketplace。
这时候 Product、Content、SEO 和 Distribution，其实已经连在了一起。
增长不再只是“产品做好以后，再想办法给它找流量”。
产品本身也可以成为增长的一部分。
甚至我觉得，自媒体内容的逻辑也可能因此发生变化。
现在很多 SaaS 官方账号都会发布类似这样的内容：
5 Tips for XXX
AI is changing XXX
3 Ways to Grow Your Business
这些内容当然可以获得曝光。
但如果面对的是 Developer、Founder、SaaS 团队或者技术型用户，也许另一类内容反而更有价值：
我们为什么开放这个 API。
我们为什么接入某个平台。
如何通过我们的 API 搭一个真实 workflow。
如何和 Zapier、n8n、MCP 配合使用。
某个用户是怎么把我们的产品接进自己现有 software stack 的。
这种内容的流量不一定最大，但它离真实的产品使用场景可能更近。
于是可能出现一种增长循环：
新增 Integration
产生新的 Use Case
制作 Demo
发布教程和内容
创建 SEO Landing Page
进入 Marketplace 或 Developer Ecosystem
获得新的开发者和用户
新的用户又产生新的 Use Case 和 Integration 需求
如果这个循环成立，那么 Integration 本身就不仅仅是 Product Feature，也可能成为 Growth Engine 的一部分。
MCP 的出现又让我觉得这件事情更值得关注。
过去 API 主要是给程序员使用。
但 Agent 出现以后，软件的使用者可能不再只有“人”。
未来一个用户可能不会每天打开十几个 SaaS。
他可能只是告诉 Agent：
帮我查看今天新增的客户，把高意向客户整理出来，然后同步到 CRM。
Agent 再去调用 CRM、Email、Analytics、Search、Database 等不同的软件。
如果这个方向成立，那么一个 SaaS 未来可能同时需要考虑两个入口：
给人的 UI。
以及给机器、Agent 和其他软件使用的接口。
当然，我觉得这里也不能走到另一个极端。
不是所有产品都应该做 API，也不是所有 SaaS 都应该为了赶热点去做 MCP。
如果一个产品本身就是一个非常完整、独立的消费体验，那么 Integration 可能根本没有那么重要。
真正值得判断的是：
我的用户是不是天然存在于一个由多个软件组成的 workflow 里？
如果答案是 Yes，那么 API、Webhook、Integration、Developer Docs、Marketplace，可能就不只是技术部门的事情。
它们可能本身就是 GTM 和 Growth 的一部分。
所以我现在比较好奇的是：
对于做 SaaS、AI Tool、DevTool 或 B2B 产品的人来说，你们会把 Integration 当成 Product，还是也会把它看作一种 Growth？
如果一个国内 SaaS 产品开始做美国、欧洲或者更广泛的全球市场，除了英语、Pricing、Payment、SEO、社交媒体和投放之外，是不是也应该更早考虑 API、Integration、Marketplace 和 Developer Ecosystem？
甚至在内容策略上，也不只是强调“我们有什么功能”，而是更多强调：
我们的产品怎么和你已经在使用的软件一起工作？
我现在还没有特别确定的答案。
但最近越来越觉得，很多 SaaS 的增长可能不只是去流量更多的地方宣传自己。
还有另外一种方式：
让自己成为别人生态里一个更容易被发现、更容易被接入、也更容易被使用的节点。
这件事情是不是值得国内 SaaS 团队在做海外市场时更早考虑，我还挺想听听真正做过相关产品的人怎么看。
最近在做一个「像 Tinder 一样刷互联网产品」的 C 端产品。
一开始我们以为最难的是推荐：怎么知道用户会喜欢什么产品？
后来发现，更基础的问题反而更麻烦——一个网站，怎么被另一个网站正常地展示出来？
我们原本希望用户不需要跳出去，直接在产品里预览和体验网站。但真正跑了一批产品之后才发现，iframe、CSP、X-Frame-Options、登录状态、反爬策略……几乎每个网站都有自己的脾气。
有意思的是，这最后并没有变成一个纯技术问题。
它变成了一个产品问题：
你究竟应该花更多工程成本维持“理想体验”，还是接受互联网本身并不统一，然后设计一个足够优雅的 fallback？
我们最后开始认真考虑截图、引导跳转和多种预览状态。
做产品挺有意思的一点就在这里。
很多时候，你以为自己在设计一个 feature，最后发现你其实在和整个互联网的基础设施谈判😂
过审了欸 但因为可惜没法到现场了哈哈哈
违禁词: tunee