编辑导语：区别于互联网企业，在传统企业里，产品经理身处的环境、肩负的岗位职责、拥有的能力权限等方面可能会有许多不同，比如，传统企业里的产品经理可能会失去对需求的话语权。此时，产品经理要如何应对这种情况呢？也许需求共研是一个不错的选择。本文作者就对需求共研这一问题做了解答，一起来看一下。

01

产品经理进入传统企业后不再是需求的源头，失去了对需求的话语权。但是作为需求源头的业务人员，又因为多种原因并不擅长互联网产品需求的控制。想要做好科技对业务的引领与支撑，业技融合迫在眉睫。在当前局面之下，跨界进入传统企业的产品经理与业务人员进行需求共研，是一个不可多得的策略。

需求共研，是由业务人员提出业务目标和需求方向、由产品经理根据业务目标完成产品需求的梳理与输出、然后再由业务人员进行确认的过程。

在这个过程中，产品经理与业务人员需要合理分工、紧密合作，在共同目标的指引下，发挥各自擅长的知识与技能，互通有无、互为表里。

在需求共研中，产品经理的主要任务是：对需求的引导、转化、表达。

对业务部门需求的引导主要表现在：“比用户更懂用户”。产品经理在与业务需求共研时，不妨借用互联网的用户思维，把业务人员看作产品经理的“用户”，产品经理像对待用户一样对待业务人员。

我们常说，用户并不知道自己想要什么，产品经理是比用户更懂用户的人。

当然，产品经理要做到比用户更了解用户的前提是：基于大量的用户研究、洞察用户、理解用户。只有真正做到了比用户更了解他自己，知道他想要什么、不想要什么，才能真正谈得上对用户的引导。

产品经理如何做到对业务的引导呢？实际上产品经理不可能比业务人员更懂业务、更懂业务目标、更懂业务目标的分解和各类手段的效率（至少短时间内达不到），在这种情况下想要实现对业务的引导似乎有点天方夜谭、不自量力，怕人家笑话外行指导内行，也担心业务人员怎么可能接受。

但产品经理对业务进行引导，实际上并不是一件很难的事情，经验丰富的产品经理很容易就能做到。这是因为：很多时候传统企业内的互联网产品是横向的，跨业务线、跨业务部门，这非常常见。

而业务人员对于支撑业务发展的互联网产品的了解其实也很受限，他们缺乏对互联网产品/平台的全面了解，只熟悉自己业务范围内的部分，并不知道产品/平台新增了哪些能力可供他们使用。另外一方面，他们对于业界新技术的应用也往往不敏感，对于已有技术可适用的业务场景常常也缺乏感知。而这些，当然是产品经理引导业务的重要法宝。

向业务部门引导需求，产品经理不妨借用互联网公司用户访谈、用户调研的理论方法，只是应用的对象不同而已。产品经理一定要重点关注业务人员对于业务目标和业务场景的描述，确保自己在这一点上理解到位了，否则引导业务便无从谈起，只会越引导越偏离，让业务人员觉得你似乎什么都不懂。

在这一点上，产品经理有必要拿出苏格拉底“打破砂锅问到底”的精神，对业务有个全方位的了解。

你可能担心业务人员会不会不耐烦，当然，非常常见，所以产品经理需要采取迂回策略，先表现出对业务人员提的内容全盘接受的态度，然后以学习的态度和更好地帮他实现他想要的为目标，来发出你的疑问，这时业务人员常常非常乐意一一回答。

切忌一上来就问个不休，给业务人员一种“检验其需求、评判其质量、评头论足”的感受。

在了解了业务相关背景后，产品经理基于对互联网产品/平台的信息优势（这要求产品经理平时要多了解公司内的各种互联网产品）和自己的专业优势，对业务人员进行引导。其实业务人员并不能算懂互联网产品，他们往往是使用者，他们提出的需求也基本是基于自己的使用而提出。

而使用和研究显然是两码事，使用最多算达人，而研究则意味着吃饭的看家本领。因此，产品经理在需求引导方面能发挥巨大的价值。

在对业务人员进行引导时，你会发现：

一个专业用语，就能让业务人员惊呼“对对对，就是想说这个！我不知道该用什么词，你竟然帮我说出来了！”。

一个移花接木（互联网产品/平台已经具备的别的业务模块的功能，同样适用于当前业务需求），就能让业务人员感叹“真是太好了！我们都可以直接拿来用了，我们都不知道！”。

一个新方式新手段，就能让业务人员兴奋起来“还能这样？！这能实现吗？能实现的话请务必帮我们做上！”。

一个补充扩展，就能让业务人员点赞“对对对，应该这样做，更好更完善了，还真是，要不然到时候我们肯定抓瞎！”。

类似情景，很多很多……

所有这些，都足以让业务人员不无感激地说：“遇见你真是太好了！”。产品经理做到如此，相信都会让业务人员都会有一种如沐春风般的畅然吧！

其实本来，产品经理就是业务人员很好的帮手，只是业务人员并不了解这一点，需要产品经理主动作为，让业务人员了解并亲身感受到。

产品经理在对业务进行引导时，有一点需要稍加注意：业务人员和产品经理的专业背景和知识结构不同，在产品经理通过自己的梳理把想法清晰明确地表达给业务人员时，业务人员可能并不能完全理解，从而没有在脑海中激起与产品经理相同的画面、无法共舞。

这时，一份简单的手绘稿可以简洁直观地表达你的想法，让业务人员能够快速了解你的意思，很好地解决专业不一致这个问题。

02

有人说，在传统企业里对业务引导需求就像做生意，不断地向业务部门宣讲自己的产品/平台都具有哪些能力，可以帮助他们干些什么，对他们的业务形成怎样的支撑，吸引他们使用和进一步提出新的需求，从而不断完善升级自己的产品/平台。

还真别说，这种说法还真会让产品经理有一种形同此景之感，而且这听起来跟“把业务当做产品经理的用户”还很匹配，但这样的思路是正确的吗？

当然不是，很明显这是一种站在自我角度、基于自身利益而把产品技术与业务割裂来看的一种看法与判断。显然，这不符合传统企业数字化转型的总体目标和要义。产品经理虽然也不是完全的大公无私之人，但产品经理在考虑问题时，还是不应该以这样的思路出发，影响了自己看问题的高度与角度。

对业务部门需求的转化主要表现在：给出完整的产品方案。业务人员提出的需求并不包含产品方案，产品方案在传统企业中是缺失的。在产品经理与业务需求共研时，完成了对业务的引导以后，在转化需求时，需要给出针对业务需求落地在产品/平台上的具体而完整的产品方案。

对业务部门需求的转化主要体现在对需求的转化、优化、剔除、新增、整理、拆分、重述等内容上。在这个过程中，包含了一系列的增删改查操作。

① 对需求的转化，是对需求中合理的部分，产品经理可直接转化为产品/平台上对应的功能点。

② 对需求的优化，主要是对需求中需求目的合理但需求实现方式不合理的部分进行优化，给出更优、更便捷、更有效的实现方式。

③ 对需求的剔除，主要是对需求中明显不合理的部分、对需求中无实际业务意义的部分、对识别出的伪需求部分、对需求中已经存在对应的功能可直接复用的部分等进行剔除，或引导到合理的需求。

④ 对需求的新增，主要是对有些没有提及到但与本次需求相关度很高且具有很大价值的需求，产品经理经业务部门同意后新增补充进来。

⑤ 对需求的整理，主要是业务人员对业务结构了然于胸，但却不知该如何转化成互联网产品的需求结构，产品经理可给出具体而清晰的建议，帮助业务人员调整。

⑥ 对需求的拆分，主要是业务部门提的需求往往是按照瀑布式研发模式而提出的，是一份大而全的需求，产品经理需要对需求进行合理的拆分，然后对应到不同的迭代周期，并且说服业务部门接受这样的方式。说服工作一般不难，业务部门常常乐于接受，毕竟他们也想早日看到产品上线，早日向领导汇报。

⑦ 对需求的重述，主要是业务人员不擅长需求表述，他们使用的常常是业务上的语言，而不太懂该如何表述成产品上的语言，不知如何表达简洁有效，产品经理可对业务部门的需求提出表述上的建议，方便阅读者理解。

在做了所有这些工作以后，产品经理基于对需求的全面分析与梳理，需要给出合理而完整的产品方案，这才是转化需求的终点。

在整个需求转化过程中，虽然产品经理不是需求的最初提出者，但需求的转化这项工作对产品经理的要求甚至比自己提出需求还要高！这种难度，就像是师傅指导一个新人完成一项工作远远比自己动手要费劲得多。自己可能三下五除二很快就完成了，但指导一个新人需要不断引导、不断纠正，需要足够的耐心、包容心和良好的心态。

同时，产品经理本身也还需要迅速学习、吸收业务方面的新知识，跨专业理解业务人员的意图。而业务人员的思路往往并不清晰，对互联网产品的需求表达也经常混乱不堪，描述经常只言片语，常常会另产品经理感觉不知所云，只能靠猜测和提问来弄清楚他们到底想要什么。

除此以外，业务人员经常还有一个不太好的习惯或者说还不太知道该如何与产品经理合作而导致的行为方式，也增加了沟通的难度，那就是：业务人员常常认为自己对需求、对互联网产品是懂的，所以经常一上来就直接表达想要什么，滔滔不绝地描述方案，而产品经理经常发现实际上这个方案并不适用。

不表达目的而直接描述方案，会给产品经理理解业务带来一定的困难，产品经理经常需要引导、提问、反复确认等才能挖掘出其背后的意图。在这个过程中，业务人员还非常容易表现出不理解、不耐烦、嫌弃等情绪，非常考验产品经理的理解力、共情能力、沟通技巧、场控能力。

实际上，面对产品经理，业务人员只需要表达出自己的业务目标和需求方向即可，产品经理自然会给出最合适的实现方式和完整的产品方案。

对业务部门需求的表达主要表现在：以产品原型形式直观而形象地表达需求。这里不做赘述。

需求共研so easy？更具挑战！

不用自己调研用户、不用自己输出创意与想法、也不再考验产品经理的决策能力，只是对业务人员输出的需求再加工、再整理、再表达，需求共研对于产品经理来说也太简单了吧！

简单吗？可能对于需求方面的要求确实降低了不少，似乎只考验了产品经理的基本功，但实际上在临场应变能力方面对产品经理提出了更高的要求、更高的挑战。

挑战之一：面对公司内各种各样、纷繁复杂的业务与互联网产品，产品经理需要具备快速学习与理解能力。

产品经理与业务部门需求共研的对象涉及多个业务条线，如果所在的产品/平台是全公司级的基础产品/平台，那么可能会涉及公司内所有的业务条线。产品经理本不具备传统企业所经营业务的业务知识，公司也不可能允许产品经理从头开始、系统性地学习一遍再去开展工作，而是要求产品经理直接上手。

这就要求产品经理具备快速的学习与理解能力，迅速理清公司内业务条线分布、各业务条线的业务特点、当前面临的主要问题、当前阶段的主要目标、竞争对手的状况等。

这些都需要产品经理自己整理与梳理，一般情况下公司内没有现成的资料可供参考，更为常见的情况是这些资料分布在多个同事的手里，产品经理需要自己找到并梳理，让产品经理犯难的是无法获知资料到底有多少、无法明确知识的范围与边界。

业务知识是一方面，互联网产品是另外一方面。不了解业务产品经理寸步难行，不了解公司的互联网产品/平台同样会让产品经理无法开口、参与讨论。不过产品经理对于互联网产品的快速了解不是难事，但本项基础性的工作无法跳过，而且这才是产品经理与业务需求共研的底气和根本所在。

相对于业务知识的粗略了解，对互联网产品的了解要更深、更细，否则与业务人员讨论时常常无法回答，还如何谈与其需求共研呢？

从互联网产品经理踏入传统企业的那一刻起，就意味着要准备好快速的学习和理解能力，否则其工作的展开将面临着巨大的困难。

挑战之二：面对公司内各个部门的立场与利益，产品经理需要从蛛丝马迹中观察并找到问题的症结所在。

公司内各个部门之间有利益冲突是常见的事情，传统企业当然也不例外，甚至更甚。产品经理与业务需求共研，常常与多个业务部门打交道，也时常面临各个部门不同的、甚至相冲突的业务诉求。对于各部门的立场与利益，显然没有人会明面上说，都在背地里较劲。

这些对于公司里的老人而言可能是人尽皆知的秘密，而对于不明就里的产品经理来说却会造成工作上的一些困扰，产品经理需要从蛛丝马迹中观察到这些暗地里的信息，找到问题的症结所在，并在工作中尽其所能地进行平衡（其实主要是汇报领导由其平衡，哈哈），以便项目能顺利推动下去。

在部门之间复杂的利益关系之下游走，不是一件容易的事情。一不小心得罪了某个部门的同事和领导，可能辛苦半天不但没带来一丝丝鼓励与赞扬，反而会引来对方背地里对你的控诉，而你还全然不知。

互联网公司虽然也有部门之间的不同立场、利益冲突等情况，但相对来说，人际关系还是更为单纯一些。产品经理在与业务需求共研时，在这一点上不说做到左右逢源，但更为小心、谨慎一些总是没错的。

挑战之三：面对公司内不同的团队与环境，产品经理需要快速融入。

产品经理与业务部门需求共研，意味着需要跨部门开展工作。产品经理需要在一个不太熟悉的环境，快速融入进去。产品经理需要面对不那么熟悉的同事、在原本就运转良好的组织中、在极短的时间内快速找到自己的定位、发挥出自己的价值来证明自己。

有三种情况，压力程度及压力点各不相同。

第一种情况是事先需求共研的目标已明确，只是需求、方案尚待整理与输出。这种情况对于产品经理来说难度不大，产品经理与业务人员各自发挥所长，按照目标完成任务即可。如果在计划之外，产品经理能提出一两个小亮点，可能会让业务部门对你更为赞赏有加。

第二种情况是产品经理参与的时间更早，只有个大方向和概念，目标还尚未明确，那么这时对产品经理是个考验。考验点是产品经理需要更深入地参与到业务层面的目标制定和需求方向讨论。但此时，产品经理常常还尚不具备完善的业务知识，只能硬着头皮参与讨论。

很多产品经理面临这种情况是害怕与担心，既想发表一些自己的看法体现自己的价值，又担心自己的看法犯了一些基本的错误显示出自己的外行。但实际上，这对于产品经理来说是一件非常好的事情，相比于第一种情况会给产品经理带来更大的成长。我们需要做的是放松心态，在有把握时抓住机会、提出建议。

其实想想，对方也并没有期望不太懂业务的你能提出多么有价值的建议，也只是希望你能发挥所长。但正因为产品经理的思维不受限，有时产品经理反而能找到业务人员在思维定式下想不到的一些问题和角度。除此以外，产品经理也可以利用成熟的互联网思路与打法，给业务人员提供建议。

第三种情况是产品经理暂时借用到业务部门，更深入地参与到业务部门日常工作中。这种情况最大的难点在于找到自己的定位，也就是找到能发挥自己价值的事情去完成。

刚进入时，你会发现事情都已经被分配，产品经理要如何切入呢？可以从一些辅助性的工作开始，以了解部门的情况为目标。但产品经理心中始终要明确的是：辅助性的工作只是暂时，寻找到合适的主导性工作才是重中之重。这既要看机会，也要看智慧。

这些挑战，显然不同于互联网公司对于产品经理有更高专业性的要求，而是从更多角度去要求产品经理有更强的适应性，适应传统企业的业务、环境、文化、具体事项等。这些更多元化的能力在互联网公司也会用到，只是没有传统企业中这么重要和迫切。

03

那么产品经理与业务需求共研，主要采取什么样的形式和方式呢？

需求共研做得好，将大大简化业务部门需求方面的工作。业务部门只需要带着业务部门和需求创意来即可，不必等深思熟虑甚至完成需求文档的撰写再提出。

业务部门带来需求创意，产品经理参与深度讨论。这不仅使产品经理对关键点及细节的把握更加准确，而且在讨论过程中还能帮助业务部门将需求梳理清晰。在讨论的同时，双方就需求框架、需求细节等内容一一达成一致意见，完成需求的碰撞与完整落地。

有一件事产品经理最好与业务人员提前达成一致：需求以产品原型为准。这样可以避免需求还需要以Word形式再撰写一遍，同时也避免了Word和产品原型的同步修改与反复确认。

产品经理在与业务人员完成需求讨论后开始产品原型的制作。产品原型完成后发送给业务部门进行确认，针对反馈意见产品经理对产品原型进行修改完善，直至双方达成一致。一般来讲，这个过程对于经验丰富的产品经理来说，经历一至两轮修改即可定稿。

总结起来，需求共研具体操作方式即：一次会面集中讨论、遗漏细节在线沟通、产品原型形象展现、快速反馈早日确认。

需求共研，好处多多。

业务人员具有业务专业性，产品经理擅长需求梳理与产品设计。相对于传统的由业务部门输出需求Word文档，需求共研会带来很多好处。需求共研的好处不仅表现在大方向更有利于业技融合的实践，也表现在为每日具体的工作中带来便利与效率的提升。

① 提高需求掌握度：产品团队参与需求讨论，对需求理解更加深刻，更容易快速掌握关键点，也不必再逐字逐句读需求文档。

② 提供专业意见：产品经理具有丰富经验，可以提供专业建议，使需求更加合理化，提升需求质量与有效性。

③ 提升需求细化程度：引导业务需求不断细化，将细节问题在需求阶段即得到解决，提升开发环节效率。

④ 消除等待时间：业务部门产生需求创意后即可开始需求沟通，产品先行的策略消除了需求撰写期间的等待时间。

⑤ 提高需求确认和迭代速度：产品原型将需求可视化，所见即所得，更加形象地展现需求，便于业务部门逐层汇报，加快业务部门需求确认和迭代速度。

⑥ 以用户为中心：产品经理可以更单纯彻底地站在用户角度考虑问题，产生更好方案。

⑦ 提升用户体验：产品经理更了解设计原则，依据设计规范完成设计，可有效提升用户体验。

⑧ 便于技术团队评估：产品原型可以方便开发人员理解和拆分需求，利于其对项目复杂度和工期作出更加快速地作出评估，同时也大大提升了评估的准确性。

⑨ 提升研发效率：产品经理参与需求共研可使需求研制工作提前一个迭代。在开发团队集中精力开展本迭代编码工作时，产品经理即可与业务部门开展下一个迭代的需求研制，而业务部门不必等到开发人员完成本迭代编码工作后才有时间与其讨论需求，解放了开发人员的时间与精力，为实际的编码工作赢得了宝贵的时间。

专业的人干专业的事儿，有利于传统企业形成与互联网公司类似的双迭代研发机制。

小结：

产品经理与业务需求共研，是当前传统企业实现数字化转型的有效策略与手段。在这个过程中，产品经理在体现自己的价值的同时，一定要借此机会不断积累业务知识，减少对业务人员的依赖，逐渐撕去“不懂业务”的标签，成为名副其实的跨界人才。

作者：厚厚，多年互联网和传统企业的跨界产品经理；微信公众号：厚厚的语和文

本文由 @厚厚 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议