作为产品经理，离不开需求的对接。要说对接需求，那可比设计产品需求累多了。那究竟该然后对接需求，更好地产出呢？作者总结了相关流程，希望对你有所帮助。

上周四笔者一天被领导安排对接了三个需求，分别来自三个运营。事实上对接需求这件事可比设计产品需求心累多了。在之前《谈谈对产品经理的理解》一文中提到的，如果领导把你当做一个传声筒，那今天笔者就来聊聊如何当好一个传声筒。

首先，为什么领导会安排产品经理去对接需求呢？为什么领导不直接安排对应的研发同学去对接需求方呢？

在一些相对大一些的互联网公司，同时有很多业务线，而各业务线下可能还会有很多子业务（功能模块），这每一部分都会有一个或几个产品经理来负责，也会有一个产品负责多个业务或子业务的情况。

这就引出了另一个问题，产品经理在负责什么呢？

产品经理所负责的就是保证自己业务能够正常流转稳定运营。所谓正常流转，简单来说就是不出问题，包括功能不出bug，有着需求完整的产出落地流程，支持业务的各部门能够按照优先级将产品经理设计的产品功能在预计时间点前落地。稳定运营则是产品有着稳定的用户数据以及营收数据，同时落地的业务是在合法合规的条件下平稳运作。

也就是说，产品经理在项目里可以不是最懂技术的，但一定是最了解业务的。他要知道项目的前世今生，以及要有一定的前瞻性和决策力来掌舵项目前进的方向。

而对接需求的意思通常是需求方来告诉产品经理他们要在你负责的业务下做些什么，这也正是为什么产品经理要去对接需求的原因。

可产品经理在对接需求的过程中要做些什么呢？产品经理如何在对接需求的过程中展现出自己的价值呢？

这里要分类讨论一下。首先，无论这个需求是谁提的，就算他是联合国主席，作为产品经理也要先理清需求背景，弄清楚做此事的前因后果。

其实分类讨论的点就在于此，这里大致分为两种情况，即需求方提过来的需求是真需求还是伪需求。

如果需求方的需求和优先级都很明确，且拿着圣旨，也就是说这个事儿一定要做。那没啥说的，这把拿到的就是张传声筒的底牌。作为一名专业的产品经理，你还是要在对接需求的过程中，尽量确定需求的边界，一期做到什么程度，然后冷静地分析下这个需求是否需要其他部门例如法务、风控等其他技术团队的介入，然后明确对方的预期上线时间。会后一定要和领导同步下，该发的邮件别懒，然后就可以产出需求，拉会宣讲往下走流程。

通常来说，需求方在对接需求时，传达的需求并不是很明确的，有时甚至很抽象。这个场景像极了一个病人挂号看门诊，病人只是知道自己哪不舒服，哪里疼而已。而产品经理就像是出诊的医生，聊需求的过程就像是通过望闻问切的方式给到病人诊断的过程，即产品经理会结合自己的业务，通过逐步追问或反问需求方，弄清需求方究竟想要什么。

当你在聊需求的过程中，逐步弄清了需求方到底想要什么时，你就要去分析和判断需求的真伪性。

对于一些需求来说，能够在当下立刻判断其真伪性其实是很难的。互联网行业小步快跑就是在说需求是需要快速迭代来尝试其可行性的。那么对于一个产品经理来说，判断需求的真伪性通常是基于对业务和行业的了解程度。

笔者也是个年轻的产品经理，很多时候也叫不准主意，对行业也没有足够的前瞻性。如果你也是这样，在对接需求过程中，可以考虑不断反问自己以下几个问题：

• 需求方提出的需求到底能不能根本解决问题？
• 现有的资源是否能够支持需求落地？
• 需求落地后的预期效果是否值得调用现有资源支持？
• 需不需要提前跑些相关数据来验证需求背景？

带着怀疑视角去考虑一个需求，对着需求怀着好奇心，可能会对你判断需求的真伪有帮助。不断反问自己以上问题，当你自己想不出答案时，就要靠问来搞清问题的疑点。在逐步找到答案的过程中来判断需求的真伪性。这里不是说有其中一个问题找不到答案就确定需求是个伪需求，而是要结合已知的答案综合判断。

而所谓真需求简单来说便是有理有据，即该需求是可实现的，且如果实现了该需求，的确能解决他们想解决的问题，且符合自身业务的当下节奏。

能判断对接需求的真伪性，便是产品经理在对接需求的过程中能体现出的价值之一。

在对接需求过程中，随着需求方将需求描述的越来越具体，产品经理能在结合自身业务的前提下，尝试寻找能够解决需求方问题的更优解，便是产品经理在此过程中体现出的价值之二，这也就是产品经理所谓的灵性，也是为什么要产品经理去对接需求的原因之一。

不光是从产品功能设计角度寻找更优解，当你弄清了需求方描述的需求后，如果你对业务足够了解，心理应该也有了需求实现的技术方案。可以不用弄清开发细节，但数据的流转流向，从哪生成这些应该在心里已经有了些答案。那么结合当下技术资源以及现有需求优先级排期，是否有更好的方案解决需求方的问题，是否可以利用现有的功能用换汤不换药的方式实现，作为产品经理，也要具备以上能力。

综上，产品经理作为一个六边形战士，在对接需求的过程中也要能够发挥自己的价值。你接下了一个需求，意味着你项目组的同仁们需要花时间来帮你达成目标。同理，将需求方挡回去也不是图省事儿，毕竟产品经理要对业务负责，如果需求真的是对业务发展有利，那咱们还是要支持的。