第一部分 来自顶尖科技公司的教训

1.每一个优秀产品的背后

产品经理：领导产品团队将技术和设计相结合，用一种符合业务需求的方式，来解决客户真正的问题。

2.技术驱动型的产品和服务

技术驱动型：数字化产品，但不需要完全数字化，可以是线上和线下体验的结合，比如AirBnB（Air Bed & Breakfast）

3.初创型公司

定义：尚未达到产品-市场契合点的新产品公司。

挑战：在资金耗尽前，达到产品-市场契合点。

4.成长型公司

定义：具有熟练技术和充足经验，达到产品-市场契合点的公司。

挑战：如何有效地成长和扩大规模。

5. 成熟型公司

定义：扩张成功，并希望创造可持续业务的公司。

挑战：需要始终保持产品创新，不断为客户和行业创造价值。

6. 导致产品失败徒劳的根源

工程师们通常已经尽其所能地在开发中实践敏捷模式，但被置身在一个瀑布式开发的大背景下。

1）创意的来源只是利益相关者驱动的产品，团队缺乏驱动力。

2）以商业案例产生优先路线图是荒谬的

3）产品路线图的真相

a. 我们的创意至少有一半是没用的。

b. 创意到实现通常需要几个迭代的时间

4）产品管理更偏向于项目管理

5）设计能够体现真正价值的时机已经过了

6）工程师仅写代码，介入的太迟了

7）真正看到的是交付敏捷，组织和环境完全不敏捷

8）以项目为中心

9）所有风险拖到最后爆发，客户验证太迟了

10）损失了组织的机会成本

7. 精益与敏捷开发的本质

利用精益与敏捷开发的核心原则，而不是设置门槛。

1）首先解决掉风险，而不是放到最后

2）产品定义和设计是交叉进行的

3）一切的核心都是解决实际问题，而不是功能实现

8. 关键概念

整体产品：对产品有一个非常整体、全面的定义，而不应仅仅关心需要实现的功能。

持续发现和持续交付：我们需要去发现将要打造的产品，将该产品交付给市场。发现和交付是持续和并行的。

产品发现：产品发现是产品管理、用户体验设计以及工程实现的紧密合作。四个关键问题：用户会选择我们的产品吗？用户知道怎么使用吗？我们的工程师能够实现产品吗？利益相关者会支持这款产品吗？

原型：测试产品创意。

产品交付：打造并交付产品，确保产品质量。

产品和产品-市场契合点：使产品和市场契合。

产品愿景：产品的长期目标，通常为2-10年，是我们作为一个产品组织如何去实现公司使命的打算。

第二部分 合适的人

9. 优秀产品团队遵循的原则

产品团队：跨职能团队，拥有不同的专业技能和责任，对产品拥有所有权。

特点：

传教士般的团队：致力于解决问题，而不是被吩咐做事情。

团队组成：产品经理、产品设计师、2-12名工程师。

团队权力和责任：有权提出实现目标的最佳解决方案，并对结果负责。

团队规模：两个披萨规则，团队差不多够分食两个披萨的规模。

团队汇报结构：产品团队中的每个人是独立工作的，只向他们的职能经理汇报工作。产品经理不是任何人的“老板”。

团队协作：坐在一起解决问题。

团队范围：产品团队负责所有工作，可能是一个完整的产品，也可能是一部分有意义的功能。

团队工期：应该具有持久性，团队之间需要磨合，且需要时间在领域中获得专业知识。

团队自主权：具有一定程度的自主权，才有激情像传道士一样解决问题。

1）产品团队培养团队成员之间的关系。

2）团队的持久性帮助团队获得专业知识，而创新需要专业知识的积累。

3）团队理解业务目标和场景，对产品有所有权和责任感，而不仅仅是打造别人认为有价值的东西。

10. 产品经理

产品经理具有的品质：娴熟的技术，商业的敏锐，关键管理者的信赖，深厚的客户知识，对产品的激情，赢得团队的尊重。

关键责任：

负责机会评估和决定构建什么产品交付给客户，真正难的是确定产品清单上什么值得构建。

产品经理的四项核心职责：

1）深厚的客户知识

深入了解客户和用户的问题、痛点、渴望和想法

2）深厚的数据知识

通过数据分析工具，了解客户如何使用你的产品。

3）深厚的业务知识

相关利益者相信，你清楚他们的约束，并在交付解决方案时坚持充分顾及所有这些约束。

4）深厚的市场和行业知识

了解竞争对手，技术发展趋势，客户行为和期望，关注相关的行业分析师，了解社交媒体对市场和客户的作用。

智慧、创意和持之以恒

智慧：充满好奇，快速学习

创意：正常产品功能框架之外，思考解决问题。

持之以恒：通过强有力的证据，不断的沟通，面对强烈抵制，建立桥梁，推动产品演进。

产品经理重要的两门课

编程语言和商业语言，商业包括商业会计和金融学入门。

11. 产品设计师

如何与产品设计师维护好关系：

让设计师参与你需要做的任何事情

创意初始阶段就让设计师参与

让设计师与客户和用户交互，一起了解用户和客户

给设计师尽可能多的空间解决设计上的挑战

鼓励设计师尽早且经常迭代，不是在最初的设计中就做到完美

12. 工程师

公开分享对客户的了解，将信息提供给团队，讨论解决这些问题的各种可能方案。

与工程师的交流：

发现产品的过程中，征求他们的想法

澄清与交付相关的问题

13. 产品营销经理

14. 辅助角色

用户研究人员：发现合适的用户，获取用户更多信息。

数据分析师：业务需求收集和报告的数据的专家。

自动化测试工程师：保证质量，提高测试效率。

16. 领导角色

组织的领导，首要工作是招聘，发展，留下优秀的人才，还要把握产品的大局。

产品管理领导：从业务的角度全面地看待整个系统。

产品设计领导：负责整体用户体验的人员，确保一致且有效的用户体验系统。

技术组织领导：负责系统的整体架构，制定明确的技术债务管理策略。

17. 产品主管

团队发展：培养出一个包括产品经理和设计师的优秀团队。

产品愿景和策略：需要管理与CEO之间对愿景的分歧

执行力：落地愿景，是产品规划、客户探索、产品发现及产品开发流程方面的专家。

产品文化：团队理解快速测试和学习的重要性。

其他：领域经验，处理好与其他高管私下的关系。

18. 技术主管

19. 交付经理

一般是scrum master担任，进行项目管理工作，致力于为团队消除障碍。

20. 组建产品团队的原则

. 向投资策略看齐

. 最小化依赖关系

. 所有权和自治权

. 充分利益杠杆：不希望重复造轮子，而开发公共服务会产生依赖关系

. 产品愿景和战略

. 团队规模：10-12个工程师，有且只有一个产品经理

. 向架构看齐：组建团队时，考虑架构问题，比如基础服务或平台团队

. 向用户或客户看齐：从用户层面，考虑团队架构

. 向业务看齐：从业务范围划分团队

. 结构在不断变化

第三部分 正确的产品

22. 产品路线图的问题

“至少一半的产品创意是行不通的”原因是：

没有价值：客户对创意不像我们一样感到兴奋

缺乏易用性：产生的麻烦比它的价值更多

缺乏可行性：开发的投入太多，负担不起成本

关键点是我们需要解决根本问题，而不仅仅是交付一个功能。

23. 路线图的替代方案

1）解决管理层想确定团队首先要做的是业务上最有价值的事情

提供业务环境：描述产品愿景和战略，描述业务目标

2）需要作出时间承诺

高完整性承诺：需要验证是真正的解决方案后，给出一定会履行的承诺。需要妥协，争取寻找和验证解决方案的时间。

24. 产品愿景与产品战略

产品愿景：描述了要努力创造的未来，通常2-5年。传达愿景，激励团队帮助实现这一愿景。

产品战略：实现产品愿景的道路上计划交付的产品或版本顺序。

25. 产品愿景原则

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

26. 产品战略原则

一次只专注于一个目标市场或一类角色，不要试图在单个版本中取悦每个人。

产品战略需要与业务战略保持一致。

产品战略要与销售战略以及上市战略保持一致。

关注客户，而非竞争对手。

组织全体成员参与沟通战略。

27. 产品原则

产品原则：描述了想打造的产品的实质。

28. OKR技术

职能部门的成员，应该以产品团队目标为主，如何考虑个人职能目标。

30. 产品目标与规模

大规模使用OKR时，需要有层层的目标，并管理这些目标的关联，管理高完整性承诺清单。

目标的确定要经历协调、评审过程。

随着公司规模的扩大，会有平台类的团队来支持其他团队。

31. 产品布道

使用原型；分享痛点；分享愿景；分享经验；毫无保留地信任；给一个精彩的演示；成为领域专家；发自内心地兴奋；学会表现出狂热；多花时间与设计师和程序员相处。

第四部分 正确的过程

产品发现

产品发现的挑战：

1）了解客户解决方案的细节需求是什么

2）确保交付一个超棒和可扩展的产品

一方面需要快速得到反馈，另一方面需要从产品中获得信心。所以既要在产品发现中快速学习，又能在产品交付中打造稳定可靠的产品。

产品发现的目的：工程师构建高质量的产品时，要有证据做支撑，确保这项工作不会是一种浪费。

33 产品发现的原则

产品发现的目的是解决如下风险：

价值风险：客户会购买或选择使用我们的产品吗？

可用性风险：客户知道如何使用吗？

可行性风险：我们能打造出优秀的产品吗？

业务可行性风险：这个解决方案对我们业务有用吗？

产品发现的原则：

1）不能依赖客户来告诉我们打造什么产品

2）最重要的事情是创造有目共睹的价值

3）工程实现很难，但好的用户体验更难

4）功能、技术和设计本质上是相互关联的

5）我们的很多创意并不会奏效，奏效的创意也需要很多次迭代

6）我们必须基于真实的用户或客户来验证我们的创意

7）尽可能以最快、最廉价的方式来验证我们的创意

8）需要在产品发现的过程中，验证创意的可行性

9）需要在产品发现过程中，验证创意的业务可行性

10）共同学习

共同了解用户的痛点，目睹失败和成功的创意。

34 发现技术概述

1. 发现框架技术：如何构建产品工作的基础框架

1）第一个目标是确保团队在整体目标刻画上保持一致。

2）第二个目标是定位产品发现工作中需要解决的重大风险。

- 机会评估技术：聚焦业务目标、关键结果、客户问题、目标市场四个关键问题

- 客户函件技术：通过撰写一篇想象的新闻稿，来说明产品一旦发布后是什么样子，从而提前制定工作框架。

- 初始画布技术：类似精益画布

2. 发现规划技术：确定范围并规划产品发现工作

- 故事地图技术

- 客户发现技术：找到6个参照客户

3. 发现构思技术：生成产品创意

- 客户访谈：访谈后，还要用用户测试来跟踪结果。

- 礼宾测试技术：体验客户真实在做的事情

- 客户不当行为的力量

- 黑客日

4. 发现原型技术：更低的成本学习一些东西；强迫你在一个更深的层次上思考问题；通过原型形成共识；有不同程度的保真度；在产品发现过程中解决一个或多个产品风险，通过原型规范沟通。

- 可行性原型：编写足够的代码来减少可行性风险。

- 用户原型

- 实时数据原型：发送一些数量有限的流量，并收集如何使用这个实时数据原型的分析材料。

- 混合原型技术

5. 发现测试技术：

-测试可行性：

-测试可用性：选择测试对象，准备任务和问题，通过原型测试

-测试价值：

1）需求测试技术：设置按钮，跳转至需求说明页面。一方面收集到需求的证据，另一方面获得客户名单

2）定性价值测试技术

定性测试与快速学习和洞察力有关。访谈-可用性测试-价值测试-迭代原型

3）定量价值测试技术

定量技术关于收集证据。A/B测试，邀请式测试、客户发现程序。

技术可行性测试：

问题不是“你能做到吗？”而是你让他们去探索并回答这个问题：“做这件事的最好方法是什么？需要花多少时间？”

6. 测试业务可行性：

解决方案也要服务于“业务” - 问题：什么是业务？利益相关者。理解每一个相关的限制、约束，在这些限制、约束中采取积极的行动。涉及营销、销售、客户成功、财务、合法、业务发展、安全、首席执行官/首席运营官/总经理。

7. 转型技术：

- 发现Sprint技术：《Sprint：如何在五天内解决重大问题、测试新的创意》

- 试点团队技术：对新的工作方式持开放态度的人去参与，让试点团队中的关键人员在一起工作

- 产品路线图的替代方案：致力于领导层决定的优先业务目标；透明地分享我们的关键成果；高完整性的承诺关键交付日期。

61 管理利益相关者

1）利益相关者的定义

大部分只是产品的输入来源。检验一个人是否是利益相关者：看他是否有否决权，或是否影响项目启动。

2）产品经理的责任

产品经理有责任了解各个利益相关者的考虑和约束，并将其带进产品团队中。并且要说服利益相关者，不仅了解这些问题，而且承诺提出的解决方案，既为客户服务，也有利于他们。

3）如何做

在产品发现中让关键的利益相关者预览你的解决方案。不仅要确保解决方案有价值，对客户而言是可用的，对工程师而言是可实现的，利益相关者会支持你的解决方案。

每周和你关心的利益相关者共同讨论。

62 沟通产品知识

每周或每两周，在全体员工或类似的会议上，产品负责人花15-30分钟，强调各团队产品发现中所学到的东西。

第五部分 正确的文化

64 优秀的产品团队/糟糕的产品团队

- 有一个振奋人心的产品愿景，带着传教士般的热情去追求它

- 观察客户的痛点，分析用户使用产品生成的数据

- 有效管理关键利益相关者

- 擅长很多技术，可以快速尝试产品创意

- 喜欢与来自这个公司的聪明人进行头脑风暴式的讨论

- 认为产品、设计和工程同样重要

- 在保护收入和品牌的前提下，不断尝试新创意

- 拥有对应的团队技能

- 每周都会直接与他们的用户和客户接触，以便更好地了解他们的客户

- 指导创意中有很多最终都不会服务于客户

- 评估可行方案后，做出高信用承诺

- 不断集成和发布

- 获取一个非常重要的业务成果时才进行庆祝

65 失去创新的首要原因

- 以顾客为中心的文化

- 振奋人心的产品愿景

- 目标明确的产品战略（优先级）

- 优秀的产品经理

- 稳定的产品团队

- 工程师参与产品发现工作

- 企业的勇气

- 被授权的产品团队

- 产品思维

- 创新的时间

66 失去速度的首要原因

- 技术债务

- 缺乏优秀的产品经理

- 缺乏交付管理

- 发布周期长

- 缺乏产品愿景和产品战略

- 团队成员工作地点不同，经常更换

- 没有尽早将工程师纳入产品发现工作中

- 没有在产品发现中使用产品设计

- 改变事情优先级

- 统一的文化

67 构建一种强大的产品文化

- 测试文化

- 开放思维文化

- 授权文化

- 技术文化

- 业务、客户、精明的团队三位一体的文化

- 技能组合和员工多样性的文化

- 发现技术的文化

- 紧迫感文化

- 高信用承诺文化

- 责任文化

- 协作文化

- 结果文化

- 认可文化

在创新和执行这两个维度上进行自我评估，问问自己希望你的团队成为什么样子，或者需要成为什么样子。