哈哈哈，这个问题之前好像见过，附赠高分回答：

需求需要优先级排序和进行筛选。而B端需求工作，业务驱动需求思想是核心。在和客户进行沟通时，怎么处理客户的需求呢？

我想可以通过以下三步进行解决：

1. 明确用户的问题是什么？（用户需求）

• 这个需求是真实需求吗？
• 用户想解决的问题是什么？
• 这个需求有多少人需要？使用的频率是什么？
• 不做的话影响多少用户？（痛点的价值）

2. 明确产品的定位（产品需求）

• 产品的核心定位是什么？
• 做这个需求需要多少投入？
• 这个需求做了能够得到多少收入？

3. 需求优先级排序

对你的需求进行优先级排序

• 利用kano模型

#产品经理挑战赛# day2

总的来说说没有几个方面，但是要做好是很难的。需要的理论知识、经验和沟通协调能力要求都比较高。

老生常谈的调研，在接到需求之后，实际工作已经在调研之前开始了。在去见客户之前，产品经理需要做很多准备工作，对业务的基本了解，对客户情况的了解，可能使用场景和可能的痛点。

注意，我说的是“可能”。

在调研之前我们是不知道具体场景和痛点的。我们只是通过自己的经验和对这个业务的了解做出的猜测，所以在实际调研之前，对自己做出的猜测都要保持怀疑，不要被经验蒙住了眼睛。

但也不要因此而放弃多个可能性的猜测，因为调研本来就是占用客户的时间，没有人可以保证你的客户是个有耐心的人，所以我们要准备好问题和逻辑，把客户想到的和想不到的问题都问出来，这样既能节约时间，也能显示我们的专业度，让客户可以放心。

在调研之后就是开始了方案的设计了。准备的版本迭代方案，方案价值和成本，这都是我们的基本工作能力。B端产品经理需要注意的是，和C端产品不同，我们的方案很多体验只能由客户来转述，所以B端产品经理一定要和客户保持高频率的沟通，一是为了对接好需求，确定下来。二是及时询问用户体验，才好及时做出更改。

当然，这中间一定会出现很多问题。常见的比如对交付时间的争执，客户当然希望越快越好，但是我们要对自己的研发资源和排期要做到心里有数，无论客户由什么要求，一定要耐心沟通，千万不要当杠精。只要好好和客户沟通，聪明地利用手里的资源，想必能做出一个好工作。

当然，主要原因还是不要和钱过不去。

#产品经理挑战赛# day7

B端涉及的需求往往在客户看来描述的很清晰，你却听的云里雾里的。

因此，对于B端需求，我们首先了解业务背景，产品需要了解需求背后的业务，以及业务对应的工作场景，使得我们能听懂用户的需求。例如，用户要实现货物从库位出库到集货位记录生成功能。其实就是从仓库里面规划好的放置物品的区域把东西搬到卡车停放的库门前的几个临时停放位的功能，将库位编码与集货位编码进行记录即可。

了解业务背景后，你就要判断需求可行性了，对于不合理需求直接驳回，对于合理的需求纳入需求池中。

听懂客户需求后，就要考虑解决方案的问题了，围绕客户的工作场景思考解决方案。对于记录库位编码和对应的集货位编码的需求。经过了解，在实际操作用，有时候不是一条条去填写表单，而是Excel批量去导入的。因此我们既要实现表单功能便于客户一条条提交记录，也要提供Excel上传功能来实现批量记录导入功能。

最后，你需要对你梳理的需求优先级进行排序。将影响业务流程的需求优先级提高，对于业务流程影响不大的需求优先级降低，最后再梳理一遍无关紧要的需求，如果不需要就剔除。

#产品经理挑战赛# day4

        我觉得B端产品经理对接需求分为四个阶段：对接前准备——需求对接——需求分析——交流确认。

     （1）对接前准备

B端产品和C端产品存在差异的地方在于，C端产品面向的是个体，B端产品面向的是组织。组织就会有不同的角色，包括决策者和执行者。

         首先调研之前要确定调研对象，同一业务，不同层级的人员都要进行交流了解，决策者和执行者往往需求是存在差异的，只有充分调研后，才能全面了解用户需求。

         其次针对不同调研对象制定不同的调研方案。我一般采用的方式是先获取岗位职责手册，然后进行分析，初步了解他们做什么后，对不清楚的点进行标注，以此为基础制定调研提纲。

   （2）需求对接

        需求对接我一般采用用户访谈和跟班调研两种方式。两种方式适用方式不一样。

       用户访谈适合那种在办公室进行的业务，办公室工作比较杂，而需要调研的业务只是繁杂工作的一部分，这种采用户访谈的方式进行聚焦效率更高。

      跟班调研适合那种单一业务，从工作开始到工作结束都进行的同一个业务，这种采用跟班调研效率更高，效果更好。

    （3)需求分析

        这个阶段需要对调研的内容进行总结分析，绘制业务流程图、需求点挖掘。输出需求分析报告。

    （4）交流确认

前一阶段绘制的流程图等一般还有一些细节不清楚，该阶段要拿着编写的需求分析报告，与调研对象进行确认，该阶段时已经对业务有了一个相对深入的了解，要尽量把细节了解清楚。为后续功能规划打好基础。

#产品经理挑战赛# day4

1、客户提报的都要做收集，客户提出的都要去做分析，拆分出来正负偏离。产品经理有责任来收集客户需求，进行定量的筛选后，纳入需求池，做产品规划。

2、当前产品线的规划，在哪个阶段可以融合客户的需求，哪些是客户有需求，但自己没有考虑到规划线上得。取长补短，需要根据不断的发展，修正前进的路线，增减内容，来更好的完善自身的产品线，提升产品质量。

作为B端产品，一定要跨越一个层级来看待产品，不要单纯纠结于一个功能的细节，比如匿名发布，只要有这个功能就行，还是匿名发布随机匹配一个名字？定量的功能要考虑，大众化，大众场景，大众应用，他不单纯取决于一个人（当然你的领导和老板还是说了绝对算的），也不单纯取决于某一类付费群体，一定是要考虑共性的需求。

至于使用的方法，下面已经有很多人做了很多的说明，我额外加一点：做个需求池，要经常出去见见用户，听一下销售的诉苦，有哪些是大家经常提报的，有哪些是特殊定制化的，做个定义区分。

最后就是做一点把控：这个定制化的需求，我们是不是这次要开发，要提前开发，这都要取决于你多余产品线的把控。能否把这些定制化的需求，通过其他的功能转变为通用的需求，并且可以拉长战线来实现。

（在多一句：你是否有能力做出来，一个惊艳的需求，可以引发大众的共鸣，引发潮流）

T0nyKK已经回答的很全面了，我做一些细节的补充

提前准备好具体需调研的重要事项和核心内容

找准需求对接人（包括：使用对象的管理决策者和任务执行者）约定好调研时间，并制定调研计划

同需求对接人提前约定调研时间，并告知需调研的大概事项，便于对接人提前有所准备

若存在多个部门对接人，还需根据约定结果制定好调研计划

简单介绍本次调研的目的、并重述本次需调研的重要事项和核心内容

聆听对接人描述当前的业务状况（现在的做法）、存在的问题、和期待的结果，并做好关键点记录

针对需求对接人描述不清晰，或存在歧义的部分进行反复确认（确认过程只能询问，不能反馈自认为的结果，否则容易误导他们导致需求发生偏差）

沟通中还需深入思考，对可能存在的场景遗漏及时提醒，引导他们进行补充

必须确保沟通过程中，双方始终停留在业务场景的角度，不能逾越至系统实现的角度（有些需求对接人喜欢直接站在系统角度来沟通，这里要注意做好引导）

同需求对接人索要当前业务执行过程中的相关资料（如业务表单、数据表格等）

在设定边界内可能发生的全部业务场景（确保需求全面）

各项业务启动的前置条件（确保流程清晰）

各项业务开展过程中的执行人员和作业要求（确保管理规范）

各业务环节可能发生的异常及异常处理方式（确保业务闭环）

当前存在的痛点和期望解决的核心问题（确保定位精准）

#产品经理挑战赛# day3

在跟B端客户的需求调研中，可以分解成3个步骤：调研准备、调研执行、调研总结。

1、调研准备

调研前的准备工作包含了明确调研目标、确认调研方法、选取调研对象、整理调研大纲等。

1）明确调研目标

在项目执行过程中会出现多次反复的调研，项目不同阶段的调研目标是不一样的。

一般来说，项目初期的调研目标是明确项目背景、目标、目的、业务流程等；项目推进阶段会沟通具体的业务场景。如业务范围、业务场景、业务流程。

2）确认调研方法

我们知道了很多的调研方法，需要根据实际的情况选择恰当的方式。值得注意的是，和受访者建立良好的关系可以很好的帮助后续工作的开展。

3）选取调研对象

在资源允许的情况下，期望能够对接从领导层到执行层的所有主要干系人。当然，具体人员不是我们能确定的，但是需要拟定参与调研的角色和客户提要求。

4）整理调研大纲

提前了解客户基本信息，能够帮助我们设置调研大纲，包含调研思路和问题。需提前了解项目相关信息，整理业务场景中的问题；预设的场景会有偏差，要在调研时和客户确认。避免没有框架，造成调研不够全面。也可以准备需求调研表，便于做记录。

2、调研执行

访谈式的调研不论参与人数多少，都是通过谈话的方式来进行。在执行中掌握访谈节奏和建立访谈框架是不可缺失的。

1）掌握访谈节奏

为了保障调研质量，需要稍稍掌控谈话节奏。同时根据客户描述调整自己的框架，提前准备的框架可能存在不恰当或缺失。

2）建立访谈框架

访谈内容应从整体到细节，从抽象到具体。可以从3个层面来聊：战略、战术、执行。

• 战略：战略重要性不再赘述，调研首先明确项目在公司的战略定位和目标。项目也可能是企业战略的延伸的延伸，但是明确的定位和目标必不可少。
• 战术：较为抽象的描述业务情况，战术决定了产品形态和管理模式。产品形态即产品如何运作，针对什么大场景做什么业务。管理模式即产品的管理策略，集中管理或分权管理，各方（大角色）能够参与什么任务。

执行：下沉到业务执行层面，首先明确组织结构和角色配置，其次将角色代入到业务流程中，关注各环节各角色的任务来源，以及执行和交接的操作。

3、调研总结

调研结束后一定需要输出完整的调研报告，表现形式不重要，目的在于调研情况的梳理和遗漏点的查找。

1）现状梳理

可以按照调研的层次，从战略、战术、执行不同层面进行梳理，将内容整理清楚即可。

2）问题总结

深入到具体业务流程，梳理当前整体及各环节存在的问题，并关注问题的影响面、紧急重要程度。

3）总结报告

输出报告后除了发送给内部相关人，也要同步给客户。注意和客户确认报告内容的准确性，如业务理解是否有偏差、问题梳理是否全面、问题优先级是否准确（可能因不同角色的关注点不同而出现偏差）等。

4）其他补充

并不是所有问题都要通过系统来解决，注意实物流和信息流的结合。现有的业务流程也不是一成不变的，而是随着业务发展和问题解决发生对应调整，带着发展的观念看问题。

#产品经理挑战赛# Day4

对接过B端客户的需求，一定一定要我方控场，控制谈话节奏。

1.对接前的调研

B端的客户是一个群体，跟C端不一样，C端是从有到优，先给C端用户用，然后再提哪里可以做得更好，但是B端除了有之外，还需要针对他们企业本身（我们是做saas的），所以在对接前会进行基本调研。提前了解客户想要什么之外，还有预防客户在对接过程中总说的，谁谁谁的产品也这样，哪个产品也有这个功能，提前预估是否可行？不可行的用什么理由拒绝。

2.对接中的需求分析

对接的时候，客户除了提前提出的需求外，还会天马行空，想着自己企业有什么资源，能不能把所有资源都结合起来，这时候就要去判断客户到底想要什么？想要解决什么问题？还要在谈话中拉回来，不拉回来，可能最后的结果就是客户觉得他提的需求 ，我们都能做。务必在第一次对接中确定需要做的需求大纲，不然下次对接又开始参杂一些其他的需求进来。

3.对接后的整理

针对分析后的需求做一份需求评估表，评估人/天数，费用。第二次对接，再与客户制定需求的优先级，开发过程中的细节等。

与客户沟通，客户想要什么，俺就给你什么，客户算个蛋黄派啊？

客户觉得他提什么，你就给他什么，那你算个蛋黄派啊？

太笼统了，麻烦讲清楚你的问题以及具体场景。

如果连问题都无法明确的表述清楚的话，那你也可以不用考虑和客户对接了！！！！