【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「大公司如何创新：有困难但值得一试」，主要内容见时间轴~ 【时间轴】 00:40 一、概述 1. 普遍看法 2. 大公司里创新有多难 3. 两大因素影响着大公司创新氛围 * 企业文化 * 老板的观念 4. 任何一家大公司都有潜力为自己的员工营造创新氛围 02:40 二、五个创新的方法 1. 20%法则 * 什么是20%法则？ * 最好的创意大多来自于普通员工 * 不仅适用于开发人员，同样适用产品经理和交互设计师 * 现状 2. 臭鼬工程 * 什么是臭鼬工程？ * 在不耽误本职工作的前提下产出阶段性成果 * 提醒：不要随意拿公司研究成果自行创业 3. 主动观察 * 观察和倾听是最简单的创新途径 * 注意，选实际用户作为观察对象 * 测试产品用不着正式的可用性测试实验室 * 不仅观察软件能否正常使用，还要留心能否满足用户需求 * 创新的最佳途径 4. 改善用户体验 * 跳出技术局限，完善用户体验 * 实现模型和概念模型保持一致 5. 收购小公司 （1）改变观念 （2）选择收购对象 （3）收购创业型公司的好处 （4）作者建议 * 与业内活跃的创业型公司建立联系，互相帮助，互相学习 * 为什么这样建议？ （5）妥善安排收购来的新员工 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「创业型公司的产品管理：关键在于产品探索」，主要内容见时间轴~ 【时间轴】 01:23 一、创业公司存在的问题 * 研发模式存在不足 02:10 二、目前流行的研发模式 1. 创业者想到好点子之后 2. “秘密状态”下运行，很少与用户互动 3. 开发进度慢，半年才能... 4. 内测版本漏洞百出 5. 有些外包开发工作 03:50 三、介绍一种截然不同的产品设计方式 1. 价值 2. 做法 3. 第19期播客的产品设计流程 4. 两个关键点 * 创建体现用户体验的高保真原型 * 邀请真实的目标用户验证产品原型 5. 迭代设计产品原型的过程中 * 现状 * 采取这种方式的优势 * 什么时候招聘程序员开发 06:43 四、借助原型探索产品在软件行业未普及的原因 07:29 五、小结 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「合理运用瀑布式开发方法：扬长避短」，主要内容见时间轴~ 【时间轴】 00:44 一、概述 1. 最常用的开发方法 2. 本章内容概要 01:41 二、瀑布式开发方法的基本原则 1. 理念 * 采用阶段式开发 * 采用阶段式评审 2. 形式 * 正式 * 非正式 -------------------------------------------- 03:24 三、瀑布式开发方法经久不衰的原因 1. 流程具有可预测性，受管理层欢迎 2. 在每个阶段都会提交书面材料 -------------------------------------------- 04:57 四、瀑布式开发方法让产品经理头痛的地方 1. 产品验证严重落后 * 最严重的问题 * 解释 * 进入开发阶段之前 * 在设计软件结构、准备开发之前 -------------------------------------------- 2. 变更计划代价不菲 * 前期决策修改 * 前期设计中的缺陷 * 产品经理负责 * 发现问题应尽早解决 -------------------------------------------- 3. 无法适应快速的市场变化 * 严重依赖文档和流程 * 发布后提心吊胆 -------------------------------------------- 07:48 五、小结 1. 瀑布式开发方法过于理想化 2. 如果采用瀑布式开发方法开发产品软件 3. 如果不得不使用瀑布式开发方法 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「合理运用敏捷方法：十大秘诀」，主要内容见时间轴~ 【时间轴】 00:50 一、概述 1. 认识敏捷方法 （1）起源与注意 （2）官网：https://agilemanifesto.org/ 02:03（3）敏捷软件开发宣言 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： * 个体和互动 高于 流程和工具 * 工作的软件 高于 详尽的文档 * 客户合作 高于 合同谈判 * 响应变化 高于 遵循计划 也就是说，尽管右项有其价值，我们更重视左项的价值。 03:01（4）敏捷软件的十二条原则 * ① 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 * ② 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 * ③ 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 * ④ 业务人员和开发人员必须相互合作，项目中的每一天都不例外。 * ⑤ 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 * ⑥ 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 * ⑦ 可工作的软件是进度的首要度量标准。 * ⑧ 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 * ⑨ 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 * ⑩ 以简洁为本，它是极力减少不必要工作量的艺术。 * ⑪ 最好的架构、需求和设计出自自组织团队。 * ⑫ 团队定期地反思如何能提高成效，并依此调整自身的举止表现。 05:40 2. 本章注意 * 这些诀窍只适用于产品软件团队，不适用于定制软件团队 -------------------------------------------- 05:51 二、十条原则 1. 产品经理即是产品负责人 * 代表客户的需求 * 敏捷方法不能让工作变轻松 （部分观点参考：vol.03《启示录》产品管理与产品营销：两者不是一回事） 2. 使用敏捷方法绝不等于省略产品规划 * 仍然要做的事 * 敏捷环境里的特殊处理 （部分观点参考：vol.12《启示录》评估产品机会：确定待解决的问题） 3. 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期 * 让交互设计师和视觉设计师提前设计 * 让开发人员参与评估产品设计和产品原型 （部分观点参考：vol.20《启示录》 用户体验设计与实现：先定义用户体验再动手开发） 4. 把产品设计工作拆分成独立的部分，分而治之，但也不能拆得太细 * 解释 * 敏捷环境下的注意事项 （部分观点参考：vol.21《启示录》 基本产品：消减功能还是延长工期？） 5. 产品经理的主要任务是定义有价值、可用的产品原型和用户故事，作为开发的基础 * 替代文档的三个优势 * 具体做法 6. 让开发人员自主划分迭代周期 * 不同产品的迭代周期不同 * 开发团队的考虑 7. 产品经理和交互设计师必须出席每天的晨会 晨会是一天沟通的开始，而不是结束 * 设计师的沟通 * 开发人员的沟通 * 测试人员和开发人员的沟通 8. 除非达到了产品经理的要求，否则不要轻易发布新版本 （部分观点参考：vol.25《启示录》平滑部署：避免更新产品导致用户反感） 9. 在每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型 * 这样做的意义 10. 在团队内展开敏捷培训 * 聘请敏捷顾问 * 让每位成员都理解敏捷方法 -------------------------------------------- 04:01 三、问答 14:37 1. 迭代初期开发的产品能做原型吗？ （1）这种做法对产品软件是行不通的 （2）原因如下 * 两种效率的比较 * 应该减少占用开发团队的精力 * 开发团队的成本和难度问题 16:52 2. 敏捷方法可以用来开发产品软件吗？ （1）很多人持怀疑态度 * 原因 （2）敏捷方法的起源 * 起源于定制软件领域 （3）关于定制软件 * 长久以来，开发定制软件困难重重 * 定制软件领域长期很难招聘/留住顶级程序员 * 定制软件的客户 * 定制软件的另一特点：项目规模较小 * 定制软件领域的瀑布式开发方法 （4）敏捷方法对于定制软件的作用 提高了开发定制软件的效率： * 增进客户和开发的交流 * 降低风险 * 引进现代软件测试的理念 * 省去撰写连篇累赘的产品说明文档的麻烦 （5）敏捷方法与产品软件 * 同样适用，但需要调整 * 敏捷方法唯一不适合产品软件的地方：架构设计方面 * 产品团队使用敏捷方法时遇到问题的原因 * 转型成为敏捷开发团队的关键 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「快速响应阶段：产品出炉后切忌虎头蛇尾」，主要内容见时间轴~ 【时间轴】 00:58 一、产品发布后的“误操作” 1. 迅速撤走资源，急于投入下一个项目 2. 此时正式收集反馈信息、改进产品的最佳时机 3. 为什么说是最佳时机？ * 只要稍微延长项目周期，观察用户对产品的反应，效果会有天壤之别 -------------------------------------------- 01:58 二、作者的主张 1. 留出时间作为快速响应阶段 2. 这个阶段的主要工作 3. 快速响应阶段的发展 -------------------------------------------- 02:56 三、关于快速响应 1. 为什么要快速响应？ * 应对发布后的意外情况 2. 快速响应的关键 * 不在于是否会出现问题，而在于能多快解决问题 3. 评估产品表现 * 使用明确的、可量化的指标 * 具体使用哪些指标？ * 给指标分出轻重缓急，并保持关注 * 对结果导致成功或失败，心中有数 4. 针对不同产品的特殊说明 * 针对大众的网络服务 * 企业级软件 5. 其它说明 * 其他工具或方式推荐 * 客户服务人员、销售人员和合作伙伴的意见也不容忽视 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「平滑部署：避免更新产品导致用户反感」，主要内容如下： 【时间轴】 00:36 一、用户产生反感的原因 1. 事前没收到更新通知，感到搓手不及 2. 没时间学习、适应新版本 3. 新版本无法正常运行 4. 新旧版本不兼容 5. 认为新功能和特性毫无必要 6. 版本更新太频繁，感到疲惫不堪 7. 新版本修改了已经习惯的使用方式和操作流程 ------------------------------------------- 02:06 二、工作的矛盾 1. 用户不喜欢变化 2. 工作要不断推陈出新 ------------------------------------------- 03:10 三、最轻松的1.0版本 1. 无须担心产品的历史兼容性 2. 不用考虑维护老用户的问题 ------------------------------------------- 03:49 四、互联网下的威胁 1. 过去信息不对称 2. 互联网普及，产品的口碑无论好坏都会迅速传播 3. 特别是大众互联网服务，威胁更突出 4. 平滑部署的概念 ------------------------------------------- 04:53 五、降低版本更新带来的负面影响 1. 通过一些方式提前通知用户，但方法效果有限 2. 加倍做好测试工作，避免新版本影响正常使用 3. 如果更新版本会影响大规模测试，应采取并行部署或增量部署的方式来降低风险 ------------------------------------------- 06:02 六、平滑部署的方式 1. 发布两个并行版本 * 使用方法 * 注意事项 2. 区域性逐步部署 * 使用方法 3. 增量部署 * 使用方法 4. 注意事项 * 关键要全面考虑更新可能带来的副作用 * 不要轻易试探用户的耐心 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「改进现有产品：不是一味地添加功能」，主要内容见时间轴~ 【时间轴】 00:30 一、错误的改进产品的方式 00:34 1. 许多产品经理改进已有产品不知所措 01:00 2. 大多数产品团队知识功能加工厂 01:27 二、正确的改进产品的方式 01:32 1. 第一步，明确目标 * 举例：保险公司的投保申请网站 02:20 2. 应该如何改进？（取决于能在多大程度上提升各项指标） * 先考虑从哪些方面改善用户体验。 * 时刻关注指标，与相关人员密切合作 * 进一步了解产品 03:39 3. 注意事项：能提高指标的功能才是你关注的重点 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「原型测试：把产品创意呈现给真实用户」，主要内容见时间轴~ 【时间轴】 00:46 一、概述 00:50 1. 使用产品原型的最主要原因 01:42 2. 公司里面宝贵的资源 02:07 3. 一些公司的情况 03:22 4. 注意 * 某些要领需要反复练习才能掌握 * 产品可用性测试和产品价值测试同样重要 03:41 二、物色测试者 04:09 1. 利用特约用户 04:28 2. 参加同类产品的展销会 04:42 3. 在分类信息网站上发布广告 05:02 4. 大众产品，可以邀请亲朋好友 05:26 5. 利用用户的电子邮件列表 05:36 6. 通过公司的网站征集志愿者 05:54 7. 大公司定期开展原型测试活动 06:31 8. 到用户聚集的地方 07:08 9. 针对上门测试者，补偿测试者 07:45 10. 测试前一天提醒测试者 08:16 三、准备测试 08:37 1. 事先拟定好测试内容 09:09 2. 测试原型前，先提供给测试者空白的浏览器，看看他们会怎么做 10:41 3. 测试原型前，观察测试者 11:18 4. 测试原型后，通过聊天进一步收集信息 12:105. 为每个问题的答案打分或用数字回答问题，记录每个阶段产品的表现 12:48 6. 不必等到完整原型完成后再测试 13:23 四、测试环境 13:36 1. 制造让测试者放松的环境 14:25 2. 去用户的办公室 15:15 3. 面对面的测试 15:38 4. 产品经理亲自参加每次的原型测试 16:17 5. 客观对待测试 17:03 6. 安排一个人主持，另一个人记录 17:28 7. 请一位用户研究人员帮你记录 17:58 五、测试原型 18:18 1. 测试前，不宜与测试者交谈过多 18:50 2. 告诉用户：这只是产品原型...... 19:28 3. 让测试者保持平和的情绪，避免吹毛求疵 * 测试的重点：看测试者能否轻松完成测试任务，以及他们是否喜欢产品的功能 20:36 4. 不要给测试者提示 21:06 5. 通常有三种测试结果 21:40 6. 尽量避免提示测试者，更不能引导他 22:03 7. 使用自言自语的技巧 23:20 8. 测试的作用 23:43 9. 关注测试者的肢体语言和语气 24:37 六、更新原型 25:04 1. 只要两三个用户反映了同一个情况，就动手解决 25:43 2. 何时结束测试？ 26:13 3. 何时放弃产品创意？ 27:04 七、两个获取测试灵感的资源 27:08 1.《点石成金：访客至上的网页设计秘笈》 27:37 2. “倾听实验室” * 源自产品测试公司Creative Good（网址：www.creativegood.com） 八、范例 * http://www.svpg.com/examples 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「产品验证：证明产品的价值、可用性、可行性」，主要内容见时间轴~ 【时间轴】 00:56 概述 * 什么是产品验证？ * 过去验证产品的问题 02:13 可行性测试 * 首先 * 重点 * 总结 03:09 可用性测试 * 怎么做？ * 价值 * 注意 04:15 价值测试 * 价值 * 价值测试可以和可用性测试同时进行 * 不同的产品有不同的原型 * 关于是否使用高保真原型的争论 * 使用原型并非验证产品的唯一方式 范例 http://www.svpg.com/examples 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「基本产品：消减功能还是延长工期」，主要内容如下： 【时间轴】 00:42 放弃老式的产品设计方式 * 比如，不再定义最终产品，只满足基本要求（价值、可用性、可行性） * 老式产品设计方式举例 02:40 建议采用另一种产品设计方式 * 只设计基本功能的产品 * 邀请一位开发人员（比如架构师或者主程序员）参与设计原型 * 请真实用户验证（测试）产品原型 05:16 注意事项 * 辨别是否是基本产品 * 根据产品原型估算的开发时间也不是完全准确 * 一旦进入软件开发环节，产品经理就不能在随意修改设计 07:06 总结 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「 用户体验设计与实现：先定义用户体验再动手开发」，主要内容见时间轴~ 【时间轴】 一、软件开发过程，很多工作可以同时进行 00:43 需求调研与产品设计 01:16 开发与测试 二、用户体验设计和软件开发不能同步展开 01:43 原因 * 与开发团队合作的人要记住：一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高 * 为了拿出即可用又具有价值的设计，必须尽早、反复验证设计思路 * 验证设计思路必须使用高保真原型 * 用户体验设计不可拆分 * 用户体验设计至少需要一两周时间 06:02 如果同步展开会出现的情况 * 开发人员等着设计结果无事可做 * 设计师饱受压力，要在几天内完成原本需要几周完成的工作 * 设计师仓促完成设计 * 边开发边修改设计，等设计师最终完成设计，为时已晚 * 设计师对产品不满意，用户不满意 07:15 如何解决？ * 关键是确定先后顺序，用户体验设计应该在软件开发前完成。 * 特例：开发大量后台基础软件时 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「重新定义产品说明文档：安息吧，纸质说明文档」，主要内容见时间轴~ 【时间轴】 01:00 纸质说明文档的问题 * 表面问题 * 根本问题 03:03 产品经理和产品说明文档的关系 03:34 产品说明文档应该满足以下要求 * 完整描述用户体验 * 准确描述软件的行为 * 用直观的方式把产品信息和产品行为告诉所有人 * 应该可以修改 * 有一个主体来代表产品 05:39 高保真产品原型 * “高保真”的含义 * 建议 * 作者想法的改变 * 仅仅有原型还不够 * 高保真原型的优势 12:21 总结 高保真原型和产品说明文档的范例：http://www.svpg.com/examples 【关于主播】 感谢大家收听「产品自习室」，做这个播客的目的，主要是想记录自己的产品经理的学习过程，希望通过声音输出提高自己的学习吸收率，通过做轻文案播客锻炼口才。 欢迎添加我的微信交流！pmnino9 公众号：PM尼诺