B 端软件：产品经理正确打开方式

早些年 B 端软件流行瀑布式开发，以给客户提供解决方案为目的，没有成熟的产品，以定制化的方式进行交付，这里面有一个重要的岗位衔接着客户和开发，就是：需求分析师。

现在 B 端软件有很多的业务型产品软件、也有很多平台型产品软件，需求分析师变少了，产品经理变多了。

本文聊聊 B 端软件开发中的产品经理应该做些什么？

疫情前面试过不少产品经理，大部分提到 APP 、小程序的设计如数家珍，但涉及到 B 端软件就有点力不从心了，说明 B 端软件和 C 端有着很大的区别：

1、C 端软件服务于个人；B 端软件服务于企业、组织。

2、C 端软件更注重体验，希望简单易用，像微信，全国人民都在使用、抖音，三岁小孩都知道手指往上滑；B 端软件更注重效率，能给企业带来价值，降本增效。

3、C 端软件的使用角色相对单一，就是使用软件的个人；B 端软件有上层决策者、中层管理者、下层普通员工，会涉及到不同角色的工作台、权限、数据视图、操作流程等。

4、C 端软件要么花时间、要么花钱，尽管如此，每个人还是自愿花时间和金钱在上面；B 端软件能帮企业赚钱或省钱，但对普通员工来说，不一定是友好的，可能会改变工作习惯或增加工作量，需要自上而下，宣传、培训到最后熟练使用。

5、C 端软件通常凸显核心功能，其他辅助；B 端软件可能存在业务对使用人群有所偏重，但都很重要。

6、C 端软件使用简单，迁移成本低，导致有些笔记类软件担心用户流失，开放度小，限制导入导出数据；B 端软件从采购初期企业就有各种考虑，到最终上线使用，会经历一个相对长的时间、会涉及很多不同的业务部门，迁移成本高。所以很多战略项目即使不赚钱也要先把坑占着，后面才能做二期、三期。

正是因为有着很大的差别，所以在设计 B 端软件的时候，思考的方式、角度、侧重点都不一样，了解这些差别，能帮助产品经理更好地理解 B 端产品。

对 B 端产品经理来说，去设计一款 B 端软件，也是有章法可寻的，例如：拿开发具备低代码能力的 aPaaS 平台来说：

1、搞清楚开发的软件最终用户是业务人员还是技术人员？

2、搞清楚软件是私有化部署还是 SaaS 模式提供服务？还是需要同时支持两种？

3、了解 aPaaS 平台、低代码的概念、基本业务逻辑和实现原理，现在低代码已经烂大街了，资料非常地多。

4、做竞品分析，现在各种云产品都可以注册试用，即使有些付费功能不能用，也可以通过帮助文档了解功能详情和设计思路。做竞品分析的目的不是去抄功能，而是结合软件的最终目标，提升自己对业务的理解。

5、理清核心功能脉络，在企业级应用中，可以分四个部分：

根据四个点可以去思考：

6、上面提到了在 B 端软件中有高层、中层、底层不同的角色，不同的角色看到的工作台不一样、数据不一样、功能菜单、按钮不一样，需要设计既能满足业务又能操作简单的权限体系。

7、除了核心功能这条主线，还需要考虑一些辅助能力，比如：日志、监控、预警、配置等。

8、所有功能梳理完后，需要从中摘出一条最小可执行的单元，也就是 MVP，然后进行原型设计，包括：页面操作逻辑、交互规则。

9、拉着技术的前后端负责人，进行宣讲，听听意见，如果涉及到实现问题也能提前进行沟通。

10、方案确定后，配合 UI 进行高清图的设计，包括颜色、精细布局、字体、字号，整体效果出来后可以再进行一轮沟通和讨论。

上面是举例说明了产品经理做事的步骤，在实践这些步骤时，产品经理需要具备一些基本能力：

1、学习能力：从没接触过 B 端软件，到能熟练掌握概念、业务流程等需要有极强的学习和理解能力。

2、沟通能力：要能理解需求方的要求，也要和技术进行实现相关的沟通。

3、专业知识：如果是做垂直行业软件需要熟悉对应行业的业务、如果是通用性需要了解行业共性的知识、其他还包括专业工具的使用、软件开发流程等。

4、抽象思维：需求方在提需求时，往往会赠送一个解决方案，产品经理这时就不能照单全收，需要有自己的思考，挖出背后真实需求，并转化为软件中的一个功能。