产品经理在面对领导给的需求，要怎么样才能够把需求的处理进展及时反馈，一边让领导了解情况，另一方面也更能让人觉得办事靠谱呢？
产品经理工作中大概率会碰到领导的需求，这种需求有各种反应，网上也看到一些匿名的吐槽，综合下来常见的有如下几种反应：
我怎么没想到的这个需求呢，太好了，马上去做
领导说的，那就做吧
……
然后在实际行动上又有几类：
领导说咋做就咋做
根据对需求的理解找到和产品匹配的解决方案
拖着不做
……
上面是粗略的整理，但真正接到领导需求该怎么处理？我从做不做、如果做该怎么做来讲一下我的理解。
一、做不做？
不论做不做，至少有一点产品经理需要做到，即这些需求需要有回应。
怎么理解？
互联网公司不论中层管理者还是高层管理者，事情一般比较繁杂，交代的事情有不小的概率做不到随时跟进进度。
如果能够把需求的处理进展及时反馈，一方面是能够让领导了解情况，另一方面也更能让人觉得办事靠谱。不然从领导的角度来看，交代一个事情还得总记着询问进展，其实是在todo上又加上了一项，肯定是交代完之后，这个事情有进展自动回馈回来的体验更好。
作为产品经理，亦要考虑需求提出者的体验，这点对其他合作方的需求也是类似的，建议采用同样的处理机制。
再回到做不做上面。
首先要回到需求的本质是什么，如果不是那种类似bug之类非常明显的问题，个人建议和提需求的领导了解清楚他想要解决的问题是什么。
然后尝试理解为什么领导想要解决这个问题，他是从什么角度考虑的，再自己思考是否有更好的解决方案。
采用这个处理方式的原因固然是因为做需求要了解需求提出者的想法，还有一个点是因为领导往往掌握的信息比我们要多，所以尝试了解需求的原因，有助于站在更高的高度看问题，比如：也许是因为商业化的需求？也许是因为客户的强烈要求？也许是因为某一类忽略的用户的使用体验？这类锻炼非常有价值。
但这个方法判断做不做会遇到两个问题：
（1）领导不一定会在细节上过于深入
有些需求可能来自于某个闪现的想法或者大体的思路，具体的验证、可行性、方案选择很可能需要花不少时间和精力，初级和中级的产品经理应该在执行层面和对细节了解层面要做的比领导更好，因为你的时间应该花在这个上面。
所以对这个问题的解决思路是了解需求的初衷，然后自己分析，找到做、不做的理由。
（2）领导不一定会告诉你
我比较幸运，大部分情况下如果询问需求的原因，遇到的领导基本上会告诉我为什么有这个需求，但不排除有些领导只告诉你做什么，不告诉你为什么。
这种也很正常，因为有些在你看来还需要分析的东西，对领导来说可能是用经验堆出来的常识，比如：某些类型app加个签到并送些好处大概率能增加日活、半遮罩的弹窗会比进入下一级选择的交互体验更好等等。也有可能需求来自于他/她的上级，但并没有更细节的解释。
这些东西如果领导不讲或者不想讲，那么就自己尝试多多理解下为什么会有这个需求。
当然，如果你怎么都想不通，这些需求确实不合理，而真的不是你自己的问题，那么你可能遇到了假领导，可能需要换个机会。但在真的做出类似判断前，仔细想想是真的没有价值么？
我想正常的公司中做到中高层管理者，大部分人还是有自己的所擅长的内容和值得称道的地方，尽可能尝试理解需求的深层原因，从而学习领导的思考路径。
二、怎么做？
假设觉得领导提的需求确实有价值，那么就该想想怎么做的问题了。
先聊聊怎么排优先级：
如果从实践来讲，有道理、值得做、工作量很小，建议快速行动；如果是较大的需求，建议详细分析拆解、沟通后排优先级。
如果从理论来讲，不论需求大小都应该详细分析拆解、排优先级。
为什么实践和理论会有所不同？
因为实践中那些从自己角度判断的优先级不一定高的事情，可能只是因为信息不完整、思考角度不一致、对重要性认知不一致导致的，而并不是每个需求的提出者都会就每个需求沟通到通透的程度。
所以，我的实践是如果好做，尽快行动，如果不好做，分析有方案后，沟通自己的认知，并确认领导的优先级作为优先级。
再回到怎么做的问题：
我的建议方法是在理解领导需求的诉求后，找到应该做这个事情的逻辑和理由，因为从产品经理的角度来说，了解了需求的价值，才能基于价值去做产品产出。
是否完全按照领导在提需求时候的方案来进行，我的经验还是有一定商榷余地的。如果你的方案能解决需求，那么虽然和提的方案不一致，重点是解决问题。
但是这里有个小问题，有些初级产品经理还尚未掌握寻找最优解决方案的方法，所以有些时候如果方案已经给的很明确，也可以尝试理解和了解方案为什么是这样，理解后做好执行。
三、小结
上面内容有些啰嗦，如果用较为简单的话总结下，我的建议是：
理解后如果确实有价值，基于目标寻找最优的解决方案，或做好执行。
如果未影响其他高优进展，基于领导的优先级来作为优先级，否则沟通获得一致后调整优先级。
不论怎样，及时主动反馈沟通，不要被动等待领导询问进展。
