大部分产品决策不是因为想清楚了才做的，是因为不做不行了才做的。
方法论课程总是给你一个假象：先分析、再决策、再执行。但在真实产品团队里，大多数重要决策的触发条件不是"分析完了"，是"截止日到了""竞品发了""老板催了"。接受这个现实，不是放弃分析——是把分析压缩到"来得及"的范围内。
你觉得自己在做用户调研，其实你在找支持自己想法的证据。
产品经理带着预设去做调研是常态。先有了一个功能想法，然后去找用户验证——但你不自觉地只会注意到支持你想法的反馈，忽略掉否定的。王诗沐的建议是：做调研之前先写下"如果调研结果说不该做，我会放弃吗"。写不下来，就别浪费时间做调研了。
数据涨了不代表你做对了，可能只是市场在涨。
最常见的归因错误。你上了一个新功能，DAU涨了5%。你觉得这是新功能的功劳。但可能是这个月行业整体在涨、可能是市场部刚投了一波广告、可能是竞品出了bug用户跑过来了。判断"这件事到底是不是我做对了"，需要控制变量的能力，而不是看大盘数据。
做产品最贵的成本不是开发资源，是注意力。
一个产品经理同时推进五个项目和专注推进一个项目，产出的质量差几倍。团队的开发资源可以量化，但产品经理的判断质量会随着注意力分散急剧下降。能砍掉一个项目，就砍掉一个——空出来的注意力比多出来的一个功能值钱得多。
"我们要不要做社区"——这个问题在网易云音乐被讨论了至少两年。
好的产品决策经常是慢的。不是所有问题都需要快速决策。社区功能做不做，涉及产品定位、社区调性、运营能力、技术架构多个维度，急着做大概率会做烂。有些判断值得等——等到团队对这个问题的理解从"觉得该做"变成"知道怎么做"。
用户反馈最多的功能未必是最该做的，付费用户不反馈的功能可能才是。
反馈量大的功能通常是免费用户在吵。付费用户的需求往往通过客服渠道安静地传达，或者根本不传达——他们会直接用脚投票。产品经理如果只看社区反馈做优先级排序，会系统性地忽略掉实际能带来收入的需求。