本文作者依据工作中项目实践的所思所想，结合案例等分享了B端产品设计的相关流程以及过程中需要注意的关键问题，供大家一同参考和学习。

为什么写这篇文章，是因为由我参与改造的一个系统正式投入市场后，经过几次的迭代，亲自接触了客户，获得了认可，有些真实的感受想和大家分享。

大部分产品经理的职业成功之路是成为某个领域的产品专家，而做B端产品经理是一条成功率极高的路，这就是我选择B端的原因。

我是大学期间就开始创业，折腾了几次之后，交了一些学费之后，果断求职。

先是去了一家房产中介公司做房产管理系统，一年之后进入现在这家教育公司，

现在是负责设计一款SaaS型培训系统，你要问我对这个行业了解多深，完全是从一个小白开始的，经过一年多的深度实践，现在可以用我设计的系统帮助客户做信息化改造，帮助客户实现线上线下混合式培训。

这就是B端产品，Business，即商业，帮助客户实现战略需求，从线下已有的运行业务进行信息化、系统化、高效的处理。

B端产品基本模块由用户管理、权限管理、OA管理、CRM管理、营销管理、订单管理面、报表统计等组成，几乎覆盖B端客户能应用的管理场景和运营场景。

一个行业经过几十年的发展，才形成行业标准，一款成熟的系统本几乎覆盖上面提到的产品模块，面对这样一个错综复杂的场景，产品经理最好的做法是循序渐进，从最粗略的业务目标开始，然后分析业务流程，到各职位的工作内容，最后才是数据、报表的细节。

从理论知识，到具体的设计，到部署上线，再到客户使用，这整个过程中我将踩过的雷在这里跟大家说说。

01 系统基本情况介绍

先说一说，我接手这款产品的背景，据说已经做了6年了，是从一个纯线上学习平台改造过来的，底层结构固化，客户使用者个位数。

随着教育信息化的普及，互联网的高效、便捷的特点，让市场需求越来越大，客户付费的意识越来越强烈。

面对日益丢失的市场，可想而知，公司面临着很大的压力，我们这些干活的自然而然有了压力，从市场业务人员，运维人员，产品团队，技术团队对客户的需求有了清晰的认识，这款产品到了不得不改的地步了。

我们这款产品已经有用户在使用了，为了满足这些客户未来发展的需要，降低运维成本，一款SaaS型产品最大的好处就是可复制，一星期就能就能完成新租户系统部署上线。

于是我们领导确定了改造方案：在原系统上改造升级。

02 产品背景分析

在开始做产品规划之前，首先要对产品进行定位， 这就要求多问自己几个问题，这都是吃过亏总结下的：

1. 这款产品解决了客户哪些问题？
2. 客户为什么需要这款产品
3. 适合什么类型的客户
4. 这个产品涉及到用户是谁，什么部门？
5. 这个产品帮助客户想要达到的目标是什么？
6. 这个产品的范围是什么？
7. 这个产品成功的标准是什么？

这些问题能帮助我们搞清楚产品的目标与价值，找出系统的关键受众，列出他们要解决的问题，分析业务，寻找产品范围，最终针对特性，提出系统用例细化功能需求和非功能需求

第一阶段的任务是对产品所服务的业务领域有一个概括性的了解。我们可以从行业背景、业务目标与诉求、组织架构、岗位划分等方面开展研究,这就是产品背景分析。

做背景分析的目的：要对我们的产品要重新定位，从原本模糊的客户变成针对某一个行业，某一类的客户，这样能帮助我们明确目标，缩小业务范围，这样我们更好的深入了解业务，更好匹配客户需求。

虽然第一层次并不足以让我们了解业务具体运转的逻辑，但是通过业务架构描绘出的一幅业务全景，对于进一步了解需求帮助巨大，这样就不会迷失在茂密的需求森林中。

1. 产品背景分析的技巧

无论是设计C端产品还是B端产品，首先我们都要对“使用者”进行深入的分析：

C端产品直接看用户特征，为用户做画像做分群；

B端产品则需要剖析B端行业的经营过程，再去看不同使用者的需要。

每个产品都有特定的用户群体，B端产品也不例外。背景分析的第一步，首先我们要搞清楚，产品到底是卖给谁？

做C端产品时，我们习惯用“用户故事”帮助我们定义用户类型；做B端产品，同样我们可以用一个“企业故事”帮助我们理清目标群体的需要。

2. 企业故事可以这样描述

目标客户是一家___客户，没有用我们产品之前，他们是这样工作的：_____当前客户在工作方式上出现了____问题，因此需要借助我们产品解决____需要，期望达到___的需要。通过这个企业故事，我们可以定位到产品针对什么行业、什么规模的企业，然后明确了这类公司的核心诉求，将来在做功能与设计的时候可以围绕着这个核心诉求展开，也是产品不断更新迭代的方向。

3. 业务需求资料来源

了解客户业务需求资料的途径，主要分为两种：被动获取和主动获取。

• 被动获取：从客户给的市场需求文档、技术方案、合同、招标书等获取；
• 主动获取：寻找合作的客户，现场观摩、沟通调研。

被动获取资料的行业，一般市场上已经有这样的产品，客户有了明确的要求，产品经理只要根据这些描述，基本上能还原业务场景，然后做需求分析。

但这样的需求分析是有缺陷的，因为这里面一些需求是客户定制化的，不能代表同行业其他客户的需求，这就需要产品经理收集更多的资料，从中抽离出共性。

主动获取合作的客户，需要依赖公司的长期积累的资源，通过市场销售人员的反馈寻找标杆客户。

不是这个行业的软件公司想做这个行业的软件产品，最高效，最便捷的方法就是寻找标杆客户。

4. 标杆客户的标准

你要寻找这个行业规模做的比较大，组织机构健全的客户，因为大家都会相互学习，相互模仿，谁做的好，他的管理方法逐渐被其他客户了解，并效仿，你做的产品才能迎合这些潜在客户的需求，才能获得更好的口碑。

在这个寻找标杆客户的策略上，我们就走了弯路，选择了一个规模不大的客户，重管理不重运营，导致产品目标跑偏了，系统耦合严重，操作繁琐，不仅没有获得市场认可，反而还让竞争对手反超了，就因为标杆客户选择的比我们的更精准。我们花了一年的时间进行修正，终于回到正轨上，很多研发资源都投入到这个系统上，这个代价是很大的。

做产品背景分析是让我们对产品做到“心中有数”，接下来的需求分析是我们产品设计的重点。

03 需求分类

在做C端产品时，最重要的步骤是需求梳理，也就是思考什么类型的用户在什么场景下遇到了什么问题。

那么在做B端产品时，什么是B端产品的需求分析呢？

这个看似简单的问题并不那么好回答，很多人认为的B端需求就是帮助用户完成业务流程所需要做的事情。但这样的理解并不完整，

需求分析并不是在分析系统如何实现用户的需求，而是选择一种业务导向的指引将零散的需求串联起来，形成一个体系完整、内容清晰的框架，为下一阶段的产品设计工作做准备

真正接触了客户你会发现B端的需求包含三种：

1. 表面需求（用户想要的）

用户经常从自身角度出发得出问题的解决方案。因为对产品定位、设计的依据等情况不了解，他们的建议很多时候并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。如果根据表面需求来设计产品的话，很可能会出现“头痛医头，脚痛医脚”的情况。

2. 本质需求（用户需要的）

用户想解决的根本问题。获得用户的本质需求更可能找出更合理的方案来解决用户的问题。

3. 产品需求（我们能给的）

依据用户想解决的根本问题，得出的更好的问题解决方案。解决方案可以理解为一个产品，一个功能或服务，一个活动。

这里重点分析一下需求转化的过程，叫需求透视，即透过现象看本质，我相信这是每个产品经理必须具有的产品能力。

我们们要做的事情就是挖掘本质需求。

主要任务是梳理清楚目标客户所有的业务类型。为不同的业务类型划分界限。并梳理出每个业务类型中所有的需求，也就是需求透视的过程。

04 业务流程分析

做好需求透视第一步就是要做业务流程分析，就是针对每一项业务事件，分析业务活动的特点，并确定业务活动之间的关系。具体要做的事情是：

1. 记录这些业务活动需要接收哪些信息；
2. 记录这些业务活动将产生哪些数据（报表），并确定数据传输的路线；
3. 标识出这些业务活动是由哪些部门、岗位在负责；

B端客户的核心价值就是对外部用户的诉求进行处理，在为用户创造价值的同时，为B端客户创造价值。

因此由业务事件触发的流程是分析需求时的核心线索。

在进行流程分析的时候有两个关键要点，一是理解流程的层次性，二是了解流程的类型。

1. 流程的层次性

为了方便大家理解，这里我以亲身实践的一个客户培训来举例：某省农业农村局委托某高校承办全省乡村第一书记参加某线上直播培训。

流程有组织级、部门级与岗位级三个层次；

1. 其中组织级是指经过抽象、提炼后的业务事件，如上图中受训方、组织方、承办方；
2. 部门级是指具体每个岗位负责什么活动，以及这些活动之间的关系。它是需求分析的主要线索，也是流程分析的主要输出，如上图中的省农业农村局、项目管理部等；
3. 岗位级是指每个业务活动具体的操作步骤，属于需求细节，如上图中负责人B，班主任C等。

整个报名流程，在我们平台如何实现报名需求：

第一种方案：市场部告知项目管理部有某个培训要组织，项目管理部在平台创建培训班，有组织方分享给受训方自己线上报名，班主任直接看后台数据就可以了。

第二种方案：有组织方上报报名名单给项目管理部，项目管理部在平台创建培训班，导入用户名单，生产用户账号，发送报名成功的信息给用户就可以了。

2. 流程的类型

在B端客户实际业务中，根据业务流程的目标可以将其分成不同的类型，一般我们可以分为生产流程、管理流程以及支撑流程三类。

1. 生产流程是流程中最重要的部分，也是体现B端客户价值的业务环节，通常最容易识别；
2. 管理流程是对生产流程的管控，通常是对流程效率与质量的监督控制；
3. 支持流程是对生产流程的补充，通常是对主流程起支撑作用的环节，非必须但容易忽略。

在本次培训过程中，高校培训部作为承办方，在进行项目申报、培训方案制定、培训班创建等这类环节都属于生产流程。

在这个主流程以外，每一个环节都有相应的审核操作，以及培训过程中进行学员签到、考核等这种流程属于管理流程。

在培训过程中，需要合同审批，项目备案、后勤管理等这些流程属于支持流程，有这些功能更好，没有功能能实现，客户自己线下也能实现。

在产品设计的过程中，我们优先设计生产流程，也就是B端客户的核心产品模块；

在生产流程走通的情况下适当做一些管理流程，以保证客户满意度，这是产品亮点，也是产品的目标；

在后期的迭代过程中，根据客户的要求上线一些支持流程功能。

05 角色与使用场景分析

做好需求透视第二步就是要做角色与使用场景分析，这个是很重要的分析过程，一个功能脱离了用户使用场景，用户就会感到很不爽，甚至直接放弃使用。

上面讲的企业故事，这里讲一个用户故事来帮助大家做角色与使用场景分析。

作为某某使用者/参与者，通过某项操作，以便能够达到特定的目标。

用户故事是指某种类型的用户为了完成某特定目标所执行的一系列操作。在描述层面我们可以暂时忽略业务目标，因此一条用户故事包含两个元素：参与者、做什么事。

例如，班主任要求学生完成签到，就会遇到很多应用场景：有学员在现场报名时签到，有每次线下上课前进行签到，有每次线上上课前进行签到等等。

于是我们平台有了数字签到、雷达签到、动态验证码签到、静态二维码签到，这个四种签到方式。

可有了这些签到方式，常常还是有客户抱怨太难用，很难理解系统的意思，也不知道从哪里去找需要的功能。

因为在传统的结构化分析与设计方法中，对事物的分析视角都是站在解决方案层面思考的，即这个系统需要有什么，从系统的角度出发做功能规划。

而以“用户故事”驱动的需求分析方法，是一种更侧重于“从用户的角度出发，将系统当做一个黑盒子”的视角，这种方法能够有效解决上述问题。

以线上学习每次班主任发起数字签到为例，因为每次培训正式开始前，班主任都会创建微信群，方便总要信息及时通知学员。这个场景下班主任和学员特别依赖微信群。如果班主任发起签到能直接分享签到链接到微信群，学员在微信群里直接打开完成签到操作。学员不用在平台之间直接跳来跳去，切换操作。

这样一个分享的操作，即减轻了班主任给学员反复解释操作流程的工作量，也简化了学员的操作流程。这样用户就会感觉很爽，班主任也没有负担。

从另外一个角度来说，用户故事的关键点在于发现使用系统的用户，了解并梳理这些用户如何使用系统，从而达到“以人为本”的需求分析。

面对一个陌生的领域，一个经历了多年发展变化的业务流程，要在短时间内弄清楚的确是一个不小的挑战。用户场景分析的意义在于帮助产品经理在短时间内从结构、整体上了解业务构成。产品不断迭代的前提就是建立在用户场景不断优化、不断调整的过程中。

06 获取用户需求

在客户调研的时候，经常看到产品经理傻里傻气地问客户：你对这个产品有什么需求或者有想法吗？

但不管用户怎么回答，似乎都很难让我们满意。客户提不出需求，你会觉得我们的客户对这事好像也没那么上心；更多的时候是客户提的需求都是不痛不痒，或者你感觉极具个性化，让你感觉做也不也是不做也不是；

和C端场景一样，B端场景中的用户需求也像是一个冰山，有很大一部分信息是埋藏在海平面之下，这就对需求调研工作带来很大的困扰。

调研的客户毕竟不是技术专家，只是普通的业务人员，因此他们没有办法对其工作提出产生变革的解决方案。因此需要产品经理对问题充分理解的前提下，选择合适的实现方式以创造出用户未想到的功能；

我在本次产品改造过程这些场景，也经常遇到，其中一个经费审批表导出就改了无数回，最终还是不满意。

例：客户提出需要导出PDF格式，防止业务人员随意篡改。

我们照客户的要求实现，我们满心欢喜地给到客户时，客户说这功能还是不实用，发现在实际工作中，有的文字内容过多，表格显示不全，导致分页显示，客户表示不满意，我们后来改回了word格式。

客户反馈他们需要导出每个审批步骤和审批结果，我们照客户的要求实现，发现在实际工作中，他们增加了审批步骤，还是导致分页显示。我们后来我们改成了审批流程自定义导出。

反反复复修修改，最终的方案，就是按照客户模板回填数据即可。

这样一个很小的功能，导致我们投入很多的开发资源，深挖客户需求原来是：客户从线下审批到线上审批需要过渡，需要平台 数据导出数据以备年度领导审查，备案需要。

这个例子就是我们只发现意识到的需求，而没有深究以及进一步分析的后果。

实际上B端产品的需求获取并不难，难的是与用户交流沟通的过程。因为我们的用户仅仅作为一个使用者，他只是站在自身使用的视角，想让自己的工作方便一些或是在利益分配上对自己更有利，很难站在系统规划的角度考虑全面整体的东西。

遇到这种情况，最有效的应对策略是需求分析从流程入手，搞清楚业务活动在平时是如何开展的，再逐步过渡到存在什么样的障碍，有什么困难等等。在这个过程中，多问几个为什么，多思考客户诉求背后代表的心里状态与利益冲突。

所以这一阶段，我们主要做的工作是收集针对业务活动的问题点、需求点。这时候我们获取到的是原始的用户需求。

实际上，在整个业务分类、需求梳理的大环节中，业务流程分析、角色与使用场景分析、以及获取用户需求都是伴随着用户调研进行的。

用户调研是一个有计划、循序渐进的过程。具体来说，在针对不用的访谈对象时，访谈的要点也不尽相同，具体的要点参考以下表格：

除了用户访谈和问卷调查以外，有机会到业务工作中实际现场观摩也是一种很好的需求获取手段，有助于产品经理对业务场景建立更加感性的认识。在对关键任务理解不清晰、很多东西用文字没办法表述时，现场观摩都是一种很好的方式。

到了这一步，我们已经收集到足够多的业务信息供我们进行后续的需求分析工作。

07 需求细节确认

首先，我们按照需求列表按照职责、部门、岗位整理归纳，这样我们能把产品划分成不同的业务板块，在这个层面看哪些系统需求是针对业务事件，确保业务流程正常进行的；哪些系统需求是针对报表的要求，确保流转过程中的数据传递；

接下来再往更细颗粒的维度整理，梳理哪些系统需求是支持业务步骤的，基于这些业务步骤需要设计什么样的功能点。这样一来所有的系统需求都按照清晰的脉络，层层递进展现在我们面前。

在这些需求梳理的过程中要明确哪些是前置条件，哪些后置条件。

所谓前置条件是指在用户操作某个功能的时候，用户与系统应处于什么状态。这个状态是系统能够检测并且是有意义的。而后置条件是指在操作结束时，系统应处于什么状态。同样这个状态也是系统能检测到并且有意义的。

再通过上面组织培训的例子来加深理解：

受训方有培训需求：这不是一个前置条件，因为这是系统无法检测的；

当市场部和组织方达成合作意向，甚至签订协议或合同：这也不是一个好的前置条件，虽然系统可以检测，但是只是一个支持流程，不是主要流程，客户可以选择不用，这个事情所表现出来的意义不大，对我们来说没有帮助；

在项目申报审核通过：这是一个好的后置条件，当然也要根据客户实际使用情况，但是系统可以检测并且事件对流程有影响；

项目申报通过后，项目管理部或市场部进行培训班的创建，复用项目申报的一些基础数据，添加培训简介之后对外发布展示。

一般来说，前置条件通常是一种状态，后置条件可能是一种状态，也可能是一种后续行为。并非所有的业务流程都必须在平台上存在前置条件与后置条件。

明确哪些是前置条件，哪些后置条件，能减少甚至避免在功能设计中流程耦合。

这种结构是以业务流程为整理的主线索，也就是按“事”的角度进行分解。这种方法对于工作流系统以及信息管理系统来说都是非常适用的方法。

08 消除需求间的矛盾

以上整理需求的方式，是按照业务流程进行整理的。在这个分析过程中，因为我们的需求来自不同的部门不同的岗位，难免会发现有些需求是互相矛盾、互相冲突的。

因此我们在整理后的列表中需要将这些矛盾的需求全部圈出来，然后快速地找到相关人员，通过进一步的沟通协调来消除矛盾的需求。

很多时候，需求冲突的真正原因是使用者与管理者之间的冲突。作为使用者，他的核心诉求是方便高效、省事，最好还能在某些方面获得一定的利益；作为管理者，他的诉求是流程规范、过程可追踪，杜绝损害公司利益的事情发生。

例如，项目管理人员/市场部因为委托方有很多不确定因素，自然希望在项目申报的时候能够更弹性，有一些自由度。但是作为主管部门领导，他们需要严格执行审批制度、财务报表审批制度等，导致系统上有很多信息是必填项，操作者感觉很繁琐。

从这个例子可以看出来，不同角色由于岗位不同，核心诉求也不一样。

在发生冲突的时候，我的建议是以客户的生产经营为核心，首先确保经营活动的规范化、流程化进行，在这个基础上增加为普通使用者考虑的易用性设计与情感化设计，让他们感受到产品不单单是一个反感排斥的工作系统，而是真正帮助他们提高工作效率的产品。

完成这一步后，才算是将整个产品的系统需求全部整理出来。以后每次迭代就是在业务需求与用户需求的基础上，创建新的系统需求，不断完善、丰富产品。

09 最后

大多数C端产品的设计逻辑会把用户体验与效率放在首位，追求极致的简单好用于高效。在整个产品设计上比较侧重用户的感受，精心打磨页面与交互，尽量少让用户做选择，保持产品的易用性与流畅性，都是做C端产品设计的不二法门。

但是做B端产品时，所有的产品设计都是为“流程”服务的。体验和效率未必是设计的重心。

很简单的一个例子就能明白：我们按照客户的需求上线CRM模块，不是为了让市场人员更轻松，做业务的时候更“省事”，而是为了将整个客户跟进的流程管理起来，做标准化的流程，为管理者提供更准确科学的决策。

又比如上面提到的，班主任和学员之间的互动基本都是靠微信群进行，这就要求我们产品增加微信一键登录，微信分享机制，来减少学员的操作路径。

B端产品更多是通过计算机技术实现B端客户的信息化管理，对业务流程进行优化升级，从而达到降本增效的目的。

由此可以看出来，做C端产品更注重对“人”的理解，要求产品经理具备同理心，感知用户的能力。而做B端产品更注重对“业务”的理解，要求产品经理具有系统性的逻辑思维，富有理性地对客户业务进行全面梳理与诊断，给出合理有效的解决方案。

作者：时光；公众号：时光遇见生活

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

题图来自Unsplash，基于CC0协议。