第 19 章 · 反馈不是全都要听
这条反馈该做、该等，还是该忽略？
实验做完了，开始有人说话。接下来的风险不是没有反馈，是被反馈带跑。
机制
每一条反馈听起来都像是要你去做点什么。全都照做，产品会变成一堆互相矛盾的功能，而且没有一个用户真正满意。
分类比收集重要。一条反馈要判三件事：
它属于哪一类。 缺陷、可用性、价值、功能请求、定价、噪音。类别决定了它该多快被处理——可用性问题通常很便宜，功能请求通常很贵。
它是不是趋势。 一个人提是偶发，三个人提同一件事是模式。在那之前，记下来就够了。
说的人是不是目标用户。 不是的话，一律忽略。这条最硬，也最常被违反——路过的人的意见往往更尖锐、更有「洞见感」，而他们从来不会回来用。
每条反馈都要有一个结论：处理、观察、忽略。
没有处置的反馈只是一堆笔记。「以后再说」不是处置。
为什么规则要写死
因为在手上这条反馈面前，你总能找到理由破例——尤其是当提意见的人说得很有道理、很热情，或者你很想让他满意的时候。
规则写死之后，破例要有明确的理由，而不是靠当时的情绪。
现实案例
一：「我不知道该把数据粘到哪里。」——目标用户，观察到的卡点，可用性 → 处理。改一行占位文字，十分钟。
二：「百分比那一列合并后格式丢了。」——目标用户，缺陷，挡住主路径 → 处理。
三：「能不能做个深色模式。」——目标用户，功能请求，一个人提，口头 → 观察。记下来，再有两个人提再说。
四：「这个应该做成浏览器插件，还可以接 API 自动拉数据。」——提的人是她做技术的朋友，不是目标用户 → 忽略。
第四条是最难忽略的：它听起来最专业、最有想法。但那个朋友不出周报，他永远不会用这个东西。
动手试
把你收到的反馈逐条填进去，看判定。
判定给出的是默认处置，不是命令。要破例就破，但要能说出理由——「因为提的人很热情」不算理由。
你的行动
把收到的每条反馈记下来：谁说的、在什么场景、具体内容、分类、严重度、是观察到的还是听来的、处置。
然后挑出判定为「处理」的那一到三条。只做这些。
检查标准
- 至少一条来自真实外部用户的反馈
- 每条都分了类并给了处置
- 每条都标了是行为还是口头表达
- 非目标用户的意见被忽略了，哪怕它听起来很专业
- 我挑出了最该先处理的一到三条
容易搞错的地方
旁观者没有真实约束，所以想法更大胆、更完整、更像一个产品方案。
而他不会回来用。判断标准只有一条：他属不属于目标用户。
它既不是处理也不是忽略，结果是这条反馈永远悬着，每次看到都要重新纠结一次。
明确写「观察，再有两人提到就做」，它就变成了一个有触发条件的决定。
本章自测
- 一条反馈要判哪三件事？
- 为什么非目标用户的意见要忽略，哪怕它很有道理？
- 为什么「以后再说」不算处置？
- 第 20 章 · 行为比言论值钱 — judgeFeedback