作者：(美)Gayle Laakmann McDowell,Jackie Bavaro
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
产品经理面试宝典试读：
致谢
感谢所有在写书的过程中给予我支持的人。
Paul Unterberg、Adam Kazwell以及两位不愿透露姓名的人，我向你们致以深深的谢意，感谢你们愿意在这本书中展现自己的简历。
Fernando Delgado、Ashley Carroll、Brandon Bray、Thomas Arend、Johanna Wright、Lisa Kostova Ogata、Ian McAllister、Adam Nash、Sachin Rekhi和Ken Norton，我和Jackie以及我们的读者非常感激你们对此书的贡献。
那些提出建议及反馈的产品经理（及相关）朋友、同事们，也谢谢你们！你们棒极了！
感谢我的丈夫John和我的婆婆Donna，正是你们不间断的支持使得此书得以问世。
我那漂亮的儿子Davis，总有一天你会长大，会读到这一段话，到时你就会知道我有多爱你。——盖尔
感谢爱意浓浓的家人。我的父亲对收费大桥上的罗嗦行文十分不满，我拿这个例子来作第一道产品经理面试题。我的丈夫在我写书的过程中不断鼓励我，我的猫也常伸爪相助。
非常感谢Steven Sinofsky和Marissa Mayer，是他们雇用我到了一支才华横溢的产品经理队伍，并且帮助提高了产品管理的水平。
非常感谢我那几位出色的经理——Mike Morton、Tom Stocky、Jack Menzel、Johanna Wright 和Justin Rosenstein，你们是我了不起的导师和榜样。
感谢那些与我分享产品经理的经验和建议的人。很多人可谓英雄所见略同，这真让我吃惊。我要特别感谢下面这几个人：感谢Shirin Oskooi，你帮我迈出了第一步；感谢Daniel Dulitz，你提议写一个关于从设计师转型为产品经理的章节；感谢Nundu Janakiram，你提议我写一个关于产品经理误区的章节；感谢Chrix Finne，你为我介绍了许多很有帮助的人。——杰基第1章简介
产品经理是个奇怪的职位。
对很多职位而言，从 A 点到 B 点的路径相当清晰。如果你要做编程工作，就去学习如何编程。上大学读计算机科学专业，或者自学如何编程。做会计师、律师、医生等，无不如此。
如果想做产品经理，你该怎么办呢？没有教产品管理的学校。没有正规的培训。一般也没有对应的提升职位。
那么，如何才能当上产品经理呢？本书就要来讲讲这个问题。
杰基我们俩跟不计其数的产品经理都有过合作，帮他们学习如何积累合适的经验，如何摆正自己的位置，如何准备面试，以及如何轻松拿下这一职位。
花费了大量时间的训练课程和对话，最终转换成了这本书。1.1 这个为什么重要
产品管理不应该是这么虚幻的职位，只有那些足够幸运（并且有关系）的人，才能听别人解释产品管理究竟是什么，才能涉足这个岗位。其实，有更多的人参与进来，对应聘者和雇主都是好事情。
作为应聘者，你可以更好地根据职位需要调整自己。不是说要让你去装，而是只有知道自己缺什么，才能真正去获取那些经验。
当要面试时，你可以有效地针对他们的问题作准备。你要知道如何介绍自己独特的经验，以及最重要的工作成果；还要学会如何解答面试问题；而且要深刻理解从用户出发意味着什么。最终还能夯实你的专业技能。
反过来说，雇主也能找到更多胜任的应聘者。放松而准备充分的应聘者比较能表现出自己真实的水平。他们知道哪些工作成果最能引起雇主的兴趣，最能说明问题，并且能将对话向那些事情上引导。只要真正理解问题的指向，他们就能展示出解决问题的高超技能。他们可以学会应对特定问题所需的知识点。这种准备过程可以考验应聘者从事实际工作的技能。
把面试过程中的猜测和盲目性去掉，对所有人都是好事。1.2 我们是谁
从作者介绍中你可以看到我们的经历：谷歌、微软、苹果、创业公司、招聘委员会、大量的面试和教学课程，等等。
这一切都很不错，但还不能让你了解我们真正的身份，以及我们为什么要写这样一本书讲授如何得到产品经理的职位。
我（盖尔）有着深厚的工程背景，但我也花了很多时间来做跟招聘有关的工作：招聘开发者和产品经理，进行模拟面试，教应聘者如何改善自己的答案，教会他们不懂的概念，发现他们的愿景和激情。
通过这些我学到两件事情。首先，我认识到，即便应聘者很优秀，但只要稍加指导，他们在面试中的表现也有很大的提升空间；其次，我发现有关应聘产品经理职位的信息非常少。很多人都在谈论如何做一个优秀的产品经理，但很少有人谈论如何才能进入这个领域。
当然，除了我那位迷人的合作者杰基。
我在问答网站 Quora 上无意中发现了她的博客，就关注上了。过了一段时间，有几件事打动了我。首先，她在几家顶级公司工作过，所以她自己就可以把这些面试吃透；第二，她的建议切中要点，不但可行而且非常优秀；第三，她重视。她足够重视，所以写博客来帮人们进入产品经理这个领域。
让更多的人可以涉足产品管理领域对我和杰基来说都很重要。我们相信每个人都可以从中受益，因此我们就写了这本书。1.3 现在怎么办
这本书不是让你假装成能够胜任产品经理的工作，而是要给你一个有始有终的作战计划。
我们会告诉你产品经理是什么样的，这个职位在不同的公司会有什么样的变化。我们还会介绍不同公司是如何考虑他们的招聘流程的。
我们还会跟各种背景的产品经理交谈，了解他们是如何进入这一领域的，看看他们认为优秀的产品经理应具备什么样的特质。我们还要探讨产品经理一般会有哪些背景，你又如何根据自己的背景和兴趣作出这种转变。
我们会告诉你如何写出出色的简历和求职信。其中有些建议不局限于产品经理，但大部分是专门针对产品经理的。
我们会建议你如何准备面试：面试前需要做哪些研究工作，为了回答问题还要作哪些准备。我们会分析几类主要的面试问题，主要包括：行为问题、评估问题、产品问题、案例问题和编码问题。而且，我们会向你解释面试官想知道什么，以及你应该如何掌握这些问题。
我们会帮你展示出自己最好的一面，帮你成功入职。
在阅读这些内容时，你可以想想如何在面试时亮出你的优势，如何做出强有力的响应。
crackingthepminterview.com获取更多资源和建议。
最后，就像软件永远不会“做完”一样，我们希望这本书也不会。如果你有建议、反馈、问题或者只想打个招呼，不要犹豫，给我们发邮件吧：gayleandjackie@careercup.com
谢谢，祝你好运！
盖尔·L．麦克道尔
facebook.com/gayle
twitter.com/gayle
technologywoman.com
quora.com/Gayle-Laakmann-McDowell
杰基·巴瓦罗
facebook.com/jackie.bavaro
twitter.com/jackiebo
pmblog.quora.com
quora.com/Jackie-Bavaro第2章产品经理的职责2.1 什么是产品经理
产品经理（PM，Product Manager）的职责是确保团队能交出伟大的产品。
有人说产品经理（有时也叫专案经理或项目经理）就像产品的小 CEO。从某些角度来说这完全正确，因为产品经理要全面承担产品的责任，事无巨细面面俱到。产品经理要确立愿景和策略，产品经理要定义成功的标准，产品经理要作出决定。
但把产品经理说成 CEO 漏了最重要的一点：产品经理没有团队的直接人事权。
作为产品经理，你需要学会如何在没有权力的情况下领导你的团队，用你的愿景和研究影响他们。产品经理在大多数公司里都非常受尊敬，但工程师更受尊敬。如果你摆架子，对身边的人颐指气使，就会发现可能很难把事情做成。毕竟工程师才是真正构建产品的人。你需要得到他们的支持。
产品管理这一职业之所以这么吸引人，其中一个原因是它综合了技术、业务和设计三方面的知识和技能。你要扮演很多角色，并且要了解多种观点。
作为产品经理，你要为客户代言。你得了解他们的需求，并将这些需求转换成产品的目标和特性。然后你还得确保以一种内聚的、精心设计的方式构建那些特性，能真正解决客户的需求。从总体大局到细枝末节，一切你都要关注。你可能头一天还在对团队的三年愿景做头脑风暴，而第二天就得处理对话框按钮的各种细节。
产品管理是一个需要高度协作的岗位。产品经理通常是工程师和其他角色之间的主要联络人，包括但不限于设计、质保、用户调研、数据分析、营销、销售、客户支持、业务开发、法务、文案、其他工程团队，以及管理团队。产品经理通常要负责确定何时引入哪个团队，如果没有相应的团队，还要负责填补那个空白。2.2 产品经理的职能
产品经理的日常工作会随着产品生命周期的过程发生变化。一开始，你得确定要构建什么；中间要帮团队取得进展；最后要准备推出产品。
尽管不同公司的产品生命周期是不同的（有时甚至不同的团队都不一样），但通常都会遵循研究及规划、设计、实现及测试、发布这样一个通用的模式。当然，这些步骤经常是相互叠加的，并且彼此之间相互反馈。
有些公司或团队将产品经理的职责分给两个人：一个偏重于业务，一个偏重于工程。在采用这种划分方式的公司中，偏重工程的那个人被称为技术专案经理或技术产品经理（TPM），偏重于业务那个人被称为产品经理（PM）。
如果团队中有一个 TPM 和一个 PM，则产品经理专注于研究规划和发布，而技术产品经理更多的是专注于设计以及实现和测试。比如说，产品经理会研究市场并定义需求。TPM 会跟 PM 一起合作，将那些需求变成要完成的特定功能的工作，然后促成工程团队构建它。2.2.1 研究及规划
所有的产品和功能都是从研究及规划开始的。这时候产品经理开始思考接下来该做什么。下一个点子可能来自于客户的需求、竞争分析、新技术、用户研究、销售或营销团队、头脑风暴，或者产品的总体愿景。
根据该职责的范围，产品经理在这一阶段的大部分工作是创建或提出一个路线图。也就是说要给团队找出一个有凝聚力的长期规划。产品经理要跟所有可能的信息源交谈，列出潜在特性或开发工作的大清单。然后根据客户需要、竞争格局、业务需要和团队的专业知识等因素，确定各种功能和方案的优先级。
产品经理提出路线图后，就要争取其他人的认同。在某些公司，比如微软、苹果和亚马逊，有一个自顶向下的审批过程，高管和董事们很早就会参与其中。而其他公司，比如谷歌、Facebook 和很多创业公司，采用自底向上的途径，产品经理的工作重点是争取工程师的认可。
他一旦选定特性集，就意味着产品经理成了这方面的专家。他要深入思考待解决的问题，想清楚那些功能的目的。在后续阶段，团队中的所有人都会提出各种问题，包括“我们为什么要做这个”，那时候就需要产品经理给出答案。
这也是产品经理开始定义成功标准的时候。他会想象团队成功后的世界是什么样的。很多公司用目标和关键结果（OKR）模型来交流团队最重要的目标。在这个模型中，产品经理跟团队一起拿出他们能够为之努力的可测量结果。2.2.2 设计
一旦产品经理与大家达成一致，知道团队将要构建什么，就该设计产品和特性了。
产品设计不只是用户界面（UI）设计，也不仅是要勾勒出产品看起来是什么样的。产品设计是要定义产品的特性和功能。在不同的公司和团队中，产品经理在产品设计中所扮演的角色会有很大变化。
在某些团队里，特别是在微软发运软件（跟在线软件相对）的团队中，产品经理要写出详尽的功能规范（spec），其中包括：
目标
用例
需求
框架图
描述该功能的每一个可能状态的要点
国际化
安全性
然后会由开发人员、测试人员和其他产品经理用几周的时间对这个规范进行检验、评审和迭代。在这些团队里，所有面向用户的决定都要由产品经理来作。
其他团队的规范要松散得多，并且设计过程也更迅速。产品经理可能就是跟一位交互设计师坐一坐，聊聊目标，在白板上头脑风暴一下，然后在设计师的模拟产品上给出反馈，不断进行迭代。模拟产品准备好后，产品经理可能会把它们发给工程师，邮件里可能只写几句话。在这些团队中，一般由工程师作出比较容易的产品决策，再去跟产品经理商量那些困难的决定。
对某些团队来说，特别是在苹果，设计工作大部分是由专门的设计团队完成的，基本不需要产品经理参与。在那种团队里，产品经理可能更像是项目管理和救火队员的角色。
因为产品经理在产品设计中的作用可能变化很大，所以在你面试时一定要问清楚。问问你的核心团队和外围团队都有谁一起共事。找出你要用多长时间写规范，以及要跟设计师合作多久。了解清楚在形成产品决策时，产品经理、设计师和工程师能在哪里取得平衡。2.2.3 实现及测试
并不是工程师一开始编码就算产品经理完成任务了。在实现阶段，产品经理还要跟踪项目的进展情况，并及时作出调整。
在实现过程中，产品经理最重要的一项任务是帮工程师有效地工作。产品经理会定期检查他的团队，了解工作进展。
工程师经常会因为等待其他团队的工作成果而被卡住。这时产品经理要给工程师安排其他任务，同时跟那个团队配合，促成瓶颈任务尽快结束。
有时会发现实现一个功能的困难程度超出了预期，此时产品经理要想办法修改这样的功能，让它变得更容易实现。如果某个工程师的进度拖后了，产品经理可以认真地重新审查这项工作的进度安排，并砍掉优先级较低的工作。
在实现过程中，产品经理还要开始收集早期产品的反馈并报告bug。有时在设计阶段看起来很好的特性，在现实世界中可能达不到预期那么好的效果。为了找出这样的问题，团队要做可用性研究，试运行，并且在内部做“自我体验”（dogfooding）。
自我体验源自“自己酿的酒自己喝”，就是使用自己产品的意思。比如微软的人一直都会提前在他们的电脑上运行下一版的 Windows，Facebook 的员工也用 Facebook 群组交流。
有时候为了找出自己产品的使用办法，需要团队更有创造性。比如谷歌会给员工划拨 AdWords 预算，鼓励他们创造广告营销活动，以确保他们对自己的产品有充分的体验。
可用性研究是在产品推出前检验它是否好用的另一种办法。在可用性研究中，参与者会尝试一个新产品或特性的早期原型。这些参与者通常会得到一个情景或目标，并试着用这个原型完成目标。
比较大的公司一般会有专职的用户研究员，根据产品经理给出的输入条件开展研究。比较小的公司可能是产品经理做这些研究。不论哪种情况，产品经理都可以通过观察这些研究来判断困扰人们的地方，并找出关键的可用性问题。
自我体验和可用性研究对收集定性的反馈很有利，而如果你的软件是在线的，试运行可以帮你得到定量反馈。在试运行阶段，新特性会开放给一部分用户（实验组），而其他用户（控制组）仍然使用不带新特性的产品。在线软件的新特性通常都是凭借着这样的实验逐渐推出的。
你可以在实验中测量新特性的特定指标，比如有多少用户点击了你新加上去的按钮，以及像用户参与度、留存比例和收益等多项总体成功指标。通过比较实验组和控制组的成功指标，你可以判断出新特性究竟有多成功。
有了自我体验、可用性研究和试运行的诸多反馈，产品经理就可以确定那些最重要的问题，并对特性的设计进行迭代，找出更好的解决方案。这时，确定优先级是产品经理最重要的职能之一。如果要求团队订正所有的 bug，构建所有的新特性，那产品永远也推出不了。产品经理需要斟酌所有的新需求，决定是把它们放到当前发布中，还是排到以后再做。2.2.4 发布
开发过程完成后，产品经理要确保产品能平稳推出。各团队推出产品的过程也不尽相同，但通常都要做这样一些事情。
过一遍产品发布检查表。这里可能会需要关键利益相关者（比如法人代表）的最终确认，或者一个跟营销和运营团队相互协调的过程。
确保将要支持产品继续向前的团队准备好。对于在线产品而言，可能是客户服务团队；对于硬件产品而言，可能是制造团队；对于基于服务器的产品而言，可能是运营团队。
要为一切可能会出错的事情作好准备。随着发布将近，会不可避免地冒出一些紧急问题，产品经理要有如履薄冰的感觉。
在产品成功推出后，产品经理通常要向公司的其他人宣告产品的发布，跟团队一起庆功，然后准备好下一个任务再重来一次。根据团队的性质，产品经理可能会在产品推出后继续支持它，收集指标并根据用户的反馈进行迭代，也有可能会把产品交给另外一个团队去运营和维护。2.2.5 产品类型如何影响产品经理的工作
产品经理真正的工作在很大程度上基于产品是什么。通过 DVD 或在线软件商店交付的软件和可以随时升级的在线软件有很大差别。此外，一个成熟产品的产品经理跟一个新产品的产品经理也可能会有很大差异。
1．交付式软件
交付式软件是指像移动端 App 那样通过苹果软件商店交付或刻在 DVD 上交付的软件。交付式软件是独一无二的，因为在推出后很难升级。对于 Web 应用来说，你随时都可以发布一个新特性，如果出问题了，也可以迅速回滚。而对于交付式软件而言，第一次做对就非常重要。
因此交付式软件团队一般会有较长的时间线，并且产品需要更多的项目管理和团队间协作。功能规范也更重要，因为它的特性更正式，并且需要服务更多受众。用户研究和内部自我体验（使用软件的早期构建版本）也很重要，因为在产品对外发布之前你就得知道它是否好用。
擅于做项目管理并且有良好沟通技能的产品经理在做交付式软件时会有很棒的表现。对于想要维持工作与生活的平衡的人来说，交付式软件也很理想，因为这种软件通常不会需要你在几个小时内解决什么紧急问题。
2．在线软件
在在线软件中保持旺盛的斗志非常重要。产品更新相当容易，所以一般发展得很迅速。团队一般不会等着把产品做到很完美，而是要经常推出些东西，看看它怎么样，然后再次推出。
大部分在线软件团队都会进行 A/B 测试（也称为多元化测试或在线实验）。在 A/B 测试中，新特性只会向一部分用户开放。实验组和控制组的行为会在后面进行比较，看新特性是否提升了用户体验。
因为做在线软件的公司会采集到更多的数据，所以产品经理一定要精通数据分析和设计实验。此外还要能承受较大的工作压力，因为服务器随时都可能宕掉，并且产品经理经常要快速作出决定。
3．消费类产品
对于社交网络、照片分享应用和 Web 搜索这样的消费类产品，消费者就是普通大众，就像你自己、你的祖母和广大的工程师们。做消费类产品的好处是所有人都明白目标客户和用例。不过这同时也是一个劣势。
在面向消费者的产品上，工程师经常会有很多想法，不太依赖于产品经理拿出的特性和设计方案。产品经理经常扮演牧师和编辑的角色，指导产品向好的方向发展，而不是作出所有决定。
精通数据分析的产品经理可以很好地胜任消费类产品的工作，因为他们可以为自己的提案做出强健的案例，并且他们拿出的特性经常可以让公司所关心的核心指标得到改善。做消费类产品，你也很容易跟父母解释清楚自己究竟在做什么！
4．B2B 产品
对于在线广告或生产力软件这样的企业对企业（B2B）产品，客户是在另一个公司工作的人。对于这些产品，工程师知道他们不是目标受众，更倾向于依靠产品经理来了解客户。
B2B 产品的产品经理有时要考虑产品决策对收益会有什么样的影响。面对那些符合产品长期战略的功能和大客户当前就吵着要的功能，他们需要做出权衡。
喜欢做客户研究和营销分析的产品经理可能会喜欢做 B2B 产品。产品经理也往往能在这样的产品中发挥最大的影响力，所以他们会非常满意这样的工作。
5．早期产品
对于比较新的产品，比如那些即将推出或刚刚推出的产品，团队经常会专注于交付最小可行产品（MVP）。因为这还不是应对全部挑战的时候，你甚至都不知道产品是不是符合市场和客户的需要。所以你要尽快地回答这些问题，并证明你的核心价值。
产品经理致力于砍掉不重要的功能，将产品剥离得只剩下最基本的部分。这样他们可以更快地推出产品，立刻开始一个了解客户真正需要（或者他们是否真的想要这个产品）的学习过程。有时这意味着推出的产品还没能如你所愿地进行打磨。
喜欢刺激，并且愿意以简便快捷的方式做事的产品经理能做好早期阶段的产品。对在早期阶段创业的产品经理而言，最让人兴奋的事情是把只有几个微不足道用户的产品发展成有庞大用户群的产品。
6．成熟的产品
对于成熟的产品来说，比如市场上的领导品牌，大部分工作都是在已有产品上迭代，尽量完善它。产品经理通常会有前一版本的反馈，知道哪个区域最需要改进，可以把工作重点放在上面。
成熟产品的产品经理很重要的一点，是要确保自己不被微小的增量改进拖住。成熟产品的最大竞争对手经常是自己的上一版。与此同时，成熟产品通常都有充裕的时间在新想法上作出豪赌。
在成熟的产品上工作，最大的优势就是你已经有庞大的用户群了，你做出的每个改进都会产生巨大影响。从另一方面来看，很多公司都不愿意在成熟的产品上冒险，不敢作出大胆的改变。
想要在影响上百万人的产品上工作的产品经理，会喜欢成熟的产品。成熟的产品也能让你跟那些促成产品成功的人很好地学习。2.3 产品经理最大的几个误区
因为产品经理还不是大家很了解的岗位，所以人们对产品经理是谁，以及他们是做什么的会有很多误解。这里是关于产品经理的十大误区。
1．产品经理是项目经理
尽管有些产品经理承担了大部分的项目管理工作，但大多数人并不是这样的。项目经理关心的主要是时间节点和协调工作。尽管他们可能会负责收集项目需求，但他们在确定和选择需求上并没有多少话语权。
产品经理要负责找出问题和机会，挑选出会继续发展的那些问题和机会，然后确保团队能拿出优秀的解决方案，或者自己思考，或者跟设计师和工程师一起。所以对产品经理来说，对产品的感觉——能凭直觉判断出好产品和坏产品——才最为重要。
2．产品经理属于营销部门
这个说法很有欺骗性。因为头衔没有固定的标准，有时一些营销岗位也被称为“产品经理”。但像谷歌、亚马逊、Twitter 和 Facebook 这样的公司，产品经理不属于营销部门；相反，他们通常归属于与工程相关的组织。
做营销的伙计们是要把用户吸引到产品中，而产品经理则负责判断用户在使用产品后会发生什么。
比如说，一位营销经理可能会发布消息并启动社交媒体活动，而产品经理则是给出新特性，并跟工程师一起推出它们。虽然营销人员会跟产品经理探讨这些帮助传递消息或打造品牌的特性，但他们不会去设想那些特性的细节，也不会跟工程师一起构建它们。
3．你不可能大学一毕业就做产品经理
头衔中的“经理”这个词让很多人以为成为产品经理需要很丰富的经验。此外，因为产品经理要作许多对产品方向产生影响的决策，也让它看起来像是个高级岗位。
实际上，像谷歌、微软、Facebook 和雅虎这样的很多科技公司会直接校招产品经理。他们发现伟大的产品经理富有激情、智慧、强烈的客户关注和充沛的精力。如果你想成为一名产品经理，不要觉得你得先找份别的工作。
4．产品经理就是写功能规范的
产品经理的工作跟工程师或设计师非常不同。人们对工程师的期望是让他们交付有效的代码，对设计师的期望是让他们交付草图和原型。而对于产品经理来说，只交付一份规范是不够的。
产品经理要负责照看整个项目，直到它成功完成。编写规范是一种沟通和推动项目的技术手段，但规范本身并没有内在的价值。很多产品经理并不借助规范来交流他们的想法，他们可以用谈话，还可以把想法画在白板上。也有一些产品经理失败了，他们虽然写了规范，但却没有参照执行来确保团队理解并实现其中的想法。
5．产品经理只是召集开会的
有些人觉得产品经理的工作就是把关键的相关人员召集到一间屋子里作决定。好的产品经理并不只是被动地传递别人的看法。相反，产品经理要研究那个领域，并拿出自己的观点和框架来制定决策。
产品经理确实需要跟关键的相关人员碰面，了解他们的观点和优先级，但之后他们会把那些观点综合起来，取折中点，然后拿出一个令所有相关人员都能满意的推荐方案。在任何一次会议或谈话中，产品经理都需要呈现出所有不在场人员的利益。
产品经理可以减少队友们出席会议的次数，因为他们可以代表团队跟其他分组沟通，也可以找到其他有效的沟通方式。
6．产品经理构建出的东西应该跟客户要求的完全一致
做客户研究并听取客户的要求很好，但那还不够。产品经理的视野要超越客户所讲的东西，洞见隐藏的需求和更深层的目标。
厨房用具公司 Oxo 询问客户他们的量杯有什么问题，客户说的都是杯子掉下去后打碎了，或者它的把手太滑了。但他们仔细观察了人们如何使用量杯，看到人们先倒一些，然后弯下腰来看量度，再倒，再弯腰，再倒，再弯腰。
虽然没人要求在倒水的时候也能看刻度，但 Oxo 明白有这种需求。他们现在卖一种量度带有一定角度的量杯，这样你在往外倒东西时也能看到刻度线了。
7．产品经理确定日期
就像谷歌的产品经理 Nundu 说的那样：“日期不是产品经理定的，是工程师定的。”作为产品经理，你可以告诉团队你想让他们构建什么，然后他们会告诉你需要多长时间做出来。如果时间太长，你可以要求他们代码写得快点，但那没用。
相反，如果你要满足外部的截止时间，就需要进行取舍或协商。或者砍掉特性，或者找到并行工作的办法，并找更多的人来帮忙。有时你甚至可以更聪明，能找到办法减少工程师的工作量，比如让他们省去没必要的会议，或者让他们暂时少花些时间去参加新员工面试。
如果你不相信工程师的估算，给其他团队承诺的时间比工程师认可的时间要短，那会立刻破坏你跟团队的关系。
8．产品经理是老板
有些试图推销产品经理岗位的人会说你就是团队的CEO。实际上，产品经理对团队没有直接的权威。团队绝对没义务按照产品经理的指挥做事。
相反，产品经理要在自己没有权力的情况下产生影响，在团队中积累威信，清晰地沟通，收集数据搞研究，靠自己的说服力领导团队。只有当团队确信大家的目标一致，并且产品经理能够帮助他们更好地达成目标时，他们才会跟随产品经理。
作为产品经理，一定不要试图告诉每个人他该做什么，不要干涉设计师或工程师的工作。设计师有权掌控产品的设计。产品经理要明白那些选择，以及它们在总体体验上的影响。如果没能达成一致，产品经理可以提出来，但不应错误地试图去控制那些决定。
9．想法比执行更重要
一些刚刚从事产品经理工作的人有时会觉得想出好主意是工作中最重要的。实际上，想法的执行要重要得多。团队中的很多人都能拿出很多好想法，但通常细节才是困难之处。
作为产品经理，必须广泛征集想法，并把它们变成切实可行的。产品经理要考虑各种极端情况，确定出把一个想法变成现实所有的小步骤。这经常需要你亲自出手：在服务器上运行你们的代码，说服其他团队优先处理你们所依赖的工作，持续不断地使用产品，找出并打磨好所有粗糙的地方。
10．产品经理可以说“那不是我的工作”
团队中的大多数岗位定义得都很干脆，而产品经理的角色流动性比较强。如果你是产品经理，那你的工作就是其他人覆盖不到的所有事情。
作为产品经理，你要为产品的成败负责，没有什么工作是你不应该做的。如果有一项工作没人想做，你就需要想办法解决它——即便那意味着要由你来做。如果你放任不管，就不会有其他人来解决它。2.4 项目经理和专案经理
注意：微软那个被称为专案经理（Program Manager）的岗位跟大多数其他软件公司的专案经理不同，而是比较像之前描述的产品经理一职。
有很多岗位都跟产品管理相关，并且这些岗位之间的界限可能很模糊。如果你希望应聘项目经理或专案经理的职位，看看能否找到在那个公司做过这个工作的人聊一聊，弄懂这些要求之间细微的差别。
项目经理要确保他们的项目能按照预算及时交付，不管客户是谁，都要让他们满意。专案经理（不包括微软的专案经理）也差不多，不过他们通常掌管一个长期运行的专案，而不是一系列设定了截至时间的项目。
软件公司经常会有项目经理领导面向内部的团队，比如基础设施项目和运营专案，或领导重点面向单一客户的咨询团队。这跟产品经理相反，产品经理通常是带领团队构建面向客户的产品。然而这不是一个硬性规则。工作
关于这两个岗位，有两件事是很独特的。首先，项目经理有非常清晰明确的客户或目标。
基础设施和运营团队的项目经理，把公司内的其他员工当成自己的客户。其他员工通常都非常清楚自己想从项目中得到什么。
咨询团队的项目经理为单个客户服务，这个客户已经签署了一个包含每个项目细节的工作说明。
在所有这些情况下，研究、规划和设计阶段都相当简单直接，或者已经有人做好了。对项目经理来说，产品设计通常不是他们的主要工作，所以你可能会（也可能不会）被问到有关于产品设计的问题。
还有，因为客户非常关注项目结果，所以沟通和期望值设定非常重要。项目经理要乐于汇报团队的进展情况。项目经理一定要面向细节，跟团队打成一片，这样你才能回答客户提出的问题，并且能在出状况时做出解释。
第二个独特的部分是项目管理和专案管理很大一部分工作是预算和资源管理。项目经理经常要在成本中心工作，所以他们的精力主要放在运营效率和降低成本上，同时还要保证质量，而产品经理通常会屏蔽这些方面。
下面是项目经理和专案经理要做的预算和资源管理方面的一些工作：
澄清目标并收集满意度指标；
确定完成项目所需的人员和技能；
设置项目管理工具、规划和过程；
发起状态会议，收集状态报告；
分析数据找出机会；
确定并实现修改以提升效率；
管理客户做出的修改；
想办法让项目保持正轨，即便有事情出错时也不例外。
每个公司及其相关角色对项目经理的要求都不一样。有些团队要求有项目经理认证资格，而有些没有要求。公司一般都爱找之前有过项目管理经验以及拥有良好沟通技巧的人。第3章公司
产品经理候选人最想问的问题之一是：“这些公司有什么区别？”尽管产品经理在很多公司中的职责都非常相似，但实际上他们的日常工作可能会有很大差别。3.1 产品经理的职责有何不同
我们跟亚马逊、苹果、Facebook、谷歌、微软、雅虎以及很多创业公司的产品经理都聊过，以便了解每家公司产品经理的职责是什么样的，每个公司有何独特之处。
我们了解到，各家公司的差异之处大体表现为：部门之间的透明度、工作与生活的平衡度，以及对于有技术背景的候选人和有商学院背景的候选人，各公司的评价侧重。产品经理的职责在工作范围上也不一样，具体表现在对产品定义、设计、产品策略和项目管理等工作的参与度上。3.1.1 透明度
有些公司非常透明，比如谷歌、Facebook 和雅虎，很多地方都可以直观地看到其他团队在做什么。而有些公司，比如苹果和亚马逊，隔离程度比较高，每个团队只专注于他们自己的工作。
在比较透明的公司，经常可以见到产品经理在不同的团队间穿插，而且团队间的协作也是产品经理的一大块工作。在比较隔离的公司，岗位变动的情况比较少见，并且通常强制的多团队任务也比较少。3.1.2 产品经理与工程师的比例
产品经理与工程师的比例也可能会有很大差异。微软有很多产品经理，在某些团队中的比例高达 1∶3。其他公司比较常见的是 1∶10 的比例。谷歌和 Twitter 的产品经理与工程师比例非常低。产品经理在日常工作中与工程师的合作有多紧密，以及能负责多大的产品，在很大程度上取决于这个比例。
在有很多产品经理的公司，会有很多协作工作，并且有很多机会可以跟经验更丰富的人学习。在产品经理少的公司，很有可能可以负责一个很大的领域，并且可以独当一面。3.1.3 产品策略
在不同的公司，产品经理在定义产品策略时的职责也不同。有些公司的策略是“自底向上”的，重要决定经常来自开发人员和产品经理。有些公司的策略是“自顶向下”的，他们的方向通常是由高管和产品经理定的，开发人员只是负责实现。
在谷歌、Facebook、雅虎和亚马逊，产品经理会深入参与产品策略的制定，决定将产品带向哪个方向，以及何时开始新的行动。人们希望产品经理可以考虑他们团队的策略，比如专注于哪些客户和领域。他们会从很多人那里吸取建议和看法，但最终他们要呈现一个完整的计划。这些公司的产品经理一般都可以轻松得到一个工程师团队来实现他们的想法，最起码也能做到实验阶段，在产品推出之前完全不用高管批准。
而微软和苹果的策略一般是自顶向下的，不同的产品经理都按照这种策略执行。这并不是说产品经理在自顶向下的公司里影响不了策略的制定，但在级别升高之前，很多产品经理确实没有这方面的影响力。在这些公司，只有那些非常出色的产品经理才能把他们的想法推销给高管，赢得上层支持，从而影响产品策略。3.1.4 企业文化
另一个巨大差别是企业文化。在谷歌、微软、雅虎和 Facebook 这样的公司里，上班时的心态是无忧无虑的。这些公司有引以为傲的福利，比如免费的食品和饮料，甚至免费的按摩服务。并且因为人们可能会工作很长时间，所以他们总是说工作质量要比工作时长更重要。
另一方面，在像苹果和亚马逊这样一些公司的文化中，令员工引以为傲的是他们工作的努力程度。在这些公司里，员工应该会工作很长时间，并且崇尚节俭。这些公司的员工受到公司使命的激励，愿意在周末加班，或者在深夜接听电话。做一款优秀的产品可不是件轻松的事。3.1.5 他们招什么样的人
亚马逊喜欢招 MBA 担任产品经理一职，并且不觉得技术背景是必需条件。和少数几家公司一样，他们不会招大学应届毕业生做产品经理。然而，他们确实愿意接受应届毕业生担任专案经理（Program Manager）或技术专案经理（Technical Program Manager），这个岗位相对来说更偏重于项目管理，而不是产品设计。
苹果既招工程专案经理（EPM，Engineering Program Manager），也招软件产品经理，所以对于有电子工程或计算机科学背景的人来说，它是个不错的选择。苹果招聘应届毕业生做工程专案经理，在这个岗位上一般不会招 MBA。
Facebook 是技术性最强的公司，要求所有产品经理都有技术背景。这家公司崇尚它的创业时的“黑客”文化，并且有相当数量的产品经理是它所收购的公司的创始人，还有很多之前是谷歌的产品经理。他们招聘应届毕业生做轮岗产品经理，该职位包含 3 次为期四个月的跨团队轮岗。
谷歌喜欢招应届毕业生，通常是主修计算机科学专业的，开始要参加一个助理产品经理（APM，Associate Product Manager）计划，这是一个为期两年的轮岗计划。谷歌的一些产品经理有 MBA，但更重视硕士或博士学位。
雅虎主要是招有经验的产品经理，但现在也有一个助理产品经理计划来招募应届毕业生。雅虎看重有技术背景，并且能很好地跟工程师沟通的人。他们在寻找那种有良好产品感觉，充满激情的人，这种人既要有创新精神，又要能务实地交付有亿万用户的软件。
微软招的专案经理既有应届毕业生，也有经验丰富的人，并且更喜欢有技术背景的，尽管不一定必须是计算机科学专业的。另外，微软会在产品经理岗位上招聘 MBA，产品经理在微软是个营销岗位。微软的国际化招聘做得很好，在美国境外招了很多产品经理。3.2 谷歌
谷歌的结构反映了它的创始根源。谷歌对创新充满热情，并且十分推崇将伟大的想法变成现实的文化。谷歌的愿景是自底而上的，并且团队经常是由工程来驱动的。产品经理专注于策略、分析和促进工程师团队。
谷歌的独特之处在于各组织之间有着令人难以置信的透明度。任何一个全职的谷歌人都可以看到大部分代码和文档，并且高管团队会处理所有谷歌人在每周的全员“TGIF”例会上提出的问题。谷歌的产品经理在工作时经常会切换产品团队。3.2.1 他们招什么样的人
谷歌要的是那种喜爱技术，能够自我激励，并且有创新精神的人。有 MBA 或工作经验超过 4 年的人都可以应聘谷歌的产品经理，而那些经验不足 4 年的人则可以申请助理产品经理。
助理产品经理计划是为应届毕业生准备的为期两年的产品管理精英培训计划。助理产品经理会被分配到全公司各团队的重要产品管理岗位上，不仅有各种培训与交流的机会，一年后还可以轮岗。另外，谷歌还会为他们提供国际商务旅行，拜访遍布世界各地的谷歌人和客户。3.2.2 他们做什么
谷歌有很多产品，产品管理岗位在各团队中可能会有很大的变化。尽管在所有这些岗位中，产品设计思路和分析技能都是产品经理非常重要的必备技能，但对于不同的产品，如谷歌搜索、谷歌关键字广告（AdWords）、Gmail、Android、YouTube、Google Plus 和谷歌地图等，其侧重点也会有很大差异。
搜索团队非常依赖搜索技术，工程师会主动去开发新的算法。对面向广告商的团队来说，产品经理则负责收集客户需求，并向团队其他人传达那些需求。在像谷歌 Plus 这样的团队里，设计师是团队的灵魂，而面向开发人员的团队可能根本就没有设计师。
产品经理在谷歌是独立工作的。产品经理加入团队，然后由他和整个团队决定要构建什么。产品经理在谷歌的第一个项目通常都是探索未来的工作方向。
很多产品只有一个产品经理，那些不止一个产品经理的产品，工作一般也划分得很清晰，每个产品经理都有自己完整的领域。在日常工作中，谷歌产品经理会跟工程师团队以及设计师紧密合作。很多新想法都是产品经理、工程师和设计师在白板上写写画画时讨论出来的，然后就能快速搭建出原型。
谷歌极其看重产品经理的分析技能，因为数据分析是产品经理的一大块工作。产品经理会频繁地检查使用日志，以便为搜索和广告部门拿出新的项目想法。团队做出东西后，谷歌很容易就可以把它拿给一小部分用户试用。然后数据就会源源不断地进来，产品经理要分析这些数据，或者跟数据分析师合作，看看所做的修改能否称得上是一项改进。
谷歌的产品经理有一大块工作是让项目初具雏形，能够推出。因为哪怕是很小的改变，也会被千百万用户看到，所以一定要让所有东西恰到好处，包括 UI 和算法。项目必须满足安全、法务和架构要求。在得到最终核准之前，很多项目都要经过反复的研讨与改进。3.2.3 创新
为了鼓励创新，谷歌有个“20％时间”计划。根据这一政策，工程师和产品经理可以把他们 20％的时间用在跟公司相关的副业项目上。启动 20％项目不需要任何人的批准，只管开始做就行。你可以把你的项目提交到内部网站上，招募其他人加入你的项目。Gmail、谷歌新闻和 Orkut 之类的很多大型产品就是从某些人的 20％时间中诞生出来的。
所有这些创新和自由度都让谷歌成为了产品经理心目中的梦想。如果你有一个自己特别喜欢的项目，你不仅有时间和自由自己做，并且身边还有很多优秀的工程师，可以让他们在富余的时间里帮你把它做出来！3.3 微软
微软的产品经理岗位始于 20 世纪 80 年代，当时他们意识到在营销和工程师团队之间需要增设一个岗位，安排专人对照客户的需求实现产品的可用性。
微软的专案经理（Program Manager，相当于产品经理）一职在领域和影响力上都是非常独特的。他既要充当业务分析员、项目经理，还要提供创意。微软还是产品经理对开发人员比例最高的公司之一。综合所有这些因素，使得微软的产品经理成了一个实践性非常强的岗位。团队经常是由产品经理驱动的，而所有面向用户的决定都由专案经理来做。
作为一家比较老牌的科技公司，微软非常注重员工的职业发展规划。他们知道员工想要明确的职业进程以及完善的成长机制，因而建立起一种多元化的成长机制，让员工的发展方向不仅仅局限于成为团队领导，还有可能为更大的产品负责，为更多的产品策略负责。很多员工都希望能在微软走完自己职业生涯的全程。3.3.1 他们招什么样的人
微软想招有大局观，能解决问题，能把事情做成的人做专案经理。
微软的 Uche 说：“我们想要那种喜欢刨根问底，能从多个角度看问题的人。作为产品经理，你将会扮演很多角色，所以你的思考方式比任何特定的技术技能都重要。”
微软有两个跟专案管理有关的岗位一般都是由 MBA 担任：产品经理和产品规划师。微软的产品经理归属于营销团队，要发现市场机会，并为推动这些机会开发市场策略，且都是专注于当前的发布版本。产品规划师的目光则要放得远一点，要发现市场和技术趋势，拿出新的产品场景。3.3.2 他们做什么
微软的产品愿景和策略通常来自上层，然后自上而下贯彻执行。
比如说，主管微软 Office 的副总裁（VP）会跟专案经理小组一起工作，创建和分享愿景文档，其中包含下一版要关注的主要领域。每个 Office 产品的负责人都要定义自己负责的分类产品的愿景，跟 Office 的总体愿景保持一致。然后每个团队的负责人都在 Office 的总体愿景及分类产品愿景的基础之上，再开发各自团队负责的功能领域的相关愿景。
这样做的结果是微软的产品策略在一个产品部门内部非常有聚合性。所有团队都会觉得他们在朝着相同的目标一起努力，并且几乎不太可能有两个团队同时在做相互竞争的特性。随着职业生涯的发展，你负责的策略也会越来越大。
由于采用这种自顶而下的愿景，所以很难在产品推出周期中间发生方向上的巨变。即便想法很好，也很难找到有空闲时间的开发人员来构建它。换句话说，你在做的通常是每个人都认可的重要特性。这意味着你只能把精力用在构建优秀的产品上面，而没法去说服管理层推出你做好的伟大产品。
微软会让新产品经理负责一个特性领域，跟进团队的愿景，并且会给他很多的自由度和职责，以期让产品的那些部分变得更棒。一旦产品经理在职业生涯早期证明了自己在团队中的价值，就会承担起越来越大的责任。
微软的核心特性团队包括一名开发人员、一名专案经理和一名测试人员。最近有些团队又给核心特性团队加了一名设计师。核心特性团队在产品经理的领导下，共同决定构建的内容。在很多团队里，产品经理都先要编写只有一页的“规范”，其内容是对目标和用例高度抽象的描述。
在跟产品的其他专案经理一起探讨过这个只有一页的规范后，产品经理可能会把这个简要的规范扩展得更为详细，准确描述该特性的工作方式，从抽象的流程到具体的错误消息文本。产品经理可能会跟设计师合作，也可能会自己把交互设计都做了。这取决于团队的具体情况。
规范评审完成并开始实现后，自我体验（内部试用软件的早期版本）就变得非常重要。特别是交付周期比较长的团队，微软的产品经理会从公司的其他人那里收集反馈。反馈进来后，产品经理要给 bug 和新特性的想法排优先级。
在负责核心特性的工作之外，产品经理还会承担一些团队内或是团队间的职责，比如负责产品的项目管理日程，或是在产品推出前进行检查分类，以决定究竟应该修订哪些 bug 或实现哪些特性。
随着微软把自己调整成设备和服务公司，很多团队已经用更敏捷和迭代式的工作方式取代了严重依赖文档的工作方式。团队推出产品的速度更快，也更频繁了。A/B 测试正变得更加重要。3.4 苹果
苹果的组织结构是自顶向下的，各部门独立性较强。产品方向或者说愿景被牢牢地抓在高管团队和设计师手里，而公司的其他部分就像运转良好的机器那样只需执行这个愿景即可。在苹果，工程项目经理和工程专案经理（都被称为 EPM）是产品的领导，维持着整个机制。3.4.1 他们招什么样的人
苹果找的是那些跟苹果的产品形影不离的人。尽管很多公司为自己能够提供健康平衡的工作/生活方式而自豪，但苹果希望它的员工对产品充满激情，将其视作他们的生命。
对于 EPM 一职，他们找的人通常会有很强的科学及数学背景（那样他才能“理出头绪”），还要能有良好的风度（那样他才能有适度的自信）。此外，他们还希望此人的技术能力达到能够顺畅地参与讨论，但没必要从事任何具体的技术工作。
因为苹果有很多硬件项目，所以除了软件 EPM，他们还要招聘硬件 EPM 和系统 EPM。软件 EPM 通常会有计算机科学背景，而硬件 EPM 可能会有其他工程领域的背景，比如电子工程或机械工程。
在苹果，什么样经验水平的 EPM 都有，既有应届毕业生，也有具备 15 年行业经验的业内老兵。苹果的大多数 EPM 都来自工程或技术岗位，或是在其他公司担任过 EPM，很少有经管专业 的人或 MBA。
苹果还有产品营销经理（Product Marketing Manager）一职，有时候称作产品经理。对于产品营销经理，他们要找的是有商业或营销背景的人。这个岗位经常会聘请 MBA 毕业生。3.4.2 他们做什么
在苹果，创意最初的萌芽可能是自顶而下的，也可能是自底而上。在 EPM 的推动下，经过高管团队或高级管理层一系列的评审与研讨后，最初创意逐渐成形。产品经理要进行客户研究，查看市场趋势，以确定下一版的策略。产品一旦得到批准，EPM 带领工程师团队构建产品，创建开发日程，促成多个职能团队间的沟通，并带头解决问题。
在苹果做产品，需要协调很多团队，而 EPM 就是沟通的枢纽，要确保事情按日程运转，如果没有的话就要负责解决问题。比如说，在做硬件设备时，要协调机械设计团队、电子设计团队、外协厂商，以及运维团队。
苹果总部库比蒂诺的 EPM 一天要做很多沟通方面的工作：报告团队的进展，了解其他团队的状态，跟高管一起回顾并讨论当前的状态。通过这些讨论，EPM 负责找出潜在问题及其解决办法。
对于软件 EPM 而言，日常工作的一项重点内容是测试每日构建，寻找妨碍后续工作的问题，并确保它们能及时解决。
系统 EPM 的重点是交付整个产品。他们会制定规划，带领数十名苹果工程师到海外做原型构建。除了在外协厂商那里代表苹果工程团队之外，系统 EPM 还要与制造商一起进行故障分析，直到将故障消除，协调开发对硬件的不同需求，消除妨碍原型构建的故障。系统 EPM 是苹果内部项目的领导者，负责团结其他 EPM 和工程师来交付产品。
硬件 EPM 的工作重点是产品的硬件交付，包括电路板和布线方式。他们会跟电子工程团队、产品设计团队、芯片团队以及外部供应商紧密合作。他们日复一日参与着芯片计划和供应链管理的工作中，还经常就困难的跨职能设计决策方面的问题，使各方达成共识。3.5 Facebook
Facebook 是一家斗志昂扬，以技术为中心的公司。他们几乎没几个产品经理。很多团队一开始都没有产品经理，只有在后来明显需要时才引进一位。甚至在团队的产品经理不止一位时，团队的领域之大，也足以让每个人独当一面。3.5.1 他们招什么样的人
Facebook 有一群特立独行的产品经理。
Facebook 寻找技术高超又有创新精神的产品经理。在 Facebook，所有的产品经理都要求会编码（或者最起码学过基础知识），要通过 Facebook 新手营的考核，这是一个为期 6 周的培训计划，产品经理和工程师要在其间学习如何使用工具和解决 bug。这符合 Facebook 自己动手的企业文化，产品经理经常会自己动手写出最初的产品原型。
当 Facebook 为了招募员工而收购一家公司时，人们称其为收购式招聘。Facebook 的收购式招聘通常寻找的是小团队，一般不超过 10 个人，大部分都是技术人员。公司的创始人或 CEO 经常会被带过来做产品经理。
应届毕业生和没有产品管理经验的人会加入轮岗产品经理计划。这个计划为期一年，包含 3 次在不同团队的轮岗，每次为期 4 个月。3.5.2 他们做什么
Facebook 会有一些已经制定好的计划，但很多创意还是来源于对上网用户的观察——人们如何使用网站，以及他们会遇到什么样的问题。产品经理会注意到需要关注的领域，并把故事板和提案放到一起来阐述他们想做什么，包括预期结果。因为产品经理如此自由，所以你必须知道如何把自己的想法置于公司的整体框架中，并展示出它跟全局的匹配度。
然后团队会做出一个原型，先在一个小范围市场上测试，看能否达成预期结果。如果一切顺利，正式的项目开发就会进入议程。产品经理会同马克·扎克伯格（被大家称为“扎克”），或者部门负责人一起，评审提案以便得到批准。然后团队会引入设计师，在内部启用这个特性，开始从 Facebook 的其他同事那里收集反馈。
在开发过程中，产品经理会通过产品评审进行迭代。这里一般没有太多项目管理上的开销，但只要工程师一签入代码，观察日志的产品经理马上就能看到新代码。一切就绪后，产品经理会协调一个部署计划，会同营销部门一起推出产品。3.6 亚马逊
亚马逊的文化是由他们的 14 条领导力原则指引的（参见附录中的“亚马逊领导力准则”）。尽管很多公司都有自己的原则体系，但亚马逊领导力准则在招聘和日常工作中起到了非常重要的作用。人们会在会议中引用领导力原则来协助作出决策，会在面试中寻找具备这些品质的候选人。3.6.1 他们招什么样的人
亚马逊有很多业务，既有正在启动的新举措，正在进行的技术性业务专案，也有非技术性业务专案。他们有不同的团队，分别专注于消费者、出版商和开发人员等不同受众。基于以上情况，亚马逊有很多跟产品和专案管理相关的职位。
产品经理是产品的主人，他们专注于产品的愿景。亚马逊喜欢招 MBA 做产品经理，喜欢招刚从商学院毕业的人。亚马逊跟其他很多公司不同，他们不要求产品经理有技术背景。
技术专案经理（TPM）负责技术项目的日常执行，他通常需要有很强的技术背景，可以是直接从学校毕业的，也可以是从工程师职位上转岗来的。TPM 跟工程师的合作非常紧密。
专案经理则负责非技术性项目的项目管理，比如运营上的项目。专案经理可以是具有任何背景的人，但会 SQL 是加分项。亚马逊寻找的专案经理要聪明、敏捷，并且耐压能力强。专案经理负责管理和改善团队的工作流程。3.6.2 他们做什么
产品经理决定团队的愿景和路线。亚马逊极为看重“客户至尚”的理念，很多新创意都是在确定客户需求的过程中出现的：这其中既有直接跟客户交谈而得，也有通过对用 SQL 查出来的数据进行分析而得到的。亚马逊是由数据驱动的，所以需要产品经理有很强的分析技能。
产品经理想出一个创意后，他会把它和一个业务案例一起放在备忘录里，也被称为“故事”。这个文档中会包含支撑它的推荐及分析的详细信息，特别是关于影响和理由的数值。亚马逊用文档而不是演示文稿来介绍新提案，因为文档会迫使作者更精确，并且能显现出清晰的思路。
经过最初的几轮修改和批注后，提案会在会议中分享给上面的管理层。会议一开始，所有人都要安静地看完文档。这个过程可能一开始看起来会有点儿奇怪，但它可以确保每个人都有时间阅读提案的细节，并且能得到所有人的重视。大家都看完后，就可以开始进行提问。
提案可能还会再过几轮，关键是要能对从输入到预期结果进行准确的规划。提案通过之后，团队就可以开始构建它了。很多团队采用
试读结束[说明：试读内容隐藏了图片]