产品经理必读书：启示录，打造用户喜爱的产品

#阅读笔记

元数据

启示录：打造用户喜爱的产品

书名::[[启示录：打造用户喜爱的产品-CB_9Ub7pN7r00T06rO6sx8NI5u3]]
需求::启示录：打造用户喜爱的产品
作者::Marty Cagan
简介::
出版时间::
ISBN::
分类::
出版社::[[华中科技大学出版社]]

本书评论

书评

需求:: No.1 /#产品经理

高亮划线

第一部分 人员

• 需求:: 产品是由团队成员设计开发的。选择团队成员、界定工作责任是产品成败的决定因素。

第1章 关键角色及其职责

• 需求:: 产品经理的主要职责分为两项：评估产品机会(product opportunity)；定义要开发的产品。产品创意的来源很多，比如，公司高管的意见、用户的反馈、可用性测试的结果、产品团队和营销团队的点子、业内人士的分析等。应该有人严格审核这些创意，判断是否值得采纳。产品经理就是负责这项评估的人。许多公司借助市场需求文档(market requirements document，MRD)来完成这项工作。我更愿意使用一种简化的方法，我称之为机会评估(opportunity assessment)。
• 需求:: 在产品团队里，产品经理、设计师和开发人员的人数存在一定的比例关系。为使开发人员集中精力开发产品，必须有相应人数的产品经理和用户体验设计师协助他们。

第2章 产品管理与产品营销

• 需求:: 请记住，如果产品经理定义的产品没有价值、不具备可用性和可行性，那么无论开发团队多么出色也无济于事。

第3章 产品管理与项目管理

• 需求:: 产品管理的职责是探索(定义)有价值的、可用的、可行的产品；而项目管理则关注如何执行计划以按期交付产品。
• 需求:: 在一些大公司(如微软)，产品经理也负责项目管理的工作。我认为，强有力的项目管理能力是产品经理的优势。至少你可以使产品更快进入市场，甚至很可能会决定产品能否面市。但我还是认为产品经理和项目经理应该是两个独立的职位。

第4章 产品管理与产品设计

• 需求:: 好产品必须提供舒适的用户体验。舒适的用户体验是产品管理和用户体验设计共同作用的结果。
• 需求:: 只要团队中有一位称职的交互设计师，视觉设计也可以外包，毕竟视觉设计公司很多，完全可以满足需求。此外，用户研究和可用性测试也可以外包，只是成本较高，对我这种重视测试反馈(参考第22章)的人来说更是如此，所以我建议让产品经理和交互设计师分担这项工作。

第5章 产品管理与软件开发

• 需求:: 一旦产品进入开发阶段，要尽可能避免修改产品的需求和设计。虽然有些事情超出你的控制范围，导致项目波动是不可避免的(开发人员也能理解)，但是千万不要在此时尝试突发奇想的点子。
• 需求:: 产品开发阶段难免会产生诸多问题，比如，用例丢失，用例设计考虑不周全等，这很正常，最优秀的团队也避免不了。产品经理应该迅速采取行动，在维持产品基本功能、尽量避免修改的原则上，拿出解决方案。
• 需求:: 如果你与开发团队相隔很远，无论是讨论产品文档的内容，还是讨论修改产品设计，一定要借助高保真原型进行交流。
• 需求:: 外包不是为了节约成本，而是为了实现合理的人员配置。所以才要超越地理位置的局限，雇用另一个州／区，或者另一个国家的员工，实现最佳组合。
• 需求:: 与开发团队合作应该遵循以下原则：在产品管理上为开发团队预留20％的自主时间，让他们自由支配。开发团队可以利用这些时问重写代码，完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统一胜能，避免“需要停下来重写代码”的情形发生。

第6章 招聘产品经理

• 需求:: 招聘聪明人是项知易行难的任务，结果在很大程度上取决于招聘者的能力和可靠性。常言道，“物以类聚，人以群分”，此言不虚。方法之一是测试应聘者解决问题的能力。

• 需求:: 在漫长的项目周期里，产品经理需要付出的努力和承担的义务并非一成不变。有的阶段比较轻松，有的阶段则很紧张。但是称职的产品经理对产品的关注和忧虑程度，以及愿意为之付出努力的热情是不会改变的。

• 需求:: 信任和尊重需要时间培养，产品经理唯有通过工作展示自己的素质和能力，才能成为真正的团队领导。如果产品经理对待同事缺乏诚意，怀有私心，一碗水端不平，那么势必会影响整体团结和工作效率。产品经理虽然不必事事精通，但应当知道每位成员最擅长做什么，尊重大家发挥工作特长的意愿，充分信任大家。

• 需求:: 对那些有工作经验的应聘者，可以问问他们如何处理工作中的压力，多追问工作细节。

• 需求:: 自信是很重要的素质。公司高管、产品团队、销售团队都需要看到产品经理的信心，确信他们投入的时间、金钱、努力不会付之东流。自信的人更有说服力，更容易成为人们愿意追随的领导者。

  态度

  称职的产品经理把自己当成产品的CEO，愿意为产品的最终成败承担全部责任，绝不找借口。虽然他清楚产品按时成功上市要克服许多困难——开发难度大、开发时间长、成本过高、产品复杂等，但他明白预见和解决这些问题是他的责任。

• 需求:: 称职的产品经理把自己当成产品的CEO，愿意为产品的最终成败承担全部责任，绝不找借口。虽然他清楚产品按时成功上市要克服许多困难——开发难度大、开发时间长、成本过高、产品复杂等，但他明白预见和解决这些问题是他的责任。

• 需求:: 掌握一些重要的技能是打造成功产品的关键。我相信，只要具备优秀的个人素质，所有技能都可以习得。

• 需求:: 很多成功的产品经理是工程师出身，因为策划产品在很大程度上取决于对新技术的理解，以及如何应用技术解决相关的问题。

• 需求:: 几乎所有产品都有些不那么重要的功能——这些功能对提高销量和用户满意度毫无作用。如果去掉这些功能，产品甚至会因为简单、易用获得更多用户的喜爱。我建议过滤多余的功能，缩短研发时间，降低生产成本，让产品更早上市。

• 需求:: 熟练、迅速地区分重要任务和紧急任务，合理地规划和安排时间是产品经理必备的技能。如果产品经理无法集中精力完成真正重要的任务，那产品就难免命运多舛了。

• 需求:: 沟通技巧可以学习，但要做到出类拔萃需要经年累月的练习。沟通(包括口头表达和书面表达)能力是产品经理必备的技能，如前所述，产品经理只能以理服人，绝不能靠职位压制他人。

• 需求:: 成功的产品经理尽可能减少幻灯片的页数，他们的演讲充满热情、重点清晰、数据充分、引人入胜，绝不超时(甚至提前结束)。他们更喜欢听众提问，即使遇到暂时无法回答的问题，也会努力尝试向提问者和听众阐述自己的理解。杰里·韦斯曼(Jerry Weissman)的《演讲制胜：讲故事的艺术》是一本非常好的提高演讲水平的指南。

• 需求:: 产品经理应该具备双语技能。这并非指中文和英文，而是指产品经理既能与程序员讨论技术，又能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌。

• 需求:: 最有效的招聘途径是寻找具有上述特质潜力的人，通过培训课程和传帮带把他们训练成高素质的产品经理。这些人可能就藏身于公司内部。我认识许多优秀的产品经理，他们曾经是程序员、用户体验设计师、客服人员、技术支持人员、营销人员，甚至曾经是目标用户。他们利用各自的经验进一步完善产品管理工作。出于同样的原因，公司高管应该听取不同岗位员工对产品管理的建议。对于高管来说，这是宝贵的经验。

• 需求:: 我并非要贬低经验的价值，但我发现最宝贵的经验不是行业知识或技术(这些都可能过时)，而是打造优秀产品的流程、领导产品团队的能力、应对产品扩张的经验、个人对自己的认知，以及自我激励的能力。

• 需求:: 高科技产品行业虽然要求快速学习新技术，但曼重要的是预见如何应用技术合理地解决问题。技术发展很快，所以产品经理必须善于快速学习新技术，解决新问题。我面试应聘者时，不关心他们已掌握的知识，只看重他们的学习思路。比如，让他们回忆研发产品之前，他们需要学习哪些知识，需要多长时间学习，如何利用这些知识。

第7章 管理产品经理

• 需求:: 请注意，你必须确信产品经理有足够的能力，才能够授权给他们。授权给不称职的人，那是推卸你作为产品总监的责任；如果你事必恭亲，那是替他们承担责任。
• 需求:: 调查用户是否愿意向他人推荐你的产品，满分是10分。选择9～lO分的客户称为推荐者(他们会告诉朋友非常喜欢产品，相当于在为你做宣传推广)：选择7～8分的是中立分子；选择0～6分的称为贬损者，他们不但不推荐产品，反而会在朋友面前诋毁产品。计算出推荐者所占的比例，再减掉贬损者的比例，就得到了NPS，它反映用户对产品的态度。
• 需求:: 产品管理部门提升到与开发部门和市场部门相等的级别。理想的情况下，产品管理部门应该包含设计团队，因为产品管理和用户体验设计必须紧密合作。我相信今后会出现越来越多独立的产品管理部门(或产品管理与设计部门)，这些部门甚至会由产品总监或者是首席产品执行官亲自管理。

第8章 巴顿将军的忠告

• 需求:: 目标管理           永远不要告诉别人怎么做。告诉他们做什么，他们自然会发挥天赋，给你惊喜。——乔治史密斯巴顿

第9章 产品副经理

• 需求:: 做产品要找公司最聪明的人合作。我发现每个公司都有几个聪明绝顶的人，这些人是公司的潜在资源，关键看你能不能发现他们。如果有幸能找到他们，就应该不拘一格地任用。我把这些人看做产品副经理，甚至公开授予他们头衔，把他们招进产品团队。

第10章 管理上司

• 需求:: 为项目波动做好准备 我用项目波动代指让你心烦意乱的各种返工、计划变更。不要企图消灭项目波动，但是可以尽量降低其负面影响。方法是提高警惕，记录工作进度，比如，记录每周、每月、每季度有多少时间项目在往前推进，掌握项目波动的规律，寻找对策。制订项目计划时，预留出时间应对变化和调整，做好“做无用功”的心理准备。这个方法不仅能缓解压力，提高计划的准确度，还有助于挖掘有待改善的细节。
• 需求:: 缩短邮件篇幅 产品经理喜欢写长篇的邮件向上司汇报工作，这是大忌。上司每天可能会收到上百封邮件，他更希望用简明扼要的方式进行交流。收件人的级别越高，邮件的篇幅就该越短。你可以添加附件，但不要让正文篇幅过长。
• 需求:: 内部宣传 向公司同事宣传产品，让大家认可你的工作，乐于帮助你。充分、有效的宣传，可以大大降低与其他部门合作的成本。
• 需求:: 做让领导省心的员工 管理者的工作是保证团队高效运作，他们时间有限。不要劳烦你的上司做你的导师，但可以在你的直接管理层外另寻导师。思考如何节省上司的时间，你会获益匪浅。

第11章 评估产品机会

• 需求:: 评估产品机会是产品经理的重要职责。评估产品机会的目的在于：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源。
• 需求:: 为了评估产品机会，我要求产品经理回答如下十个问题。1.产品要解决什么问题?(产品价值)2.为谁解决这个问题?(目标市场)3.成功的机会有多大?(市场规模)4.怎样判断产品成功与否?(度量指标或收益指标)5.有哪些同类产品?(竞争格局)6.为什么我们最适合做这个产品?7.时机合适吗?(市场时机)8.如何把产品推向市场?(营销组合策略)9.成功的必要条件是什么?(解决方案要满足的条件)10.根据以上问题，给出评估结论。(继续或放弃)
• 需求:: 最难回答的往往是机会评估的第一个问题——产品价值。很多人感到惊诧，这应该是最容易回答的问题！问问产品经理产品要解决什么问题。你会发现多数人答非所问，只能泛泛地说出产品的功能和特色。

第12章 产品探索

• 需求:: 一旦完成产品定义，进入开发阶段，产品团队就要切换工作重心。现在的重心在于执行——开发、测试、发布。产品经理要确保大家集中精力，捕捉软件开发不可避免的问题并迅速予以解决。开发过程中可能会出现各种干扰，比如，竞争对手的干扰、公司组织变动，甚至公司问并购等，产品经理有责任确保产品团队不受干扰，专注完成项目，按时发布产品。
• 需求:: 产品经理必须在执行阶段转换工作重心；否则，产品经理自己很可能成为产品上市的最大障碍。每位产品经理的个性都不相同。如果你天生喜欢探索发明，喜欢自由和创意，那么在执行阶段就要努力控制创造的欲望；如果你天生是“项目经理”类型的人，喜欢排除外界干扰，按部就班完成任务，那么你需要培养自己的宏观思考能力和设计能力。
• 需求:: 我有个方法可以解决这种冲突：采用流水线方式并行开发产品。也就是说，一旦1.0版本的产品进入项目执行阶段，就开始定义2.0版本的产品。一旦前一个版本进入开发阶段，就把你的创造热情投入下一个版本。
• 需求:: 以我的经验来说，发现和验证市场机会并不难，但探索产品解决方案的难度很高。有些问题即便有出色的设计师和开发人员协助，也还是难以解决。
• 需求:: 处于创业阶段的公司和大公司都应该重视产品探索流程，在确定有价值的、可用的、可行的产品解决方案后，再全面转入执行阶段。
• 需求:: 你应该帮助管理层理解探索产品的本质，明白产品经理的职责是保证开发团队开发有价值的，可用的产品，这样你才能安心完成探索产品的任务。

第13章 产品原则

• 需求:: 为了鼓励创新，改善讨论效果，同时降低外界干扰，在作产品决策之前，应该先确定决策要解决什么问题，让大家在以下几个要点上迭成共识。1．究竟要解决什么问题?2．要为哪类人物角色解决这个问题?3．产品要达到什么目标?4．每项目标的优先级是什么?        在我看来，每当团队内出现严重的意见分歧时，并非是大家对事实的认定有争议，而是对目标和目标的优先级有不同的理解。

第18章 重新定义产品说明文档

• 需求:: “高保真”的含义是原型应该真实地体现用户体验。除了描绘用户界面的某些细微之处以外，我不建议使用“纸上原型”。如今使用工具创建高保真原型既简单又快捷，成本也不高，没理由不这么做。为了获得接近真实的用户体验，甚至应该模拟后台处理流程和某些数据。

第19章 用户体验设计与实现

• 需求:: 在软件开发过程中，有很多工作可以同时进行。比如，我一直认为需求调研和产品设计(用户体验设计)是互相影响的，应该同步展开。我不喜欢老式的瀑布式开发模型，产品经理先完成需求调研，然后交给交互设计师设计。业界已经认识到这是一种陈旧的产品开发思路。
• 需求:: 与软件开发团队合作的人要记住一点：一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高。因为开发团队必须根据确定的用户需求和产品定义设计软件架构，然后进行开发。前期架构决策极大地制约着后期的开发工作，事后修改软件架构，无异于推翻重来。另外，从心理上说，事后修改设计会打击开发人员的斗志，引发消极的心态。随着时间一分一秒过去，返工和波动会增加团队的压力。尽管敏捷方法提倡不断修改和完善，但并非所有的修改都受欢迎。
• 需求:: 我认为验证设计思路必须使用高保真原型。有人说，迭代结果和公开测试的产品可以当做原型。抛开要等很长时间不谈，这些开发中的产品与产品原型有很大的区别，不能混用。为了验证各种设计思路，产品原型应该可以随意修改，完成其任务后应该被丢弃。而开发中的产品应该以固定的原型为基础。

第21章 产品验证

• 需求:: 不再试图定义最终产品，转而定义只满足基本要求(价值、可用性、可行性)的产品，简称基本产品。一旦基本产品定义完成，通过了用户测试，它就是一个不可分割的整体，去掉任何元素，都不可能获，得预期的效果。
• 需求:: 根据产品原型估算的开发时间也不是完全准确，比如，对某些功能的开发时间的估计可能过于乐观。如果出现这种情况，只能延长工期，不能削减功能，因为你已经没有东西可削减了。尽管如此，由于估算的依据从一纸文档变成了精减功能的原型，精度还是大大提高了。即使延长工期，情况也远没有以前严重。
• 需求:: 可行性测试           首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。有些方案通向死胡同，但总有些是可行的。
• 需求:: 可用性测试           交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用。

第22章 原型测试

• 需求:: 如果你已经拥有一批特约用户(参见第15章)，可以邀请他们参加测试。如果你手头一位特约用户都没有，请马上开始物色。
• 需求:: 产品经理应该亲自参加每次原型测试，不能委托他人，尽可能多与用户接触，观察他们使用原型的反应。即使把测试外包给专业测试公司，产品经理也要亲临现场。没人比你了解产品，只有你能从测试者细微的犹豫、困惑、疑问中看出问题，知道测试者并未明自如何使用原型。第三方收集的测试结果难免会遗漏这些信息。

第23章 改进现有产品

• 需求:: 能提高指标的功能才是你关注的重点。你应该找准方向，分析关键指标，有针对性地改进产品。

第24章 平滑部署

• 需求:: 通过公告、群发邮件、在线教程等方式提前通知用户，但是很多人既没时间也没兴趣阅读这些内容，所以这个方法效果有限。
• 需求:: 平滑部署的方式很多，比如发布两个并行的版本，邀请有兴趣、有时间的用户试用新版本。如果新版本运行正常，大部分用户习惯新版本后，再将新版本设为默认版本。同时将旧版本保留一段时间，公示为旧版本提供支持的最后期限，以便没来得及习惯新版本的用户在这段时间内能照常使用产品。对于用户数量庞大的服务和产品，这个过渡可能需要几个月的时间。产品经理还要准备好承担来自开发团队和运维团队的压力，毕竟支持并行版本不是件容易的事。

第25章 快速响应阶段

• 需求:: 一旦问题反馈回来，产品团队(产品经理、交互设计师、主程序员、客户服务人员、市场营销人员等)应该至少每天召开。次简短会议，讨论问题的轻重缓急，确定最佳解决方案，比如，通过网站发布补丁，或是发表声明公示处理办法……如果团队事先做好心理准备，认识到快速响应阶段的重要性，大幅提高产品或服务的质量便指日可待了。

第26章 合理运用敏捷方法

• 需求:: 产品经理即是产品负责人(product owner)，他代表，客户的需求，因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题。有些产品经理以为敏捷方法可以让工作变得轻松，这是大错特错的。如果产品经理和产品负责人不是由一个人担任，通常会埋下隐患
• 需求:: 使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法替代冗长的市场需求
• 需求:: 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保你们有足够的时间攻克难题。让交互设计师和视觉设计师提前设计产品，充分发挥他们主导设计的作用，不能一边设计一边开发(参见第19章)。另外，始终让开发人员参与评估产品设计和产品原型，及时反馈关于可行性、成本、解决方案的建议。
• 需求:: 除非达到了产品经理的要求，否则不要轻易发布新版本。产品经理必须确保交给用户的产品能正常运行。过度频繁更新版本会让用户感到不安
• 需求:: 产品软件必须在各方面都尽量做到完美，才能赢得市场。所以必须由产品经理负责收集广大用户的需求：由用户体验设计师创造完美的用户体验；由测试人员测试产品，保证软件可以像广告里说的那样正常运行。

第29章 大公司如何创新

• 需求:: 随着规模变大，公司会不可避免地变得更加保守，不敢冒险。因为一旦失败，比起小公司来，大公司的损失会惨重得多，所以只要情况允许，他们会尽可能维持现状。但大公司也需要创新以谋求发展，何况大公司还有自己的优势。
• 需求:: 另一种创新途径是跳出技术局限．完善用户体验。改善用户体验不仅要提高产品的工作效率，更要剔除多余的功能，明白哪些功能是用户必需的，哪些是设计和开发带来的衍生物。

读书笔记

第4章 产品管理与产品设计

• 需求:: 好产品必须提供舒适的用户体验。舒适的用户体验是产品管理和用户体验设计共同作用的结果。 [[用户体验]]