在谈到产品经理能力的时候，我们更多关注的是产品经理对需求挖掘和需求实现上的能力。其实，在现实工作中，怎样接需求也是对产品经理充满考验的。
一、写在前面
产品经理工作中的需求，不仅仅来自于自己的发现、思考，还有很大一部分来自于自己之外，可能包含了业务线内其他岗位的同事、其他业务线的同事、领导、外部合作方等。
关于如何处理领导需求，之前专门整理过想法，可参见《#41 产品经理如何处理领导的需求？》，但不论需求来源如何，其实处理思路是比较一致的。
至于外部合作方，影响因素过多，本文更多针对公司内部的需求，暂不针对外部合作方的需求做展开。
针对需求承接，实际工作中还是会发现不同人的处理风格差异明显，而有的风格我觉得还是挺值得探讨，所以整理下我觉得比较值得提倡的处理思路。
二、承接需求的不正确姿势
在需求承接的方式中，一种比较常见应对需求的处理方式是：
你告诉我需求是啥，我按你说的做。
再进一步，如果没说清楚，我问到清楚为止。
如果以这种方式应对，需求能否承接好，和需求提出方关系很大， 如果需求方的需求提的好、足够清晰、价值明确，那么尚且好说，否则各种问题都会发生，比如：
- 需求价值不明显，做了没什么产出
- 需求没想清楚，做的过程中遇到各种细节问题
- 需求没有可行性，结果不能做
- …
这种情况下的产品经理其实等于是把自己的一部分职责转移到了需求方，即把需求分析的阶段省略或者简略了。
三、承接需求的建议姿势
产品经理的工作内容包含了需求分析，即接到一个需求需要考虑包含但不限于如下点：
- 这个需求价值是什么，用什么衡量，怎么衡量？
- 为什么认为这个事情有价值，现状如何，数据如何，怎么体现出来需要做这个事情？
- 需求要达到的目标是什么？
- 限制条件是什么？
- …
至于针对这个需求具体用什么产品方案，需要注意的是需求方有可能同时把解决方案一起给过来，但要明确需求方解决方案是一个重要参考，而不是直接作为执行方案。
因为针对你的产品，理论上你应该是最清楚的，所以你需要根据自己对产品的了解，针对目标，结合限制条件，提出解决方案。
如果恰好你了解信息后解决方案和需求方一致，那么说明双方对事情的判断、理解都是非常一致的，如果你的方案好于需求方且同样能达成目标，那就更好了，如果比需求方给的方案差，那至少可以采纳需求方的方案。
但有可能会存在业务方提出的需求中包含了自己不懂的部分，这一部分绝大部分情况下你是需要搞明白的，因为不搞明白就不知道什么是合适的解决方案，即使出了解决方案，也不完全确定是否真的解决了问题，是不是埋下了什么坑。
当然，这里还有一个可能性是，需求方的需求自己没有理清楚，比如需求方不清楚这个事情的价值有多大，没有数据只是觉得可能有价值，或者只知道问题，但解决问题的思路不清晰。
理论上这一部分应该需求方补齐，即提供足够的说服力以便让产品经理来认可价值，从而为有价值的目标提供解决方案。
但是还是会碰到有些时候需求方在这个地方的基础建设比较弱，那么如果明确问题存在和这个事情对公司的价值，产品经理可以考虑补位，协助需求方明确此部分价值，这里有两个好处：
- 在理清楚价值的情况下，可以和需求方对齐认知。
- 如果价值对齐后价值有限或路径不合理，那么可以减少不必要或者低 ROI 的资源投入。
而在其中，产品经理也要清楚自己的定位，产品经理的定位是作为产品的负责者，在明确价值的基础上，产品经理应该把自己作为主人翁推动事情进行，而不只是其中的一个环节，即不要遇到问题就推回给需求方，要尽可能利用自己的专业知识针对目标的达成提供合理的解决方案，如果有资源问题，通过优先级管理来解决。
当然，需求方自然应该是「主人翁」的角色，但产品经理不要因为这个就降低对自己的要求，因为一个作为「主人翁」角色的产品经理，除了更能站在业务角度思考问题，也更容易获得团队和合作伙伴的认可。
简单总结下，我建议的需求承接姿势是：
明确问题或价值–>确定目标–>确定限制条件–>提出合理的解决方案–>和需求方达成一致
随后就是常规的需求推进流程了，而在期间的角色定位，应该尽早定位于「主人翁」的角色，即使晚介入一步，在需求价值明确的基础上也需要进入角色了。
