持续运营

上线不是结束。真正的产品工作从真实用户开始：他们哪里卡住、为什么留下、为什么付费、下一版该改什么。

一个闭环

每周看一次数据  →  知道哪里变了
   ↓
反馈集中到一个地方  →  分类
   ↓
每轮只选 1-2 个问题处理
   ↓
观察数据和反馈有没有变化
   ↓
重复出现的动作写成模板或自动化

闭环的关键是最后两步。做了改动但不观察，等于每次都在重新猜；重复的动作不沉淀，你会一直在做同样的事。

先盯能指导动作的数

上线后打开数据后台，最容易犯的错是不知道该看什么。访问量跌了焦虑、涨了高兴，但不知道这些波动意味着什么。

标准很简单：一个指标涨跌之后不会改变你的任何决定，就先别看它。

如果只能先看一个，看留存。留存决定增长速度——留存低的时候，新增再多也没用，用户来得快走得也快，还会带来负面口碑。

工具型产品的用户"用完即走"很正常，停留时长和跳出率天然不好看。真正重要的是：他下次遇到同类需求时，会不会第一时间想起你。

看什么、怎么定义，见最小数据看板。

反馈要能变成改进

用户反馈不是越多越好，关键是能不能真的变成产品改进。

早期产品最大的风险不一定是做得不够好，真正的风险是做了很多用户根本不在意的东西。

三个层次：

不要只等用户主动说。 主动找你的人，通常是特别满意或特别生气的那两类，中间那一大批沉默用户的问题你听不到。

处理流程是四步：记录（集中到一个地方）→ 分类（功能请求、问题报告、使用困惑、正面反馈）→ 定优先级 → 闭环（处理完告诉报告的人）。

最后一步最容易漏，但它的回报最高。主动告诉用户"你提的那个问题修好了"，会让他从用户变成愿意帮你说话的人。

什么时候不该照用户说的做

三类反馈要谨慎：

• 用户要的和他真正需要的不是一回事——他会用现有方案的形状描述需求
• 一两个用户的特殊需求，样本太小
• 和产品定位冲突的需求，加了会让产品越来越模糊

迭代节奏

没有节奏的迭代很容易变成永无止境的修补。

每月那一次最容易被跳过，但它是唯一会问"这件事还值不值得做"的时刻。

优先级排序：修坏掉的 > 补缺的 > 加新的。

新功能是最诱人也最容易做错的选项。它有即时的成就感，但如果核心流程还有人走不通，加什么都是往漏水的桶里倒水。

一个简单的判断：如果这个功能不做，会有人离开吗？ 不会，就先别做。

你在维护的不只是代码

一个人做产品，实际在维护五样东西：

1. 可用性——别让用户一来就坏
2. 清晰度——别让页面越来越绕
3. 信任感——别让联系、支付、交付变得不确定
4. 节奏——你自己知道什么时候看什么
5. 心力——项目不要把你拖垮

第五样最常被忽略，也最容易先崩。每周只抓少数几件事，否则维护会变成永无止境的自责。

什么时候该停、该砍、该重来

可以考虑停掉： 很长时间没有真实反馈；你已经明确不想继续这个方向；用户反应持续很弱；你发现真正值得做的是衍生出来的另一个问题。

可以考虑砍功能： 很少被用；解释成本很高；维护成本明显高于价值；会分散用户注意力。

可以考虑重来： 定位始终讲不清；旧结构让每次改动都很痛苦；你已经明确知道该保留的核心是什么。

停和砍不是失败。它们是把心力从没有回报的地方收回来。

长期靠什么

短期靠功能，长期靠两样：

• 信任——你说的话别人信，你推荐的东西别人试
• 积累——内容、数据、用户关系，这些会随时间变厚

功能会被抄，这两样不会。

这一章的其他页面

常见卡点

验收标准

• 有一张能指导行动的数据看板
• 反馈集中在一个地方，且分过类
• 有每天、每周、每月三层节奏
• 每轮只处理 1-2 个问题
• 处理完会回复最早报告问题的人
• 用"出现三次"作为进入迭代的标准
• 有一份可以逐步自动化的重复动作清单
• 知道什么信号出现时该停或该砍

本章动作

打开你的数据，找出流失最严重的那一步。

只修那一个。 修完再看下一个。

下一步

1. 最小数据看板——先知道该看什么
2. 新用户激活——流失通常在这一段
3. 每周复盘——把证据变成下一版决策