上一节和玉伯聊了语雀的发展史,部分内容涉及玉伯对产品的理解,这一节继续围绕产品话题,聊一聊究竟产品经理是一个什么样的岗位,产品经理的基础能力模型是什么。
极客时间:依据你这么多年做产品的体会,你觉得应该如何定义产品经理这个岗位?
玉伯:我可以聊聊产品经理应该具备什么能力,拿语雀举例,我觉得产品经理需要具备三个核心能力。
第一个核心能力是,产品经理必须要有需求洞察力。需求洞察力从哪里来?一个最关键的来源,是来自产品经理在特定领域的专业知识积累。比如做语雀,得对文档,对知识库,对传统的知识管理,以及知识协同等领域有体系化的理解。比如对历史上的卢曼卡片法,比如新近流行的双向链接,甚至最早期的互联网里网页与网页之间的连接,以及知识网络等等概念,作为产品经理,都需要去探究究竟是怎么回事。产品经理要把产品所在领域当成一个专业去钻研,要长期有兴趣,领域知识的专业积累非常重要。
领域知识的积累是一个产品经理具备需求洞察力的核心要素。此外,需求洞察力来自产品经理对用户的好奇,知道用户在什么场景下会去用这个产品,用户的使用路径是怎样的,使用过程中的心理状态是愉悦的还是有挫败感,用户会用产品里的什么样的功能去具体完成什么样一件事,等等。作为产品经理,要对用户的用法能感同身受,要有一种灵魂出窍和灵魂附体的感受。
产品经理的第二个核心能力是,必须要有抽象和设计能力。产品经理在日常工作中,经常干的活就是逻辑抽象和设计,你在做产品的时候可以洞察到很多用户需求,但你不可能每个需求都用一个产品功能去实现,删繁就简的过程,就需要抽象设计能力。
拿语雀举例,我们在文档里设计了斜杠命令,这是一个功能抽象。用户在写文档过程中,很多情况下写着写着可能需要快速插入一个卡片或者是一个链接之类的。在这个使用场景下,人眼的焦点在光标处,如果不用点击菜单而是直接在光标处快速唤起功能的话,效率会更高。如果不抽象成斜杠命令和斜杠面板,我们得把所有功能罗列在工具栏上。抽象设计往往没有对错,内蕴的是产品设计理念,产品经理的不同喜好,会带来不同的设计方式。比如我们一直没有做即时浮动工具栏,因为我们觉得浮动工具栏虽然便捷,但同时对专业用户是个强打扰。任何设计,往往都有利有弊,很难去谈对错,更需要的是取舍平衡。在抽象完之后,作为产品经理,还要能够与团队一起,去用 PRD、设计稿把具体设计做出来,抽象和设计能力是一体的。抽象是把需求化繁为简,而设计是化抽象为具象,这是产品经理的第二个核心能力。
产品经理的第三个核心能力是,需要有未来洞见和规划决策能力。这是我自己这么多年的体感,也是现在对团队里高级产品经理的一个要求。能够看见用户需求,把用户需求经过抽象、设计转化成一个产品功能,这是产品经理的基本能力。要把一个产品做长久,还非常需要产品经理的长期的洞见和规划决策能力,面对纷纷扰扰的各种用户声音时,面对各种相关方的质疑甚至否定时,产品经理必须要能看见未来,能和核心团队成员一起有内心的笃定,同时面对各种短中期的利益时,能有取舍判断力,敢于说不,同时又能不伤着对方,能保持长期友好的合作态度。面向未来的规划和决策能力,特别难,但这往往是优秀产品经理进阶的必由之路。
极客时间:我看到语雀里面有很多用户,无论是在知识库里还是其他地方,都会给你们提很多建议或者需求,小到某个功能怎么改,大到语雀未来应该走什么方向,你是怎么看待这些需求的?你有没有印象非常深刻的用户的需求。
玉伯:用户的声音确实蛮多的,现在每天都能收到几百个反馈。面对这么多反馈,首先我觉得要分清楚两个概念:用户反馈和产品需求是两个东西,绝对不能直接把用户反馈当成产品需求。从用户反馈到产品需求还需要经过产品经理的专业转化,有些反馈可以经过抽象与设计之后,变成一个有效产品需求。
更多用户反馈,反映的是用户使用过程中的情绪,反馈是用户情绪的一个出口。作为产品经理,非常有必要去看用户反馈,这也是我们团队的基本要求。同时,作为产品,在看反馈时,需要在看见一个个具体的反馈后,能在晚上闭上眼睛睡觉时,对用户群体有个感知,知道有哪几个用户群体,每个用户群体当前使用产品时,普遍的情绪是怎么样的,每个用户群体,看重的产品功能究竟是什么,普遍期待的产品改进又是什么。能闭上眼睛时,脑海里有一幕幕电影般的用户印象。
做产品还要有个心态,叫“弱水三千,只取一瓢饮”。张小龙说,每天都有一亿人教他做产品,语雀也是,每天也有几百人在教语雀做产品。这么多用户反馈里,能抽象总结出来的产品功能点,往往也是非常非常多。是否都要去做?还要取决于产品团队对产品本身的思考和定位,同时还要考虑到团队的产研能力,是否有精力去实现某个功能后,能长期有效发展下去。这里有很多很多交集,每个交集下来,都是弱水三千取一瓢,最后从一瓢瓢里,不断取下去,剩下的最后一瓢,才是当下需要去做的。
极客时间:用户反馈不等于产品需求,可以讲个案例么?
玉伯:什么叫用户反馈,什么叫产品需求呢?这个蛮有意思。拿最近的一个例子来说,有一个语雀用户,很生气地给我们反馈一个事情,他说为什么我们写的文档发出来后,无法看到有谁读了?
他希望某篇文档可以在有人看了后,他可以看到具体是谁读了,有没有读完,如果在规定时间内没看,语雀需要进一步提醒,不断倒计时提醒用户去阅读完成。对产品经理来说,这是一个文档的指定人群已读并提醒的功能,从技术角度讲,是可以去实现的。但如果真去做的话,就会发现这种需求做不完的。从语雀当前的产品定位来看,这个例子中的需求,就只是一个用户反馈。
后来我跟他深入沟通这个事情,问他为啥需要这个功能,了解到原来他在负责公司培训的事情,有一些培训材料要提前发给学员看,他想保证学员在上课前都已看过。我后来就问他公司里在用什么办公软件,用飞书还是钉钉,他说用钉钉。我说你可以拉一个群,把语雀文档发到群里,用钉钉已读未读来看大家是否已收到。钉钉已读虽然不等价于文档已读,但已经能解决很多。后来这个用户还自己研究出来了更好的解决方案,用钉钉的消息标签功能来做,让已读的同学在读完后,主动加一个已读的标签。
有时候跟用户沟通,深入了解使用场景后,往往用户自己就能找到合适的解决方案。但确实,有些情况下,与用户越沟通,会彼此越焦躁,用户的情绪甚至会被激发出来,会非常不理解语雀为什么不去做他想要的某个功能。这时,只能说抱歉了,冷静客观地说清楚我们的想法就好。客户第一这句话,讲的并不是把所有客户都当成第一,而是要分清楚,这么多客户里,哪些是语雀的第一客户,哪些是第二客户。分清楚后,做到有理有据有节,就好。
极客时间:拒绝用户反馈时,是不是也要看场景的大小呢?
玉伯:这取决于产品定位。需求永远是无穷无止境的,如果什么需求都去做,这个产品就会什么都是,从而什么都不是。产品要有定位,有了定位就有了边界,有了边界才能清楚哪些需求应该做,哪些需求不应该做。
产品边界具体是什么?往往是探讨产品定位时,团队共同确定的一些共识约定,也包括共识的一些产品价值观。产品的价值观,往往就是团队的价值观。所谓价值观,最简单理解,就是你对一件事对错的判断,一件事情你觉得正确,是因为符合你的价值观,反之,一件事情符合你的价值观,你往往就会觉得是对的。像刚才那个用户的需求,希望能看到具体有谁读了文档,在我们的认知里,是有违背我们的价值观的,因为这涉及到用户隐私。真要做,也要分场景。在办公等互信场景里,因为已经在一个彼此了解的环境下,一篇文档具体谁读了的信息,是可以考虑公开的。然而进一步思考,语雀倡导的是轻松愉悦的学习工作氛围,如果自己是否阅读了某篇文档,是文档作者可看见的,那么就会对更多用户造成必须要去读完的心理压力,甚至会逐步引起同事与同事之间,在这种小事上的竞争,容易带来一些不必要的内卷。最后综合各种考虑,虽然这个用户的需求有其合理的使用场景,但语雀并没有选择去实现。
对于刚入门的产品经理,我们会让他去看用户反馈,一方面是让他增强用户体感,一方面是在训练他如何去真正看到用户需求。很多时候,用户给的反馈,你以为是一个需求,其实不是,而是用户在给你解决方案。比如“文档能指定别人阅读,能展现已读未读状态”,其实并不是用户需求,而是用户在给语雀提供解法,他真正的问题,在反馈里并没有告诉你,这在用户反馈中非常常见。分清楚什么是用户反馈,什么是产品功能,这是产品经理的第一课。
推荐一本书,叫《学会提问》。很经典的一本书,教你学会提问。产品经理有时候要反向看清楚这些问题,因为有大量的人向他提问。一个经典方法,是产品经理要学会 XYZ 思维。用户给你的是 X,你要去挖背后的 Y,甚至这个 Y 还是解决方案,你要继续挖 Z,你要挖到三四层才会知道原来用户是遇到了怎么样一个具体问题。张小龙在《微信背后的产品观》里也讲过,比如很多人都希望朋友圈有分组,挖到最后的需求并不是要分组,而是大家发朋友圈不想让部分人看见。不想让部分人看见那就有不同的解法了,在微信场景里,分组就不是最优解法,微信最终选择的解法是定向屏蔽。
极客时间:语雀的用户中,有没有超过你们预期的使用行为?比如你们本来没想到他会这么用。
玉伯:这个还蛮多的,因为语雀只是工具,这个工具可以做什么,更多是交给用户去发挥。就如你买一把刀,用来切西瓜还是切菜,这是用户的选择。
印象中很深刻的一个案例,是北大附中使用了语雀,除了常规的文档和知识库用法,我们发现,北大附中居然用语雀的话题功能,来组织同学进行线上辩论赛。参与的同学都很认真,一个话题,正方和反方发言有理有据,彼此讨论非常热烈。使用语雀来进行线上辩论赛,在北大附中老师主动跟我们说之前,我们自己都不知道语雀还能用来干这件事。
极客时间:对于高级产品经理的要求是未来洞见和规划决策能力,可以再具体解释一下么?比如拿语雀来说,未来洞见应该体现在哪里?
玉伯:面向未来的洞见力,是指能看到更大的一个局,能想到这个产品三五年之后是什么样子。比如我们去看个人版语雀时,它的文档和知识库是可以公开的,这个公开看起来就是一个知识库文档的公开能力,但这个公开能力真的往下探,它究竟在解决用户什么场景的问题?有可能的机会点在什么地方?我们需要去想这些问题。目前语雀个人业务做了一个升级叫做数字花园,最最简单的理解就是新一代的博客专栏,我们会通过数字花园这个概念去把这个理念做包装,那为什么不叫专栏博客呢,这里面就会涉及对未来的理解。
洞见来自于什么地方?往往是来自历史,来自产品经理对过往的观察。比如说我们提到的数字花园,是我们发现,团队内部很多同学,包括我自己,不太逛朋友圈,也不大逛微博了,公众号也不太看了,抖音有时候会刷,但刷完之后很空虚。我们就在想这究竟是为什么。刚才谈到微博也好,朋友圈也好,所有这些产品都有一个共性:它们是基于时间的信息流或者内容流,都有一个 Timeline,让用户活在一个个时间流里。时间流产品一定是满足了当下很多用户的需求,但同时会让一波用户感到焦虑,想远离。
所以我们在想除了时间流之外,是不是还存在空间流,空间流的基本结构是怎样的,空间流是否能解决用户的焦虑问题,是否有可能构建一套更好的信息消费形态。比如说我想去了解某个人,我去微博上或者朋友圈上看他发了什么,只能了解他最近的一些情况。但如果这个人能够把自己的一些体系化知识、学习资料等按知识库分门别类的方式构建出来,形成一个个知识空间的话,那这个东西是从时间流里面脱离出来的一种空间沉淀。这个空间的沉淀就像花园里的景色一样,我们称之为数字花园。这是语雀很宏大的一个设想。
极客时间:我还有个特别好奇的,你说现在每天都会有几百条用户反馈,这个反馈量开始有多少,大概是怎么样的波动情况呢?
玉伯:最开始一天只有几条,后来快速增长到了每天一两百条,现在每天有四五百条,还在持续增加。我们同时有在做一些观察和调整,希望反馈量的增速是收敛的。如果用户反馈量一直涨,往往意味着产品有问题。同时,如果没有用户反馈,那是更大的问题。
面对用户反馈,不能焦虑,语雀目前积累了几十万条用户反馈。曾经我们这边有一个运营同学,想做数据挖掘,想通过科学的数据分析之后,从这一堆用户反馈里推导出语雀应该做什么产品功能。曾有一段时间,我们迷信过这类数据,但最终发现这个方式不对,走过一段弯路。
极客时间:这个讲一讲为什么是走弯路?他是有分析出一个什么决策发现不行,还是说其实通过数据分析也分析不出来啥?
玉伯:因为最后我们发现,数据的真正作用是辅助决策,数据一定不能绑架决策。
举个例子。曾经有段时间,我们挺焦虑语雀的用户增长,开始学其他网站做拉新,比如未登录时不让看,通过这种方式拉升注册用户数。从数据上看,用户注册数的确增加了。但同时,时常也会有用户反馈不好用,发给对方的语雀链接,对方看不了。这类反馈虽然不多,但每次看到时,总觉得哪里不太对。
后来我们把登录拦截去掉了。拦截虽然能带来短期注册上涨,然而用户的不爽,会影响产品的长期发展。做工具,还是得有良心,这是一个感性判断。
还有其他一些案例。我最大的一个感触是,一旦看数据很容易短视,这让我后怕。最终我们的经验是,数据是辅助决策的,最终决策还是得来自于产品的清晰定位和团队的长期信心。这不是说不应该看数据,而是要不断提醒自己,应该去看什么维度的数据。语雀目前最核心的两个指标,一个是付费客户数,代表有多少客户认可语雀,能让语雀长期健康发展下去。
语雀还有一个核心指标是自然留存率。自然留存率反映的是语雀的基础产品力。当用户来了语雀后,有多少用户会注册使用并长期留存,这是很关键的指标。如果一个用户主动想来用你,但你连这种用户都留不下的时候,这个产品就很危险了。当这个指标发生变化的时候,大概率表明什么地方出问题了。比如有段时间我们的短信服务验证码出了问题,导致自然留存率就暴跌,因为用户收不到验证码根本进不来。通过数据的反映,我们赶紧去解决这个问题。
找到一个好的数据指标挺难的。去找到合适的指标,也是产品经理的一项关键能力。语雀确定这两个关键指标,花了大半年不断讨论才达成共识。
极客时间:开始会看什么维度的数据?日活月活这种看么,如果数字很好的话,人性使然,人们还是更多愿意说这种证明产品很好的数字,或者叫虚荣指标。
玉伯:早期我们会看 MAU(月活)、DAU(日活)等数据。语雀的 MAU 很早就过千万了,但后来我们才想清楚,如果付费客户数没上去,MAU 越高,成本越大。
除了月活日活等流量指标,我们也会关注营收、用户平均使用时长等指标,会出现大量指标,充满诱惑。但一定要认识到,虚荣指标只是虚荣指标,并不代表产品的健康发展。
从这么多数据指标里,去找到符合语雀的关键北极星指标,需要不断去思考。比如,究竟语雀的业务方向是什么,语雀团队的竞争力在哪,语雀究竟有哪些重要用户群体,对用户群体提供的核心价值究竟是什么,把这些问题都逐步想清楚后,才能最终把关键数据指标确定下来。
关于产品经理能力进阶,这一节你可以关注:
留个小问题,你所负责的产品的核心指标是什么呢,欢迎分享,我们下一节见!
© 2019 - 2023 Liangliang Lee. Powered by gin and hexo-theme-book.