上线那一刻我通常是很兴奋的，但兴奋很快会变成另一种情绪：没人用。这一篇讲我怎么度过这段，以及后来形成的一套很轻的运营方法。
先接受：冷启动本来就是慢的
第一次上线，几乎不可能「很多人用」。这不是失败，这是常态。把它当成「开始收集信息」，心态会稳很多。
这一阶段的目标不是「增长」，而是「搞清谁在用、卡在哪、还想不想要」。
只看少数几个指标，别被数据淹死
我会给自己定三到四个真正会用来做决定的指标。做产品时通常是这几类：
有多少人真的完成了核心动作（不是打开了，而是走完了主线）；
有多少人回来了（第二次使用比第一次使用重要得多）；
卡在哪一步（这是最有用、也最容易被忽略的指标）；
有多少主动反馈（主动来的反馈，价值远高于你去问来的）。
注意这里没有「访问量」。对早期产品来说，访问量几乎不能用来做任何决定。
怎么筛选真实反馈
反馈这件事，最关键的是「区分类型」。我的做法是先把反馈分成三类再处理：
「我卡住了」—— 最高优先级，这是产品本身的问题，立刻修；
「我希望它能做 X」—— 记下来，但先问「你现在是怎么解决的」，判断是不是真需求；
「我觉得应该改成 Y」—— 放一放，尤其是涉及你核心设计的建议，要非常谨慎。
我的经验是：用户是最好的「问题报告者」，但不是好的「方案设计者」。听他们把问题讲清楚，方案仍然你来定。
迭代节奏怎么定
我用的是「固定节奏 + 小批量」：
固定节奏：给自己一个能长期维持的频率（比如每周或每两周一次），而不是想到就发；
小批量：每次只改一到两件事，保证出了问题能马上定位；
留一次「修体验」的窗口：不要每次都只加功能，要定期专门收拾卡顿、文案、空状态这些细节。
功能越加越多怎么办
这是我后来最警惕的问题。产品变复杂的过程很像房间变乱：每一件东西都有理由留下，合起来就成了灾难。
所以我给自己定了一条规矩：**加一个功能的门槛，是「明确说出它替代了什么、或者删掉了什么」。**
做加法很容易让人有成就感，但做减法才是产品变好的主要方式。
什么时候该继续，什么时候该停
这一条我给的是自己的判断标准，不是通用答案：
还在继续：有人回来用，并且有人主动来问「能不能做 X」；
需要调整方向：有人用，但用法和你设想的完全不同（这往往是机会）；
该停下来：用尽办法之后，依然没有人愿意付出最小成本去用一次。
「停下来」不丢人。把时间从一件不对的事上拿回来，是最划算的决定之一。
长期做下去真正靠什么
我最后发现，长期坚持靠的不是自律，而是两件更实在的事：
把每件小事都做成「我自己也用得上」的样子 —— 用得上就自然想维护；
把门槛降到极低 —— 改一篇文章只要几分钟、发一次版只要一条命令，你就不需要「下决心」才能维护它。
这一章的结尾
从「想清楚」到「做出来」再到「持续维护」，一个人做产品的完整闭环大体如此。它没有捷径，但每一步都有办法做得更省力。
如果说这一整章只有一件事值得带走，那就是：**把「上线」当成开始，而不是结束。**真正决定一个产品价值的，是上线之后你愿意继续改它多久。