为什么很多产品经理都不愿意做后台？
你知道今天我这里招一个平台型的产品经理有多难么……真想死啊……
很多人都关注了这个问题，也有不少知友来询问平台型产品经理是个什么鬼。
为此我半夜三更不睡觉更新了一篇专栏，希望对大家有帮助：
http://zhuanlan.zhihu.com/workandlife/20439226后台产品对逻辑能力和业务能力要求很高。做过跟没做过差别很大，做的好跟做的不好也差别很大。人人都是产品经理，在这里是行不通的～我就是做后台的产品经理啊，工作快六年了，最初是做传统行业it部的系统需求分析师，也就是后台，偏流程偏逻辑，后来互联网火起来了，移动互联网也火起来了，就跳槽到互联网行业，那时候就觉得做前台尤其是移动端的，才叫互联网pm。
真的做过pc前台和移动端，见识了太多的口若悬河，天花乱坠，异想天开，装逼刷存在感，各种卖概念卖见识之后，我回归到后台，并定位自己为专做后台的产品经理。
不是做不了前台，是觉得没意思，因为真的觉得很多前台pm并不真正懂业务，但没有人会承认，每个人都装得自己很懂似的，从各种爆炸信息或竞争对手里攫取点什么整理下，换个马甲就是idea，开始进入互联网时，看着大家如此热火朝天，各种看起来很厉害的信息名词概念idea乱飞，我看热闹不知所措，后来慢慢觉得这只是很多人的相互掩饰罢了，只能唬住外面的人吧。
当然前台也有很多确实真正很牛逼很靠谱很懂业务的pm哈，我也有幸结识了不少。互联网行业这些年发展太快，不管人才还是其它方面都有些泡沫，比较浮躁，鱼龙混杂。
我自己觉得，脱离业务做产品总觉得脚没踩着地，心里不踏实，还是回归后台，虽然累繁琐，可能不被重视没有存在感，不过我自己觉得有意义吧。
一直都是刷知乎，很少答题，估计这个答案肯定被喷，我只是分享几句心里的实话，就这样。本人经历：app工具类产品有过极短时间内零到百万经验，后做过个人信贷系统，做过电商系统，erp，物流终端。可以说我是前后台经验都丰富的人
首先输出点私货，作为一个产品人员，我是很不赞同产品线按面向用户的逻辑进行工作划分，而这是一般老板和非产品的人员的通常思维。我比较喜欢的是面向业务或流程做产品线划分的方式。
至于为什么说普通产品经理做不了后台产品，我本人的经历就是教科书式的典范。（这里的做不了没有任何能力上否定的意思。）
我们先看那些业务和流程仅限于后台的产品，比如：我第一次做的电商的库存管理系统。
我遇到的坑如下。
1，业务人员不了解业务。
这里不是说业务人员不知道自己怎么做业务，只是大多数业务人员从来没有系统的想过仓储这些事，所有的抽象和发散都要产品人员自己刨根问底抓着业务人员问。然而就算这样系统设计出来自己还是没谱，不知道会不会有业务线没考虑进去。
对比普通2c产品，有大量的竞品可参考，业务模型也没2B产品复杂，场景更是单一，甚至产品经理自己就是用户，在做需求分析的时候都是很轻松的事。
2，业务人员不了解系统
我司做的是生鲜供应链，很多都是传统行业从业人员，对互联网或IT系统的理解几乎为无。我遇到过收到系统订单后业务人员不按流程做事，不过系统私底下联系操作人员进行操作，之后系统频繁报错，责怪产品团队，最后靠开发写数据库解决bug的事情。坦率讲这种情况在互联网化很低的一些行业出现的频率应该很高。
3，技术难度会挡掉一大批人。
2B后台产品一般会和其它第三方做接口对接，而往往对接只有一个接口文档。也就是说如果看不懂接口文档，就不知道这个部分能实现什么功能，更不用说产品设计了。（好在我作为非coder出身的产品狗也能看懂接口文档）
坦率讲，做后台业务的过程是非常无聊的，不像app有那么多新用户、行为数据分析，版本迭代上线……做后台的产品经理需要一颗坚韧，耐心的心，懂技术的同时又要有一定经验可以对业务做抽象和发散，所以一般人做不来或不想做，也是可以理解的。第一名的答案。。说得好像这些人前台产品就会了一样。。说得前台比后台简单一样。。
我觉得讨论前台后台是没意义的，就像做社交产品和做电商产品能是一回事吗？
不同的人偏好不同，擅长的能力不同，不同公司产品的定位不同，重视程度不同，导致不同的人做了不同的产品方向选择。
百度做搜索（包括百度地图这样的产品）的产品，做风巢等商业项目的产品经理，按划分绝大部分都是所谓后台产品经理，怎么没听百度的人抱怨大部分产品经理都宁愿去做贴吧之类的所谓前台产品，不愿意去做搜索产品，不愿意做商业产品？（ecom的pm之前赚的钱可比用户产品多多了）
百度这样遍地都是大牛后台产品经理（至少我当时在的时候，百度的产品经理其他能力不说，策略和逻辑绝对是强项，也不缺大平台经验）的公司，如果真的做后台的都很牛逼，怎么做所谓前台产品很多都做得一塌糊涂？你能说做后台更牛逼？真心也没听说啊。
基于我个人的经验（百度做了2年所谓的后台产品项目），为何印象中后台产品没人做，是因为真正高仿的后端项目（搜索，风巢），这种项目有足够钱能招到顶尖的策略技能特长的产品经理，这些人大部分本身就是佼佼者,当然里面也有苦力了，这些苦力就很惨，你知道搜索低阶产品经理每天都做啥吗?天天标query，几乎就是体力活。这些人升不上去，当然肯定不愿意继续做后台项目了。
觉得招不到好的“后台产品经理”？好的“前台产品经理”也缺啊。
觉得招不到好的“后台产品经理”？给够钱呗，给够定位呗，肥差永远不缺人的，就怕你把你自己不愿意干的苦活想找便宜劳力来做，没这么容易的。
相关：我做过2年后台产品经理。现在是创业公司产品负责人，是一个相对更偏前端的产品，但前台后台都得做。较之找到个模版抄来抄去，有逻辑性和了解业务要难些。
其实任何工作要做好都不容易，只是有些工作起步容易。谢媳妇邀。。。。
作为一个只做过后端的产品经理必须不正经的略答一二：
为了避免歧义，我所说的后端的意思是非商业的、不面对外界用户的企业内部产品，比如erp、crm、bi等等，而非某个商业产品的后端部分
1.后台基本都属于支撑型的产品，出了成绩也没啥关注度，相比于好的前端产品做得好了一呼百应瞬间成为业界大牛的赶脚，后端也就属于某领导过来拍拍你的肩膀说“小伙子做的不错好好干看好你哟”的阶段
2.承接第一点，前端产品做失败了可以说是为了情怀为了理想用户是傻逼还能找一堆人背锅，商务、运营、产品、技术互相喷一了百了；后台可是直接面对一群虎视眈眈的可接触用户。。。页面加载稍微慢点就山呼海啸的一堆邮件恨不得跑到你工位扇你脸。。。
3.绩效考核的时候很闹心啊，人家移动端产品月活上千万上亿那是人家牛逼跟我们一点关系都没有，活跃下降了？？？数据平台怎么回事！！！我们的用户呢怎么没了！！！！你们的数据是不是有问题？？
4.申请headcount的时候：好吧这一点略过想起来有点伤心。。。。
5.也许前后端产品的逻辑复杂度可以是一样（但是身为后端人我必须高呼一句后端产品经理更牛逼！！），但是前方埋伏的地雷数量以及拆除地雷需要花费的脑力与体力（是的没错真得要体力）以及没发现结果炸了以后的损伤程度来说，不是一个level啊亲。。。。
暂时说这么多，有可能还会补充。。。。。为什么很多产品经理都不愿意做后台？
问得蛮靠谱，并不是什么伪命题，虽然说不愿意可能是纯意愿性的，也可能是由于能力不足所导致的。
其实，大多数说不愿意做后台的产品经理要么是刚入行，什么也没做过的新人，要么是之前只做过前台产品，而没做过后台产品的产品经理。我碰到过的后台产品经理，目前还没见着说对后台特别厌倦或抗拒的。一方面是做后台也有做后台的乐趣，一方面是做得久了，不愿意离开自己的舒适区（况且收益还不低）。
那为什么这些人不愿意做后台呢？其实非常好理解，下面大致地说一下我能想到的一些原因。
▎对产品经理的鼓吹都是对前台产品经理的鼓吹
之所以有这么多人憧憬产品经理这个岗位，是因为近几年行业对产品经理的鼓吹太过了。很多尚未入行或资历尚浅的人会觉得产品经理无所不能，能够创造的价值巨大，甚至是决定一家公司生死的最主要因素。另外，又由于产品经理是一个相对通用的岗位，已有的一些大牛啥专业出身的都有，所以很多人所谓的热爱互联网、热爱产品设计实际上是觉得这活容易干，拿的钱又多（相关回答：产品经理的未来在哪里？ - 郑坚义的回答）。然而，种种这些对产品经理的鼓吹中貌似都没有提到过后台产品经理，所以对打算入行或刚刚入行的人而言，压根就没有后台产品经理这个概念，更不用说愿不愿意做了（大多数人的想法：怎么能做听都没听过的后台产品经理呢，我可是冲着前台产品来的，毕竟做 app 狂卷个几千万用户才是我的职业追求啊 - -）。
▎用户基数小
这点不用过多解释，你懂的。
▎前台需求决定后台需求
当然，这不是一句绝对的话，但就大多数情况而言，确实如此。后台不可能是完全孤立的，基本上在做一个功能或业务时，都是先从用户端（前台）出发考虑，而后台只是作为支撑。所以，关键的决策给别人做了，理想这么大的你怎能容忍一个附属职能？
▎内部重视不足
做后台产品经理不仅得不到外部用户的簇拥，甚至连内部的关注都显得弥为珍贵。对于初创公司而言，早期的后台连配备的产品经理和前端工程师都没有，完全是后端 GG 一个人撸出来的。等到开始有产品经理介入的时候，很多情况下也是能用即可，根本不会去注重 UE 和 UI 。有时为了节省开发或短期的管理成本，一些粗陋的地方还可以用 “内部用户可教育” 给搪塞过去。当然，这无可厚非。然而，一个事实是，哪怕后台已经做得十分庞大，而且也有足够的资源支撑，在 UE 和 UI 方面它还是不可能和前台相比。就像媳妇在家里可以长得不漂亮，但出去必须得化好妆。你瞧，淘宝、京东等大平台的后台颜值可好？可能有人说，哎，你要求就别太高，颜什么的，过得去就行，活好才关键。至于活好不好，你自己去体验呗 - -
▎没有同理心，难拍脑袋
说到同理心，常常会想到 “用户是白痴”、“麻花藤能一秒钟变白痴”、“我本身就是用户，我当然知道” 等话语。然后，就脑补工程师一巴掌甩产品经理脸上：“用户！我让你是用户！” OK，忽略这些讽刺的冷笑话。想要表达的意思是如果产品经理有同理心的话，能够更好地感知用户的需求。但是，对于后台产品而言，你似乎很难建立同理心。后台产品的需求更多靠理性的推导，也就是说你要老老实实地梳理业务的结构、逻辑和流程。
▎难参照竞品
其实也不能说是竞品，而是说可以参照甚至抄袭的对象。面向用户的产品很好调研和分析，毕竟现在是全民创业时代，市面上太多类似的产品。而且一些交互语言是通用的，用户只要大量地使用过别的产品，便会建立起相应的心智模型。然而后台对于很多人而言却非常陌生，毫无心智模型可言，也难以做竞品调研（这样其实非常考验设计的基本功以及设计师的信心）。举个例子，你要设计电商相关的后台，参考淘宝或京东的话，还得通过商家资质验证（一些细节的功能的调研的成本则更高）。
▎对 web 设计语言不熟悉
有段时间我都觉得 web 产品经理或交互设计师已经成了活化石，新入行的产品经理或交互设计师就没多少有相关知识储备的。大家讨论来讨论去的都是 iOS 或 android 的设计规范，然而你知道 web 的设计规范是什么吗？后台基本都是 web 形态的说。
▎和业绩关联度不高
前面有说到，很多人对后台产品的预期是能用就行，再加之它属于支持性产品，所以在项目业绩提升的时候，一般人也不会觉得后台在里面发挥了多大的作用。也就是说，做得好，那是你应该的；做得不好，你可能还得背锅。
▎颜值低，没有吸引力
做过后台的人都知道，其实后台没有那么丰富的交互范式，满屏过去都是各种表格、表单元素和按钮。看着你就觉得枯燥，做的欲望自然已经大大降低。
▎不能晾出去给别人看
你做得再好，后台是能随便脱掉裤子给外边的人看的吗？出去吃个饭都可以发个朋友圈，不能炫耀得是多么无趣。
--------分割线--------
以上是对 “很多产品经理不愿意做后台” 的分析，可以发现除了纯意愿性因素外，其它更多是因为自我感知能力不足所导致，也就是心里没谱。这里简单开几剂药：
1. 后台产品未必很难，你一开始觉得难，是因为你不熟悉，人们对不熟悉的事物都比较抗拒（熟悉之后感觉也就那样）
2. 后台产品未必很难，你一开始觉得难，是因为你期望完全套用做前台产品的方法去做后台产品，发现并不管用，心里有点慌（找到合适的方法即可）
3. 后台产品未必很难，你一开始觉得难，是因为以为后台很庞大，很复杂，不知从何下手（其实后台也是可以迭代的，由简入繁，罗马并非一日建成）
4. 前后台产品都操刀过，你的职业生涯更完整，以后干活更有底气
5. 就电商行业而言，好的后台产品经理蛮值钱的，尤其注重经验，所以做后台产品不见得是一件糟糕的事情
1、导读
强大的后台系统需要具有良好的可扩展性，设计时一定要将目光放长远。本文将以后台订单系统为例子，深入浅出地阐述后台产品设计时的要点和难点。看了之后，你自然会知道为啥很多经理不愿意做后台。
零基础产品转型方案专家——随心：金融领域产品专家，北航it项目管理硕士，10年it及互联网行业经验，负责阿里钉钉一体机产品，蚂蚁金服金融一体机产品等。本人曾帮助上千位0基础0产品经理经验的小伙伴成功转行产品经理，如果你是销售、你是UI、开发、项目经理、运维工程师想入职产品经理岗位，可以加我微信chanpin189 为大家提供快速0基础转行产品经理一对一指导和产品面试方案。
2、电商订单系统
从广义角度来讲，一切可以在网络上进行交易的业务都可以归到电商的范畴。电商发展至今，模式形态已然非常丰富，包括O2O、新零售等概念在内，最终的交易环节可能提前可能置后，可能在线上也可能在线下，但基本的用户转化路径是一致的，即：找商品-看商品-下单订购-钱货两清-完成-（售后）。
看看下面这几个场景：
- 这件商品的运费竟然这么贵！我不要了。
- 银行卡里钱不够了诶，算了不买了。
- 这物流好慢啊，等不及了我要退货。
- ······
是不是很熟悉的场景呢？
可能你会问，有些场景很极端吧，比如：我真的很想要这件东西时，怎么着我都会去买啊。
确实如此，然而这是建立在你已经有了非常强烈的意向的前提下，让我们回顾一下转化路径：找商品-看商品-下单订购-钱货两清-完成-（售后），这个转化路径也是一个漏斗模型，每一环节都会有用户流失。为了尽可能提升转化率，需要在每一环节明确用户需求及需求场景，必要时辅助用户召回、创造需求等手段，来扩大去往下一环节的用户量。
如果你在进入第三层漏斗前，已经有非常强烈的意向，那么实际上你已经是一位不管遇到什么阻挠，都会进入最后一层漏斗的人。所以这里要讨论的，不是怎样让确定会转化的用户去转化，而是怎样防止用户因为或这或那的原因流失。
如前文所述，如今电商平台业务范围可以囊括人们的衣食住行，根据常见的服务类型，我们可以将电商平台做如下分类：
综合类：淘宝、京东、网易严选、小米有品等。
生活服务类：
- 快消类：京东到家、多点mall、每日优鲜等；
- 旅行团购类：去哪儿网、马蜂窝、美团点评等。
大宗商品类：链家、我爱我家、优信、瓜子、人人车等。
在不同的服务交易场景下，进入下单环节后用户关注的内容会略有差别，因此平台可提供的服务也是不同的，比如：针对综合类、快消类电商，用户非常关注物流速度；针对大宗商品类（涉及比较重的线下服务），用户往往关注下一步要去哪里做什么；针对旅行团购类，用户比较关注时间地点对不对，跟我的行程计划是否匹配。
因为用户的关注点既有共通性又有差异化，所以下面会从下单订购-钱货两清-完成（售后）环节入手，按照产品设计流程，剖析电商平台订单产品设计的要点及方法，并结合不同业务实例来分析共通性和差异点，方便读者理解。
3、战略层
首先订单产品的目标是什么？
1. 辅助用户完成最终转化
这是订单产品的核心目标，通过集结支付中心、合同中心、售后中心等等平台系统，来帮助用户一步一步走到该笔订单的终点，顺利抱得商品归。
2. 呈现信息流转
订单产品需要让用户明确下订后的每一节点是什么，并且提供用户与平台在每一节点就可能存在的问题的信息交互通道。比如：在付款后想要退货怎么办？物流环节发货太慢联系谁？配送环节想要改收货地点找谁等等。信息的流转需要与业务流程保持一致，给到用户有效的反馈和合理的信息通道。
3. 关联平台服务
订单与平台服务的关联，可以分为两种场景：
付款前：平台服务是帮助用户确定下订决心的。
- 比如：担心买的东西不合适怎么办？没关系我们提供了运费险，实在不行你能退货并且还不收运费；
- 比如：运费太贵怎么办？千万别走我们提供了会员服务，你看要不开个会员我们给你免运费？
付款后：平台服务是引导用户再来一单的。
比如：
- 列出你的常购清单（多见于快消品），引导再次购买。
- 根据你成交的商品，进行同类商品推荐等。
4、范围层
订单产品需要具备的功能是什么？
1. 订单基本信息：人、商品、钱、物流服务等
谁买了什么，花了多少钱，啥时候能送给谁，中间流通节点及关键联系人，这些就是一个订单基本的信息构成，拆分出来内容会比较多：
- 人：购买人、收货人、中间节点联系人；
- 商品：这件商品是什么？它的信息、数量；
- 钱：总价是多少，是否有满减、优惠券、购物卡、积分抵扣等内容；支付方式是什么，是否有发票信息等；
- 物流服务：配送方式、配送时间等；
- 其他：针对大宗商品，在下订时可能还需要签署相关合同、协议等（有趣的是，网易严选的下订环节中，不论何种商品均有服务协议露出）。
以上信息需要在不同节点进行不同的内容呈现。
2. 平台附加服务
付款前：运费险、退换险、会员服务等减少用户后顾之忧，促进用户下单的服务。
付款后：针对已购商品的售后增值服务、针对下一单引导的再来一单、常购清单、常买店铺、同类商品推荐等。
5、结构层
我猜经过范围层的信息汇总，已然觉得订单是项浩大的工程了吧？
作为用户转化流程的末端，订单需要串起各项业务系统进行内容呈现，并且针对每一节点建立用户和平台之间的信息通道，也就是需要将业务流程与用户节点进行映射。
这里用大宗商品二手车交易进行举例（该流程涉及到车主和买家两条线，并且有很多线下服务环节），针对车主和买家，分别有对应的业务流程和订单节点，设计的核心在于，将多种业务流程节点进行统一，映射单一的用户订单节点，节点内的具体信息，根据业务规则而变。
具体解释一下，就是比如一辆车在买卖双方确定成交后，需要对车辆进行二次检测，从成交后到确定检测时间地点这段时间内，车辆处于【等待检测】节点，此时该笔订单是由销售负责维护的，买卖双方有任何疑问，可以与销售联系，在订单节点中给用户展示的信息出口，就是【联系销售】。
而当该笔订单确定了检测时间地点后，此时车辆仍旧处于【等待检测】节点，但业务系统中负责维护订单的已经由销售转变为检测人员，此时订单节点中给用户展示的信息出口，也就变成了【联系检测师】。能够看到上述节点一直是【等待检测】，但实际上对应了两个业务节点，因此对应了两套节点内的信息。
下面是隐藏了业务节点的订单信息结构，可以看到在这里订单主要涉及的业务系统有客服、评估师、编辑、销售、售后等。对于诸如淘宝、京东等业务线复杂的平台，订单系统还会对接促销、会员、支付、物流等系统。
因为订单系统对接的业务系统较多，后端逻辑非常复杂，因此在设计过程中也需要循序渐进，同时保证良好的可扩展性。
6、框架层
到了框架层这一步，重点如下：
- 提炼各节点核心信息
- 排布设计遵循简约至上原则
订单的每一节点包含的信息分为两部分：之前节点的关键信息和当前节点的关键信息。
之前的节点信息，是用来帮助用户在必要时进行信息回溯，一旦有任何问题，可以高效得同平台进行沟通，也就是让用户心里有数。当前节点的关键信息，则是需要让用户一眼就能看到的内容。
比如：针对【待支付】的订单，我们需要将订单状态、待支付金额及剩余时间放在首屏位置；针对【待收货】的订单，则是物流信息突出；像外卖类订单，由于整个订单的完成周期较短，用户非常关注何时能收货，因此某时刻商品的位置是重点信息。
在这里想重点说说京东和淘宝在订单完成后的框架结构，从下图可以看到，京东认为用户在订单完成后，若再来看订单，核心关注的可能是【我以前买了什么，现在还想买】，因此将订单商品相关的同类商品、同类卖场做了突出，隐藏了物流信息、订单详情。
而淘宝认为用户关注的，是【我之前的订单可能存在的问题】，将订单的物流状态、订单详情全部显示了出来，并没有在这个节点做过多的运营动作。
究竟哪一种设计是对的，需要根据数据来进行分析，可能两个平台在此处的设计差异，也是经过了数据分析后得出的结论。
7、表现层
表现层的重点是配合信息框架设计，进行视觉层面的引导。之前的框架已经将核心信息进行了提炼排布，视觉方面就需要根据这种排布，用规范化的视觉语言进行产品的最终描绘，此处就不做过多延伸了。
8、总结
- 订单产品首先是一个工具属性的产品，是用户与平台在转化的末端进行信息交互的载体；
- 其次可以是一个运营资源位，通过对用户的之前的购买行为进行种类、频次方面的计算得出用户的偏好，加以二次转化引导。
零基础产品转型方案专家——随心：金融领域产品专家，北航it项目管理硕士，10年it及互联网行业经验，负责过中国银行积分购物网站（千万级用户）、中国银行快捷支付平台（京东、驴妈妈、途牛等千家商户、千万级交易量），曾著有银行快捷支付平台设计与实现、电商平台整体运营方案等，同时获得20余项it技术发明专利。
本人曾帮助上千位0基础0产品经理经验的小伙伴成功转行产品经理，如果你是销售、你是UI、开发、项目经理、运维工程师想入职产品经理岗位，可以加我微信chanpin189 为大家提供快速0基础转行产品经理一对一指导和产品面试方案。
相关阅读
互联网产品经理面试题总结？_ 比邻学院_ 产品手记比邻学院_ 产品经理学习交流平台产品经理需要懂技术吗？不是计算机专业想做产品的应届生出路何在？_ 比邻学院_ 产品手记比邻学院_ 产品经理学习交流平台产品经理，负责的产品数据不好看，该如何在简历中扬长避短？_ 比邻学院_ 产品手记比邻学院_ 产品经理学习交流平台区分「优秀产品经理」与「普通产品经理」的标准是什么？_ 比邻学院_ 产品手记比邻学院_ 产品经理学习交流平台从简历开始重构自己，让人一看就想约_ 比邻学院_ 产品手记比邻学院_ 产品经理学习交流平台1. 产品性质：前台 to C，后台 to B。
后台不能主导产品，主要任务是管理，辅助前台。前台对接的是C端用户，后台对接的是B端内部人员。这两者在数量上不是一个量级。
前台主要是吸引用户，让其通过完成操作，或得到有价值的信息，或解决其问题。后台主要功能是GTD，而不是体验。前台的优化围绕着用户为什么来？来了能干什么。后台是保证能用，然后继续做下一个需求。啥，你说后台优化？这个还真没时间。
后台主要是管理，主要为5类：产品，事，人，钱，数据：
- 产品本身：产品维护，增删改查。如商品的上下架，活动管理等。此为运营的主要工作之一。
- 事务性：各种内部流程，如审核，商家入住审核，客户的签约审核等等。后台复杂所在。
- 用户管理：对外的客户管理系统（crm），对内的人员架构管理，角色的权限管理，等等。
- 数据分析：收集前台的数据，整合输出，展示分析。运营人员看重此点。
- 考核结算：升降级，销售人员的业绩提成的计算等等。（有业务需求的产品涉及）
前台的需求出于对市场和用户的把握，依靠数据的分析，找到用户的痛点和引爆点。而后台的需求主要来自于和各部门的沟通（或争论），而非对用户的感觉和数据分析。在销售型为主的公司的话，后台技术人员反而会被业务压制。
前台产品有试错的机会，不断的调整方向，完善产品。但是后台功能上线即要直接使用，简单粗暴。出于这个性质，后台的坑很多。前人可能为了满足一时的需求，而忽略了重复性，扩展性。那么后期需求稍变，可能需要重做。
前台的产品设计一般流程为，根据想法和创意，收集市场上的竞品，对比分析之后，调整产品的切入点。根据了然于胸的功能和版块，就可以开工了。但是后台开工之前，要做的就是要把所有流程理清。答主上次项目配合前台做退款，前台按钮进入需要对应后台8种不同的流程。
3.一个事实：看脸
现在是看脸的社会。前台专门的UI和前端设计，尽可能的优化展示，用的最多的词是“用户体验”。以获得好感。但是后台基本只是功能的满足，不对接UI和前端，程序员直接操刀上马，听的最多的是“功能怎么还没上！”。因此，页面你懂得。
前端页面，各种最新交互，如H5、响应式布局，等等。一切都是美好的。后台，基本上是千篇一律的左右结构。左边一般为是两级菜单目录，右边是操作页面。三级的话在操作界面增加tap切换。
在颜值上，后台只能一个人默默的蹲在街角迎着寒风吃烧饼。
当体验产品的时候，下了众多app。看的、说的，对比的交互，用起来的体验，同伴间的交流，都是前台。我们在36氪看到哪哪又融资，资本又投了哪家公司。然后膜拜的也是别人的前台。
但是，每一个光鲜亮丽的网站背后，都有一个烂成渣的后台。这话适用于每一个网站。
假设你是一个女生，羡慕着商场里高冷贵的白富美们。在思考，自己如何能成为那样呢？这就需要对自我的管理（后台），然后呈现出想要表达的姿态（前端）。前端就是舞台上的明星：考虑唱什么歌，说什么话，什么时候煽情，什么时候卖萌，引爆演唱会现场。而后台就是灯光，舞台布景，特效，字幕，化妆，服饰，录像等等。
4.PM的定义：改变世界
产品经理的引导趋势：PM是CEO的预科班，用产品改变世界。
意思就是，发现了新的需求，然后设计产品满足之。然后出现就差一个程序员的商业计划书。这个时候的思量，也完全是前台的立场。
大概一个不想当CEO的产品经理，似乎不是一个好的汪汪。
5.一点看法：
无所谓喜欢还是不喜欢做后台，都了解、做过，甚至精通，才能做出更符合目前产品的决策，务实的决策。
然后，才有了对比，在选择选择的领域，想做前台就是前台，想做后台那就后台吧。全部统筹更佳。
懂后台架构、流程、逻辑的前台，似乎是极好的。就像产品经理要懂技术吗？这不是必须的，但是懂一些是极好的。就像产品经理要懂UI设计，色彩搭配吗？这不是必须的，但是懂一些是极好的。
可以不做，但最好懂一些。为什么很多产品经理都不愿意做后台？
很多人回答是，因为不会。确实如此。详细的内容 @郑坚义已经阐述的差不多了。
作为做过后台产品的人，我希望从另一个方面来聊聊原因。
先摆结论：
很多产品经理不愿意做后台是因为对后台产品有错误的理解和认识。
错误1： 后台产品很难
有些人会觉得后台产品牵扯面广，沟通难度大，推进起来很困难。即使能推进，但是业务逻辑复杂，关联性强，千头万绪不知道如何下手。
先说第一个：沟通难度大。
诚然，越大的公司沟通难度越大，不管做什么都一样。后台系统根据业务的不同，会涉及到很多不同的部门和同学，而大部分时候大家对你的支持力度也有限。但是，正因为涉及广，强沟通才有做的意义。设想一下，有哪个产品能让你快速和公司各个部门的同学建立联系？凭借内部产品，你可以快速的把公司核心部门，重要的负责同事都认识一遍，扩大朋友圈什么的就不说了，单说在这个过程里，你会逐渐发现不同人身处不同角色，承担不同责任时候的不同想法和不同视角，都能让你受益匪浅。你会发现张三的需求也许是李四想要避免的，老王的想法似乎和小李是一样的，中国人又很多事讲究犹抱琵琶半遮面，你在逐渐沟通的过程里，本质上是在了解不同人的过程。同理心很大程度就是这么来的。
尤其如果你以后想创业，哪怕是做个自己的小生意，不在具体岗位上，不承担具体责任，单凭想象是无法明白对方的需求。而这段经历，可以让你非常好的通过认识不同岗位的人，了解不同岗位的想法，有些坑，你可以记着；有些捷径，你可以借鉴；甚至有些人，说不定以后就是合作伙伴了呢。
第二个：业务复杂，需求难度大
一般来说，后台产品分两种：从1到1.1的维护型和从0到1的开创型。
对于第一种，你只要花点时间就可以完整的了解前人的思路和框架，这比开发同学不知道幸福多少倍啊~并且这是一个宝贵的学习过程，每个公司的常用后台都是宝贵的作品，他可能是好几代人的心血。以前在EX，我们就经常开玩笑说，整个公司最值钱的就这套后台系统了，虽然它很丑。通过了解，你可以难得的高屋建瓴的俯瞰整个产品，他的思路，他的逻辑，他做的好的，做的不好的，能适应现在业务的，不能适应现在业务的，都能看得一清二楚。我就是因为曾经在EX里思考过我们的那套后台系统，之后创业做的后台避开了很多陷阱，少走了一些弯路。
对于第二种，机会就更难得了。确实一开始会千头万绪，但是人生哪件事不是看起来千头万绪的？我一直相信，一个产品经理没有从头做出过一款逻辑复杂的产品是没有职业快感的。说白了，现在很多APP也好，web也好，不管你主观上想不想抄，都会或多或少受到影响。而且很多事情，毫无逻辑性可言。产品经理的价值真不是死磕像素练就像素级眼睛，真不是死磕放左边还是放右边自我陶醉在强迫症里，真的不要没有乔布斯的命，还得了乔布斯的病。
错误2： 后台产品没有成就感
没有成就感是后台产品被很多人鄙视的另一个重要原因。其实关键看你怎么定义成就感。
我第一份工作就是做一个后台系统，当时刚入行，有个主导这个产品的同事每天看起来都非常嗨，尤其是一些精密的逻辑规划好后，总会情不自禁的拉着我跟我讲解他的思路。我一直记得他的那种表情，嘴上说着“这个其实没什么，很简单的”，脸上却是不由自主的带着很骄傲的笑容。当时他经常和业务部门有沟通，专门有个业务部门的同事配合他，经常看到他们俩开会的时候互相吹捧，自乐其中。
坦白说，那套广告系统我至今都没搞懂，也正因如此，他无可替代的价值才体现出来。我很感激我第一份工作是做这种事，没有百万千万级的用户给你分析，没有数以千记的用户反馈给你研究需求，没有无休止的争论这个配色那个位置，没有人跟你扯“用户不喜欢这样”，“用户不是这么想的”。有的只是踏踏实实的做东西，严谨细致的构建业务逻辑。这种踏实做事的感觉，何尝不是一种成就感？
后来我去了知名互联网公司，可以负责千万级用户的产品了，但是港真，有时候看到后台那些七八位的数字，就感觉是数字，只有翻着用户反馈的时候，才能感觉到自己是在面对的是真实的多人。有些人会觉得，你一个改动影响百万千万的人是成就感，但是这种成就感是你站在现有平台之上的成就感，而不是你智慧结果的成就感，换言之，其实与你无关。
现在我在创业公司，从网吧式办公环境里开始设计我们的业务后台，我的成就感之一就是我把很多所谓前台的产品理念成功运用在后台产品里。举例说，大家都知道后台产品堆叠功能其实很容易，反正是给自己人用的，大不了出个说明文档，虽然没什么人会看。但是控制功能的无效堆叠就很难。我把这个作为自己的挑战，虽然后台做的还不够完美但是我的成就感达到了。我们一个模块的东西可以同时应付多个业务的功能需求，就算不能直接处理，简单的改动之后就能适应。我自己使用过功能庞大，业务重复的大型后台产品，所以深知这种痛苦，我在自己的公司自己的事业里解决了这种痛苦，难道没有成就感吗？
错误3：后台产品对个人没有提高
我前面说了那么多，你认为对个人能力有没有提高？
人呐就都不知道，自己就不可以预料。一个人的命运啊，当然要靠自我奋斗，但是也要考虑到历史的行程，如果以后命运告诉你“我们已经决定了，你来创业”，而你欠缺后台经验，难道你忍心回答“另请高明”？所以产品经理什么都不需要干，只需要干三件事就行了：
一个，做一个完整的后台产品，确定严谨细致的逻辑框架；
第二个，把后台产品的思路纳入未来其他工作里；
第三个，就是做一个面向用户的产品。
如果说还有一点重要的东西，就是后台产品经理一定不能太纠结细节。这个对产品经理命运有很大关系。当你经历完之后，至少不会感觉惭愧，不会感觉只做了一些微小的工作。
希望每个产品经理，都能以后由衷的说句：我搞得这个东西，一颗赛艇！这个事情我有一点发言权
1. 浮躁。这是刚入门乃至初级产品经理的通病。总觉得做一些酷炫叼炸天的产品功能和界面才会让自己有成长，缺乏耐心，不思考产品价值。
2. 没有这个能力。浮躁的人会拒绝一些自己不擅长的事情，而不是勇于挑战这些事情。做前台产品和功能大家都看得到，也有很多可以「借鉴」的思路，做后台产品，没有什么可以借鉴的模式。何况做后台还需要非常懂业务。
3. 大多数公司或团队对后台产品重视不够，也没有很好的激励制度去激励产品经理去做好这些事情。这会给不少人传递错误的信号，他们进而会做出错误的取舍。
最后说一句，后台做不好的产品经理不是好的创业者。
一个产品经理，职责其实很大，能调动的资源很多。需要较高的要求。也需要很好的学习能力。
另外，我一直在找愿意做后台的产品经理。联系我难道不是前后台必须同个人做才能事半功倍吗？总是后台、web、以及各种客户端一人做的路过。小公司的产品经理必须十项全能啊。
P.S.我喜欢做后台，也喜欢做前台，喜欢画流程图用例图各种结构图，也喜欢画界面，喜欢做交互，前后台严丝合缝的配合，才完美！不喜欢做的事情是接手一个屎一样的产品，还没有任何文档，理来理去，修修补补，各种填坑......简单讲几个观点:
1. 不具备足够的业务知识, 无法构建整体的后台业务框架. 而前端可以"分析竞品", 后端可以"借鉴"的有限.
2. 产品经理在见识, 战略高度, 以及职位对等的沟通对象不够格的时候, 只有把更多的精力投入到 Consumer Facing 的技能上, 例如 UX/UI, 当然这也是无可厚非的过程.
3. 外部用户(消费者)更容易被引导, 可能遇到的 challenge 是相对可预知的, 但内部的"老鸟"用户往往自带知识, 观点, 及非顾全大局的私心, 这些可能会误导知识体系不够强的产品经理, 还有一个问题是初级产品经理在软技巧上能力不足, 很难搞定他们.
4. 公司管理层对后端产品要求较低, 缝缝补补能用就行 (这个我们很多人都需要检讨), 导致产品经理在前端方面更容易出头, 浮躁地涌向前端.楼上的各位讲的都很好
首先对于后端的定义：
- To B的
- 平台型产品（ @天顺 童鞋的回答及专栏）
- 公司各种业务/服务部分的系统（包括不限于：财务、客服、CRM、ERP等等）
结合身边发生的一些小故事，讲一讲可能存在的原因
1、－1至3年的产品新人，都感知不到后端的存在
故事：有个在VIP工作两年的学妹，主要做的都是App端。某天闲聊说，有个创业团队做目的地陪游的创业项目，让她兼职做产品，咨询下我的意见；对于产品有余力做其他项目一向比较支持，但是想到她没有后台经验，就确认了几个问题：目的地陪游项目的地陪人员怎么管理？旅游路线由谁来制定？定价机制是？怎么处理双方交易和结算？以及出了投诉该怎么处理？学妹愣了一下，说需要一个平台型的产品来跟她配合
作为一个已经在大的电商公司有一定经验的人来说，在面对一个新的产品模型时，没有系统性去思考产品，以及业务流转的完整模型；再加上现在主流的产品成功学宣传，都是某个伟大App多少用户，交互多牛逼，界面设计多好看，体验多好；导致绝大部分刚入行、甚至准备入行的人根本看不到后端（产品架构）的存在；都不知道有这个东西，怎么会去往后端发展呢
PS：楼上很多产品也都表达了，基本是入行后，或者被动选择才去做后端的
2、爹不亲，娘不爱；做的不好还要被踹
故事：亲身经历在一家电商创业公司。CEO天天拿着app跟美团淘宝比，你的搜索筛选少个啥条件，你的UI设计没有美团好看（当时都没有专职的UI设计师），商品展示页面图片要大。。。反正每天被搞的晕头转向，伺候老板做需求。对于后端需要新做个to B端的app，直接一个月内上线，包括账号体系、物流、库存管理、SKU对接、财务等等等等功能，结果肯定只有呵呵呵呵（C端和B端两个App的开发只有五个人，没QA，而且用户端节奏不变）
能够明白后端价值的老板、团队、甚至很多产品老大本身都很少，冰山理论更没几个人真正理解。因为你提出来后端价值的时候，都会以“能用就行”，“现在不是重点”，“以后再说”等等搪塞过去；既然公司是这个态度，后端产品自身的成就感、工资收入、以及传承与延续性都得不到保障
3、后端的起点虽低，但是天花板更高（模块化设计，可拓展性，整体运营效率是否提升）
故事：关于美团和点评的爱恨情仇，有各种解读；个人理解其中平台系统对于业务的支撑，其实帮助美团领先不少。对于两家都近万人的销售团队管理，其实本质是效率的竞争，因为在团购行业团单的数量会直接带来团购交易额的增长。对于销售的考核就是最终交易额（结果指标），与交易额紧密相关的则是拜访量（过程指标），美团比点评大概早一年开发出移动端的CRM，通过移动端CRM的管理会大大提高销售童鞋的拜访量，最终带来个人签单效率提升，最终到交易额的提升
另外个人比较佩服美团后端架构系统的设计，详细参照文章：美团O2O供应链系统架构设计解析
（PS：原文地址发布于http://tech.meituan.com/，可惜被美团删掉了）
很多公司都是那个新人来做后端，满足于眼下现在的需求；而新人是完整考虑整个业务线，以及未来的发展；上文中提到，美团优惠买单业务完整供应链开发只用了5人日，而之前需要30人日；作美团优惠买单的参照对象点评闪惠，其中花费的时间＊＊＊＊＊＊
4、后端需要更强的能力（业务深入理解、项目管理、还有撕逼等）
前端产品和运营都是爷，一般配置的资源会远大于后端，没办法，谁让用户都是抱着：我是你爹！的态度来用你产品呢；那后端产品往往会通知对接N个前端需求，如何供好前端这些大神么，就需要后端要精通各种体位的跪舔姿态，跪完需求方再回来跪技术，做好了应该，做不好各种抱怨、投诉、喷子都会出现
前端和运营都爽的咧，今天来个满减，明天来个赠品，后天再发一波券，再后面还接个支付渠道的折扣红包；发券一时爽，后端火葬场；哪些是运营支出，哪些是费用，哪些是成本；赠品算不算库存，赠品算不算正常商品的调用？甚至A团队跟B业务的还有各种收入与支出的比例，这些难么？其实不难，但是对于新人想要深入理解下去，门槛绝对比前端产品要高不少
5、能够培养好后端公司不多，且大部分人努力程度不足以拼公司
业务变了流程重新梳理；发展快了要及时重构；更多的公司和人都在堆产品，所以某OTA公司对外说业务太复杂了，新人进来半年都在熟悉业务和流程；而后端产品能否定期去复盘流程，及时的梳理，并深入业务一线去了解客户和用户需求变化，更多采用懒的策略，就是堆功能呗，功能越来越多，后台越来越复杂，仔细去看看，大量的后台可能使用频次和需求早就到了该抛弃的阶段
平台产品难招确实，但是其实在咨询行业培养了不少业务梳理的能手；为啥不说高手，因为可能对于业务快速变化，互联网的规模协作等是短板，不过相信需求缺少会增加供给，也祝各位在后端的路线上发展顺利
一句话简要概括：
“后台产品经理不受待见的根本原因是企业管理能力低下”
后台产品不受人待见的原因，看起来主要是对产品人员素质要求高，逻辑性强还得精业务。实际在互联网行业，大部分的中小企业所推出的产品和服务，其后台系统之烂是BAT级别系统的后台产品经理所无法想象的，在中小企业的经营条件下，维持企业经营，保障业务发展是第一位的，在这个条件下后台产品经理被牺牲看起来是非常顺理成章的事儿。
而在大企业，这个情况却恰恰相反。由于企业提升规模后，经历过了管理混乱的黑暗时期，因此无论从人员组织架构还是IT信息系统来讲，都有了长足的发展，在这个情况下企业对于后台的建设重视程度会分外提升，这时候就极其需要精逻辑、懂业务的后台产品经理出马来维护和迭代系统，这时候无论企业中层还是高层都对自身企业管理有了深入的认识，业务导向和流程已经明确，作为企业需要精于业务分析、逻辑思考的后台产品经理来make it better。所以才会出现题中完全两极分化的讨论结果。
说回小企业，对于小企业来说业务发展随着阶段的不同产品经理的侧重点也大相径庭。对于初创型的项目而言，快速布局业务，快速发布可用的产品，使得业务能快速run起来是最重要的，在这个状态下暂时牺牲一部分后台系统是必要的。而随着业务的发展和企业规模的逐渐扩展，随着管理问题的凸显，对于后台产品的抱怨也会随之而来。在这个过程中如何感知，并深挖管理问题，这才是作为后台产品经理做好的真正要点。在这个过程中如何对上管理，向管理层引导灌输管理理念，如何通过后台产品来影响组织结构是需要后台产品经理深刻思考的问题。而逻辑能力、业务能力等只是做好后台的基础。
总而言之，大企业小企业对后台产品有截然不同的偏好，这是企业发展所决定的，不受行业舆论导向而改变。需要改变的其实是产品经理自己，根据企业的所处阶段，为企业在产品层面谋求价值才是产品经理的生存之道。
看完了楼上所有的回答后，深有体会，我也想通过自己亲身的经历来分享自己的感受。回答的总体思路如下：
用户调研（略写）>用户需求（略写）->产品需求（干货）
用户调研：
没有仔细与提出问题的知友沟通，所以仅凭自己的理解列出用户（提出问题的知友）的痛点：
- 为什么身边的PM都想做前台，尤其是移动端的前台？
- 为什么大多数PM不想做后台的PM？
- 后台PM与前台PM的区别，希望可以从难度、收获（成就感、钱）进行分析？
- 是不是以后没有人做后台PM，都去做前台PM？
用户需求：
分析：“身边的PM”有可能是指“后台PM”吧，因为我就是一名标准的“PC后台PM”，身边也有一些同事也是说同样的话。老是吐槽一些前台PM钱多事少离家近，自己钱少事多离家远~~~
转化：知友更多的是想知道“后台PM”真实遇到的一些事情，以及“前台PM”尤其是“移动端前台PM”真实遇到的一些事情；
解决：后半部分非本人专业，解决不了（超出能力范围），我下面仅提供：
“后台PM”真实遇到的一些事情，以及自己的看法。
前方高能
前方高能
前方高能
产品需求：
“后台PM”常见的事情：
1、业务能力：业务为本。如果你刚来到一间中小型公司（不排除某些大公司）尤其是你负责的后台系统经营了几年，那基本上你会可能发现这些问题：系统功能紊乱；身边的业务方、运营方、研发、测试都比你懂需求；群雄撕逼的时候，你安静的做个美男子；原因是后台系统大多是维持公司制度或者业务的正常运转，你业务都不懂，你BB个啥，别人会听你的吗，研发测试都比你更懂需求。难度大，对吧？
2、借鉴能力：可借鉴少。你来了一段时间后，想做一个新功能，业务知识也懂了一些，这时你可以会发现这些问题：这个功能竞品公司后台是怎么做的呢？其他大型公司后台是怎么做的呢？想了一下后，你大多会看看自己公司后台之前PM是怎么做类似功能的，然后你着手就···；比起前台PM有竞品类似功能的参照。难度大，对吧？
3、产品框架：乱。习惯了一段时候后，你可能会发现这些问题：怎么一个一级菜单下十来个二级菜单，怎么之前的PM没有好好梳理一下，留下一些可参考的东西，留下一些可学习的整理好的业务知识框架呢？后来你可能会发现：哦，前方业务瞬息万变，迭代速度已经很快了，哪有时间去整理，公司有闲钱也会把前台拾掇拾掇，终端用户使用起来体验更好点。难度大，对吧？
4、心态：轻浮。我个人觉得成就感不强是源于心态。你刚来的时候，可能是怀揣着“改变世界”的理想，分分钟想数据翻一翻。可接触一段时间后，你发现“产品经理”中的“经理”是唬人的，是虚的。你可能会发现：你越来越不爽了，天天被业务方、需求方、研发测试追的问，你越来越觉得自己时间不够，很忙却不知道做了些什么，你开始会幻想，前台PM是不是更容易，他们是不是不用做事就可以迎娶白富美。难度大，对吧？
5、基本功：一般。我觉得“产品经理”是个“互联网”衍生出来的“职业”。行业没有统一的定义和标准。你觉得自己能力很强，可你做事情会发现力不从心，比如你做不好甚至不知道产品经理常用工具、产品经理需求的能力。很多人只知皮毛，你知道流程图，原型，PRD真实的使用场景吗？难度大，对吧？
6、逻辑能力：一般。你或许上面的条件满足了，可你接着可能会发现这些问题：怎么一个按钮竟然隐藏着N个逻辑，而且这些逻辑与逻辑之间还有内在联系，会相互触发，这不就是一个按钮而已吗？是的，后台系统功能竟然是一两个界面就可以搞定，但界面的触发条件有些复杂到你要捋很久很久，没有思维严谨的话，你真做不来。而且做这个功能的产品经理可能已经离职了，可能已经忘了，文档里可能有好多写不清楚。你要怎么办？难度大，对吧？
7：实用性>炫酷性。这不用说，你懂吧。难度大，对吧？
8：趋势：PC
那我吐槽了很久，想说明什么呢？
-----产品经理都应该有一种必备的能力：解决问题的能力。
请各位看官大方点赞哈，如果觉得有什么建议请评论一下哈。
你不经意间的小举动对我有很重大的意义，谢谢。
码字不宜。不喜勿喷。转载随意。
为什么找个产品助理的职位都这么难？ - 知乎用户的回答
问题是“为什么很多产品经理都不愿意做后台”
我理解这些产品经理还算是知道有前台后台这个区别，并不愿意做的
原因上述答案基本也讲的很清楚了，对非互联网行业出身的很多老板来说脑子里根本没有后台这件事情，对PM本身来说后台不可见，无法作为炫酷的成果展示，薪资低，上升空间有限等等......
个人延伸几个看法：
- 大公司相对这种情况会少很多，偏IT的公司这种情况也会少很多，毕竟能成为有一定规模的公司没有后台还是不太可能成为这种规模的......所以，遇到压根不重视后台的公司，基本可以绕行
- 更多的情况是很多PM不了解后台的意义，甚至不知道后台的存在（so sad！）
- 对很多创业公司来说，老板着急拿出一个demo级产品（非正式产品，能完整跑通业务的产品）给投资方看是最紧要的，关心程度超过了自己的业务支撑系统是否ok，基本属于一种饮鸩止渴的做法，就算拿到钱了也很难支持后续发展，无非是重构又重构......时间蹉跎过去，下一轮钱再也没有指望
- 不重视后台这种恶习，一方面是体现并不是真的想好好做事的急功近利心态，一方面是体现老板和高管的相关经验缺乏，另一方面会给公司内部业务支撑部门造成巨大的困难，财务、审核、风控、内容运营、用户运营、商家运营等等，工作条件都不具备，绩效出不来，数据看不到内容录入不进去......GOD！非常容易导致员工流失。
- 大部分公司还是需要以运营为驱动力的，对运营后台不重视，直接把运营后台扔给研发做是非常不负责的行为，并不是对研发有偏见，工程师如果具备经验或者产品sense的话还ok，如果没有经验又没有责任心的工程师来做后台，各种反人类的设计足以拖垮一个公司，参见第四条
- 我个人招PM是不喜分工，必须一起来
- 此问题里大量靠谱PM，我是猎头和老板就来这里挖人
以上。
前后台产品都做过。在软件IT公司做过4年的需求分析师。主要是梳理业务的。那会儿做的工作是2B的。用户群体覆盖面极少，且相对C端是专业的用户。后来看着互联网热闹，尤其是移动互联网热闹。转投去做了前端。做了2~3年的前端后，严重的感觉到前端更注重的是颜值（UI、交互）好看好用。业务逻辑性的东西都在后端。
后续也接触了一些产品经理。也接过做成一摊shi的项目，在烂摊子上面优化迭代的。越发觉得现在只做前台的产品经理大多太水了。（当然牛逼的人也是有很多的）
想来不愿做后台的产品经理也是业务撸不清楚，或者说不会撸业务，分分钟被研发秒杀。更加不懂得基础的web端界面规范，只专注于移动端。
后来加之前台功能零散也没有线性的业务关联，必须与后台配合使用。而且变化太过快速，自己又是按部就班的人。最后又回归后台。
现在几乎前后台都一人负责。毕竟一个产品硬是要去拆分出前台后台来，当中的业务关联，逻辑算法出错的风险概率还是蛮高的。版本迭代进度也是极好把控的。
个人对于前台后台的理解是：前台是颜值，后台是内核实质。
若想真成一产品，怎么可能只偏重一侧呢
后台产品经理
以我自己经历的项目和身边同行朋友的经验，项目的产品leader都是在全部或部分职业生涯中做过后台产品的；直白的来说，同样的工作经验，后台pm的工资是同样优秀的前台pm的1.5倍以上。
自己刚毕业时做过一年的前端产品，后来临危受命负责项目的整个后台，并逐渐迷上了这块。结合2年的后台经验，我认为后台pm最看重逻辑思维能力、对所做业务足够熟悉、项目需求管理和推进能力、后台设计架构可扩展性兼容性高这几块。
逻辑思维能力
一种是系统内的逻辑。后端系统在页面设计方面要求不会非常高，只需要做到布局清楚，做好提示减少误操。如同做支付的人经常讲路由和成本，其他后端系统也有类似的考虑，就是信息的路由。
一条请求发过来，不管是要查询信息，还是要执行某个操作，都离不开系统内几个模块的信息流转和同步。这条请求包含哪些数据，对数据需要做哪些处理，处理是人工做还是系统做，如果是人工做，还需要有系统的校验和保存，处理后提供什么要的结果，结果如何展示，是否需要把结果通过接口或批量报表的形式提供给其他后台模块。往往在思考这些问题的时候，一张清晰的数据交互时序图，可以帮助你解决很多问题，也更容易把你的想法传达给开发同事。
另一种是写后台PRD时的逻辑。比如一个功能点，逻辑思维一般的人描述可能就是实现了xxx功能；而一个逻辑思维严谨的人，会清晰的描述出，前置条件，触发因素，产生结果，系统处理规则，默认是什么样，有数是什么样，数据多了是什么样，异常是什么样。总结一下，就是条例清楚的表达出需求的来龙去脉。
充分跟需求方沟通，然后思维导图罗列出功能架构，再基于这些，做逻辑图。思路一定要清晰，否则很难推进下去。一定要尽量想的全面，别到时候需求评审时候，这里有问题，哪里不全面，会被开发笑话的。自己不清楚的时候，别指望别人能清楚的理解你。
熟悉自己在做的业务
熟悉自己在做的业务，是需要对服务体系内的业务流程足够了解的，因为你设计的后台是要去帮助他们更好的处理业务，你对业务流程不够了解的话，设计出来的产品就会不贴合实际的使用场景。
对于业务的理解，可以概括为三点：
- 前台有什么，后台管什么，比如最基础的用户管理、商品管理、订单管理、内容管理等等
- 对后台系统的管理，比如个人信息管理、权限管理；
- 数据管理，一款好的产品一定是用户利益和产品利益的结合体，而最能客观反映产品利益的就是数据，所以平台数据化；其次是逻辑思维，基本业务流程化、特殊场景特殊处理，与前台互动的触发机制等等
以自己在做的代购工具项目（自创业，已经成功卖给某电商平台），我需要去了解整个代购的接单流程，为此我加了十几个高质量代购群，并且自己把积累的这些认识的核心代购拉了个种子用户群，每日坚持在群里发红包向他们了解最真实的需求。为此我设计的后台中，除了常见的商品管理模块、订单管理模块，在此基础上我加了自建商品库（为了满足代购创建一些销量好，但免税店没有的商品，比如某几类杂志）、委托单管理模块和采购清单管理模块，委托单和采购清单的实际应用场景请自行思考，就当是课后作业，答对有微信红包。
项目需求管理能力
项目需求管理能力，我认为可以分为两块，需求池管理和明辨真伪需求。
一个比较大的后台项目，可能涉及到多个前端产品的需求，好多功能，比较分散，并且多线并行。这时候需要一个需求池来管理需求，我一般采用excel把负责的需求汇集成一个需求池，并上传公司内网，支持团队内小伙伴的多人在线编辑，随时更新各自跟进的需求的进度。需求池一般需要优先级、提出人、需求进度、预计上线日期等关键字段。
明辨真伪需求的前提，是懂业务！懂业务！懂业务！重要的事情说三遍。业务方的提的要求是一匹可以跑得更快的马，但是实际你要给他的是一辆车。在跟业务方聊天的时候，不一定要记住他要求你做什么，但是你一定要记住他提出来种种的原因和期望实现的目的。
再就是后台除非大版本大改动，否则基本上不会走版本，许多小改动当日改当日上，而且一般后台产品会对接多个业务方，需求排期整理也是个技术活……
另外，有些常见改动模块或者重复类功能，一定要做成灵活可配置，能帮你怼回去N多“白痴”需求。
对后续业务需求和功能的可扩展性
考虑后续业务的扩展，一个后台管理系统，是为了满足老板、运营等角色的管理需求。现在阶段的管理是为了满足现有阶段业务的需要，后续业务量上来了，一定要考虑扩展性。
举一例，运营人员后台上传照片时，如果你简单的想到一个button单张上传，可以满足现有业务的需求。但一旦量大了呢？上千上万张图片，一个一个button的去点么？
祝你在成为优秀后台pm的路上，成功迈出第一步！
对于选择培训机构，这里简单粗暴的给出两点建议：1.十几个人的小班授课，绝对要比三四十人的大班授课效果好，因为老师的时间精力是有限的，有些机构对外宣传自己是小班授课，其实是30—40人的“小班”，所以实地考察一看人太多，直接掉头就走就OK了。2.成立早的产品培训机构不一定就质量好，什么职业都培训的机构教学质量也不一定就不好，但是成立早的还始终专注产品经理培训的机构，质量一定不会差，不然早凉凉了，有兴趣的知友可以查看链接咨询学习：
