编辑导语：B端产品即为组织提供商业价值的产品或服务，B端产品设计能力是产品经理需要具备的能力之一。本文作者通过正在规划的战略项目，总结B端产品设计的方法论，分享一些能够指导B端产品经理具体工作的方法，希望对你有所帮助。

最近我们正在规划设计一个部门的战略项目，目标是搭建一套可支持对外商业化的零售SaaS系统，过程中涉及到一些B端产品设计的方法论，我觉得有必要总结分享一下。

总体来看把过程分为以下三个阶段：

1. 背景分析
2. 需求调研及分析
3. 系统搭建

具体每个阶段又分为若干步骤，这些可以指导B端产品经理的具体工作，纯干货分享。

一、背景分析

做背景分析第一步先看需求来源，这决定了项目的重要性和紧急性，通常有以下几种：

1. 客户需求-合同、招标书

对于靠为大公司做定制开发软件的企业来说，这是常规操作，拿到合同或招标书后开始启动，有明确的deadline，时间要求比较紧迫。

2. 战略需求-老板

做过C端产品经理的朋友都经历过老板基于个人喜好、同理心，对人的理解，突然提一些奇思妙想，希望团队尽快落地。

而B端产品的服务对象是企业，需要基于业务的系统性逻辑思考，天马行空的成分会低很多，老板通常是基于一定的洞察力发现未来可能会出现的机会和变化，结合目前策略上的差距，指出战略方向，但具体怎么做仍需要专业团队的分析输出。

由于看的是未来战略，老板相对会有耐心，会给团队足够的时间分析准备，属于重要但不紧急的项目，但会阶段性检查成果，通常半年或1年是一个节点。

3. 日常需求-产品经理

通常是自发的，基于对产品体验的优化、竞品的对标、客户的反馈，围绕战略需求有针对性的打造，重要性上不如战略需求，紧急性上不如客户需求。

作为一家致力于打造SaaS产品的企业来说，第2和第3种需求将会是主旋律。当然也不排除第1种需求，但比例应控制在10%-20%，传统的软件公司就完全是第1种需求驱动。

如果按照凯勒&帕帕森的《最重要的事，只有一件》理论，那么对要吃SaaS商业化这碗饭的企业来说，当前阶段这个战略项目的规划和落地就是唯一，至少应该保证有一个全职团队要不遗余力的做这一件事，其他事情都靠边。

背景分析的第二步是“战略五看”，分别是：

1. 看环境
2. 看行业
3. 看客户
4. 看竞争
5. 看自己

从长期视角洞见行业终局， 从全局视角观察领先格局，从动态视角把握趋势，再回到行业的本质，看看哪些东西是不变的。

知己知彼，从环境、行业、客户分析得出的行业机会点，结合从竞争、自己得出的战略控制点，可以识别出未来的战略机会，最终推导出where to go，既确定产品的目标和范围。

每个产品都有特定的用户群体，确定产品目标和范围实际上就是输出如下这段话：

我们的目标客户是一家 XXX 企业，目前他们的工作方式是：XXX ，面临了 XXX 的痛点，我们可以通过提供 XXX 产品解决，可以达到 XXX 的效果。

把这段话中的XXX补齐，输出的就是我们的目标客户和产品，多段这样的话就组成了我们的目标客户群和产品范围。

4. 以零售行业为例，输出“战略五看”

4.1 行业终局

如我在《三维零售-我的最终幻想》一文中所分析，未来零售行业的终局可以用“商品-时间-价格”的三维坐标来表示，原点就是“你在脑子里想象某个东西，不论是你曾经见过、用过，或者仅仅是一个设想时，都能以一个最合适的价格立马获得，并且瞬间出现在面前”。

那么为了达到这个目标，企业首先会通过全渠道零售构造一条价格和时间的曲线，然后通过供应链C2B能力打造一个曲面，最后将这个曲面逐步向原点趋近，越趋近于原点的企业竞争力越强。

换个角度，谁能够有效帮助零售企业趋近这个终局，谁就可以在企业服务市场中分得一杯羹。

4.2 领先格局

通过对20多家零售企业服务商的调研，我们发现逻辑简单、价格便宜的管家婆，备受传统中小企业青睐，满足日常经营80%场景，横跨7大品类服务50万家企业：

我们发现营销玩法多样、体验好、平台服务丰富、紧跟微信生态的有赞，备受中小型数字化转型企业的喜爱，满足多种业态服务于8万商家；

我们发现深耕多年商超、连锁、便利店业态的海鼎，具有强大的配置能力，丰富的报表，全面细致的功能，能满足大型企业的精细化运营需要，在深耕行业有很强的影响力；

我们发现具有丰富产品线、强大的财务管理模块、复杂的组织管理能力，正在向SaaS转型的传统软件厂商用友、金蝶，具有大量高端客群，行业案例丰富，对大型集团公司有很强吸引力。

4.3 趋势

2020年两会三番五次提到产业数字化、新基建、互联网+等等概念，已上升到国家战略，企业在数字化转型，降本增效上有迫切需求。

尤其是这次新冠疫情席卷中国之后，很多企业用5个月完成了过去5年都没有下决心做的事，是一次难得的历史机遇。

而社零数据中网上实物零售的比重也从2019年同期的18%增长到25%，交易上行的大势已不可阻挡。

就连打造平台生态的微信，也于7月10日正式宣布将推出“微信小商店”，一套免开发0费用的卖货小程序，裁判员也脱光膀子下场当起运动员。

4.4 行业本质

无论是阿里新零售、京东无界零售、腾讯智慧零售，也无论是重构人、货、场、还是流量、转化、客单、复购、裂变的新零售公式，企业追求的永远是降本增效，成本、效率、体验的优化。

二、需求调研和分析

最傻的需求调研方法恐怕就是直接跑过去问客户：你要的是什么？你有什么需求？

因为这样你压根得不到想要的结果，或客户根本提不出需求，或觉得客户提出的都是不痛不痒的需求，或感觉极具个性化，做与不做无所谓。

毕竟你调研的人不是技术专家，他们关注的永远都是看得见的需求，如果你傻傻的只满足了这些看得见的需求就交差，那就大错特错，结果只有一种：客户不满意，反馈系统难用。

产品在接收到一个需求时，除了关注业务反馈的点外，应该具备在实际工作场景中挖掘那些看不见的点的能力，甚至进一步的需求。

这需要对业务的充分理解，做到感同身受，设计出更合理、高效的方案。

举个例子：

给某个超市做一个纸质价签管理功能，客户提出的需求就是能够查看并根据商品价格打印价签，这是一个看得见的需求。

于是，产品经理就在每条商品详情页增加了一键打印功能。按说客户提出的点满足了，但交付后客户反馈系统没法用，非常不满意。

如果我们深入挖掘一下，就会发现至少有以下几个看不见的和进一步的需求：

1. 一般便利店都会有上千个SKU，假设每次10%变价，也会有100个价签需要打印，而每次进入商品页面打印价签的操作时间至少5秒，打印100次，再加上等待打印时间，可能半个小时都搞不定，这个过程对于店员来说非常煎熬，降低人效不说，而且会极大影响工作热情；最好的解决方案就是提供批量打印功能，在等待打印同时还可以做别的事情；
2. 线下门店打印价签通常是提前为促销做准备，或者是促销后恢复原价，这个反应速度越快越好，为了做到无缝衔接，价签打印要前置，也就是在系统真正变价之前就准备好物料，所以要有按变价时间维度筛选商品并打印价签的功能；
3. 促销是变价的主场景，所以应该有预先知道门店促销活动的功能，这就需要营销日历，让店员清晰明确的了解到接下来的活动及变价情况，并且联动打印价签；
4. 促销活动的种类繁多，那么在价签样式上要予以区分，尤其是与普通商品的价签样式，那么是不是可以考虑增加各种活动的价签模板，并给出不同的默认颜色和样式，额外再提供编辑功能；
5. 我们发现经常变价的门店人力成本非常高，除了打印还有核对、陈列，偶尔的操作失误还会引来客诉，基于ROI考虑，是不是可以改用电子价签呢？这就是进一步的需求了。

综上，如果每一个产品都能向前一步说话，从行业“降本增效”的本质出发，设身处地的为客户思考，获取全量的真实需求，也就避免了无从下手及费力不讨好的窘境。

价签管理只是一个很简单的功能，当我们面对复杂功能的需求调研和分析时该如何下手，还是要有一套方法论。

1. 过程分为三步

1.1 业务流程梳理

业务流程是分层的，尤其是当我们把目标客户定位为中大型企业时问题尤其复杂：

1. 第一层：是组织级，集团视角，关注分工、管理和大方向的业务流向。比如在零售企业中，就会存在供应链、门店、售后，客服、财务等几个不同的部门。这一层的调研内容主要是确认企业的组织构成，流转方式，目前存在的经营问题，寻找潜在的机会点；
2. 第二层：是业务级，部门视角，关注每个岗位具体负责什么，产出什么，以及这些活动之间的关联。例如门店部门要销售商品，需要库管、销售运营、导购的配合才能完成，产出就是销售额，这是业务流程梳理的主线索，也是主要输出。这一层的调研内容主要是确认部门内岗位分工，每个业务事件的流程，参与者，事件及关注的产出物，通常是报表形式；
3. 第三层：是操作级，通常是某个岗位的视角，实现某个业务场景需要的具体操作步骤，可能由某个或几个岗位的人操作，属于需求细节。这一层的调研内容主要是确认每个角色参与的业务流，日常的操作流程，了解功能、数据、用户体验等方面的问题。

业务流程分析起来很多很复杂，还会有子流程嵌套，很难用文字描述清楚，因此这一步的产出最好采用跨部门和岗位的泳道图，下边以线下销售场景为例说明：

线下门店销售业务流程横跨3个部门7个岗位角色，而每一个步骤又包括若干的子流程，输出这个流程的目的是确认各个部门之间的关系，及各个角色应该承担的工作内容。

1.2 角色与场景分析

基于步骤1输出的角色应承担的工作内容，再具体看某个角色在特定场景中都需要做什么事，那么就拆分成两个基本要素：

1. 参与者：这个流程中与系统进行有意义交互的任何事物，可以是某个岗位的人，也可能是一个硬件或系统，比如门店销售可以是导购，也可以是自助结账机，线上销售就是APP或者小程序；
2. 做什么事：是指系统执行的一系列动作，是一个动词+名词的组合，且必须是有意义的，产生实际结果的动作，比如，操作收银机执行一系列动作，生成销售订单，这就是一个完整的场景了，但只是添加一个商品到购物车，这不能叫完整场景。

2. 为什么要用这种角色+场景的方式分析

主要因为以往很多技术性产品经理在分析和设计产品时，总是以功能的视角去思考，既这个系统应该有什么功能，这样做出来的产品就是一系列功能的堆积，用户常常抱怨太难用。

看到一堆“xx管理”的菜单，根本不知道干什么用，即使看了天书一样的手册，要完成一个场景，可能需要切换若干个菜单模块，合上天书，又不知道该去哪找需要的功能了。

而以角色+场景方式驱动的分析方法，是一种侧重于“用户视角”的分析，将系统做成一个黑盒子，不仅可以有效指导最终展现的菜单形式，避免上述问题，还有利于梳理场景时发现那些看不见的问题。

下边以“导购”角色的“销售”场景为例进行分析：

步骤2分析的角色+场景只输出了一个核心路径，是主流程，还要补充拓展流程、完善前置条件、后置条件、特殊规则。

• 拓展流程：指分支事件和一些异常情况；
• 前置条件：指这个场景发生前需要系统具备哪些能力或处于哪个状态；
• 后置条件：是场景结束时输出的内容或一种状态；
• 特殊规则：就是受限于客观情况必须规避的情况，比如硬件性能、数据库大小、使用环境、技术选择、公司规定等产生的限制。

将多个角色场景进行抽象整合输出系统用例，系统用例作为最小需求单位指导系统开发。

这里说的抽象整合就是技术层面的复用逻辑，好比软件开发中“类”和“对象”的关系，系统用例是一类的抽象，角色场景是一个具体的行为。

仍然以“导购”+“销售”场景示意，输出系统用例如下：

三、系统开发

进行到这一步，系统变得越来越具象，引入的人也会越来越多，一个很复杂的项目为了保证原始需求不走样，非常有必要的一步是把系统用例映射回原始业务流程，看看是不是都覆盖全了，可以用类似这样的表来跟踪：

这是一个回顾和整理的过程，同时优化系统用例，按照模块分工给相关的人输出原型设计和数据报表，这些是技术产品经理最擅长的了，但需要强调3件事：

1. 菜单结构设计

很多技术产品在设计交互时喜欢用功能模块来划分菜单结构，直接把底层的功能投射到用户交互层，这对于没有行业属性的软件来说是迫不得已，但在客户实际使用中却有很大缺陷。

因为在业务操作中，会出现不同层次页面的频繁交替，让使用者云里雾里，感觉十分混乱。

产品经理只能通过输出天书版的操作手册来培训使用者，无形中增加了学习成本，而放下天书，又忘了该去哪个页面操作，想找一个功能也不知道该去哪个页面。

对于垂直行业的B端产品来说更好的方式是以“业务场景”来划分菜单结构，以完成某一件事为主线，好处是可以明显改善重复和混乱的现象，让整个系统的菜单结构清晰明了，使用者更容易上手

为了适应不同行业中“业务场景”可能存在的差异，系统中还可以设计一套业务流程管理功能(BPM)，去定制“业务场景”中的操作流程，并最终体现在菜单结构的改变。

这是一个很复杂的功能，但对于横跨多种行业的软件来说可以大大增加系统灵活性，减少后期的开发工作量。

2. 数据操作完整性原则

本质上软件的工作就是信息输入、信息处理和信息输出。

在设计输入环节时我们要检查“增删改查CRUD”四个基础功能是不是给全了，是不是能够在一个页面内解决？以及是不是足够好用。

比如商品主数据的输入，由于涉及到大量SKU，那么设身处地为操作人员考虑，从提高效率的角度，要考虑批量导入，批量删除、批量修改、条件筛选的功能；在设计输出环节时我们要提供丰富的筛选查看以及必要的导出功能，这样不仅方便客户在系统内查看数据，也可以自助导出用其他工具透视。

通常不同的数据操作权限会分配给不同的角色处理，所以不仅要提供功能，还要考虑在权限层面解耦出来。

3. 角色权限模型

B端产品通常都适用于RBAC权限模型(Role-Based Access Control)，也就是每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素、数据资源的访问与操作权限。

需要建立一个“用户——角色——权限”之间的对应关系，用户与角色，角色与权限都是多对多关系，即一个用户可以对应多个角色，一个角色可以分配给多个用户，一个角色具有多个权限。

当用户比较多时，还可引入用户组，将角色与用户组进行关联，当角色发生变更时，可以大大提高操作效率。

完成这些工作后交付UI设计，最后进入软件开发，这两步就要交给专业的UI设计和软件架构师操刀了。

四、总结

B端产品设计需要丰富的行业背景和专业能力，不仅要有逻辑能力还要有全局视野，清楚行业的上下游关系，看不同角色在链条中的作用。

不应是简单的堆砌功能，也不是所有的功能都适合做到线上，而是要看清楚哪些符合行业本质，才在哪个方向发力。

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

题图来自Unsplash，基于CC0协议