做我能独立主导验证链路的项目时，我可以很快。
一个想法出现以后，我会先做 Mockup，去小红书找用户，推进最小版本，再根据对话、留存和访谈决定继续还是关闭。做萌芽时，从提出概念到完成冷启动、MVP、用户研究和复盘，所有关键判断都在一条很短的链路上。
进入公司级项目以后，速度明显变了。
同样是发现问题，一个改动可能同时牵动产品、研发、设计、内容、增长和既有用户。它不再是「我判断应该做，就马上试试」。
以前我会把这种差异简单理解为推动很麻烦。现在我更愿意把它看作两种不同的速度系统。
决定速度的，不只是人的行动力
这篇文章里的「个人项目」，不是指所有事情都由我一个人完成，也不是指它一定发生在公司之外。它指的是问题、指标、节奏与停止条件主要由我负责，决策链相对完整。
这类项目快，是因为决策面很小。
我可以同时决定解决什么问题、先验证哪一段、用什么指标判断，以及什么时候停。一次试验即使失败，影响的用户和成本也相对有限，很多决定都是可逆的。看见数据不对，我可以在当天改变方向。
公司级项目承担的东西更多。它已经有稳定的产品结构、品牌承诺、技术基础和大量用户。一个看起来很小的入口变化，可能影响原有路径；一个增长活动带来的新用户，也可能改变服务成本、数据口径和后续运营。
当错误的代价变大，团队需要更多人共同理解问题、确认优先级并承担结果。速度因此变慢，却不一定意味着谁不愿意做事。
真正决定速度的，是一个决策需要跨过多少依赖、失败是否容易撤回，以及有多少人会被它影响。
快的价值，是尽早暴露错误；慢的价值，是不让局部正确伤害整体
萌芽的次日留存只有 15%，低于预设目标。我能够很快关闭项目，因为它仍处在验证阶段，停止的成本可控。这个决定让我们没有继续为一个不成立的假设增加功能。
在帆书智能版的增长实验里，我也迅速推动了一轮外部博主合作。数据很快告诉我们：渠道可以带来发布和注册，但非帆书用户的持续使用仍然不足。
接下来就不能只靠我把一个页面改掉。留存涉及产品价值、首次体验、内容供给、交互、笔记沉淀以及用户原本对帆书的认知。每个局部方案，都要放回更大的系统里判断。
个人项目的速度适合探路，让错误尽早、便宜地出现；公司级项目的协作适合把已经看见的问题，变成能在更大规模上安全运行的方案。
两者都有自己的盲区。
个人决策过快，容易把一个人的偏好当成市场，也可能因为资源有限而错过真正需要时间积累的价值。公司协作过慢，则可能让问题在对齐中失去窗口，最后用流程代替判断。
产品经理不是让所有事情都变快
我现在更关心的，不是证明自己动作很快，而是辨认一件事应该以什么速度发生。
哪些假设可以用一个轻量原型先试，不需要等完整方案？哪些改动可逆，应该给一线团队更大的决策空间？哪些事情一旦上线就很难收回，必须先把风险、依赖和口径说清楚？
在公司级项目里，推动力也不只表现为更频繁地催进度。它包括把用户问题翻译成各方能讨论的结构，缩小第一次验证的范围，让团队知道这次不解决什么，并用证据减少无休止的意见争论。
个人项目让我练习如何在不确定里迅速开路；公司级项目则迫使我学习，怎样让一条路穿过真实组织，而不是只存在于我自己的判断里。
快从来不是目的，慢也不是成熟。
好的速度，是让一个决定既没有错过用户，也没有把本该共同承担的代价，藏在某个人的果断里。