互联网b 互联网B端产品设计经验总结

一、什么是B端产品

b端产品可以概括为:供给端在供需关系中使用的产品或系统。

b端产品与C端产品的区别在于以下特点:

c端产品，以满足个人生活需求为重点，为用户提供愉悦(满足方便、新奇、虚荣、欲望、冲动)，且好玩。

b端产品，专注于满足组织的生产需求，帮助用户提高效率(发现并解决业务问题)，有用。

有一段说“手机这么好玩，找什么女朋友？”这里的乐趣大部分来自于C端产品给用户带来的快感。

B端产品迭代开发的立足点是发现和解决业务流程中的问题，提高效率。

二、我的B端产品设计经验

写这个总结的基本思路是:如果要做一个独立的、相对复杂的B面产品系统，如何进行产品设计工作？

主要包括以下几个方面:

B端产品系统设计的基本原则(指导思想)

B面产品系统设计五步曲(具体怎么做)

B端产品系统设计需要避免的误区(不要那样做，或者不要那样做)

业务流程中包含哪些角色和关键节点，从头到尾的正向流程是什么，从头到尾的反向流程是什么，中间的分支流程是什么，如何自上而下、自下而上的配合各种角色...

梳理业务流程，必须做到以下几点:一定要闭环(不能有半逻辑，不能有不能停留在某个环节的流程)；要看到底(不仅宏观合理，还要被底层细节逻辑所覆盖)，一定要有边界(什么是完整的系统，不是没有边界，没有延迟)。

尽量用一个大的业务流程图，把整个系统要解决的问题都包含进去。这样做的好处是可以想通所有的功能，防止出现重大的逻辑缺陷或者功能缺失。

3.定义最小粒度(基本单位)

基于以上业务流程，我们会发现，在这个系统中，有一个“基本单元”可以自始至终、自始至终、自上而下、自下而上地顺畅流动。

这个基本单元就是需要我们定义的“一件事”，分解成大小和粒度合理的“一件事”——这个系统主要解决的问题的基本组成部分，整个系统就是由这些粒度最小的“一件事”组成的。

这个“一物”在系统中有哪些“节点”，这个“节点”对应的是系统中的关键状态；

不同的人，存在于这个系统中，是系统中的“角色”；

哪些“角色”可以影响“一件事”的“节点”，哪些影响是“权限”和“数据范围”。

根据业务流程，抽象出基本单元“一件事”、关键状态“节点”、用户的“角色”、“权限”和“数据范围”。这个体系基本形成了。

以客服工单系统为例:

最小粒度基本单位“一件事”是指“一个投诉”，不是一个电话(太小)，也不是一个人的所有投诉记录(太大)。

“节点”:指工单的状态。从投诉开始，到转到相关部门或负责人，再到投诉的最终解决，每一次工作指令的中止都可以作为一个“节点”。

“角色”:除了一线客服、组长、客服组长等协作部门的角色外，任何参与本系统的人都可以概括为一定的角色；无法概括或需要详细分工的参与者需要添加角度“角色”来满足自己的需求。

“权限”和“数据范围”:每个角色可以做哪些操作、哪些内容、哪些影响构成“权限”和“数据范围”。

好的基本单元就像一个容器，通用(可以灵活处理)，灵活(方便添加)。定义一个系统的最小粒度，系统就成功了一半。

在我见过的B端产品设计中，大部分失败都是由于最小粒度定义不合理，导致系统逻辑不完整或者扩展性差。

4.建立框架和分类(用页面串系统)

根据不同的角色和功能，然后组合成一个整体框架，以页面的形式呈现，可以形成交互式的草稿。

从第二步到第三步，从第三步到第四步，是一个拆卸和重装的过程。先将其拆解粉碎，再与产品创意组装，形成最终的产品形态。

5.编写需求文档

在对上述过程和内容进行梳理后，将产品逻辑、图表、页面和功能点以文字的形式串在一起，再进行丰富和提炼，形成需求文档。

一份好的需求文档应该逻辑严谨，组织清晰，文字简洁，能够清晰地解释事物。

每个角色(交互、愿景、开发)都能准确理解需求的背景、目标、实现方法，从流程逻辑到功能细节。可以为不同的角色提供不同侧重点的需求表单。

尽量用通俗易懂的语言(不是形容词)描述需求，挤出任何歧义空。

(3)应避免的误解

1.看不到尽头

一个新用户，第一次使用系统，不能通过自己的思维理解系统(不会使用，不知道它有什么功能)。我不认为这个系统是一个好系统。一个好的系统可以通过页面功能或者很少的介绍来理解底层的逻辑和边界。

伴随到最后看不到的现象是，特殊的逻辑太多，往往导致枝蔓太多。产品逻辑的打补丁可能会很快解决一个问题，但是从长远来看，这种方式会影响产品系统的简单性和组织性。

最终看不到的不好影响是，一方面用户(尤其是新人)学习成本高；另一方面，添加新功能时很容易挖“线”，增加了维护和迭代成本。

2.延展性差

如上所述，由于初始考虑不全面(缺乏前瞻性的业务理解或最小粒度定义不明确等。)，系统扩展性差，增加一个功能就像是对系统的一次大操作。所以在产品设计初期尽量多考虑，每次迭代尽量为后续迭代提供便利。

3.所有的问题都被认为是由产品系统解决的

一个系统不能解决所有的问题，也不是所有的问题都适合用产品系统来解决。在投入产出比和灵活性方面，通过管理标准、SOP和Excel解决一些问题(需求)可能比作为一个系统更合适。

第三，低端产品经理的自我培养

在与令人钦佩的、成功的前辈/领导共事的过程中，以及近几年的工作经验，我认为B端产品经理不断沉淀的能力如下:

1.了解业务

无论是O2O还是互联网plus，B端产品都必须了解业务，了解行业的历史和现状，关注行业的发展。

除了垂直业务逻辑，大多数互联网plus还会涉及业务问题。经济管理和市场营销知识将帮助产品经理拓宽思路，增强业务思维。

2.沟通与协调

B端产品的业务链大多比较长，涉及的角色也比较多。一款B端产品的成功离不开相关角色的共同努力和相互支持。

通过一两件事与合作部门建立互信是后续合作的基础；建立固定的信息同步机制(每天与R&D团队开会，每周与业务部门开会等。)是合作顺利的保证。

在工作中，是一种发现和利用资源的能力。

3.持续学习

我欣赏的那些前辈，一般桌子上都有一本书。一个人很有能力并不可怕。可怕的是他还在学习。

这个时代和互联网行业都发展太快，需要不断学习。

主要结论概述

b方产品是指在供需关系中为供应方提供服务和支持的产品。

B面产品体系的核心价值在于发现问题、解决问题、提高效率。

B端产品系统设计的基本原则:“产品思维，业务导向”；站在用户的角度思考；考虑系统的扩展性和弹性。

B面产品系统设计的五个步骤:确定产品系统的目标；梳理业务流程；定义最小粒度；建立框架和分类；写需求文档。

B端产品系统设计需要避免的误区:看不到尽头；延展性差；所有的问题都被认为是由产品系统解决的。

B端产品经理要继续沉淀能力:懂业务；沟通协调；持续学习。