这个产品基本是我一个人完成的。我主要利用晚上、周末，以及比我愿意承认的更多假期来开发它。很长一段时间里，即使它已经在 Web 上运行，我仍然把它当成一个个人项目。
支付功能上线后，这种感觉立刻变了。代码并没有突然变得更高级，但我对产品承担的责任变了。一旦有人可以付钱，一个坏掉的流程就不再只是“以后再修”的 edge case。Onboarding、moderation、retention、信任和可靠性不再是未来的问题，而是产品此刻承诺的一部分。
这是这次上线给我最重要的教训：一个人把功能丰富的项目做出来，和真正运营一个产品，是两种不同的工作。
Solo 开发真正的瓶颈变成了注意力
开发这个产品的那段时间，我几乎从社交媒体上消失了。这不是 launch 策略。产品决策、实现、edge case、流程测试和 release 准备，都在争夺同样有限的时间。
我现在更理解 solo development 的这一面了。瓶颈并不总是我写代码有多快，而是我能把多少注意力分配给产品里不断增加的状态、状态转换和失败路径。
Build 成功并不能回答这些问题。一次支付成功也不能。
支付改变了我对 bug 的定义
在支付上线前，我还可以把一些不完善的地方看成“以后再修”。支付上线后，这种想法对我来说就不再成立。付费产品并不意味着必须没有任何 bug，那不现实。但当另一个人已经把钱交给产品之后，一个已知问题长期不解决的代价就不同了。
Onboarding 和 moderation 也是一样。开发阶段，它们很容易被看成围绕“核心功能”的辅助系统。但在 production 中，只要用户会直接经历它们，它们就是功能体验的一部分。Retention 也是类似：第一次使用体验不错，并不能证明产品已经给了用户再次回来的理由。
支付没有证明产品已经完成。它只是让我看到，“完成”这个词背后其实藏着多少工作。
上线给了我另一种信息
Release 之后开始的是不太适合放进漂亮截图里的工作：只有发布后才暴露的 bug、坏掉的流程、用户出现后才真正成立的 moderation 问题，以及远比做好第一次体验更难的 retention 问题。
我也尽量不把这些信号解释得太过头。上线后的 bug 并不自动说明 architecture 很差。Retention 有问题，本身并不能诊断 product-market fit。一个 moderation 问题也不能证明整个系统都不安全。症状会告诉我该去哪里调查，但不会自动告诉我原因。
真正变化的是证据的质量。上线前，我测试的是“我认为用户会怎么做”。上线后，我必须面对“用户实际怎么做”。Release 不是不确定性消失的时刻，而是某些最重要的不确定性终于变得可观察的时刻。
我现在使用的 post-launch 循环
现在，比起把 launch 故事包装得更漂亮，我更在意上线后的工作：支付带来的经验、坏掉的流程、moderation 挑战、用户行为、retention 中的意外，以及那些让产品逐步变得更可靠的小修正。
- 观察真实流程。 不假设我设计的路径就是用户真正会走的路径。
- 区分症状和原因。 某一步失败能说明问题发生在哪里，但不自动说明为什么发生。
- 优先处理影响信任的失败。 支付、访问、onboarding 和 moderation 的失败成本更高，所以优先级高于纯视觉问题。
- 先修最小的已确认问题。 与其根据猜测重构整个系统，我更愿意先消除一个已经确认的摩擦点。
- 修完后重新检查用户体验。 代码改动可能技术上完全正确，却仍然没有解决用户面对的问题。
这不是一套普遍适用的 framework。它只是从“做产品”转向“运营产品”以后，对我最合理的一种工作纪律。
Launch 改变了我的“事实来源”
我现在最在意的区别，是已经把产品做出来和已经准备好运营产品。开发关注系统是否能按设计工作。运营关注的则是：真实的人使用它、误解它、离开、回来、付钱，或者走进我没预想过的路径时，会发生什么。
所以我不再把 launch 看成终点。上线前，大多数证据来自我的假设和测试。上线后，产品开始通过真实行为、失败和重复使用来给我答案。