第 15 课：用户反馈与迭代
面对真实用户
产品上线后最重要的事：面对真实用户。
在这之前，你所有的认知都是假设。你的用户画像是假设，痛点是假设，解决方案是假设。上线之后，假设才开始被验证——或者被推翻。
面对真实用户的心态：
不要害怕负面反馈。 负面反馈是最有价值的反馈——它告诉你哪里出了问题。一片叫好声反而是危险的信号，可能意味着你的用户还不够多，或者你的反馈渠道有问题。
不要急于回应每条反馈。 不是每条反馈都需要立刻行动。收到反馈后先记录、分类，等积累了足够的量再做决策。
区分反馈的来源。 核心用户的反馈和随机用户的反馈权重不同。一个每天使用你产品的用户说"这个功能不好用"，比一个第一次来的用户说"界面不够好看"重要得多。
反馈渠道建设
常见的反馈渠道：
- 应用内反馈：最直接的渠道，用户在使用过程中随时可以反馈
- 客服/工单：用户主动报告问题的渠道，通常是最紧急的反馈
- 社区/论坛：用户之间讨论产品的场所，能发现你没想到的使用场景
- 社交媒体：公开的反馈，影响面大，需要及时关注
- 用户访谈：主动获取深度反馈的方式，适合验证特定假设
选择渠道的原则：让反馈的门槛尽可能低。 用户越容易反馈，你收到的反馈越真实。如果反馈需要填 5 个字段才能提交，大部分人会选择直接离开。
RICE 框架排优先级
反馈多了之后，你不可能什么都做。需要一个系统的方法来排优先级。
RICE 框架：
| 维度 | 含义 | 评分 |
|---|---|---|
| Reach | 这个改动会影响多少用户？ | 预估影响用户数 |
| Impact | 对每个用户的影响有多大？ | 3=高，2=中，1=低，0.5=极低 |
| Confidence | 你对这些估计有多确定？ | 100%=高，80%=中，50%=低 |
| Effort | 需要多少工作量？ | 预估人周数 |
RICE 分数 = (Reach × Impact × Confidence) / Effort
分数越高，优先级越高。
一个例子：
| 需求 | Reach | Impact | Confidence | Effort | RICE |
|---|---|---|---|---|---|
| 搜索功能 | 5000 | 2 | 80% | 4周 | 2000 |
| 深色模式 | 3000 | 1 | 100% | 2周 | 1500 |
| 导出 PDF | 1000 | 3 | 80% | 1周 | 2400 |
按 RICE 排序：导出 PDF > 搜索 > 深色模式。
RICE 不是精确计算，而是让优先级判断有据可依，而不是凭直觉。
学会说"不"
每个产品经理都要学会一件事：拒绝需求。
不是所有用户反馈都应该变成产品功能。有些反馈反映的是个别场景，有些反馈跟产品定位不符，有些反馈的用户根本不是你的目标用户。
说"不"的方式：
- "这个需求很重要，但不在当前版本的范围内，我们记下来后续评估"
- "这个场景目前不是我们的重点，但我们会在 v2.0 时重新审视"
- "这个需求跟产品的核心定位有差异，我们可能不适合做"
说"不"不是否定用户，而是保护产品的聚焦。什么都做的产品，最终什么都做不好。
关键概念
- 负面反馈最有价值：它告诉你哪里出了问题
- RICE 框架：Reach × Impact × Confidence / Effort，让优先级有据可依
- 学会说"不"：不是否定用户，而是保护产品聚焦
课后练习
- 建立一个反馈收集渠道——选择适合你产品的渠道，确保反馈门槛足够低
- 收集并分类 10 条反馈——按来源、类型、紧急度分类，用 RICE 排优先级