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

好产品靠设计

富有创意的产品从不来自偶然，以下是作者总结的十条成功产品的规律：

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

Part1 人员

Ch1 · 关键角色及其职责

现代软件产品团队

• 产品经理：评估产品机会，定义要开发的产品。（文档应该描述产品的功能和属性，避免讨论产品的实现方法）

• 用户体验设计师：用户体验设计团队由多重角色组成，最关键的角色是——交互设计师（也称信息架构师、用户界面设计师、用户体验架构师）。负责深入理解目标用户，设计有价值的、可用的功能，以及用户导航和产品使用流程。与产品经理密切合作，将功能与设计相结合，满足用户需求，确保产品同时具有可用性和价值。

  可用性指用户明白如何使用产品，价值指用户对产品的渴求程度。

• 项目管理人员:负责在开发产品的过程中制订计划和跟踪进度。

• 开发团队：负责开发产品。

  IT团队通常指的是为内部员工提供技术支持的团队，而开发团队指的是为外部客户开发和维护产品的团队。

• 运维团队：保证服务器正常运行。

• 产品营销人员：负责对外发布信息、宣传产品，为拓展市场销售渠道、组织重点营销活动、促进产品销售提供技术支持。

通常，每五到十位开发人员配备一位产品经理，一位交互设计师大约可以支持两位产品经理的工作，一位视觉设计师可以支持四位交互设计师的工作。凡超过十名开发人员参与的重大项目，就应该配备专职的项目经理。

Ch2 · 产品管理与产品营销

产品经理和市场营销不是一回事。

产品公司常常会陷入一下三种误区：

①由市场营销人员定义产品。由营销经理负责收集高层产品需求，然后直接交给开发团队开发。

②两人分担定义产品的工作。营销人员负责高层商业需求，产品经理负责底层产品需求。

③一人兼任两项工作。营销人员兼任产品经理的工作。

以上这些错误会为公司带来很大损失。要解决这些问题，必须清晰界定产品经理和营销人员的职责。但是，产品经理和营销人员也应该多沟通、展开合作。

Ch3 · 产品管理与项目管理

产品管理的职责是探索（定义）有价值的、可用的、可行的产品；而项目管理则关注如何执行计划以按期交付产品。

对互联网公司而言，把这两种职位分开至关重要。

作者总结的优秀项目经理的七个特点：

工作紧迫感、善于捕捉问题、思路清晰（分离问题、专注解决）、用数据说话、果断、判断力（何时做何事）、态度（一往无前、愈挫愈勇）。

Ch4 · 产品管理与产品设计

理解用户体验设计

与用户体验设计密切相关的分工：用户研究、交互设计、视觉设计、原型制作。

Ch5 · 产品管理与软件开发

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

Ch6 · 招聘产品经理

寻找出色的产品经理

个人素质和态度、对产品的热情、用户立场、智力、职业操守、正直、信心、态度、技能、运用技术的能力、注意力、时间管理、沟通技能、商业技能。

Ch7 · 管理产品经理

建设公司从建设团队开始

管理产品经理的人通常被冠以产品总监或产品副总裁的头衔。

建设产品管理团队

规划公司的产品战略

Ch8 · 巴顿将军的忠告

目标管理

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

产品经理收集需求时，常听到客户建议“如何做”产品，而不是产品应该“做什么”，毕竟思考问题的解决办法是人类的本性。如果产品经理试着思考产品要做什么，就会惊讶地发现实现方法如此之多。

产品经理习惯于告诉用户体验设计师如何设计产品，却忘了告诉他们产品要“做什么”。这是普遍存在于用户体验设计中的问题。

产品经理留给用户体验设计师和开发人员的空间应尽可能大。

Ch9 · 产品副经理

办公室里最聪明的人

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

产品经理应该接受别人来提出创意，因为更多的灵感是受别人启发得到的。公司的目标是打造卓越的产品，所有可以借用的力量都是可取的。

Ch10 · 管理上司

十条经验

由于管理层导致的项目波动问题是固有的，不可能完全消除，唯一能做的是缓解其影响。作者介绍了管理上司的十条经验：

1. 为项目波动做好准备。
2. 注意沟通方式与频率。
3. 会前沟通。
4. 多提建议，少谈问题。
5. 向上司借力。
6. 充分准备。
7. 缩短邮件篇幅。
8. 多用数据和事实说话。
9. 内部宣传。
10. 做让领导省心的员工。

Part2 流程

Ch11 · 评估产品机会

确定待解决的问题

正常情况下，业务人员会撰写一份论证产品可行性的市场需求文档，描述待解决的问题。理论上，市场需求文档只描述产品机会，不涉及具体解决方案。但是多数公司跳过了市场需求文档，有些将市场需求文档误写成产品规范文档，有些则没回答该回答的问题，还有些即便玩长了市场需求文档，也将它束之高阁，不闻不问。

评估产品机会是产品经理的重要职责。评估产品机会的目的在于：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源。

为了评估产品机会，作者希望产品经理回答如下十个问题：

1. 产品要解决什么问题？（产品价值） 较难回答。
2. 为谁解决这个问题？（目标市场）
3. 成功的机会有多大？（市场规模） 可求助于行业分析师、贸易协会、公司财务，再结合自己的分析作出判断。评估务必谨慎，避免浮夸。
4. 怎样判断产品成功与否？（度量指标或收益指标）
5. 有哪些同类产品？（竞争格局）
6. 为什么我们最适合做这个产品？（竞争优势）
7. 时机合适吗？（市场时机）
8. 如何把产品推向市场？（营销组合策略） 描述具体销售方式，甚至会影响具体需求。
9. 成功的必要条件是什么？（解决方案要满足的条件） 调研过程中发现的特殊需求，搞清楚产品的依赖因素和约束条件。比如：如果要通过系统集成商来销售产品，对方可能会对产品的扩展性、合作方式提出要求。
10. 根据以上问题，给出评估结论。（继续或放弃）

以上问题并不涉及具体的解决方案。机会评估只讨论待解决的问题，不应涉及具体的解决方案。产品经理往往把待解决的问题和解决方案放在一起考虑，当具体解决方案遇到困难时，他们会放弃产品机会。这是典型的“把洗澡水和孩子一起泼掉”的做法。

开发新产品还是维护旧产品？

关键在于比较两者的机会。产品团队一视同仁地评估两者的收益与成本，然后由管理团队作出决策。此时，机会主义并不是不可取的。

很多时候，好机会就在眼皮底下，完善不尽如人意的产品特性往往事半功倍。

举例来说，100位打算注册使用产品的用户最后只有9人顺利完成注册，如果设法把人数提高到18，就能让产品的收益翻倍。这种改进往往很容易实现，只要做一些原型测试和用户测试，很快就能找出存在的问题， 想出解决方案。

再举一个例子，产品公司往往雇用上百人的客服团队为用户提供售后服务，如果能提高产品的易用性，将大幅减少客服人员的数量，降低成本，同时提高用户满意度和用户净推荐值。

这也是糟糕的产品设计和蹩脚的用户体验导致的结果。原有产品质量差，公司不愿意想办法改进，反而认为开发新产品更容易，导致原有产品无法发挥潜力、产生应有的利润。除非这些公司改变研发产品的方式，否则，新产品难免重蹈覆辙。

结交一位懂财务的朋友（财务部门的同事）能让产品经理受益匪浅。他们能：

帮助我们了解产品，评估产品，看看公司的投入是否划算，他们对产品的预测如何。

帮助我们了解用户，财务部门掌握着交易记录、支付信息、客户数据和经营报表。获取到我们有权获取的信息，并利用好它们。

帮助我们确认我们的新想法在商业上的可行性。我们提供信息，他们帮我们分析整合。当我们与高管讨论产品的可行性时，能得到财务部门的支持真是再妙不过了。

Ch12 · 产品探索

定义正确的产品

软件项目可以划分为两个阶段：弄清楚要开发什么产品（定义正确的产品）；开发该产品（正确地开发产品）。第一个阶段探索产品，第二个阶段则强调执行。产品经理必须在执行阶段转换工作重心，否则，产品经理自己很有可能成为产品上市的最大障碍。

作者建议的解决冲突的办法：采用流水线方式秉性开发产品。一旦1.0版本的产品进入项目执行阶段，就开始定义2.0版本的产品。一旦前一个版本进入开发阶段，就把创造热情投入下一个版本。但是，不要让这种做法干扰正在执行的项目。

Ch13 · 产品原则

确定什么最重要

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

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

产品原则是否公开因公司而异，它还可以用来团结产品团队，让产品、开发、营销团队形成共同的价值观，在认识上保持一致性。

仅仅罗列出产品原则还不够，还要按照原则的重要性排序，总有要优先考虑的原则。

产品原则在制定时容易出现两类错误：①过于空泛，失去了指导作用。②把设计原则误当成产品原则（如：为用户提供清晰的导航路径（方便用户完成下一步操作）属于常见的设计原则，不是产品原则）。

如果我们所在的团队还没有制定清晰的、有关产品理念的产品原则，应该把大家召集起来，花点时间讨论分析，确定团队最看重的价值理念。

解决意见冲突

制定产品决策的过程中存在的困难着实不少，这些困难是不可避免的，因为建设性的辩论和论证是定义优秀产品的必经之路。不过即使意识到这点，与会者也很难把争论当成一种享受。

为了鼓励创新，改善讨论效果，同时降低外界干扰，在作产品决策之前，应该先确定决策要解决什么问题，让大家在以下几个要点上达成共识：

1. 究竟要解决什么问题？
2. 要为哪类人物角色解决这个问题？
3. 产品要达到什么目标？
4. 每项目标的优先级是什么？

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

比如说，团队首先应该确定哪个目标对用户最重要，是易用性、响应速度、功能、成本、安全性、还是用户隐私？只有先统一对产品目标优先级的认识，大家才能在此共识上进一步讨论各种方案的合理性与可行性。

务必认真分析产品目标的优先级（从最重要到最不重要逐项排序），让团队达成共识。切不可囫囵把所有目标都贴上“关键”“重要”的标签。

制定决策的过程和依据必须完全透明，不能让人觉得我们只凭直觉判断。务必告诉大家决策的依据和理由，清楚展示每一个决策环节。

激烈的会议争论会影响大伙的斗志和工作效率。如果再出现这种情况，需要先回顾产品目标和目标优先级，确保大家达成共识。

Ch14 · 产品评审团

Ch15 · 特约用户

产品开发伙伴

为了解决——既深入洞察目标用户的需求，又赢得用户对产品的推荐的问题，建议征集特约用户（也叫用户顾问委员会、用户评审团）协助完成产品研发。

方法为，在项目开始阶段物色至少六位积极、活跃、乐于分享的目标用户，要求是他们在产品的目标用户中具有一定的影响力。至于他们是否使用过公司原有的产品并不重要，只要他们认为未来的产品可以解决他们手头亟待解决的问题就行。

成为特约用户的好处

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

产品经理的收获

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

组织特约用户的注意事项

1. 不要向特约用户收取参与费用，否则合作关系会变味。产品经理需要的是开发产品的伙伴，不要变成为特约用户开发产品。如果用户愿意，我们可以等正式产品发布后再向他们收取费用。
2. 由于可以免费试用，通常有大量申请者申请成为特约用户。但众多的特约用户会消耗产品经理大量精力，而且这些用户不一定符合要求。特约用户人数绝不能超过十个。
3. 如果在寻找特约用户时遇到苦难，很可能是因为产品解决的问题不像产品经理想象的那么重要，将来也很难销售出去。这可以初步验证产品创意是否有价值。出现这种情况，产品经理应该重新考虑产品计划。
4. 产品经理需要确保特约用户是产品的潜在目用户。我们很容易把产品尝鲜者误当成特约用户，他们常常能容忍产品的不足和缺陷，
5. 产品经理务必向特约用户说明，我们要开发的是面向大众的通用产品，不是为某家公司开发的定制产品。特约用户也不希望出现这种情况，因为一旦产品被淘汰，售后服务也将被取消。
6. 产品经理应该把特约用户当成开发伙伴对待，视他们为同事，互相帮助。
7. 产品经理与特约用户的合作贯穿产品研发的每个环节：向他们展示产品原型，请他们参加测试，向他们请教产品的细节问题，让他们帮你部署、测试待发布产品的备选版本。
8. 正式产品发布之前，一定要先请特约用户试用，确保每个人都满意，一旦发布，他们会坚定不移地向大众推荐产品。
9. 产品经理还要和产品营销团队紧密合作。一方面，营销团队可以帮助我们物色特约用户；另一方面，他们可以协助我们提高特约用户受关注的程度。
10. 如果是平台产品，特约用户的作用就更突出了，只不过六个特约用户要换成六个应用。产品经理要与特约应用的开发者紧密合作，确保在平台上构建的应用让用户感到满意，最好鼓励应用开发者发展自己的特约用户。

以上例子虽然多数是企业软件和平台产品，但同样也适用于针对针对大众的互联网服务和消费类产品。如果是互联网服务，特约用户的人数应该增加至10-15人，不过要保证产品经理有精力充分了解每位特约用户，以及他们使用服务的环境（家或办公室）。

从营销的角度来看，大众消费者对口碑营销的反应可能与企业采购经理的不同。大众消费者更容易接受媒体和网站评论的影响，但是他们也希望看到真实用户的评价。在这一点上两者是相同的。

使用特约用户是确保产品不偏离用户需求最简单有效的办法，同时也是向潜在用户宣传、推荐产品的最佳手段。

Ch16 · 市场调研

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

市场调研的作用

常用的市场调研工具和方法：用户调查、产品使用分析、数据挖掘、拜访用户、人物角色、可用性测试、同类产品分析。

市场调研的局限性

市场调研结果可以作为研发产品的依据和参考，但不能决定产品研发的方向，即，不能直接回答最根本的产品问题：打造什么产品？

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

1. 采用什么技术来更好地解决产品要解决的问题？
2. 设计什么样的用户体验？

Ch17 · 产品人物角色

理解目标用户

创建人物角色。

Ch18 · 重新定义产品说明文档

安息吧，纸质说明文档

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

1. 完整地描述用户体验——不只是用户需求，还包括交互设计和视觉设计。
2. 必须准确地描述软件的行为。文字和图片的表达能力实在有限，不足以完成这项任务。
3. 必须以某种直观的方式把产品信息和产品行为告诉所有人（产品说明文档的受众较广——开发人员、测试人员、客服人员、市场营销人员、运维人员、销售人员、管理层等等）。
4. 应该可以修改。虽然进入开发阶段后，应该尽量避免修改产品说明文档，但总有意想不到的问题出现，需要修改产品说明文档以适应新情况。
5. 撰写产品说明文档的过程中会出现许多衍生物，比如，按优先级排列的需求列表、线框图、实体模型，但应该有一个主体来代表产品，避免混淆不清，版本错乱。

作者认为，只有一种形式的产品说明文档可以满足以上所有要求——高保真产品原型。

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

最理想的展示补充说明文档的方法是在原型上增加注释，如果无法做到，可以使用内部网站，团队成员可以随时读到最新信息，不用浪费时间查找版本混乱的纸质文档。网站可以定期通知大家产品说明文档的更新情况，方便大家提问和讨论，并保存所有决策记录。

但是，产品说明文档的主体应该是高保真原型，由他来体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。另外，它最突出的优势是可以用于测试。

只有通过真实用户的可用性和价值测试，产品说明文档才算合格，产品才值得开发。

为了验证各种设计思路，产品原型应该可以随意修改，完成其任务后应该被丢弃。而开发中的产品应该以固定的原型为基础。

Ch19 · 用户体验设计与实现

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

尽管作者提倡需求调研和产品设计都要在软件开发前完成，但是在此期间至少应该邀请一位软件开发人员检查设计工作，他可以帮助我们评估设计的可行性和成本，作出更明智的决策。

Ch20 · 基本产品

削减功能还是延长工期？

建议团队放弃老式的产品设计方式。比如，不再视图定义最终产品，转而定义只满足基本要求（价值、可用性、可行性）的产品，简称基本产品。一旦基本产品定义完成，通过了用户测试，他就是一个不可分割的整体，去掉任何元素，都不可能获得预期的效果。

作者建议采用的产品设计方式：

1. 产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少，因而是非常重要的。
2. 邀请一位开发人员（架构师或主程序员）参与设计原型。请他检查原型，帮助产品经理和设计师估算各种功能的直接成本和间接成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能。等产品原型确定时，他详细估算所有产品功能能点时间成本。
3. 请真实的用户验证（测试）产品原型，这一点至关重要。在产品团队全力开发产品前，产品经理和设计师必须确信产品是用户需要的。

一旦基本产品确定，通过了目标用户的测试，就不可能再削减任何功能。如果还能削减，那说明我们定义的不是基本产品。

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

Ch21 · 产品验证

证明产品的价值、可用性、可行性

产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求。

产品团队对自己的产品往往过于自信，不愿意验证产品，只顾埋头开发，总想等到公开测试时再收集反馈意见。毫无疑问，到那时再想大幅修改产品是不可能了，因此许多产品刚发布时表现得非常糟糕，这也不足为奇。

产品经理向产品团队提供最终的产品说明文档前，需要进行以下三项重要的验证。

可行性测试

首先要明确在现有的技术条件下，能否成功开发出产品。

可用性测试

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

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

一定要请真实的用户来试用可用性原型，从目标用户那里可以得到宝贵的反馈信息。

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

价值测试

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

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

使用原型并非验证产品（尤其是互联网服务）的唯一方式，还有其他简单有效的方法，但它们都在强调正式开发软件前验证产品设计，因为设计总有考虑不周、出人意料的情况。越早发现问题越好，一旦进入开发阶段，修改产品设计的难度和成本会越来越高。

Ch22 · 原型测试

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

使用产品原型的最主要原因是产品原型可以让用户验证产品的创意，加深产品经理对产品的理解，避免开发团队浪费时间和精力开发没有把握的产品。

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

物色测试者

开始原型测试前，要寻找测试者。如果把测试外包给专业团队，他们会为我们挑选用户、约定测试时间，节省我们的时间。如果我们自己寻找测试者，作者给出如下几条建议。

1. 如果我们已经拥有一批特约用户，可以邀请他们参加测试。否则，需要马上开始物色。
2. 如果是企业及产品，同类产品的产销会是寻找目标用户的好去处。
3. 可以在分类信息网站上发布广告，征集测试者。征集要求可以写得笼统些，不必过于具体。时候打电话给我们感兴趣的应征者，了解对方的意向，进一步筛选合适的测试者。
4. 如果是大众产品，可以邀请自己的亲朋好友参加测试，但要避开过去亲密的人和科技行业的从业者，除非他们就是目标用户。另外，测试者不能只局限于亲友。
5. 如果手头有用户的电子邮件列表，可以从中筛选测试者。营销团队可以帮我们缩小名单范围。
6. 可以通过公司的网站征集志愿者，主流的网站都这样做。但还需打电话联系并筛选应征者，避免参加测试的全是产品尝鲜者。
7. 建议较大的公司定期开展原型测试活动，每次邀请10-20位测试者参加。让所有产品经理自己申请时段，安排每位测试者参加测试1-2个原型。这样可以避免产品经理为寻找测试者分心。
8. 到街头巷尾、用户聚集的地方，让他们花个把小时测试产品。可以送些礼物表示谢意，注意放低身段。
9. 如果邀请测试者上门参加测试，尤其是出于商业目的，应该补偿测试者为此损失的时间。如果是大众网络服务产品，通常送上公司相关周边就够了。
10. 在测试前一天致电测试者，最大程度避免测试者爽约。

准备测试

测试环境

测试原型

更新原型

Ch23 · 改进现有产品

不是一味地添加功能

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

Ch24 · 平滑部署

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

作者把合理地、审慎地更新产品版本的行为成为“平滑部署”。

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

1. 加倍做好测试工作，避免新版本存在影响正常使用的隐患。比如可靠性、扩展性、性能问题。确保将来不会陷入被迫返回旧版本的窘境，为用户增加不必要的麻烦。
2. 如果更新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式来降低风险。

平滑部署的方式有很多，比如为旧版本提供支持期限，过渡发布。另一种方式是区域性逐步部署（在某个区域内部署新版本，然后逐步扩大范围），还有一种方式是增量部署（将更新项分割成几个较小的部分逐步发布）。

无论采用哪种处理方式，关键要全面考虑更新可能带来的“副作用”，为用户提供便利，方便他们在空闲时适应变化，同时尽可能降低新版本带来的负面影响。

优秀的产品和服务可以赢得用户的好感，这是宝贵的信任，应该小心保护。不要轻易试探用户的耐心，让好感变成反感。

Ch25 · 快速响应阶段

产品出炉后切莫虎头蛇尾

发布产品不等于大获全胜，交互产品后依然要保持高度警惕。

产品发布后，正是收集反馈信息、改进产品的最佳时机。急于“撤军”是项目管理和产品开发流程中的大忌，只要稍微延长项目周期，观察用户对产品的反应，效果就会有天壤之别。这样做投资小，汇报稿，绝非其他项目阶段可比。

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

评估产品表现应该使用明确的、可量化的指标。我们最关心产品哪方面的表现，是页面访问量、注册用户数、访问停留时间、会员转换率、订阅数、还是广告收益？具体使用哪些指标取决于产品的商业目标。应该给指标分出轻重缓急，并保持关注。此外，对于什么样的结果代表产品成功，什么样的结果代表失败，应该做到心中有数。

一旦问题反馈回来，产品团队应该至少每天召开一次短会，讨论问题的轻重缓急，确定最佳解决方案。

在快速响应阶段，客户服务人员、销售人员和合作伙伴的意见也不容忽视。

Ch26 · 合理运用敏捷方法

十大秘诀

尽管敏捷方法有许多优点，但这类方法源自定制软件领域，不完全适用于开发产品软件。

在这里将介绍适用于产品软件团队，而不适用于定制软件团队的敏捷方法。

1. 产品经理即是产品负责人，他代表了客户的需求，因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题。（如果产品经理和产品负责人不是由一个人担任，通常会埋下隐患。
2. 使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法替代冗长的市场需求文档。
3. 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保我们有足够的时间攻克难题。让交互设计师和视觉设计师提前设计产品，充分发挥他们主导设计的作用，不能一边设计一边开发。另外，始终让开发人员参与评估产品设计和产品原型，及时反馈关于可行性、成本、解决方案的建议。
4. 尽量把产品设计工作拆分成店里的部分，分而治之，但也不能拆得太细——好比设计建筑不能一次只设计一个房间。目标是设计出符合基本要求的产品。值得注意的是，在敏捷环境里，设计师必须加快工作进度，采用迅速制作原型的方法更能适应敏捷坏境。
5. 产品经理的主要任务是定义有价值、可用的产品原型和用户故事，作为开发的基础。用产品原型和用户故事替代厚厚的产品需求文档和功能说明文档有三个优势：①可以请用户测试；②强迫产品经理全面认真地思考问题；③向开发团队明确地描述每次迭代周期需要完成的任务。请用户测试原型，根据反馈意见反复迭代修改原型设计，确保交给开发团队的是有价值的结果，避免任何浪费，哪怕只是一个迭代周期。
6. 让开发人员自主划分迭代周期。有的功能可以在一个周期完成，有的却需要要几次迭代才能完成。
7. 产品经理和交互设计师必须出席每天的晨会。晨会是一天沟通过程的开始，而不是结束，关于产品的讨论会持续一整天。设计师向开发人员和测试人员展示产品功能；开发人员互相展示完成的代码，让测试人员测试，请设计师和产品经理过目；测试人员和开发人员在制作原型的阶段识别潜在的问题，协助产品经理制定更合理的决策，解决产品设计、开发的问题。
8. 除非达到了产品经理的要求，否则不要轻易发布新版本。产品经理必须确保交给用户的版本能正常运行。过度频繁更新版本会让用户感到不安。
9. 在每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型，让大家看到工作成果，同时加深大家对产品的理解，增强团队对这种开发方式的信心。
10. 在团队内展开敏捷培训。（可以聘请顾问，但要确保他理解产品软件与定制软件的差别。只有每位团队成员都真正理解敏捷方法，我们才能把工作重心放在执行上，否则敏捷方法就只能停留在理论层面。

迭代初期开发的产品不能用做原型。原因如下：

1. 用一个迭代周期来验证产品创意太长，不如用几天时间验证可更改的产品原型。
2. 在探索（定义）产品的阶段，开发团队还有许多重要工作要完成。这时占用他们的时间开发产品原型，会消耗他们开发正式产品的精力。
3. 一旦进入开发阶段，设计出软件架构后，再想改变产品设计思路，对开发团队来说，无论是成本还是难度都太高了。 

Ch27 · 合理运用瀑布式开发方法

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

Ch28 · 创业型公司的产品管理

关键在于产品探索

Ch29 · 大公司如何创新

有困难，但值得一试

20%法则

谷歌的程序员有20%的工作时间可以用来尝试创新研究。

20%法则鼓励普通员工自己尝试各种想法，发挥大家的主观能动性。

臭鼬工程

指在受限制的条件下，利用自己的时间，低调地进行创新研究。但创新研究的成果归属通常要看公司政策。

主动观察

观察和倾听是最简单的创新途径。仔细观察使用公司产品或同类产品的用户，想办法更好地满足他们的需求，再找一位熟悉技术的开发人员合作，我们就可以着手改进产品了。

注意，应该选择实际用户作为观察对象，不要选择产品尝鲜者，更不能选择公司同事。

创新不是发现新问题，而是用新方法解决已有的问题。观察人们对现有产品的不满，是创新的最佳途径。

改善用户体验

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

每款产品都有特定的实现模型，但用户脑子里装的是概念模型，他们对产品要解决的问题，以及如何解决问题有自己的想法。如果实现模型与用户的概念模型不一致，用户就会感到失望。找到用户失望的地方，就找到了创新，或至少是改善产品的机会。

收购小公司

建议大公司的产品经理多和业内活跃的创业型公司建立联系，互相帮助，互相学习。这种人脉关系也许能替公司节省上百万资金。

妥善安排收购来的新员工，让他们继续发挥特长，才能拓展产品线，保持市场领先地位。

Ch30 · 在大公司施展拳脚

十大秘诀

只要懂得利用资源，在大公司工作有明显的优势。

首先，大公司都遵循一条潜规则——尽量规避风险。其次，多数大公司都采取矩阵式的管理方式，核心部门（比如设计、开发、测试、运维、市场部门等）是共享资源，产品经理要确保争取到足够的资源才能研发出产品。

理解这两点后，提出几点在大公司施展拳脚的方法：

1. 了解公司制定决策的方式。 每家公司企业文化不同，制定决策的方式也不同，要学会融入其中。知道决策权在谁手里，我们的工作目标就很明确了。了解他制定决策的方式，他更看重原型演示、市场数据，还是客户的承诺和评价。如果我们需要公司的支持，只需要说服他就行了。
2. 建立人脉网络。在大公司必须与人合作，我们需要同事的协助才能完成设计、开发、发布工作。主动与各个部门的同事结交朋友，聊聊工作的事，向大家介绍我们手头的项目，不要等到有事才去找人家。主动帮助他人，积累人脉关系。
3. 臭鼬工程。找三五个志趣相投的同事在工作之余做出产品原型来。产品原型具有超出想象的说服效果。比起枯燥的陈述，生动形象的演示更有吸引力。数不清的优秀产品是这样诞生的。
4. 自己顶上。大公司虽然员工众多，但真正需要帮手的时候却总找不到人。即便是公司高管重视的项目，也难免资源不齐。遇到这种情况，我们就得自己想办法了。实在不行，就得自己顶上。一切为了推出产品，不要计较个人得失。
5. 有选择地据理力争。在大公司工作，多一敌不如多一友。如果我们不满意同事的工作，或与他人意见不同，不要随便发脾气，除非这件事对我们确实重要，值得我们据理力争，撕破脸也在所不惜。与人辩论要小心措辞，不要把人逼到死角。我们的目标是完成产品，别为了一场战役输掉整场战争。
6. 会前沟通，形成默契。如果有人在重要的决策会议上，公开反对我们的提议，我们会变得非常被动。设法在会前达成一致意见。会议的主要作用是让与会者认识到大家取得了一致意见，所以会前应该逐一找与会者聊聊，了解每个人的立场。如果有不同意见，对症下药及时化解，确保他们会投赞成票。
7. 合理分配时间。大公司频繁开会，有些人忙得不可开交，产品却毫无起色。产品经理应该重新检查会议日程，划掉无关紧要的会议，学会充分信任同事，让他们自己拿主意，产品经理应该留时间完成自己的本职工作：制定产品战略，构思产品路线图，研究产品原型，分析竞争对手。
8. 分享信息。有舍才有得，分享信息会让我们获得更多的朋友和资源，作为交换，别人也会毫无保留地分享信息给我们。充分共享信息对我们自己和公司都有好处，这叫共赢。
9. 向上司借力。学会利用上司的关系，可以更好地开展工作。利用他的人脉关系，传播我们的理念。多向他请教，了解公司文化和组织结构。如果需要上司出面说服公司高管，我们一定要事前做好充分的准备，为他提供翔实可靠的资料和信息，用实力取得他的信任，让他放心地当我们的说客。
10. 传播我们的产品理念。 多向同事传播我们的产品理念，向大家描绘产品愿景，介绍产品策略，演示产品原型，分享用户反馈信息。不要低估了内部宣传潜移默化的作用。让大家（包括没有直接业务联系的部门同事）不遗余力地支持我们。

不可否认，在大公司里工作得克服重重障碍，为产品争取支持和资源实属不易，但大公司也有大公司的优点，产品会获得媒体和用户的高度关注，这是小公司望尘莫及的。一旦我们掌握了充分利用大公司资源的方法，将会如鱼得水。

Part3 产品

Ch31 · 苹果公司给我的启示

另类的硬件公司

作者认为在苹果公司值得学习的经验中，以下四点最重要：

1. 硬件为软件服务。软件直接服务用户，满足用户需求。采用多点触控显示屏、重力加速器、距离传感器这些硬件技术是为了配合软件满足用户需求，而不是花哨的噱头。仅凭华丽的硬件技术和软件效果无法真正吸引用户，一旦消费者过了尝鲜的阶段，就会对产品失去兴趣。
2. 软件为用户体验服务。苹果公司的所有工作都围绕着产品可用性、交互设计、视觉设计、工业设计展开。公司各个部门不遗余力地支持用户体验设计，苹果公司明白用户体验是产品立足之本。
3. 用户体验为情感服务。苹果公司比谁都清楚是什么让消费者为产品疯狂，他们知道怎样抓住用户的情感需求。人人都想拥有一台iphone，对比其他的手机和品牌电脑，前者像是宝马，后者像是租来的二手车。
4. 产品为真正的需求服务。手机并非苹果公司首创，但他们挖掘出了尚未被满足的用户需求。市面上的手机品种成百上千，十几年不变的语音邮件系统，不兼容的地址簿，蹩脚的网页浏览器和电子邮箱，只会让用户抓狂。苹果公司逐一完善这些功能，成功的产品应运而生。

Ch32 · 提防有特殊要求的产品

避免陷入困境

如：销售代表向CEO转达客户的提议，要求产品增加七项功能，否则拒绝购买产品。

这种特例产品到底有什么问题呢？它混淆了客户需求和产品需求，必然会使公司偏离正轨。

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

即便不存在以上问题，产品经理也不宜把工作重心放在特例产品上。耗费精力添加特殊功能，必然会耽误更重要的工作，带来的长远损失并非这点蝇头小利所能填补。

退一步讲，即使以上问题都可以解决，特丽产品的风险仍然不能忽视。因为产品经理的任务是满足大众的需求——这是产品公司和定制软件公司的区别。如果一年后市场需求发生变化，产品必须快速应对。签订合约后，产品就被合同绑住了，难以应变，最后会让公司不堪重负。

但并非贬低定制软件公司，只因商业产品软件和定制软件完全是两码事。

为回避特例产品可能带来的危害，公司应该根据企业文化树立自己的产品原则，关键时刻根据产品原则决定是否接受客户提出的特殊要求。

无论是企业软件还是网络服务，产品经理都确保开发出来的产品是有价值的，尽可能满足更多用户的需求。

Ch33 · 新瓶装老酒

新技术层出不穷

成功的产品往往不是什么新鲜事物，只是新瓶装老酒，之所以成功，是因为这个“新瓶”做得更好、更方便、更便宜，改变了消费者对“老酒”的印象。

如：谷歌在搜索引擎市场几近饱和的情况下入驻搜索领域。苹果在市场上有上百种MP3播放器的情况下，用iPod引领市场潮流。

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

1. 对目标市场了如指掌，对鲜有产品的缺陷洞若观火。可以通过产品可用性测试掌握产品情况（包括自己的产品和竞争对手的产品）。
2. 跟踪最新的技术趋势。新技术层出不穷，让之前无法实现的方案变得可能。虽然谁都没有把握永远走在技术的前列，把最新的技术融入产品设计中，但是只要做到一次，我们的产品将所向披靡。

优秀的产品经理应该抓住现有技术与用户需求的契合点。市场机遇无处不在，我们需要做的就是挖掘需求，运用新技术解决用户的老问题。

Ch34 · 恐惧、贪婪、欲望

产品中情感的作用

消费者购买产品大多源于情感需求。企业级消费者出于恐惧和贪婪购买产品：如果不买，竞争对手会超过我，黑客会攻破我的防火墙、客户将弃我而去；如果买了，我会赚得更多、省得更多。

大众消费者购买产品的原因更多样化：使用这款产品，就有机会交到朋友（化解孤独），或者找到约会对象（满足爱的需求），或者大挣一笔，或者展示我的照片和音乐（满足自豪感）。

只有从情感的角度重新观察市场上的产品和服务，我们才能体会用户真实的感受。同一产品，不同类型的用户还有这不同的情感需求。

每次开展原型测试，除了观察测试者是否能顺利使用产品外，还应该趁机了解测试者的情感需求（是什么驱动他使用产品），怎样才能更好地满足他的情感需求。

明确目标用户情感需求后，问问自己谁还能满足用户的这种需求，他们才是我们真正的竞争对手。许多情况下，我们的竞争对手不是创业型公司或大型门户网站，而是大众的线下生活方式。

Ch35 · 情感接纳曲线

技术接纳曲线模型从技术角度描述了消费者对待产品的态度，但是它还不足以解释消费者的行为。所以，可以用情感接纳曲线模型对它的分类法进行补充。

根据消费者的情感特征，可以把他们分为：

• 技术爱好者（即技术创新者）：他们购买产品，仅仅因为产品采用了新技术。这类消费者容易误导产品经理，因为他们的需求与普通大众的不同。他们对技术本身很痴迷。
• 非理性消费者（即尝鲜者）：他们的情感需求与大众的相同，但是更强烈。愤怒、恐惧、孤独这类消极情绪被放大后，会导致非理性的消费行为。在生活中，非理性消费者为了满足情感需求，会付出大大超出解决问题本身所需要的精力和成本。
• 普通大众：具有和非理性消费者同样的情感需求，只是在程度上没有那么强烈。随着产品的完善，他们也会逐步加入消费队伍。
• 理性消费者（即早期消费大众）：只会购买他们认为实用、成熟的产品。他们更务实，只会购买性价比合适的产品。
• 超理性消费者（即后期消费大众）：他们的情感需求更弱，哪怕产品有半点不合意，他们都不会掏钱。
• 观望者（即跟随者）：约占总人数的15%，他们同样有需求，但只会购买公认好用的产品。

在这几类人中，非理性消费者最值得产品经理注意，技术爱好者是最没有参考价值的人群。

非理性消费是对不满情绪的过度反应，是放大后的情感需求在“作祟”。非理性消费者夸大了产品的价值，产品经理如果深入了解他们的想法和感受，就能抓住这种情感需求。

非理性消费者能帮助产品经理发现产品的内在价值。他们内心弥漫着强烈的不满情绪，这种情绪可能会慢慢减弱，但不会小时。技术爱好者并不关心产品要解决的问题，吸引他们的是产品采用的新技术。

Ch36 · 可用性与美感

两者缺一不可

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

Ch37 · 大众网络服务与产品

十大要点

作者总结了十条管理大众网络服务产品的要点，这些经验适用范围包括电子商务、社交网络、搜索引擎、网络游戏。

1. 可用性。大众网络服务产品必须具备良好的用户体验。如果用户不清楚怎样使用产品，或者产品性能很差（产品性能是最重要的一条可用性指标），页面加载缓慢到让用户无法接受，公司都无法成功盈利。
2. 人物角色。
3. 扩展性。激增的用户数量会带来莫名其妙的问题。实现扩展性需要产品经理、设计人员、开发人员、运维人员的通力协作。最好利用部分开发资源和运维资源专门为系统扩展做好准备，留有余地，不到万不得已不要满负载运行。
4. 持续可用性。大众网络服务要求一刻也不能停歇。系统终止服务是件痛苦的事，但是系统出故障的时间却不确定。在系统设计上保证持续可用性与规划扩展性一样重要。
5. 客户服务。传统的客户服务无法应对数量庞大的网络用户，收费的网络服务情况更严重。要想降低客服压力，除了尽量减少系统故障和缺陷外别无他法。
6. 保护用户隐私。应尽早树立保护用户隐私的意识，设置用户资料保护机制，千万不能辜负用户对我们的信任。
7. 口碑营销。如果用户喜欢产品，就会主动向家人、朋友、同事推荐。这是宣传产品的最佳方式。建议为用户提供便利，方便他们向熟人推荐产品。
8. 全球化。易于本地化的产品设计可以大大节省开发成本和开发时间，避免为了语言、货币、文化差异大量改写程序。这样随着产品业务的拓展，我们可以迅速适应当地用户的需求。
9. 平滑部署。网站用户数量过百万后，任何小小的变化都会影响大面积的用户，要三思而行。除了逐步过渡，为用户留出足够的时间来适应变化，还要尽量减少不必要的更新。用户小花、吸收新事物不是件容易的事。
10. 用户社区管理。如果用户认可我们的产品，他们会很乐意成为用户社区的一员，同时希望得到重视和认可。与用户交流的方法有很多，多和他们接触，了解他们希望如何改进产品。多用类似于“回馈用户”的活动表达对他们的重视。让公司上下认识到用户的重要性，真正从行动上把用户当上帝。

处理好以上十个问题，打造大众网络服务的过程会轻松许多。

Ch38 · 打造企业级产品的经验

十大要点

介绍了打造企业基础软件和企业应用软件的方法。

Ch39 · 打造平台产品的经验

最具挑战性的工作

所谓平台产品，是指一类基础软件，应用开发者能在其基础上开发应用程序。平台有很多种，例如，操作系统（Windows、Mac、Android)、运行环境（Java、Flash）、web服务（亚马逊和eBay的集成应用程序接口）、游戏开发平台，以及应用平台（Facebook）。

这种工作的艰难在于要面对三种不同的客户：

1. 应用软件供应商 选择你的平台创建解决方案的公司；关心平台开发商的生存能力，如果我们的公司突然破产，或不再为平台产品提供技术支持，让他们的业务受牵连。此外，他们还关心平台产品的定价、认证情况、产品质量、技术支持能力，以及将产品国际化的难易程度等。
2. 开发人员 应用软件供应商的雇员，由他们在平台上开发应用软件；关心平台产品是否支持自己惯用的编程语言、开发工具、基础架构，希望迅速、便利地开发出性能好、可靠性高的应用。
3. 终端用户 应用软件的使用者，也是平台服务的真正使用者。只在意最终结果。如果平台产品上没有需要的功能和服务，或者功能和服务和想象的不吻合，他们就不会掏钱，应用软件供应商就无利可图。

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

很多产品经理忽略终端用户的需求，把开发人员摆在第一位，这是普遍存在的误区。实际上，只有让终端用户满意，平台产品才是成功的。

管理平台产品还有其他的困难：没有统一的交付形式（嵌入式产品、自有品牌、联合品牌、托管服务等）；客户的定制要求多种多样。技术支持是管理平台产品的另一个难点。客户是我们赖以生存的根本，因此必须提高技术支持的服务能力和服务水平。

尽管管理平台有很多难点，但平台产品的潜在能量巨大，如果能够妥善处理以上这些问题，围绕产品会形成一个繁荣生态系统，实现各方共赢的局面。

总结

Ch40 · 最佳实践经验

十大要点

1. 产品管理的职责。不要把大把时间浪费在与产品管理无关的工作，如营销管理和项目管理上。这些都不是产品经理该干的活。
2. 用户体验。 对大多数软件产品来说，用户体验就是生命。
3. 机会评估。用方便快捷的机会评估方法取代过时的市场需求文档。动手设计产品前，先明确产品要解决什么问题，为谁解决问题，以及评估产品的标准。
4. 特约用户。打造优秀的产品没有任何捷径，只能请用户反复试用产品，不断改进。
5. 产品原则。产品管理工作的主要内容是制定决策。明确的产品原则可以帮助产品经理和产品团队树立清晰的价值标准，作出果断的决策。
6. 人物角色。人物角色是协助产品经理制定决策的另一项工具。
7. 探索（定义）产品。产品经理的主要职责是探索（定义）有价值的、可用的、可行的产品。
8. 使用原型。使用高保真原型是探索（定义）产品的关键步骤。
9. 用户参与原型测试。有了产品原型，产品经理可以方便地请用户验证产品创意。
10. 根据数据改进产品。改进产品不是根据客户要求一味增加新功能，而是根据产品的实际应用情况，不断地提升产品的各项指标，逐步完善产品。

Ch41 · 产品经理的反省清单

十大问题

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

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