首页  思维导图  详情

启示录读后感

2022-05-19 19:54:25   0  举报





AI智能生成

启示录读后感

工作学习

系统架构

产品功能架构图

分布图

大数据

作者其他创作

大纲/内容

产品

第三十一章苹果公司给我的启示

1.硬件为软件服务

2.软件为用户体验服务

3.用户体验为情感服务

4.产品为真正的需求服务

第三十二章提防有特殊要求的产品

避免陷入困境

我反复强调产品需求不能用户说了算，原因如下：第一，在看到具体的产品之前，用户很难知道自己需要什么；第二，用户不知道什么样的产品是可行的（在目前的技术条件下可以实现）；第三，用户之间缺少沟通，需求很难统一。

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

其次，看看能否在保持产品通用用途的前提下，设法满足客户定制（调整、拓展）产品的要求。

第三十三章新瓶装老酒

新技术层出不穷

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

第一，对目标市场了如指掌，对现有产品的缺陷洞若观火。我喜欢通过产品可用性测试掌握产品情况（包括自己的产品和竞争对手的产品）。

第二，跟踪最新的技术趋势，新技术层出不穷，让之前无法实现的方案变得可能。虽然谁都没有把握永远走在技术的前列，把最新的技术融入产品设计中，但是只要做到一次，你的产品将所向披靡。

第三十四章恐惧、贪婪、欲望

产品中情感的作用

第三十五章情感接纳曲线

技术爱好者：购买产品，仅仅是因为产品采用了新的技术。

非理性消费者（即尝鲜者）的情感需求与大众的相同，但是更强烈。

普通大众具有和非理性消费者同样的情感需求，只是在程度上没有那么强烈。随着产品的完善，他们也会逐步加入消费队伍。

理性消费者（即早期消费大众）只会购买他们认为实用、成熟的产品。他们更务实，只会购买性价比合适的产品。

超理性消费者（即后期消费大众）的情感需求更弱，哪怕产品有半点不合意，他们都不会掏钱。

观望者（即跟随者）约占总人数的15%，他们同样有需求，但只会购买公认好用的产品。

第三十六章可用性与美感

第三十七章大众网络服务产品

十大要点

十条管理大众网络服务产品的要点，但愿能帮助大家打造出更好的产品。这些经验的适用范围包括电子商务、社交网络、搜索引擎、网络游戏。

1.可用性。大众网络服务产品必须具备良好的用户体验。另外，别忘了产品性能是最重要的一条可用性指标，页面加载缓慢让用户无法忍受，也是糟糕的用户体验。

2.人物角色。网站用户数量过百万后，产品经理不可能再逐个研究每位用户，只能按典型特征将用户分类，抽象出有代表性的用户类型（人物角色），加以分析。

3.拓展性。激增的用户数量会带来莫名其妙的问题：数据库崩溃、系统出现性能瓶颈、用户界面罢工。网站上线前进行压力测试虽然可以发现部分问题，但正式使用时总有意想不到的情况出现。

4.持续可用性。大众网络服务要求一刻不能停歇，但迄今为止我还没见过哪家网站能做到24*7小时无故障运行。在系统设计上保证持续可用性与规划拓展性一样重要。

5.客户服务。传统的客户服务完全无法应付数量庞大的网络用户，收费的网络服务情况更严重。要想降低客服压力，除了尽量减少系统故障和缺陷外别无他法。

6.保护用户隐私。大众网络服务公司容易因侵犯或泄露用户隐私被迫停业。应尽早树立保护用户隐私的意识，设置用户资料保护机制，千万不能辜负用户对你的信任。

7.口碑营销。用户如果喜欢产品，就会主动向家人、朋友、同事推荐。这是宣传产品的最佳方式。我建议为用户提供便利，方便他们（通过邮件、短信、社交网络等）向熟人推荐产品。

8.全球化。优秀的互联网产品很快会被其他国家、地区的用户接受，迅速在互联网覆盖的范围内传播开。易于本地化的产品设计可以大大节省开发成本和开发时间，避免为了语言、货币、文化差异大量改写程序。

9.平滑部署。网站用户数量过百万后，任何小小的变化都会影响大面积的用户，要三思而行。部署前要仔细测试，逐步过渡，步幅不可过大，为用户留出足够的时间来适应变化。

10.用户社区管理。所有的商业公司都依靠用户生产，这一点对大众网络服务公司来说显得尤为突出，水能载舟亦能覆舟。如果用户认可你的产品，他们会很乐意成为用户社区的一员，同时希望得到重视和认可。

第三十八章打造企业级产品的经验

十大要点

1.可用性。企业级软件很少会进行交互设计、视觉设计、可用性测试，这样的产品即使卖出去，也不会卖到好价钱。

2.产品正常工作。作为产品经理，确保产品按设计的方式运行是其最基本的责任。

3.特例产品。公司总以为客户可以直接告诉他们需求。必须坚持原则才能拒绝特例产品的诱惑，对急需资金的小公司而言尤其如此。开发满足广大用户需求的产品始终是你的首要任务。

4.特约用户。并不是说客户的话不能听，恰恰相反，应该多同客户见面，听取他们的意见。虽然他们不能直接给出产品需求，但它们能帮助你确定产品需求。

5.销售渠道的需求。按照销售和分销渠道的需求来设计产品很重要。

6.客户和用户的需求。许多企业级软件产品时按照客户（为产品买单的人）的需求设计的。他们的需求并不代表产品最终用户（产品使用者）的需求。

7.产品安装。零售软件如果安装过于繁琐，肯定会影响销量，所以大众软件基本上都做到可以在几分钟甚至几秒钟完成安装。企业级产品在这方面表现则很差。

8.产品的配置、自定义、集成。企业希望重金购置的软件正常运行，相互兼容，协同工作。这一需求催生了一个巨大的专业服务产业。

9.产品升级。想办法简化技术和升级流程，这一点值得企业级软件学习。

10.销售策略。企业级软件的销售靠的是销售人员的个人才智和魅力。但因特网的出现改变了挑选产品和评估产品的方法，软件厂商应该充分利用这种新的销售手段。

合格的软件产品应该具备哪些特征

1.产品具有价值，用户愿意掏钱购买产品。当然用户付费不一定是为了获得使用许可，也可能是为了移除产品中的广告，或者购买售后服务。

2.产品能在多种环境下运行，不是定制软件。

3.只要提供必要的销售工具和销售培训，产品就可以通过销售渠道顺利销售出去。

4.产品公司能够为该产品提供支持，不断完善产品。

5.经销商、服务合作伙伴、客户明白如何安装、配置、使用产品。

专用解决方案

1.软件能帮助企业解决业务问题，通常是特定（垂直）的行业问题。

2.产品可能由一个或多个组件整合而成，这些组件可能是你的公司开发的，也可能是合作方开发的，但他们是预先集成好的。

3.必要时，产品应该获得合作方的产品认证。

一般来说，客户不大关心产品使用的技术，只在意产品能否解决业务问题。

第三十九章打造平台产品的经验

很多成功的平台产品都曾是开发人员的梦魇，却获得了广大终端用户和应用软件供应商的青睐。‘折磨’开发人员并非我的初衷，但产品管理必须权衡利弊。为终端用户提供优质的服务才是我们的目标。

管理平台还有其他的困难：没有统一的交付形式（嵌入式产品、自有品牌、联合品牌、托管服务等）；客户的定制要求多种多样（比如针对终端用户、IT部门、解决方案供应商、系统集成商进行优化）。

技术支持是管理平台的另一个难点。客户是你赖以生存的根本，因此必须提高技术支持的服务能力和服务水平。

第四十章最佳实践经验

十大要点

1.产品管理的职责。许多产品经理将大把的时间浪费在与产品管理无关的工作上，比如，营销管理和项目管理，这些都不是产品经理应该干的活。

2.用户体验。对于大多数软件产品来说，用户体验就是产品的生命。产品经理应该与交互设计师、开发人员密切合作，设计良好的用户体验，打造有使用价值的产品。

3.机会评估。用方便快捷的机会评估方法取代过时的市场需求文档。动手设计产品前，先明确产品要解决什么问题，为谁解决问题，以及评估产品的标准。

4.特约用户。有些产品团队企图绕过用户，直接设计、开发产品，这种想法可笑至极。打造优秀的产品没有任何捷径，只能请用户反复使用产品，不断改进。

5.产品原则。产品管理工作的主要内容是制定决策。明确的产品原则可以帮助产品经理和产品团队树立清晰的价值标准，作出果断的决策。

6.人物角色。人物角色是协助产品经理制定决策的另一项工具。把目标用户按特征分类，逐一分析、理解其情感和行为，以此作为决策的依据。

7.探索（定义）产品产品经理的主要职责是探索（定义）有价值的、可用的、可行的产品。除非产品经理确定这三点，否则同事的努力都将付之东流。

8.使用原型。使用高保真原型是探索（定义）产品的关键步骤。原因如下：第一，迫使产品经理深入定义解决方案；第二，可以让真实的用户参与测试、验证产品创意；第三，可以直观地向团队展示产品的设计思路。

9.用户参与原型测试。有了产品原型，产品经理可以方便地请用户验证产品创意。原型测试是所有产品经理和产品设计师都必须掌握的工作技能。获取有效的用户反馈是产品经理最重要的工作。

10.根据数据改进产品。成功的产品经理懂得利用数据来改进现有产品。改进产品不是根据客户要求一味增加新功能，而是根据产品的实际应用情况，不断地提升产品的各项指标，逐步完善产品。

第四十一章产品经理的反省清单

色的产品经理会时刻关注产品的现状和未来。以下是产品经理无时无刻不在思考的问题。

1.产品能吸引目标消费者的关注吗？

2.产品的设计是否人性化，是否易于操作？

3.产品能在竞争中取胜吗？即使是面对未来风云变化的市场，依旧有取胜的把握吗？

4.我了解目标用户吗？产品（不是理想的产品，而是实际开发出来的产品）是否能得到它们的认可？

5.产品是否有别于市面上的其他产品？我能在两分钟内向公司高管阐明这些差别吗？能在一分钟内向客户解释清楚吗？能在半分钟内向经验丰富的行业分析师解释清楚吗？

6.产品能正常运行吗？

7.产品是否完整？用户对产品的印象如何？销售业绩如何？销售任务是否顺利完成？

8.产品的特色是否与目标用户的需求一致？产品特色是否鲜明？

9.产品值钱吗？值多少钱？为什么值这么多钱？用户会选择更便宜的产品吗？

10.我了解其他团队成员对产品的看法吗？他们觉得产品好在哪里？他们的看法是否与我的观点一致？

反思

成功的产品的十条规律

1.产品经理的任务是探索产品的价值、可用性、可行性。

2.探索（定义）产品需要产品经理、交互设计师、软件架构师通力合作。

3.开发热源不擅长用户体验设计，因为开发人员脑子里想的是实现模型，而用户看重的是产品的概念模型。

4.用户体验设计就是交互设计、视觉设计（对硬件设备来说，则是工业设计）。

5.功能（产品需求）和用户体验设计密不可分。

6.产品创意必须尽早地、反复地接受目标用户的试用，以便获取有效的用户体验。

7.为了验证产品的价值和可用性，必须尽早地、反复地请目标用户测试产品创意。

8.采用高保真的产品原型是全体团队成员了解用户需求和用户体验最有效的途径。

9.产品经理的目标是在最短的时间内把握复杂的市场/用户需求，确定产品的基本要求---价值、可用性、可行性。

10.一旦认定产品符合以上基本要求，它就是一个完整的概念，去掉任何因素，都不可能达到预期的结果。

人员

第一章关键角色及其职责

产品经理

评估产品机会(product opportunity)；定义要开发的产品。

用户体验设计师

交互设计师负责深入理解目标用户，设计有价值的、可用的功能，以及用户导航和产品使用流程。

项目管理人员

产品经理完成产品定义后，开发团队承接项目，开始开发产品。项目管理的核心任务是制定计划和跟踪进度。

开发团队

软件工程师也称为产品开发人员或软件开发人员，负责开发产品。

运维团队

互联网服务产品通常运行在服务器上，用户通过WEB访问服务。运维团队负责保证服务正常运行。

产品营销人员

产品营销团队负责对外发布信息、宣传产品，为拓展市场销售渠道、组织重点营销活动（如在线营销）、促进产品销售提供支持。

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

产品公司会陷入以下三种误区

由市场营销人员定义产品：由产品营销经理或所谓的产品经理负责收集高层产品需求，然后直接交给开发团队开发。这种方式忽略了收集详细产品需求的步骤，回避探索（定义）产品的艰难决策过程（也绕开了用户体验设计）。

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

好的项目管理可以推动项目快速落实。从这一角度产品经理应该和项目经理分开由不同的人负责。

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

用户研究

专门研究、分析用户，评估产品或产品原型是否符合用户的使用习惯，其具体工作包括拟订恰当的测试项目，监督测试，评估测试结果，提出改进方案。

交互设计

在理解目标用户的基础上设计有价值的、可用的目标功能、用户导航和产品使用流程。交互设计师通常用线框绘制产品需求，然后交给视觉设计师。

视觉设计

根据线框设计可见的用户界面（页面），包括严格的布局、颜色和字体设置等。视觉设计能够传达并唤起产品蕴含的情感。

原型制作

迅速制作融合了产品经理和设计师创意的产品原型，让用户试用，并根据反馈意见反复修正原型。

目标

确保产品同时具有可用性（用户明白如何使用产品）和价值（用户对产品的渴求程度）。

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

产品经理负责定义产品方案；开发团队最了解哪些产品构思是可行的，他们负责产品的开发与实现。

如何让开发参与产品定义

1.让开发人员直接面对用户或顾客，体会用户的困惑和疑虑，了解问题的严重性，这样好点子常常会随之而来。

2.向开发人员了解最新的技术发展动向，讨论哪些新技术可以用到产品里。开展头脑风暴，看看目前已实现的技术或即将实现的技术能不能解决手头的问题。

3.让开发人员在探索（定义）产品的初期阶段参加评估产品设计，协助策划方案。

第六章招聘产品经理

对产品的热情；用户立场；智力；职业操守；正直；信心；态度；技能；运用技术的能力；注意力；时间管理；沟通技巧；商业技能；

第七章管理产品经理

建设公司从建设团队开始

新产品经理必须经过约3个月刻苦学习才能开始管理产品。这段时间，它要融入目标用户和客户群，学习相关的技术，了解市场和竞争局势。

规划产品战略

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

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

第八章巴顿将军的忠告

目标管理

永远不要告诉别人怎么做。告诉他们做什么，他们自然会发挥天赋，给你惊喜。

用户体验设计师应该在产品经理分析目标市场、思考解决方案的初期阶段就发挥作用。

第九章产品副经理

办公室里最聪明的人

第十章管理上司

1.为项目波动做好准备用项目波动代指让你心烦意乱的各种返工、计划变更。不要企图消灭项目波动，但是可以尽量降低其负面影响。方法是提高警惕，记录工作进度，比如每周、每月、每季度有多少时间项目在往前推进，掌握项目波动的规律，寻找对策。制定项目计划时，预留出时间应对变化和调整，做好“无用功”的心理准备。

2.注意沟通的方式与频率千人千面

3.会前沟通在会前逐一会见与会的高管和股东，提出你的观点，征询他们的意见，确保会议召开前你们已经达成一致意见。

4.多提建议，少谈问题管理者希望听到解决问题的方法，而不是听你抱怨。最好根据问题的重要性列举出多种解决方案，并附上你的依据和建议。

5.向上司借力假如你通过分析得出了解决方案，公司高管没有时间与你进行会前沟通，但你的上司能找到机会与他们交流，你可以把想法告诉上司，请他帮忙转达建议。

6.充分准备管理者通常聪明过人，能够立马发现你思路和计划上的漏洞。你最好准备充分，弄清问题所在，做到有备无患。

7.缩短邮件篇幅产品经理喜欢写长篇的邮件向上司汇报工作，这是大忌。

8.多用数据和事实说话与上司（尤其是高管）打交道时，务必要提供数据和事实。网景公司前CEO吉姆·巴克斯德尔说过一句名言：如果我们依照个人看法来做决定，那就是臆断。多做准备工作，收集事实和数据，你的建议才有说服力。

9.内部宣传向公司同事宣传产品，让大家认可你的工作，乐于帮助你。充分、有效的宣传，可以大大降低与其他部门合作的成本。

10.做让领导省心的员工管理者的工作是保证院队高效运作，他们时间有限。

流程

第十一章评估产品机会

1.产品要解决什么问题？（产品价值）

2.为谁解决这个问题？（目标市场）

3.成功的机会有多大？（市场规模）

4.怎样判断产品成功与否？（度量指标或收益指标）

5.有哪些同类产品？（竞争格局）

6.为什么我们最适合做这个产品？（竞争优势）

7.时机合适吗？（市场时机）

8.如何把产品推向市场？（营销组合策略）

9.成功的必要条件是什么？（解决方案要满足的条件）

10.根据以上问题，给出评估结论。（继续或是放弃）

第十二章产品探索

弄清楚要开发什么产品（定义正确的产品）

开发该产品（正确地开发产品）

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

第十三章产品原则

确定什么最重要

产品原则是对团队信仰和价值观的总结，用来指导产品团队作出正确的决策和取舍。它体现了产品团队的目标和愿景，是产品战略的重要组成部分。从形式上看，它是一系列明确的、体现团队特色的产品价值准则。

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

在做产品决策之前，应该先确定决策要解决什么问题，让大家在以下几个要点上达成共识。

1.究竟要解决什么问题？

2.要为那类人物角色解决这个问题？

3.产品要达到什么目标？

4.每项目标的优先级是什么？

第十四章产品评审团

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

产品公司需要一套机制让决策者和相关人员及时作出明智的产品决策。

产品评审团的工作目标

成立产品评审团的目的是决定产品战略方向，从宏观上监督公司产品的研发流程，合理地配置资源。

产品评审团的职责

产品评审团并不是设计和开发产品的团队，它的职责是监督产品研发流程，指定关键决策。

他根据研发产品的四个里程碑来评审产品，制定决策。

1.评审产品战略和产品路线图，启动评估产品机会的工作，即选择值得投入精力的产品，请产品经理开始评估产品机会。

2.根据评估产品机会的结果，决定是否开始定义产品的解决方案。

3.评审产品原型、用户测试结果、成本估算明细，决定是否开始开发产品。

4.评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品。

第十五章特约伙伴

产品开发伙伴

产品经理要深入了解目标用户，明确产品需要解决的问题，定义出满足用户需求的产品，因此产品经理必须和用户紧密结合。

为了解决这两个问题--及深入洞察目标用户的需求，又赢得用户对产品的推荐，我建议征集特约用户协助完成产品研发。

成为特约用户的好处

1.参与构思产品创意，解决他们手头上的问题--他们最清楚产品要解决的问题，因为这些麻烦正在困扰他们。

2.提前试用产品，越早使用产品意味着越早解决麻烦。

3.通常，提前试用产品还可以显著降低用户的各种成本。

产品经理的收获

1.聚拢一批积极的用户，它们可以为定义产品和开发产品提供建议和协助。

2.提供调研便利，便于产品经理去特约用户的工作场所调研。

3.可以定期组织特约用户进行小组讨论。

4.特约用户第一时间试用、测试产品，迅速反馈意见。

5.如果特约用户满意产品的表现，会乐意公开推荐产品。

组织特约用户的注意事项

1.不要想特约用户收取参与费用，否则合作关系将会变味。产品经理需要的是开发产品的伙伴，不要变成为特约用户开发产品。如果特约用户愿意，你尽可以等正式产品发布后再向他们收取费用。

2.由于可以免费试用产品，通常会有大量的申请者申请成为特约用户。公司的销售部门为了提高业绩，可能会要求产品经理招募更多的用户。这会消耗产品经理大量的精力，而且这些用户不一定符合要求。

3.如果在寻找特约用户时遇到困难，很可能是因为产品要解决的问题不像产品经理想象的那么重要，将来也很难销售出去。

4.产品经理需要确保特约用户是产品的潜在目标用户。我们很容易把产品尝鲜者误当成特约用户。产品尝鲜者常常能容忍产品的不足和缺陷，根据他们的建议研发的产品，很可能只适合他们自己，无法满足大众的需求。

5.产品经理务必向特约用户说明，我们要开发的是面向大众的通用产品，不是某家公司开发的定制产品。

6.产品经理应该把特约用户当成开发伙伴对待，视他们为同事，互相帮助。

7.产品经理与特约用户的合作贯穿产品研发的每个环节：向他们展示产品原型，请他们参加测试，向他们请教产品的细节问题，让他们帮你部署、测试待发布产品的备选版本。

8.正式产品发布前，一定要先请特约用户试用，确保每个人都满意，一旦发布，他们会坚定不移地向大众推荐产品。

9.产品经理还要和产品营销团队紧密合作。一方面，营销团队可以帮助你物色特约用户；另一方面，他们可以协助你提高特约用户受关注的程度。

10.如果是平台产品，特约用户的作用就更突出了，只不过六个特邀用户要换成六个应用。产品经理要与特约应用的开发者紧密合作，确保在平台上构建的应用让用户感到满意，最好鼓励应用开发者发展自己的特约用户。

第十六章市场调研

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

用户调查：做用户调查注意两点。第一，设计调查问卷需要技巧和经验，不是一件容易的事。要结合具体情景，仔细设置问题，如果调查问卷措词不清、先入为主，其他部门的同事就会质疑调查结果。第二，调查结果为获得解决方案提供了一条途径，但不是解决方案本身。

用户使用分析：如果你的产品是网站，有很多实用的工具可以分析用户访问网站的行为。

数据挖掘：收集数据的渠道越多，除了上面提到的产品使用分析，还有用户的账单和账户信息、产品数据等。

拜访用户：没有一种方法可以替代前往用户使用产品的场所（家、办公室）实地考察的作用。

人物角色：我喜欢定义和设计产品的过程中使用人物角色。市场调研也可以借助人物角色展开。

可用性测试：我主张尽早、反复地进行可用性测试。观察用户使用现有产品的反应，收集反馈意见，了解他们的真实想法。

同类产品分析：每款产品都有做的好的地方。有必要找出竞争对手的优势，学习对手的成功经验。

合理的利用市场调研工具和方法可以回答以下几个关键问题。

1.谁是目标用户？

2.用户会怎样使用产品？

3.用户能想明白怎样使用产品吗？障碍在哪里？

4.用户为什么选用你的产品？

5.用户喜欢产品的哪些特点？

6.用户希望如何改进产品，增加哪些功能？

市场调研的局限性

市场调研结果可以作为研发产品的依据和参考，但不能决定产品研发的方向。

探索（定义）产品的过程则要回答如下问题。

1.采用什么技术来更好地解决产品要解决的问题？

2.设计什么样的用户体验？

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

总而言之，市场调研结果可以用于完善现有产品，精益求精。

第十七章产品人物角色

产品管理的核心在于制定决策--应该抓住哪些机会，解决什么问题，哪些功能最有价值，谁是主要用户。有决策就有失误，但要打造成功的产品必须保证大部分决策是正确的。

人物角色又称为用户特征记录（user profile），是指通过与用户沟通交流，确定典型的目标用户类型，在理解各类目标用户的特征的基础上建立的人物原型。

为了发掘潜在的人物角色，产品经理必须深入参与创建人物角色的工作，尤其是要亲自参加用户交流和用户调查。产品经理、交互设计师、用户研究团队（如果有的话）之间必须密切合作。产品经理应该参与所有的产品可用性测试，抓住一切机会与用户交流，深入了解目标用户。

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

产品经理的核心责任是确保向开发团队交付具有成功潜力的产品说明文档。

理想的产品说明文档应该满足以下要求。

1.产品说明文档应该完整地描述用户体验---不只是用户需求，还包括交互设计和视觉设计。希望大家已经明白用户需求和用户体验是密不可分的。

2.产品说明文档必须准确地描述软件的行为。文字和图片的表达能力实在有限，不足以完成这项任务。

3.产品说明文档的受众较广---开发人员、测试人员、客服人员、市场营销人员、运维人员、销售人员、管理层等等。因此，产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。

4.产品说明文档应该可以修改。虽然进入开发阶段后，应该尽量避免修改产品说明文档，但总有意想不到的问题出现，需要修改产品说明文档以适应新情况。

5.撰写产品说明文档的过程中会出现许多衍生物，比如，安优先级排列的需求列表、线框图、实体模型，但应该有一个主体来代表产品，避免混淆不清，版本错乱。

“高保真”的含义是原型应该真实地体现用户体验。

仅仅有高保真原型是不够的，因为有些产品行为不容易用原型体现，比如业务逻辑（税务表单和运费等）、发布要求（性能表现、可靠性、拓展性等）、平台交付要求（安装要求、浏览器兼容性等）。用例可以作为有效的补充，用来描述重要的产品行为。

第十九章用户体验设计与实现

先定义用户体验在动手开发

1.与软件开发团队合作的人要记住一点：一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高。

2.用户体验设计要保证产品同时具备可用性和价值，任务很重要。

3.我认为验证设计思路必须使用高保真原型。为了验证各种设计思路，产品原型应该可以随意修改，完成其任务后应该被丢弃。而开发中的产品应该以固定的原型为基础。

4.尽管产品开发可以分成多次迭代（这样做可以降低风险，提高质量，便于产品集成），用户体验设计却不能拆分。设计师必须全面地连贯地看待用户体验，考虑以往用户的使用习惯。让用户放弃不可用的软件很容易，要他们放弃使用习惯却很难。

5.用户体验设计不一定是最费时间的工作（像软件开发一样，所需时间取决于具体的方法、特定的产品需求，以及从业者的技能和经验），但至少需要一两周时间。

虽然需求调研和产品设计可以同步开展，产品开发和测试可以交叉进行，但是用户体验设计应该在软件开发前完成。

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

第二十章基本产品

削减功能还是延长工期？

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

另一种产品设计方式可以解决这个问题。

第一，产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少，因而是非常重要的。

第二，邀请一位开发人员参与设计原型。请他检查原型，帮助产品经理和设计师估算各种功能的直接成本和间接成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能。等产品原型确定时，他详细估算出所有产品功能的时间成本。

第三，请真实用户验证（测试）产品原型，这一点至关重要。在产品团队全力开发产品前，产品经理和设计师必须确信产品是用户需要的，然而仅仅相信还不够，必须通过用户测试来验证。

因此，设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。就像我从前的老板常说的---短腿的狗打不了猎。

第二十一章产品验证

正面产品的价值、可用性、可行性

可行性测试

首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。

重点是让开发人员寻找产品设计里那些难以克服的障碍，现在发现远比损失了时间和资金后发现来得好。

可用性测试

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

可用性测试往往能发现没能成功实现的产品需求，如果测试得当的话，甚至能发现原本被忽略的产品需求。最好规划多次迭代测试，确保实现最佳的用户体验效果。

请注意，为了测试可用性，即使要模拟复杂的后台处理过程也是值得的，关键是要评估用户体验的实际效果。

价值测试

最后，仅仅知道产品能够开发出来、方便使用，这还不够。同样要紧的是知道用户是否觉得你的产品有用，是否愿意购买，有多喜欢产品的设计。

第二十二章原型测试

把产品创意呈现给真实用户

产品可用性测试（检验用户能否想明白如何使用产品）和产品价值测试（检验用户是否渴望使用产品）同样重要。

物色测试者

开始原型测试前，要寻找测试者。如果把测试外包给专业团队，他们会为你挑选用户、约定测试时间，节省你的时间。

准备测试

确定可用性测试的内容，并拟出问题，就产品的价值向测试者提问。

测试环境

轻松地测试环境可以收集到更多的反馈。

测试原型

1.测试前不宜与测试者交谈过多，事先谈的越多，透露的产品线索就越多，测试者就越不可能说出他们对产品的第一印象。

2.寒暄之后务必告诉测试者：这只是产品原型，是初步的产品创意，不是正式产品；请说出真实的想法（不管好坏），不必碍于情面有所保留；被测试的对象是原型，不是测试者，测试者不必担心测试失败，只有原型会通不过测试。

3.测试时，尽量让测试者保持平和的情绪，千万不要让他们陷入吹毛求疵的状态。

4.测试时尽量保持安静，不要给测试者提示。

5.通常有三种测试结果：测试者在没有提示的情况下，顺利完成测试项目；测试者遇到麻烦，但通过反复尝试，最终完成了测试项目；测试者受挫，最终放弃。

6.一般来说，要尽量避免提示测试者，更不能引导他。

7.测试主持人不妨向鹦鹉学习，使用自言自语的技巧。

8.测试的作用是理解目标用户如何看待产品要解决的文艺，发现原型与用户预期不一致或不相容的地方，也就是原型不符合用户直觉和习惯的地方。

9.从测试者的肢体语言和语气里可以发现许多有用的信息。

更新原型

测试原型的目的是找出原型中需要修改的部分，提高原型的可用性和价值（吸引力）。

第二十三章改进现有产品

不是一味的添加功能

许多产品经理改进已有产品时会变得不知所措。有些人详细画出产品路线图（roadmap），列出想要添加的功能，或是记下来自某位用户的要求，例如，想让我掏钱买这款产品，除非添加六项功能......

产品改进不是简单的满足个别用户的要求，也不能对用户调查的结果照单全收。能提高指标的功能才是你关注的重点。

第二十四章平滑部署

避免更新产品导致用户反感

不是所有的用户都喜欢新版本的产品。用户产生反感的主要原因有以下几个

1.事前没有收到更新通知，用户觉得措手不及。

2.用户没时间学习、适应新版本，产品公司也没有提供旧版本方便用户在过渡阶段使用。

3.新版本无法正常运行。

4.新旧版本不兼容（比如新版本无法访问旧版本的数据）。

5.虽然新版本可以正常运行，但用户认为添加的功能和特性毫无必要。

6.应付接二连三的版本更新，用户感到疲惫不堪。

7.新版本修改了用户已经习惯的使用方式和操作流程，用户不得不重新调整适应。

为了将版本更新带来的影响降到最低，可以采取以下几种措施。

1.通过公告、群发邮件、在线教程等方式提前通知用户，但是很多人既没时间也没兴趣阅读这些内容，所以这个方法效果有限。

2.加倍做好测试工作，避免新版本存在影响正常使用的隐患，比如可靠性问题、拓展性问题、性能问题。确保将来不会陷入被迫返回旧版本的窘境，为用户增加不必要的麻烦。

3.如果更新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式来降低风险。

一种平滑部署的方式是发布两个并行的版本，邀请有兴趣、有时间的用户使用新版本。如果新版本运行正常，大部分用户习惯新版本后，再将新版本设为默认版本。

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

还有一种方式是增量部署，将更新项分割成几个较小的部分逐步发布。

第二十五章快速响应阶段

产品出炉后切莫虎头蛇尾

产品发布后依旧需要保持高度警惕。收集反馈信息、改进产品。

评估产品表现应该使用明确的、可量化的指标。你最关心产品哪方面的表现，是页面访问量、注册用户数、访问停留时间、会员转换率、订阅数，还是广告收益？

第二十六章合理运用敏捷方法

十大秘诀

1.产品经理即是产品负责人（product owner），他代表了客户的需求，因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题。

2.使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法替代冗长的市场需求文档。

3.产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保你们有足够的时间攻克难题。让交互设计师和视觉设计师提前设计产品，充分发挥他们主导设计的作用。

4.尽量把产品设计工作拆分成独立的部分，分而治之，但也不能拆得太细---好比设计建筑不能一次只设计一个房间。目标是设计出符合基本要求的产品。

5.产品经理的主要任务是定义有价值、可用的产品原型和用户故事（user story），作为开发的基础。用产品原型和用户故事替代厚厚的产品需求文档和功能说明文档有三个优势：①可以请用户测试②强迫产品经理全面认真地思考问题③向开发团队明确地描述每次迭代周期需要完成的任务。请用户测试原型，根据反馈意见反复迭代修改原型设计，确保交给开发团队的是有价值的结果，避免任何浪费，哪怕只是一个迭代周期。

6.让开发人员自主划分迭代周期。有的产品功能可以在一个迭代周期完成，有的却需要好几次迭代才能完成。好的原型可以提高估算工作量和开发时间的精度。别忘了，开发团队必须考虑产品的质量、性能、拓展性，应该让他们自行决定如何划分迭代周期。

7.产品经理和交互设计师必须出席每天的晨会。晨会是一天沟通过程的开始，而不是结束，关于产品的讨论会持续一整天。设计师向开发人员和测试人员展示产品功能；开发人员互相展示完成的代码，让测试人员测试，请设计师和产品经理过目；测试人员和开发人员在制作原型阶段识别潜在的问题，协助产品经理制定更合理的决策，解决产品设计、开发的问题。

8.除非达到了产品经理的要求，否则不要轻易发布新版本。产品经理必须确保交给用户的产品能正常运行。过度频繁更新版本会让用户感到不安。

9.在每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型，让大家看到工作成果，同时加深大家对产品的理解，增强团队对这种开发方式的信心。

10.在团队内展开敏捷培训。聘请敏捷顾问协助你们完成敏捷团队转型的目标，但是要确保敏捷顾问有过类似的工作经验，理解产品软件与定制软件的差别。只有每位团队成员都真正理解敏捷方法，你才能把工作重心放在执行上，否则敏捷方法就只能停留在教条式的理论层面。

第二十七章合理运用瀑布式开发方法

瀑布式开发方法的基本原则

1.采用阶段式开发。软件开发过程被事先分成固定的几个阶段：撰写书面的需求说明文档、设计高层软件架构、设计低层细节、编写代码、测试、部署。

2.采用阶段式评审。每个阶段结束后，对该结束后，对该阶段提交的成果进行评审，评审通过后才能进入下一阶段。

第二十八章创业型公司的产品管理

关键在于产品探索

两个关键点

1.创建体现用户体验的高保真原型

2.邀请真实的目标用户验证产品原型