做内部产品，我踩过的这4个坑

内部产品，顾名思义就是提供给内部员工使用的产品。之前我在网易实习做支付，关注的都是to C的东西，页面呈现效果，表单设计，用户行为路径，用户反馈，活跃数据。从来没有接触过这类内部产品，什么CMS、CRM、ERP，当时就像发现了新大陆一样的兴奋，想着又有新技能要解锁了。后来才知道，这内部产品，并不好做。

1.沦为需求传达器（只勤奋不思考）

据我不客观的猜测，刚入行的产品新人，绝大部分都会踩到埋头执行不思考这个坑。我也一样。

而且当时我自认为做的很认真了，每天跟业务方反复沟通，跑到他们位置上把一个一个问题复现，整理好按优先级排序，写文档画交互，重要的提给开发，预发环境里我自己测试一遍，确定没问题了再反馈给业务方。

业务方说这里要加个筛选按钮，我说“好”。业务方说想一键分享到微信，我说“行”。业务方说前台页面展示信息混乱，我说“OK，我去画原型。”

工作中最可怕的状态莫过于此，你每天努力勤奋，充满动力。走过一阵路后，回头一望，发现做了好多无用功，好多事的解决方案不够优雅，甚至一些改动为将来埋下了祸患。

保持这个工作状态一阵子后，我的leader找到了我。她当时很生气，狠狠地批评了我：“如果你的做法只是把业务方的解决方案转交给了开发，只起到传达而没从全局思考的话，公司为什么还要养着我们？！”她的话很重，当时的我很委屈，明明业务方很认可我的工作成果，为什么到领导这就变成有问题了？

后来，随着我自己在产品路上的经验有所增长，开始教导别人。再来细品，越想越觉得当时leader批评的对。

闷头执行就容易这样，用户要一匹跑的更快的马，我就花尽心思地找马。而忘记了“马”只是用户提出的解决方案，他的需求是更快的速度。了解了背后的需求，你就能尽情发挥，不管是汽车、火车还是飞机都能满足用户的真实需求。

前两天看到一则需求的小故事，也是这个意思：

顾客向服务员要一杯水，服务员端了一杯热水过来，顾客一摸，“太烫了！”，服务员听罢，转而端了一杯冰水，顾客一摸，“太冰了！”。服务员换了一杯温水，顾客拿着很开心地，用了这杯温水洗了手……

怎么避免呢？

leader后来教我一个方法：连问五个Why！(你为什么需要XXX？)

连问五个Why，你基本就把用户最真实的需求挖掘出来了（虽然在最开始的时候会显得你很傻逼）。用户要一杯水，如果是渴了，他需要的是一杯温水。如果是擦干净手，他需要的是一张湿巾。如果是为了兑酒，可能雪碧和红牛更配噢！

不要简单听信业务方提出的解决方案，要回到他的用户场景和业务目标，去挖掘他真实的需求是什么，再给出合理的解决方案。因为内部产品的用户比你懂业务，但不如你懂产品，他提出的解决方案常常是局部和片面的，这时就需要你能站在产品的更高角度，优雅地解决问题。

2.没有深钻业务

如果你是旅行App的产品经理，你得去了解旅行行业的需求和痛点。如果你是短视频App的产品经理，你得去研究短视频的功能和需求。这是毋庸置疑的。

但如果你是个HR系统、CRM、CMS的产品经理呢？你该做什么？守住产品的一亩三分田就可以了么？

不，你要成为一个业务专家和系统专家。你得懂业务，一个完整的招聘流程是怎样的？怎么组织销售，激励销售，寻找机会？怎么提高编辑的效率？这些问题你都得清楚，成为一个业务专家，和业务方站在一起。

同时你不能仅陷在业务里，得跳脱出来成为系统里的专家。画各种系统组织架构图，抽象出各种概念。对系统的发展有自己的规划和预期，按自己的节奏去迭代升级系统以满足业务的拓展需求。这些系统的理论知识，经过这么多年的发展演变，已然长成了大家伙，里面的门门道道可多，够我们钻研很久。

一位产品前辈曾说过：做产品要把70%的精力花在业务上，这才是安身立命之本；而剩下的30%是产品通用技能，算不上什么核心竞争力。回想当时的我，一个劲地只顾做需求，改Bug，醉心于产品细节。没有相应的高度，钻到角落里而不自知，也算是当时经验尚浅的表现吧。

3.不了解开发成本（不懂技术）

关于产品经理要不要学技术，业界争论了很久，大部分人得出的结论是：产品可以不学技术，但是得懂。

懂什么呢？至少得清楚原理和具体的实现成本，才便于平衡多方利益，做出恰当的决策。就好像给你一千块预算办活动，你可以组织的风风火火的，在预算内把事情做漂亮。但如果光让你做活动，不知道最后能报下来多少钱，那你一定会畏手畏脚的，很受限制。

不懂技术，就像给了你一个“黑箱”，里面不知道是黑猫还是白猫（三个梗好像串了）。必定影响你决策的能力。我当时就是这样，闹的第一个笑话，就是出了Bug不知道找前端还是后端。东问问西问问不得要领。

第二点是无法评估一个需求背后的代价，从而影响优先级的排定。因为做的是内部产品，最重要的事是提升效率。我入职第一天拿到一张列着一百多个需求的表，一半以上是Bug……排期的时候，第一个需求开发说要两天，我说“好”。第二个需求开发说要三天，我说“哦”。这样一周的时间就排满了，其它活得下周再排。留下原本排了十个P0优先级需求准备大干一场的我在会议室黯然神伤，于是接下来几周在排期和接需求的时候，我心中都没有底气，担心笑话+1。

第三点，做业务系统的产品经理，需要有更坚实的基本功，出色的抽象和建模能力，要懂概念模型，画各种图。而我当时几乎是第一次接触这些概念，每天九、十点下班回家抱着UML的专业书籍啃，很是痛苦。

4.要做正确的事（不只有用户体验）

小时候，我幼稚地认为世界上只有两个国家：中国和外国。长大后，我们仍免不了犯这类低级错误。把一类事物抽象为一个整体。比如，把业务部门抽象为一个利益共同体，把一个公司的不同部门当做一个利益共同体。但从微观看不是的，可能内容编辑人员和内容组负责人的利益并不一致，甚至是相悖的。

业务组成员都是和我们朝夕相处的人，相隔不过几个工位。这时我们很难从用户的情感中跳出来，我们习惯性地把提高他们的操作便捷度当做最高优先级的需求，仿佛这是一款to C的产品。当他们利益受损，向你抱怨的时候，你更倾向于解决他们的问题。

举个例子，当时我们在开发内容审核流程的时候，对流程进行了重新梳理，增加了多个审核状态，完善了操作规范，并要求三审必须由领导审核，大大拉长了审核流程。对于内容编辑人员，原本五分钟能做完的事，现在要用十分钟才能完成，而且操作更加繁琐。这是件对公司利好，对编辑利空的事情。编辑们对此积极性不高，不愿配合。我也松松垮垮能拖就拖，仿佛这个功能一上线，就和编辑们做不了朋友了。从某种程度来讲，这是对公司不负责的表现。

常有人抱怨，这类to B产品操作繁复，用户体验奇差。但我们做内部产品的不得不承认，在开发资源非常有限的后台，用户体验只是一堆重要问题的其中之一。像系统稳定、流程合理、信息安全、定制功能这些都很重要。一味地强调用户体验，照顾眼前看得见的操作者，忘记了背后看不见的公司，重视部分而忽略了整体，同样是值得引起注意的进阶问题。