【书摘】启示录：打造用户喜爱的产品

这本书基本上说清楚了打造好产品的方方面面，很值得一看。

我们汲取了深刻教训：如果开发的产品没有市场价值，那么无论开发团队多么优秀也无济于事。不仅如此，我们认识到仅仅做出产品并不够，还要确认产品是有价值的、可用的、可行的。

从担任网景高级产品经理开始，我的日常工作明确分为三块：人员、流程、产品。

人员是指负责定义和开发产品的团队成员的角色和职责。
流程是指探索、开发富有创意的产品时，反复应用的步骤和成功的实践经验。
产品是指富有创意的产品具有的鲜明特性。

这三个部分是探索和开发用户喜爱的产品必不可少的。项目都是由人完成的，流程则保证大家持续开发出用户喜爱的产品。

我从不认为富有创意的产品来自偶然。成功的产品都遵循一定的规律。以下是我总结的十条规律。

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

关键角色及其职责

产品经理的主要职责分为两项：评估产品机会（product opportunity）；定义要开发的产品。

产品创意的来源很多，比如，公司高管的意见、用户的反馈、可用性测试的结果、产品团队和营销团队的点子、业内人士的分析等。应该有人严格审核这些创意，判断是否值得采纳。产品经理就是负责这项评估的人。许多公司借助市场需求文档（market requirements document，MRD）来完成这项工作。我更愿意使用一种简化的方法，我称之为机会评估（opportunity assessment）。

确定有价值且符合公司发展要求的产品机会后，还需要探索产品的解决方案，包括基本的产品特征和功能、产品的用户体验、产品的发布标准。这些也属于产品经理的工作范畴，而且是产品经理的核心职责。有些公司借助产品需求文档（product requirements document，PRD）来完成这项工作，也有人称其为产品说明文档或功能说明文档。同样，我主张采用简化的文档，围绕产品原型来展开这项工作。注意，文档应该清晰地描述产品的功能和属性，避免讨论产品的实现方法。

用户体验设计团队由多种角色组成，稍后我会详细说明。这里只谈谈最关键的角色——交互设计师（也称为信息架构师、用户界面设计师、用户体验架构师）。交互设计师负责深入理解目标用户，设计有价值的、可用的功能，以及用户导航和产品使用流程。交互设计师与产品经理密切合作，将功能与设计相结合，满足用户需求。目标是确保产品同时具有可用性和价值（可用性指的是用户明白如何使用产品，价值指的是用户对产品的渴求程度）。

产品经理完成产品定义后，开发团队承接项目，开始开发产品。项目管理的核心任务是制订计划和跟踪进度。项目管理工作常常由不同的角色承担，可能由专职的项目经理操刀，也可能由开发经理兼任（因为开发团队占有大部分项目资源），还可能由产品经理披挂上阵。这通常取决于公司文化和项目规模。规模较大的项目最好安排经验丰富的专职项目经理管理。

软件工程师也称为产品开发人员或软件开发人员，负责开发产品。开发团队在有些公司被称为IT（信息技术）团队。注意不要混淆这两个概念，区分的关键是看他们是为顾客开发软件，还是为公司内部（如人力资源部门）开发软件。IT团队通常指的是为内部员工提供技术支持的团队，而开发团队指的是为外部客户开发和维护产品的团队。

互联网服务产品通常运行在服务器上，用户通过web访问服务。运维团队负责保证服务正常运行。虽然有些公司将这项任务交给开发团队负责，但是运维工作需要一系列专业技能，很难由开发团队单独承担。

产品营销团队负责对外发布信息、宣传产品，为拓展市场销售渠道、组织重点营销活动（如在线营销）、促进产品销售提供支持。有些公司让一个人同时负责产品管理（产品定义）和产品营销。这两项工作内容相差很大，这样做实在不明智。

顺便提一下，微软把负责制定产品说明文档和管理项目进度的人称为项目经理（program manager）。由于这些“可怜”的人要同时应付多个项目，因此业界现在已经习惯用这个头衔称呼同时管理多个项目的管理人员。在微软，产品经理指的是那些负责产品营销的人。虽然我不喜欢微软对这两个头衔的用法，但我认为他们定义产品的工作做得非常棒。

产品管理与产品营销

产品经理负责详细定义待开发的产品，让真实的用户测试产品。产品营销人员负责向外界宣传和推广产品，负责产品发布，为拓展市场销售渠道、组织重点营销活动（如在线营销）、促进产品销售提供支持。

产品管理与项目管理

有些项目经理以为管理能力等同于使用微软Project软件的能力，他们没有领悟项目管理的真谛。以下是我从琳·丽迪这样优秀的项目经理身上总结出的七个特点。

工作紧迫感

只要琳走进房间，立刻就能传达给大家一种紧迫感。每次会议大约60秒闲话开场白后，马上转入正题。这种效果表面看来是因为她独特的身体语言和气质，但事实上，紧迫感和高效率是eBay企业文化的核心，而且已经升华为琳人格的一部分。

善于捕捉问题

有无数原因导致会议效率低下、毫无建设性，其中最主要的原因是会议目的不明确，不清楚要解决什么问题，也不知道难点在哪。优秀的项目经理能够迅速地、准确地指出问题及其要害，改善会议效果。

思路清晰

引发典型业务问题的原因多种多样，比如政治因素、日程安排有冲突、同事个性不合等，如果置之不理，稍作拖延就会导致整个项目一团糟。项目经理需要排除感情因素，放下思想包袱，拨云见日，把待解决的问题逐一独立分离出来，分配给每位同事，专注解决。

用数据说话

优秀的项目经理明白数据的重要性，懂得利用数据识别项目方向，确认项目进度。他们知道改善产品和开发流程必须从测量、收集数据开始。在时间紧迫的情况下，最容易仅凭直觉草率行事。为避免出现这种情况，项目经理务必坚持根据数据和事实制定决策。

果断

在多数公司里，产品团队成员不必向项目经理汇报工作，但项目经理必须驱动同事作出决策。项目经理必须向大家传达一种紧迫感，及时向团队收集数据和建议，适时向上级部门汇报情况，把问题理顺，用理性的思路和清晰的理由帮助大家，利用数据作出决策。

判断力

以上这些特点都基于良好的判断力。项目经理必须清楚何时催促进度，何时向上级汇报，何时需要收集更多信息，何时找个别成员私下交流。判断力很难言传身教，只能靠自己积累经验获得。

态度

如果产品不能按时交付，我们总能听到各种理由：可行性太差、资源不足、时间不够、资金匮乏等等。项目经理绝不能为自己找借口，必须克服所有障碍，解决所有问题，一往无前、愈挫愈勇，直到梦想成真。

产品管理与产品设计

好产品必须提供舒适的用户体验。舒适的用户体验是产品管理和用户体验设计共同作用的结果。这是个很大的话题，我们先从了解设计包括哪些角色、分工开始。这里我给出与用户体验设计密切相关的分工。注意我描述的是工作角色而不是个人，因为有的人可能承担多项工作。

用户研究

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

交互设计

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

视觉设计

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

原型制作

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

对大型产品（尤其是大众互联网服务）来说，这四种角色缺一不可。开发企业级应用软件的公司如果想从众多竞争对手中脱颖而出，最简单的办法是提供优秀的用户体验。用户体验是大部分企业级产品的弱项。对小型产品来说，可以让一位设计师身兼多职。例如，我最近与一家创业型公司合作，开发针对大众的Web 2.0服务。对方只有三个人：一位产品经理、一位交互设计师（同时负责用户研究）、一位视觉设计师（同时负责开发原型）。他们的工作非常出色，很快就拿出了可供目标用户测试的产品原型。

很多公司希望改善产品的用户体验，把用户体验设计外包给设计公司。这在一定程度上是可行的，但是有些工作不适合外包。例如，我认为交互设计不能外包，原因如下。

深入理解用户需求非常费时间，需要多个项目的经验积累。设计公司没时间深入了解客户需求，就算他们做到了，这些经验也很难保存下来，用到下一个版本里。
交互设计师必须现场深度参与项目开发，从立项直到产品发布。开发和测试过程中会出现各种细节问题，必须有一名交互设计师迅速作出决定。
产品的用户体验是公司的核心竞争力，必须在内部完成。如果让我选择，质量检验更适合外包。只要团队中有一位称职的交互设计师，视觉设计也可以外包，毕竟视觉设计公司很多，完全可以满足需求。此外，用户研究和可用性测试也可以外包，只是成本较高，对我这种重视测试反馈（参考第22章）的人来说更是如此，所以我建议让产品经理和交互设计师分担这项工作。

产品管理与软件开发

产品经理负责定义产品方案；开发团队最了解哪些产品构思是可行的，他们负责产品的开发与实现。作为产品经理，你很快能体会到，只有与开发团队融洽合作，才有可能开发出合格的产品；否则等待你的将是一段漫长、难挨的日子。形成合作关系的关键是双方承认彼此平等——任何一方不从属于另一方。产品经理负责定义正确的产品，开发团队负责正确地开发产品，双方相互依赖。你要求开发团队完成任务，必须先取得他们的认可，确信为了达到产品质量标准必须这么做；开发团队也要留给你足够的空间，设计有价值、可用的产品。

开发人员帮助产品经理完善产品定义的方式有如下三种。

让开发人员直接面对用户或顾客，体会用户的困惑和疑虑，了解问题的严重性，这样好点子常常会随之而来，譬如，可以邀请一名开发人员参加产品原型测试。
向开发人员了解最新的技术发展动向，讨论哪些新技术可以用到产品里。开展头脑风暴，看看目前已实现的技术或即将实现的技术能不能解决手头的问题。
让开发人员在探索（定义）产品的初期阶段参与评估产品设计，协助策划方案。产品经理常犯一类错误，即完成产品定义后，便扔给开发团队，置之不理。这样做只会贻误协调需求与可行性的最佳时机，等到发现问题时，为时已晚。

同样，产品经理也应该配合开发人员的工作，方式如下。

产品经理只定义满足基本要求的产品。产品经理应该意识到，自己要定义的不是最终产品，而是满足基本要求的产品。只有这样，产品管理与软件开发之间才能形成良好的互动。
一旦产品进入开发阶段，要尽可能避免修改产品的需求和设计。虽然有些事情超出你的控制范围，导致项目波动是不可避免的（开发人员也能理解），但是千万不要在此时尝试突发奇想的点子。
产品开发阶段难免会产生诸多问题，比如，用例丢失，用例设计考虑不周全等，这很正常，最优秀的团队也避免不了。产品经理应该迅速采取行动，在维持产品基本功能、尽量避免修改的原则上，拿出解决方案。

与开发团队合作应该遵循以下原则：在产品管理上为开发团队预留20%的自主时间，让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统性能，避免“需要停下来重写代码”的情形发生。

如果你的糟糕处境已经初现端倪，就应该拿出至少20%的资源进行调整。我担心有些团队连20%都不愿意拿出来。如果你已经身陷重写代码的困境，说明公司危在旦夕，这里给出一点建议供你参考。

第一，针对开发团队确定的产品修改目标制订切实可行的计划和时间表。通常，有经验的开发团队估计的开发时间八九不离十，但是重写代码是例外，因为多数团队没有重写代码的实际经验，估计往往过于乐观。你必须审时度势，仔细检查每处细节，确保计划切实可行。

第二，只要有可能，最好把重写目标分成几大块，实现递增修改，让用户感受到产品的改进，哪怕会因此把九个月的工作时间延长至两年，也一定要采用这种方式。重写代码时，保证让用户看到功能的改进——即使会占用少则25%，多则50%的开发资源——对保持产品（尤其是互联网产品）的市场占有率至关重要。

第三，由于开发用户可见功能的资源有限，必须谨慎选择正确的产品特性，确保产品定义的正确性。

招聘产品经理

个人素质和态度

技术可以学习，素质却难以培养，有些素质是成功的产品经理必不可少的。

对产品的热情

有这样一群人，他们对产品有一种本能的热爱，把自己生活中的一切事物都看成产品，怀揣对优秀的产品的热爱和尊重。这份热情是产品经理必备的素质，是他们夜以继日克服困难、完善产品的动力。这份热情能感染团队成员，激励所有人。

用户立场

理想的产品经理不一定来自产品的目标市场（这种情况有利也有弊），但是他必须融入目标市场。这一特质对制造大众产品的高科技企业尤为难得。我们倾向于从自己的角度去理解用户和市场。事实上，目标用户的经验、喜好、价值观、知觉能力、忍受程度、技术理解很可能与我们的大相径庭。

智力

人的智力水平是无法替换的。产品管理需要洞察力和判断力，因此必须具备敏锐的头脑。勤奋当然是必需的，但从事这项工作光有勤奋还远远不够。

职业操守

每种团队角色承担的义务和付出的努力都不相同。产品经理肩负着产品的前途和命运，绝不适合贪图安逸的人担任。即便掌握了时间管理和产品管理的技巧，产品经理依然要为产品投入大量精力。成功的产品经理能拥有时间享受清闲的家庭生活吗？只要具备足够的经验，我相信可以做到。但是，如果你期望的是一周只工作四十个小时，下班后把工作抛诸脑后，那是不现实的。

正直

在所有产品团队成员里，产品经理最能体现公司和产品的价值观。通常产品经理不直接管理团队成员，不能要求别人执行命令，所以他必须通过行动影响、说服身边的同事。这种影响基于相互的信任和尊重，要求产品经理必须是个正直的人。

信心

很多人相信经验可以让人产生自信。如果仅凭经验可以建立信心，为什么许多工作多年的产品经理却毫无自信？相反，刚刚步入社会的大学毕业生却往往充满自信（虽然这种自信通常源自对自身状况的无知）。自信是很重要的素质。公司高管、产品团队、销售团队都需要看到产品经理的信心，确信他们投入的时间、金钱、努力不会付之东流。自信的人更有说服力，更容易成为人们愿意追随的领导者。

态度

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

技能

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

运用技术的能力

很多成功的产品经理是工程师出身，因为策划产品在很大程度上取决于对新技术的理解，以及如何应用技术解决相关的问题。出色的产品经理并不需要自己发明或实现新技术，但必须有能力理解技术，发掘技术的应用潜力。

注意力

产品经理要优先解决重要问题。研发产品的过程中有很多干扰。能否集中注意力解决关键问题、克制不断增加功能的冲动、不受关键人物或重要客户的影响，取决于产品经理是否有足够强的自律性——不但要遵守公司制度，还要严格要求自己。

时间管理

电子邮件、即时消息和手机构成的世界充满了干扰。你可能一大早就来上班，拼命工作一整天，连吃饭喝水都顾不上，深夜回到家却发现到头来没完成一件重要工作。时间都用来“救火”和处理“紧急”事件了。熟练、迅速地区分重要任务和紧急任务，合理地规划和安排时间是产品经理必备的技能。如果产品经理无法集中精力完成真正重要的任务，那产品就难免命运多舛了。

沟通技能

虽然沟通技巧可以学习，但要做到出类拔萃需要经年累月的练习。沟通（包括口头表达和书面表达）能力是产品经理必备的技能，如前所述，产品经理只能以理服人，绝不能靠职位压制他人。口头表达能力可以在面试中测试，测试书面表达能力则需另寻他法。我常建议应聘者随身携带文字材料证明其书面表达能力，比如，不涉及专利的产品策划文档。

商业技能

作为产品团队的发言人，产品经理要协调团队与财务部门、营销部门、销售团队、公司高管之间的工作——必须使用这些人听得懂的概念和术语。我认为产品经理应该具备双语技能。这并非指中文和英文，而是指产品经理既能与程序员讨论技术，又能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌。

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

巴顿将军的忠告

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

优秀的用户体验设计师，特别是交互设计师可谓凤毛麟角。如果你发现了这样的人选，就一定要给予足够的创作空间，充分发挥其才能，使设计师成为产品团队的重要组成部分，让他们探索各种设计方案，倾听他们分析用户的行为和喜好。

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

产品副经理

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

产品经理还可以向自己的领导借力，听取他们对产品的建议，虽然他们不太可能参与具体工作，但并不表示他们会袖手旁观。你需要的帮手可能隐身于公司各处——开发部门、销售部门、客户服务部门，甚至董事会。如何发现他们呢？

打听！多问问同事，肯定会有收获。
采用走动式管理模式。这源于惠普的做法。管理者要走出自己的办公室和圈子，花时间与员工相处。
认真倾听与会者的对话与发言。
敞开办公室的门，让大家知道你随时欢迎他们向你提出产品建议。
坦率地把你的烦恼告诉同事，大家会热情地帮助你。
一起泡吧。工作之余，产品经理总是与产品经理一起消遣，高管总是与高管为伍，这是司空见惯的事。如果你能抽出时间与普通员工一起休息、娱乐，一定能发现“埋在沙里的金子”。

管理上司

下面我介绍管理上司的十条经验。

为项目波动做好准备我用项目波动代指让你心烦意乱的各种返工、计划变更。不要企图消灭项目波动，但是可以尽量降低其负面影响。方法是提高警惕，记录工作进度，比如，记录每周、每月、每季度有多少时间项目在往前推进，掌握项目波动的规律，寻找对策。制订项目计划时，预留出时间应对变化和调整，做好“做无用功”的心理准备。这个方法不仅能缓解压力，提高计划的准确度，还有助于挖掘有待改善的细节。
注意沟通的方式与频率千人千面，管理者也不例外的。有些管理者喜欢事无巨细亲力亲为；有些则希望尽量不被打扰。有些喜欢你用邮件介绍工作进展；有些则喜欢简短的口头汇报。弄清上司的喜好，对症下药。
会前沟通很多公司频繁开会。公司的高管、股东越多，汇报进度和评估工作的会议就越多。为了让大家了解进展，必须确保人人到场。组织好会议的诀窍是在正式会议召开前充分沟通，即在会前逐一会见与会的高管和股东，提出你的观点，征询他们的意见，确保会议召开前你们已经达成一致意见。如果会前沟通顺利，可以大大缩短正式会议的时间，结果也将毫无悬念。正式会议的作用只是让与会人员认识到大家取得了一致意见。
多提建议，少谈问题管理者希望听到解决问题的方法，而不是听你报怨。最好根据问题的重要性列举出多种解决方案，并附上你的依据和建议。
向上司借力许多员工不懂得向上司借力。假如你通过分析得出了解决方案，公司高管没有时间与你进行会前沟通，但你的上司能找到机会与他们交流，你可以把想法告诉上司，请他帮你转达建议。上司也想尽早结束会议，因而会乐于帮你。
充分准备管理者通常聪明过人，能够立马发现你思路和计划上的漏洞。你最好准备充分，弄清问题所在，做到有备无患。
缩短邮件篇幅产品经理喜欢写长篇的邮件向上司汇报工作，这是大忌。上司每天可能会收到上百封邮件，他更希望用简明扼要的方式进行交流。收件人的级别越高，邮件的篇幅就该越短。你可以添加附件，但不要让正文篇幅过长。
多用数据和事实说话与上司（尤其是高管）打交道时，务必要提供数据和事实。网景公司前CEO吉姆·巴克斯德尔（Jim Barksdale）说过一句名言：如果我们依照个人看法来做决定，那就是臆断。多做准备工作，收集事实和数据，你的建议才有说服力。
内部宣传向公司同事宣传产品，让大家认可你的工作，乐于帮助你。充分、有效的宣传，可以大大降低与其他部门合作的成本。
做让领导省心的员工管理者的工作是保证团队高效运作，他们时间有限。不要劳烦你的上司做你的导师，但可以在你的直接管理层外另寻导师。思考如何节省上司的时间，你会获益匪浅。

评估产品机会

市场给予新产品诸多机会，即使成熟的市场也不例外。因为市场环境充满变数：竞争对手不断被淘汰，新技术、新创意不断涌现……产品经理必须用他灵敏的“嗅觉”，从纷至沓来的机遇中迅速评估、挑选出有市场潜力、可行的创意，过滤那些没有价值或时机尚不成熟的点子。

为了评估产品机会，我要求产品经理回答如下十个问题。

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

开发新产品能为老用户提供更多选择，还能吸纳新用户；改善原有产品能提高老用户的满意度，也能吸纳新用户。两者各有千秋。

产品探索

管理层坚持给产品探索设定期限，主要有如下原因。

探索产品的过程不可预测。管理层担心花几个月研究解决方案，最后却做不出产品，而如果按计划进入开发阶段，至少有事可做。
开发人员是紧缺资源，开发团队无事可做会让管理层抓狂。问题是，这反而导致开发资源被浪费。不管大家意识到没有，所有的公司都会执行探索产品的流程，只不过有些公司不是利用产品原型完成这项工作，而是孤注一掷，用实际产品搭上全部开发时间进行产品探索。他们开发的是一款非常昂贵的原型，让不知情的用户掏钱参与原型测试。这些公司需要一两年时间（发布几个版本）才能赢利。

产品原则

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

每次加入新团队，我要做的第一件事就是制定产品原则。制定产品原则意味着决定什么重要、什么不重要，哪些原则是根本的、战略性的，哪些是临时的、战术性的。产品原则不是产品功能的清单，不依赖于任何单独的产品，它是整个产品线的战略指南，是公司的价值宣言。好的产品原则甚至可以激发设计产品的灵感。制定产品原则的过程也是学习的过程，我可以从中了解新公司的企业文化，以及公司创始人设立的企业目标。产品原则是一套价值判断的框架，帮助公司作出正确的决策。

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

不少产品经理向我抱怨说，他们受够了没完没了的会议（既无议程也无结果），以及会议中的那些争论、冲突。公司高管还时不时打断会议进程，扔下没头没脑的意见，然后拂袖而去，留下他们丈二和尚摸不着头脑。这种情况在产品决策过程中经常发生，原因主要有以下几点：第一，每位同事对公司的产品都有自己的看法；第二，大家都非常在乎产品，明白公司营利得靠用户，只有产品才能吸引用户；第三，许多人以为自己比其他人了解目标用户，事实上并非如此。

务必认真分析产品目标的优先级（从最重要到最不重要逐项排序），让团队达成共识。切不可囫囵吞枣地把所有目标都贴上“关键”和“重要”的标签。一定要区分什么最重要，什么第二重要…… 我常被请去解决产品决策中出现的争议，我发现，多数团队跳过了这关键的一步。由于缺少基本评估标准，每个人对目标和优先级的理解都不同，大家往往情绪激动，在细枝末节上争执不下。

即使大家已经达成共识，也应该在讨论开始前再次予以强调，最好把目标按优先级顺序写在白板上，这样每位同事都可以看到评估方案和制定决策的确切依据。制定决策的过程和依据必须完全透明，不要让人觉得你只凭直觉判断。务必告诉大家决策的依据和理由，清楚地展示每一个决策环节。激烈的会议争论会影响大伙的斗志和工作效率。如果再出现这种情况，请先回顾产品目标和目标优先级，确保大家达成共识。

产品评审团

产品评审团并不是设计和开发产品的团队，它的职责是监督产品研发流程，制定关键决策。它根据研发产品的四个里程碑来评审产品，制定决策。

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

特约用户

组织特约用户的注意事项

不要向特约用户收取参与费用，否则合作关系将会变味。产品经理需要的是开发产品的伙伴，不要变成为特约用户开发产品。如果特约用户愿意，你尽可以等正式产品发布后再向他们收取费用。
由于可以免费试用产品，通常会有大量的申请者申请成为特约用户。公司的销售部门为了提高业绩，可能会要求产品经理招募更多的用户。这会消耗产品经理大量的精力，而且这些用户不一定符合要求。为了满足大批心急的用户，公司可以发布预览版产品。特约用户的人数绝不能超过十个，否则产品经理不可能有时间和精力与每位用户深入沟通。
如果在寻找特约用户时遇到困难，很可能是因为产品要解决的问题不像产品经理想象的那么重要，将来也很难销售出去。这可以初步验证产品创意是否有价值。出现这种情况，产品经理应该重新考虑产品计划。
产品经理需要确保特约用户是产品的潜在目标用户。我们很容易把产品尝鲜者（early adopter）误当成特约用户。产品尝鲜者常常能容忍产品的不足和缺陷，根据他们的建议研发的产品，很可能只适合他们自己，无法满足大众的需求（参见第35章）。
产品经理务必向特约用户说明，我们要开发的是面向大众的通用产品，不是为某家公司开发的定制产品。特约用户也不希望出现这种情况，因为小众产品的生命周期比较短，一旦产品被淘汰，售后服务也将被取消。产品经理应该向特约用户承诺产品不会昙花一现。
产品经理应该把特约用户当成开发伙伴对待，视他们为同事，互相帮助。许多特约用户和我结下了深厚持久的友谊。
产品经理与特约用户的合作贯穿产品研发的每个环节：向他们展示产品原型，请他们参加测试，向他们请教产品的细节问题，让他们帮你部署、测试待发布产品的备选版本。
正式产品发布之前，一定要先请特约用户试用，确保每个人都满意，一旦发布，他们会坚定不移地向大众推荐产品。
产品经理还要和产品营销团队紧密合作。一方面，营销团队可以帮助你物色特约用户；另一方面，他们可以协助你提高特约用户受关注的程度。
如果是平台产品，特约用户的作用就更突出了，只不过六个特约用户要换成六个应用。产品经理要与特约应用的开发者紧密合作，确保在平台上构建的应用让用户感到满意，最好鼓励应用开发者发展自
己的特约用户。

市场调研

用户调查

网络降低了用户调查的难度，提高了调查的效率，以至于现在几乎所有产品都要求做用户调查。做用户调查要注意两点。第一，设计调查问卷需要技巧和经验，不是一件容易的事。要结合具体情景，仔细设置问题，如果调查问卷措辞不清、先入为主，其他部门的同事就会质疑调查结果。第二，调查结果为获得解决方案提供了一条途径，但不是解决方案本身。哪怕所有用户都回答喜欢X特性，我们还是可以通过提供Y特性更实际地解决他们的需求。

产品使用分析

如果你的产品是网站，有很多实用的工具可以分析用户访问网站的行为。这些工具正确安装和配置后即可使用，非常划算。越早使用分析工具越好，不断地观察学习，然后调整产品。如果你的产品不是网站，可以在产品中添加分析工具，记录用户使用产品的行为。应该明确告知用户分析工具的用途，声明只收集统计数据，不涉及用户隐私。这样做虽然麻烦，但很值得。

数据挖掘

收集数据的渠道很多，除了上面提到的产品使用分析，还有用户的账单和账户信息、产品数据等。新的数据分析工具的功能越来越强。想知道同时使用几项服务的用户性别比例？想知道特定人物角色的活跃程度和分布情况？新的数据分析工具可以轻松回答这类问题。

拜访用户

没有一种方法可以替代前往用户使用产品的场所（家、办公室）实地考察的作用。虽然拜访用户成本高、耗时长，但我每次都能收集到从其他途径无法了解的信息。拜访用户很有效，但出于对资金和时间成本的考虑，建议谨慎使用。

人物角色

我喜欢在定义和设计产品的过程中使用人物角色。市场调研也可以借助人物角色展开。请记住，你要面对的绝不是单一类型的用户，务必找出若干主要用户类型，深入了解他们，弄清哪些是当前的用户，哪些是潜在的用户。具体内容请参考第17章。

可用性测试

我主张尽早、反复地进行可用性测试（请参考第22章）。观察用户使用现有产品的反应，收集反馈意见，了解他们的真实想法。从用户的视角重新审视产品，不光阅读反馈信息，更要观察、记录用户的行为和反应（比如兴奋、沮丧）。现在还有工具带有远程功能，可以在异地进行可用性测试，记录、分析用户行为。

同类产品分析

产品团队常常低估了竞争对手。就我的经验而言，每款产品都有做得好的地方。有必要找出竞争对手的优势，学习对手的成功经验。

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

谁是目标用户？
用户会怎样使用产品？
用户能想明白怎样使用产品吗？障碍在哪里？
用户为什么选用你的产品？
用户喜欢产品的哪些特点？
用户希望如何改进产品，增加哪些功能

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

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

产品人物角色

作为产品管理的工具，人物角色的主要用途如下。

人物角色可以用来筛选重要的产品功能。假设目标用户是“玛丽”，就该添加对“玛丽”重要的功能；如果某项功能只是针对“山姆”的，就该被淘汰。人物角色既有助于决定谁是目标用户，也有助于决定谁不是目标用户，两者同样重要。面面倶到的产品往往一无是处，使用人物角色可以避免犯这种错误。
产品团队常常把自己的需求当成用户需求，我在别处讨论过这个问题，使用人物角色可以避免犯这类的错误。
许多产品的用户类型不止一种。如果只是简单地针对每种用户添加功能，结果会是一团乱麻。这主要是设计上的问题，使用人物角色有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的地方。
有了人物角色，可以方便地向团队描述产品的目标用户是谁，他们怎样使用产品，他们关心产品的哪些方面。
和产品原则一样，人物角色可以帮助团队成员达成共识。产品发布之前有数以千计的细节问题要解决，产品经理和设计师不可能事必躬亲。如果产品经理、设计师、文案创作人员、开发人员、测试人员在产品原则和人物角色上达成共识，解决问题的效率会更高。

重新定义产品说明文档

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

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

用户体验设计与实现

许多团队把用户体验设计和软件开发放在一起进行，这是行不通的。原因如下。

与软件开发团队合作的人要记住一点：一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高。因为开发团队必须根据确定的用户需求和产品定义设计软件架构，然后进行开发。前期架构决策极大地制约着后期的开发工作，事后修改软件架构，无异于推翻重来。另外，从心理上说，事后修改设计会打击开发人员的斗志，引发消极的心态。随着时间一分一秒过去，返工和波动会增加团队的压力。尽管敏捷方法提倡不断修改和完善，但并非所有的修改都受欢迎。
用户体验设计要保证产品同时具备可用性和价值，任务很重。为了拿出既可用又具有价值的设计，必须尽早、反复地验证设计思路。有些人觉得可以等到每个迭代周期结束再观察设计思路是否合适，甚至等到产品公开测试时再收集用户反馈，这样低效的验证方法肯定是行不通的。优秀的用户体验设
计师一两天内要尝试几十个点子，哪怕只是2～4周的迭代周期都会慢得让人无法忍受。
我认为验证设计思路必须使用高保真原型。有人说，迭代结果和公开测试的产品可以当做原型。抛开要等很长时间不谈，这些开发中的产品与产品原型有很大的区别，不能混用。为了验证各种设计思路，产品原型应该可以随意修改，完成其任务后应该被丢弃。而开发中的产品应该以固定的原型为基础。
尽管产品开发可以分成多次迭代（这样做可以降低风险，提高质量，便于产品集成），用户体验设计却不能拆分。设计师必须全面地、连贯地看待用户体验，考虑以往用户的使用习惯。让用户放弃不可用的软件很容易，要他们放弃使用习惯却很难。
用户体验设计不一定是最费时间的工作（像软件开发一样，所需时间取决于具体的方法、特定的产品需求，以及从业者的技能和经验），但至少需要一两周时间。

只有在开发人员要开发大量后台基础软件的情况下，用户体验设计和软件开发才能并行展开。在这种情况下，开发团队可以利用设计师设计产品的时间完成这部分工作。虽然双方的工作会有一些依赖关系，但可以解决。多给设计师一些时间定义详细的待开发任务。

基本产品

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

产品验证

可行性测试

首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。有些方案通向死胡同，但总有些是可行的。重点是让开发人员寻找产品设计里那些难以克服的障碍，现在发现远比损失了时间和资金后发现来得好。有些产品的技术风险较大，如果你的产品存在可行性风险，一定要提前解决这些问题。

可用性测试

交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用。可用性测试往往能发现没能成功实现的产品需求，如果测试得当的话，甚至能发现原本被忽略的产品需求。最好规划多次迭代测试，确保实现最佳的用户体验效果。一定要请真实的用户来试用可用性原型，从目标用户那里可以得到宝贵的反馈信息。虽然产品经理和设计师也能从设计和使用原型的过程中掌握大量信息，但这些都不能代替让真实用户体验原型的作用。

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

价值测试

最后，仅仅知道产品能够开发出来、方便使用，这还不够。同样要紧的是知道用户是否觉得你的产品有用，是否愿意购买，有多喜欢产品的设计。价值测试可以和可用性测试同时进行，使用的原型也是一样的。只不过可用性测试重在观察用户如何设法完成必要的操作，而价值测试重在观察用户是否喜欢这些功能，是否满意功能的具体实现方式。

简单的产品也许在纸上画画原型就够了，但对于大多数采用复杂用户界面、运用新技术的产品来说，必须借助产品原型评估设计是否符合要求。不同的产品有不同的原型，比如，常见的原型是可点击的页面，当然，原型也可能是物理设备，或是软件与硬件的结合。无论哪种形式的原型都必须足够真实（高保真），可以提供给目标用户测试，并获取有效的用户反馈信息。

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

改进现有产品

产品经理应该时刻关注这些指标，与交互设计师、用户研究人员、主程序员密切合作，分析改善产品的可能性。想要进一步了解产品情况，还可以进行网站分析，请用户测试产品，向客服人员、销售人员了解情况，做盈亏分析，估算净推荐值。在互联网服务领域，可以获得几乎实时的数据反馈。通过分析这些数据改进产品，往往能收到事半功倍的效果。

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

平滑部署

毫无征兆地更新不必要的版本会令用户产生反感。有件事你可能觉得难以置信，但的确是事实：不是所有用户都喜欢新版本的产品。用户产生反感主要有以下几个原因。

事前没有收到更新通知，用户觉得措手不及。
用户没时间学习、适应新版本，产品公司也没有提供旧版本方便用户在过渡阶段使用。
新版本无法正常运行。
新旧版本不兼容（比如新版本无法访问旧版本的数据）。
虽然新版本可以正常运行，但用户认为添加的功能和特性毫无必要。
应付接二连三的版本更新，用户感到疲惫不堪。
新版本修改了用户已经习惯的使用方式和操作流程，用户不得不重新调整适应。通常情况下，用户不喜欢变化。虽然他们也希望产品更完善，功能更丰富，但前提是不改变已有的使用习惯，大多数人不愿意花时间学习、适应新的使用方式。

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

通过公告、群发邮件、在线教程等方式提前通知用户，但是很多人既没时间也没兴趣阅读这些内容，所以这个方法效果有限。
加倍做好测试工作，避免新版本存在影响正常使用的隐患，比如可靠性问题、扩展性问题、性能问题。确保将来不会陷入被迫返回旧版本的窘境，为用户增加不必要的麻烦。
如果更新版本会影响大规模的用户，应该采取并行部署或者增量部署的方式来降低风险。平滑部署的方式很多，比如发布两个并行的版本，邀请有兴趣、有时间的用户试用新版本。如果新版本运行正常，大部分用户习惯新版本后，再将新版本设为默认版本。同时将旧版本保留一段时间，公示为旧版本提供支持的最后期限，以便没来得及习惯新版本的用户在这段时间内能照常使用产品。

对于用户数量庞大的服务和产品，这个过渡可能需要几个月的时间。产品经理还要准备好承担来自开发团队和运维团队的压力，毕竟支持并行版本不是件容易的事。另一种平滑部署的方式是区域性逐步部署，首先在某个区域内部署新版本，然后逐步扩大范围。还有一种方式是增量部署，将更新项分割成几个较小的部分逐步发布。无论采用哪种处理方式，关键要全面考虑更新可能带来的“副作用”，为用户提供便利，方便他们在空闲时适应变化，同时尽可能降低新版本带来的负面影响。

快速响应阶段

我反复强调发布产品不等于大获全胜，交付产品后依然需要保持高度警惕。本章详细介绍产品交付后的收尾工作。产品发布后，多数公司会迅速撤走为研发产品和发布产品整合的资源，急于投入下一个项目，殊不知此时正是收集反馈信息、改进产品的最佳时机。急于“撤军”是项目管理和产品开发流程中的大忌，只要稍微延长项目周期，观察用户对产品的反应，效果就会有天壤之别。这样做投资之小、回报之高会令你瞠目结舌，绝非其他项目阶段可比。

我向来坚持产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段。这个阶段的主要工作是快速响应、处理产品发布后的用户反馈意见。快速响应阶段最早是针对大众网络服务的，因为大众网络服务特别重视用户的反馈意见。我相信它同样适用于平台产品、基础设施类产品、企业级产品。

合理运用敏捷方法

注意这些诀窍只适用于产品软件团队，不适用于定制软件团队。

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

合理运用瀑布式开发方法

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

传统瀑布式开发方法的理念很简单，主要有两点。

采用阶段式开发软件开发过程被事先分成固定的几个阶段：撰写书面的需求说明文档、设计高层软件架构、设计低层细节、编写代码、测试、部署。
采用阶段式评审每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才能进入下一阶段。

大公司如何创新

臭鼬工程是工程界的行话，原指秘密军事行动，现指在受限制的条件下，利用自己的时间，低调地进行创新研究。臭鼬工程拯救了很多大公司。在大公司里，普通员工很难凭空获得允许从事创新研究。如果你能拿出阶段性的成果来，获得许可会容易得多。在这种情况下，只要不耽误本职工作，管理层通常会支持你的做法。

有一点要提醒大家，有些公司规定员工在职期间研究出来的成果都归公司所有，所以不要随意拿研究成果自行创业。如果公司因为某些原因不愿意帮助你，你才能尝试谋求其他途径来实现自己的创意。了解硅谷历史的人知道，当年斯蒂夫·沃兹尼亚克（Steve Wozniak）因为惠普公司不愿意进入个人电脑市场，所以离职创业，才有了后来的苹果公司。

在大公司施展拳脚

理解这两点后，我再介绍在大公司施展拳脚的方法。

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

苹果公司给我的启示

硬件为软件服务与其他硬件公司不同，苹果公司明白硬件必须为软件服务，这种关系不能颠倒。软件直接服务用户，满足用户需求。采用多点触控显示屏、重力加速器、距离传感器这些硬件技术是为了配合软件满足用户需求，而不是花哨的噱头。苹果公司明白，仅凭华丽的硬件技术和软件效果无法真正吸引用户，一旦消费者过了尝鲜的阶段，就会对产品失去兴趣。要抓住消费者的心，需要更深层的东西。
软件为用户体验服务所有公司都把用户体验挂在嘴边，只有苹果公司把它放在心里。苹果公司的所有工作都围绕着产品的可用性、交互设计、视觉设计、工业设计展开。研发一款iPhone手机要两年半时间，设计用户体验几乎占了大部分时间。设计团队明白用户体验的重要性，即使阻力重重，也不轻言放弃。公司各个部门不遗余力地支持用户体验设计。相比之下，微软就差得远了，改善Vista用户体验的工作不但效果差，而且进展缓慢。苹果公司明白用户体验是产品立足之本。
用户体验为情感服务如果非要举出苹果公司成功的秘诀，我相信是这一点：他们比谁都清楚是什么让消费者为产品疯狂，他们知道怎样抓住用户的情感需求。人人都想拥有一台iPhone手机，哪怕是四百美元的天价也心甘情愿！没人把iPhone和RAZR、Treo做比较，它们完全不是一个“重量级”的。我在机场候机时，常常暗中比较人们对待苹果电脑和其他品牌电脑的态度——前者像是宝马，后者像是租来的二手车。如果你胆敢从街头少年手里抢他的iPod，那一定是吃了熊心豹子胆。
产品为真正的需求服务手机并非苹果公司首创，但他们挖掘出尚未被满足的用户需求。市面上的手机品种成百上千，却没几款让人爱不释手。十几年不变的语音邮件系统、不兼容的地址簿、蹩脚的网页浏览器和电子邮箱，只会让用户抓狂。苹果公司逐一完善这些功能，成功的产品应运而生。在数码音乐播放器领域，他们做得一样出色。很少公司像苹果公司那样理解和运用以上四点。竞相模仿其产品的大有人在，这些公司不过是在照猫画虎，形似神非。

新瓶装老酒

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

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

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

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

恐惧、贪婪、欲望

多数软件产品行业的从业者都是理工科或经济学背景，我们每天的工作却和研究人类情感的心理学有关。虽然很少有人意识到这一点，但事实如此。消费者购买产品大多源于情感需求。优秀的产品经理和销售人员明白其中的道理，懂得产品应该满足用户的情感需求。

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

情感接纳曲线

杰弗里·摩尔（Geoffrey Moore）在他的作品《跨越鸿沟》中提出了一个颇具影响力的概念——技术接纳曲线，这条曲线涉及了技术创新者、尝鲜者、早期消费大众、后期消费大众和跟随者。这本书尝试解释为什么很少有产品能越过鸿沟——获得尝鲜者以外消费者的青睐。

不要一味从技术角度看待产品，多从用户的角度考虑问题。是什么问题让他们头痛？是什么让他们垂头丧气、愁眉苦脸？比如，如今大家都讨厌旅行——旅行的过程变得毫无乐趣可言；又比如，人人都讨厌电话公司——复杂的话费清单几乎没人能看懂。电话公司仿佛存心为难消费者，每个月月底大家都得提高警惕，免得被忽悠。

大众网络服务产品

可用性在我看来，多数公司不够重视产品的可用性，尤其是开发企业级软件的公司。大众网络服务产品必须具备良好的用户体验。如果用户不清楚怎样使用产品，也不知道产品的优势何在，你就等着关门歇业吧。另外，别忘了产品性能是最重要的一条可用性指标，页面加载缓慢让用户无法忍受，也是糟糕的用户体验。
人物角色网站用户数量过百万后，产品经理不可能再逐个研究每位用户，只能按典型特征将用户分类，抽象出有代表性的用户类型（人物角色），加以分析。产品每增加一项新功能，都要请典型用户参与测试，根据反馈信息加以完善（参见第17章）。
扩展性激增的用户数量会带来莫明其妙的问题：数据库崩溃、系统出现性能瓶颈、用户界面罢工。网站上线前进行压力测试虽然可以发现部分问题，但正式使用时总有意想不到的情况出现。实现扩展性需要产品经理、设计人员、开发人员、运维人员的通力协作，最好利用部分开发资源和运维资源（我建议分配20%的资源）专门为系统扩展做好准备。不要到系统承受不了压力，即将崩溃才追悔莫及。从设计系统的第一天开始，就应该不间断地考虑扩展性问题，永远留有余地，不到万不得已不要满负载运行（参见第5章）。
持续可用性大众网络服务要求一刻也不能停歇，但迄今为止我还没见过哪家网站能做到24×7小时无故障运行。系统中止服务是件痛苦的事，对那些负责解决系统故障的人来说更是如此，不是所有人都适合干这一行。系统出故障的时间没个准，工作日、节假日、周末、深夜，随时可能发生，从业者的压力相当大。在系统设计上保证持续可用性与规划扩展性一样重要。
客户服务另一件让大众网络服务公司头痛的事是客户服务。传统的客户服务完全无法应付数量庞大的网络用户，收费的网络服务情况更严重。要想降低客服压力，除了尽量减少系统故障和缺陷外别无他法。在这个问题上，节省开支只是一方面，更重要的是维持良好的用户体验。
保护用户隐私大众网络服务公司容易因侵犯或泄露用户隐私被迫停业。虽然你收集用户资料的初衷可能是好的，比如提供个性化用户体验，但如今电子邮件信息、信用卡卡号等用户数据都是敏感资料，一旦不小心泄露出去，后果不堪设想——接踵而来的负面报道、法律制裁，还有用户的满腔怒火。应尽早树立保护用户隐私的意识，设置用户资料保护机制，千万不能辜负用户对你的信任。最近美国在线的案件给我们敲响了警钟，我们需要警惕，提防自己的员工泄露用户资料。
口碑营销用户如果喜欢产品，就会主动向家人、朋友、同事推荐。这是宣传产品的最佳方式。令我费解的是，很少有公司充分利用这种营销手段。我建议为用户提供便利，方便他们（通过邮件、短信、社交网络等）向熟人推荐产品。许多公司愿意为吸引新用户支付报酬，不妨向踊跃推荐产品的用户发放奖金。当然奖金激励还是次要的，最重要的是让用户易于向家人、朋友、同事、网友推荐产品。
全球化优秀的互联网产品很快会被其他国家、地区的用户接受，迅速在互联网覆盖的范围内传播开。易于本地化的产品设计可以大大节省开发成本和开发时间，避免为了语言、货币、文化差异大量改写程序。这样随着产品业务的拓展，你可以迅速适应当地用户的需求。
平滑部署网站用户数量过百万后，任何小小的变化都会影响大面积的用户，要三思而行。我详细讲述过平滑部署的要点（参见第24章），请大家务必谨慎小心。部署前要仔细测试，逐步过渡，步幅不可过大，为用户留出足够的时间来适应变化。有些公司让新老版本同时运行一段时间，让用户适应过渡，这是个好办法。最后，尽量减少不必要的更新，用户消化、吸收新事物不是件容易的事。
用户社区管理所有的商业公司都依靠用户生存，这一点对大众网络服务公司来说显得尤为突出，水能载舟亦能覆舟。如果用户认可你的产品，他们会很乐意成为用户社区的一员，同时希望得到重视和认可。与用户交流的方法有很多，多和他们接触，了解他们希望如何改进产品。多用类似于“回馈用户”的活动表达对他们的重视。让公司上下认识到用户的重要性，真正从行动上把用户当做“上帝”。

打造平台产品的经验

产品管理中难度最大，也最能体现产品经理实力的是定义成功的平台产品。所谓平台产品，是指一类基础软件，应用开发者能在其基础上开发应用程序。平台有很多种，例如，操作系统（如Window操作系统、Mac操作系统、Palm智能手机操作系统）、运行环境（如Java、Flash）、web服务（如亚马逊和eBay的集成应用程序接口）、游戏开发平台（如XNA），以及应用平台（如Facebook和Salesforce.com）。

最佳实践经验

从业二十多年来，我一直在总结打造富有创意产品的方法。这里分享我认为最重要的十个要点。每个要点在书中都有详细描述，希望这里的汇总能加深读者的印象，建议大家结合实际工作来体会。

产品管理的职责许多产品经理将大把的时间浪费在与产品管理无关的工作上，比如，营销管理和项目管理，这些都不是产品经理应该干的活。
用户体验对于大多数软件产品来说，用户体验就是产品的生命。产品经理应该与交互设计师、开发人员密切合作，设计良好的用户体验，打造有实用价值的产品。
机会评估用方便快捷的机会评估方法取代过时的市场需求文档。动手设计产品前，先明确产品要解决什么问题，为谁解决问题，以及评估产品的标准。
特约用户有些产品团队企图绕过用户，直接设计、开发产品，这种想法可笑至极。打造优秀的产品没有任何捷径，只能请用户反复试用产品，不断改进。
产品原则产品管理工作的主要内容是制定决策。明确的产品原则可以帮助产品经理和产品团队树立清晰的价值标准，作出果断的决策。
人物角色人物角色是协助产品经理制定决策的另一项工具。把目标用户按特征分类，逐一分析、理解其情感和行为，以此作为决策的依据。
探索（定义）产品产品经理的主要职责是探索（定义）有价值的、可用的、可行的产品。除非产品经理确定这三点，否则同事的努力都将付之东流。
使用原型使用高保真原型是探索（定义）产品的关键步骤。原因如下：第一，迫使产品经理深入定义解决方案；第二，可以让真实的用户参与测试、验证产品创意；第三，可以直观地向团队展示产品的设计思路。
用户参与原型测试有了产品原型，产品经理可以方便地请用户验证产品创意。原型测试是所有产品经理和产品设计师都必须掌握的工作技能。获取有效的用户反馈是产品经理最重要的工作。
根据数据改进产品成功的产品经理懂得利用数据来改进现有产品。改进产品不是根据客户要求一味增加新功能，而是根据产品的实际应用情况，不断地提升产品的各项指标，逐步完善产品。

产品经理的反省清单

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

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