文章内容由『喜马拉雅FM』产品总监李明泽，在『SmallTalk 2.0 第六期』中的分享整理而成。
** 文章版权由SmallTalk及演讲者共同拥有，如需转载请简信 **
SmallTalk的朋友们，大家下午好。今天简单跟大家聊一下后台产品的重要性。这个题目呢，听起来有点枯燥，有点老土，感觉没什么意思（为了撇清责任呢，我一定要跟大家说，这个题目是主办方起的，哈哈）。Anyway，对于今天大家的到场，我还是特别的心存感激，感谢大家愿意抽出一点时间，来跟我一块探讨关于后台产品的那点事。毕竟，后台产品或者说后台产品经理，往往是容易被忽略的一个角色。
自我介绍
OK，在我们正式开始这个话题之前，简单的做一下自我介绍。我叫李明泽，好像中文名有点拗口，所以大家也可以叫我的英文名Dylan。对，就是美国著名的摇滚、民谣巨星Bob Dylan的那个Dylan。稍微解释一下，这个名字起得还是挺有前瞻性的，起这个名字的时候，还不知道有一天它会出现在《乔布斯传》里，而被广大的产品狗熟知。
然后，Slides上有我个人的一些标签。这些标签基本反映了我工作这几年的经历，General的介绍就是大学毕业后直接进入大众点评工作，完成了管理培训生到产品经理的转型。去年的时候，为了探索一下大大的世界，结束了我在点评的三年职业生涯，加入了喜马拉雅FM。目前在喜马拉雅FM负责主播服务、内容生产及商业化三条产品线。
关于后台产品的经历
今天要聊后台产品嘛，那我就再多说一点自己关于后台产品的经历。坦率的讲，我接触后台产品的时间并不算长，大概两年左右的时间。在这两年的时间里，我主要接触的是点评的团购制作平台和大客服系统，中间涉及到一点点CRM和财务系统相关的内容，也算是基本见识过了O2O类公司的各种后台产品。
当然，在我有限的产品生涯里，我还做过纯C端的用户产品和商业产品，这些经历，也让我在回头审视后台产品的经历时，别有另外一番感悟。
TO B产品、后台产品，傻傻分不清楚
OK，前面的铺陈结束。回归正题，我们先简单的做一个定义澄清：当我们在讨论后台产品的时候，我们到底在说哪些产品？是TO B的产品吗？其实很多人提到后台产品的时候，往往就跟TO B画了等号。我不能说，这种看法完全错，但可以肯定的是，这样的想法并不准确。
什么是TO B产品？简单说就几种类型，第一种呢，就是面向企业服务的产品，最近比较火SaaS就属这类产品，当然很多我们熟知的C端产品，比如说滴滴打车，他们也推出了面向企业的产品；第二种呢，当然我们今天将重点研究的后台产品，它主要是用于支持企业的内部运营，比较典型的有ERP、CRM等；最后一种呢，其实我也不确定算不算，其实它应该是第二种的进阶版，就是平台型产品，这里我就不展开了。
所以呢，我的观点是，后台产品属于TO B产品，TO B产品包含后台产品。二者是不完全划等号的。OK，记住我们这个结论，后面我们可能会用到。
为什么很多产品经理都不愿意做后台产品？
好了，铺陈了这么久，终于要进入正题了。混知乎的小伙伴们应该看到过这个帖子，至少在产品经理圈里，这个话题一度有点热。为什么很多产品经理都不愿意做TO B产品？估计在座的各位一看这题目就有点懵了，刚才说了那么久TO B和后台的区别，开头的时候又跟我们说今天的主题是后台产品，这么又聊起TO B来了？是不是跑题了？别着急，听我慢慢说。
当初这个话题火的时候，作为一只也有个几年后台经验的产品汪，我也关注了这个话题。不过在我浏览这个帖子，以及众多知乎大牛的答案的时候，我发现了一个小问题。其实大家说的TO B产品啊，大都是再说后台产品。所以呢，这里我也就借着这个热门话题，换成一个更准确的关键词，聊聊这个困扰了很多后台产品汪的问题。
一些常见的“偏见”
为什么很多产品经理都不愿意做后台产品？我的答案是，因为“偏见”。（其实我更喜欢另外一位同学的答案，没记住他的名字，却记住了他的答案，他说“不会就不会，怎么还说成不愿意了呢”）那么，有哪些偏见呢？我大概总结梳理了一下：
1、做系统的也能叫产品经理吗？
不知道是不是大家在第一次接触产品经理这个词时候，就是乔帮主或者是龙神，所以给大家造成了一种潜在印象，好像产品经理，就是那些做出了我们大众消费者能够用得到的东西。而后台产品好像给我的印象并不是这样，后台产品大家更愿意简称为系统。那么一个做系统的人，也能叫产品经理吗？
请允许我傲娇一回，我不想说答案了，请有这个疑问的同学自行度娘一下，产品经理的角色定义是什么，后台产品经理的工作内容又是什么，两者是不是吻合？
2、后台产品不需要注重用户体验？
对于后台产品，好像有一种传统的观念：“反正是给内部人用的，做成什么样都可以，能用就行了呗”，所以很多人说，后台产品是不需要注重用户体验的。
这绝对是一个大写的偏见。我们说后台产品一个很重要的意义是什么？是运营效率。运营效率从何而来，重了业务流程上的梳理、解耦，在很大程度上也依赖于系统的易用性。如果说一个好用的系统是没有注重用户体验的结果，那么只能说这是一个巧合。
当然，后台产品对于UI的的要求，确实没有前台产品那么强，但是用户体验并不仅仅指的是视觉体验，视觉体验也不能全权代表用户体验。所以，如果说由于后台产品对于UI要求的让步，而让大家觉得后台产品是不注重用户体验的，那么我觉得这真的是冤枉了后台产品经理。
顺便举一个我在做客服系统时的一个小例子，而且是一个关于UI的例子。大家都知道在这个看脸的时代，又碰上我的用户群里有是一群妹子居多的客服童鞋，所以为了让她们对客服系统产生好感，我做了一件什么事呢？就是给系统换皮肤，我们第一期的皮肤主题就是小黄人，妹子们可以在系统的好多地方看到萌萌的小黄人，这其实对系统来说是件非常简单的事，开发量也很小，但是带来了一个什么效果呢，我们的NPS直线上升！让产品变得有趣，打破用户对产品的预期，往往会有意想不到的好效果。
3、后台不需要挖掘用户需求？
很多不了解后台产品的人精彩会问，你们做后台的，是不是不需要挖掘用户需求啊，业务方告诉你们做什么就做什么，这样就可以了？
我只能说，有这样的后台产品经理，但这样的后台产品经理，绝对称不上是一个好的后台产品经理。因为一个好的后台产品经理绝对不应该允许自己沦为一个业务与技术之间的传话筒。当你变成了一个传话筒，那你可能需要反思一下自己的定位和工作了，因为我们说一个好的后台产品经理，应该能够推动并引领业务更快速的发展。
4、后台用户量太小，没成就感
这也是一个常见为的问题，确切的说，这不能算是一个误区。但是今天，我想让大家换一个角度去看待这个问题。
对于C端产品来说，用户量是他们的一个很重要的衡量指标。但是对于后台产品来说，用户量重要吗？其实并不重要。就拿财务结算系统来说，可能这个系统只有2、3个人在用，但是却支撑了公司每月几百亿的流水，你说这个系统没有价值吗？如果你是这个财务系统的产品经理，你会觉得没有成就感吗？其实这个流水，就相当于前台的用户量，如果这样一比，你还会觉得这是个问题吗？
适当的换位，把不同的业务形态抽象出来作类比，这才是更可取的方法，而不是绝对的比相同的东西。
5、后台产品不受公司重视，受夹板气
这其实是公司，或者说是老板对后台产品的一个误区，不理解。如果你碰到这样的老板，请把我今天分享的内容转述给他，看看他会不会改观，或者直接让我跟他聊聊也行。
扯远了，其实客观的将，后台产品的重要性也要依据公司不同的业务形态而议。我相信，至少在O2O或者是电商类的公司，后台产品还是会很受重视的，通常来讲，企业规模越大，后台产品的价值发挥就越大，这点我后面也会展开来讲。
6.、后台产品逻辑复杂，没有竞品参考，比较难做
好了，明眼人都能看出来，这其实是一个褒奖。作为一名后台产品经理，我就愉快的承认了，哈哈。
“偏见”的来源——价值
OK，现在我们来回顾一下这些问题。这些“偏见”的来源都是什么？大家其实都在讲一个什么问题？我大概总结了一下，两个字：价值。也就是说，很多人觉得做后台产品没有价值，可是我们到底有没有价值呢？有多大价值呢？这些价值又该如何衡量呢？
接下来，我将会从以下两个不同的角度，来简单的回答一下这些问题。
1、从【感性】的角度讨论后台产品的重要性
从感性的角度看，后台产品就是我们整个生态的基础，就像大树的根，或是这个高楼大厦的地基。没有这些基础的东西，上面的枝繁叶茂、耸天入云，都是不可能存在的。
我们的后台产品就是整个公司业务的支撑，很多公司的重大战略，都是通过后台产品倒推到前台的。
最后还有一个点，是我们最常提到，却又常常忽略的，就是效率问题。后台产品其实是整个公司运营效率的引擎。前面我们也提到了，后台产品一个很重要的意义就在于提升公司的运营效率，让公司内的每一个业务人员，都能高效顺畅的完成工作。这真的是一个看不见的竞争壁垒。我们看到一些相同类型的公司，有自己完整的供应链的，A和B两个公司做到了同样的低价，结果B公司无声无息的就死掉了，为什么？因为B公司，虽然做到了低价，但却是亏损状态，而A公司做到了同样的价格，却是盈亏平衡甚至微盈的状态，如果打持久战的话，哪家公司会更持久，显而易见。A公司为什么能做到盈亏平衡甚至微盈的状态呢？这就是运营效率的差距。
2、从【理性】的角度讨论后台产品的重要性
从感性的角度，其实还是比较好理解的，所以我也就不多说了。下面来谈谈，从理性的角度，怎么看待这个问题。说到理性这两个字，很容易联想到数字，基本上，能用数字衡量的，我们都认为是相对理性的。那我们就看看后台产品如何来用数字量化结果。其实每一种业务形态，它的后台衡量指标以及数字模型肯定都是不一样的，比如团购的BPM系统，可能就是人均上单量，客服系统可能就是接线量，这个肯定是根据具体的业务形态具体分析的。
不过在这里的，想跟大家分享一个通用的标准，或者说是模型吧。这个模型是什么呢？我相信绝大部分的互联网创业公司，最后都还是奔着上市去的，但现在呢，整个中概股在美国的处境都不太理想，老美对我们比较失望，比较不放心，我们呢，也总觉得老美不懂中国市场，低估了自己公司的市值。所以大家纷纷回国投身主板、创业板（原先还有个不要求利润的战兴版可以期待，但是前段时间也给取消掉了），但这两个板都个什么共同点？利润，利润要求。什么是利润？简单的讲，利润就是收入和成本的差额。那么，想要在收入一定的情况下，提高利润，让我们的财务报表好看，该怎么做？无非就是压缩成本。而我们看到，成本的大头都有什么，营销成本和人员成本。
1、如果我们缩减营销成本？
我们这里指的营销成本，指的是有效的营销费用支出。什么意思呢？就是我花出去了这笔钱，是一定能够带来预期效果的。那种花出去了，就跟打水漂一样，只能引起波澜，但却无法带来任何收益的情况，不在我们今天的讨论范围之内。那么我们可以想象，如果我们压缩了有效的营销费用，会带来什么情况？我们的收入也会随之降低，看起来，这笔个买卖并不是那么划算。那我们就再看看另外一种情况。
2、如果我们压缩人员成本？
让我们想象一下，如果我们压缩的人员成本，会是一番什么样的景象？我们离职不补，不会让我们的业务停滞吗？我们部门整合，会让我们业绩下滑吗？回想一下我们的职业经历，好像往往当我们碰到这些情况时，公司的业务好像也都稳步发展，并没有收到什么影响。
所以说想要把利润做的漂亮，一定是在人员成本上做到了最优解。那么，想要压缩人员成本，必然是要提升单个员工的工作效率，扩大产能，这就要仰赖我们的后台产品了。这个时候，你还会说，我们的后台产品不重要，后台产品经理没价值吗？
顺带举2个例子，说说我们是怎么提升运营效率的
1、CRM系统
做后台的产品经理应该都知道，CRM是客户关系管理系统，销售会在CRM中完成客户分配、拜访计划制定、签约管理以及结算等一系列的操作。以团购业务为例，当一个销售和他的商户达成了合作意向，并完成签约，那么销售后续就需要在CRM系统中录入合同及相关物料（团购套餐介绍、图片等信息）。原先呢，销售们只能通过PC完成这些繁杂的录入，可销售平时是什么样的工作状态呢？早上晨会及拜访演练，结束后执行拜访计划，几乎白天的时间都在外面跑，所以要想录入这些资料，只能等到晚上进行，录入的时间和数量都非常的有限。
后来我们做了一件什么事情呢？就是把销售的办公移动化。为什么做这件事呢？前面我们也提到，销售大部分的白天时间都在跑客户，但是跑客户的过程中也有大量的时间浪费在了交通上，移动化的意图就是把这段交通工具上的时间有效的利用起来，让销售在移动端办公，既解放了销售们的工作时间，有提升他们的办公体验，何乐而不为呢？
2、BPM系统
BPM系统是我们的团购制作平台，也就是说我们在前台看到的所有团购页，都是业务运营团队通过这个平台制作出来的。原先一个业务运营同学每天只能做4单团购，这个效率听起来怎么样？是不是很低？后来我们观察他们的制作流程，发现他们在制作一单团购的时候，需要横跨至少三个页面（物料信息页、制作页、预览页）才能完成最终的制作，而且这三个页面在制作过程当中还要不停的比对，相当的麻烦和低效。
后来我们就立了一个叫做“三单合一”的项目，希望解决这个问题，其实现在回想这个项目还是比较简单，无非就是把物料页的信息结构化，然后自动填入到制作页，这样业务运营同学就省去了大量的copy-paste的工作，同时我们又将制作页做了“可视化”调整，让制作页和预览页长成一样，这样就省去了运营同学反复比对成形效果的过程。别看原理简单，但是却起到了大作用，项目结束后，运营同学的焦虑几十倍的提升。这是什么概念？就是说在人力相同的情况下，我们能支撑业务几十倍的增长，而无需增加人力成本。
一个后台产品经理的自我修养
经过刚才的讨论，我相信大家或多或少对后台产品有了更为深入的了解，和价值的认可。那么，问题来了，怎样才能成为一名合格的后台产品经理呢？结合我自己的经验，我总结了如下两个维度：
1、务虚：智商&情商
2、务实：业务理解&项目管理
其实这两个维度在一定程度上是交叉的，不过这并不妨碍，他们和谐的共存在一个二维平面上。这些slide还是比较直观的，我觉得，对于后台产品经理来说，他的情商决定了他在产品中能够生长到的长度，而智商却是决定其高度的重要因素。而当我们具备了“务虚”的能力后，回归到“务实”的层面，则需要业务理解和项目管理这两项能力来充实。
1、智商
其实我觉得现在的产品经理，能入了门了，就说明咱不笨，至少都是在平均线以上的，所以呢，这里我要将的智商，并不是聪不聪明的问题，而是一个人的思维方式和抽象能力，甚至是你看起来聪明不聪明的问题。
首先我们来说说思维方式的问题，这点是产品经理的一个重要技能，不管是前台产品经理也好，还是我们今天讨论的后台产品经理，当我们遇到一个问题的时候，是不是能够透过现象看本质，直击问题的核心，把握住价值点是非常重要的事情。不过关于思维方式的问题，有段时间炒的特别热，什么“互联网思维”啊、“产品经理思维”啊，类似的概念层出不穷，估计大家之前都主动或被动的接收过很多信息了，这里我就不赘述了。
我们着重来说说“业务抽象能力”。什么是“业务抽象能力”，之前在知乎上看到某大牛（就是说“不会就不会，怎么还说成不愿意了呢”的那位）举了一个例子，我印象很深刻。蝴蝶，蜘蛛，蜈蚣，蜻蜓，蟋蟀，知了。现在让你分类，你会怎么分？有人说，蝴蝶、蜻蜓、知了是一组，蜘蛛、蜈蚣、蟋蟀是一组，它们之间的区别是会不会飞；也有人会说，蟋蟀和知了是一组，蝴蝶，蜘蛛，蜈蚣，蜻蜓是一组，它们之间的区别是会不会叫。这其实就是一种“业务”抽象能力。这个能力对于后台产品经理来说尤为重要，后台产品经理特别需要在众多的业务旁支中梳理出一个主干，合并同类项这种事儿是在所难免的。别看让你为昆虫分个类挺简单，但要真到实际业务上，可就没有这么容易了。
最后在提一点更“务虚”的，就是我觉得让别人看起来你很聪明也很重要，甚至往往比我们想象中更重要。这是一种潜在的影响力，如果你跟别人沟通的时候，别人对你的预判是，你这个人很聪明，那么可能在后续的沟通中，你推进的就会比较顺利。反之则不然。那么如何让别人觉得你聪明呢，一方面自己需要修炼内容，一方面也要掌握一点点小技巧，比如适当的引入一些专业的概念，或先进的理念等等。
2、情商
我们简单的聊了一下关于“智商”的问题，接下来我们聊聊情商。首先表达一个观点，很多人觉得自己智商可能不够，那就拿情商来凑，这样就万事大吉了。实际上，确实不然。的确，好的情商是会让自己更加游刃有余，但是别忘了，智商决定高度，而情商只是在这个高度上，让自己更加从容，大家可以自己体会一下。
其实说到情商呢，主要就是沟通的部分。沟通这件事对于后台产品经理来讲，其在工作中占的比重要远远大于前台产品经理。除了常规的技术团队外，一般后台的产品经理还要跟大量的兄弟团队和业务团队沟通，如何与这些团队打好配合，让大家多赢，也是一门很深的学问。后面，我们在项目管理的内容上会做更详细的阐述。
最后需要提醒大家的一点是，沟通其实是一个很广义的词，它不仅仅指的是我们和人面对面的沟通，也包含了邮件、QQ、微信等书面沟通，甚至还包含了肢体、表情等一些“隐形”的沟通。这些沟通方式都是需要大家注意的。另外，沟通也是一个信息双向传递的过程，你发了一封邮件，别人没回你，那顶多叫通知，不是沟通，至少不是有效沟通，这点也是大家值得注意的。
3、业务理解
接下来我们切换到另外一个维度，说说“务实”的东西。先说对业务的理解。这块我觉得可以直接点说，如果你对业务不了解，你不知道你的用户每天用你的产品是用来解决什么问题的，用何种方式来解决问题的，那么你一定不是一个合格的后台产品经理。换句话说，如果你自己对业务不熟悉的话，也很难体现你的专业，更别提挖掘用户需求，引领和推动业务发展了。所以为什么很多后台产品经理沦为了业务和技术的传话筒了呢？我猜大抵就是这个原因。永远要比你的用户更了解他们的业务。
那么如何才能了解业务呢？聊呗，看呗，学呗。自己去和一线的业务人员去聊，然后在一旁观察他们的实操情况，如果有可能的话，自己上阵真刀真枪的试一把，一下就能明白很多，跟一线的业务人员泡在一起，接接地气，对后台产品经理来说没什么坏处。一方面，你会更加收获一种叫做“同理心”的东西，另外一方面，也能让你的用户看到，你不是飘在空中，而是真正的和他们并肩在一起。
但仅仅是了解业务就够了吗？当然不是！还要理解业务，看清你业务的本质。举个例子好了，我之前在大众点评做大客服平台，很多人觉得，客服嘛，就是接电话解答用户咨询或者解决用户投诉的，那作为一名客服的产品经理，我好像只需要搭一个工单&业务处理系统就好了。可是客服业务的本质真的是这样吗？客服，作为一群离用户最近的人，难道只是解决用户当下的一个疑问或者一个投诉吗？我的理解是不是的。我认为客服业务的本质是产品优化，就是说，客服第一时间接收到的用户反馈，不仅仅是当下被解决，还应形成机制，被彻底的解决，这样才能让产品体验不断的提升，越来越好。
4、项目管理
最后我们说说项目管理，项目管理这件事呢，说难不难，说简单也确实不简单。难就难在呢，它需要项目负责人很强大的驱动力和影响力，而不能依靠行政权力去约束团队。可简单却也简单在，它其实并不是毫无章法可言，只要切中了几个关键点，就能达到事半功倍的效果。
比如，在团队内部做好目标管理。这点是最基础，但也是最容易被忽略的一个方法。我们常常知道自己要干什么，却忘了问，我们为什么要干这件事。我们也常常单纯的告诉别人我们要做这件事，却对为什么这么做只字不提。当我们对目标不清晰的时候，其实很多问题就会随之而来，比如当你手头的事情不止一件的时候，你会不知道该如何合理的排布优先级，比如当你做完一件事的时候，你会不知道如何衡量自己做的好不好。所以，一定要做好目标设定，也一定要跟团队同步你设定好的目标，哦对了，这个目标最好是可量化的，这样会让团队目标感更强。
再比如，在跨团队协作的时候，做好预期管理。很多后台产品经理大概都会遇到这样一种情况，就是你的业务方追着你问需求排期情况。如果你经常面临这个问题，那你或许该好好反思一下自己的预期管理是否做好了。所谓的预期管理，再通俗一点说就是让你的合作伙伴参与进来。在需求排期的时候，就让他们知道你的需求池里还有那么多那么多的需求在等待，在开发过程中，让他们知道此刻的进度如何，是会如期发布，还是面临延期的风险。让他们参与进来，给他们安全感，这样你们之间的协作就会顺畅许多。
回顾
OK，最后就让我们猝不及防的结束今天的分享吧，再回忆一下我们今天讲了什么内容？我们首先界定了TO B与后台产品的定义与关系，然后我们直面了几个常见的“偏见”，紧接着我们通过感性和理性两个角度探讨了后台产品的重要性，最后我们通过智商、情商、业务理解和项目管理，两个维度四个角度来提炼了一个后台产品经理的自我修养。希望今天的分享，能对大家有用，谢谢！
Q&A：
Q：在后台产品迭代的过程中，如何平衡产品需求的“前瞻性”和“确定性”。保证既能找到业务方的核心本质需求，又能预计到相关功能改动后，会带来的影响，并做出预案。
A：我觉得是这样，还是我之前提到的，首先你要对自己的业务非常熟悉，知道你业务的本质什么，未来是什么走向。当你明确这些问题的时候，你的“前瞻性”和“确定性”就会靠谱很多。多说一点，一般的业务人员其实很难描绘出真正的需求，大都是给了你一个，他认为最优的解决方案。这时候，你就需要发挥出你产品经理的本领，通过你对业务的理解和判断，推敲他真正的需求是什么，找、抓到了真正需求，这样你的“确定性”就能得到很大的保障，另外在你设计这个需求的解决方案时，再结合你对产品未来的规划，这样“前瞻性”也能在一定程度上有所保障。
作者：李明泽『喜马拉雅FM』产品总监
编辑：SmallTalk_小太阳、SmallTalk_人人
校对：SmallTalk_Areslay