编辑导读：作为一个B端产品，它的商业模式都是跟公司现有产品或业务有关联性的。如果要从零开始设计一款B端产品，要注意什么呢？本文将梳理整个B端产品完整的设计过程，与你分享。

某天Boss招呼老文去他办公室，坐下来，点上一根香烟之后便开始最近工作的近况的闲聊。相信很多看官都熟悉这个画面，唯一不同的可能是你们只有故事没有烟。

聊着聊着，Boss突然话锋一转，最近我有个这样的想法，业务是这样的：现在物流供应链相对还比较落后，咱们也很有机会，如果结合金融进行辅助，那不就可以……听明白了么？你看看如何设计一下，下周我过来的时候给我一个具体的方案。

接下来，老文便会根据自己的理解重述一下Boss刚刚的想法，必要时会白板上写写画画。经过可能长达几个小时的沟通后，Boss也觉得差不多了，便说方案尽快给出来哈，还抽根烟么？云云~~然后离开办公室脑袋一片空白。

Boss的这个想法可能来自于深思熟虑，可能来自于圈内大佬的交流总结，可能来自于某篇文章。有时候我想：也有可能来自于昨晚的一个梦。但是不管来自哪个脑洞，咱们该如何开展接下来的工作呢？接下来老文将经验进行分享。

根据这个话题背景，Boss是想设计一款物流+供应链金融系统，那咱们梳理一下，一个完整的B端产品设计要经过哪些步骤？先来看看总体设计架构：

一、设计前：分解Boss的想法

1. 业务现状梳理

B端产品的某个想法和商业模式的探索一定是基于某一个行业，大部分的时候都是跟公司现有产品或业务有关联性。因为沉淀一个行业的资源需要相对长的时间，所以不会突破行业突然来个创新型的idea，然后去予以实现，或者是公司转型和非主营性业务。

我们首先要做的就是将Boss的想法结合行业现状去梳理清晰，整理出来一个大致的流程和方案，然后匹配到公司现有的业务中，哪个事业线的负责人更有经验和权威。通过请教他来了解现有行业中的操作方式及痛点等，如果有机会的话最好是自己亲身去体验需求场景中去。

如老文公司是做公路物流的，所以经常去到物流公司或集散中心的操作现场去和一线的用户和操作员去聊天和了解业务现状。

通过以上方式将会对现有的业务现状有个初步的了解，并且能够和实际的业务场景有所结合，形成草稿式的文档，不限于采用什么形式。这个也是基于我们不是很了解行业的时候采取的方式，假设本来就深入了解业务，那就直接进行梳理即可。

目的就是为了将需求贴合实际的业务，分析出来业务问题并整理基础的解决问题的思路，而不是仅凭自己的主观经验去理解，脱离了线下的实际业务，最终设计出来的产品将会是一座空中楼阁。

2. 竞品分析&调研

B端产品设计时，不管是竞品分析还是市场调研，是具备一定难度的事情，因为有时候根本就找不到竞品，即便找到竞品想要获取测试账号也是很难的一件事情，实际的用户调研有可能是在饭桌上。

但是如果在行业中已经生存过一段时间，那么总会有一些熟悉的行业网站或者系统供应商，可以从这里去搜集到一些信息（咱们这里只讨论外部客户这种场景，不讨论内部用户和系统），然后慢慢扩展搜寻。

如何找到B端产品竞品我的经验如下：

• 基于第一点业务现状梳理，明确竞品分析的目的和核心需求，找到切入点和方向。不要把网撒太大了，这样容易迷失在各类信息中。
• 找到对应事业线同事并与其沟通，他们有些是行业中的业务专家，他们可能曾经使用或听过其他公司的同类产品。切记记录好产品的公司及名称，有什么特点之类的，尽可能多的了解产品的信息。假设公司找不到对应的事业线，那就拜托事业线的同事找行业中其他的客户或朋友，然后去那里调研。
• 通过行业网站、公众号、竞争对手等找到同类型的产品，浏览过程中某些文章或者论文也许还能够启发一些思路。
• 寻找行业中的软件供应商，每个行业基本上都会有一些软件外包公司或者标准化的软件供应商。可以约他们进行商务沟通，也能够得到一些很有用的信息。
• 最后，输出竞品分析报告，通过分析比较得出结论和对业务现状梳理结果论证。

通过以上的方式基本上能够完成竞品分析的工作，关键点在于如何提炼对于分析有用的信息。至于如何找到同行系统的测试账号、产品介绍等，那就需要各凭本事去套路了。

关于进行B端产品市场调研我的经验如下：

• 市场调研主要还是以线下拜访为主，亲临业务现场比听到的任何高谈阔论都有意义。
• 其次，如果公司有条件，能够提供实操的环境，或者能够在用户岗位提供学习的机会，那这就是最好的市场调研方法。
• B端产品的调研对象分为两大块，第一个为管理层，第二个为员工层。因为有可能做决定的管理层并不一定是使用用户，所以和员工层的沟通也是至关重要的一个环节。他们也是特别重要的干系人，一定程度上决定了产品能够在客户处走多远。
• 提前准备好业务问题，最好是有一定的层次和针对性，分不同的对象去了解，不同的业务角色需求、目的、痛点不同。
• 最后，不管调研的效果如何，一定要输出调研报告，将收集的业务问题做一个优先级，明确用户痛点，为后续的产品方案设计和实施提供决策支持。

光是市场调研这个板块都是可以独立出来写很多内容的，如调研的流程、方法、报告总结等。

咱们产品设计过程中也不能忘记这一环节，另外作为产品经理只有经历过一线才会对业务有更深刻的理解，然后做出正确的决策。每多去一次一线，就能少拍一次脑袋，每少拍一次脑袋，就能多一分成功。

3. 蓝图设计：商业模式

B端产品商业模式的设计是非常复杂的设计，涉及到的方式也比较多。落实到产品层面，就是我们常说的BRD文档。但是如果咱们是刚刚接触这个行业或者产品岗位，商业模式的设计基本可以忽略，毕竟设计好产品本身的业务逻辑才是重点。

一般的情况，B端产品的商业模式的建立也不是我们来做决定，我们也相对比较少接触，这里还需要根据产品运营的形式来决定盈利方式。

既然咱们上面做了竞品分析，竞品的盈利方式当然我们也是需要分析的。所以可以结合竞品分析报告及公司的现有业务模式给出一定的建议，将产品后续的蓝图提前规划，做到这个层面基本完成要求。

二、设计中：从不缺席的那个PPT

老文这部分的经验大部分是从我们CTO那里学习到的，相当于他带我入门，然后再从他如何设计产品的过程中自己去摸索沉淀，还有一部分来源于学习产品部的小伙伴们。所以现在部门慢慢形成了一个这样的文化，从0开始设计产品时，产品经理必然会写一篇类似上述思维导图一样的结构性PPT。

每次产品设计时，都会先写一个思路相对整体的PPT，可以让后面产品详细设计的时候少走很多弯路。目前我们部门的表现形式为PPT，其实使用什么文档类型并不重要，Word也可以，主要是要描述清楚下面的流程即可。

此PPT的意义：

1. 将需求方的想法和需求做一个全面的整理，并且可以用于与需求方进行沟通，使其意见达成一致。
2. 可以减少资源浪费，如果深思熟虑后发现此需求并不成立，就不必要进入产品的详细设计阶段，更不需要浪费研发资源。
3. 可以作为产品详细设计阶段的蓝本，也可以作为工作安排的依据，可以以此分解工作任务给到产品团队成员。
4. 可以作为项目组认知此产品的基础文档，对产品整体性达成共识，防止技术方案设计时，不符合产品设计要求。此PPT通过之后，架构师即可开始工作，这样产品和技术则可以同步进行工作。
5. 可以作为项目管理的尚方宝剑，因为这个就是和Boss达成一致的相对详细的文档。如果后面Boss认为产品方向偏离，则可以对照此PPT。也可以作为和技术团队的参照物。
6. 最后，这个PPT也是后面写产品介绍PPT的原型，将会为后面的工作打下基础，所以事实上它从不缺席。

我将此部分内容分为两大部分，12个分点。第一部分为总体概要设计，包括01-07点；第二部分为模块详细设计，包含08-12点。

1. 产品背景

以前从0至1设计产品时，我也对这块的内容存在疑惑，感觉产品背景的描述过于虚幻，不仅是现在PPT中需要描述，咱们的后续的需求文档中也需要。有时候都不知道怎么下笔，又不能直接把Boss的那个梦进行描述。直到现在稍微有那么一些感觉了，下面给各位看官提供一下我的思路。

大致可以分为四点：

1. 背景描述：一个是将行业背景分析并进行描述，再一个将公司背景和业务进行描述。
2. 核心诉求：阐述需求方或用户的核心诉求，如提高效率？解决某个业务问题？降低成本？
3. 项目评估：此处可以描述高层决定，所需资源，以及少许的风险描述。
4. 预期目标：时间目标、系统目标、业务目标等，如：3个月完成XX系统的研发并上线，系统能够支持业务XX年。

2. 产品定位

产品定位的描述就涉及到产品设计的本身业务，定位的描述可多可少，多的描述会涉及到业务支持的范围、预期目标的详细描述、简要的业务架构、产品角色业务支持等。少的描述集中于产品在公司产品中的定位以及边界定义。

产品定位和产品背景的区别在于背景更多的还是行业背景、痛点描述，定位将是描述你设计此产品的整体性描述和概要总结，并且对产品功能边界、系统or模块边界进行定义。

经验总结，目前我们部门的做法是：

1. 首先，先会做一个产品定位图，用来表述大致的业务以及和公司其他产品的连接。
2. 其次，将产品定位图进行解释，让文档阅读者能够清晰的认识产品定位，篇幅两页PPT基本搞定。

产品定位图：

3. 角色说明

产品中的角色大致可以分为两类，业务角色和系统操作角色。系统操作角色设计在系统的权限管理中，可以灵活的赋予角色不同的权限和功能。

业务角色本身就存在于实际的业务过程中，他们被赋予了不同的工作场景和使命，当然和系统操作角色一样也有同时承担多个角色的主体存在。

经验总结，业务角色定义的用处：

• 角色的定义和描述是在重塑用户画像的过程，能够使文档阅读者更清晰的认识业务过程中的操作，以及快速理解角色的定义和来源。
• 可以规范产品模块的边界，哪些角色需要在哪个系统or模块中操作，并且可以检验产品业务流程的闭环性。
• 促进与业务部门进行分析时，达成对业务角色的理解一致，防止出现产品经理对某一块业务的不熟悉导致理解偏差。
• 能够给系统的技术架构提供参考，也可以为后台人员提供业务理解的基础，因为产品及技术中后台的部门，很多对前台的业务并不是很熟悉。

业务角色虽然一开始就存在于业务过程中，但是把其映射到产品中来的时候也是需要进行一定包装，并且需要结合整体的业务流程进行不断的完善和修正。

4. 核心业务流程

相信在前面分析铺垫的基础上，梳理起来核心业务流程将不会是一件特别让人头疼的事情了。我们有了角色说明之后，根据实际的业务流程将他们通过一定的业务操作串联起来。这些业务操作一定是系统非常具有代表性的操作，并且角色相互之间是需要沟通和交流的（两次握手）。

经验总结，建议：

• 核心业务流程一定需要使用流程图来进行描述，纯文字性描述起来相对不会那么清晰，流程图辅以部分文字说明是相对比较好的实现方式。
• 实现方式建议使用具有一定代表意义的图标，包括序号、箭头、颜色等进行区分，这样整个图不会显得很死板，因为这里还没有到详细流程图的设计。

业务流程图：

5. 核心资金（支付）流程

这部分的内容，并不是所有的B端产品都是必须的，比如常见的OA系统、客服系统等并不具备这些功能，因为类似这样的产品只是为了解决企业内部的某些效率问题。并且里面的角色并不参与业务交易。

但是，作为一款商业型的B端产品，大部分都会涉及到资金流程，但是不一定会涉及支付流程。这里咱们要区分开的是，资金流程可以理解为一个记账的过程，比如财务模块、应收应付管理等功能，这些功能不一定会触发真实的资金支付流程。

支付流程又是另外一个独立的流程和体系上的内容，支付流程的设计也关系到公司是否已经存在支付系统，还有产品支付渠道的选择等，B端产品的支付和C端的支付差别相当大，因为涉及资金的限制也不同。比如老文的公司使用了很多银企直连接口，这些渠道也将会影响产品后续的设计，所以一开始最好是有所准备。

经验总结，建议：

• 如果涉及到资金相关的流程，先考虑资金流程和业务流程的匹配度，是否满足业务要求，再去考虑支付流程的工作。
• 资金流程中需要考虑到各系统之间的结算、利润等，如果产品涉及到公司多个业务系统，也要同财务部门和对应事业部进行前置沟通。
• 资金流程也需要考虑各角色之间的结算、利润，平台运营主体的利润等。
• 尽早让财务部的同事参与进来，或者提前进行沟通，防止出现设计的资金流程违背的了财务部门的要求。

6. 发票流程

发票流程的设计紧跟资金流程设计，整体原则就是谁收钱谁开票。所以，发票的内容基本上都是和资金流程同步出现的。

但是发票流程的设计并非如此简单，特别是遇到复杂的业务流程的时候。还有关于发票模块和流程的设计，往往容易被忽略，因为大多数情况发票都是一个线下的动作，实际上，对于一个商业型的B端产品，并且产品中拥有多个企业主体，又涉及到资金结算等业务，那必然会出现发票流程。

经验总结，建议：

• 设计阶段尽早让财务部的同事参与进来，可以少走很多弯路，特别是很多对公司本身的财务规则不熟悉的小萌新。
• 尽早确定系统的运营公司主体，因为不同的公司主体营业范围不一样，可开的发票也不一样。如果没有对应的公司主体，则需要提前去准备，防止出现系统上线后无运营主体的情况。
• 发票流程的设计需要符合公司财务部的习惯和要求，这里具备一定的专业性，不能一味的只考虑产品交互层面的实现。

7. 系统应用架构：功能模块

之前老文也说过，B端的产品经理如果具备技术背景将会是优势之一，如果是有技术知识的话，这块的内容写起来将会更加得心应手。这个也叫做业务架构图，也是产品功能模块的雏形，将核心的功能模块进行定位。这个和产品定位不同的是站的角度和层面不一样。

业务架构更多的是考虑产品内部功能模块之间的定义和关系，以及与公司其他系统的关联关系和布局。刚刚开始可能会觉得用处不大，但是这里还是蕴含着一系列的设计思考，这也会受到公司本身的技术架构影响，比如我们常说的SaaS、中台思想等。

经验总结，建议：

• 如果经验不够，架构图画起来比较别扭，那就提前请教做的好的同事或者技术同事，不然换种方式实现。
• 提前和CTO或者架构师进行沟通，不同的实现方式，所需的资源不一样，达到的效果也不一样，比如小程序和APP。
• 好的系统应用架构应该得到技术团队的认可，也可以使产品能够达到预期的使用期限，所以不能为了实现而实现。
• 这一步我认为是非必要步骤，也可以在后续的功能模块分解时做简要描述，将两者结合起来去实现。

最后：为什么文章没结束？

原本在文章架构上使用一篇文章写完，但是感觉篇幅过长，阅读起来将会很累。所以采用了两篇文章，喜欢的小伙伴，可以关注老文的下一篇文章《2B产品设计：2B产品经理做的那些2B事（二）》。

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

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