需求来了先写一句话判断，不写PRD
收到一个需求——无论来自老板、运营还是用户反馈——不要急着写需求文档。
要做的事：用一句话回答"做这个需求是为了解决什么问题"。不是"用户需要一个X功能"——是"用户在Y场景下遇到了Z困难"。如果一句话写不出来，说明你还没理解这个需求。
判断点：把这句话念给一个不了解背景的同事听。他能不能秒懂？如果不能，你的理解还不够准确。
完成标准：一句话判断通过了，再决定这个需求值不值得往下走。很多需求在这一步就可以过滤掉。
方向争论超过两轮就停下来问可逆性
团队内部对方向有分歧。A方案和B方案各有支持者，数据和逻辑都能讲通。争论超过两轮还没结论。
要做的事：停止争论"哪个方案更对"。换一个问题——"哪个方案做错了之后更容易改回来？"可逆性高的方案优先。
判断点：评估两个方案的回退成本——A方案做完发现不对，推倒重来需要多少人天？用户预期会不会被不可逆地改变？技术架构会不会被锁死？
完成标准：选择了可逆性更高的方案，或者两个方案可逆性差不多时选了团队能力更匹配的那个。记录下你的判断依据——三个月后复盘用。
数据涨了不要庆功，先做排除法
产品上线后数据变好了。不要急着归功于自己做的改动。
要做的事：列出同期所有可能影响这个数据的因素——运营活动、渠道投放、竞品变动、季节性因素、同版本其他改动。逐一排除。
判断点：排除了所有已知的干扰因素之后，剩下的增量能不能合理归因到你的改动上？如果不能确定，标记为"相关但未证实因果"。
完成标准：数据归因报告里每个结论后面都有排除过程，而不是"我做了A，数据涨了，所以A有效"的直接跳跃。
老板坚持要做你觉得不该做的需求
老板指了一个竞品的功能说"这个我们也做"。你的判断是不该做。
要做的事：不要在会上直接对抗。会后用一页纸写清楚——做这个功能需要多少开发资源、挤掉哪个已排期需求、预期收益是什么、主要风险在哪。呈现的逻辑是"选择题"而不是"反对意见"。
判断点：老板看完一页纸后有没有改主意？如果没有——做，但在需求文档里记录你的判断和老板的决策理由。三个月后带着数据复盘。
完成标准：无论最终做不做，你的判断过程有记录、有数据、可复盘。这比单次决策的对错更重要。
产品改了两版还是不对的时候回到用户场景
你根据反馈改了产品，改完数据没变好。又改了一版，还是没用。
要做的事：停止改产品。回到用户端——找五个活跃用户做深度访谈。不问"你觉得产品怎么样"，问"你上次用的时候遇到了什么不舒服的事"。用场景描述替代满意度评价。
判断点：五个用户的场景描述里有没有共同模式？如果有，你的改进方向找对了；如果五个人说的都不一样，说明问题可能不在产品——在用户群的匹配上。
完成标准：从用户场景中提取出至少一个可验证的假设，然后用最小改动去测试。