方法论：后台产品经理的前世今生（一）

后台产品经理是开发企业内部应用的产品经理，服务于企业内部的业务部门，通过产品满足业务需求，帮助业务提效。
直思量写点关于后台产品经理的东西，奈何本人懒惰成性，始终没有提笔，今天心血来潮，遂提笔成文，望诸位不吝赐教，给予斧正。

提起后台产品经理，首先要给这个职业下一个定义，在我的理解中，后台产品经理是服务于企业内部的业务部门，通过产品满足业务需求，帮助业务提效的产品经理；简言之就是开发企业内部应用的产品经理。

这里说的业务是指企业的各个部门，例如HR、Sales、行政、技术部等等，而互联网企业的后台产品经理服务的业务方往往都是运营团队。

什么是后台产品经理

后台产品经理，是一个怎样的存在呢？这个叫法大多是中国互联网企业的叫法，可能是延续了互联网产品经理的概念，而又是做企业后台的，遂命名为后台产品经理。

那么他的目标是什么呢？普遍的理解是通过需求调研收集业务需求，并协调资源开发出满足业务需求的产品，多数初入行的同学都会这么理解，但是这样的理解未免有些肤浅。

我个人的理解是后台产品经理的目标是“帮助业务实现或创造更大价值”，因为满足业务需求这个本身就是个伪需求，你并不知道业务提的需求是否是真实想法，你并不能保证业务人员的专业性，你并不能保证业务人员的需求稳定性和对产品的理解能力，所以单纯的满足业务需求，并不是一个好的后台产品经理该做的。

而业务需求背后，其实是业务想解决自身的问题、痛点，好的后台产品经理不是要满足业务需求，而是要解决业务的问题或痛点，帮助业务实现或创造更大价值，这两者有很大差别。

举一个很形象的例子，也是我本人的实际经历：

有一次和朋友去日本Nagoya（名古屋），当地有一家非常有名的做鳗鱼饭的店叫『蓬莱轩』，人均大概得500元人民币，有三家门店『神宫南门店』、『松坂屋店』、『热田蓬莱轩屋』。

我们一行四人，就我还会几个简单的日语单词，打了一辆出租车（顺便说一下，日本的出租车是自动开门关门的，所以上下车不要去拉门，否则司机师傅会很诧异，我就犯过这个尴尬的错误）。

司机是一位老大爷，看样子有60+以上的岁数了，态度特别和蔼可亲，我坐前排拿着手机地图给他指了路，他狂点头はいはい说个不停，等到了地点之后停在了店对面，我们付钱下车（日本打车出了名的贵）。

日本的饭店门面都很小，就在我们还在找门店的时候，大爷已经下车了，和街对面的几个日本人说着什么，然后转过身就和我们连说话带比划，搞了半天我才明白，他是想让我们上车，然后我们就在诧异中再次上车了，好在我终于听懂了一个词，意思是休息，原来我们要去的那家店休息了，他要带我们去另一家店，就在我们还在担心要不要额外付打车费的时候，大爷已经把我们拉到了，远远就看见门口排的长队，下车后，大爷没有额外收钱，直接对我们笑着道别，我们几个无不感叹。

下面我就来分析一下这件事，我们对于大爷来说是客户，我们的需求是要大爷拉我们去指定的地点，大爷的职责是拉我们快速到达正确的位置，任务完成，收钱走人，没错吧，这就是初级产品经理的思路。

但实际上，我们的需求不是要到那个地点，而是去吃那个地方的鳗鱼饭，而大爷发现了需求背后的问题（我觉得完全是发自内心的服务态度才能做到），所以大爷把我们拉到指定位置后并没有完成任务，而是让我们吃到鳗鱼饭才是完成任务，这是一个非常典型的业务需求与实际不符的情况，而司机大爷很好的找到了我们的真实诉求，而不仅仅是满足表面的业务需求。

我把后台产品经理粗略划分为三个层次，初级的后台产品经理，是跟随业务，业务提什么需求就做什么需求；中级的后台产品经理，是有自己的想法，拿到需求后首先进行分析评估合理性，然后和业务进行讨论，进而形成产品方案；高级的后台产品经理，是能够站在业务前方，引领业务发展的，在业务前面思考，这就要求产品要懂行业，要比业务更懂业务；目前大多数同学还处在低级或中级阶段，请各位对号入座。

后台经理的工作职责

那么后台产品经理的工作职责以及工作内容都是什么呢？按照产品生命周期，我把工作内容分为以下几个方面：
以上只是PM工作的主流程以及工作内容，我认为，PM是对产品负责的人，是产品的CEO，所有产品开发过程中的问题都是PM的工作范围。所以后台产品经理是一个很高大上（kubi）的行业，行业有风险，入行需谨慎；当然同时也会给你带来很大的成就感。

与互联网企业的C端产品经理有何不同

那么互联网企业的C端产品经理和后台产品经理有什么区别呢（此处暂且不提B端产品）？接下来我为各位娓娓道来：

1. 需求来源不同

C端产品的需求来自于多渠道，有从运营过来的需求，有从用户对于产品的建议过来的，有从用户行为分析得来的，有从PM自身使用产品分析得来的，有从别的产品借鉴来的，有从领导那被压下来的，还有七大姑八大姨给你提出来的……

来源渠道多种多样，PM要去伪存真；而后台产品的需求比较明确，就是你服务的业务方（有时候也有领导提的），因此伺候好业务方就可以了

2. 用户不同

C端产品的用户大多数情况下就是普通的社会人群，你我他，比如微信、头条，谁都能下载使用，而他们也都费尽心思扩大用户群体，打压竞品，即使你不是目标用户，他们也希望把你拉过来充人头，打架也多点气势。

而后台产品不同，这里要讲两个词，用户和客户，是不同的，客户是给你提需求的，用户则是使用产品的人，是两波人，用户往往是企业内部员工，数量有限，没办法拉人头，你总不能把门卫拉过来用你的CRM吧！

3. 产品着力点不同

C端产品（移动端偏多，PC端逐渐被冷落）更注重界面美观，酷炫，注重交互体验，注重产品易用性，注重设计细节，例如按钮的颜色，位置都必须要有强大的分析才能确定，且影响很大。一个按钮的位置放错，可能流失成千上万的用户点击。

对产品精益求精，细细打磨，总之就是要让用户用的爽，让用户爽的同时，达到企业目标（变现，拉流量，UGC等等），发展到现阶段，C端产品的套路基本已经比较清晰了；而后台产品则对界面，美观，交互细节没那么强烈的要求，反正是内部人用，能用就行呗，不好看？忍着，你又没有别的用，为啥是橘红的按钮，老子喜欢，按钮为啥放左上角，嗯……因为我是左撇子。

后台产品更注重产品逻辑设计，流程，产品整体性，权限设计，框架搭建，可扩展性，可复用性，数据安全性（关于后台产品设计，以后专题讨论）；因此可以看出，C端产品考验的精，后台产品考验的是全

4. 设计复杂度不同

C端产品往往是单一主流程，少数分支流程，比如商城产品，主流程就是选商品-放购物车-下单-付费，而重点在于给你推荐更符合你的产品，勾起你的购买欲望。

后台产品设计更为复杂，往往不是单一产品流程，要和N多产品进行交互，定接口，设计数据结构，比如CRM，要和财务系统，合同，ERP等多系统交互

5. 抄袭成本不同

C端产品，你抄我，我抄你，天下产品一大抄，很难有技术壁垒（这点还得佩服百度），往往是你出了一个新功能，我两天就能跟上，比如淘宝和天猫，美团外卖和饿了么，头条和百度新闻，OFO和摩拜，除了颜色不同外，使用体验没啥大差别，因为C端产品都是暴露给所有用户的，很容易就能抄袭。

而后台产品则很难，往往是用户无法感知的，你很难知道淘宝的CRM长啥样，因为没权限，甚至有的为了安全是需要内网登录的，除非是找到企业内部的人，拿到账号登录进去，而即使登录进去你也很难看到全图，因为有权限控制，你能拿到的帐号往往都是小兵，没啥权限。

6. 入门门槛不同

C端产品普遍认为入门门槛相对较低（人人都是产品经理害了多少人），专业限制少，（C端同学不要打我），虽然我不敢苟同，但这是普遍的认知，技术转产品，运营转产品，销售转产品，厨师转产品，凡是用过几款APP，懂一点互联网知识的都觉得可以做产品……

后台产品入门门槛相对较高，懂业务，有逻辑思维，有技术背景最好，软件开发，项目管理（关于后台产品知识体系，以后会专题讨论）

当然还有很多不同点，这里不再一一赘述，最主要的就是以上说到的。

后台产品经理的进化史

接下来说一下后台产品经理的进化史，在讲这个之前，不得不提一下产品经理的由来，1927年宝洁公司的故事我就不讲了，大家感兴趣自己百度一下，中国产品经理的产生，是随着互联网的发展而发展起来的，几乎所有的互联网企业都有产品经理岗，这类人也是一个很高大上的存在，被誉为神一样的产品经理。

后台产品经理是近些年才被划分出来的独立的岗位，也只有互联网企业这么叫，做后台的，又是互联网行业，所以就叫后台产品经理吧，主要做的是CRM、ERP、HR系统、财务、DSP、DMP，等等，是不是很多70、80后感觉很熟悉的词，没错，其实在互联网崛起之前，这些系统就已经存在了，并且有很多人，很多公司也都已经在做这些系统了，那时候叫系统，还不叫产品。

说到企业应用，不得不提一下企业应用的鼻祖OA（办公自动化），OA的发展经历了三个阶段，早在1982年，很多同学都还没出生，中国还处在计划经济时代，美国的俩哥们Mitch Kapor和Jonathan Sachs建立了莲花公司，就是Lotus，也就是最早的做办公软件的公司。

最早被广泛应用的是该公司的Lotus1-2-3产品，要比office早得多，在当时的地位就像现在的苹果在手机中的地位，直到1989年，IBM收购了Lotus，把Lotus彻底推到了辉煌年代，成为全世界最流行的办公软件，以至于有一种说法，Lotus就是OA，OA就是Lotus，虽然最早还是CS结构。

而OA的第一阶段就是就是90年代随着Lotus传入国内，由政府采购，解决政府办公的文件管理，档案管理，行政流程，公文流转的场景，口号是无纸化办公，因此第一阶段是由政府需求催生了第一代OA，也产生了一大批OA软件公司，这些软件公司的模式就是乙方，由项目经理带着项目团队，给政府也就是甲方搭建办公系统，可能也包括硬件的采购，搭建，软件部署开发，以及后期的培训维护等。

第二阶段是2000年后OA开始由政府进入企业，帮助企业解决日常办公需求，出现了发文管理，档案管理，物品管理，车辆管理，后勤管理，人事管理等功能，这一阶段更侧重管理；随后由于企业办公场景逐渐丰富，出现了协同办公的概念，就是多人在线上共同完成一项任务，来提升生产效率，架构也逐渐从CS到BS，同时也产生了更为专业的，解决特定问题的系统，比如CRM，专注解决销售客户关系管理，ERP解决进销存的问题等等，OA的市场逐渐被挤压。

第三阶段是2008年之后，协同，智慧，被越来越多的OA供应商提及，同时OA也与CRM、ERP、SAP等企业软件深度集成，作为业务以及数据的中枢；再后来随着移动网络的发展，OA也大步迈向了移动端，出现了移动办公，在家或在外就能处理公司业务，大大提高了企业运作效率。

虽然市面上有大量OA的供应商可供选择，有收费的有免费的，有购买的，有租赁的，还有出台（外包）的，但是随着企业越来越庞大，人越来越多，业务越来越复杂，一套OA系统很难满足企业需求，二次开发又贵又慢，所以很多企业开始自己组建团队来做这个事，开发完全符合企业自身发展和业务要求的系统，他们大多数来自于原来的OA生产商，这波人在传统企业里面有的叫信息技术部，负责企业信息化建设，包括硬件，软件，网络，设备，而负责软件开发这些人，随着互联网发展，很大一部分人来到互联网企业，被叫做后台产品经理。

在传统企业里，信息技术部的组织形式是这样的，基础建设有专门的人负责，比如网络设备，服务器等，而软件系统这一部分，大多是项目组的形式，如下图：
职责分工不是特别细，有的项目经理几乎是全能，所有的事情基本都做了（很多时候确实是这样），既是开发又得测试，既要写前端又要懂数据库，写SQL，可以说是文武双全，人才难得；组织以项目的形式，完成系统开发上线，项目组有固定的，有的是临时搭建的，所有组员都要听命于项目经理，接受项目经理管理以及打绩效。

这种组织形式的好处是效率高，极大程度减少了沟通成本以及内耗，反正都要听项目经理的，你让干啥就干啥，坏处是对项目经理要求很高，综合素质要高，什么都要懂，极少有不懂技术的专业项目经理，有的项目经理都是技术大拿。

而在互联网行业里，随着互联网企业逐渐做大，也出现了同样的诉求，就是市面上很难找到符合业务发展的系统产品，因此也无疑的走向了自研的道路，但是互联网企业本身就是产品开发的专业，所以做后台系统也沿用了C端产品的开发方式和组织形式，就是一个流程化开发的方式，岗位设置也不同，分工也更加精细，如下图
流程化产品开发，业务提交需求，由PM写PRD，然后技术开发，QA测试，上线，各司其职，管理上各回各家，各找各妈，PM由PM老大管理，RD由开发老大管理，QA由QA老大管理，工作上协作，管理上分开。

这种组织形式的好处是分工明确，更有助于专业精进，PM负责写好PRD，RD负责写好代码，减少错误，QA保证产品质量，坏处就是沟通成本增加，资源协调困难，而且往往PRD写好之前RD都完全不知道要做什么，只有等PRD评审的时候才第一次知道要干啥，理解时间短，思考少，另外项目管理难，由于没有管理权力，PM对项目进度把控完全靠个人能力和各个干系方的自觉很职业素养。

由于PM懂技术的少，导致对于工作量预估没有话语权，也是PM和RD互相撕逼的很大一个原因。所以从传统项目经理转型到后台产品的人有一定的先天优势，也有不懂互联网的劣势，最终还是要看个人了。

那么C端产品转后台呢，我觉得，虽然都叫产品经理，但是不好转，完全是两个思路，C端产品习惯了关注界面，关注用户行为分析，而很难转变去理解业务，分析复杂的业务场景，多角色的用户权限，设计逻辑复杂的业务流程。

预见未来，后台产品经理是随着互联网发展而发展起来的，那么这个行业的未来如何呢？以我看来C端产品的人口红利以及发展到接近天花板了，巨头们很难再去低成本获得新客。

新进公司更难于在巨头林立的行业找到生存空间，资本市场也在寻找未来的突破口，随着经济形势的进一步下行，企业间的竞争日益激烈，C端产品经理的职业壁垒越来越小，未来的企业竞争一定是组织能力的竞争，哪个企业能更好的发挥组织效能，高效低成本的运行组织，才是未来制胜点。

组织，人，与系统产品的结合，谁能做的更好，谁才能胜出，可以想象一百个运营人员成交100单和1个运营人员成交100单，里面的成本差距和效率差距有多大。所以后台产品经理的未来可期待，发展空间很大，且行业跨度小，但是要先练好自己，迎接广大的市场和挑战，帮助企业存活，也祝福所有后台产品经理新年发大财！