我是如何完成一年连续2次晋升的 | 360产品经理
光阴荏苒,日月如梭,一元复始,万象更新。我们还未觉察到2018年从指尖悄悄溜走,2019年就已纷至沓来。回顾总结,反思不足。下面我用真实的工作案例,与你探讨产品工作方法和心得,期待对你有所裨益。
我的2018:
这一年的产品工作和成长,我总结起来,有4个key word:Team、Ownership、执行力、产品力。
Team
某个饭局上,我的一位产品朋友告诉我,他跟开发撕逼了,突然觉得好累,争吵的原因是他的产品方案没有得到开发同学的认可。说实话,我挺佩服他,敢跟开发同学叫板。但互联网行业是一个极其讲求团队作战的地方,每个人各有所长、各司其职。
我之所以把Team放在最前面,正是因为如果没有团队,其他一切都是空谈。一个人单枪匹马能做成的事情,非常有限,包括个人的精力是有限的、个人的力量是薄弱的、个人的思维是局限的。合作才能实现和创造更多的价值。融入到团队中,也才能让我们自己学习、成长得更快。
那么产品经理,在一个团队中担任什么样的角色呢?我想:
- 首先,应该是一名服务员,服务好团队的所有人,做别人不愿意做的杂活;
- 其次,是一名掌舵的舵手,把控方向和进度,把项目成员凝聚在一起;
- 同时,还是一名救火队长,出现问题时第一时间解决;
- 最后,是一名专业的背锅侠,遇到锅要当仁不让地背起来,意味着产品经理是最终的负责人。
团队的核心是什么?
我理解,是成员之间默契的配合、是相互包容带来的凝聚力,从而发挥出来的团队爆发力。那产品经理首先要做的,便是与成员“和睦相处”,避免每日菜刀相见。
如何与设计师相处?
首先,要让设计师在设计之前,就十分清楚我们想要什么、我们不想要什么。因此,当面充分沟通讨论是十分必要的。
其次,给设计师足够的个人空间,要避免我们过多的主观意见。虽然产品经理对设计也有自己的想法,但是打心底里,要相信设计师比我们更加专业,而往往设计师也会给我们惊喜。网上有个段子,产品经理在设计师的屏幕上指指点点,设计师默默把菜刀摸了出来。
最后,切忌反复修改需求,尤其是作品完成后,再让设计师大改。
例如,我们在设计信息流不感兴趣功能时,用户点击“不感兴趣”按钮后,会在原位置,重新推荐一篇文章。我们希望通过设计,让用户感知到推荐的过程。我把这个功能的设计初衷,和希望给用户传达的信号,与设计师做了充分的讨论。
最后,设计师制作了一张gif图,一个桃心从空到满的变化过程,旁边配上文字“猜猜你喜欢”,在新推荐的文章展示前,会加载这种gif图,整体的体验非常友好,给了我们很大的惊喜。我录制了一张动态图放在文末,稍后可以看下最终呈现的效果。
如何与开发工程师相处?
第一,亲身教训,不要去随意打扰开发的写码时间。开发一天的黄金写码时间,只有两个小时。有时候,追一个bug会让开发同学抓狂。有一天下午,由于对某个“个性化策略”有疑问,我三番五次地找开发同学讨论,最终导致开发同学禁不住发飙了,因为我不间断地沟通,打乱了他写代码的节奏,导致他难以专心写代码。最后,经过调和,我们约定普通的需求讨论,尽量在上午时间沟通,下午让他专心写代码。
第二,和开发同学的沟通,是一个良性互动的过程。
- 一方面,切莫把开发同学仅仅当成是一个写代码的,他们对产品也有自己的理解,及时让开发同学了解用户的情况、产品的数据等,对他们的开发工作也有裨益。
- 另一方面,我们也要善于倾听开发同学的建议,在某些层面上,开发是最懂产品的人,因为这是他亲手一句代码一句代码垒出来的。最后,仍然是:切忌反复修改需求。
如何与运营同学相处?
运营是与用户走得最近的人,经常与运营沟通,能获得更加全面的用户信息。我们需要做的,是给运营同学足够多的支持,当运营需要帮助时,第一时间协调资源解决。
例如:运营内容的同学,提出“10分钟级内容实时点击数据”的需求,通过线上实时数据,及时更换效果不佳物料。评估下来,这个需求是合理的,并且对收益帮助较大,因此我们投入人力开发。运营同学有了好帮手,提高了效率,才有更大的发挥空间。
其次,产品经理和团队成员,要经常“对一下”和“问一下”。
“对一下”:我们在工作中,说得最多的就是“咱们对一下”。这是我在进入职场环境中,体会最深刻的一个词:对一下需求,对一下方案,对一下进度等等。千万不要不耐烦,这个简单的工作,能够保持团队成员思想、理解、行动、步调的一致性,避免因理解偏差,导致出错。
“问一下”和“对一下”类似,比如:我看到信息流中推荐了一篇旧闻“2017全运会-男子百米谢震业10秒04夺冠 苏炳添摘银”,我马上通知运营同学下线稿件,似乎问题解决了,其实这条badcase反馈的问题,不仅没有解决,反而被掩盖了。
出现旧闻,是审核标记错误,还是算法推荐时丢失了时间参数,或者是前端缓存未更新导致旧闻展现,还有没有其他case,能不能复现?
起初,我觉得这些是技术问题,产品经理不需要了解底层原理,但当leader向我了解情况时,我发现自己一问三不知,事情并不在我的掌控之内,假如真的发生事故了,我可能都还全然不知。
因此,不过于限制自己的边界,遇到问题,抱着请教的态度,向周围同学及时问、大胆问、主动问、勤快地问、厚脸皮地问,深入地问、追根究底地问、辩证地问,切莫担心会失去面子、也别怕招人烦。问到的知识都是自己的。
而如果我们不问,往往会给自己埋下一个坑,等产品上线后出现bug,投诉的用户涌进来,这时候才着急忙慌地去排查。有一次做AB test,我对“放量的人群维度是否一致”有些疑问,但没有及时询问开发同学,结果导致数据出来,我在做分析对比时,才发现数据差异过大,不是我设想的方案,只能重做,有苦说不出。
最后,关于团队,千万别把平台的产出、团队的成绩,误以为是自己的能力,沾沾自喜。随时保持谦逊的姿态,会让自己收获更多。
Ownership
这事我负责——领导者
这事我搞定——顶梁柱
这事我来做——左右手
这事我要学——基层员工
这事找谁啊——团队多余之人
这事不怪我——团队垃圾
这事没人教——团队落后分子
这事为什么我来做——团队寄生虫
虽然这是一则鸡汤段子,但我的实际感受却很深刻。我特别喜欢360每层楼梯墙上的座右铭,每天爬楼梯是我锻炼身体的方式,我摘录几句给大家感受下:
其中第2层楼梯上,讲的便是Ownership:“同样一件事,只有心怀Ownership才会做得更好”,用老话说便是:把工作当作是自己的事情,有主人翁意识。
有人说,这个简单,我有Ownership,那么请问一下自己,你是否会在吃午饭的间隙,思考怎么解决一个用户的反馈,你是否会在清晨上班的地铁上,思考如何去优化某个交互的体验,当项目出现问题,无人说话时,是不是自己第一个拉着大家讨论解决方案。Ownership不是一句空话,而是这些实实在在真真切切的小事情。
有人说,Ownership是负责人才需要的,但很多时候我们在项目中,并没有担任重要的工作,是不是就没必要心怀Ownership了?我记得,去年我们部门在突击某答题项目时,起初我并没有领到任务,主要工作是熟悉需求文档和设计稿。
剩余的时间,我便拿起手机,不断使用和体验APP,邀请好友安装体验,发现其中的bug,进而报给开发同学。反复多次,其他同事遇到bug,也会汇总给我。就这样,很自然地,我成了组内最熟悉我们APP bug的人。
在后续的一次集体扩大内测中,在几个工作群中,我自然地承担了答疑的角色。对于每位同事提出的问题,我都立即做出判断,并给出解释和反馈,最终,通过这件事儿,赢得了大家的信任和口碑。
当然,也有人会说,我就是一个打工的,何必这么拼命。每当你这样想的时候,其实也意味着,你放弃了成长的机会,放弃了对自己的挑战,放弃了自己未来的可能性。
当我在没有Ownership的时候,做项目只是机械地执行,遇到困难,第一时间想到的是反馈给leader寻求帮助,面对困境,不敢踏出去一步。当我心中充满Ownership的时候,我心中的想法是:我来主导,我来总负责,遇到困难,第一时间想办法,面对困境,努力找相关接口人协调资源,寻求解决办法。
有几位产品朋友,向我吐槽部门经常有一些杂活儿,很苦恼,例如处理用户反馈和投诉、给团队买夜宵、搞团建、布置场地。我想当你有了Ownership之后,你不会再为这些问题困扰。
执行力
执行力分为很多层面:
- 第一层面,是个人执行力,自身的干活速度、做事效率;
- 第一层面,是外部执行力,包括项目内部的研发上线、协调外部资源、推动外部门力量。推动并不是说,每小时去催一次进度,这样只会让对方不甚其烦。有效地推动,是合理的规划和安排,并在过程中及时check问题。
- 第三层面,最难也最重要的,就是尽可能做正确的事儿。错误的决定,不仅会把方向带偏,甚至推倒重来。这时候不仅错过黄金时间,队伍的心气都会没了,产品经理个人信用也大打折扣。那如何才能做出正确的决策,这方面我也在学习的路上,我在后文写了几点自己的经验教训。
我先举一个“如何开一场有结论的跨部门沟通会议”的案例,来讨论对执行力的理解。由于我们的产品经常涉及多个部门间合作,因此跨部门沟通成为了我产品工作的常态。那么,如何保证跨部门沟通顺畅、有结论。
举例:我们这次跨部门会议的主题是:在产品中接入商业化广告。
第一次开会,仓促进行,在会上我们讨论了可以接入的位置,进行了头脑风暴。由于每个位置是否确认可以接入广告,内部没有确认过,只能列入待定。每个位置有多少曝光,点击量预估多少,这些数据都没有提前准备,因此也无法准确预估出收入,更难以做出决策。
会议开的时间很长,开了两个小时,但最后的结论是:这些方案,我们回去再评估一下。两周之后,广告还没有接进来。
第二次开会,反思上次的问题,做了如下改进:
(1)会前,准备工作做足
充分了解各方的诉求,求同存异,互利共赢,这是合作的基础。我们作为媒体方,有多少流量,预估收益价值等,列出我们的优势,对方才会高优先级推进这项工作,因为从他们的视角,我们只是众多接入广告的媒体方之一。
预约相关人员时间,尤其是,要尽可能邀请能做决策的人员参与。
会前准备好相关方案:在什么位置接,接入什么类型的广告:CPT、CPC还是CPS,什么样式的广告:文字链、图文、橱窗,可能存在什么问题:文字链的长度是否符合要求、图片的尺寸比例是否适配。部门内部先沟通达成一致意见,个别问题,内部来不及开会的时候,可以在工位上,当面简要沟通。切忌在跨部门沟通时,自己的同事一脸懵逼,这时候自己也会被束缚了手脚,不知道哪个工作,能够落地,不敢发言表态。
(2)会中,提高效率
按时参加:会前10分钟,与各方再次确认时间。如果是视频或电话会议,提前15分钟调试设备,不要因人员迟到、设备故障,干扰会议节奏。
会议一开始,务必介绍一遍需求背景,否则很多同事是不了解情况的。我常犯这个错误,自己很理解这个项目,但参会的人,他们可能对这个项目,不是十分清楚前因后果。一开始就懵,后面会上讲的内容,更是听不懂。
同步现阶段进展、陈述问题,尽可能用图、表的方式,更加直观地展示,配合简要文字突出重点。
讨论解决方案:对于这种大会,切忌在现场,召集大家头脑风暴、现场讨论怎么解决。效率低不说,还常常讨论出很低质的方案。方案是提前沟通准备好的,会上主要是评审方案可行性和check每一项具体工作如何落地。
会议得出结论后,在下一步工作中,每件事情约定好负责人和时间节点。
(3)会后,同步会议结论
通过发送会议纪要邮件,同步结论,忌长篇大论。把结论、负责某一项工作的人,完成时间点列上。同时,可以创建一个工作群,方便后续沟通。
这样开下来的会议,一般能够得出可行、落地的解决方案,跨部门项目得以有效推进。
产品力
刚进入360时,我的一位指导人告诉我:“你要思考,当你某一天离开360的时候,我们的产品,有哪个功能、哪个页面,是你做的,它还在线上服务着我们的用户”。快两年过去了,我始终记得这句话。
目前,我负责360日活数亿级的产品,设计和推动了几处重要的产品功能迭代,尤其是今年完成了信息流产品新的里程碑,内容导出量增长两倍半,收入涨一倍半。
下面分享几点我对产品力的理解:
(1)与用户沟通
请问您多久与用户交流一次?
我最密集的时候,每天至少和2名用户QQ交流。我们日常可以通过查看用户反馈,了解用户的意见和投诉,也可以直接和用户对话。在用户面前,我就是一个专业的客服,帮助他们解决问题。
我的经验是:
- 一方面,尽可能把用户当作小白,用户需要的往往很简单,没有我们设想得那么高级。
- 另一方面,要听用户的,但不要照做。网上说张小龙,在负责QQ邮箱产品时,制定“1000/100/10”规定,即每月查看论坛1000个用户的反馈并回复、关注100名用户、做10名用户调研。
(2)自己的产品,自己要多用
我发现很多产品经理有一个共性:自己的产品,自己很少使用。用的最多的时候,是在产品上线前的功能测试。反省了下原因,可能是因为产品经理自身并不是产品的真实用户,也可能是因为自己的时间都忙于思考需求去了。
我曾经设计了一个红包活动资源位,我原以为效果不错,但上线后,数据让我大跌眼镜。我反复使用,没发现什么问题。后来,我找了几名同学体验了下,反馈1:第一眼并没有注意到这个资源位,反馈2:看完并不知道是可以点击的。
原来由于我陷入了自己设计的产品里,打开产品的第一眼,我就默认了它的存在,并且知道它是可点击的。
我们不仅要多用自己的产品,更要在尽可能真实的用户场景下去使用,把自己当作一名小白。
(3)保持对数据的敏感度
我每天早上刚到公司,第一件事情,便是打开数据中心,查看数据报表。数据是用户历史使用情况的反馈,往往可以从数据中发现不少问题。
但很多时候,通用性的报表,无法再细致地跟踪问题,不能不满足自定义的需求。当没有现成报表的时候,怎么办?向开发提需求、排期,等个一两周吗?
NO,我想每个产品人都应该学会的技能:SQL数据查询,例如下面这条语句:
SELECT PV, UV FROM 表名称
数据库就摆在眼前,学会了SQL查询,想查什么数据,信手拈来。
再比如:AB test也是一个绝佳的数据分析工具,能够给出明确的结论、精确指导产品工作。下表是一个典型的AB test,可以明显看出,试验组的效果优于对照组34%:
注:表格中的数据为虚拟值。
AB test的要点是,放量人群要控制相同,包括:时间、人群属性、人群数量。同时,按照控制变量法,每次试验只能有一个变量。比如两张海报中,只有标题的文案不同,其他设计、图片都保持一致,再投放出去,就能得出文案对转化率的影响情况。
(4)微创新
请问你对创新的理解是怎样的?我以前认为,创新是用一种技术完成了革命性、颠覆式的改变,才能称得上创新。但在360,我逐渐感受到,其实微创新,也是非常难能可贵。创新不是为了与众不同,它背后的原因,一定是为了更高的效率、更友好的用户体验。举一个我做的例子:信息流文章的不感兴趣关闭功能。
做这个功能的初衷,是因为有大量的用户,反馈文章质量低。一方面,我们去提高优质文章的分发比例,另一方面,我们提供用户主动关闭的选择权。
市面上的信息流产品,用户点击关闭后,这篇文章直接隐藏了。但这种方式,并不适合我们信息流两列文章的产品架构,关闭隐藏后,会导致剩余的文章左右移动。如果直接借鉴,开发成本高,用户体验还不友好。
经过几个方案的PK,最终采用了“关闭后,在原位置再推荐一篇不同兴趣类别的文章,其他文章位置不动”的方案。功能上线后,用户吐槽的反馈,减少了一半,用户数据也非常好,这个功能还产生了新增导出。
(5)商业化
还有一个问题,会困扰产品经理,那便是用户与商业化的冲突。商业化是产品的终极目标,不商业化那只能做公益了。
但加广告怎么加、什么时候广告加到了极限。比如说,当增加了数个广告,导致自然导出下降超过10%的时候,是不是说明已经有大量用户,因为广告的加入,开始抛弃产品了。
什么样的广告效果好?
经过我们一年的实践,不管是PC端还是移动端,原生广告的变现效率最高。核心在于原生广告具备高有效曝光。用户最反感的是弹窗广告,抢眼的弹窗,适合需要快速曝光的品牌广告。但同时,大部分的曝光,是没有形成即时转化的,因为虽然用户注意到了,但是在用户心里,这个位置默认是广告,选择性忽略或点击了关闭按钮。
如果一个位置,被用户默认成广告位,后续想再提升导出,就比较困难了。即使花了大量功夫,做了很多优化调整,甚至此时你把所有广告去掉,换成优质内容,也无济于事,用户已经形成惯性,默认这里是广告位,他的第一个动作,仍然是关闭。
说到广告,还踩过另一个坑。信息流文章和原生广告,“仅图片、标题可点击”,改为“整块区域(包括空白处)均可以点击”,改完后结果始料未及,自然流量和收入均较大幅度下降。
我想起Google的经典案例:2007年4月以前,Google搜索广告,只要hover在广告附近就可以点击。4月之后,Google采用了一个令人费解的策略:把整块广告区域可点击,修改为限制在标题处才响应点击,结果导致广告点击CTR大跌,以至于当年的广告收入腰斩。但Google并没有回退这项策略,坚持了一段时间后,广告收入竟开始疯涨,一直占到总收入的80%,更加令人费解。
奥秘就在于:用户误点击和广告转化率。减少用户误点击,提高广告主的实际转化率,帮广告主省钱,提高了广告投放效果。这个指标才是广告主是否加大投放预算的关键所在,众人恍然大悟。
(6)个人产品修炼
在个人产品修炼方面,如何保持对行业的敏感度。除了关注行业新闻和报告,我建议简单一些,直接上手实际去体验产品。为了研究一款产品,有的同学会去网络上搜寻大量的产品分析报告和文章,但我逐渐发现,不少文章,不仅有效信息少,还容易误解产品,造成误导。最经济的方式(时间成本),是直接去体验网站、下载安装APP。
此外,另一个有效途径是是找当事人聊,或者内部员工也可以,再不济可以找创始人的谈话、分享的文章。
如何保持产品思维的敏捷性,老周(周鸿祎)教导我们要经常做头脑体操。如果我们刷了3小时的抖音,只是开开心、放放松,那在我们脑子里,什么也没有留下。头脑体操,就是要不断去思考,这个短视频为什么要这么拍,为什么点赞量这么高。
再比如:我们平常晚上回到小区,看到电梯里的分众广告,可以思考,它是怎么设计文案和配图的,广告投放策略和小区人群是怎么样的。因此,我们可以多关注生活,尽可能地去体验生活和产品。
我们还可以通过多阅读,多与名家对话,保持思维的敏捷性,我今年看了12本书籍,如:《爆品战略》、《小群效应》、《流量池》、《上瘾》、《乌合之众》。也观看了30多部电影,如:《三块广告牌》、《我不是药神》、《楚门的世界》、《摔跤吧!爸爸》、《灵魂冲浪者》、《头号玩家》。
产品力,本质上是对产品的决策能力。而要做出正确的决策,尤其是在产品的关键阶段,就非常考验产品经理,对信息的掌控和处理能力。拍脑门想出的主意,往往会让自己声誉受损、失去团队成员的信任。当自己信息不足,难以做出决策怎么办?准备好备选方案,邀请leader、开发、设计、运营同学一起开会,共同决策。
360有六条价值观:用户至上、诚信正直、当则奋斗、开放协作、不断反思、持续创新,我得问问自己,我今年做到了几条?
反思自己2018年做的工作,事情多而杂、主线重点不突出、未形成聚焦合力。这可能也是很多产品人的现状。未来一年,我会把更多时间精力铺在产品的打磨上。我要收敛精力,集中力量做几件重要的事情。虽然“互联网寒冬”来临,但我们相信:长风破浪会有时,直挂云帆济沧海。2019,继续守住初心、坚持产品信仰、延迟满足感。
祝大家在2019新的一年里,突破自我,取得长足进步。
最后,用Steve Jobs的一句话,勉励自己:Stay hungry stay foolish.
作者:金师兴
下一篇:没有了
相关文章:
相关推荐: