独立负责项目两年,我的产品原则及方法论_职位
2020-01-01 11:40:44 作者:佚名
原标题:独立负责项目两年,我的产品原则及方法论
作为一名入行有四年,产品经验只有两年的人来说,写下本篇文字,内心未免是惴惴不安的。一方面是经验尚浅,还达不到可以立说著述的程度。另一方面,则是产品未能取得数据上的很大辉煌,不足以令人信服。然而,即使是一名拙劣的厨子,在长期的烹饪过程中,也可能总结出一些有价值的招数。我从去年4月份开始负责同城招聘的项目,到今天为止,已经主导了3个大版本、14个小版本的迭代,实现了162万注册用户、116万简历和15万企业的积累。经历的版本多,碰到的问题多,我想,劣庖厨也许会有一些好的方法。 下面8条方法论,是我过去两年多产品经验的总结。2019年即将结束,能以这种形式跨年,我很开心。 1. 基于现状做设计 12月份的时候,我们新版本上线了聊天功能,可实现求职者与企业的沟通。在梳理需求时,有一个小的功能点让我陷入了长考:要不要有已读、未读的状态通知呢? 熟悉互联网史的朋友肯定了解,微信当年也有这种困惑,最终,坚持让用户有撒谎自由的作法,使得微信一直没有已读状态的提示。 我们同样面临这个问题,作为用户,我当然是非常想要这个功能的。然而,作为一位产品经理,当我站在全盘考虑这个问题时,已读的状态提示似乎并不适合。 原因很简单,当前现状无法支持这一方案。我们平台的历史包袱较重,很多岗位是旧职位。为了扩充平台的职位库,我们和友商进行合作,数据打通,获得了大量的新鲜职位。友商们的企业,是不需要登录APP的。已读、未读功能的上线,基于逻辑推测,很多消息必然得不到及时反馈,反而会暴露企业不活跃的事实,造成用户质疑的加深。 因此,已读、未读功能上线貌似能够更好地满足用户需求,且符合Dieter Rams设计十戒关于“好的产品要诚实”的声张,但是对于整体业务而言,却是一场灾难。 同样的思考方式,另一例事情上也有所提现。我在接手项目时,公司已经有一款老产品在运行了。当时的注册/登录方案,跟行业老大51job的类似,开放所有的职位给到求职者,用户只在投递或者完善简历环节,才需要注册或登录账户。从体验上来说,对于求职者无疑是很有帮助的。 但是这一设计必须基于两个前提条件:
- 平台拥有足够丰富的职位以充分覆盖用户的求职需求,否则匆匆浏览,不会留下任何东西。
- 平台品牌较为知名,有足够的自信在求职者短暂离开后又能回到平台。以上两点,我们都不具备,这也造成老产品的尴尬现状:用户量低、留不住人。
- 求职者务必要留下一份简历;
- 企业务必要留下一条职位。
- 我们面向的是蓝领求职者,他们对岗位竞争不太敏感,而更关注工作好不好。相反,对于蓝领人群来说,围观的人数越多,越能说明职位可靠,大家在人才市场上蹲一下午就知道了。
- 我们的品牌知名度不高(2年花了不到5万块用作推广),用户并不太信任平台上的岗位。
短信模板:您好,我刚刚在 同城招聘 上投递了贵司的岗位,期待与您进一步沟通。在考虑这个功能,有个问题让我陷入了纠结:短信抬头的签名部分,能否使用我们APP的名字? 从数据效果来说,直接使用作为抬头肯定是更好的方案,毕竟HR阅读短信的自然顺序是由前到后。 但是我们能否这么做呢?我的选择是不能,理由很简单,这是求职者的私人短信,发送行为是发生在求职者与企业之间,而不是平台与企业之间。我们可以在模板中提到APP名字,以推动两者交流(否则求职者说在××上投递了岗位,企业还是一脸懵逼),但是作为抬头强行塞给用户却不行。这本身就构成了一种侵犯,对私人空间的侵犯。因此,最终我还是放弃了一种可能数据表现上更好的方案。 我认为产品经理在很多时候总会陷入犹豫不决的情况,这时候,可以不用从外面寻找答案。问问自己的内心,也许思路就清楚了。 4. 好的产品软、硬价值兼具 硬价值和软价值是我杜撰的一种非严谨定义的概念,主要目的是描述一件事情。职位量、简历量、简历完善率、企业日活等等,这种可供量化的指标,可以看作一种硬价值。与之相反的,情绪、感受、调性等非理性部分,可以看做软价值。硬价值是骨骼,软价值是血肉。硬价值解决需求,软价值构建体验。 我认为好的产品不应该是冷冰冰的,应该是有温度的,比如我们的日签功能。 为什么要做这个功能呢? 观察数据发现,我注意到每天有很多用户会签到。在之前的设计中,签到结束后,就是一句简单的toast提示:签到成功,获得100金币。这是很轻量的一种反馈,很普通,也很没意思。所以我决定让签到变得有价值一点,并不是单纯获得金币的价值,而是这个行为会让用户有所期待。所以我精选了励志类、求职技巧及安全类、趣味段子等,作为日签卡片的轻内容。 为什么要选择这几类呢? 一方面求职是人生的一个小节点,即使是以高频换工作著称的蓝领求职者,一年2-3次的跳槽频率,在其一年中,这也是几个特殊的时间段,不是吗?或期待、或惆怅、或迷茫。在这个时间段中,如果一句话可以让用户获得片刻的信心或者愉悦,激励一下其士气,我觉得价值本身就很大了。 我一直告诉开发同学,求职者来到我们平台,在找工作过程中,看到日签上的内容,就像中场休息,虽然我们提供的这类信息,网上都能看到,但那是终场休息,两者性质是不一样的。 至于求职安全类的知识,则是基于现实考虑。很多求职者,尤其是年轻求职者,安全意识不够强,相关的信息甄别能力比较弱。我们之前想的办法是,将求职安全知识普及与用户激励建立强绑定。用户参与平台组织的答题活动,可以获得200金币奖励。答题的内容就包括这类知识。这种活动参与人数不多,并且偏重了,效果并不是很好。因此,干脆化整为零,每天在日签上给用户普及一小条,零敲碎打,让他找工作时起了提防心,这就够了。 类似的思路也反应在我们的一些小细节上,比如一个用户的面试列表为空时,相应的空页面文案是:亲爱的,别急,面包会有的,面试邀请也会有的。同样的,我们的加载动画是一个扑腾着翅膀的小蜜蜂,呆萌可爱,目的是为了降低用户的等待压力。为了这个动画,设计师被我逼得撸了好几套方案。 5. 避免自嗨的设计 我以前犯过不少错误,做了一些自嗨式的设计,导致结果掺不忍睹。比如为了引导求职者主动分享职位,在求职者主动打招呼的职位卡片上,画蛇添足,加上了一个分享职位的引导,期待求职者可以分享职位。 实际上,求职者在与企业沟通时,核心的目的是咨询岗位的具体细节,而不再是对职位心存疑虑需要朋友的介入了。产品希望用户帮忙分享一下职位,扩大岗位及品牌曝光度,但是求职者在此场景下,却并不需要此功能。 除了产品设计上,业务上我们也犯过不少错。1.0版本的时候,我们总监和我商量一种机制,简单描述,就是A邀请B注册我们平台,B的简历被企业下载后,A每次都能获得2块钱。这个机制没有运行下来,原因是多方面的,核心原因还是A的动力严重不足。我们很难教育用户去理解这项机制,更遑论去拉人了。当一项机制缺乏不证自明的理解力,缺乏足够打动用户的动机,而需要文案、弹窗去教育用户时,这项机制本身是有问题的。 我们不能陷入自我动机而不是用户动机去考虑问题,造成片面的自嗨。 6. 砍需求三原则 对于一名天秤座的产品经理,砍需求简直比砍自己还难受。可能很多人不理解,为什么产品经理会觉得砍需求这么痛苦。其实我们换一个角度看,大家就能够共情理解了。 产品是产品经理的孩子,这个说法大家应该都听过。试想一下,有一天你带着自家可爱的小闺女出去玩,路上看到有很多好吃的、好玩的,你能忍住内心腾腾燃烧的父爱,不给孩子买点吃的吗? 所以产品经理在面临砍需求的时候,往往是很痛苦的。痛苦一般要经历两次:一次是需求分析阶段,这一阶段是产品经理自我挥刀的时刻;另一阶段是技术评估阶段,一般在需求评审会议上,一帮坏叔叔们,决定不给孩子买哪些零食,因为他们觉得某些零食很贵,买不起(不好实现)。 作为一位骄傲的产品经理,我宁愿自己动手。在2年的迭代过程中,我慢慢摸索出自己的砍需求三原则,概述如下:
- 偏离目标的需求,不做;
- 只是有点效果的需求,不做;
- 可做可不做的需求,不做。