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

作者:潘潘,公众号:Hey潘潘

关键字:产品经理, 业务

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部