欢迎阅读互联网产品经理的自我修养,内容无节操,可能会影响发育。唯部分特异人士关注卢东东博客后能力飞增,一柱擎天,尺寸空前。

素未谋面的产品,关注他的博客很久了,博客文风嬉笑怒骂,看着不太正经,但藏着很多私货,值得细品。

整理了博文中认同的产品经理见解摘要,表示感谢。

博客地址:https://dou.lu

后来因为其.lu的后缀接触到国别域名概念,收入了现在的 zhan.lu 及 zhong.lu 。

优秀的产品经理定义

能够在宏观环境和微观场景里持续输出高质量决策的产品人员就是优秀的产品经理。

顶尖的产品经理画像

互联网行业,优秀的产品经理大约占总数的10%,他们推动市场的运行。顶尖的产品经理最多占1%,他们对市场作出真正的改变。

—- 乔布斯·雅各布·卢

我不确定我见过真正顶尖的产品经理,因为自觉顶尖的产品经理比自觉美丽的前台还要多,让我难辨真假。这并不是谁的错,人生第一大误会就是觉得你喜欢的人也喜欢你。这是好事,如果每个人都得知关于自己的所有真相,才是一件真正可怕的事。

每个人都以自己的人生经验作为素材,幻想过一个完美的朋友、完美的爱人。由于素材是真实的,幻想中的人虽然完美异常,却并没有超出寻常人的边界。所以这个幻想中的人是可以真实存在的,只是我们没有缘分遇到罢了。

同样的道理,勾勒出真正顶尖产品经理的特质,也就不那么难了。

1.富有创造力的想法

顶尖产品经理的想法不会受到当前环境、资源的限制,这得益于他们丰富的想象力和知识面。他们的点子总是能描绘出一个巨大的市场机会,并能制定出利用机会的具体计划。

2.强大的说服能力

由于顶尖产品经理的想法过于新奇,占团队中大多数的智力平平者难以理解和接受。如果没有强大的说服能力,顶尖产品经理的想法会越来越不受重视。

顶尖产品经理会在合适的时间引用合适的论据,抛出一个你无法驳斥和忽视的论点。会通过讲故事的技巧和人格魅力获得团队成员的支持。他们从不使用杜撰或夸大的“忽悠”技巧,因为诚实是人格魅力的重要组成部分。

3.简化能力

顶尖产品经理懂得如何通过20%的努力获得80%的回报。他们能迅速将复杂事物分解简化。他们能利用合适的方法与工具更高效的处理繁杂的日常性工作。

4.优先级把控能力

顶尖产品经理能够娴熟的进行优先级排序。他们能够通过优先级平衡需求的攻与防。进攻型需求是指被用来实现业务增长的需求,防守型需求是用来消除业务阻力的需求,比如体验优化、bug修复等。

5.预测与衡量能力

顶尖产品经理能够以其过去的项目经验作为基准,去预测计划中项目的大致收益。预测本身是一个高难度工作,因为要面对未来的各种不确定性。比如一个项目的目标是带来用户活跃指标的增长,那影响这个指标的可能是公司内部的其它项目,可能是未来市场的变化、政策的影响、竞品的动作等。顶尖的产品经理能将更多的不确定因素考虑进去,通过合理的计算方式来进行预测。

6.疯狂的执行

一个顶尖的产品经理绝不会一直固守在产品的角色中。顶尖的产品经理从不承认其有固定的职责范围。在需要他们的时候,他们会去招聘优秀的人才、会帮助忙碌的前端写控件、帮助QA团队测试、突然消失一下午去和法务争执用户条款。总之,为了产品的成功,他们愿意做任何事,而且有能力做任何事。

7.了解技术

顶尖的产品经理不需要有软件工程学位。但他了解各类技术的原理和局限,在提出一个需求时,他能粗略了解技术实现的复杂性。有了这些,就能与研发人员作出正确的技术权衡(妥协)。“这个需求很简单,怎么实现我不管”这句话绝不会出自顶尖产品经理的口中。

8.知道什么是好设计

顶尖产品经理有着正常的审美,他知道什么是好的产品外观。并用设计师能够理解和接受的语言阐明当前设计的不足(虽然在满足需求的前提下,不建议产品干预设计,但有些时候指出不足是团队每个成员的责任,谁公司还没几个辨色力丧尽天良的渣设计师)并提出可以执行的建议。

9.产出简洁的需求说明

顶尖产品经理知道,PRD除了需要说明需求规格外,还要保证易读、无歧义,也就是“简”与“明”。在需求文档中,每一个多余的词汇都会淡化它之前那个词的价值,顶尖产品经理拥有强大的文字表达能力,他们愿意花费一定的精力,找到完美的词语来描述需求。

以上,九条足够了,写的越多,这样的产品经理就越少。

如果你是HR,那么不要以招聘到顶尖产品经理作为目标,这是需要缘分的。把关注度放在那10%的优秀产品经理身上。琴瑟合鸣终是理想,锱铢生计才是现实啊!

装逼概念

以下是几个著名的概念,在中国经常被各色人等用来装逼。鲁先僧从专业装逼角度对各种概念进行了深度解析,通俗易懂,老少女咸宜。

青蛙现象

据说把一只青蛙放在开水里,它被烫就本能的跳出来。但如果把青蛙放在冷水里慢慢加热,青蛙就会被煮死。因为当青蛙感受到烫的时候,它已经来不及跳了。

青蛙现象是说当事情缓慢恶化时,并不会引起人的警觉,最终导致灾难。

不光动物如此,这种现象也适用于菌类。例如,如果木耳由粉变黑的过程是瞬间的,木耳就会通过减少运动摩擦的方式防止变黑。如果变黑的过程是缓慢渐进的,就会沦落到“屌丝终有逆袭日,木耳再无回粉时”的尴尬境地。

二八定律

二八定律说的是在物质匮乏的年代,二八自行车作为一种奢侈品,只被20%的人拥有,剩下的80%是买不起或买不到二八自行车的。

在任何一组东西中,最重要的只占其中一小部分,约20%,其余80%尽管是多数,却是次要的。社会约80%的财富集中在20%的人手里,而80%的人只拥有20%的社会财富。这种统计的不平衡性在社会、经济及生活中无处不在。

马太效应

马太效应说的是,在东北有一位姓马的老太太,街坊都叫她马太。马太家里很穷,为了改善生活,马太勤俭持家艰苦劳作,但这些让马太付出了大量的时间成本和健康成本,为了弥补这些成本,马太更加勤劳。人的精力是有限的,马太陷入了恶性循环中,导致越来越穷。终于,马太的房子拆迁了,马太一夜暴富。目不识丁的马太用补偿款买了三套房,房价上涨后,马太卖掉了这三套房用所得利润贿赂官员弄了一块地,各大银行主动登门贷款,马太摇身成为房地产老板,越来越富。

从此以后,“马太效应”就被用来描述社会中普遍存在的两极分化现象。

木桶理论

木桶理论就是说一个木桶能装多少水是由最短的木板决定的。每个人都有短板,不管如何进步,永远都有一个木板是最短的。所以解决木桶短板问题的唯一方法是往桶里套个塑料袋……

破窗理论

如果一座房子的窗户碎了不管它,其它的窗户也会被人打碎。因为淘气的孩子看见破窗会以为这房子是没人要的。如果一条马路异常干净,路人就不会乱扔垃圾,如果路上布满了垃圾,路人就会不假思索的扔垃圾。

与破窗理论相似的还有破鞋理论,太高深了,我也没太懂。

刺猬法则

春天万物复苏,交配的季节到了。一对发情的刺猬紧紧拥抱在一起,但由于身上都有刺,被扎之后就分开了。经过无数次尝试,两只刺猬终于找到了一种合适的体位,即能不被扎,又能完成交配任务。

刺猬法则被用来描述人际交往中的心理距离效应。

手表定律

当一个人有一块手表的时候,他可以准确的知道时间,但当他同时戴了二十多块手表时,就会失去对准确时间的信心。

与手表定律相同的还有绿茶婊定律,说的是当女人只拥有一个男人时,她会认为这个男人是最符合自己的择偶标准的,当女人变成绿茶婊拥有多个男人时,其择偶标准就会发生模糊,永远也找不到最适合的。

分析需求

分析需求的方法

  1. 人性法:看看产品满足哪些方面的人性特征,比如好奇,虚荣心,炫耀感,社交等
  2. 采用特定场景的故事进行模拟测试,看是否符合用户的真正需求
  3. 从马斯洛五层次去看满足哪些层次(生理,安全,社交,尊重,自我实现)
  4. 伪测试法、ab测试
  5. 找公司的一些产品大牛,技术市场运营专家一起分析,经验丰富条件下能有效得出需求的合理性
  6. 结合产品定位和目标去分析需求试试
  7. 如果是已上线产品则可以通过后台数据进行分析需求

产品经理要懂技术吗?

要。

这是个好问题。

首先我们得搞清什么是技术。

技术可以指人类对机器、硬件或人造器皿的运用。

它也可以包含更广的架构,如系统、组织方法学和技巧。

网络词汇的发展让技术定义更宽泛,对身体技巧的运用,也被称为技术。

简单点说,会挖鼻孔算会技术。

知道挖鼻孔的原理,鼻孔的构成,快感产生的原因。即便不会挖鼻孔,也算是懂技术。

复杂点说,懂技术就是要体悟一个事物的体、相、用。 光懂例用,不懂理体,是无法进行创造行为的。

PM在工作中,如果让产品设计和技术两者在理念上泾渭分明,会严重限制自身能力提升。

如何才能懂技术呢?

  • 是否需要读个计算机学位才行吗?
  • 要参加个培训班吗?
  • 你能不能带带我?

有计算机背景固然好,但专业出身的,对技术的理解可能狭隘(从产品的角度)。至于培训班,是不适合PM提升技术的,短时间系统学习的也只是技巧和名词。至于让别人带和培养,你要记住,犬是人为培养训练的,狼是自己野蛮成长的,所以狗永远打不过狼。狼对自然界有重要价值,狗却只是人类的附庸。

所以,PM提升技术能力的最好方法是——在独立创造行为中学习。

成为一个面向自己的独立开发者,自己设计产品,自己做UI,自己编码,将自己的小想法付诸实践。没有成功标志,没有里程碑,什么不会就研究什么,在不断解决问题的过程中,你会获得比系统学习更好的实战能力和对技术原理的理解。

与系统培训相比,我的方法最大的优势是:连续的成就感很难让你放弃和拖延。

不要。

你猜为什么?

关于转职到产品经理前的心理准备(以设计师为例)

定义问题和解决问题一样重要。

大部分互联网流水线职位无法参与定义问题的工作,这会让他们有点沮丧,比如从设计师的角度可能想不明白为何要取消一条产品线,为何要设定一个新战略方向。

于是很多职业就决定转行做产品了,他们觉得如果自己能够决策和统筹,一定能把产品做的更好。

就像我觉得如果我来当XX,就能让天下变得更好,起码人们不至于连XX都不敢写出来。

当然,转行PM是件好事,每个敢于尝试的人都值得钦佩。这篇文章列出了设计转产品可能遇到的不适和一些方法。

完全不同的日程管理

其实绝大多数设计师,一周的大部分时间都没有日程安排。如果你是个有用日历习惯的设计师,你会发现你安排好的日程也就占你20%的时间。所以设计师每天都有大把的时间进行深度投入的设计工作,能够专注于高认知要求的工作任务。

而作为PM,情况正好相反,80%的时间都是被计划好的。以敏捷项目为例,站会、冲刺计划、冲刺启动、review,都需要PM的深度参与,此外,PM还要处理很多计划外的事,解决突发问题、跨部门沟通、了解用户客户、甚至应对突如其来的撕B……

PM要完成以上的日程,剩下的时间还要完成自己繁重的本职工作:写文档,用户故事,策划,思考解决方案,画原型……。这对时间管理是个残酷的挑战。

但当PM的好处是,你可以用PM的身份参与任何与产品有关的会议,并输入你的想法,这是设计师转产品前十分渴望的。但问题是,这些会议会牺牲你更多不被打扰的时间,你更难去深入思考解决棘手问题。

没有尽头的代办事项

作为设计师,你每天都能有一列简洁的代办事项,即便有些事项的时间花费比预期长,但总体上并没有什么变化。

而PM每天的代办事项会越来越多,优先级也可能在一天内频繁变化。比如你今天优先级最高的事项是准备明天立项会议的PPT,但QA突然跑来说,昨晚的上线导致以前的功能出现Bug,于是你的最紧急事项就变成了解决bug带来的损失。

PM作为救火队员,大脑需要频繁的进行上下文切换,频繁的奔赴各种火场。这种长时间的亢奋状态通常让新手产品经理很享受,但相信我,没多久你就会感觉疲惫。因为每天你的压力水平都处在高位,这只会增加你的焦虑和抑郁。

控制压力水平这件事,似乎那些打着高手标签的PM从来没分享过。其实这才是国内PM生存的关键。

我来分享一个有效的框架:小事化了、坐享其成、用人不疑

  • 小事化了:那些不重要也不紧急的任务是否可以不做?
  • 坐享其成:有些日常任务是否可以自动化?
  • 用人不疑:一些任务别人比你更擅长更有效率,是否可以请别人帮忙?

消失的团队边界

作为设计师,你通常存在于两个团队。一个是你的项目团队,这包括你和PM、研发等,你们一起打造产品,一起经历艰难和喜悦。另一个团队是你所在的设计团队,你在这个团队中与其他设计师交流你们的专业领域,这个团队让你产生归属感。

而PM,要和其他很多部门和团队成员保持协作关系。从责任上说,PM既要为用户体验负责,也要和其他部门一起为业务指标负责。团队边界消失,那作为PM的你如何处理这些团队之中或之间的人际关系、利益冲突甚至政治斗争?尤其在大公司,这是很可怕的难题。

设计师每天大部分时间都在和志同道合的同行合作,但PM要跟各种形形色色熟与不熟的人合作,我的感受是,别看PM跟谁都能嘻嘻哈哈,实际上很孤独。

完全不同的工作流程

作为设计师,你早就学会了5步设计流程:移情、定义、构思、原型和测试。通过你的经历,你拼凑出了自己对设计流程的观点与方法。作为设计师,你总是专注于理解问题、定义范围、探索想法、测试假设和交付。你的项目在你把设计文档交付给工程师后就结束了,你很快就被撵到了新的项目中。

但作为一名PM,我要同时兼顾多个项目的不同阶段。例如,我可能与我的设计师一起探索一个动效的想法,同时与我的测试工程师一起对另一个项目进行QA,此外,我还要监控第三个项目的数据分析。保持多个项目并行运行,需要每天在不同的产品阶段之间跳跃。这与设计师不同,在设计阶段,设计师通常一次只专注于一个项目。

残酷的沟通

设计师通常在需求定义好的价值之上发挥创意,设计师最常说的句型是:是的……而且……。这永远都不会得罪人。

PM最常说的词是“不行”。不行意味着不会因为涉众的利益牺牲产品价值。但没有人喜欢被拒绝和否定,如何说了No还不得罪对方?这样才能保证以后的合作关系,才能保证最终的项目进度和产品质量。

这里的学问太大,不好展开讲。(我也没太整明白~)

总之设计师和PM都需要鼓励其他人向他们提出想法和要求,同时也可以提出不同的意见。关键的区别在于,PM要默认说 “不”,因为执行产品策略的本质是选择不做什么。而设计师则要说 “是”,以积极的态度去解决问题。

最后

其实设计师or产品经理只是一个权衡问题,两者没有优劣,薪资差别也不大。

如果你犹豫要不要转产品,那不妨问自己几个问题,了解自己更适合哪个,而不是看起来更喜欢或者更习惯哪个。

  • 你理想的工作环境氛围是什么样?你讨厌的又是什么样?
  • 你的沟通风格是?
  • 你喜欢被如何管理?
  • 什么能给你能量?什么会消耗你的精力?
  • 你想如何为团队带来价值?