读书笔记:启示录

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

Marty Cagan


读书笔记,如有侵权,请告知删除。


第10章 管理上司
2017-09-17 15:58:29
正式会议的作用只是让与会人员认识到大家取得了一致意见。
2017-09-17 15:58:36
最好根据问题的重要性列举出多种解决方案,并附上你的依据和建议。
2017-09-17 15:59:07
收件人的级别越高,邮件的篇幅就该越短。你可以添加附件,但不要让正文篇幅过长。
第11章 评估产品机会
2017-09-17 16:32:59
评估产品机会是产品经理的重要职责。评估产品机会的目的在于:淘汰馊主意,避免浪费时间和金钱;挑选合适的产品机会,团结团队,理解产品,整合资源。为了评估产品机会,我要求产品经理回答如下十个问题。

1.产品要解决什么问题?(产品价值)

2.为谁解决这个问题?(目标市场)

3.成功的机会有多大?(市场规模)

4.怎样判断产品成功与否?(度量指标或收益指标)

5.有哪些同类产品?(竞争格局)

6.为什么我们最适合做这个产品?

7.时机合适吗?(市场时机)

8.如何把产品推向市场?(营销组合策略)
2017-09-17 16:33:09
9.成功的必要条件是什么?(解决方案要满足的条件)

10.根据以上问题,给出评估结论。(继续或放弃)

以上问题并不涉及具体的解决方案。机会评估只讨论待解决的问题,不应涉及具体解决方案。将来有大把的时间来考虑解决方案,现在是认真考虑要解决什么问题的时候。产品经理往往把待解决的问题和解决方案放在一起考虑,当具体解决方案遇到困难时,他们会放弃产品机会。这是典型的“把洗澡水和孩子一起泼掉”的做法。
第12章 产品探索
2017-09-17 20:20:15
如果你天生喜欢探索发明,喜欢自由和创意,那么在执行阶段就要努力控制创造的欲望;如果你天生是“项目经理”类型的人,喜欢排除外界干扰,按部就班完成任务,那么你需要培养自己的宏观思考能力和设计能力。

我有个方法可以解决这种冲突:采用流水线方式并行开发产品。也就是说,一旦1.0版本的产品进入项目执行阶段,就开始定义2.0版本的产品。一旦前一个版本进入开发阶段,就把你的创造热情投入下一个版本。
第13章 产品原则
2017-09-17 20:49:50
制定产品原则意味着决定什么重要、什么不重要,哪些原则是根本的、战略性的,哪些是临时的、战术性的。

产品原则不是产品功能的清单,不依赖于任何单独的产品,它是整个产品线的战略指南,是公司的价值宣言。好的产品原则甚至可以激发设计产品的灵感。
第14章 产品评审团
2017-09-18 17:19:22
成立产品评审团的目的是决定产品战略方向,从宏观上监督公司产品的研发流程,合理地配置资源。产品评审团不制订公司的商业战略,而是在给定商业战略的条件下,提出与之相匹配的产品战略。产品评审团的决策直接影响企业的运营。
第16章 市场调研
2017-09-20 14:39:50
探索(定义)产品的过程则要回答如下问题。

1.采用什么技术来更好地解决产品要解决的问题?

2.设计什么样的用户体验?
2017-09-20 14:39:59
成功的产品基于以下两点认识:深入理解用户需求,以及明白什么样的解决方案在现阶段是可行的。
第18章 重新定义产品说明文档
2017-09-20 15:48:22
我认为理想的产品说明文档应该满足以下要求。

1.产品说明文档应该完整地描述用户体验——不只是用户需求,还包括交互设计和视觉设计。希望大家已经明白用户需求和用户体验是密不可分的。

2.产品说明文档必须准确地描述软件的行为。文字和图片的表达能力实在有限,不足以完成这项任务。

3.产品说明文档的受众较广——开发人员、测试人员、客服人员、市场营销人员、运维人员、销售人员、管理层等等。因此,产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。

4.产品说明文档应该可以修改。虽然进入开发阶段后,应该尽量避免修改产品说明文档,但总有意想不到的问题出现,需要修改产品说明文档以适应新情况。

5.撰写产品说明文档的过程中会出现许多衍生物,比如,按优先级排列的需求列表、线框图、实体模型,但应该有一个主体来代表产品,避免混淆不清,版本错乱。
2017-09-20 16:05:55
“高保真”的含义是原型应该真实地体现用户体验。除了描绘用户界面的某些细微之处以外,我不建议使用“纸上原型”。如今使用工具创建高保真原型既简单又快捷,成本也不高
2017-09-20 16:06:03
为了获得接近真实的用户体验,甚至应该模拟后台处理流程和某些数据。
2017-09-20 16:20:26
仅仅有原型是不够的,因为有些产品行为不容易用原型体现,比如业务逻辑(税务表单和运费等)、发布要求(性能表现、可靠性、扩展性等)、平台交付要求(安装要求、浏览器兼容性等)。用例可以作为有效的补充,用来描述重要的产品行为。
2017-09-20 16:20:01
高保真原型最突出的优势是可以用于测试
第20章 基本产品
2017-09-20 17:17:30
设计产品时一定要考虑哪些功能是最重要的,争取设计出只满足基本要求的、不可删减的产品。就像我从前的老板常说的——断腿的狗打不了猎。
第21章 产品验证
2017-09-20 17:18:09
产品验证是指在正式开发、部署产品前,验证产品说明文档描述的产品是否符合预期要求。
第22章 原型测试
2017-09-20 21:05:24
l.如果你已经拥有一批特约用户(参见第15章),可以邀请他们参加测试。如果你手头一位特约用户都没有,请马上开始物色。

2.如果是企业级产品,同类产品的展销会是寻找目标用户的好去处。

3.可以在分类信息网站(如Craigslist)上发布广告,征集测试者。征集要求可以写得笼统些,不必过于具体。事后打电话给你感兴趣的应征者,了解对方的意向,进一步筛选合适的测试者。

4.如果是大众产品,可以邀请自己的亲朋好友参加测试,但要避开过于亲密的人和科技行业的从业者,除非他们就是目标用户。另外,测试者不能只局限于亲友。

5.如果手头有用户的电子邮件列表,可以从中筛选测试者。营销团队可以帮你缩小名单范围。

6.可以通过公司的网站征集志愿者,主流网站都这样做。但还是需要打电话联系并筛选应征者,避免参加测试的全是产品尝鲜者(early adopter)。

7.我建议较大的公司定期开展原型测试活动(比如两周一次),每次邀请10~20位测试者参加。让所有产品经理自己申请时段,安排每位测试者参加测试一两个原型。我常这么做。安排专人邀请和筛选测试者,以免产品经理为此分心,产品团队也可以定期测试原型,再不用为寻找测试者操心。
2017-09-20 21:05:32
8.离开公司,到街头巷尾去,到用户聚集的地方去。开发电子商务产品,应该去大的商品卖场寻找测试者#开发体育产品,应该去体育酒吧。如果产品真的能解决用户的需求,让他们花个把小时测试产品是没问题的。可以送些礼物表示谢意,注意放低身段。

9.如果邀请测试者上门参加测试,尤其是出于商业目的,应该补偿测试者为此损失的时间。如果是大众网络服务产品,通常真诚地说声谢谢,送上一顶印有公司标志的帽子就足够了,多数用户乐于助人,尤其是帮助他们喜爱的公司。如果真的要补偿测试者,不妨送五十美元左右的公司电子购物券。

10.即使和测试者约定了测试时间,还是有人会忘记时问,爽约的几率大约是30%。在测试前一天致电测试者,可以把这个比例降到5%~10%,给测试者留一条语音留言也行,不过要注意,发电子邮件的效果不是那么好。
第24章 平滑部署
2017-09-24 15:18:16
平滑部署的方式很多,比如发布两个并行的版本,邀请有兴趣、有时间的用户试用新版
2017-09-24 15:19:03
本。如果新版本运行正常,大部分用户习惯新版本后,再将新版本设为默认版本。同时将旧版本保留一段时间,公示为旧版本提供支持的最后期限,以便没来得及习惯新版本的用户在这段时间内能照常使用产品。对于用户数量庞大的服务和产品,这个过渡可能需要几个月的时间。
第25章 快速响应阶段
2017-09-24 17:10:45
评估产品表现应该使用明确的、可量化的指标。你最关心产品哪方面的表现,是页面访问量、注册用户数、访问停留时间、会员转换率、订阅数,还是广告收益?具体使用哪些指标取决于产品的商业目标。应该给指标分出轻重缓急,并保持关注。此外,对于什么样的结果代表产品成功,什么样的结果代表失败,应该做到心中有数。
第26章 合理运用敏捷方法
2017-09-24 18:43:26
1.产品经理即是产品负责人(product owner),他代表,客户的需求,因而需要与产品开发团队保持密切的联系,协助督促开发进程,及时解决出现的问题。有些产品经理以为敏捷方法可以让工作变得轻松,这是大错特错的。如果产品经理和产品负责人不是由一个人担任,通常会埋下隐患(参见第2章)。

2.使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标,设定衡量产品成功与否的标准。只不过在敏捷环境里,规划周期应该适度缩短,反复迭代,采用轻量级的机会评估方法替代冗长的市场需求文档(参见第11章)。

3.产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期,确保你们有足够的时间攻克难题。让交互设计师和视觉设计师提前设计产品,充分发挥他们主导设计的作用,不能一边设计一边开发(参见第19章)。另外,始终让开发人员参与评估产品设计和产品原型,及时反馈关于可行性、成本、解决方案的建议。

4.尽量把产品设计丁作拆分成独立的部分,分而治之,但也不能拆得太细——好比设计建筑不能一次只设计一个房间。目标是设计出符合基本要求的产品(参见第20章)。值得注意的是,在敏捷环境里,设计师必须加快工作速度,采用迅速制作原型的方法更能适应敏捷环境。
2017-09-24 18:43:38
5.产品经理的主要任务是定义肯价值、可用的产品原型和用户故事(user story),作为开发的基础。用产品原型和用户故事替代厚厚的产品需求文档和功能说明文档有三个优势:①可以请用户测试;②强迫产品经理全面认真地思考问题;③向开发团队明确地描述每次迭代周期需要完成的任务。请用户测试原型,根据反馈意见反复迭代修改原型设计,确保交给开发团队的是有价值的结果,避免任何浪费,哪怕只是一个迭代周期。
第27章 合理运用瀑布式开发方法
2017-09-25 15:51:20
瀑布式开发方法的流程具有可预测性,因而深受管理层欢迎。只要能准确理解需求和技术,而且需求不再变更,开发团队就能为大规模的、复杂的项目制订精确的开发计划
2017-09-25 15:51:40
其次,采用瀑布式开发方法,在每个阶段结束时都会提交书面材料。有了翔实的文档和设计图表,管理层、客户(委托方)、开发人员觉得所有工作都是经过深思熟虑的,才能放心。这些材料可以从一定程度上增强人们对项目的信心。问题在于把书面材料当成定心丸多少有些靠不住,毕竟文档不能像软件一样运行、验证。
2017-09-25 15:51:54
产品验证严重滞后

这是最严重的问题。产品经理必须等到软件开发的尾声,才能看到可以运行的软件。也就是说,在投入大量人力和资金之前,软件的可用性无法得到验证。
2017-09-25 15:52:13
变更计划代价不菲
2017-09-25 16:08:43
无法适应快速的市场变化
2017-09-25 16:10:18
瀑布式开发方法过于理想化,以为人们能预见所有问题,全面把握需求。
第28章 创业型公司的产品管理
2017-09-25 16:27:01
创业初期只设三个职位:产品经理、交互设计师和原型开发人员。为节约成本,公司创始人可以亲自担任产品经理,交互设计师也可以由原型开发人员兼任,只要有人负责承担这三项工作(产品管理、交互设计、原型制作)即可。这个团队可以快速展开产品设计,迭代修改。
2017-09-25 16:27:08
确定产品原型后,再招聘程序员进行开发。有了产品原型(代替产品说明文档),开发人员可以更直观、高效地领会产品设计和开发要求。这将大火缩短开发时间。
第29章 大公司如何创新
2017-09-25 16:33:12
人们误以为优秀的产品是战略规划的结果,或是来自公司高管的创意。其实,最好的创意大多来自于普通员工。
第31章 苹果公司给我的启示
2017-09-25 20:30:45
苹果公司有很多值得学习的经验,但我认为以下四点最重要。
2017-09-25 20:30:53
.硬件为软件服务
2017-09-25 20:30:57
2.软件为用户体验服务
2017-09-25 20:31:12
3.用户体验为情感服务
2017-09-25 20:31:29
4产品为真正的需求
第32章 提防有特殊要求的产品
2017-09-25 21:12:24
我反复强调产品需求不能用户说了算,原因如下:第一,在看到具体的产品之前,用户很难知道自己需要什么:第二,用户不知道什么样的产品是可行的(在目前的技术条件下可以实现);第三,用户之间缺少沟通,需求很难统一。
第33章 新瓶装老酒
2017-09-26 11:35:03
想在成熟的市场抢占一席之地,精明的公司至少要手握两件“法宝”。

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

第二,跟踪最新的技术趋势。新技术层出不穷,让之前无法实现的方案变得可能。虽然谁都没有把握永远走在技术的前列,把最新的技术融入产品设计中,但是只要做到一次,你的产品将所向披靡。
2017-09-26 11:35:11
优秀的产品经理应该抓住现有技术与用户需求的契合点。
第34章 恐惧、贪婪、欲望
2017-09-26 14:35:04
只有从情感的角度重新观察市场上的产品和服务,你才能体会用户的真实感受。他们通过什么途径满足这些情感需求?哪种视觉设计更能抓住这些情感?哪些功能更能满足这些情感需求?哪些产品特性阻碍用户宣泄情感?
第35章 情感接纳曲线
2017-09-27 18:37:27
情感接纳曲线

整章都很有启发

2017-09-26 14:43:28
杰弗里·摩尔(Geoffrey Moore)在他的作品《跨越鸿沟》中提出了一个颇具影响力的概念——技术接纳曲线,这条曲线涉及了技术创新者、尝鲜者、早期消费大众、后期消费大众和跟随者。这本书尝试解释为什么很少有产品能越过鸿沟——获得尝鲜者以外消费者的青睐。
2017-09-26 14:50:13
愤怒的用户决定着产品未来的发展方向。
2017-09-26 14:50:22
我建议产品经理关注门常生活里那些让大众烦恼不堪,又不得不应付的事情。如果产品经理能解决这些问题,一定能打造出成功的产品。

痛点

第36章 可用性与美感
2017-09-27 18:37:52
良好的用户体验是交互设计师和视觉设计师合作的结果。他们共同配合产品经理定义产品。
第37章 大众网络服务产品
2017-09-27 18:38:18
十条管理大众网络服务产品的要点
第38章 打造企业级产品的经验
2017-09-27 18:39:09
企业级软件的销售对象,主要是企业,而不是个人消费者。当然,企业有大有小,我所说的企业不包括小型工作室、家庭办公室和其他小企业,在我看来,它们更适合被划入个人消费市场而不是企业市场(过去很多公司在小企业市场进行过尝试,大都以失败告终,原因就是他们没有认识到这一点,不了解这个市场的产品需求)。这里提到的企业包含中型企业,尽管大部分人提到“企业”时总会联想到更大的集团,比如“财富五百强”企业。我认为销售给中型企业和大企业的软件存在同样的问题。

企业级软件的类型包括企业基础软件(例如,安全软件、系统管理软件、通信软件)和企业应用软件(例如,营销自动化软件、客户关系管理软件、企业资源计划软件)。它们之间存在着很大的差异。我要介绍的要点对两种产品同样适用,只是侧重点不同。
第39章 打造平台产品的经验
2017-09-27 20:41:10
只有让终端用户满意,平台产品才是成功的。这总比开发人员怡然自得,终端用户却怨声载道好得多。
2017-09-27 20:41:49
管理平台产品还有其他的困难:没有统一的交付形式(嵌入式产品、自有品牌、联台品牌、托管服务等):客户的定制要求多种多样(比如针对终端用户、IT部门、解决方案供应商、系统集成商进行优化)。技术支持是管理平台产品的另一个难点。客户是你赖以生存的根本,因此必须提高技术支持的服务能力和服务水平。
多看笔记 来自多看阅读 for iOS

☕️听说你想请我喝咖啡?