读书笔记 启示录(第2版)

启示录2

前一阵子在设计新一代的项目协作平台时，在做一些关于新组织架构模式研究和产品开发过程优秀方法论研究，想起以前看过的启示录一书，里面针对互联网产品的开发有许多宝贵的经验之谈，然后发现该书已经与时俱进的出了第二版，于是买了刷了一遍，与第一版相比增加和调整了不少内容。

这本书的副标题是：如何创造用户喜欢的产品，打造伟大产品的灵感、方法与工具 ，非常值得产品从业者、项目管理、企业管理者去阅读。以下是我个人阅读后对文中的一些重点知识摘记，希望对你有用。

来自顶尖科技公司教训

在如何开发产品上，优秀公司与大多数公司有天壤之别。

每个优秀产品背后

不要以为国外没有996工作氛围，那么所有的产品开发都是朝九晚五进行的，那些耳熟能详的优秀产品背后其实的历程都是难度极大的，参与的团队也都是开足马力，贡献了超长的工作时间，只不过不是强行996加班，主要是自愿加班或在家中办公完成的。

技术驱动型产品

本书主要的讨论对象还是技术驱动型产品，而不是老板驱动或销售驱动的模式。
技术驱动的一个显著特征就是拥抱技术变革作用，团队保持始终如一创新精神。

初创型公司

对于初创型公司来说，最重要的事情是实现公司产品PMF工作，即完成产品和市场契合，从而生存下来，专注力重点应该放在产品上。

成长型公司

成长型公司的一个目标就是快速扩张，形成规模化，直至成功。这个阶段对于绝大多数公司来说都是极其困难的，不过令人欣慰的是，公司到了这个阶段，至少实现PMF，且发展的不错。值得注意的是，这个阶段初创期的领导力机制将失效，需要引入一些规范与制度。

成熟型公司

到了这个阶段的公司，基本也是行业内的独角兽了。这个时候公司要做的就是始终如一保持产品创新，公司发展到一定程度，原业务增长都会出现乏力，会有新的入行者或产品替代者出现，企业想要获取持续增长，必须不断尝试新的市场，不断寻找第二条曲线。这个阶段领导力机制将以企业文化和价值观为主。

导致产品失败根源

• 瀑布流式产品开发：相信大家都在吹捧敏捷式开发，且不说我见过的大多数团队敏捷都是伪敏捷，及时是真敏捷的那些团队，也只有在需求到了产品团队才进行敏捷，而这之前和之后环节都还是传统的瀑布流模式，即敏捷只出现在研发环节，难道产品研发只和研发有关吗？
• 创意来源自销售或利益驱动：导致偏离产品初心，最后变成四不像。
• 详细优先级路线图：未来不可预估，这种路线图几乎很难执行到底。
• 忽视很多创意是无效的：实践证明，至少一半以上创意是无效的，有效的创意也至少需要几轮迭代。
• 产品管理主要工作是收集需求并文档化：这与真正的现代科技产品管理完全是南辕北辙，这种工作根本不需要团队最具才干的人去做。
• 产品设计参与的太晚，只能把口红涂在猪嘴上：实在是太形象，我见过的大多数设计师都是对着原型画设计图，毫无灵魂而言。
• 工程师只写代码的话，至多只发挥50%作用：能把这50%发挥好的公司已不多，如果能挖掘出另外50%才对得起薪资普遍较高的工程师们。
• 把产品当作项目输出，忽视了结果：如果最终发布的某些东西，但它却与目标不符，那发布它的意义何在？
• 把风险拖到最后：上线后才发现产品不是/用户客户想要的。
• 浪费组织的机会成本：如此之多的公司花费了大量时间和金钱却鲜有回报。

精益与敏捷开发的本质

请牢记一句话：产品打造没有银弹。
精益与敏捷开发本质包含如下三大原则：

• 及时解决风险，不要拖至最后。
• 产品定义和设计是交叉进行。
• 一切核心是解决实际问题，不是功能实现。

这三个原则，也是贯穿本书的三大原则，很多章节都有体现。

关键概念

本书中罗列了一些新的概念和对一些常见概念重新解读，为了大家便于理解，统一罗列下。

• 整体产品：产品是一个非常整体，全面的定义，而不应该仅仅关心需要实现的功能。
• 持续发现和持续交付：不仅仅是研发流程敏捷化，产品整个流程都应该遵循敏捷化，充分发挥设计师、工程师作用。
• 产品发现：主要包含4个方面，客户价值：用户会为我们的产品买单吗？；易用：用户知道怎么使用我们的产品吗？；可行性：我们工程师能够实现；干系人价值：利益相关者会支持这几款产品吗？。
• 原型：原型类型有很多，每种原型都有不同的适用条件与风险。
• 产品交付：最终可销售才是产品交付。
• PMF：产品满足PMF验证，mvp应该是一个原型，而不是一个产品。
• 产品愿景：产品长期目标。

合适的人

优秀产品团队遵循原则

• 团队：传教士而非雇佣军。
• 组成：1:10左右比例，1名产品经理，1名产品设计师，2-10名工程师。
• 权力与责任：有权提出解决方案，对结果负责。
• 规模：两个比萨原则。
• 协作：一起制订方案。
• 团队工期：稳定长期团队很重要。
• 团队自主：足够自主权，减少依赖。

产品经理

应该是团队里最具才干的人：具备娴熟的技术；商业的敏锐；关键人员信任；深厚客户知识；产品激情；团队尊重。

• 关键责任：让其他人相信你所构建产品是真正值得的。
• 牢记：产品成功是每个人各司其职，产品失败就是产品经理过错。
• 深厚客户知识。
• 深厚数据知识。
• 深厚业务知识。
• 深厚市场和行业知识。
• 智慧、创意、持之以恒：智慧：好奇心，快速学习能力，善于利用新技术；创意：创造力；持之以恒：产品热情，通过证据不断沟通。
• 重要的两门课：计算机编程入门；商业会计和金融学入门。

产品设计师

这个岗位职责和国内大多数设计师职责差别最大了，可以发现一些产品经理职责划到了这个岗位，初看起来有点不合理，但是仔细一思考，还真是很合理，也很顺理成章的。最近我看到很多国外的设计师，他们利用processing编程语言，结合机器学习，创造出了很多有趣的产品，我想他们应该一直的重新定义设计师这个岗位角色，而我们设计师定位大多停留在美工层面。

• 产品发现：传统的工作方式，设计师从产品经理哪里获取需求或产品说明书后再进行设计。产品设计师工作价值：由产品成功度衡量而不是工作产出。
• 完整的用户体验设计：包含完整UX和UI。
• 原型设计：不单只是传统意义上原型图。
• 用户测试：找到现实用户测试。
• 交互和可视化设计：这部分类似传统设计师相关工作，国内应该只停留在这一层。

工程师

对于一个成功的产品经理来说，最重要的关系莫过于与你团队中工程师关系。

• 与他们直接交流讨论：充分挖掘和发挥他们作用，不仅可以为产品未来省下很多工作而且还能为你提供很多创意设计。
• 向他们承诺真正的调研：不要欺骗和拍脑袋，不然到最后你会发现，小丑竟然是你自己。
• 他们的士气取决于产品经理：产品经理工作要确保工程师们感觉自己是传教士而不是雇佣军。

产品营销经理

• 一个营销经理通常服务与多个产品团队。
• 如果公司有营销经理，产品经理要确保他和你一起工作，为了产品的常规，花时间去了解市场绝对很值。

辅助角色

• 用户研究人员。
• 数据分析师。
• 自动化测试工程师。

领导角色

• 产品管理领导CPO：定期审核各产品经理和产品团队的工作，找出问题并帮助解决。
• 产品设计领导CDO：负责整体用户体验。
• 技术组织领导CTO：从技术角度了解整个系统是如何整合的，负责系统的整体架构。

其它管理角色

• 产品主管角色：最重要的职责就是培养出一个包含产品经理和设计师的优秀团队。
  

  强调团队发展，设定产品愿景和策略，强大执行力，技术驱动产品文化，一定行业经验，处理好部门关系。

• 技术主管角色：即使是最伟大的产品创意，如何你不能付诸实践并发布，它就只是想法。
  

  该岗位也可能被称作CTO，其主要职责：建立优秀组织；帮助指导并购活动建立购买协作决策；快速交付产品；设计符合产品演化架构；确保团队活力。

• 交付经理角色：消除协作障碍。

正确的产品

产品路线图

不要使用传统的产品路线图。

• 产品路线图问题：我们至少有一半的创意是行不通的，所以指定产品路线图很多情况下是无用功；有价值可行的创意，也需要根据市场反馈进行多次迭代，产品路线图无法预测规划好这一切。

• 路线图替代方案：故事地图技术。此替代方案满足产品路线图提供的两个需求：1 管理层想确定业务上最有价值的事情；2 管理层需要时间承诺。故事地图是一种二维地图，纵轴是用户活动，横轴是时间；管理层提供需要解决的特定业务目标，团队工作方式关注结果而不是产出，建立高信用承诺的文化。按照我个人的理解，用户活动类似史诗级故事。

产品愿景

搞清楚产品愿景与产品战略，它们都起到赋予团队工作意义感重大作用。
产品愿景具体作用：

• 传达愿景，激励团队(利益相关者、投资人、合作伙伴、潜在客户)。
• 有效招聘工具。
• 类似于优秀的领导力。

产品战略具体作用：

• 不要试图取悦任何人，不然会导致取悦不了任何人。
• 它是计划交付的产品或版本顺序。
• 类似于优秀的管理力。

产品愿景原则

• 从为什么开始。
• 相比解决方案更热爱提出问题。
• 不要害怕远见卓识。
• 不要害怕打乱自己。
• 产品愿景需要激励。
• 拥抱那些有意义的趋势。
• 关注事物变化的方向。
• 大方向坚持，小细节灵活。
• 实现任何产品愿景都是一种信仰的飞跃。
• 坚持不懈的布道。

产品战略原则

• 一次只专注于一个目标市场或一类角色。
• 产品战略于业务战略保持一致。
• 产品战略与销售战略、上市战略保持一致。
• 关注客户，而非竞争对手。
• 组织全体成员参与沟通战略。

产品原则

• 产品愿景描述了你想打造出什么东西
• 产品战略描述了你实现产品愿景的路径
• 产品原则描述了你想打造的产品实质

产品目标

OKR技术

采用OKR技术来管理产品目标：

• 每年设定一次公司OKR。
• 每季度设定一次部门的OKR。
• 团队目标和组织目标保持一致。
• 每次设置1-3个目标。
• 每个OKR设置1-3个关键结果。
• 打分阶段推荐：0 毫无进展，0.3 完成基本工资, 0.7 满足期望, 1.0 超出预期。
• 高级管理层对组织OKR负责。
• 产品和技术主管对团队目标负责。

产品团队目标

• OKR的关键点就是集中在产品团队级别上。
• 不要和职能团队的OKR混到一起。

产品与规模

产品规模上分为小组织和大组织。

• 小组织：每个人都有必要知道别人在做什么和为什么做这个。
• 大组织：对组织目标有非常清晰的理解，确保产品团队适应多层级OKR。

此外产品需要做好布道的工作，这是CEO和产品负责人最重要工作之一。推销梦想的工具和方法：展示原型，分享愿景，分享痛点，毫无保留分享经验，毫无保留信任，学会精彩的演示，发自内心的兴奋，表现出狂热，花时间多和团队相处。

正确的过程

产品发现

产品发现确保工作不是一种浪费

产品发现原则

• 不能依赖客户、高管、利益相关者。
• 最重要事情是创造有目共睹的价值。
• 功能、设计、技术本质上是相互关联的。
• 很多创意会行不通，行得通的也需要多次迭代。
• 产品发现目标是以最低的成本来验证我们的创意。
• 基于真实用户/客户来验证创意。
• 在产品发现中迭代，比在交付中迭代起码节省一个数量级时间和精力。

产品发现风险管理

• 价值风险：客户会购买或选择使用我们的产品吗？
• 可用性风险：客户知道如何使用我们的产品吗？
• 可行性风险：我们能打造出优秀的产品吗？
• 业务可行性风险：这个解决方案对我们的业务有用吗？

产品发现技术包含：发现框架技术，发现规划技术，发现构思技术，发现原型技术，发现测试技术，测试可行性，测试可用性，测试价值，测试业务可行性，转换技术。

发现框架技术

确保团队在整理目标刻画上保持一致,发现和解决重大风险(财务、业务、营销、销售、法律、道德)

• 1 机会评估技术：主要回答4个关键问题，1 业务目标：这项工作解决什么业务目标？2 关键结果：如何度量成功？3 客户问题：这项工作解决了客户什么问题？4 目标市场：我们关注哪些客户？
  适用：小规模、典型项目

• 2 客户函件技术：站在客户的角度，介绍产品成功发布后，能够带来的价值和变化
  适用：大规模项目

• 3 初始画布技术：一种业务模型验证法
  适用：新业务和新产品

发现规划技术

• 故事地图技术(简单)：一种二维地图，纵轴是用户活动，横轴是时间，将主要用户活动分布在二维图中（个人觉得有点类似史诗级的故事）。

• 客户发现技术(复杂)：寻找自己产品的铁杆粉丝，铁粉是产品的参照客户，产品经理需要投入大量的精力。根据客户类型，参照客户的含义也不尽相同。

  toB：为企业量身定制产品，参照客户数至少6个。
  to应用程序：打造平台类产品。
  to内部员工：打造公司内部员工使用的客户支持工具。
  toC：为消费者量身定制产品。

理念探索技术

• 客户访谈：最强大且最重要的技能之一，主要问题有：你的客户是你认为的那种人吗？他们真的存在你认为的问题吗？现在，客户是如何解决这个问题的？他们需要什么才能改变？
• 礼宾测试技术：快速生成高质量的产品创意，走到实际用户和客户身边，让他们教你他们是如何工作的。
• 客户不当行为力量：鼓励客户使用产品解决计划/规定之外的问题。
• 黑客日：是一种内部产品创意(定向和非定向），可以使用这种方法来打造传教士般的组织。

原型探索技术

• 原型原则：使得成本更低，强迫我们在更深层次思考问题，强大协作工具，有不同程度的保真度，解决一个或多个产品风险（价值、可用性、可行性）。
• 可行性原型技术：通常工程师使用代码来创建可行性原型，工程师给出大概的时间成本，团队是否花费这个成本由产品经理决定。
• 用户原型技术：用户的原型不只是原型图，根据不同的目的选择不同的原型技术，低保真原型传递：信息和工作流，高保真原型传递：交互、布局，模拟业务场景。
• 实时数据原型技术：是一个非常有限的工具，主要目的是解决重大风险，所以收集一些实际的使用数据，实际数据原型只是产品的一小部分，不过是最核心部分。
• 混合原型技术：原型+人工双重配合。

发现测试技术

• 测试可用性：产品经理和设计师必须参加每一项和每一次测试，目的是更深入了解用户和客户，找出并解决原型中摩擦点。
• 价值测试：定性价值测试：用户会不会花钱？定量价值测试：用户会花多少钱？
• 需求测试技术
• 定性价值测试技术：从金钱、时间、信誉、其它方面对用户进行测试。
• 定量价值测试技术：收集具体的证据。
• 技术可行性测试：由工程师进行，产品经理要注意控制成本。
• 业务可行性测试：业务的可行性涉及各个部门：营销，销售，财务，合法，安全，客户，业务发展。

转型技术

• 发现sprint技术：敏捷化产品开发，不只是研发流程，是整个产品周期。
• 试点团队技术：从小范围开始实施、改变，然后逐渐扩大。
• 让组织摆脱路线图：采用故事地图或用户故事来进行迭代

过程与规模

在过程中要管理好利益相关者，做好产品知识的沟通，最好每1-2周分享产品近况。

利益相关者包括但不仅限于：管理层，商业伙伴，财务部门，法务部门，合规部门，业务发展部门。关键技巧有：和利益相关者进行一对一的交流；不要构建好方案才展示，学会预展示；产品经理和利益相关者意见一定要统一。

正确的文化

优秀和糟糕团队对比

【优秀】

• 振奋人心产品愿景，像一群传教士
• 观察客户分析痛点，结合新技术挖掘灵感
• 从关键干系人收集需求
• 专注于客户
• 庆祝成果
• 不断主动创新

【糟糕】

• 没有清晰的目标，像一群雇佣军
• 从销售和客户那获得需求
• 从所有干系人收集需求
• 专注于竞品
• 庆祝上线
• 等待授权

失去创新缺少东西

• 以客户中心文化
• 振奋人心愿景
• 目标明确的战略：最容易导致产品失败的原因就是试图取悦每个人
• 优秀产品经理
• 稳定产品团队
• 工程师参与产品发现
• 被授权的团队
• 产品思维与工程思维结合
• 企业勇气

失去速度的首要原因

• 技术债务
• 缺乏优秀产品经理
• 缺乏产品愿景和战略
• 没有统一文化
• 没有稳定的团队

构建一种强大产品文化

• 持续创新
• 执行