调研准备

找到业务代表，了解原始需求信息，梳理提炼关键信息。

• 业务方
• 业务方代表
• 产品背景
• 业务痛点
• 业务需求（粗颗粒度）
• 领导要求
• 时间要求
• 预算

【PS：原始需求】

设定调研目标

B端产品调研结束后需要至少达成以下几个目标
1）价值共识
价值共识是指产品团队与业务方需要就产品价值形成共识，包括产品定位、产品目标、产品要解决的核心问题及衡量产品价值是否达成的标准。原则上是不允许变动的。
【PS：会议两类型，共创，共识】
2）需求共识
需求共识是指产品团队与业务方需要对产品需求形成初步共识，包括需求范围、需求场景、用户角色及需求的优先级。
在调研过程中，我们需要引导业务方把需求思考得更细致些，这样不仅可以帮助业务方厘清思路，让我们更好地理解需求，也能避免业务方提一些想当然的需求，但在调研过程中不要讨论到方案层面，这是调研结束后要做的事。也需要制定好需求变更机制，
【PS：需求与方案的区分】
3）理解共识
理解共识是指产品团队与业务方需要对涉及的问题、知识、概念形成理解共识。
在了解了原始信息后，我们心中自然会产生各种各样的疑问，为了消除这些疑问，我们需要提前将这些疑问整理出来，在调研过程中寻找答案。
达成共识是一个双向的过程，产品团队不仅要理解业务方的需求，还要向业务方说明与产品相关的概念、做法，以避免日后产生误会。

规范调研准则/原则

调研准则是指在调研过程中产品团队及业务代表都需要遵守的要求。为了调研过程稳定有序地进行，我们需要提前规范双方的行为。
全程参与：在调研过程中，无论调研对象是谁，业务代表都要与产品团队一起，全程参与调研过程，除非有极特殊情况，否则不应缺席任何一场调研会，这样做的好处有以下几点。

• 信息同步。合作最重要的基础之一是信息及时有效地同步，业务代表虽然是业务领域中的资深人员，但其不可能了解每个人的想法，所以他们也需要作为调研方参与调研过程。
• 辅助调研过程。调研虽然是以产品团队为主导，但业务代表可以起到很好的补充作用，如做一些破冰说明，背景介绍等。
• 为调研对象提供心理支持。每个调研对象的性格不同，有的比较内敛，当有一个或多个他们熟悉的人在身边时，有助于缓解他们的心理压力。
• 调研结束的空档可以及时进行讨论沟通，对调研内容进行回顾总结。

相互尊重：调研阶段是产品团队与业务方合作的初期，双方对彼此都不太了解，做事方式也千差万别，难免会出现相互不认同的时候，很多地方都需要磨合，这时双方应该秉持相互尊重、相互信任的原则，尊重彼此的专业性，相信双方都是为了同一个目标而努力，这样才能在有矛盾时和平解决。
聚焦问题：调研中最浪费时间的地方就是问题过度发散，这几乎在每一场调研会中都会遇到，所以我们要始终聚焦调研问题，当发现讨论过度发散时，要及时打断，用新的问题进行引导，让大家回到焦点问题的讨论上来。
开放包容：既然是调研，就应该允许各种声音出现。无论是积极的还是消极的、主观的还是客观的、偏激的还是温和的观点，都应该鼓励大家表达出来。

快速掌握业务知识

要想顺利地进行业务调研，B端产品经理需要快速学习一些基础的业务知识，然后在做中学，逐渐深入。
业务知识包括业务概念和业务规则两大类。

业务概念 业务概念是业务中涉及各个名词的含义，如HR、VP等人力资源领域中特定的术语。业务所处行业发展越成熟，业务概念就越规范，歧义也越小。必要时直接向业务方请教。 业务规则 业务规则既有行业通用规则，又有组织自定义的特殊规则。

业务概念与业务规则就好像珍珠与线的关系，即业务概念是一颗颗散落的珍珠，业务规则是将这些珍珠串起来的线。
技巧方法：
1.信息爆炸的时代，找业务方提供一些他们平时觉得比较好的学习渠道。
2.找到已经商业化的同类产品，有针对性地进行学习研究。
3.知识库建立，整理思路，温故知新。
4.探究业务领域的历史，从发展历史中，可以看出业务的初衷与本质。
5.和业务专家沟通
【PS：快速了解行业、业务。方法论，PEST等。】

分析角色及干系人

无论是做B端产品还是做C端产品，产品经理都应该先想清楚产品给谁用，再看用产品的人有什么需求，我们不能脱离用户谈需求。

• 角色：由于B端需求的集体性和不同角色间需求的巨大差异，所以在调研B端用户需求时，以角色为单位进行调研。
• 干系人：不怎么使用产品，但对产品方向、功能会产生影响的人。

  分析角色

  从两个维度进行角色划分
  1）业务维度
  （1）按岗位划分
  按岗位划分比较好理解，如人事部门的人事主管、人事经理、人事专员等。这种划分标准非常清晰，定义起来也简单，能够与公司现有组织结构对应，产品上线后用户更容易理解，降低了培训成本，但这种划分标准只适用于组织结构划分非常清楚、职能间没有交叉的组织，如果实际情况不满足这两点要求，那就要按人员工作内容来抽象提炼了。
  （2）按工作内容划分
  按人员工作内容划分是指从所有的工作事项中，按工作内容和性质将人员进行归类，找到需要完成这项工作的角色。
  按人员工作内容划分相比于按岗位划分稍微麻烦一些，但更灵活，使用场景更广泛，不过其缺点是需要重新定义清晰的边界，也会增加一些用户的理解成本。从本质上讲，按岗位划分其实也是按工作内容划分的一种，它们的区别是一个从公司层面定义，一个从产品所在的业务领域层面定义。
  2）系统维度
  从系统维度划分是指从系统管理角度，为应对特殊情况和非业务场景所设置的角色，常见的如系统管理员、超级管理员等。视为一种补充。
  小贴士：
  a.在确定角色时颗粒度要保持先粗后细的原则。
  b.不好理解的角色名称，需要补充角色定义。

  分析干系人

  干系人（领导），有很大的话语权，甚至能够决定产品的生死。
  定制化阶段的B端产品因为是为组织服务的，所以组织领导的意见很重要，无论是业务方领导还是己方领导，都会对产品有一定的理解和要求，充分了解这些干系人的想法，一方面可以给我们提供一些思路，另一方面有利于产品在公司战略框架下的发展。

  识别角色及干系人重要性

  判断角色及干系人的重要性，可以从多个维度进行分析，如对产品的刚需程度、使用频率、对产品成败的影响力、对产品感兴趣的程度等。
  建议选择对产品的刚需程度和使用频率两个维度来分析已梳理的对象，分为核心对象、主要对象、次要对象三个梯度。

  判断对象对产品的刚需程度时，如果采用正向思考很容易陷入“都是刚需”的困境，所以我们一般采用反向分析法，也就是当没有这个产品时，会对特定角色造成多大的不便。

整理对象代表名单：
产品角色是一类人的集合，因此我们无法直接与角色进行沟通，需要从每个角色中挑选一到两名较为资深的人员作为角色代表，全权代表各自角色的利益，表达他们的需求。
干系人已经是具体的人了，所以就不需要代表。
注意事项：
最好不要让一个人同时代表多个角色，虽然从功能设计的角度来说允许一个人担任多个角色，但在调研过程中，如果让一个人同时代表多个角色，调研对象就会把不同角色的需求混在一起，不利于我们进行需求分析，也容易忽略部分弱势角色的需求。

制订调研计划

以一周的调研周期为例，可以制订一个如表所示的完整计划：


制订调研计划的注意事项：
注意步骤的先后顺序。很多步骤是有前后关联的，例如，需要业务方提前提供调研对象名单及时间安排才能进行调研。
调研对象职级最好由高到低排列。不是因为某些“职场文化”，而是因为职级越高的领导视野往往越开阔，看待事物与问题更深入，也更有话语权，所以我们需要先根据他们的调研结果来确定产品未来的方向。如果我们先调研职级较低的同事，很容易被他们不够深入的个人理解带偏。
调研对象和时间需要非常精确。这样做的目的是便于协调各个调研对象的时间，另外两个调研对象间要预留一定空档时间做缓冲。
预留一定的时间，及时整理调研结果。每天调研结束后一定要当天把核心内容整理出来，输出用户/角色画像，趁热打铁。
【PS：很多时候都需要考虑特殊情况，“预留”资源。】

#什么是痛点、需求、功能

痛点是目标与现状的差距，需求是达到目标的愿望，功能是实现目标的方式。
痛点其实一半是客观的一半是主观的，现状是客观事实，但目标则与个人的主观愿望有关。目标不同，目标与现状的差距就不同，痛点也就不同。
痛点与需求总是同时出现的。
功能为什么常常会跟需求混为一谈呢？第一个原因是很多产品经理没有认识到这三个概念的区别，误把业务方说的具体功能当成了需求；第二个原因是主语不同，产品经理收集、挖掘、分析的是用户需求，而对开发团队来说，产品经理设计的产品功能，则是开发需求，此时，功能就等同于需求。
【PS：经典。】

处理原则

• 客户的痛点，是我们调研的主要目标。产品经理要明确痛点是什么，是哪个角色在什么场景下产生的、发生频率多高、影响程度如何、影响范围多大。
• 对于客户的需求，我们要思考能否满足、何时满足、如何满足及满足这个需求的成本有多高。
• 对于客户想拥有的功能，我们则应该将其当作建议，思考是否采纳。每个痛点的解决方案不止一种，是否采用业务方所说的方案，则需要产品经理从更全面的角度权衡、比较。

调研方法

B端产品需求调研的方式以定性调研为主，很少用到定量的调研方式，具体方法与产品业务特点有关。

以流程为主线的业务（用户体验地图）

大多数B端产品的业务都是以流程为主线的。
以流程为线索，通过用户体验地图，帮助我们进行调研，这样可以很好地避免调研过程中低效、跑题、偏离主线的问题。
什么是用户体验地图
用户体验地图是一种针对某一角色，选择一个具体的业务目标后，按主流程及分支流程梳理此角色达到这一业务目标所经历的每个业务节点，并将其体验和感受用线状地图展现出来的方法。
它包括的要素有以下几个。

• 具体的业务角色。
• 明确的业务目标。
• 实现业务目标的流程。
• 用户的体验和感受。
• 具象化的形式。

  操作步骤

  （1）选择角色和业务目标
  （2）梳理任务流程（要想实现业务目标，需要经历哪些步骤，无论是线下节点还是线上节点，都要列举出来。）
  如何处理分支流程？聚焦主流程，将分支流程拆分出来，先分析主流程，再分析分支流程。如果分支流程影响不大，业务节点不多，在调研需求时也可以视情况省略。
  （3）绘制用户体验曲线（明确各节点感受好坏）
  （4）调研痛点（找出是哪些问题导致体验很差的，列举在对应节点下方）
  （5）调研痛点场景及频次
  了解每个痛点发生的场景及发生频次，是帮助我们认清需求的有效方式，大部分的伪需求都是建立在虚假场景上的，当我们厘清痛点场景后，就能过滤很多不真实的需求。而确定痛点发生频次是为了帮助我们在后面确定需求的优先级。
  频率的定义方法：在定义B端用户痛点的频次时，不是以时间频率来定义的，而是以“每经历n次业务节点就会出现这一痛点”的方式来定义的。如果不好量化，可以用每次、经常、一般等表示程度的词代替。
  【PS：真实需求，伪需求，优先级】
  （6）思考解决方案明确用户痛点后，产品团队可以趁热打铁，通过头脑风暴的方式思考痛点的解决方案，并将其放到对应的痛点下方。
  
  用户体验地图优势：
  【PS：一直觉得用户体验地图是C端的方法，B端相对角色多、流程多。】
  （1）契合特性：虽然很多B端产品业务复杂，但并非一团乱麻，而是由一条或多条非常明显的流程主线串联起来的，而用户体验地图就是以这些流程为基础来使用的，所以在这一点上两者正好契合。
  （2）避免遗漏：天马行空式的需求调研是低效且容易遗漏的，因为大家的思考缺乏逻辑清晰的指引，而以流程为思考脉络，能让我们始终围绕一根主线进行，这样在调研过程中不至于偏题太远；同时顺着流程的每个节点，能够思考得很全面，只要节点不漏，痛点基本就不会漏。
  （3）聚焦事实：在整个调研过程中，大家会发现我们没有主动问业务方想要什么、他们的需求是什么，而是围绕他们的情感变化，找出他们觉得体验不好的地方，始终聚焦于事实，保证了信息的有效性。

#非流程为主线的业务（深度访谈）

对于非流程为主线的业务，用户需求比较分散。
深度访谈是通过渐进式的提问，了解调研对象在真实业务场景下，对业务现状的看法、存在的痛点及其行为背后的原因。
准备问题-问题分类
在深度访谈中，一般会涉及以下四类问题。

• 描述现状：调研对象描述已经发生或正在发生的客观事实。
• 表达感受：调研对象对某些事物或问题的感受。
• 询问动机：调研对象采取某些行动、产生某些期望的动机。
• 征询建议：调研对象对提到的问题是否有解决方案或建议（是否采纳就要视情况而定），以及对产品的期望等。

  每类问题都有它的意义。通过调研对象描述的现状，我们可以了解业务的客观情况；通过他们的感受，我们可以了解他们的痛点，明确产品在哪些地方存在改进的空间；通过询问动机，我们可以理解其需求产生的原因；通过建议，我们可以了解他们的期望。所以产品经理在调研中每类问题都要问到。

准备问题-设计问题
要根据不同的对象，设计不同的问题。
除了要覆盖到前面说的四类问题，问题的顺序上也有讲究，总体来说应该由浅入深、由客观到主观、由具体到开放，循序渐进，步步为营。
问题设计原则

• 有目的性。除了在一开始设定总体的调研目标，针对每个调研对象也应该有明确的调研目的，因为B端业务各角色间的需求差异较大，每个调研对象掌握的信息及其视角、职责千差万别，各有不同，有的人可能是某些信息的唯一来源，所以为了提高调研的效果，产品经理需要提前想好每个对象的访谈目标和设计这个问题的目的。
• 有针对性。由于B端业务各角色间的需求差异大，所以不能像调研C端产品需求那样用一套题库进行调研，而是需要在了解调研对象背景的前提下，有针对性地设计题目。例如，如果调研对象是人事管理者，那么问题就应该侧重于管理方面；如果调研对象是普通员工，那么问题应该侧重于执行方面。
• 半开放结构。为了让用户更充分、自由地表达，调研所设计的题目应该比较开放，能给予调研对象一定的空间，尽量不要问对方只需要回答“是或否”的问题。但为了防止调研偏离主线，我们的问题又应该限定在一定范围内，如“你在人事管理工作中遇到的问题有哪些呢？”，这样的问题就太宽泛，涉及面太广，对方反而不好回答，我们应该缩小范围，改成“你在管理员工信息时有哪些觉得不方便的地方呢？”，这样对方就知道往哪方面回答了。
• 不预设立场。预设立场是指问题本身有倾向性，导致调研对象只能往预设方向回答，使调研结果失真。
• 问题明确。每个问题都应该是明确的、好理解的，不能够模棱两可，让对方无法回答。
• 引导例证。在设计问题和实际调研过程中，要引导调研对象多举例论证，列举实际场景，以帮助大家通过场景理解需求背后的原因。

访谈流程
一个完整的访谈过程，大致可以分为以下三个阶段。
（1）开场
在开场阶段，我们需要完成自我介绍+背景介绍+破冰三个任务。

• 自我介绍。调研团队的介绍，一般可以由全程参与的业务代表进行介绍。
• 背景介绍，可以由业务代表在协调双方调研时间时提前做个背景说明，实际开始调研时只需简单补充一些即可。
• 破冰。无论我们前期做了多少心理铺垫，对访谈对象而言，调研时都会有一定的心理压力，这时可以通过一些话术或者动作缓解对方的心理压力。例如，你可以夸一夸刚进来的人。

（2）访谈
虽然提前设计了一系列问题，但不要把思维限定在这些问题中，而是要视情况灵活多变，尤其是发现对方提到一些有价值的信息时，要进一步追问，以挖掘足够多的有效信息。
访谈时要把握以下几个原则

• 保持平等姿态。
• 引导对方继续。在语言上，我们可以用诸如“还有吗？举个例子呢？然后呢？”这类短语，引导对方继续说下去；在行为上，当对方说到比较重要的地方时，你可以温和地看着他的眼睛，以示对他的肯定，表示你对他现在的描述很感兴趣。
• 给对方安全感。由于B端业务很容易涉及敏感信息，在调研对象无法把握这个度时，更倾向于不说，这样就会遗漏很多信息，所以我们在访谈时要给对方足够的安全感，承诺对所有信息保密，并制定一些必要的保密规范。

  额外说明：产品干系人的需求都是通过深度访谈的形式来调研的，因为他们可能涉及业务不深。用户体验地图更适合调研重度参与业务的对象。

头脑风暴查漏补缺

通过头脑风暴的方式进行查漏补缺。例如，在调研过程中不容易提到的可视化需求、安全性需求等。

构建角色/干系人画像

在C端产品设计中，为了具象地理解用户，产品经理会将相似的一群用户进行抽象总结，提炼其共有的特点，然后构建一个真实的用户模型，这就是用户画像。
在B端产品设计中我们需要将前面的调研信息进行整理、提炼，构建角色/干系人画像，以帮助我们理解每个角色/干系人的特点。
在使用B端产品时，其社会科学方面的特征影响极小，所以我们构建的角色/干系人画像不需要C端用户画像中常见的如年龄、收入等信息。

主要记录的信息包括角色定义、业务职责、核心目标、主要痛点和期望建议。其中期望建议受个体想法影响较大，不能完全代表这一角色整体的想法，如果调研的角色代表想法比较多，产品经理就能收集到很多建议，但如果这个角色代表平时对这方面的思考较少，那么产品经理得到的信息就比较有限，这就体现了选择角色代表的重要性。
【PS：用户画像】