最详细的产品反馈，往往来自最懂工作流的那个人。他能指出每一个缺失的快捷操作、每一个边缘情况，以及系统在专家用法下会从哪里断掉。这些反馈具体、清楚，几乎可以直接变成待办事项。也正因为这样，它很容易把产品带向危险的方向。
成熟用户并没有错。他描述的是一项真实工作，只是站在一个高度发展的位置上。团队真正容易犯的错，是把反馈表达得清楚，当成需求普遍而重要的证明。专业能力会让问题更容易被说出来，却不会自动让问题变得更常见、更符合战略。
团队很容易把清晰，误认为重要
一个新手可能安静地卡住，没有到达价值，然后离开，连一句有用的话都没有留下。专家则会继续使用，自己搭出临时方案，再提交一份精确的需求。于是路线图越来越照顾那个已经成功的人，而那些连第一道门槛都没跨过去的人，在数据里保持沉默。
这会形成一种可表达性偏差。用完整语言送到团队面前的问题，看上去比犹豫、放弃和反复咨询暴露的问题更真实。产品逐渐变得擅长解释复杂性，却没有继续减少复杂性。
声音最大的反馈，往往来自拥有最强替代方案的人，不一定来自需求最没有被满足的人。
把反馈当成证据，不要直接当成指令
一条需求，只是关于某项工作、某种情境和某个人的一次观察。真正的产品工作从收到它以后才开始。用户到底想完成什么？这种情况多久发生一次？产品不处理会造成什么后果？还有哪些人共享这个问题？解决它会强化产品方向，还是会在同一个界面里长出另一款产品？
这并不是要忽略专家，也不是把所有意见做平均。专家用户可能比更广泛的市场更早看见一条工作流的未来，也能暴露新手根本说不清的能力缺口。关键是把他们要完成的工作，从他们提出的具体实现方式里分离出来。
这套框架不是打分机器，它只是让团队不要从表达清楚的需求直接跳到路线图承诺。一个少见的专家需求，可能因为后果严重、又处于战略核心而值得投入。一个常见请求，也可能因为把产品拉进低价值类别而应该拒绝。
听反馈时，也要向旁边看
专家要求更多控制时，看看那些连第一个决定都没理解的新手。重度用户要求更多配置时，看看是不是默认设置迫使所有人开始配置。成功客户要求覆盖另一个边缘流程时，看看那些连核心流程都没完成的人。
重要信号往往分散在不同类型的用户身上。专家解释产品的天花板，新用户暴露产品的地板，已经流失的人则指出活跃社区早就学会忍受的缺口。把这些视角放在一起，产品方向才不会被最会表达的那个人代替所有人决定。
最懂产品的用户可以是一位非常好的向导，但他不能成为整张地图。认真听他学到了什么，再越过他给出的解决方案，看看更深的工作。路线图应该跟随那个问题，也跟随产品想去的方向，而不是跟随最擅长替团队写需求单的人。