方法论:后台产品经理的前世今生(一)

36 评论 24949 浏览 331 收藏 23 分钟

后台产品经理是开发企业内部应用的产品经理,服务于企业内部的业务部门,通过产品满足业务需求,帮助业务提效。

一直思量写点关于后台产品经理的东西,奈何本人懒惰成性,始终没有提笔,今天心血来潮,遂提笔成文,望诸位不吝赐教,给予斧正。

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

这里说的业务是指企业的各个部门,例如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单,里面的成本差距和效率差距有多大。所以后台产品经理的未来可期待,发展空间很大,且行业跨度小,但是要先练好自己,迎接广大的市场和挑战,帮助企业存活,也祝福所有后台产品经理新年发大财!

 

作者:辉哥。微信公众号:huigezaji。

本文由@辉哥 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. PM和PD弄混了

    来自浙江 回复
  2. 我一直觉得,后台或者后端产品是按照产品所处位置定义的,b端是按照服务对象定义的,不同维度。后端产品两个特点:1.地位方面就是说不是业务终极目标,而是过度或支撑。2.单独它一个,是不完整的。因此钉钉不是后端产品,但是b端产品。因为它本身有后台。企业oa这不是后端产品,因为它往往前后端都在一起。它本身就完成了使命。
    我说的对不对,希望纠正

    回复
  3. 请教下后端产品的定义,您说是企业内部使用的就是,那和2b的定义有啥区别?那钉钉算吗?oa算吗?

    回复
  4. 你的亲身经历?我怎么感觉在哪本书里看到过。从点子到产品?你是作者?

    回复
  5. 哇,能收我为徒吗 ❓

    来自湖北 回复
    1. 不敢当,共同交流吧,可以关注一下我的公众号

      回复
  6. 感觉大腿对18M挺了解啊~~写的条理清晰,辉哥应该是外企大厂的吧

    来自北京 回复
    1. 目前在美团外卖

      回复
  7. 很系统,很清晰,我也是“后台产品经理”,之前也短暂做过技术,现在逐步也在做toC。个人认为后台产品经理更注重逻辑思维能力,对业务理解要求比较高,沟通能力要求比较高;toC产品经理更注重用户研究,竞品分析,审美能力,总之用户数多就是好产品。就目前看,toC待遇普遍更高,需求量也更大,也更容易成就人,一些大牌、众所周知的产品经理都是做toC的。貌似压力也更大一些,因为kpi比较好考核;后台或toB需求量相对较小,待遇也略差一些,业绩不太好衡量,也不太容易出彩。主要还是看个人吧,自己适合哪个就做哪个比较好,不然真的会比较累,主要也做不太好。个人的一点愚见,希望以后可以多学习多沟通。

    回复
    1. 分析的很有道理了~

      来自浙江 回复
    2. 产业互联网逐渐发展,toC流量见顶,我认为在toB领域,会有更多的增长机会。而后台产品经理的能力模型与toB领域更加契合。

      来自澳大利亚 回复
  8. 写的不错

    回复
  9. 对来龙去脉写的挺清楚的~赞

    来自广东 回复
  10. 666

    回复
  11. rrr

    回复
  12. 顿时对后端产品更有信心了

    来自江苏 回复
    1. 前途是光明的 :mrgreen:

      来自北京 回复
  13. 抱住大腿

    来自四川 回复
  14. 后台PM竞品感觉好难,找不到合适的号去体验,如何做好竞品调研呢?

    回复
    1. 是个难题,属实没有那么方便,回头对此话题单独写一写

      来自北京 回复
  15. 辉哥什么时候更新啊,跪等

    回复
    1. 感谢关注,着急的话可以关注我的微信公众号huigezaji,里面更新比这里快

      回复
  16. 真的很巧,今天注册了【人人都是产品经理】,第一篇看到了这样的文章,很兴奋。原因无它,本人从事it20年,其中有近10年后台产品经理经历的人,看到辉哥的文章,真的很有认同感。尊称一声【辉哥】不是讨好,这不是做技术的人的本性,而且猜想能写出这样的文章,没有20年从业经历真的很难。我现在是技术部门经理,之前的工作,说是PM也不对,说是公司的CIO也差点,说是SSE还不全,听到【后台产品经理】,豁然开朗,就是这个。
    另外辉哥,后三段匆匆结尾,会有很多人不认同,期待后续。

    来自辽宁 回复
    1. 那我要尊称你一声前辈了,我们应该是同行出身,我也是技术出身的,今后共同咱们共同探讨

      回复
  17. 我就是c端APP转到后台产品的,给zf做项目,一开始确实非常不适应,业务流程极为复杂,数据项要求极为严格

    来自上海 回复
    1. 不着急,慢慢转变,可以关注我的公众号,看看后台产品经理需要具备的能力模型

      回复
    2. 我之前也是C端APP 现在这家公司产品是B端的 后台、APP、web都有做 业务流程同复杂 😎

      来自浙江 回复
  18. 后台产品经理、ToB端的产品经理,两者有什么区别呢?
    从全文看,感觉是一个,不敢苟同

    来自湖北 回复
    1. 是不同的,今后会抽时间单独聊聊toB的事

      回复
  19. 是我们的老师辉哥吗 感觉好亲切 哈哈哈

    回复
    1. 肯定不是,哈哈

      回复
  20. 写的挺实在的

    回复
  21. 听起来后台产品经理和2B产品类似

    来自四川 回复
    1. 有60%-70%的重合度

      回复
    2. 我也是做后台的产品,而且还兼任项目经理,一天累死累活的,看看做C端的好爽,工资不少拿,活还轻松

      回复
    3. 大实话啊···有些做C端的连流程都不设计,就做页面。所有的业务逻辑都需要后台产品来搞定

      来自北京 回复