产品经理的价值-后台产品业务与设计的平衡点

最近正在调研一些后台产品，比如市面上成熟的相关系统：CMS、ERP、WMS、客服系统、CRM系统等，首先关于跳槽的数据上周简单的发起了一个投票，看到了数据结果，我认为说互联网人是跳槽的一代人毫不为过

想跳槽的朋友是不跳槽的3倍，并且除开一部分是观望薪资待遇再决定是否跳槽。

回过头来，我们常说前端产品经理是需要理解用户心理、用户的直接或间接需求，一个好的交互设计也可能让你的产品成为一款爆款。类似【探探】这样的创意交互产品，火爆了朋友圈。

但除了前端，后台产品的设计也是一个产品生态的完整重要组成部分。前端的控制、管理、权限分配都是靠一个完整的后台系统完成。

但是对于后台产品与前端产品，你更偏向于那一个？

• 逻辑思维能力

• 需求管理能力

• 需求与业务扩展能力

• 业务熟悉与了解能力

首先针对我们常说的逻辑思维能力，落地当产品设计中就是产品流程的管理与触发设计，我们常用的方法是以泳道图或时序图来进行管理业务流程，在这里用的VISIO或PROCESS ON工具为例，产品同学不仅要将需求在PRD清楚描写，评审中，更需要将不同的流程所面对不同的需求展现出来。

【泳道图】

其次就是需求管理能力，在这里与C端产品类似，但后台产品对于需求的管理更侧重在业务侧面上，比如与C端没有太关联的提现模块，是针对后台管理员的一个功能模块，并且以需求池来管理相应的需求，以相应的需求优先级来建立。并且这里要单独说明的是针对后台的需求，除了大版本的改动或迭代。基本没有版本的说法，能做的都是当日能改就改，能上就上。

需求池我常用的是EXCEL管理办法，并且上面是我在网上的一个截图，其字段应该增加需求提出人、需求上线日期、需求进度。

除了业务的理解，针对业务的扩展能力首先是要考虑其需求的来源会有几个方面来自：老板的需求、运营的需求、业务侧的需求、设计后台用户的需求。比如当前广告系统广告位在移动端上首页可以实现，那么如果其他移动端二级页面都需要呢？

重新开发肯定是不现实的，那么就将原来的广告系统重新增加字段即可。这就是扩展性的一种方式。

我我们在做C端需求的时候，我往往需要调研，去挖掘需求。【挖掘】这个词意味着能够找到用户直接的需求，是衡量产品经理好坏的一个客观标准。你的需求是否挖掘的够明确，最后在需求的实现上能够尽可能的完善，才可能会诞生出一个好的产品。

但不同于C端产品，后台的需求常常都是业务性的直接推到，但需求的明确性不代表需求就很好落地。因为后台的需求会有很多的联动，如合同的签订流程。当合同的字段改变后台相关合同审核、合同生成的字段都要保持统一改变。

在这里后台的需求明确性就导致后台产品落地中会有下面几个特点

• 大量的列表产品设计

• 字段的斟酌

• 微交互或弱交互

• 竞品的参考意义

后台中存在大量的列表产品设计，但每次到了UI或交互稿中，其列表的层次性会减弱的原因是UI或交互设计师会尽可能的将列表的形式弱化与美学保持统一。毕竟在设计中圆润与简洁的内容与列表的自身夹杂内容复杂和方正成了鲜明的对比。

所以在后台系统使用中，很多用户都不能感觉到方方正正的使用体验。但在产品原型和需求梳理中，其实产品同学都是依据列表来做需求落地。

大量的使用列表栏目，之前我有分享过关于后台产品原型布局设计，案例|后台产品设计联动性与交互TIPS，具体的可以在里面进行下载相应的原型。

最后说明关于后台产品设计中竞品参考的意义，其后台产品有相应的成熟系统，例如WMS、ERP、CRM等成熟系统。其竞品的参考可以帮助你快速了解其业务中需要的核心字段，国内做系统管理比较好的有Kingdee、用友、任我行等系统软件，这些都是基于公司业务做的成熟型系统。

产品经理不是为了抄袭而抄袭，而通过分析竞品尽快的定位需求的落地方法

这里首先个人认为好的后台产品设计最好还是由一个人负责相应的前端和后台模块，这样的关联性会很强。至于弱点就是后台产品的扩展度和细节是否能够满足业务的需求。曾经我所在的部门要求后台与前端产品人员分开，各自负责相应的前端和后台。但其最后沟通成本非常大，因为前端不知道后台会有什么规划、后台不知道前端需要那些管理权限等。

因此如果你的当前产品团队分工中处于这种情况，我建议可以试试以模块分工，不管是订单模块还是提现模块，其模块涉及的前端或后台由模块负责人落地。

【不同的模块分工由不同的产品人】

另外在后台产品设计中，满足业务的平衡其中首先要考虑的就是其后台满足的业务人员是那个？那条线？例如运营管理平台，那么首先的业务满足方是运营需求，运营需要什么样的功能去落地。排出优先级，其他非运营主线的需求就可以暂时放后面去。