启示录

1. 前言
   1. 缘起：如何确保开发的产品是用户想要的，有价值的，可用的，可行的；
2. 关键角色及其职责
   1. 产品经理的主要职责：
      1. 评估产品机会；
         1. 有商业价值；
         2. 符合公司的发展方向；
      2. 定义要开发的产品（寻找解决方案）；
         1. 功能清单（流程图，业务逻辑，用例）；
         2. 用户体验（用原型来体现）；
         3. 发布标准（性能要求，可靠性，浏览器兼容等）；
   2. 运维团队：保证服务正常运行；
   3. 产品vs交互=1：2；
   4. 交互vs视觉=1：4；
3. 产品经理与产品营销（两项工作天差地别）
   1. 前者负责定义产品；
   2. 后者负责对外宣传产品；
4. 产品管理与项目管理
   1. 前者负责探索有价值的、可用、可行的产品，后者关注如何执行计划以按时交付产品；
   2. 对于少于10人的项目，可能不需要特别设置项目管理人员，因为可由scrum master承担部分事务，团队自组织；
   3. 对于大型项目，如采用版本火车的项目，由于需要多个scrum团队协同，单独的项目管理很有必要；
5. 产品管理与产品设计
   1. 用户体验设计包括：
      1. 用户调研（或设计调研）；
      2. 交互设计；
      3. 视觉设计；
      4. 原型制作；
6. 产品经理与软件开发
   1. 开发团队给产品经理提供帮助的方法:
      1. 开发人员参与原型测试，到现场感受用户的痛点；
      2. 产品经理向开发人员了解最新的技术趋势，以便了解原来不可行的方案现在变得可行了；
      3. 开发人员参与到早期的原型设计中，出谋画策的同时，也可以有效的评估开发成本；
   2. 产品经理配合开发人员的方法：
      1. 只定义满足基本要求的产品（即最小功能原型）；
      2. 进入开发阶段后，尽量减少变更；
      3. 对于开发阶段中出现的问题，产品经理应迅速给出解决方案（在维持基本功能和尽量减少更改的前提下）；
   3. 外包是出于寻找最优秀合适的团队人员，而不是出于省钱，因为提高生产效率产生的价值，远超过节约的成本；
   4. 重构代码：平时应预留20%的时间用于重构；如果已出现问题及短时间内不可能全部做完，则可以考虑分模块和分批重构；
7. 招聘产品经理
   1. 产品经理应有的特质：
      1. 对产品的热情：他们尊重产品，喜欢思考，喜欢创造，喜欢改进一切不好的部分，让它变得更好；
      2. 用户立场：他们懂得换位思考，而不是一意孤行想改变用户的习惯；
      3. 智力：他们是善于思考的聪明人，对事物本质有洞察力，仅有勤奋是不够的；
      4. 职业操守：他们对自己的产品具有高度责任感，不会因贪图安逸而弃之不管；
      5. 正直：能够尊重和信任自己的同事，而不是一个自私的人，唯有如此，才能获得团队其他成员的支持；
      6. 信心：自信的人更有说服力，人们愿意追随有信心的人做为领导者；
      7. 态度：他们愿意对产品出现的问题承担责任，而不是一味的找借口；
      8. 技能：好的技能能够提高工作效率，但技能可以通过时间来习得；
      9. 运用技术的能力：新的技术涉及思考新的解决方案来处理老问题，所以对技术的理解和运用变得很重要；
      10. 专注：懂得什么才是最重要的，关注核心功能，克制增加功能的冲动，并去掉多余的功能（更简单的产品，更容易获得用户的喜爱）；
      11. 时间管理：熟练的区分重要任务和紧急任务，合理的安排工作时间；
      12. 沟通技能：书面和口头沟通的能力，以及演讲的能力；
      13. 商业技能：能够用合适的语言与各种角色的人员进行有效的沟通，商业的语言和技术的语言；
   2. 行业知识可以学习，但解决问题的思路则难得多，比如招聘产品经理的时候，可以询问他们如何学习思考，比如开发一个陌生的新产品前，他们需要学习哪些知识，花多久时间学习，如何学习，如何利用这些知识；
8. 管理产品经理
   1. 产品总监的两个职责：
      1. 组建优秀的产品经理团队；
         1. 训练和培养产品经理的工作能力；
      2. 规划公司的产品战略，负责产品组合；
         1. 透彻理解公司的商业战略，确保产品组合直接支持公司的商业战略；
         2. 与产品经理一起完成产品规划，共同实现产品规划；
         3. 带领产品团队制定产品原则，坚持按照原则去开发产品；
         4. 识别和协调不同产品经理之间的冲突；
      3. 通过用户净推荐值来评价产品经理的工作是否合格（这个指标体现了用户满意度，而且有利于低成本的口碑营销）；
9. 巴顿将军的忠告
   1. 永远不要告诉别人怎么做，而是告诉他们你想要什么结果（即告知你的目的，而不用告诉你的解决方案，因为解决方案是有多种的，如果告诉了解决方案，就错失了其他多种的可能更好的解决方案）；
   2. 两个常见的误区：
      1. 用户经常告诉产品经理他们想怎么做，而不是他们想达到的目的（因为针对问题思考解决办法是人的天性）
      2. 产品经理经常告诉设计师要怎么做，而不是告诉他们自己想达到的目的；（注意：留给设计师和开发人员的空间越大，他们越能发挥他们的才能创造更好的解决方案）；
10. 产品副经理
    1. 创造好的产品，本质上是思考好的点子和创意；因此，如果只局限于自己思考点子，就会有很大的局限性；做产品要找公司最聪明的人合作，每个公司内部都会有几个绝顶聪明的人，找到他们，请求他们的帮助，甚至把他们招到团队里面来；
    2. 找到这些人的办法：
       1. 多向同事打听打听，肯定会有收获；
       2. 走动式管理，多花时间与员工相处；
       3. 打开大门，让大家知道你随时欢迎他们来提建议；
       4. 注意倾听与会者的对话和发言；
       5. 向大家诉说你的烦恼，请求大家的帮助；
       6. 和同事一起去泡吧；
11. 管理上司
    1. 管理上司的10条经验：
       1. 为项目波动做好准备，通过提高警惕，以及记录工作进度（不波动是不可能的）；
       2. 注意沟通的方式和频率（不同的上司偏好不同的沟通方式，对症下药）；
       3. 会前沟通（如果在会上有人反对，其他人也会附和；因此，应该在会前私下取得每个人的建议和支持）；
       4. 多提建议，少提问题（最好根据问题的重要性列举多种解决方案，并附上你的建议和依据）；
       5. 向上司借力（如果自己无法找到其他高管进行沟通，可由上司代为转达）；
       6. 充分准备（对自己方案中的漏洞，做好回答的准备）；
       7. 缩短邮件的篇幅（由于管理者每天收到大量邮件，因此级别越高，写出的邮件应该越短，简明扼要）；
       8. 多用数据和事实说话（没有数据支持的方案，只能是个人的臆断）；
       9. 内部宣传（充分有效的宣传，可以让内部同事乐于帮助你）；
       10. 做让领导省心的员工（不要让上司做你的导师，但可以在上司外的人群中寻找导师，思考如何节省上司的时间，会收益匪浅）；
12. 评估产品机会
    1. 只关注市场需求，不涉及解决方案；
    2. 评估过程中需要回答的10个问题：
    1. 产品要解决什么问题；（产品价值）
    2. 为谁解决这个问题；（目标客户）
    3. 成功的机会有多大；（市场规模）
    4. 怎么判断产品是否成功；（度量指标）
    5. 成功的必要条件是什么；（解决方案需要满足的条件，或者说解决方案应该解决掉哪些问题，满足哪些条件才算是好的解决方案）（此处有新的理解，或许是指前提条件？即背景因素，有部分非我们所能掌控？）
    6. 市场上的同类产品有哪些；（竞品分析）
    7. 为什么我们适合做这个产品；（竞争优势）
    8. 现在的时机合适吗；（市场时机）
    9. 如何将产品推向市场；（销售策略）
    10. 结论：继续 or 放弃；
        3. 盈利模式：多从财务的角度来看待产品，例如各种财务指标的计算与分析；
13. 产品探索
    1. 弄清楚要开发什么样的产品（定义正确的产品）；
    2. 工作内容：
       1. 分析各种创意；
       2. 广泛收集用户需求；(角色、场景、问题）
       3. 拿出原型并加以测试；
    3. 软件行业常见的偏见：需求分析与设计是可预测的，可控制的；但实际情况是它是不可预测的，是创造性的工作，更像是艺术而非科学；
       1. 探索是否有用户需要产品；（寻求市场，让用户难验证产品，确保产品有价值）
       2. 探索能够解决问题的产品方案；（让产品可用、可行）
    4. 教训：在弄清楚产品定义前，不要招聘开发人员；如果有开发人员，也要将其投入到产品探索的工作中；
14. 产品原则
    1. 在组建或进入一个新团队时，务必先制定产品的原则，这样可以让大家在决策过程中减少争执；
    2. 产品原则需要召集团队成员一起讨论和制定，而不是由单个人说了算，这样才能确保原则制定后，能得到每一个人的贯彻执行；
    3. 制定原则过程中需要思考的4个问题：
       1. 究竟要解决什么问题；
       2. 究竟要为哪一类角色解决问题；
       3. 产品要达到什么目标；（例如易用性、功能、成本、响应速度、安全性、用户隐私等）
       4. 每项目标的优先级是什么；（务必要为每个目标制定优先级，让团队达成共识，并将其写在白板上，提醒每一个人，开会前重申）
    4. 制定决策的过程和依据需要透明，不要让别人觉得自己是在凭直觉判断；务必告诉大家决策的依据和理由；
    5. 激烈的争吵会影响团队的士气和工作效率，所以应该尽量避免；如果有出现，应该回顾一下产品原则，包括产品目标和目标优先级；
    6. 我看了一下作者网站上的案例，发现案例里面的产品原则涉及以下几个部分：
       1. 我们的产品是为了改变什么情况；
       2. 我们想为准改变这些情况；
       3. 我们想这么改变的原因；
       4. 我们的价值观念，即我们认为什么更加重要；
       5. 为什么我们觉得我们产品的存在是必要的；
       6. 注：感觉以上5点都侧重做这个产品的使命感，大家因为使命感来做这个产品，带着一种要改变世界的原动力；
15. 产品评审团
    1. 决策流程过长会影响工作效率，所以很有必要设定机制，以便可以及时的做出明智的决策；
    2. 评审团的成员一般由相关部门的负责人组成，这些负责人可以分配和协调资源；
    3. 分为四个里程碑的工作点：
       1. 制定产品战略和产品路线图（在这个阶段，产品经理还没有开始介入；相当于是公司的高层人员参与的季度或年度会议）；会议结果是选择值得投入的产品，之后让产品经理开始评估产品机会；
       2. 根据产品机会评估的结果，决定是否开始定义产品的解决方案；
       3. 根据产品原型、用户测试结果、成本估算明细，决定是否开始开发产品；
       4. 根据最终产品，评审产品质量、产品效应、发布计划，决定是否最终发布产品；
    4. 注意事项：
       1. 评审团不负责具体细节，也不负责设计；如果有提出，置后考虑；
       2. 第二个里程碑点，只按大中小码来估算成本；第三个里程碑点，按原型来估算较详细的成本；
       3. 产品上线3-6个月后，再组织一次评审会议后，根据运营指标，回顾之前的评审，经验总结供将来参考；
       4. 每次评审前，产品经理最好向各评审团成员做简要汇报，以便提前得到反馈，避免会上措手不及，导致无法及时决策；
16. 特约用户
    1. 通过特约用户，可以更早的得到反馈，洞察需求，降低风险；
    2. 成为特约用户的好处：
       1. 参与产品的设计，以便确保产品可以解决他们手边急需解决的问题；
       2. 可以尽早的试用产品，解决问题并降低相关成本；
       3. 不需要支付费用，只在确保产品可以解决问题后才付费，降低了风险；
    3. 如果一个产品征集特约用户出现困难，则说明产品本身的价值可能有问题，解决的并不是用户痛苦的问题；
    4. 至少征集6位特殊用户（可以先圈定8-10人，再筛选为6人）（如果太多，可能产品经理会忙不过来）（用户特征：积极、活跃、善于思考、乐于分享）（如果是面向大众的互联网产品，则人数建议为10-15人）
17. 市场调研
    1. 每一种调研方法都有其适用场景以及局限性，要能够弄清楚它们的区别；
       1. 采集数据：
          1. 现场观察法：可以获得大量信息，而这些信息是口头无法充分表述的；
          2. 单人访谈法：可以了解到观点、目的和思路，这些是观察法所无法提供的；
          3. 问卷调查法：低成本，快速收获大量的结果，缺点是考验问题设计的能力；
          4. 焦点小组：适用于某些需要知悉多方意见的内容，从不同角度阐述相同主题，缺点是会互相干扰，群体压力；
          5. 头脑风暴法：适用于创新思路的场景；
          6. 自我陈述法：适用于使用反馈的收集，考验用户的表达能力；
       2. 分析数据：原型测试；A/B测试；卡片法；数据对比分析；鱼骨图；情景分析法；人物角色法；故事板；用户点击分析；
    2. 调研是为了获得信息和存在的问题，用于思考解决方案；而不是简单的通过调研获得解决方案；
18. 产品人物角色
    1. 主要用途：
       1. 可以用来筛选重要的功能，即确定功能的优先级；
       2. 避免团队将自己的需求当成用户的需求；
       3. 可能不止一种人物类型，加以区分有利于对角色的优先级进行排序；
       4. 通过角色，可以方便的向开发团队成员描述目标用户是谁；
       5. 清晰的人物角色，可以让团队成员在一些问题上快速达成共识；（而不是陷入按自己角度出发的争论之中）
    2. 人物角色要越早设定越好，而且要在最明显的地方贴出来，时时提醒自己；
       1. 制定人物角色时，一开始先不要想这个角色有什么特点，而是先描述这个角色的方方面面，等描述足够多的内容后，它的特点自然会浮现出来；
19. 重新定义产品说明文档
    1. 产品文档的目的是向开发团队交付具有成功潜力的产品说明，所以，只要是能够让开发团队更加迅速理解需要开发的产品，就是一份好的说明文档；所以，高保真原型是最好的方式；
    2. 但只有原型并不够，还应该包括一些辅助的文档，以便能够说清楚以下一些事项：
       1. 业务逻辑（虽然通过原型相关人员可以摸索出逻辑，但那样的效率太差，也可能由于原型本身问题出现理解偏差。直接用文字说明来得更简单直接）（建议包括：功能清单、业务流程、用例）
       2. 发布要求：性能表现（比如网页的打开速度）、可靠性（比如数据备份、网络攻击、负载均衡等）、交付要求（比如浏览器兼容性、安装的硬件要求等）
20. 用户体验设计与实现
    1. 先定义用户体验再动手开发（因为UE设计可以低成本的修改，而且更改迭代的周期很短，所以设计与开发务必不要同时进行，设计应该在开发的前面完成）
    2. 但在设计的过程中，可以请一位开发成员评估设计的可行性与成本，以便做出更明智的决策；
21. 基本产品
    1. 第一版原型，只具备实现商业目标的最基本功能要求；（最小功能、最小功能、最小功能，重要的事情说三遍）
    2. 邀请一位开发人员参与原型设计，以便协助评估成本和可行性；
    3. 请真实用户验证产品原型；
22. 产品验证
    1. 可行性测试：由开发人员在原型阶段参与评估，重点寻找那些难以克服的障碍；如果存在技术上的可行性风险，一定要提前解决这些问题；
    2. 可用性测试：请真实用户验证原型；除了可以得到大量的反馈信息，还可以发现原先设计上面遗漏思考的地方；
    3. 价值测试：可用性测试验证产品是否方便使用，价值测试验证用户是否喜欢这个产品，是否能解决他们的问题，是否愿意付费；
23. 原型测试
    1. 物色测试者：
       1. 邀请特约用户参加，如果没有特约用户，马上寻找；
       2. 如果是企业级产品，可以在同类产品的展销会上面寻找目标用户；
       3. 如果公司较大，可以定期展于原型测试活动，并安排专人负责，这样产品经理可以不用为寻找测试者操心；
       4. 离开办公室，去目标用户聚集的地方，进行观察、倾听和寻找，注意放低身段；
       5. 在约定时间的前一天与测试者进行电话确认，以免对方爽约；
    2. 准备测试：
       1. 事先准备好测试内容
          1. 根据用户的心智模型和功能点，整理好测试任务；
          2. 制作测试大纲，即做测试时的流程，以便大致控制测试过程，避免事项遗漏；
          3. 制作脚本，即测试过程中要讲的台词、要问的问题、需要记录的事情等；
          4. 记录工具，包括纸张、摄像、录音等；
       2. 在给用户原型前，要先观察一下用户之前是如何解决他们所面临的问题的，让其试演示一下，从中可以了解到用户的操作习惯和心智模型；
       3. 在让用户开始测试任务前，先让用户自由探索2分钟左右，然后询问用户能否看出产品解决什么问题、哪些地方吸引他们等；
       4. 测试后通过沟通了解用户对原型的评价，包括打分、推荐值等；
       5. 两个技巧：
          1. 鹦鹉学舌：当用户发出提问时，不要回答他们的问题，而是复述他的问题，把问题回给用户，目的是鼓励他们自己尝试和探索，而不是为了方便从我们这边得到答案；
          2. 当用户陷入困难时，询问用户“接下来希望发生什么”，这样可以了解到用户的心理预期，以及他们的心智模型；
       6. 测试前，务必向用户说明两个事项：
          1. 这个原型只是一个初稿，希望他们多给意见，以便修改得更好用，不必碍于情面不好意思说；
          2. 这个原型是用来测试产品，而不测试人，所以失败了不要紧，失败了才能说明出产品设计的不合理，有待改进；
    3. 只要有2-3个用户反映同一个问题，即开始着手马上修改，而不用等到更多用户来验证；
    4. 如果有连续6个用户表示理解和欣赏产品的价值，而且能完成关键的测试任务，就算完成了原型测试任务；
    5. 如果发现没有用户对产品感兴趣，或者让产品简单易用以使其理解产品的价值，则应赶快考虑放弃这个创意；
24. 改进现有的产品
    1. 改进产品之前，首先要做的第一件事情是明确产品的目标（只要明确目标，才能不迷失改进的方向）；
    2. 考虑可以从哪些方面改善用户体验（到现场去观察用户是如何使用现有产品的，使用过程中存在哪些困难或困惑的地方）；
    3. 避免误区：一味的考虑如何增加新功能（增加功能并不能更好的让产品更好，事实常常正好相反，功能越多，用户对产品的评价越低）；
25. 平滑部署
    1. 多数用户不喜欢产品出现更新，因为那往往意味着他们要改变操作习惯，以及花费时间重新学习；
    2. 应对措施：
    1. 提前通知；
    2. 新旧版本同时并行，让用户有学习过渡的时间；
    3. 灰度部署，即先从部分区域开始试用，以便提前发现一些问题并进行修正，为后续大规模的部署减少阻碍；
    4. 加强测试；
26. 快速响应阶段
    1. 产品上线后不要急于撤退，而应该留出2-4周的时间，来快速响应；因为在上线后的一段时间内，会得到大量的用户反馈，这个时候可以用很小的成本，对产品做出很有价值的改进；
    2. 评估产品表现，应该通过各种可以量化的指标来进行，借助现有的各种成熟工具来获取指标数据；方法包括：
    1. 网站分析工具；
    2. 问卷法；
    3. 邮件、即时聊天工具、论坛、留言板等；
       3. 如果是企业级软件，产品上线后，应该派遣产品经理和设计人员到现场去驻点以收集大量有价值的反馈，这一点非常重要；
27. 合理运用敏捷方法
    1. 敏捷方法缘起于定制软件，而在传统的定制软件行业中，并没有产品经理和交互设计的岗位，所以敏捷只提到设计可以和开发在同一个冲刺中实现；但对于产品软件来说，这样是不可行的，设计必须早于开发；
    2. 另外，由于产品软件往往面对海量用户，相对于定制软件数量有限的客户，软件的架构变得非常重要，所以必须提前设计好，而不是在敏捷执行过程中重构；
    3. 在敏捷开发中，产品经理的主要任务是提供可用的、有价值的原型和写用户故事；
28. 合理运用瀑布式开发方法
    1. 瀑布式方法的优点是看起来有阶段性产出，所以让管理层感觉项目比较可控；缺点是软件行业充满了不可预测性，所以除非很小的项目，对可预测性抱乐观的理想主义经常是不现实的；
    2. 如果非得用瀑布式的方法，则重要的一点是在进入开发前应该将原型做好，并通过用户的验证；
29. 创业型公司的产品探索
    1. 在创业的初期，最重要的人员不是程序员，而是负责以下三项工作的人员：
    1. 产品经理；
    2. 交互设计师；
    3. 原型制作师
       2. 在原型通过用户测试验证后，再招聘开发人员完全来得及，不仅节省时间，也节省金钱；
30. 大公司如何创新
    1. 20%法则：给以员工20%的时间，去实践自己的创新想法；
    2. 臭鼬工程：员工利用自己的业余时间实践创新的点子；
    3. 主动观察：创新不是发现新问题，而是用新方法解决已有的问题；所以观察人们对现有产品的不满，是创新的最佳途径；
    4. 改善用户体验：提高用户体验意味着提高产品的使用效率；寻找现有产品中那些让用户失望的地方，想办法改进它们；
    5. 收购小公司：能够生存下来的小公司都有其独特之处，所以收购他们也不失为一种好办法；
31. 在大公司大展拳脚
    1. 大公司的现实情况：
    1. 遵守一条规则：尽量规避风险；
    2. 矩阵式的部门：为了降低成本（因此在大公司里面要获得资源去完成一件事情，需要多个部门的合力支持）；
       2. 应采取的措施：
    3. 了解制定决策的方式：这样才可以找到正确的决策人，而不是被卡在一些非关键的人身上；
    4. 建立人脉网络：这样在需要帮助的时候，别人才会帮助你；
    5. 臭鼬工程：凭空申请资源很困难，所以先私下里和几个同事把东西原型做出来，之后再申请资源就会变得容易一些；
    6. 自己顶上：虽然大公司很多，但经常遭遇资源紧张，所以与其等待他人，自己顶上常常能更快的解决问题，不要让事情处于等待的状态；
    7. 有选择的据理力争：多一个敌人不如多一个朋友，所以除非是非常重要的事情，不要随便发脾气，另外要对事不对人；
    8. 会前沟通，形成默契：如果决策会议上有人反对，其他人就会附和，所以应在会议前，提前私下跟各关键决策人形成一致意见；
    9. 合理分配时间：大公司经常会有一些无关紧要的会议，学会拒绝，将自己的时间花在最重要的事情上面；
    10. 分享信息：分享的过程中会学到更多；
    11. 向上司借力：如果上司是一个有威望的人，则利用他的关系，可以更好的开展工作，应该充分加以利用，而不是单靠自己一个人埋头苦干；
    12. 传播你的产品理念：当一个理念得到足够传播的时候，它获得支持的可能性会大大上升；念念不忘，必有回想；
32. 苹果公司的启示
    1. 硬件为软件服务（因为软件直接接触用户）；
    2. 软件为用户体验服务（用户体验不好的软件会让用户抓狂）；
    3. 用户体验为情感服务（要学会如何抓住人们的情感，因为情感是我们一切行为的动机）；
    4. 产品为真正的需求服务（手机并非苹果所创，但他们抓住了尚未被满足的需求）；
33. 提防有特殊要求的产品
    1. 产品需求不能由用户说了算，原因如下：
    1. 用户在看到具体的产品之前，很难自己真正需要的是什么；
    2. 用户不知道什么样的产品是可行的（在当前的技术条件下）；
    3. 用户之间缺少沟通，需求很难统一；
       2. 解决办法：
    4. 用户在描述需求的时候，习惯提出自己的解决方案；产品经理应该与用户一起梳理需求，发现问题的本质，提供更合理的解决方案；
    5. 原则上是在保持产品通用用途的基础上，再考虑用户的定制或拓展需求，可以考虑由第三方供应商来解决拓展或定制的部分，最后集成在一起；
       3. 原则：产品经理应该确保产品是有价值的，并尽可能满足更多用户的通用需求（而不是一个用户的更多需求）；
34. 新瓶装老酒
    1. 要想在成熟的市场抢占一席之地，应该掌握两件事情：
    1. 对目标市场了如指掌，对现有产品的缺陷洞若观火；（可以通过产品可用性测试掌握情况，包括自己的产品和竞争对手的产品）
    2. 跟踪最新的技术趋势，为老问题寻找更好的新办法；
35. 产品中情感的作用
    1. 企业级消费者会出于恐惧和贪婪而购买产品；
    2. 个人消费者会出于自己的情感需求而购买产品；（马斯洛需求模型）
    1. 生理上的需求：吃穿睡；
    2. 安全上的需求：安全感；
    3. 情感和归属需求：相互的关系和照顾（友情、亲情、爱情、亲密关系）
    4. 尊重的需求：自我尊重和社会尊重；
    5. 自我实现的需求：道德感、创造力、自觉性、公正；
       3. 在可用性测试中，除了发现产品的问题，还应该了解是什么情感驱动用户来使用这个产品（情感是我们一切行为的动机）；
36. 情感接纳曲线
    1. 不要从技术的角度问题，而应该从用户的情感角度思考问题：是什么让他们失望、愤怒、痛苦、恐惧？
    2. 关注非理性消费者的情感（因为他们会放大自己情感并做出行动，从而更容易被我们所观察，同时其背后也代表了其他理性的消费者的情感问题）
    3. 注意不要被新技术爱好者误导了自己的注意力焦点，他们做出的选择常常只是因为产品采用了新技术；
    4. 关注失望、不满、愤怒等一切情感的因素；
    5. 评估产品，重在评估它满足了什么样的情感需求，以及这种需求有多迫切；
    6. 带着新生的感受，去倾听、观察和感受每一天折磨用户的情感：孤独、恐惧、不满、愤怒等；
37. 可用性与美感
    1. 交互设计影响了使用的方便与简单，视觉设计影响了美感与情感，二者缺一不可；
38. 大众网络服务产品
    1. 10个要点
    1. 可用性：无须赘言；
    2. 人物角色：大众产品面对的用户众多，无法一一交流，所以设计几个典型的角色，如果有增加新功能，邀请典型用户进行测试；
    3. 扩展性：满负荷运载非常危险，容易导致系统崩溃，所以应该提前准备，即预留20%的空间余量来应对状况；
    4. 持续可用性：与拓展性一样重要；
    5. 客户服务：减少系统故障和缺陷，是降低客服压力的唯一办法，否则大众百万级的用户，会让客服系统压力暴涨；
    6. 保护用户隐私；
    7. 口碑营销：为用户的分享，创建便利的方式；
    8. 全球化：注意设计的易于本地化；
    9. 平滑部署：不中断服务的进行更新升级；
    10. 用户社区管理：好的产品会吸引用户参与，多倾听他们的声音，多给予参与回馈，让团队真正将用户当做上帝；
39. 打造企业级产品的经验
    1. 应该处理好的10个问题：
    1. 可用性：注重交互设计与视觉设计；
    2. 产品正常工作：增加测试减少缺陷；
    3. 特例产品：不要误以为客户会告诉他们的需求，他们经常搞不懂自己真正要的是什么；
    4. 特约用户：认真倾听，通过现象发现问题的本质，向他们提供更好的解决方案并进行验证；
    5. 销售渠道的需求：根据产品通过不同的渠道销售，考虑给这些渠道商创造价值，比如系统集成商与增值转售商既有区别；
    6. 客户和用户的区别：买单的人，与实际用户不是同一个人，他们的需求不能代表最终用户，根据不同角色，要分别进行调研，确保产品价值；
    7. 产品安装：简单和傻瓜安装；
    8. 产品的配置、自定义与集成；
    9. 产品升级：简化升级技术和流程；
    10. 销售策略：因特网的出现，改变了传统的销售方式，多利用新的网络渠道进行销售；
40. 打造平台级产品的经验
    1. 面临着3种角色的人员，分别是：终端用户、应用程序提供商、开发人员；
    2. 其需求各自不同：终端用户关注产品价值，能否解决自己的问题；应用商关心平台生存，别突然倒闭使自己的付出泡汤；开发人员关心平台开发的易用与简单；
    3. 其中最应该优先满足的需求是终端用户，只有受到终端用户认可的平台，才是成功并有可能生存下去的（做不到这一点，其他两项便是浮云无所依附；做好了这一点，则有可能形成繁荣的生态）；
41. 最佳实践经验
    1. 产品管理的职责：不要与项目管理和营销管理搞混了；
    2. 用户体验：好的用户体验是产品的生命；
    3. 机会评估：用简便快捷的方式取代过时的市场需求文档；动手设计产品前，先明确产品要解决的问题，为谁解决，以及评估的标准；
    4. 特约用户：寻找特约用户，让其不断试用和改进；
    5. 产品原则：树立清晰的产品原则，有助于减少团队成员间的分歧；
    6. 人物角色：避免陷入为自己的需求设计的误区，时刻记住产品的目标用户是谁（最好写好后，贴在桌面旁边）；
    7. 探索产品：确保产品的价值、可用性、可行性；
    8. 使用原型：使用高保真原型，三个好处：方便用户试用、方便团队间沟通明确需求；
    9. 用户参与原型测试：通过用户测试验证产品的创意和设计；
    10. 根据数据改进产品：改进产品不是一味增加新功能，而是围绕产品的目标，寻找反映目标的数据指标，追求这些指标的上升；
42. 产品经理的反省清单
    1. 每天要思考的10个问题
    1. 产品能够吸引目标消费者的关注吗？（如果不能，是因为什么，营销不够，还是产品不好？）
    2. 我了解目标用户吗？现有的产品是否得到了他们的认可？（去用户现场调查，以及通过反馈和社区倾听用户的声音）
    3. 产品是否完整？用户对产品的印象如何？销售业绩如何？销售业务是否能够完成？
    4. 产品值钱吗？值多少钱？为什么值这么多钱？用户会选择更便宜的产品吗？
    5. 产品能正常运行吗？
    6. 产品的设计是否人性化，易于操作？（多做可用性测试，多去现场观察用户是如何使用自己的产品的）
    7. 产品的特色是否与目标用户的需求一致？产品的特色是否鲜明？
    8. 产品能够在竞争中取胜吗？面对不可预测的市场变化，产品是否仍然有取胜的把握？（竞争对手的产品的优缺点有哪些，用户为什么喜欢它们，喜欢什么；以及用户为什么不喜欢它们，不喜欢什么）（走出办公室，去用户的现场了解答案）
    9. 产品是否有别于市面上竞争对手的产品？我能否在2分钟内向高管解释清楚区别？1分钟内向客户解释区别？半分钟内向行业分析师解释区别？
    10. 我了解其他团队成员对产品的看法吗？他们的觉得产品如何做才能更好？他们的看法与我的看法是一致的吗?