知乎高赞:作为产能忽视哪些实际上很重要的细

2019-11-11 18:26 来源:未知

  从业时间相同,优秀的产品经理总是能比别人注意到更多的小细节,换句话说,以下一些点是产品经理或者产品负责人会经常忽略的。

  对产品经理来说,想出牛逼的点子只是副业,怎么把产品流程的设计顺利圆满没有遗漏地完成才是天职。

  比如,作为电商产品经理,除了正常购买流程,每个环节的错误页面有补全吗?每种问题的处理情况想到了吗?遇到网络信号不好时界面会是如何的?用户没登录、没绑定支付、没支付成功的时候交互如何?用户登录失败、绑定失败、支付失败的交互又是如何?

  产品经理很多时候是需求承接方,有时需求来自老板,有时需求来自同事,有时需求来自用户。这时候,一定要分清一件事情,这件事情是非常非常容易被搞混的,就是:他们给你的是明确无误的需求还是只有实际的方案!

  比如,老板的需求可能是这样的:给我做个客户端实时记录美甲师 GPS 的功能来。

  作为忠贞不二的员工你可能就落实去了。但实际上,你需要搞明白老板为什么这么做。在再三的追问下,老板可能就告诉你他的原因是:因为美甲师经常会为了奖励刷单,也就是不出门让朋友来下单。GPS 用来帮助判断这个。

  所以你理解了老板的需求,那么下一步做的时候就清楚了:要查美甲师是不是刷单,没有必要实时做记录,这样增加美甲师端的流量消耗,也增加了服务器的负担。

  正常的接单时间都会大于半小时,因此完全可以将功能改成:每半小时记录一次美甲师的 GPS。

  任何人(包括用户,严格说尤其是用户)给你提需求时,有时候只是根据自己的需求拍脑袋想了一个方案建议你做,但作为产品经理,要做的是理解其背后真正的原因或者原理,转化为更合适的产品方案。

  @张博远:产品经理的工作有很多:求开发,撕运营,挑UI,瞻领导,看竞品,问用户,回邮件,写PPT,如果这些事情占据了你全部的时间,你可能会忽视两个非常重要的问题:开发前的「效度预估」和上线后的「效果复盘」。

  效度(Validity)即有效性,它是指测量工具或手段能够准确测出所需测量的事物的程度。

  用在产品经理工作中,一个新功能、一次版本优化的效度是指本次开发的东西多大程度上指向了需求、完成了目标。在具体的工作中,又可以细分成以下几个问题:

  2、对方给到的是需求还是方案?如果是方案,这个方案背后的需求和目的是什么?针对这个需求/目的,这个方案是最有效的吗?

  3、这项新功能,与现有产品形态的关系是什么?可能会对现在产品产生什么负面影响?

  4、这项新功能解决什么具体问题,为哪些用户解决问题?会不会影响到其他用户的体验?

  如果没有充分考虑以上的问题,可能的后果是:PM做无用功,RD浪费时间,产品在兜圈子。举一个负面的案例:

  有段时间大量用户反馈说评论区的质量下降了,于是小组讨论出了一个方案:给每一位用户一项能力,发现 “垃圾评论” 时把评论者指认出来,被指认次数达到一定量级时会被禁止评论。这个方案两个月后上线了。但效果很差,甚至帮了倒忙,其中一个原因是:

  指认“垃圾评论” 时用的标签太好看了,有人被禁言时,头像旁边多出来的东西就跟徽章似的,大家开始羡慕他,争着抢着也要“徽章” ,这就像在上世纪的中国,犯了投机倒把罪的罪犯游街示众时头上戴的不是高帽而是红花,那岂不是大家争当罪犯了?

  这表面上是UI设计的问题,UI设计有一项原则,即形式追随功能。更确切地说是:形式追随功能背后的目的和意义,当产品经理没有把这项方案背后的意义和目的十分明确的提出来时,当这项功能的目的和意义没有有效传达给UI设计师时,UI的问题也有产品经理的责任。

  第一、明确本次迭代/优化/新功能的目的、意义,越明确越好。第二、每向前推进一步,都要用目的和意义来审视一下,如有必要及时调整。

  如果不做效度预估,就像如下左图,目标模糊笼统,向前推进时方向跑偏也不知道。

  产品经理在做进度规划的时候,很少把「效果复盘」算进去,再加上上线时间往往延迟,一个功能上线后恨不得马上推进第二个,有时候我会跟同事讨论说:

  既然咱们公司不是为了赚短线的钱,如果一个功能模块上线天之后,没有一个人用,那这个功能模块有必要做吗?

  其实有时候产品经理很无奈,因为他的leader甚至整个工作氛围都是这样,就算有心,也只能挤时间做复盘。

  某次工作中,商务提出一个需求,在客户端里加入一个H5页面来宣传某客户的新产品,由于是销售谈下来的付费客户,优先级比较高,因此我积极响应,迅速协调相应的交互、UI、开发按要求上线了。期间前端开发颇有微词,我除了好言相劝无我他法,他手头的活儿实在太多,但这个事情必须有人来做。

  过了一段时间,那位商务同学又来提需求了,我随口问了她一句:上次那个H5页面客户那边的钱到账了吗?她说不知道。“能帮我问一下当时负责的销售吗?” ,“行吧,我一会儿去问问,咱们先来谈谈新需求吧”。

  到了第三天,我见她没有任何反馈,又去问她,我才知道:客户没给钱!客户没给钱!客户没给钱!

  几翻讨论之后,我们达成一个协议:对于销售提过来的类似需求,需要同时提供客户的首付款凭证。会后我又想到了几点:

  为了应对销售需求的而开发的页面和功能,因为其目的是卖钱,所以复盘效果的方式很直接,就是看结款情况。但是在我负责那条产品线之前的三年里,一直没人考虑过这个问题,大家一直奉行着销售需求优先排期的原则,还有许多其他产品线也同样如此。

  还有,对于运营提过来的需求,我也时常会拒掉,理由很简单,一项活动最理想的效果,无论对于品牌的提升,还是对于用户量的提升,还是对于日活的提升,全都加起来还不够两个RD一周的工资钱(p.s.如何换算是另一个话题),而这项需求仅仅开发就至少两周时间,有时候运营气急了就骂我是神经病。

  也不怪运营同学,有时候部门根据需求设立了一个岗位,根据岗位招了一名员工,但是三个月后,当初的需求变小了,进而这名员工的工作量减小了,他甚至他的leader就会觉得不要让其他人觉得闲的慌,就得找活干,就得提方案,提需求,sigh~

  「效度预估」和「效果复盘」这两项工作很重要,但是受到的重视程度远远不够,有时候我会想两个问题:

  「效度预估」和「效果复盘」都属于重要性高但紧急性低的事情,这样的事情很容易在忙的时候被忽略掉,万一再碰上有员工离职,这时候可能需要一个人干两个人的活,稍有一点空隙时间了,也只是静坐在那里,发呆放空休息一下,久而久之,没有人觉得需要预估,需要复盘。事实上,这件事情是需要产品负责人写到工作原则中去的。

  总之,对于以广告为赢利模式的C端产品,当用户达到一定量级之后,很多数据的变化和波动是综合因素导致的,很难说数据上升或下降是由某个特定的新功能的导致的。而且很多功能上线后,往往有非预期后果,非预期是指不知道什么时候产生。

  后果可能是正外部效应,也可能是负外部效应,但正因为此,才更需要产品经理们刻意练习「效度预估」和「效果复盘」的能力,从错综复杂的表象背后深挖出真正的逻辑关系,才能逐步把产品量级提到新的高度。

  相反,如果始终不留出时间做「效度预估」和「效果复盘」,你可能最终于成为一名浑浑噩噩的产品经理。

TAG标签:
版权声明:转载须经版权人书面授权并注明来源