【学习笔记】启示录 - 打造用户喜爱的产品（阅读摘录）

图书信息
Marty Cagan 著
七印部落 译

人员： 负责定义和开发产品的团队成员的角色和职责
流程： 探索、开发富有创意的产品时，反复应用的步骤和成功的实践经验
产品： 富有创意的产品，包括设计、软件开发、视觉设计、设计工具等

好产品靠设计

1. 产品经理的任务是探索产品的价值、可用性、可行性；
2. 探索（定义）产品需要产品经理、UI、软件架构师通力合作；
3. 开发人员不擅长用户体验设计，因为开发人员脑子里想的是实现模型，而用户看重的是产品的概念模型；
4. 用户体验设计就是交互设计、视觉设计（工业设计）等；
5. 功能（产品需求）和用户体验设计密不可分；
6. 产品创意必须尽早地、反复地接受目标用户的试用，以便获取有效的用户体验；
7. 为了验证产品的价值和可用性，必须尽早地、反复地请目标用户测试产品创意；
8. 采用高保真的产品原型是全体是全体团队成员了解用户需求和用户体验最有效的途径；
9. 产品经理的目标是在最短的时间内把握复杂的市场/用户需求，确定产品的基本要求——价值、可用性和可行性；
10. 一旦认定产品符合以上基本要求，它就是一个完整的概念，去掉任何因素，都不可能达到预期的效果；

第1章 关键角色和职责

产品经理

两个职责：

评估产品机会 - MRD ( Market Requirements Document )
审核各个途径来源的产品创意，判断是否采纳；

定义要开发的产品 - PRD ( Product Requirements Document )
基本的产品特征和功能，产品的用户体验，产品的发布标准。

用户体验设计师

深入理解目标用户，设计有价值的、可用的功能以及用户导航和产品使用流程。与产品经理配合，将功能与设计相结合；

项目管理人员

制定计划和跟踪进度；可由产品经理担任，也可以单独设置；

开发团队

负责产品开发

运维团队

负责互联网产品服务正常运行

产品营销人员

发布信息，宣传产品，拓展市场渠道，组织营销活动

每 5~10名开发配备一名产品经理

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

两者不是一回事

产品经理的工作是从细节上定义开发团队开发什么产品。市场营销的职责是对外宣传产品；

公司开发产品存在三种比较不好的情况：

市场营销人员定义产品

在市场营销上提供资源，制作数据表格，培训销售队伍，为产品命名和定价，但是涉及到产品定义的具体工作，往往无能为力。

两者同时定义产品

营销负责收集高层需求，产品负责收集低层需求；但是没有人对最终的产品负责；这个模式很难创造创新的产品；

一人兼任两项工作

团队模式的扩展性差，一个人很难把两件事做好；

解决方法：
清晰界定营销人员和产品经理的工作职责

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

产品管理：探索（定义）有价值的，可用的，可行的产品；
项目管理：执行计划和按期交付；

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

好产品必须提供舒适的用户体验，舒适的用户体验是产品管理和用户体验设计共同的结果；

用户研究、交互设计、视觉设计、原型制作。

交互设计不能外包

1. 深入理解用户需求非常费时间，需要多个项目的经验积累，设计公司可没有时间；
2. 交互设计师必须现场深度参与项目开发，从立项到产品发布。
3. 产品的用户体验是公司的核心竞争力，必须在内部完成。

只要交互设计师称职，视觉设计可以外包；

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

定义正确的产品与正确的开发产品

产品经理需要定义产品方案，开发团队最了解哪些产品构思是可行的，他们负责产品的开发与实现。任何一方不从属于另一方。他们相互依赖。

开发人员协助产品经理

1. 开发人员参与产品原型测试；
2. 头脑风暴，讨论新技术使用；
3. 在产品的初级探索阶段，开发人员协助产品策划；

产品经理配合开发人员

1. 产品经理定义满足基本要求的产品
2. 开发阶段，尽量避免修改需求，千万不要提出新的突发奇想的点子
3. 开发阶段会遇到很多问题，产品经理应迅速采取行动，维持基本功能、尽量避免修改的原则上，拿出解决方案；

第6章 招聘产品经理

产品经理特质

素质和态度: 技术可以学习，素质却难以培养
对产品的热情: 辨别这种特质比较容易，可以让应聘者谈谈自己最喜欢的产品及原因，聊聊不同领域的产品额他讨厌的产品，如何改进？
用户立场: 可以让应聘者谈谈目标市场的感觉，要换位思考。
智力: 必须具有敏锐的头脑，面试官不关心答案是否正确，而是解决问题的思路。
职业操守: 绝不适合贪图安逸的人担任，产品经理要为产品投入大量的时间和精力；
正直: 体现公司的价值观，通过行动影响和说服身边的同事，多追问细节；
信心: 自信的人更有说服力，更容易成为人们愿意追随的领导者；
态度: 称职的产品经理把自己当做产品的CEO，愿意为产品的最终成败承担全部责任，绝不找借口。
技能: 掌握一些重要的技能是打造产品成功的关键；
运用技术的能力: 出色的产品经理并不需要自己发明或实现新技术，但必须有能力理解技术，发掘技术的应用潜力；
注意力: 产品经理要优先解决重要问题。如果去掉某些功能，产品甚至会更简单，更容易获得用户的喜爱，可以缩短研发时间，降低生产成本，让产品更早上市；
时间管理: 熟练、迅速区分重要人物和紧急任务，合理规划和安排时间是产品经理必备的技能。如果产品经理无法集中精力完成真正重要的任务，那产品就难免命运多舛；
沟通技能: 沟通能力是产品经理必备的技能，如前所述，产品经理智能以理服人，绝不能职位压人；
商业技能: 产品经理既能与程序员讨论技术，又能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌。

去哪招聘呢？

最有效的招聘途径是寻找具有上述特质潜力的人，这些人可能就在公司内部。出于同样的原因，公司高管应该听取不同岗位员工对产品管理的建议，对于高管来说，这是宝贵的经验。

第7章 管理产品经理

建设公司从建设团队开始

管理产品经理的人通常被冠以产品总监或产品副总裁的头衔。产品总监的关键职责有两方面，第一，组建优秀的产品经理团队，第二，规划公司的全局产品战略，对产品组合负责。

建设产品管理团队

如果发现手下的产品经理总是无法胜任工作，就要立刻采取行动。新产品经理必须经过三个月刻苦学习才能开始管理产品，这段时间，他要融入目标用户和客户群，学习相关的技术，了解市场和竞争局势，管理者应该为新人创造学习条件，监督学习进度。
一旦找到有潜力、称职的人选，就应该放手让他们工作，尽情发挥其潜力，如果事无巨细都过问，他们就不可能步入正轨成为产品的主人。注意，必须确信产品经理有足够的能力，才能授权给他们，授权给不称职的人，那是推卸产品总监的责任，如果事必躬亲，那是替他们承担责任。

规划公司的产品战略

产品总监负责管理公司的系列产品，决定公司经营什么产品，仔细评审每款产品的战略和研发流程。

产品总监要负责制定产品组合路线图——兼顾用户需求和商业目标，从全局出发制定产品发布计划。

考察也即的新指标，用户净推荐值：调查用户是否愿意向他人推荐你的产品，满分是10分，选择9_{10称为推荐者，选择7}8分为中立，选择0~6分为贬损者，计算出推荐者比例，再剪掉贬损者的比例，就得到了 NPS。

产品管理放到市场部门或者开发部门都不合适，应该提到与他们同等级别。

第8章 巴顿将军的忠告

目标管理

永远不要告诉别人怎么做，告诉他们要做什么，他们自然会发挥天赋，给你惊喜。——乔治.史密斯.巴顿

如果产品经理试着思考产品要做什么，就会惊讶发现实现方法如此之多。客户其实不必考虑解决问题的途径。

很多公司里，用户体验设计师是稀有资源，通常在产品需求说明文档完成之后才参与产品设计，这限制了设计师的作用。用户体验设计师应该在产品经理分析目标市场、思考解决方案的初期阶段就发挥作用。

留给用户体验设计师和开发人员的空间越大，他们就越有可能打造出用户喜爱的产品。

第9章 产品副经理

产品就是创意，产品经理的职责是相处好点子并加以实现。许多产品经理不愿意接受这些建议，主要是因为过于自负。他们认为自己才是提出创意的人。记住，公司的目标是打造卓越的产品，所有可以借用的力量都是可取的。

第10章 管理上司

困难无处不在，不可能完全消除，唯一能做的事缓解其影响。

1. 为项目波动做好准备：预留出时间应对变化和调整。
2. 注意沟通的方式与频率：千人千面
3. 会前沟通：组织好会议的诀窍是在正式会议召开前充分沟通，提出自己的观点，征询他们的意见，确保会议召开前你们已经达成一致意见，可以大大缩短正式会议的时间。
4. 多提建议，少谈问题：管理者希望听到解决问题的方法，而不是听你抱怨。
5. 向上司借力
6. 充分准备：
7. 缩短邮件篇幅：
8. 多用数据和事实说话
9. 内部宣传：向公司同事宣传产品，让大家认可你的工作，乐于帮助你。
10. 做让领导省心的员工

第二部分 流程

第11章 评估产品机会

确定待解决的问题

产品经理必须用他灵敏的“嗅觉”，从纷至沓来的机遇中迅速评估、挑选出有市场潜力、可行的创意，过滤那些没有价值或时机不成熟的电子。

为了评估产品机会，产品经理需要回答10个问题：

1. 产品要解决什么问题？（产品价值）
2. 为谁解决这个问题？（目标市场）
3. 成功的机会有多大？（市场规模）
4. 怎样判断产品成功与否？（度量指标或收益指标）
5. 有哪些同类产品？（竞争格局）
6. 为什么我们最适合做这个产品？（竞争优势）
7. 时机合适吗？（市场时机）
8. 如何把产品推向市场？（营销组合策略）
9. 成功的必要条件是什么？（解决方案要满足的条件）
10. 根据以上问题，给出评估结论。（继续或放弃）

产品经理往往把待解决的问题和解决方案放在一起考虑，当具体解决方案遇到困难时，他们会放弃产品机会。

第12章 产品探索

定义正确的产品

在探索产品的阶段，产品经理负责分析各种创意，广泛收集用户需求，了解如何运用新技术，拿出产品原型并加以测试，从全局视角思考产品方向，兼顾短期需求和长期规划。总而言之，就是探索出兼具功能性和设计性的产品。

采用流水线方式并行开发产品，一旦1.0 版本的产品进行项目执行阶段，就开始定义2.0版本的产品。

第13章 产品原则

确定什么最重要

制定产品原则意味着决定什么重要、什么不重要，哪些原则是根本的、战略的，哪些是临时的、战术性的。

产品原则不是产品功能清单，不依赖于任何单独的产品，它是整个产品线的战略指南，是公司的价值宣言。好的产品原则甚至可以激发设计产品的灵感。产品原则是一套价值判断的框架，帮助公司作出正确地决策。

制定产品原则时容易犯两类错误：

1. 原则过于空泛，失去指导作用。
2. 错把设计原则当做产品原则。

每当团队出现了严重的意见分歧时，并非是大家对事实的认定有争议，而是对目标和目标的优先级有不同的理解。

第14章 产品评审团

指定更及时、更可靠的产品决策

组织产品评审团的难点在于既要为高管制定产品决策、监督产品流程提供透明的信息，又要避免高管查收干预产品团队的具体工作，比如亲自参与设计产品。

成立产品评审团的目的是决定产品战略方向，从宏观上监督公司产品的研发流程，合理地配置资源。产品评审团不指定公司的商业战略，而是在给定商业战略的条件下，提出与之相匹配的产品战略。

成员包括：

• 首席执行官/首席运营官/部门总经理
• 产品总监/副总监
• 用户体验总监/副总监
• 市场总监/副总监
• 开放总监/副总监
• 网站运营总监/副总监
• 客户服务总监/副总监

职责

1. 评审产品战略和产品路线图，启动评估产品机会的工作，即选择值得投入精力的产品。
2. 根据评审产品机会的结果，决定是否开始定义产品的解决方案。
3. 评审产品圆形、用户测试结果、成本估算明显，决定是否开始开发产品。
4. 评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品。

如果公司制定产品决策的效率太低，应该考虑组织产品评审团。产品评审团可以替代以往各种冗长的决策会议，大大缩短决策时间，制定明智、及时、透明的产品决策。

第15章 特约用户

产品开发伙伴

大部分市场人员认为拥有一群忠实的、乐于推荐产品的用户会让产品发布变得更容易、效果更好。

征集特约用户

1. 参与构思产品创意，解决他们手头的问题——他们最清楚产品要解决的问题，因为这些麻烦正值困扰他们。
2. 提前试用产品，越早使用产品意味着越早解决麻烦。
3. 通常，提前试用产品还可以显著降低用户的各种成本。

产品经理的收获

1. 聚拢一批积极的用户，他们可以为定义产品和开发产品提供建议和协助。
2. 提供调研便利，便于产品经理去特约用户的工作场所调研。如果是平台产品的话，便于产品经理去开发人员的工作地点调研。
3. 可以定期组织特约用户进行小组讨论。
4. 特约用户第一时间试用、测试产品，迅速反馈一键。
5. 如果特约用户满意产品的表现，会乐意公开推荐产品。

组织特约用户要注意

1. 不收费。
2. 数量不要超过10个。
3. 如果寻找特约用户困难，可能是产品解决的问题没有那么重要，应重新考虑产品计划。
4. 应区分产品尝鲜者和特约用户。
5. 产品是通用的，而非定制的。
6. 当做合作伙伴。
7. 全流程让他们参与。
8. 确保每个特约用户试用并满意；
9. 产品经理和营销团队紧密合作；
10. 鼓励应用开发者发展自己的特约用户；

产品经理应尽可能地亲自拜访用户，与用户交流，参加每一次的可用性测试和特约用户讨论会。

第16章 市场调研

理解市场调研的作用与局限性

市场调研的工具和方法

1. 用户调查：设计调查问卷需要技巧和经验，调查结果为获得解决方案提供了一条途径，但不是解决方案本身。
2. 产品使用分析：越早使用分析工具越好，不断地观察学习，然后调整产品。
3. 数据挖掘：
4. 拜访用户：
5. 人物角色：深入了解，弄清哪些是当前用户，哪些是潜在的用户。
6. 可用性测试：尽早、反复地进行可用性测试，观察用户使用现有产品的反应，收集反馈一键，了解他们的真实想法。
7. 同类产品分析：每款产品都有做的好的地方，有必要找出竞争对手的优势，学习对手的成功经验。

成功的产品基于以下两点认识：深入理解用户需求，以及明白什么样的解决方案在现阶段是可行的。

第17章 产品任务角色

理解目标用户

产品管理的核心在于制定决策——应该抓住哪些机会，解决说明问题，哪些功能最有价值，谁是主要用户。

任务角色的主要用途

1. 面面俱到的产品往往一无是处
2. 避免将自己的需求当成用户需求
3. 有助于对用户类型优先级进行排序，识别需要重点考虑用户体验的地方
4. 方便向团队描述产品的目标用户是谁
5. 帮助团队达成共识，解决问题的效率会更高

注意事项

1. 定了就要用，老少皆宜就是自欺欺人，重点关注某一类关键角色
2. 与目标用户面对面交流
3. 邀请用户参加产品原型测试

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

理想的产品说明文档

1. 完整描述用户体验——不只是用户需求，还包括交互设计和视觉设计。
2. 必须准确描述软件的行为；
3. 必须某种直观的方式将产品的信息和产品行为告诉所有人
4. 支持修改
5. 版本要清晰

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

在软件开发过程中，很多工作可以同时进行。老式的瀑布式开发模型已经过时了。

敏捷方法里有个概念叫“第0次迭代”，产品经理和用户体验设计师利用这段时间先完成产品设计工作，然后交由开发人员开始迭代开发。这需要更详细地定义待开发任务。

第20章 基本产品

削减功能还是延长工期

不再试图定义最终产品，转而定义只满足基本要求（价值、可用性、可行性）的产品，简称基本产品。

产品设计方式：

1. 设计高保真原型
2. 邀请架构师参与设计原型
3. 请真实用户验证产品原型

设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。

第21章 产品验证

可行性测试

邀请架构师深度参与技术调研，寻找可行的方案。如果产品存在可行性风险，一定要提前解决这些问题。

可用性测试

交互设计师应于产品经理密切合作，想发设法突出产品的功能特性，让不同类型的用户都能明白如何使用。

可用性测试往往能发现没能成功实现的产品需求，如果测试的好，甚至发现被忽略的需求。一定要请真实的用户试用可用性圆形，从目标用户那里可以得到宝贵的反馈信息。

价值测试

价值测试可以和可用性测试同时进行，使用的原型也是一样的。可用性测试重在观察用户如何设法完成必要的操作，而价值测试重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式。

第22章 原型测试

让真实用户验证产品创意是必不可少的环节，也是产品经理最重要的工作；

物色测试者

1. 特约用户
2. 同类产品的展销会
3. 分类信息网站，征集测试者
4. 大众产品，可以邀请亲朋好友测试，避开亲密的人和科技者，除非他们是目标用户，不要局限
5. 营销团队提供
   …

准备测试

1. 定好测试内容，着重测试主要项目
2. 只有一次机会了解测试者未接触产品原型之前如何解决产品要解决的问题。
3. 观察测试者能否从原型首页看出产品要解决什么问题。
4. 与测试者沟通进一步收集信息
5. 为每个问题的答案打分
6. 不必等到完整原型再测试，可以先测主要项目
7. 产品经理应亲自参加每次原型测试

更多内容请看原书。

第23章 改进现有产品

不是一味地添加功能。开发新产品的第一部是要明确目标，先考虑可以从哪些方面改善用户体验。

改进产品不是简单地满足个别用户的要求，也不能对用户调查的结果照单全收。能提高指标的功能才是关注的重点。应该找准方向，分析关键指标，有针对性地改进产品。

第24章 平滑部署

毫无征兆地更新不必要的版本会令用户产生反感。

通常情况下，用户不喜欢变换。虽然他们也希望产品更完善，功能更丰富，单前提是不改变已有的使用习惯，大多数人不愿意花时间学习、适应新的使用方式。

降低版本更新的风险

1. 公告，邮件，在线教程通知用户，这个效果有限；
2. 加倍做好测试工作，避免新版本存在影响正常使用的隐患。
3. 采取并行部署或者增量部署的方式来降低风险。

另一种平滑部署的方式是区域性逐步部署，首先在某个区域内部署新版本，然后逐步扩大范围。

第25章 快速响应阶段

产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段，用于处理用户反馈意见。

不管测试多可靠，依然会有无法预料的所有意外情况，有些问题发布后才会显露端倪。

关键不在于是否会出现问题，而在于能多快解决问题。

第26章 合理运用敏捷方法

敏捷方法源自定制软件，不完全适用于开发产品软件。

产品软件领域使用敏捷方法的诀窍：

1. 产品经理即是产品负责人，代表了客户的需求，需要与开发团队保持密切的联系；
2. 敏捷方法不等于省略产品规划，产品经理仍然要明白产品的方向和目标，设定衡量产品成功与否的标准。
3. 产品经理和设计师的工作进度应比开发团队领先一到两个迭代周期。
4. 尽量把产品设计工作拆分成独立的部分，分而治之。
5. 产品经理的主要任务是定义有价值、可用的产品原型和用户故事，作为开发的基础。
6. 让开发人员自主划分迭代周期。
7. 产品经理和交互设计师必须出席每天的晨会。
8. 除非达到了产品经理的要求，否则不要轻易发布新版本。
9. 每次迭代完后，产品经理向团队展示产品现状。
10. 在团队内开展敏捷培训。

第27章 合理运用瀑布式开发方法

从产品经历的角度看，瀑布式开发方法存在不少问题：

产品验证严重滞后：这是最严重的问题。要等到软件开发的尾声，才能看到可以运行的软件。
变更计划代价不菲：任何对前期决策的修改都会打乱开发流程。如果需求发生变化，修改产品设计是不可避免的 。
无法适应快速的市场变化：严重依赖文档和流程。

瀑布式开发方法过于理想化，以为人们能预见所有问题。全面把我需求，时间证明除非是规模很小的项目，否则瀑布式开发方法很难顺利执行。

第28章 创业型公司的产品管理

创业初期只设三个职位：产品经理、交互设计师和原型开发人员。为节约成本，公司创始人可以亲自担任产品基尼，交互设计师也可以由原型开发人员兼任，只要有人负责承担这三项工作（产品管理、交互设计、原型制作）即可。这个团队可以快速展开产品设计，迭代修改。

1. 创建体现用户体验的高保真原型；
2. 邀请真实的目标用户验证产品原型；

确定产品原型后，再招聘程序员进行开发。有了产品原型，开发人员可以更直观、高效地领会产品设计和开发要求。这将大大缩短开发时间。

第29章 大公司如何创新

20%法则

谷歌的程序员有20%的工作时间可以用来从事创新研究。最好的创意大多来自普通员工。20%法则孤立普通员工自己尝试各种想法，发挥大家的主管能动性，让员工打心底愿意倾注更多的激情和汗水取创新。

臭鼬工程

原指秘密军事行动，现指在受限制的条件下，利用自己的时间，低调地进行创新研究。

主动观察

观察和倾听是最简单的创新途径。应该选择实际用户作为观察对象，不要选择产品尝鲜者，更不能选择公司同事。创新不是发现新问题，而是用新方法解决已有的问题。观察人们对现有产品的不满，是创新的最佳途径。

改善用户体验

另一种创新途径是跳出技术局限，完善用户体验。改善用户体验不仅要提高产品的工作效率，更要提出多余的功能，明白哪些功能是用户必须的，哪些是设计和开发带来的衍生物。

收购小公司

收购是有效维持创新的手段。创业型公司如雨后春笋般出现，经过市场淘汰，留下来的通常都有其特长，可以作为收购对象。

第30章 在大公司施展拳脚

大公司都遵循一条潜规则——尽量规避风险。在大公司工作，首先要面对的是公司现有的流程、规定和条条框框。多数大公司都采取矩阵式的管理方式，核心部门是共享资源。

1. 了解公司指定决策的方式：要学着融入其中。直到决策权在谁手里。
2. 建立人脉网络：主动帮助他人，积累人脉关系。
3. 臭鼬工程：找三五个志趣相投的同事在工作之余做出产品原型来。
4. 自己顶上：与其与流程对抗，不如自己顶上。
5. 有选择地据理力争：不要随便发脾气，与人辩论，要小心措辞，对事不对人。
6. 会前沟通，形成默契：与其临渴掘井，不如未雨绸缪，设法在会前达成一致一键。
7. 合理分配时间：划掉无关紧要的会议，信任同事，让他们拿主意。
8. 分享信息：有舍才有得，分享会获得更多。
9. 向上司借力：用实力取得他的信任，让他放心当你的说客。
10. 传播你的产品理念：多向同事传播你的产品理念，向大家描绘产品愿景，介绍产品策略，演示产品原型，分享用户反馈信息。

第三部分 产品

第31章 苹果公司的启示

苹果公司有很多值得学习的经验，以下四点最重要：

1. 硬件为软件服务：
2. 软件为用户体验服务：苹果公司的所有工作都围绕着产品的可用性、交互设计、视觉设计、工业设计展开；
3. 用户体验为情感服务：
4. 产品为真正的需求服务：手机并非苹果公司首创，但他们挖掘出尚未被满足的用户需求。

第32章 提防有特殊要求的产品

特例产品到底有什么问题呢？它混淆了客户需求和产品需求，必然会使公司偏离正轨。产品需求不能用户说了算，原因如下：在看到具体的产品之前，用户很难直到自己需要什么；用户不知道什么样的产品是可行的；用户之间缺少沟通，需求很难统一。

客户在描述需求时，习惯提出自己的解决方案，但不一定抓住了需求的本质。产品经理应该与客户一起梳理需求，发现问题的本质，提供更合理的解决方案。

第33章 新瓶装老酒

想在成熟的市场抢占一席之地，精明的公司至少要手握两件“法宝”。

第一，对目标市场了如指掌，对现有产品的缺陷洞若观火。
第二，跟踪最新的技术趋势。新技术层出不穷，让之前无法实现的方案变得可能。

市场机遇无处不在，要做的是挖掘需求，运用新技术解决用户的老问题。

需求管理用wiki就够了。

第34章 恐惧、贪婪、欲望

消费者购买产品大多源于情感需求。产品应该满足用户的情感需求。

只有从情感的角度重新观察市场上的产品和服务，你才能体会用户的真实感受。

机会永远不会消失殆尽，比起从前，现在有更多的产品机会。

第35章 情感接纳曲线

愤怒的用户决定着产品未来的发展方向。建议产品经理关注日常生活里那些让大众烦恼不看，又不得不应付的事情。如果产品经理能解决这些问题，一定能打造出成功的产品。

不要一味从技术角度看待产品，多从用户的角度考虑问题。是什么问题让他们头痛？是什么让他们垂头丧气、愁眉苦脸？

为了让产品吸引理性消费者和超理性消费者，应该从分析非理性消费的情感需求入手。非理性消费者的情感需求是推动产品跨越鸿沟的动力。

第36章 可用性与美感

视觉设计可以满足用户的情感需求。

如果向用户展示两款具有同样功能的产品原型，一款具有良好的视觉设计效果，另一款只是由粗糙的线框图组成，用户对这两款原型的反应肯定截然不同。

良好的用户体验是交互设计师和视觉设计师合作的结果，他们共同配合产品经理定义产品。

第37章 大众网络服务产品

十条要点

1. 可用性：如何使用？加载速度。
2. 人物角色：用户画像
3. 扩展性：数据库扩展
4. 持续可用性：24*7
5. 客户服务：尽量减少系统故障和缺陷，更重要的是维持良好的用户体验
6. 保护用户隐私：
7. 口碑营销：用户如果细化产品，就会主动向家人、朋友、同事推荐。
8. 全球化：易于本地化的产品设计可以大大节省开发成本和开发时间
9. 平滑部署：
10. 用户社区管理

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

十条要点

1. 可用性
2. 产品正常工作
3. 特例产品：拒绝诱惑，满足大众
4. 特约用户：多听取客户意见，挑选几位优秀的目标用户，配合产品设计、回答问题、试用软件
5. 销售渠道的需求：不同的渠道有不同的要求，需要为分销链的每一个环节提供价值。
6. 客户和用户的需求：他们的需求并不代表产品最终用户的需求。
7. 产品安装：安装过于麻烦，影响销量
8. 产品的配置、自定义、集成：正常运行，相互兼容，协同工作
9. 产品升级：简化升级技术和流程
10. 销售策略：

第39章 打造平台产品的经验

产品管理中难度最大，也最能体现产品经理实力的事定义成功的平台产品。所谓平台产品，是指一类基础软件，应用开发者在其基础上开发应用程序。

参与研发平台产品的人要面对三种不同的客户：

1. 应用软件供应商：选择你的平台创建解决方案的公司；
2. 开发人员：应用软件供应商的雇员，由他们在平台上开发应用软件；
3. 终端用户：应用软件的使用者，也是平台服务的真正的使用者。

三放各自有截然不同的需求，除非同时满足他们的需求，否则无法打造成功的平台产品。

平台产品的产品经理时常错误估计了形势， 开发人员发表的意见最多，因此他们的需求总是被有限考虑。应用软件供应商为平台产品买单，因此他们被排在第二位。终端用户通常离平台开发时最远，几乎没有直接的互动，因此不幸排在了末尾。忽略终端用户的需求，把开发人员排在了第一位，这是普遍存在的误区。

开发人员勤奋工作是理所应当的，这个观点也许不太中听，但是事实，只有让终端用户满意，平台产品才是成功的。这总比开发人员怡然自得，终端用户却怨声载道好得多。

管理平台产品还有其他的困难：没有统一的交付形式（嵌入式产品、只有品牌、联合品牌、托管服务等）；客户的定制要求多种多样。技术支持是管理平台产品的另一个难点。

第40章 最佳实践经验

十大要点

1. 产品管理的职责：许多产品经理将大把的事件浪费在与产品管理无关的工作上，比如，营销管理和项目管理。这些都不是产品经理该干的活。
2. 用户体验：对于软件产品来说，用户体验就是产品的生命。
3. 机会评估：用方便快捷的机会评估方法取代过时的市场需求文档。先明确产品要解决什么问题，为谁解决问题，以及评估产品的标准。
4. 特约用户：打造优秀的产品没有任何捷径，智能请用户反复试用产品，不断改进。
5. 产品原则：产品管理工作的主要内容是制定决策，明确的产品原则可以帮助产品经理和产品团队梳理清晰的价值标准，做出果断的决策。
6. 人物角色：把目标用户按特征分类，逐一分析、理解其情感和行为，以此作为决策的依据。
7. 探索产品：产品经理的主要职责是探索有价值的、可用的、可行的产品。除非产品经理确定这三点，否则同事的努力都将付之东流。
8. 使用原型：使用高保真原型是探索产品的关键步骤。
9. 用户参与原型测试：原型测试是所有产品经理和产品设计师都必须掌握的工作技能。获取有效的用户反馈是产品经理最重要的工作。
10. 根据数据改进产品：成功的产品经理懂得利用数据来改进现有产品。

第41章 产品经理的反省清单

1. 产品能吸引目标消费者的关注吗?
2. 产品的设计是否人性化，是否易于操作？
3. 产品能在竞争中取胜吗？
4. 我了解目标用户吗？产品是否能够得到他们的认可？
5. 产品是否有别于市面上其他产品？能在两分钟内向公司高管清楚地阐明这些差别吗？能在一分钟内向客户解释清楚吗？能在半分钟内向经验丰富的行业分析师借是很清楚吗？
6. 产品能正常运行吗？
7. 产品是否完整？用户对产品的印象如何？销售业绩如何？销售任务能否顺利完成？
8. 产品的特色是否与目标用户的需求一致？产品特色是否鲜明？
9. 产品值钱吗？值多少钱？为什么值这么多钱？用户会选择更便宜的产品吗？
10. 我了解其他团队成员对产品的看法吗？他们觉得产品号在哪里？他们的看法是否与我的观点一致？