前言：人月神话告诉我们，我们不知道做什么可以成功，但是我们知道可以不做什么。
今天，我就给大家分析下，为什么产品经理都要做前端产品经理，而不是后端产品经理。
随着互联网行业的兴起，大量新型创业公司和传统产业公司转型互联网。这批资源有限或者不了解计算机科学技术的企业，以为产品就是可视化的产品，对产品在创始之前其背后的愿景完全不懂，也不规划，导致其后台程序维护成本越来越高。
举个例子帮助大家了解下产品规划，也了解下人性。
小王是一个后端产品经理，做的是内容管理系统。前期满足前端的内容需求，前端有“A”需求，后台就增加模块添加内容“A”，前端有素材需求“B”，就增加添加素材需求“B”。生活安逸而舒适，老板经常表扬小王工作认真踏实肯干。
突然，出现了“A”“B”“C”内容的组合，A、B、C之间还有协同和互斥的规则。小王弄了2天。终于捋顺了A、B、C之间的逻辑关系,老板看在眼里记在心上。小王最近可能有点其他事情，人嘛，难免家里有点事情。
突然前端又甩出一个需求，A、B、C组合投放到D、E、F上，还有时间纬度。这回小王彻底麻爪了，这些模块组合非常冗杂，再考虑扩展性，1-2周完全弄不出来。这样小王把扩展性去掉，模块写死。成功在2周内写完，老板一看，小王给力啊，升职加薪。其实小王心里知道，这么做是有隐患的。
又这样过了一段时间，前端又增加了几个模块。小王已经深刻的了解到了，这个系统已经崩了，开始寻找下家，这时候再加的后台需求就是只为满足功能、完全不谈模块设计了，只要能对付过去，就算可以。当然在老板眼里，小王一直是位好员工，踏实肯干，能力强。半个月后，成功找到下家，甩甩屁股走了，走了的时候，前任老板依依不舍，还要升职加薪留人。
小王走了，小张来了，都说程序员要做好代码设计，要不终究有一天你是要还的。产品也是，但是问题落到谁来还这问题上。小张注定接盘侠，小张看了下原来的后台。我去，啥玩意？这模块怎么放在这，他怎么想的？这个东西他考虑这种情况了吗?
最后他决定重做一版，这和让程序员改别人的代码原理极其相同。当他向老板反映说要重做后台的时候，老板虽然嘴里答应，但心里满是不悦，你看小王在的时候啥事情都没有，这又要重做多耽误事情。虽然嘴上不爽，但是毕竟业务还得上啊，答应了。小王要了1个月的时间。老板彻底震惊了，1个月，光设计？？？开啥玩笑，1个月小王能做5-6个模块了，你一个月就重做一个后台？啥都不变？搞笑吗？这能力也太差了。
小张很努力，开始选择设计模式的时候严格按照Saas和Paas模块去做，甚至数据库表结构都亲自参与设计。他想搞出来一个长久点的东西，至少1年半载的不会重建。
这时候，开发是非常难推动的，原因很简单，相似的业务流程，现在却按照更复杂的流程去设计。开发不开心、任务量也相对较大。小张心好累，项目推进困难重重。
最终第一版终于出来了，小张觉得自己的功夫没白费，可是事实却恰恰相反，小张被扣掉了10%的工资。小张明白了，原来后端产品经理和程序员差不多啊，老板看的是代码量啊。后来小张做东西也不做过多的考虑、也不做更多的规划，后来小张变成了小王。后来,后来……
其实这个故事已经深入的揭示了为啥后端产品经理是个坑，我来盘点几条，欢迎大家发散思维。
从属性上：后端产品经理被赋予工具属性，前端有啥你就得支持啥。都是工具了，当然不值钱了。
从成长上看，越多和交互、前端打交道越能增加自己对用户体验的理解。常说常见常练，肯定成长飞快。相对来说给予后台资源较少，很少产品的后台设计能让人觉得赏心悦目，爱不释手。
从荣誉上看，在一个团队里，负责业务玩法的人，一定是最受欢迎的人，用各种不同的玩法解决问题。而后端产品经理几乎与此无缘，更悲剧的是他与开发的关系可能是最激化的。因为他设计的是业务底层，规划的是产品架构。和他对接的低级的可能是撰写业务流程的PHP，高级的就是软件架构师。说服他们改变原有的工作思维和经验去按照你的搭建系统，你需要非常强大的行政职权，而这是一般的产品经理是没有的。
从薪水上讲，大型公司同级别的产品经理，前端和后端差不多。中型公司，后台的产品经理要高于前端（因为同等薪水招不到）。小型公司，后台产品经理却低于前端产品。
