书籍-启示录：打造用户喜爱的产品 我的笔记

#阅读笔记

元数据

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

书名::[[启示录：打造用户喜爱的产品-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章 大公司如何创新

• 需求:: 随着规模变大，公司会不可避免地变得更加保守，不敢冒险。因为一旦失败，比起小公司来，大公司的损失会惨重得多，所以只要情况允许，他们会尽可能维持现状。但大公司也需要创新以谋求发展，何况大公司还有自己的优势。
• 需求:: 另一种创新途径是跳出技术局限．完善用户体验。改善用户体验不仅要提高产品的工作效率，更要剔除多余的功能，明白哪些功能是用户必需的，哪些是设计和开发带来的衍生物。
• 需求:: 创业型公司在选择收购自己的东家时，并不是只看重收购价格，他们往往会选择有过合作关系的公司。
• 需求:: 建议大家尝试以上的方法．帮助公司保持创新。德鲁克曾说过：“公司的核心竞争力在于创新。”我相信大公司一样可以创新，苹果公司是最好的例子。

第30章 在大公司施展拳脚

• 需求:: 多数大公司都采取矩阵式的管理方式，核心部门(比如设计部门、开发部门、测试部门、运维部门、市场部门)是共享资源，产品经理要确保争取到足够的资源才能研发出产品。采用这种组织结构不是因为它的效率高，而是为了节约公司运营的成本。
• 需求:: 每家公司的企业文化都不相同，制定决策的方式也千差万别。如果公司制定决策的方式不符合你的习惯，不要老想着改变大家来适应自己，要学着融入其中。
• 需求:: 建立人脉网络   在大公司工作必须与人合作，如果你喜欢单枪匹马工作，创业型公司更适合你。你需要同事的协助才能完成设计、开发、发布工作。主动与各个部门的同事结交朋友，聊聊工作的事，向大家介绍你手头的项目，不要等到有事才去找人家。主动帮助他人，秘累人脉关系。
• 需求:: 想靠几张画着产品构想的幻灯片说服老板是不切实际的。更可行的方法是找三五个志趣相投的同事在工作之余做出产品原型来。产品原型具有超出想象的说服效果。比起枯燥的陈述，生动形象的演示更有吸引力。数不清的优秀产品是这样诞生的。
• 需求:: 自己顶上   说出来你也许不信，大公司里虽然员工众多，但真正需要帮手的时候，却总找不到人。即使是公司高管重视的项目，也难免资源不齐。遇到这种情况，你就得自己想办法了，比如，打电话找人帮忙，甚至自己顶上。在凡事都需要提交材料，有严格流程要求的大公司，与其对抗流程，不如自己主动填写、提交需要的材料。程多时候产品经理还要协助编写技术文档，组织销售培训，提供客户服务。一切为了推出产品，不要计较个人得失。
• 需求:: 有选择地据理力争   在大公司工作，多一个敌人不如多一个朋友。如果你不满意同事的工作．或者与他人意见不同，不要随便发脾气，除非这件事对你确实重要，值得你据理力争，撕破脸也在所不惜。与人辩论，要小心措辞，做到对事不对人，不要把对方逼到死角。你的目标是完成产品，别为了一场战役输掉整场战争。
• 需求:: 会前沟通，形成默契   在重要的决策会议上，如果有人公开反对你的提议，你会变得非常被动。在这种公开场合下发表的意见，反对者很难改口，你想再挽回就很难了。与其临渴掘井，不如未雨绸缪，设法在会前达成一致意见。会议的主要作用是让与会者认识到大家取得了一致意见。所以会前应该逐一找与会者聊聊，了解每个人的立场，如果有不同的意见，对症下药及时化解，确保他们会投赞成票
• 需求:: 合理分配时间   大公司频繁开会，有些人每天忙于参加大大小小的会议，深夜回家还要回复邮件，忙得不可开交，产品却毫无起色。产品经理应该重新检查会议日程，划掉无关紧要的会议；学会充分信任同事，让他们自己拿主意。产品经理应该留下时间完成自己的本职工作：制定产品战略，构思产品路线图，研究产品原型，分析竞争对手。
• 需求:: 分享信息   不管在哪种组织里，沟通都是难题，大公司尤其如此——信息俨然变成了某种货币，大家只想获取，不愿支出。许多人把它看成私有财产，藏起来不愿与人分享。其实有舍才有得，分享信息会让你获得更多的朋友和资源，作为交换，别人也会毫无保留地分享信息给你。充分共享信息对你自己和公司都有好处，这叫共赢。
• 需求:: 向上司借力   学会利用上司的关系，可以更好地开展工作。如果你的上司在公司里威望很高，你应该学会向他借力，利用他的人脉关系，传播你的理念，多向他请教，了解公司文化和组织结构。如果需要上司出面说服公司高管，你一定要事前做好充分的准备，为他提供翔实可靠的资料和信息，用实力取得他的信任，让他放心地当你的说客。
• 需求:: 传播你的产品理念   多向同事传播你的产品理念，向大家描绘产品愿景，介绍产品策略，演示产品原型，分享用户反馈信息。不要低估了内部宣传潜移然化的作用。让大家(包括没有直接业务联系的部门同事)不遗余力地支持你。

第34章 恐惧、贪婪、欲望

• 需求:: 消费者购买产品大多源于情感需求。优秀的产品经理和销售人员明白其中的道理，懂得产品应该满足用户的情感需求。

第36章 可用性与美感

• 需求:: 视觉设计公司的网站美轮美奂，用起来却让人抓狂；交互设计公司的网站操作方便，导航设计条理清晰，但视觉设计却枯燥乏味，毫无吸引力。这说明交互设计和视觉设计完全是两回事。设计既美观又实用的网站，交互设计师和视觉设计师缺一不可。但大部分团队却固执地认为只要招聘一位设计师，就能完成这两项工作。更有甚者根本不招聘任何设计师，设计网站的工作全由产品经理和界面开发人员操刀。在开发企业级应用的公司里，这一现象尤为突出。反而是后起的创业型公司通常会聘请一位设计师。
• 需求:: 良好的用户体验是交互设计师和视觉设计师合作的结果。他们共同配合产品经理定义产品。

第37章 大众网络服务产品

• 需求:: 可用性   在我看来，多数公司不够重视产品的可用性，尤其是开发企业级软件的公司。大众网络服务产品必须具备良好的用户体验。如果用户不清楚怎样使用产品，也不知道产品的优势何在，你就等着关门歇业吧。另外，别忘了产品性能是最重要的。条可用性指标，页面加载缓慢让用户无法忍受，也是糟糕的用户体验。
• 需求:: 人物角色   网站用户数量过百万后，产品经理不可能再逐个研究每位用户，只能按典型特征将用户分类，抽象出有代表性的用户类型(人物角色)，加以分析。产品每增加一项新功能，都要请典型用户参与测试，根据反馈信息加以完善
• 需求:: 扩展性   激增的用户数量会带来莫明其妙的问题：数据库崩溃、系统出现性能瓶颈、用户界面罢工。网站上线前进行压力测试虽然可以发现部分问题，但正式使用时总有意想不到的情况出现。实现扩展性需要产品经理、设计人员、开发人员、运维人员的通力协作，最好利用部分开发资源和运维资源(我建议分配20％的资源)专门为系统扩展做好准备。不要到系统承受不了压力．即将崩溃才追悔莫及。从设计系统的第一天开始，就应该不问断地考虑扩展性问题，永远留有余地，不到万不得已不要满负载运行
• 需求:: 持续可用性   大众网络服务要求一刻也不能停歇，但迄今为止我还没见过哪家网站能做到24×7小时无故障运行。系统中止服务是件痛苦的事，对那些负责解决系统故障的人来说更是如此，不是所有人都适合干这一行。系统出故障的时间没个准，工作日、节假日、周末、深夜，随时可能发生，从业者的压力相当大。在系统设计上保证持续可用性与规划扩展性一样重要。
• 需求:: 客户服务   另一件让大众网络服务公司头痛的事是客户服务。传统的客户服务完全无法应付数量庞大的网络用户，收费的网络服务情况更严重。要想降低客服压力，除了尽量减少系统故障和缺陷外别无他法。在这个问题上，节省开支只是一方面，更重要的是维持良好的用户体验。
• 需求:: 口碑营销用户   如果喜欢产品，就会主动向家人、朋友、同事推荐。这是宣传产品的最佳方式。令我费解的是，很少有公司充分利用这种营销手段。我建议为用户提供便利，方便他们(通过邮件、短信、社交网络等)向熟人推荐产品。许多公司愿意为吸引新用户支付报酬，不妨向踊跃推荐产品的用户发放奖金。当然奖金激励还是次要的，最重要的是让用户易于向家人、朋友、同事、网友推荐产品。
• 需求:: 平滑部署   网站用户数量过百万后，任何小小的变化都会影响大面积的用户，要三思而行。我详细讲述过平滑部署的要点(参见第24章)．请大家务必谨慎小心。部署前要仔细测试，逐步过渡，步幅不可过大，为用户留出足够的时间来适应变化。有些公司让新老版本同时运行一段时间，让用户适应过渡，这是个好办法。最后，尽量减少不必要的更新，用户消化、吸收新事物不是件容易的事。

第38章 打造企业级产品的经验

• 需求:: 软件能帮助企业解决业务问题，通常是特定(垂直)的行业问题。
• 需求:: 产品可能由一个或多个组件整合而成，这些组件可能是你的公司开发的，也可能是合作方开发的，但它们是预先集成好的。
• 需求:: 必要时，产品应该获得合作方的产品认证。

第40章 最佳实践经验

• 需求:: 产品管理的职责   许多产品经理将大把的时间浪费在与产品管理无关的工作上，比如，营销管理和项目管理，这些都不是产品经理应该干的活。
• 需求:: 用户体验   对于大多数软件产品来说，用户体验就是产品的生命。产品经理应该与交互设计师、开发人员密切合作，设计良好的用户体验，打造有实用价值的产品。
• 需求:: 机会评估   用方便快捷的机会评估方法取代过时的市场需求文档。动手设计产品前，先明确产品要解决什么问题，为谁解决问题，以及评估产品的标准。
• 需求:: 产品原则   产品管理工作的主要内容是制定决策。明确的产品原则可以帮助产品经理和产品团队树立清晰的价值标准，做出果断的决策。
• 需求:: 探索(定义)产品   产品经理的主要职责是探索(定义)有价值的、可用的、可行的产品。除非产品经理确定这三点，否则同事的努力都将付之东流。
• 需求:: 使用原型   使用高保真原型是探索(定义)产品的关键步骤。原因如下：第，迫使产品经理深入定义解决方案：第二，可以让真实的用户参与测试、验证产品创意：第三，可以直观地向团队展示产品的设计思路。

读书笔记

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

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