《启示录》摘记
###启示录:打造用户喜爱的产品【美】Marty Cagan
—–前言——
2014-08-31 02:29:07 所以我把范例都放在网上(www.svpg.com),所有在线资料都免费,也无须注册。网络可以实时更新,随时加入新的范例,这是书本无法做到的。
——第1章 关键角色及其职责——
2014-08-31 02:30:49 产品经理的主要职责分为两项:评估产品机会(product opportunity);定义要开发的产品。
2014-08-31 02:32:47 项目管理的核心任务是制订计划和跟踪进度。
2014-08-31 02:34:23 如果采用火车模型发布模式(以固定的周期持续发布产品,如果某项既定功能未完成,就挪到下个周期发布的开发方法),必须为每次产品发布(通常这类产品由多个项目组成)配备专职的项目经理。
——第4章 产品管理与产品设计——
2014-08-31 02:40:30 用户研究 专门研究、分析用户,评估产品或产品原型是否符合特定用户的使用习惯。其具体工作包括拟订恰当的测试项目,监督测试,评估测试结果,提出改进方案。
2014-08-31 02:40:40 交互设计 在理解目标用户的基础上设计有价值的、可用的目标功能、用户导航和产品使用流程。交互设计师通常用线框绘制产品需求,然后交给视觉设计师。
2014-08-31 02:40:57 视觉设计 根据线框设计可见的用户界面(页面),包括严格的布局、颜色和字体设置等。视觉设计能够传达并唤起产品蕴含的情感(其重要性常常被低估)
2014-08-31 02:41:08 原型制作 迅速制作融合了产品经理和设计师创意的产品原型,让用户试用,并根据反馈意见反复修正原型。
——第5章 产品管理与软件开发——
2014-08-31 02:48:27 形成合作关系的关键是双方承认彼此平等——任何一方不从属于另一方
2014-08-31 02:49:00 你要求开发团队完成任务,必须先取得他们的认可,确信为了达到产品质量标准必须这么做;开发团队也要留给你足够的空间,设计有价值、可用的产品。
2014-08-31 02:50:03 开发人员帮助产品经理完善产品定义的方式有如下三种。 1. 让开发人员直接面对用户或顾客,体会用户的困惑和疑虑,了解问题的严重性,这样好点子常常会随之而来,譬如,可以邀请一名开发人员参加产品原型测试。 2. 向开发人员了解最新的技术发展动向,讨论哪些新技术可以用到产品里。开展头脑风暴,看看目前已实现的技术或即将实现的技术能不能解决手头的问题。 3. 让开发人员在探索(定义)产品的初期阶段参与评估产品设计,协助策划方案。产品经理常犯一类错误,即完成产品定义后,便扔给开发团队,置之不理。这样做只会贻误协调需求与可行性的最佳时机,等到发现问题时,为时已晚。
2014-08-31 02:50:57
- 产品经理只定义满足基本要求的产品(参见第20章)。产品经理应该意识到,自己要定义的不是最终产品,而是满足基本要求的产品。只有这样,产品管理与软件开发之间才能形成良好的互动。 2. 一旦产品进入开发阶段,要尽可能避免修改产品的需求和设计。虽然有些事情超出你的控制范围,导致项目波动是不可避免的(开发人员也能理解),但是千万不要在此时尝试突发奇想的点子。 3. 产品开发阶段难免会产生诸多问题,比如,用例丢失,用例设计考虑不周全等,这很正常,最优秀的团队也避免不了。产品经理应该迅速采取行动,在维持产品基本功能、尽量避免修改的原则上,拿出解决方案。
2014-08-31 02:56:47 你需要预留一定的技术能力,eBay称为余量(headroom)。很多因产品迅速膨胀产生的问题都与扩展规模有关,余量意味着避免触及技术能力的上限,为用户数量的增长预留空间,为事务增长预留空间,为新增功能预留空间,保证产品的技术构架能够满足团队的要求。
2014-08-31 02:57:19 与开发团队合作应该遵循以下原则:在产品管理上为开发团队预留20%的自主时间,让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中
2014-08-31 02:57:30 有缺陷的部分,或者更换数据库管理系统,提高系统性能,避免“需要停下来重写代码”的情形发生。
2014-08-31 02:58:35 重写代码时,保证让用户看到功能的改进——即使会占用少则25%,多则50%的开发资源——对保持产品(尤其是互联网产品)的市场占有率至关重要。
——第6章 招聘产品经理——
2014-08-31 02:59:34 辨别这种特质很容易,可以让应聘者谈谈自己最喜欢的产品及喜欢的原因,聊聊不同领域的产品和他讨厌的产品,问问对方,如果有机会,他打算怎样完善自己最喜欢的产品。热情是难以伪装的,虚伪的做作毕露无遗。
2014-08-31 03:04:12 熟练、迅速地区分重要任务和紧急任务,合理地规划和安排时间是产品经理必备的技能。
——第7章 管理产品经理——
2014-08-31 03:14:39 它的原理如下。调查用户是否愿意向他人推荐你的产品,满分是10分。选择9~10分的客户称为推荐者(他们会告诉朋友非常喜欢产品,相当于在为你做宣传推广);选择7~8分的是中立分子;选择0~6分的称为贬损者,他们不但不推荐产品,反而会在朋友面前诋毁产品。计算出推荐者所占的比例,再减掉贬损者的比例,就得到了NPS,它反映用户对产品的态度。
——第11章 评估产品机会——
2014-08-31 03:23:33 为了评估产品机会,我要求产品经理回答如下十个问题。 1. 产品要解决什么问题?(产品价值) 2. 为谁解决这个问题?(目标市场) 3. 成功的机会有多大?(市场规模) 4. 怎样判断产品成功与否?(度量指标或收益指标) 5. 有哪些同类产品?(竞争格局) 6. 为什么我们最适合做这个产品?(竞争优势) 7. 时机合适吗?(市场时机) 8. 如何把产品推向市场?(营销组合策略) 9. 成功的必要条件是什么?(解决方案要满足的条件) 10. 根据以上问题,给出评估结论。(继续或放弃)
——第13章 产品原则——
2014-08-31 03:35:37 制定产品原则意味着决定什么重要、什么不重要,哪些原则是根本的、战略性的,哪些是临时的、战术性的。
2014-08-31 03:42:42 在作产品决策之前,应该先确定决策要解决什么问题,让大家在以下几个要点上达成共识。 1. 究竟要解决什么问题? 2. 要为哪类人物角色解决这个问题? 3. 产品要达到什么目标? 4. 每项目标的优先级是什么?
2014-08-31 03:43:39 务必认真分析产品目标的优先级(从最重要到最不重要逐项排序),让团队达成共识。切不可囫囵吞枣地把所有目标都贴上“关键”和“重要”的标签。一定要区分什么最重要,什么第二重要……
——第14章 产品评审团——
2014-09-01 17:42:23 总而言之,我建议分两个阶段进行成本估算。在评估产品机会时做粗略估算;根据最终的产品说明文档做详细估算。
——第15章 特约用户——
2014-09-01 17:45:59 为了解决这两个问题——既深入洞察目标用户的需求,又赢得用户对产品的推荐,我建议征集特约用户(也叫用户顾问委员会、用户评审团)协助完成产品研发。
2014-09-01 17:54:26 如果是互联网服务,特约用户的人数应该增加至10~15人,不过要保证产品经理有精力充分了解每位特约用户,以及他们使用服务的环境(家或办公室)。设计和规划网站时很容易犯一类错误,即对用户需求把握不够,收集的用户反馈信息不充分,直到项目尾声才发现产品的定位有问题。
2014-09-01 17:57:54 使用特约用户是确保产品不偏离用户需求最简单有效的办法,同时也是向潜在用户宣传、推荐产品的最佳手段。
——第16章 市场调研——
2014-09-01 18:14:51 市场部门与产品部门往往存在意见分歧。争议的焦点是市场调研工具和市场调研方法在探索(定义)产品中所起的作用。这些工具和方法包括用户研讨会、用户调查、产品使用分析、拜访用户、可用性/现场测试、同类产品分析。
2014-09-01 18:17:08 用户调查 网络降低了用户调查的难度,提高了调查的效率,以至于现在几乎所有产品都要求做用户调查。做用户调查要注意两点。第一,设计调查问卷需要技巧和经验,不是一件容易的事。要结合具体情景,仔细设置问题,如果调查问卷措辞不清、先入为主,其他部门的同事就会质疑调查结果。第二,调查结果为获得解决方案提供了一条途径,但不是解决方案本身。哪怕所有用户都回答喜欢X特性,我们还是可以通过提供Y特性更实际地解决他们的需求。
2014-09-01 18:17:45 产品使用分析 如果你的产品是网站,有很多实用的工具可以分析用户访问网站的行为。这些工具正确安装和配置后即可使用,非常划算。越早使用分析工具越好,不断地观察学习,然后调整产品。如果你的产品不是网站,可以在产品中添加分析工具,记录用户使用产品的行为。应该明确告知用户分析工具的用途,声明只收集统计数据,不涉及用户隐私。这样做虽然麻烦,但很值得。
2014-09-01 18:18:20 数据挖掘 收集数据的渠道很多,除了上面提到的产品使用分析,还有用户的账单和账户信息、产品数据等。新的数据分析工具的功能越来越强。想知道同时使用几项服务的用户性别比例?想知道特定人物角色的活跃程度和分布情况?新的数据分析工具可以轻松回答这类问题。
2014-09-01 18:18:40 拜访用户 没有一种方法可以替代前往用户使用产品的场所(家、办公室)实地考察的作用。虽然拜访用户成本高、耗时长,但我每次都能收集到从其他途径无法了解的信息。拜访用户很有效,但出于对资金和时间成本的考虑,建议谨慎使用。
2014-09-01 18:19:38 人物角色 我喜欢在定义和设计产品的过程中使用人物角色。市场调研也可以借助人物角色展开。请记住,你要面对的绝不是单一类型的用户,务必找出若干主要用户类型,深入了解他们,弄清哪些是当前的用户,哪些是潜在的用户。具体内容请参考第17章。
2014-09-01 18:19:48 可用性测试 我主张尽早、反复地进行可用性测试(请参考第22章)。观察用户使用现有产品的反应,收集反馈意见,了解他们的真实想法。从用户的视角重新审视产品,不光阅读反馈信息,更要观察、记录用户的行为和反应(比如兴奋、沮丧)。现在还有工具带有远程功能,可以在异地进行可用性测试,记录、分析用户行为。
2014-09-01 18:20:09 同类产品分析 产品团队常常低估了竞争对手。就我的经验而言,每款产品都有做得好的地方。有必要找出竞争对手的优势,学习对手的成功经验。
2014-09-01 18:20:25
- 谁是目标用户? 2. 用户会怎样使用产品? 3. 用户能想明白怎样使用产品吗?障碍在哪里? 4. 用户为什么选用你的产品? 5. 用户喜欢产品的哪些特点? 6. 用户希望如何改进产品,增加哪些功能?
2014-09-01 18:21:58 探索(定义)产品的过程则要回答如下问题。 1. 采用什么技术来更好地解决产品要解决的问题? 2. 设计什么样的用户体验?
2014-09-01 18:22:21 成功的产品基于以下两点认识:深入理解用户需求,以及明白什么样的解决方案在现阶段是可行的。
2014-09-01 18:24:02 虽然组织用户研讨会可以面对面了解目标用户对产品的看法,但我保证在用户研讨会上不可能讨论出成功的产品。为什么?有两个根本原因。
2014-09-01 18:25:04 用户研讨会还有其他弊端。 1. 人群聚集时容易冲动,相互影响,难以获取每个用户的真实想法,取而代之的是那些善于表达者的一家之言。 2. 除非让用户试用实际产品,否则他们不清楚自己想要什么,而通常组织用户研讨会时产品还没有眉目。 3. 与用户调查一样,组织用户研讨会也需要经验。主持人不但要熟悉组织技巧,能随机应变,还得掌握产品领域的知识,擅长引导话题,才能获得预期的效果。这样的人实在是可遇而不可求。
——第17章 产品人物角色——
2014-09-01 18:32:30 没接触真实用户之前,我不会先入为主地下结论。与目标用户面对面交流是创建人物角色必不可少的环节。
——第18章 重新定义产品说明文档——
2014-09-01 18:35:07 产品经理的核心责任是确保向开发团队交付具有成功潜力的产品说明文档。
2014-09-01 18:35:56
- 产品说明文档应该完整地描述用户体验——不只是用户需求,还包括交互设计和视觉设计。
2014-09-01 18:36:42
- 产品说明文档必须准确地描述软件的行为。文字和图片的表达能力实在有限,不足以完成这项任务。
2014-09-01 18:36:47
- 产品说明文档的受众较广——开发人员、测试人员、客服人员、市场营销人员、运维人员、销售人员、管理层等等。
2014-09-01 18:37:46
- 撰写产品说明文档的过程中会出现许多衍生物,比如,按优先级排列的需求列表、线框图、实体模型,但应该有一个主体来代表产品,避免混淆不清,版本错乱。
——第19章 用户体验设计与实现——
2014-09-02 02:52:26 在软件开发过程中,有很多工作可以同时进行。比如,我一直认为需求调研和产品设计(用户体验设计)是互相影响的,应该同步展开。我不喜欢老式的瀑布式开发模型,产品经理先完成需求调研,然后交给交互设计师设计。业界已经认识到这是一种陈旧的产品开发思路。
——第21章 产品验证——
2014-09-04 01:41:18 可行性测试 首先要明确在现有的技术条件下,能否成功开发出产品。邀请架构师和开发人员深度参与技术调研,寻找可行的方案。有些方案通向死胡同,但总有些是可行的。
2014-09-04 01:43:37 可用性测试重在观察用户如何设法完成必要的操作,而价值测试重在观察用户是否喜欢这些功能,是否满意功能的具体实现方式。
2014-09-04 01:44:49 使用原型并非验证产品(尤其是互联网服务)的唯一方式,还有其他简单有效的方法,但它们都强调在正式开发软件前验证产品设计,因为设计总有考虑不周、出人意料的情况。
——第23章 改进现有产品——
2014-09-04 01:59:31 先考虑可以从哪些方面改善用户体验。比如,注册阶段是否需要详细的用户信息?用户放弃注册,多半是因为他不确定是否该把这些信息托付给你。
——第25章 快速响应阶段——
2014-09-04 02:04:46 页面访问量、注册用户数、访问停留时间、会员转换率、订阅数,还是广告收益
——第26章 合理运用敏捷方法——
2014-09-04 02:16:38 产品经理的主要任务是定义有价值、可用的产品原型和用户故事(user story),作为开发的基础。用产品原型和用户故事替代厚厚的产品需求文档和功能说明文档有三个优势:①可以请用户测试;②强迫产品经理全面认真地思考问题;③向开发团队明确地描述每次迭代周期需要完成的任务。
——第33章 新瓶装老酒——
2014-09-05 15:12:18 想在成熟的市场抢占一席之地,精明的公司至少要手握两件“法宝”。 第一,对目标市场了如指掌,对现有产品的缺陷洞若观火。我喜欢通过产品可用性测试掌握产品情况(包括自己的产品和竞争对手的产品)。 第二,跟踪最新的技术趋势。新技术层出不穷,让之前无法实现的方案变得可能。虽然谁都没有把握永远走在技术的前列,把最新的技术融入产品设计中,但是只要做到一次,你的产品将所向披靡。
——第34章 恐惧、贪婪、欲望——
2014-09-05 15:13:33 企业级消费者出于恐惧和贪婪购买产品:如果不买这款产品,竞争对手会超过我,黑客会攻破我的防火墙、客户将弃我而去;如果买了,我会赚得更多、省得更多。
2014-09-05 15:13:49 大众消费者购买产品的原因更多样化:使用这款产品(登录这个网站),我就有机会交到朋友(化解孤独),或者找到约会对象(满足爱的需求),或者大挣一笔,或者展示我的照片和音乐(满足自豪感)。
2014-09-05 15:14:36 另外别忘了,不同类型的用户有着不同的情感需求。同是eBay的消费者,出手阔绰的买家、专门寻找打折商品的买家、寻求竞价刺激的买家……他们的情感需求是不一样的。
2014-09-05 15:14:32 每次开展原型测试,除了观察测试者能否顺利使用产品外,还应该趁机了解测试者的情感需求(是什么驱动他使用产品),怎样才能更好地满足他的情感需求。
——第35章 情感接纳曲线——
2014-09-05 15:23:37 我根据消费者的情感特征,把他们分成技术爱好者、非理性消费者、理性消费者、超理性消费者和观望者
2014-09-05 15:23:51 技术爱好者(即技术创新者)购买产品,仅仅是因为产品采用了新的技术。这类消费者容易误导产品经理,因为他们的需求与普通大众的不同。他们对技术本身很痴迷。
2014-09-05 15:24:04 非理性消费者(即尝鲜者)的情感需求与大众的相同,但是更强烈。愤怒、恐惧、孤独这类消极情绪被放大后,会导致非理性的消费行为。在生活中,非理性消费者为了满足情感需求,会付出大大超出解决问题本身所需要的精力和成本。
2014-09-05 15:24:26 普通大众具有和非理性消费者同样的情感需求,只是在程度上没有那么强烈。随着产品的完善,他们也会逐步加入消费队伍。 理性消费者(即早期消费大众)只会购买他们认为实用、成熟的产品。他们更务实,只会购买性价比合适的产品。 超理性消费者(即后期消费大众,也是雅虎的核心用户群)的情感需求更弱,哪怕产品有半点不合意,他们都不会掏钱。 观望者(即跟随者)约占总人数的15%,他们同样有需求,但只会购买公认好用的产品。 在这几类人中,非理性消费者最值得产品经理注意。
2014-09-05 15:24:41 对产品经理来说,技术爱好者是最没有参考价值的人群。
2014-09-05 15:25:14 技术爱好者购买普锐斯(Prius)只是因为他们喜欢新的电池技术。 非理性消费者也甘愿花两万美金购买普锐斯,因为他们是狂热的环保主义者。他们完全可以把购买普锐斯的钱用在别的地方,比如买一辆摩托车,一样可以为减少温室气体的排放做出贡献。他们急于解决问题的迫切心情促使他们为昂贵且不实际的解决方案买单。 产品经理应该注意研究非理性消费者的行为,避免被技术爱好者误导。 大众不会因为痴迷电池技术购买产品,他们的消费动机与非理性消费者类似。
2014-09-05 15:25:36 非理性消费是对不满情绪的过度反应,是放大后的情感需求在“作祟”。非理性消费者夸大了产品的价值,产品经理如果深入了解他们的想法和感受,就能抓住这种情感需求。 非理性消费者能帮助产品经理发现产品的内在价值。 非理性消费者内心弥漫着强烈的不满情绪,这种情绪可能会慢慢减弱,但不会消失。技术爱好者并不关心产品要解决的问题,吸引他们的是产品采用的新技术。
2014-09-06 02:02:12 市场营销部门常常简单地用人口统计的方法来划分情感人群,比如,认定非理性消费者由18~30岁的男性构成。这是不对的。在金融领域,非理性消费群体主要由退休女性构成。不同的产品有不同的非理性消费者,不能一概而论。
——第37章 大众网络服务产品——
2014-09-06 02:13:31
- 人物角色 网站用户数量过百万后,产品经理不可能再逐个研究每位用户,只能按典型特征将用户分类,抽象出有代表性的用户类型(人物角色),加以分析。产品每增加一项新功能,都要请典型用户参与测试,根据反馈信息加以完善(参见第17章)。
2014-09-06 02:13:56
- 扩展性 激增的用户数量会带来莫明其妙的问题:数据库崩溃、系统出现性能瓶颈、用户界面罢工。网站上线前进行压力测试虽然可以发现部分问题,但正式使用时总有意想不到的情况出现。实现扩展性需要产品经理、设计人员、开发人员、运维人员的通力协作,最好利用部分开发资源和运维资源(我建议分配20%的资源)专门为系统扩展做好准备。不要到系统承受不了压力,即将崩溃才追悔莫及。从设计系统的第一天开始,就应该不间断地考虑扩展性问题,永远留有余地,不到万不得已不要满负载运行(参见第5章)。
2014-09-06 02:14:40
- 持续可用性 大众网络服务要求一刻也不能停歇,但迄今为止我还没见过哪家网站能做到24×7小时无故障运行。
——第39章 打造平台产品的经验——
2014-09-06 02:24:41 参与研发平台产品的人都知道这项工作的艰难,因为要面对三种不同的客户。 1. 应用软件供应商 选择你的平台创建解决方案的公司; 2. 开发人员 应用软件供应商的雇员,由他们在平台上开发应用软件; 3. 终端用户 应用软件的使用者,也是平台服务的真正使用者。
多看笔记 来自多看阅读 for Kindle