数据涨了，但你不知道是因为什么
一个音乐类产品上线了个性化推荐功能。第一周DAU涨了8%。团队庆功，准备加大投入。
但产品经理回去复查数据，发现同期运营团队刚推了一个拉新活动，渠道部门也加了投放预算。DAU涨的那8%里，推荐功能贡献了多少？没法确认。
更尴尬的是：推荐功能上线的同一个版本里，还修复了一个影响播放体验的bug。有没有可能DAU涨的原因是bug修了、体验好了，跟推荐功能没关系？
这个场景暴露的问题：产品经理最常犯的归因错误是"我做了A，然后B发生了，所以A导致了B"。真实环境里变量太多，单一归因几乎不可能。
可操作的判断方式：不要做"A导致B"的结论。做"在X时间段内，A和B同时发生了；除了A之外还有C和D也在同期变化"的描述。如果需要确认A的贡献，做AB测试——虽然慢，但这是唯一可靠的方法。
老板说"做一个"，你知道不该做但说不出理由
产品例会上，老板看了竞品新发的一个功能，说："这个我们也做一个。"你的直觉告诉你不该做——但你说不出一个让老板信服的理由。
如果你说"这个功能和我们的定位不匹配"——老板会问你定位到底是什么，你发现自己也说不清楚。如果你说"我们没有资源"——老板会说那就砍掉另一个需求。如果你直接说"我觉得不应该做"——那只是你的观点对老板的权力。
这个场景暴露的问题：产品经理的"直觉"如果没有一套可展示的判断框架支撑，在组织决策里就是零。方法论课教你做决策，不教你在权力结构里推销决策。
可操作的判断方式：不要在会上直接对抗。会后用一页纸写清楚：做这个功能需要什么资源、挤掉哪个需求、预期收益是什么、风险在哪。让老板在具体数字面前重新判断。有时候老板看完一页纸还是坚持要做——那就做，但把你的判断和数据存档，三个月后复盘。
两个方向都能说通，但你只能选一个
做社区还是做工具？两个方向各有一半数据支持。做社区——用户互动数据在涨，有社区调性的基础。做工具——用户留存依赖核心功能质量，社区可能分散注意力。
团队内部意见分裂。产品经理自己也没有强烈的倾向。但下个季度的开发资源只够投一个方向。
这个场景暴露的问题：方法论假设每个决策都能用数据和逻辑推导出"正确答案"。但在真实产品工作中，很多决策就是五五开。硬分析只能帮你排除明显错的，不能帮你在两个都对的选项里选一个。
可操作的判断方式：选可逆性更高的那个。社区做烂了可以收回去，工具做错了功能也能回滚——但社区一旦建立了用户预期就很难关掉。如果两个选项可逆性差不多，选团队当前能力更匹配的那个。还是选不出来？选你自己更相信的那个——然后全力以赴，因为结果取决于执行质量，不取决于方向选择。
产品改了三版用户还是不满意
一个社交产品的私信功能被反馈"不好用"。产品经理第一版改了界面——用户反馈没变。第二版加了消息已读提示——还是不满意。第三版增加了语音消息——反馈更差了。
最后去做了一次深度访谈才发现，用户说的"不好用"根本不是功能问题——是消息通知太频繁、干扰日常使用。他们要的不是更多功能，是少被打扰。
这个场景暴露的问题：用户的表达和真实需求之间有翻译损耗。"不好用"是一个模糊信号，产品经理按自己的理解去翻译，翻三次可能三次都错。
可操作的判断方式：收到模糊反馈时不要急着改。先追问"不好用是哪种不好用"——是找不到功能、操作太复杂、还是被干扰了？用"给我讲一个你最近用的时候不舒服的场景"来替代"你觉得哪里不好"。场景比评价有用一百倍。