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。

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

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

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

本文精选自图灵社区