作为一名产品经理，你有经历过业务方提出一些天马行空不切实际的需求吗？有经历过业务方需求描述不清晰、提完需求又反复修改的痛苦吗？作者在本文中结合工作中遇到的问题，提出了自己的解决办法，希望能够对你有帮助。

产品经理的工作流程的前半部分是在承接需求，这个过程里我们会遇到很多麻烦，感受很多痛点。我想就我工作里这块部分遇到的问题，浅谈一点自己的理解，并且说一下我当下的解决办法。

一、何为需求？价值几何？

（一）需求是什么？

产品经理的日常就是找需求，接需求，做需求…… 但是你有没有思考过，需求到底是个啥？

礼记里有句话说：“饮食男女，人之大欲存焉”。这句话意思是：饮食吃喝与男女情爱，是人存在的最大欲求。我们的欲望其实就是需求。

因为生活中存在太多的问题和太多不满意，我们就会产生解决问题和让自己满意的欲望，然后导致人产生各种需求。

马斯洛把人的需求分成五个层次：生理需求、安全需求、社交需求、尊重需求、自我实现需求。具体的我不再赘述，大家应该都很了解。但是不论哪个层次的需求，它们都是推动的人们各种行为的内因。

（一）价值几何？

作为产品经理，我们之所以做一个产品，肯定是为了解决某些问题，满足某些需求。需求之于产品经理，就像“汽车之于福特”。

你应该听过 “用户要一匹马，福特给了用户一辆车” 的故事，把“马”变成“野马”，这就是价值所在。

当然，我想表达的重点其实不是给了用户什么东西。其实你也可以预想一下你给了用户一头驴，一头猪之后的场景，也许现在福特就会是一个食品公司？皮革公司？重点在于发现和思考需求中的用户价值与商业价值。

二、产品经理和需求的“爱恨情仇”

我曾经听过梁宁老师的课，她认为产品经理需要有判断信息，抓住要点，整合有限资源向外输出的能力。

我是比较认同这个观点的。因为产品工作处在信息的上游，这些信息大部分都没有“降噪”，需求又多又杂。我们此时就需要拥有“判断信息，抓住要点”的能力。判断信息可以理解为是判断需求的真伪（识别需求），抓住要点可以理解为抓住当下最关键的那些需求（排列优先级）。

其实产品经理日常工作的很大一部分时间就是和需求进行无休止的“缠斗”。这些需求的来源一般是来自业务，用户，老板和产品经理本身这四个部分。在需求这一环节，我们的战略目标就是“解决”掉当前所有需求。

• 对那些伪的、无法落地的和没考虑清楚的需求，一律打入“冷宫”，什么时候想清楚了再来见“朕”。
• 对那些真的，可落地的，清晰且有价值的需求，咱们得一个也不能漏的纳入到需求池里。但是这些需求的“牌子”也得一个个翻。我们要按照优先级，给这些需求排个序。产品的项目安排（包括产品设计和研发）都按照这个顺序往下进行。

不过真实处理需求的过程中会遇到很多麻烦。需求真真假假，需求提出方还各不相同（不同的需求方沟通起来也不一样）。我们面临的困难有时候在于：不仅要搞定需求，也得搞定提需求的人。

我把产品经理处理需求的流程简单分为四步，今天我们主要讲第一步，也是非常重要的一步——承接需求。由于需求的来源很多，一文难以讲全，所以本文先讲如何承接来自业务方的需求。

产品工作简易流程图

三、如何承接业务方的需求

（一）什么是业务

公司多个部门协作（如运营/销售/市场），履行不同的职责，共同达成业务目标（比如赚一个“小目标”）。其中提出需求的部门就是业务方，他们的需求就是业务需求。

（二）产品经理对待业务需求的原则

不管做人做事，都要守住原则。基于原则做事，事情才能做的长久。对待业务需求，请记住下三点原则：

1.不要参杂私人感情，一切以业务为先。

不要因为某个需求提出者和你的关系好就做这个需求，也不要因为某个提出者和你的关系差就不做这个需求。请记住需求本身的价值是你判断的唯一标准。为了需求的一切，一切为了需求。

2.业务方尽可能多提经过一定程度思考的需求。

• 尽可能的多提出需求：《人人都是产品经理》一书中说“需求需要被尽可能多的采集”，我很认同这句话，“韩信点兵多多益善”。我们不怕接到荒谬的需求，我们怕遗漏合理的需求。如果最后大家都不提需求，最后受损的还是公司的产品和业务。
• 有一定程度思考的需求：经过思考过的需求不会不堪一击，也不会有很明显的漏洞，所以才具备被讨论的价值。我们在和业务方讨论需求的时候，也可以最大程度上聊清楚这个需求的价值。虽然我们不怕接到荒谬的需求，但是荒谬的需求会降低团队效率。

3.产品经理要对所有的需求进行深度思考。

产品经理是一个非常需要决策能力的岗位，整个职业生涯几乎都在做着决策。不经过深度思考就直接决策，就像海上的一个求生者喝海水，无异于饮鸠止渴。看起来做了很多需求，但其实对产品和业务没有帮助，反而有可能给系统增负。所以让你的思考为需求做一层过滤，于产品于业务都有益处。

（三）对接业务需求的痛点

和业务方沟通的时候，大家或多或少的都被困扰过，结合本人真实经历，我总结成以下几点：

1. 需求描述不清晰（需求描述千奇百怪，理解起来很费劲）
2. 每个需求都是重要又紧急，优先级失效（需求优先级个个P0，先做谁呢？）
3. 想到需求就提，大部分都是不经思考的伪需求（需求质量很低，来回沟通降低效率）
4. 双方沟通不顺，无法达成共识（一意孤行不听劝，双方不在同一个频道）
5. 提完需求，后期反复修改（看到我的眼神了吗？这就是之后研发想刀我的眼神）

括号里的是开玩笑，不过不好好对待需求，版本上线后，你可能面临“虽然我也不太懂，但这不是我想要的”的场景。

（四）解决痛点问题的思路

反思复盘，找到问题，根据痛点问题整理出思路：

1. 让业务方提靠谱的需求：明确标准，解决需求不靠谱的问题。 通过一套标准来帮助业务方想清楚。
2. 提升团队沟通效率：设定流程，提高沟通效率，做到信息对称。通过一套流程来降低沟通成本，增加团队协作效率。

（五）模版：业务提交需求模版

制定标准模版的意义：

1. 降低业务方提交需求的成本：我们常常会要求业务方提交的需求经过思考，可我们却从来没有告诉他们怎么思考。提供一套标准，可以理解为“思考模版”。它可以很大程度上降低业务方思考需求的难度（按照模版来提需求难度就像开卷考试），毕竟这不是他们的主要工作，我们需要提供支持让提交需求的人尽快上手。
2. 提升业务方提交的需求的质量：我们常常会要求业务方提交的需求质量高一点，信息全一点，可我们却从来没有告诉他们什么是“高质量”。我们给标准是让业务方把最开始在脑子里的需求按照“模版”进行思考的时候，能更清晰的了解自己想要什么，想要多少，需求目标等等，同时把思考结果记录下来，也可确保写作者不会少写或者乱写某些内容。
3. 最大程度确保思维的一致：我之前有篇文章写了“研发思维”和“产品思维”的区别，但其实“产品思维”和“业务思维”也有很大的不同。其实是所在的职能岗位不同，团队目标，业务流程，思维方式都不一样。每一方都是基于自己的立场去设定预期并进行沟通。很多时候你说前门楼子，他说胯骨轴子。所以让对方通过“思考模版”的洗礼，很大程度上能确保你们思考的是同一个“频道”。即使最后讨论的时候你们还是有偏差，我相信作为产品经理的你，也一定有足够的耐心和同理心去处理好这个需求。

标准模版的内容：

1.需求背景（包含三个点）

• 1.1:背景信息（什么场景下产生这个需求，以场景化，叙事的方式进行描述，最好可以加入一些数据进行支撑。）
• 1.2:目前存在的问题
• 1.3:当前方案及遇到的问题（无法满足需求的原因）

2.需求目标 （讲清楚需求的目标以及能带来的价值，对优先级的设定也有指导意义。如业务目标的达成，用户的体验，数据决策层的指导or降本增效）

3.当前业务流程（最好用流程图）

4.业务策略（如一次运营营销活动，有对应的时间段，在考虑上线时间和优先级时可作为参考）

5.预期上线时间

6.优先级（需求重要性）

可参照我写的这份例子一起查看：

其实《人人都是产品经理》一书里有一个单向需求模版，我放在下面，其实这也是一个“思考模版”。内容更多，维度也更加全面，不过我认为平时工作还是尽量简化业务方提需求的工作，“less is more”。

这套模版不是束缚，大家可以在此基础上增加更多想法，可以根据自己公司的不同情况进行修改。如果大家有更好的建议，也可以在评论区进行评论，欢迎大家探讨。

（六）一套流程：业务需求沟通流程

流程的意义：

其实大家在产品工作的时候，会接触到非常多的流程。诸如日常发布流程，紧急发布流程，需求变更流程等等。这些流程现在或多或少的帮助到了大家，随着不断完善，久而久之一套行之有效的流程就应用了起来。

但是在协作过程中，尤其是跨部门协作时，其实很少有公司有一套沟通流程，如果没有流程的话，势必出现这些问题：

1. 业务随时提需求，产品感觉时间被切割的细碎，而且事情又多又乱

常常有产品吐槽，自己的时间少，被切割的细碎，难以深度思考。往往只有晚上的时间才能安静的工作。业务方随时提需求就是其中一个因素。

2. 经常有人提需求，但是需求内容常常重复

多个部门协作，往往一个部门有多个提需求的人，同一时间段内甚至需求还有重复。这将会造成产品经理工作的极大不便。

3. 业务方常常问需求的进度

需求是否被采纳，是否进入版本规划，是否有上线时间。这些信息都要和业务方进行同步，不然会造成信息不对称和信任缺失，如果不重视甚至会影响团队协作。

流程内容：

流程分两种，一个是常规需求，一个是紧急需求。

接业务需求流程（常规需求）：

1. 同一部门固定人员提需求

固定一个需求输出口，其实对于产品经理工作而言，好处很大。第一：先部门内部达成共识，再外部输出给产品经理。可以降低沟通成本，减少无效沟通。第二：避免因为人员的需求描述和要求的标准不一致，导致需求的对接和落地出问题。

2. 产品经理固定时间接需求（需求讨论会议）

固定时间（一个周期）的有组织的会议，取代随时随地单点沟通，提升沟通效率。在会议上进行需求讨论。

产品经理需要准备这个周期内根据大家提交的业务需求模版整理的文档。对应的参与人员要有业务方和产品。

3. 产品经理固定时间反馈需求

这个反馈需求是必不可少的，可以放在需求讨论会后的几天或者一周内。方式的话有多种可供选择，如消息，邮件，亦或者是下一次的需求讨论会上。

但是需要讲清楚需求处在哪个阶段。是否进入开发队列，如果没进入则讲清楚原因，如果进入队列还需要讲清楚需求的排期和进度。此时对方有问题就可以单点进行沟通解决。

接业务需求流程（紧急需求）

一些非常紧急的需求，可能等不到常规需求设定的时间，就需要走另外一套流程。不过这套流程我建议少用，尽量保证常规流程的权威性。而且这种插队需求也会影响原本的产品开发流程（研发大哥们可能会不开心）。虽然这种需求不可能完全避免，但是提高提这种需求的成本，能让需求方更谨慎的动用这套流程。

处理方式：由需求方的固定需求对接人联系部门直属leader，再由有需求方直属leader联系产品部leader，最后决策这个需求的优先级。

当然，需求还是要符合上文中所说的提交标准的。一个再紧急的需求，也需要经过谨慎的思考。

就像一个患者肚子疼，来到医院和医生说快帮我把阑尾给切了，没有任何一个医生会不做检查就动手术。我给大家分享一句话：“急事缓办，缓事急办”，希望和大家共勉。

最后说一下推动流程中的关键节点：

1. 首次共识流程：重点是流程的“统一”，不是一定要用“某种格式”。大家的共识是最重要的。不要固执己见的一定要某套流程，不同公司适用的场景也不一样，所以作为产品经理要努力促进共识的产生。而且促进共识的产生也能最大程度确保流程执行时，大家都可以遵守。

2. 流程应用过程中产生问题：我们知道各种模板，规范和流程并不是与生俱来的，这些都是在需要的时候自然产生，和产品一样，从简单到全面。大家在过程里不断完善。此时无需怀疑流程本身，根据反馈，具体分析后再迭代应用即可。

四、写在最后

回想过去，在我入行最初的那一年，因为需求发生了太多的事情。

我有享受过需求满足后各方的反馈，感觉世界因此变得更好。我也有讨厌过那些彻夜难眠的思考需求的夜晚，恨方案一次次的被否定，陷入自我怀疑里。我相信大部分产品经理都曾经历过或者正在经历这个过程。

我现在回首再看过去的经历，其实感慨万千。走了太多弯路也踩过很多坑，抱着为了让后来的朋友不再受困于当初我的窘境的想法，我写下这篇文章，希望对你有所帮助。

同时也给大家分享几点心得：

1. 我们产品经理的工作就是满足需求。当自己遇到困境的时候，也要学会运用产品思维去思考自己面临的问题，然后设法满足这个需求。

比如在接业务需求这个场景中，既有痛点又高频出现，就可以尝试一些新的解决方案。我们产品经理有一项很重要的技能就是产品设计，设计是什么？维克托·帕巴奈克给出的回答是：为赋予有意义的秩序，付出有意识或直觉的努力。

设计产品是这样，设计规则也是这样，我们都要进行思考后赋予秩序，然后让秩序提高我们效率。

2. 我们只能尽人事，即使你提前设定了完美的流程和方案，但是也有可能出现问题。要学会在反馈中前行，事物的发展都是螺旋上升的。建立认知，然后去实践中获得反馈，最后重建认知。

希望大家都能在产品工作中完成自我实现。

最后，大家一起加油！