Facebook产品经理:PM应该是一位诚实的仆人

Chris Vander Mey,Facebook产品经理,前谷歌高级产品经理、前亚马逊技术产品开发经理和工程经理,他交付的软件正在被亿万人所使用。Chris曾多次带队在消费者或企业领域开发软件,其中包括亚马逊的实名制系统,也包括Google Maps。他在Google期间交付了Google应用Marketplace和Hangouts,很大程度上提高了Google Pack,他还为Microsoft Outlook开发了Google Apps Sync。在此期间,Chris自己也写了点C++。2012年他把自己的经验集结成书《谷歌和亚马逊如何做产品》(Shipping
Greatness)。

<<<-------------  <_< 向左看

你在大学期间似乎学习了很多不同的方向,航天工程、工程管理,甚至还有电视电影。你为什么最终选择成为一位产品经理?从这些经验中你学到了什么?

其实这更像是一种进化,而不是选择,而且我也不确定重新来过的话我会做同样的事!我热爱工程的技术性,也热爱电视电影中的工艺性。从很多方面来说,做工精良的软件融合了这两个方面,所以这也是一种合乎逻辑的选择。另外,我在接受正式工程课程以及沉迷于摄影很久之前就开始写代码了!作为一个软件工程师的成长过程中,我永远相信应该把用户放在第一位。我曾在很多情境下看到这样的情况:最有效地影响大多数用户的方式就是成为一位产品倡导人,而不是仅仅聚焦于软件开发的技术工艺上。

从这里看,问题的区别只是在于关注点。我在Facebook的职位是产品经理,这意味着我是一位产品倡导者,我不用去招聘工程师。但是我偶尔还是会深究一些技术问题。我的工程管理的同事们经常都是产品倡导人,但是他们还需要投入很多时间在招聘、人力管理,以及其他非产品方向的挑战上。这既是一种好处也是一种诅咒。好处是因为作为一位管人的经理,要说服工程师投入到某个方向上更加简单。说它是诅咒是因为这样你花在倡导产品上的时间就变得更有限了。我要说的要点就是,首先,必须要先成为一位产品倡导者,然后再弄明白如何更好地执行(通过计划、招聘、或者写代码)。

你在Facebook, Google,以及亚马逊都工作过,这几家公司在交付产品方面有什么不同?它们各自独特的优势是什么?

这真是个大问题,正常回答的话可能需要一百多页才能说清楚。简要地说,我认为最关键的区别在于文化。所有这些公司的员工都是很有才能,很有驱动力的人,你会很愿意和他们一起喝啤酒,和他们在一起工作也很愉快。关键的区别在于领导者,领导者如何做出决策,以及公司层如何确定投资的优先级。以下是一些可以帮助你理解这个优先级的宽泛总结:

亚马逊的利润很薄,因为它是零售商。关于每个特性如何影响底线,亚马逊有无与伦比的支持数据。所以很多决策,包括人事安排,都可以根据收入影响(或缺乏收入影响)来决定。

从另一方面来说,Google通过运营一个我们大脑难以理解的超级规模来赚取大量收入。这个规模的意思就是几乎所有的问题都变成了令人着迷的计算机科学问题,而且一个问题越有趣,它就越有可能造成一个更大的影响。所以Google强调的是计算机科学。

一部分Facebook的使命是让这个世界更加连通,从很多方面来说,“连通”可以通过用户活跃度来测量。所以在我看来,Facebook重视用户增长,互动,以及和直接收入影响或者技术栈发展的联系。

重申一遍,这是一个很宽泛的概括,能找到的例外比证据还多,但这是一个好问题,值得为之提供一个答案。

你怎么处理用户反馈?在这过程中有什么具体步骤吗?

亲力亲为。快速。如果你犯了什么错误就要道歉。如果碰到有些危险的问题,把公共关系部(如果你们有的话)拽进来。永远都要做到彬彬有礼。不要像我在书里那样用口头用语,但不要过分正式。简单来说:想象一下在你经历过的最好的购物体验中,销售人员是怎么做的。

对于产品经理和开发人员之间的沟通你有什么建议吗?有什么真实的案例可以和我们分享?

要诚实。做好一个仆人。如果你错了就要承认。有些开发者之间的问题最终注定是可以得到解决的,不需要强加干涉。开发者就和普通人一样,只是更倾向于二元思维,他们对别人要求他们解决的问题有更强烈的理解欲望。我们要明白,很多棘手的问题没有完美的解决方案,所以不要偏执地寻找那个纯粹的解决方案,而是以最简单为目标找到大家都能认同的,可运行的方案,剩下的问题可以留到下一个版本中来解决。

举一个例子,今天一位和我共事的工程师找我过去聊一聊曾经在代码评审中被另一位开发人员质疑过的线上/线下行为。首先,我试图弄明白问题究竟是什么,以及在app里的其他行为是什么。然后,我并没有重申我最开始的逻辑,而是枚举了我所有可能的潜在行为。我问那位开发人员他怎么想。他不确定,所以我建议完成最不需要花功夫,最简单的事,并且解释说我们永远可以在下个发布的时候做升级。这句话打动了他——虽然他还得去展开一些代码——但是我们得以继续前进。

如果一位开发者想成为产品经理,对于他你有什么建议吗?

写代码,永远不要停!你永远都不会技术性太强,当然,你永远都不该告诉一个开发者他该干什么。关于用户体验、写作,以及统计,能学多少就学多少。为什么?因为用户体验就是你的天下,你需要能够清晰地讨论微妙的问题和解决方案。而且只有你拥有了可以信任的数值数据之后,你才能知道自己是否成功。

产品经理最常见的错误是什么?

不要总是问:“我们现在可以做吗?”

忘记他们并不是老板;

为他们的事业操太多心。

我承认这三件事我都有纠结过。我也承认曾经因为这些问题向我的同事求助过!

大型软件公司比如微软曾经也制造过很多复杂但并不受欢迎的功能,其目的是吸引竞争对手的火力。客户和竞争对手都可能被这样的计谋蒙蔽。你认为这样的方法在今天仍然适用吗?你认为这是一种对战略上缺失的掩饰吗?

我怀疑这个方法在任何事情上都有效,但只是在短期内。你可以这样想:人们都会被进度所驱动。如果你每天工作只是为了构建一些根本没有用的东西,如果在有其他选择的情况下,你还愿意维持这样的工作吗?当然不会。在一个对于工程才能竞争异常激烈的世界,任何采用这个计策的公司都会变得更加缺少优秀的工程师。正是这些伟大的工程师让这个世界运转起来!

你有什么书可以推荐给雄心勃勃的产品经理们吗?对于刚毕业,有志于成为产品经理的同学你有什么建议?

在这里可以找到我的推荐书单,其中包括《谷歌和亚马逊如何做产品》,《变革》,《卓有成效的管理者》,《谈判力》,《人件》,《人月神话》,《创业的艺术》,The Goal,《点球成金》,Crossing the Chasm,《新机器的灵魂》,《群体的智慧》,《引爆点》,A Whack on the Side of the Head。

对于刚刚毕业的同学我有几条建议,一,读《谷歌和亚马逊如何做产品》;二,找一位导师;三,坦诚,诚实,开放地接纳反馈。这就是你提高的方法。

在未来你还打算再开自己的公司吗?这次出发你会有什么新调整?

我绝对还会再开公司的。上一次经历中我最大的产品错误就是我被迷人的科技冲昏了头脑,而忽视了用户在使用上的痛苦。下一次,我会先确保有真正的用户愿意付费,而这些人从头开始就不是团队内的人。如果通过解决你关注的问题真的能给人们减少烦恼,那你的方向就不会错。

本文精选自图灵社区

Facebook产品经理:PM应该是一位诚实的仆人,布布扣,bubuko.com

时间: 2024-10-24 23:16:36

Facebook产品经理:PM应该是一位诚实的仆人的相关文章

facebook产品经理要以长远眼光看待html5

凌雪起身,轻盈的走到我身边坐下,问道"搞定什么啊?你是不是大脑发热了,居然会雇佣王俊杰的人?他们一定会警觉的!" *!这圣骑士的防御力还真强悍,经受我一击之后,居然只掉了不到2000点气血,看这个样子,他的总气血应该也超过了20000点了,直追淡淡稻花香啊! 套装属性增加使用者45的攻击力.35的防御力,移动速度+75,气血回复速度+300,并且可以让使用者24小时内死亡之后原地复活一次. 不过有些可惜,偏偏这个小MM跟林傲有什么渊源,任我如何示好也不肯加入雪月,但是万幸的是,现在稻花

周鸿祎:如何做好产品经理

我刚才来的时候,会议主办方跟我讲,今天来交流的很多人是设计师.产品经理,据说还有 50 位公司的高管,我今天希望跟大家有一个交流,对很多公司高管来讲,我其实有一个建议,过去这种公司分工特别明确,做一个产品好像变成一个生产线,有人负责策划,称为产品经理,有人负责项目实施,称为项目经理,还有专门做 UE,我后来没搞清 UX 和 UE 怎么区分,曾经有一个大公司跟我讲半天,UX 是用户体验,UE 做 UED,分的非常细,我听了半天,这两个角色至少从我的从业生涯来说,我觉得很难区分,最后可能还有负责做研

想讨好程序员?在他面前开产品经理的玩笑就对了

很多人都觉得软件工程师们是一群聪明绝顶但装模作样的家伙,通常身边有这种朋友,大家心里都是又敬又惧又恨啊! 但其实要让他们把你当自己人倒也不难,先赢得他们的尊重即可.以下提供「内行人」的七大绝招,让软件工程师们对你另眼相待! 第一招:发送纯文字电子邮件 工程师们不欣赏内容繁琐又花俏的电子邮件,有人喜欢加上一堆修饰用语.花俏字体格式来丰富邮件内容,这种图文并茂的风格不会得到工程师青睐的!他们要看的是简洁有力的内容,最好是类似程序用语的写法,如果你想要加粗什么关键字,就在**关键字**两边加上星号表示

周鸿祎:做产品经理要用心、将心比心、处处留心

我刚才来的时候,会议主办方跟我讲,今天来交流的很多人是设计师.产品经理,据说还有50位公司的高管,我今天希望跟大家有一个交流,对很多公司高管来讲,我其实有一个建议,过去这种公司分工特别明确,做一个产品好像变成一个生产线,有人负责策划,称为产品经理,有人负责项目实施,称为项目经理,还有专门做UE,我后来没搞清UX和UE怎么区分,曾经有一个大公司跟我讲半天,UX是用户体验,UE做UED,分的非常细,我听了半天,这两个角色至少从我的从业生涯来说,我觉得很难区分,最后可能还有负责做研发的人,负责拿到产品

如何不被程序员(RD)们嫌弃--写给那些血气方刚的产品经理(PM)

编者按:本文是来自X小姐的第四篇投稿,第一篇文章<一个至今没做出靠谱好产品的产品经理是这样活着的>,第二篇文章<一个初次创业的互联网P民是 这样被投资人拒绝的--写于没有拿到任何投资意向书的某清冷夜晚>,第三篇文章为<针对女性开发的互联网产品还敢再男性思维一点么--来自白富美女票们的 哭与泪>. 最近有位刚做PM(产品经理)的小伙跑来跟我控诉,说公司技术部的RD们(程序员)个个不给力.需求过了千百遍还是理解错,或者就是简单回一句"做不了",表情如死灰

PM产品经理练级攻略(1-5等级)

大家都叫“PM”,但做的事情却完全不同? “PM”这个词到底是什么意思? 这个话题恐怕也是各位同行都一直在想,也一直想不清楚的吧,我也是. 每次看到各种“产品经理的能力模型”,我都觉得有点扯淡,总觉得模型里少了点什么,没错,就是“适用范围”,那一张张漂亮的图,必定只适合某些人,那么,到底是哪些人?于是,我的思路就是忘记一切模型,先去看各种顶着“产品经理”职位的人,他们做的事情为什么不同? 初想下来,和两个因素有关——内在vs外在,符合MECE原则哦. 内在是指个人能力,无法否认,一个叫“产品经理

资深PM告诉你为什么产品经理应该学习代码编程

大家都说产品经理不需要懂太多编程技术,不用太刻意学习编程知识,真的是这样么?今天和大家分享的是产品经理应该学习代码编程,为什么呢?一起来看看吧. 对于一个产品汪来说,创造产品是一件令人兴奋的事情(程序喵.设计狮按住了刀片....).产品经理们可以将自己天马行空的idea与在团队友(diang)好(guang).和(huo)谐(shi)的沟通之后转换为实实在在的产品.或者至少是制作出一个版本,然后发送给全世界. 每一天我都对我的工作所带来的创造性而备受鼓舞.而从零开始规划一个产品又往往会带来一系列

产品经理改变世界的9步法

"想要改变世界的人,都是最孤单的人".现在,产品经理已经不再是稀缺工种,但是很多拿着入门级薪水的PM改变世界的梦想犹在.其实,在你无数次的cosplay和殚精竭虑之中,其实有很多误区可以避免,有很多章法可以借鉴. 前百度贴吧负责人舒迅就梳理了自己十年的产品经验,结合了非常详实的优秀产品案例,总结出了产品设计的"九步法"长文,借用他的话--"谨以此文献给梦想改变世界的人". 多年以后,当我面对那些年轻的产品经理,我会想起自己当年从事的是一份高薪的工

【转】产品经理的职业规划:9步成为行业高手

在IT行业,如果你能够成为既懂技术又懂客户的PM产品经理,那是多么令人羡慕的职业!很多人不知道产品经理职业规划与发展的要领,以致在这条路上走得很艰难.多年以后,当我面对那些年青的产品经理,我会想起自己当年从事的是一份高薪的工作.那是2000年,我大学毕业后在北京一家IT网站做搜索引擎PM,当时我一个月的薪水能在亚运村买一平方米房子,十年之后,朋友招聘PM,开出的月薪和我十年前一样,差别是这时年青的PM用一年的薪水才能在亚运村买到一平方米的房子.对此,我很迷惑,于是咨询HR的同事,HR的同事告诉我