启示录

过去二十多年， Marty Cagan作为负责定义和开发产品的高级经理人为多家一流企业工作过，包括惠普、网景通信、美国在线。他曾担任eBay产品管理及产品设计高级副总裁，负责规划全球电子商务网站的产品和服务。他亲历了个人电脑、互联网、电子商务的起落沉浮，致力于通过写作、演讲、培训 帮助客户打造富有创意的产品。他在自己的网站上定期撰写博客，分享管理产品的经验。他创办了硅谷产品集团（SVPG），为“财富500强”企业和广大创业型企业提供产品咨询服务，他的客户包括Yahoo!、eBay、TiVo、BBC、PROTRADE Sports……

  • 前言

    • 产品经理的任务是探索产品的价值、可用性、可行性 可用性指的是用户明白如何使用产品，价值指的是用户对产品的渴求程度

    • 用户体验设计就是交互设计、视觉设计（硬件设备则是工业设计）

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

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

      第一部分：人员

    • 第1章 关键角色及其职责

      • 产品经理的主要职责分为两项：评估产品机会、定义要开发的产品
      • 许多公司借助市场需求文档(MRD)来完成审核创意的工作，我更愿意使用一种简化的方法—机会评估
      • 有些公司借助产品需求文档(PRD)来完成定义产品的工作，我主张围绕产品原型来展开这项工作
      • 交互设计师与产品经理密切合作，目标是确保产品同时具有可用性和价值
      • 项目管理的核心任务是制定计划和跟踪进度

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

      • 我一直认为，导致产品失败最根本的原因是公司对产品经理的职责界定不清
      • 定义产品：将产品需求和用户体验设计相结合
      • 由市场营销人员直接定义产品，这种方式忽略了收集详细产品需求的步骤，回避探索产品的艰难过程
      • 产品营销人员负责高层商业需求，产品经理负责低层产品需求这种分工也是错误的，问题在于没人对最终的产品负责
      • 所有成功的产品背后都有一个全权负责定义产品的人

    • 第3章 产品管理与项目管理

      • 产品管理的职责是探索、定义有价值的、可用的、可行的产品；而项目管理则关注如何执行计划以按期交付产品
      • 强有力的项目管理能力是产品经理的优势，至少可以使产品更快进入市场，甚至会决定产品是否面市。但我还是认为产品经理和项目经理应该是两个独立的职位
      • 改善产品和开发流程必须从测量、收集数据开始
      • 项目经理必须清楚何时催促进度，何时向上级汇报，何时需要收集更多信息，何时找个别成员私下交流。判断力很难言传身教，只能靠自己积累经验获得

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

      • 好产品必须提供舒适的用户体验
      • 用户体验设计包括：用户研究 -> 交互设计 -> 视觉设计 -> 原型制作
      • 交互设计师通常用线框绘制产品需求，然后视觉设计根据线框设计可见的用户界面
      • 迅速制作融合了产品经理和设计师创意的产品原型(Demo)，让用户试用
      • 交互设计不能外包，因为：
        • 深入理解用户需求非常费时间；
        • 交互设计师必须深度参与项目开发；
        • 产品的用户体验是公司的核心竞争力；

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

      • 定义正确的产品与正确地开发产品
      • 产品经理只定义满足需求的产品，而不是最终产品
      • 外包不是为了节约成本，而是为了实现合理的人员配置
      • 日益普遍的情形是软件架构师、测试经理、产品经理、设计人员留在公司总部，其他成员分散在各地
      • 选择业务外包的关键是要挑选有能力的员工

    • 第6章 招聘产品经理

      • 如果仅凭经验可以建立信心，为什么许多工作多年的产品经理却毫无自信？
      • 称职的产品经理知道，虽然产品的实现离不开大家的协助，但是他应该对自己的产品创意负责
      • 产品经理的时间应该用来改变现状，而不是疲于奔命参加大小会议、逐一回复邮件
      • 聪明的产品经理不会浪费时间写没人看的东西，一旦决定动笔就要做到最好，言之有物，让人信服
      • 我认为产品经理应该既能与程序员讨论技术，又能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌
      • 最有效的招聘途径是寻找具有上述特质潜力的人，这些人可能藏身于公司内部
      • xixi我甚至认为资深行业经验对产品经理的工作可能是不利的，长期从事某一行业的人通常会落入一种常见的心理陷阱：他们以为自己了解目标客户，盲目自信
      • 熟悉新行业达到自信制定产品策略的程度，只需要两三个月时间
      • 最宝贵的经验不是行业知识或技术（这些都可能过时），而是打造优秀的产品流程、领导产品团队的能力、应对产品扩张的经验、个人对自己的认知，以及自我激励的能力

    • 第7章 管理产品经理

      • 对产品经理的工作唯一正确的评价标准是看产品本身是否成功
      • 最近出现了一种考察业绩的新指标，用户净推荐值（NPS,net promoter score，是否愿意向他人推荐你的产品）,满分是10分

    • 第8章 巴顿将军的忠告

      • 永远不要告诉别人怎么做。告诉他们做什么，他们自然会发挥天赋，给你惊喜
      • 用户体验设计师应该在产品经理分析目标市场、思考解决方案的初期阶段就发挥作用
      • 你留给用户体验设计师和开发人员的空间越大，他们就越有可能打造出用户喜爱的产品

    • 第9章 产品副经理

      • 坦率地把你的烦恼告诉同事，大家会热情的帮助你
      • 许多产品经理不愿意接受这些建议，他们认为如果由别人提出建议，还要产品经理做什么

    • 第10章 管理上司

      • 大公司高管和股东尤其多，让大家朝着同一个目标前进简直难于上青天
      • 做好做无用功的心理准备
      • 向上司借力
      • 多用数据和事实说话

第二部分：

  • 第11章 评估产品机会
    • 市场给予新产品诸多机会，即使成熟的市场也不例外
    • 为了评估产品机会，我要求产品经理回答如下十个问题：
      • 产品要解决什么问题（产品价值）
      • 为谁解决这个问题（目标市场）
      • 成功的机会有多大（市场规模）
      • 怎样判断产品成功与否（度量指标和收益指标）
      • 有哪些同类产品（竞争格局）
      • 为什么我们最适合做这个产品（竞争优势）
      • 时机合适吗（市场时机）
      • 如何把产品推向市场（营销组合策略）
      • 成功的必要条件是什么（解决方案要满足的条件）
      • 根据以上问题，给出评估结论（继续或放弃）
    • 以上问题并不涉及具体的解决方案。机会评估只讨论待解决的问题，不应涉及具体解决方案
    • 产品经理往往把待解决的问题和解决方案在一起考虑，当具解决方案遇到困难时，他们会放弃产品机会
    • 我相信结交一位懂财务的朋友能让产品经理受益匪浅。起码他可以确认商业上的可行性
  • 第12章 产品探索
    • 软件项目可以划分为两个阶段：弄清楚要开发什么产品（定义正确的产品）；开发该产品（正确地开发产品）
    • 在产品探索的阶段，产品经理负责分析各种创意，收集用户需求，了解如何运用新技术，拿出产品原型加以测试，兼顾短期需求和长期规划。总之就是探索出兼顾功能性设计性的产品
    • 一旦完成产品定义进入开发阶段，产品团队就要切换工作重心——开发、测试、发布
  • 第13章 产品原则
    • 产品原则不是产品功能的清单，不依赖于任何单独的产品，它是整个产品线的战略指南
    • 制定产品原则时容易出现两类错误，第一类是原则过于空泛，失去了指导作用；第二类是把设计原则误当成产品原则
    • 产品创意在辩论中可以得到完善。请高官出面决策会激发团队内部矛盾，得不偿失
    • 在我看来，每当团队内出现严重的意见分歧时，并非是对事实的认定有争议，而是对目标和目标的优先级有不同的理解
    • 制定决策的过程和依据必须完全透明，不要让人觉得你只凭直觉判断
  • 第14章 产品评审团
    • 成立产品评审团的目的是决定产品战略方向
    • 它根据研发产品的四个里程碑来评审产品，制定决策：
      • 评审产品战略和产品路线图，启动评估产品机会的工作
      • 根据机会评估的结果决定是否开始定义产品的解决方案
      • 评审产品原型、用户测试结果、成本估算等，决定是否开发产品
      • 评审最终产品、产品品质、发布计划等，确定是否发布产品；
    • 产品评审团不负责评审对产品细节的更新和修正
  • 第15章 特约用户
    • 为了解决两个问题——既深入洞察目标用户的需求，又赢得用户对产品的推荐，我建议征集特约用户协助完成产品研发
    • 如果在寻找特约用户时遇到困难，很可能是因为产品要解决的问题不像产品经理想的那么重要，将来也很难销售出去
    • 我们很容易把产品尝鲜者误当成特约用户
    • 如果公司不允许你直接与用户交流，你一定要尝试改变这个政策
    • 从呆板的报告里是不可能洞察用户需求的
    • 唯有理解用户需求的工作，产品经理不能推诿他人
    • 与用户打交道的过程中，你会发现一些富有洞察力、善于思考的用户，应设法与他们建立长期联系
  • 第16章 市场调研
    • 市场部门夸大了市场调研的作用，而产品部门只看到其局限性
    • 市场调研的工具和方法：用户调查、产品使用分析、数据挖掘、拜访用户、人物角色、可用性测试、同类产品分析
    • 市场调研的局限性——市场调研不能直接回答最根本的问题：打造什么产品
    • 成功的产品基于以下两点认识：深入理解用户需求，以及明白什么样的解决方案在现阶段是可行的
    • 用户研讨会上不可能讨论出成功的产品：1、用户不知道什么样的想法是可行的；2、用户不知道自己想要什么
  • 第17章 产品人物角色
    • 要打造成功的产品必须保证大部分决策是正确的
    • 人物角色又称为用户特征记录，重点关注用户的行为、态度、目标
    • 人物角色的主要用途如下：
      • 可以用来筛选重要的产品功能
      • 可以避免把自己的需求当成用户需求
      • 有助于对用户类型的优先级进行排序
      • 可以方便地向团队描述产品的目标用户是谁，怎么样使用产品
      • 可以帮助团队成员达成共识
    • 与目标用户面对面交流是创建人物角色必不可少的环节
    • 实际使用产品不可能完全与关键人物角色的设定相符，所以还需要测试范围以外的用户
  • 第18章 重新定义产品说明文档
    • 产品说明文档包含的范围很广，有产品需求文档、市场需求文档、业务需求文档、功能规格书等等
    • 虽然花费了大量时间撰写，却很少有人阅读。更要命的是，对管理层和产品团队来说，产品说明文档很容易成为一个幌子，仿佛一切都进展顺利
    • 产品说明文档应该满足以下要求：
      • 完整地描述用户体验；
      • 准确的描述软件的行为；
      • 直观的把产品信息和产品行为告诉所有人；
      • 可以修改；
      • 有一个主体来代表产品；
    • 在我看来，只有一种形式的产品说明文档可以满足以上所有要求，那就是高保真原型
    • 如何展示补充的说明文档也值得考虑，最理想的方法是在原型上增加注释
    • 高保真原型最突出的优势是可以用于测试。把它放到真实用户面前，观察他们是否清楚如何使用（可用性），是否渴望使用你的产品（价值）。只有通过这两项测试，产品说明文档才算合格，产品才值得开发。
    • 与其花几个星期撰写冗长的文档，既没人读，也无法测试，还不如和设计师一起创建产品原型
  • 第19章 用户体验设计与实现
    • 我一直认为需求调研和产品设计是相互影响的，应该同步展开
    • 我认为验证设计思路必须使用高保真原型
    • 虽然需求调研和产品设计可以同步展开，产品开发和测试可以交叉进行，但是用户体验设计应该在软件的开发前完成
    • 尽管我提倡需求调研和产品设计都要在软件开发前完成，但是至少应该邀请一位软件开发人员检查设计工作
  • 第20章 基本产品
    • 不再试图定义最终产品，而定义只满足基本要求（价值、可用性、可行性）的产品，简称基本产品
    • 开发出来的产品让人不满意，其实这是不合理的流程造成的结果
    • 产品经理设计师合作设计产品的高保真原型，应该只具备实现商业目标的最基本功能要求
    • 请真实用户验证产品原型至关重要。一旦基本产品确定，通过了目标用户的测试，就不可能再削减任何功能，否则说明你定义的不是基本产品
    • 如果出现开发时间不够的情况，只能延长工期，因为你已经没有东西可削减了
    • 设计高保真原型能使产品经理改掉随意修改的坏毛病
  • 第21章 产品验证
    • 产品经理向产品团队提供最终的产品说明文档前，需要进行以下三项重要的验证：
      • 可行性测试：在现有的技术条件下能否成功开发出产品；
      • 可用性测试：请真实的用户来使用原型，让不同类型的用户都能明白如何使用；
      • 价值测试：用户是否觉得你的产品有用，是否愿意购买；
    • 争论使用高保真原型还是低保真原型已经没有意义了，因为使用高保真原型的成本已经大大降低，而通过它得到的反馈信息物超所值
  • 第22章 原型测试
    • 应该把高保真产品原型当作描述产品的最基本方式
    • 产品可用性测试、产品价值测试同样重要
    • 要避开过于亲密的人和科技行业的从业者，除非他们就是目标用户
    • 测试原型前还有一件事要做，即观察测试者能否从原型首页看出产品要解决什么问题
    • 首页的设计极大地影响着实际使用效果与用户期望之间的差距。
    • 测试者遇到功能上不完整的死胡同，问问他们接下来希望发生什么
    • 远程测试无法观察用户的表情和肢体动作，而这些包含着重要的信息
    • 用户如果知道自己想要什么，设计产品就不会这么麻烦了。所以应该多观察用户的操作，少听他们的抱怨
    • 测试的作用是发现原型与用户期望不一致或不相容的地方
    • 如果没法让测试者对原型产生兴趣或无法让原型变得足够简单易用，应该马上放弃这个产品创意
  • 第23章 改进现有产品
    • 大多数产品团队实际上只是功能加工厂，附带补丁制作，修补缺陷
    • 改进产品不是简单地满足个别用户的需求，也不能对用户调查的结果照单全收。能提高指标的功能才是你关注的重点
  • 第24章 平滑部署
    • 通常情况下，用户不喜欢变化
    • 不能因为用户可能反感就放弃更新产品，但更新产品时必须谨慎、理智
    • 平滑部署的方式有很多，比如发布两个并行的版本，邀请有兴趣、有时间的用户试用新版本
    • 另一种平滑部署的方式是区域性逐步部署，然后逐步扩大范围
    • 还有一种方式是增量部署，将更新项分割成几个较小部分逐步发布
  • 第25章 快速响应阶段
    • 产品发布后，大多数公司会急于撤走资源投入下一个项目，而此时正是收集反馈信息、改进产品的最佳机会
    • 产品发布几天至一周内，所有项目成员应留出时间作为快速响应阶段
    • 关键不在于是否会出现问题，而在于能多快解决问题
    • 评估产品表现应该使用明确的、可量化的指标。对于什么样的结果代表产品成功或失败，应该心中有数
  • 第26章 合理运用敏捷方法
    • 敏捷方法(Scrum)起源于定制软件领域，而不是产品软件领域。但我认为同样适用于产品软件的开发，只是要做出相应的调整。敏捷方法唯一不适合产品软件的地方是在架构设计方面
    • 敏捷方法鼓励人们不要拘泥于传统的开发流程，要相信简单重构和快速重新设计架构的优势。这对于多数定制软件可行，但对于大众网络服务就不可能了
    • 产品软件领域使用敏捷方法的诀窍：
      • 产品经理即是产品负责人
      • 使用敏捷方法绝不等于省略产品规划，只不过在敏捷环境里，规划周期应该适度缩短，反复迭代
      • 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期。不能一边设计一边开发
      • 尽量把产品设计工作拆分成独立的部分，但也不能太细，采用迅速制作原型的方法能更适应敏捷环境
      • 产品经理的主要任务是定义有价值、可用的产品原型和用户故事，作为开发的基础
      • 用产品原型和用户故事代替产品文档有三个优势：
        • 1、可以请用户测试；
        • 2、强迫产品经理全面认真地思考问题；
        • 3、向开发团队明确描述每次迭代周期要完成的任务；
      • 让开发人员自主划分迭代周期。好的原型可以提高估算工作量和开发时间的精度
      • 晨会是一天沟通过程的开始而不是结束，关于产品的讨论会持续一整天
      • 除非达到产品经理的要求，否则不要轻易发布新版本
      • 在团队内展开敏捷培训
    • 迭代初期开发的产品应该用作原型吗？No：1.花的时间太长；2.不应在产品探索阶段占用开发团队太多时间；3.一旦进入开发阶段，想改变产品设计思路就很难了
    • 要想转型成敏捷开发团队，必须理解产品软件与定制软件的差别
  • 第27章 合理运用瀑布式开发方法
    • 传统瀑布式开发的理念主要有两点：
      • 采用阶段式开发——软件开发过程被分成固定的几个阶段：撰写需求文档、设计高层软件架构、设计低层细节、编写代码、测试、部署
      • 采用阶段式评审——每个阶段结束后，对该阶段的结果进行评审，通过后才能进入下一阶段
    • 瀑布式开发的优点：
      • 流程具有可预测性，因而深受管理层欢迎；
      • 每个阶段结束时都会提交书面材料，让人觉得所有工作都是经过深思熟虑的，增强人们对项目的信心；
    • 瀑布式开发的缺点：
      • 产品验证严重滞后，这是最严重的问题；
      • 变更计划代价不菲；
      • 无法适应快速的市场变化；
    • 如果不得不使用瀑布式开发，产品经理应该设法规避以上问题，首要的工作是在探索/定义产品阶段，制作产品原型，请目标用户试用
  • 第28章 创业型公司的产品管理
    • 关键在于产品探索
    • 创业初期只设三个职位：产品经理、交互设计师、制作原型的人，相互兼顾也可以，只要有人负责这三项工作即可
    • 产品设计流程有两个关键点：
      • 1.创建体现用户体验的高保真原型；
      • 2.邀请真实的目标用户验证产品原型。
    • 这种流程的优势在于可以获得通过市场检验的产品设计
    • 确定产品原型后，再招聘程序员进行开发
  • 第29章 大公司如何创新
    • 随着规模变大，公司会不可避免地变得更加保守，不敢冒险。因为一旦失败，大公司的损失会惨重得多
    • 有两大因素影响着大公司的创新氛围：企业文化和老板的观念
    • 谷歌的程序员有20%的工作时间可以用来从事创新研究
    • 人们误以为优秀的产品是战略规划的结果，或是来自公司高管的创意。其实最好的创意大多来自普通的员工
    • 在大公司里，普通员工很难凭空获得允许，如果能拿出阶段性的成果来，获得许可会容易很多
    • 观察和倾听是最简单的创新途径。仔细观察用户使用公司产品或同类产品的一举一动，留心他们欣喜和失望的表情。注意，应该选择实际用户作为观察对象
    • 创新不是发现新问题，而是用新方法解决已有的问题。观察人们对现有产品的不满，是创新的最佳途径
    • 另一种创新途径是跳出技术局限，完善用户体验。找到用户失望的地方，就找到了创新的机会
    • 收购是有效维持创新的手段，创业型公司如雨后春笋般出现，经过市场淘汰，留下来的通常都有其特长，可以作为收购对象
  • 第30章 在大公司施展拳脚
    • 大公司的现实情况：
      • 大公司都遵循一条潜规则——尽量规避风险
      • 为了节约成本，多数大公司都采用矩阵式管理，核心部门比如设计、开发、测试等部门是共享资源，产品经理要争取到足够的资源才能研发出产品
    • 在大公司施展拳脚的方法：
      • 知道决策权在谁手里，需要公司的支持，只需要说服他就行；
      • 找三五个志趣相投的同事在工作之余做出产品原型（臭鼬工程）。数不清的优秀产品经理是这样诞生的；
      • 会前沟通，形成默契。在重要的决策会议上如果有人公开反对你的提议，会变得非常被动
      • 乐于分享信息。信息俨然变成了某种货币，大家只想获取，不愿支出
      • 传播产品理念
    • 但大公司也有大公司的优点，产品会获得媒体和用户的高度关注

第三部分：

  • 第31章 苹果公司给我的启事
    • 苹果公司有很多值得学习的经验，但我认为以下四点最重要：
      • 硬件为软件服务
      • 软件为用户体验服务 所有公司都把用户体验挂在嘴边，只有苹果公司把它放在心里
      • 用户体验为情感服务 苹果公司比谁都清楚是什么让消费者为产品疯狂，他们知道怎样抓住用户的情感需求
      • 产品为真正的需求服务 十几年不变的语音邮件系统、不兼容的地址簿、蹩脚的浏览器，苹果公司逐一完善这些功能，成功的产品应运而生
  • 第32章 提防有特殊要求的产品
    • 特例产品到底有什么问题呢？它混淆了客户需求和产品需求，必然会使公司偏离正轨
    • 产品需求不能用户说了算：
      • 第一，用户很难知道自己需要什么；
      • 第二，用户不知道什么样的产品是可行的；
      • 第三，需求很难统一
    • 耗费精力添加特殊功能，必然会耽误更重要的工作，带来的长远损失并非这点蝇头小利所能填补的
    • 签订合约后，产品就被合同绑住了
    • 关键时刻根据产品原则决定是否接受客户提出的特殊要求
    • 客户在描述需求时，习惯提出自己的解决方案，但不一定抓住了需求的本质
  • 第33章 新瓶装老酒
    • 成功的产品往往只是新瓶装老酒，但这个新瓶做得更好更方便更便宜，改变了消费者对老酒的印象
    • 想在成熟的市场抢占一席之地，公司至少要手握两件法宝：
      • 对目标市场了如指掌，对现有产品的缺陷洞若观火
      • 跟踪最新的技术趋势
    • 优秀的产品经理应该抓住现有技术与用户需求的契合点
  • 第34章 恐惧、贪婪、欲望
    • 产品经理每天的工作和研究人类情感的心理学有关
    • 消费者购买产品大多源于情感需求
    • 只有从情感的角度重新观察市场上的产品和服务，你才能体会用户的真实感受
    • 明确目标用户的情感需求后，问问你自己谁还能满足用户的这种需求，他们才是你真正的竞争对手
    • 许多情况下，你的竞争对手不是创业型公司和大型门户网站，是大众的线下生活方式
    • 要坚信现在的创新机会肯定比以前多，因为
      • 只要市场上还有蹩脚的产品，就有机会；
      • 技术会不断发展，今天难以置信的创意，明天也许就能实现；
      • 现有的应用程序为将来的发展打下基础，这是行业规律；
  • 第35章 情感接纳曲线
    • 不同类型的用户具有不同的情感需求，除了用技术接纳曲线模型描述用户外，还应该增加一种情感接纳曲线作为补充
    • 愤怒的用户决定着产品未来的方向，如果能解决日常生活中让大众烦恼不堪，又不得不应付的事情，一定能打造出成功的产品
    • 不要一味从技术角度看待产品，多从用户的角度考虑问题
    • 我根据消费者的情感特征，把他们分成以下几类：
      • 技术爱好者
      • 非理性消费者(尝鲜者)
      • 理性消费者(早期消费大众)
      • 超理性消费者(后期消费大众)
      • 观望者(跟随者)
    • 这几类人中，非理性消费者最值得产品经理注意；而技术爱好者是最没有参考价值的人群，他们会误导产品经理
    • 产品经理应该关注失望、不满、愤怒等一切负面的情绪
    • 成功的产品需要满足某种情感需求，而某些领域（比如网络摄像头）没有太多不满的情绪可以利用
    • 位于马斯洛的金字塔模型低端的是最基本的人性需求，充分挖掘这些情感，产品离成功就不远了
    • 安全需求最容易让人们言听计从，而模型顶端的精神需求收效肯定不佳
    • 新生测试：如果你带着新生的感觉去挖掘每天折磨着大众的情感——孤独、恐惧、挫折、不满，那离发现新产品的日子就不远了
  • 第36章 可用性与美感
    • 交互设计与视觉设计完全是两回事，有的网站美轮美奂，用起来却让人抓狂。但大部分团队却认为只要招聘一位设计师，就能完成这两项工作
    • 视觉设计可以满足用户的情感需求
  • 第37章 大众网络服务
    • 可用性
    • 人物角色
    • 平滑部署
    • 用户社区管理
  • 第38章 打造企业级产品的经验
    • 小型工作室、家庭办公室和其他小企业，更适合被划入个人消费市场而不是企业市场。很多公司在小企业市场进行过尝试大都以失败告终，原因是他们没认识到这一点
    • 很少企业开发这类软件时会进行交互设计、视觉设计和可用性测试
    • 公司总以为客户可以直接告诉他们需求，这种想法大错特错
    • 并不是说客户的话不能听，相反，应当多见客户，虽然他们不能直接给出产品需求，但他们能帮助你确定产品需求
    • 要考虑销售渠道的需求，确保产品不会耗费他们过多的时间
    • 客户的需求不代表最终用户(产品使用者)的需求
  • 第39章 打造平台产品的经验
    • 产品管理中难度最大也最能体现产品经理实力的是定义成功的平台产品，因为要面对三种不同的客户：
      • 应用软件供应商(使用平台的公司)
      • 开发人员(软件供应商的雇员)
      • 终端用户(应用软件的使用者)
    • 应用软件供应商关心平台的生存能力；开发人员则更关心平台产品是否支持自己惯用的开发语言、工具、架构；终端用户只在意最终结果
    • 忽略终端用户的需求，把开发人员摆在第一位，这是普通存在的误区。只有让终端用户满意，平台产品才是成功的
    • 很多成功的平台产品都是开发人员的噩梦，却获得广大终端用户和应用软件供应商的青睐
    • 管理平台还有其他的困难，没有统一的交付形式、客户定制要求多种多样。技术支持是管理平台的另一个难点
    • 但平台产品的潜在能力巨大，围绕产品会形成一个繁荣生态系统，实现各方面共赢的局面

总结

  • 第40章 最佳实践经验
    • 打造富有创意产品的十大要点：
      • 产品管理的职责
      • 用户体验
      • 机会评估
      • 特约用户
      • 产品原则
      • 人物角色
      • 探索(定义)产品
      • 使用高保真原型
      • 用户参与原型测试
      • 根据数据改进产品
  • 第41章 产品经理的反省清单
    • 产品经理应该时刻思考的十大问题：
      • 产品能吸引目标消费者吗
      • 设计是否人性化
      • 能在竞争中取胜吗
      • 我了解目标用户吗
      • 是否有别于市面上其他产品
      • 能正常运行吗
      • 产品是否完整
      • 产品特色是否与目标用户需求一致
      • 产品值钱吗
      • 我了解其他团队成员对产品的看法吗