是否可能发布得太多——或者太快？
是的。大概是的。遗憾的是。
如今，只需要少数几个判断力不错、而且拥有大量 token 的人，就能完成过去需要整个产品组织才能完成的工作。结果是，由大语言模型（LLM）驱动的软件，比历史上任何时候都更便宜地被构建、也更快地扩展。
然而，一旦跨过某个阈值，产品速度就不再继续复利增长，而是开始彼此竞争。此时，限制你的不再是“你能发布多少新东西”，而是“你的用户能够吸收和采用多少”。
作为一家痴迷于快速发布的公司，我们对这个问题体会得非常深刻。因此，我想分享我们正在如何应对它，希望你也能从中受益。
约束理论（Theory of Constraints）
由于 PostHog 是一款工作工具，而不是生活方式品牌，即便是最狂热的用户，也不可能每周采用无限多个新功能。
在实践中，B2B SaaS 用户的采用节奏通常是：
- 每几个月采用一个重大的新功能
- 若干个中等规模的改进
- 少量提升体验的小型优化
其他一切，都会被忽略，直到有人明确解释清楚“为什么它重要”。这正是一个典型的瓶颈。
幸运的是，瓶颈是有解法的。制造业早已发现这一点，并将其总结为一个概念：约束理论（TOC）。其中有一条原则在这里尤其关键：
当上游产出增加，但下游能力没有相应提升时，系统就会失稳。
在我们的场景中，这种失配表现为：
- 上游：40 多个小团队异步工作，以极高的速度持续发布，AI 进一步放大了生产力
- 下游：用户有限的注意力、理解能力与参与能力
当你意识到这一点，TOC 还能帮助你理解这种能力错配会带来哪些具体后果。
当发布速度超过采用速度时，会发生什么？
1. 队列堆积
在制造业中，这种情况表现为库存积压；在软件中，它会形成一个“隐形待办清单”——你的工作已经完成了，但在“用户认知与理解”层面却尚未完成。
结果是影响力被稀释：发布了大量进展，但用户真正感受到的进展却更少。
2. 价值实现时间被拉长
随着这个隐形积压不断扩大，从“功能可用”到“真正有用”之间的时间差持续拉长。
你的团队不断发布新代码，但每一个新能力都需要更久才能被用户理解并真正使用。用户逐渐跟不上变化节奏；支持与销售花更多时间解释背景；市场营销开始追赶发布，而不是放大它们的影响。
3. 产品质量开始退化
当瓶颈被过载时，质量会通过被迫的权衡而下降。
在软件中，这种退化表现为：
- 功能只被部分采用，而没有带来完整的行为改变
- 能力被误解
- 原本被设计为“基础能力”的功能，却只被狭隘地使用
你的产品不断变大、变强，但并没有成比例地变得更清晰。
那是不是意味着应该慢下来？
绝对不是。
放慢速度，是公司在“没想法了”时才会做的事，而显然这并不是问题。幸运的是，约束理论对“不该做什么”说得也非常清楚：
提升非瓶颈环节，是在浪费资源。真正能改善系统的，是抬升瓶颈本身。
产品采用是一件“一个人一次”的事情，而每个用户的认知带宽都是有限的。所以真正的问题不是“要不要慢下来”，而是：
如何在不牺牲速度的前提下，提高采用能力？
真正的瓶颈：用户注意力
如果你正在构建任何严肃的产品，并且正在用 AI 提高产出，你迟早都会撞上这堵墙。
在 PostHog，我们仍在不断摸索最佳路径，但有几件事已经变得异常清楚。
1. 把注意力当作稀缺资源（因为它确实是）
小型自治团队天然会围绕自己负责的那一小块产品进行优化。他们拥有某个功能，并持续把它做得更好。
但用户并不是以“功能所有权”的方式体验产品的。他们是通过有限的注意力，被动接收你所有的产品变化。
正是在这里，系统开始失衡。
常见的失败表现
- 把“发布”当作产出，而不是结果
- 兴奋地宣布每一个新功能
- 期望用户通过更新日志或邮件来跟上变化
这些方式能捕获的注意力是有限的。一旦发布速度足够快，就连最投入的用户也会产生“功能疲劳”。
如果你曾从一个长期客户口中听到过：“我都不知道你们还能这么用”，恭喜你——你已经发布得超过了采用速度。
更好的做法
继续发布，但要对“此刻什么最重要”保持高度主观且果断的判断。
不是所有东西都需要一次发布、一篇博客，或者立刻被解释清楚。可以引入一个清晰的发布分级框架，例如：
- 品类定义级：全新产品发布，或改变客户如何理解整个品类的重大设计，需要全公司对齐
- 战略升级级：有分量的产品改进，但不重新定义品类
- 稳定改进级：常规产品开发，只需产品团队内部协调
这正是品牌发挥作用的地方。幽默、叙事感、刻意的荒诞，都能降低“付出注意力”的成本。与在目标客户群中拥有信任的影响者合作，也能有效扩展心智份额。
2. 把“发现”内建到产品中
如果实现价值需要在产品之外被解释，那你并没有消除采用瓶颈，只是把它转移到了市场、销售或支持那里。
用户并不是为了“了解产品更新”而醒来，他们只是想把事情做完，然后继续生活。
这就是为什么，与用户当前意图紧密绑定的功能发现，比脱离语境的公告有效得多。
常见的失败方式
- 依赖嘈杂、饱和的外部渠道进行功能发现
- 使用缺乏语境的产品邮件或打断式的产品提示
- 发布视频或新闻稿承诺“革命性变化”，却没有清楚解释产品究竟变了什么
更好的做法
在功能与用户当前行为相关时，再把它呈现出来。
先定义清晰的激活信号——那些表明用户正在深入使用某个产品区域的行为。一旦识别这些信号，就可以把新功能锚定到用户已经关心的任务上。
这也被称为持续发现（continuous discovery）：让用户行为与反馈，决定接下来该放大什么。
3. 衡量“学习”，而不仅仅是“使用”
产品采用不仅仅是功能是否被点击，而是这些功能是否真的让用户更擅长他们的工作。
这也是为什么我们大量内容营销并不是直接讲 PostHog，而是在讲如何成为更好的产品工程师。
分享知识、真正提供帮助，比功能公告更能建立信任和品牌认知。
常见误区
- 过度关注虚荣指标
- 把产品团队变成“功能工厂”
- 发布只有在你已经关心产品时才有意义的内容
你能犯的最大错误之一，就是以为别人和你一样在乎你的产品。
他们并不。
更好的方式
发布即使不用你产品，也依然有价值的内容：
- 真实的经验总结
- 内部知识的公开版本
- 坦诚的事故复盘
- 对整个行业的教学，而不仅仅是产品教学
快，但不慌乱
把“发布得太快”当作一种自嘲式炫耀，很诱人，但这是懒惰的思维方式。如果用户无法采用你发布的东西，那就不是速度，而是浪费。
在实践中，这意味着你必须清楚地区分：
什么值得被大声强调，什么不值得。
通常，一个功能值得被重点营销，当且仅当：
- 它改变了核心工作流
- 它能与已有行为形成叠加效应
- 它有清晰的“啊哈时刻”
- 你能为它提供持续的支持与引导
其他一切，都应该安静地通过系统流转，不去争夺不需要的注意力。
只有当采用速度跟得上，产品速度才能真正复利增长。
如果用户注意力是瓶颈，你的工作不是慢下来，而是更有选择性。刻意把少数事情放大声量，让其余部分安静地做到极致。