18. 产品失败的根本原因
• 产品团队只是负责实现产品路线图
• 产品路线图本身
• 聚焦项⽬输出⽽不是产品结果
• ⼯程师和设计师参与太晚
• 最⼤的缺陷: 客户验证太晚
Truth / 事实
1. >50%的想法都不靠谱
2. time to money 将想法实现达到交付必要业务价值的程度通常需要多次迭代
3. ⼯程师通常是最好的创新来源
19. 基本原则
• Risks are tackled up
front, rather than at the
end
• Products are de
fi
ned
and designed
collaboratively, rather
than sequentially
• Finally, it's all about
solving problems, not
implementing features
• 最先解决不确定⻛险⽽不
是最后解决
• 协同定义设计产品，⽽不
是按顺序瀑布式
• 最后，⼀切都是为了解决
问题，⽽不是实现功能
20. 持续发现与交付
“We need to discover the product to be built, and we need to deliver that product to
market”
“我们需要发现要构建的产品，并将该产品交付推向市场”
21. Product Discovery / 产品发现
• Will the user buy this (or choose to use it)?
• Can the user
fi
gure out how to use this?
• Can our engineers build this?
• Can our stakeholders support this?
产品发现的⽬的是快速将地把靠谱的想法与坏的想法分开。
产品发现的输出是经过验证的产品需求储备(product backlog)
• ⽤户会购买(或者说选择使⽤)吗？
• ⽤户能明⽩如何使⽤吗？
• 我们的⼯程师能实现吗？
• 我们的相关决策者能⽀持吗？
26. The Product Manager
• 产品经理将每个问题和决策上报给CEO/⽼板 (项⽬管理)
• 产品经理召集所有业务决策者，让他们开会来解决问题
• （由委员会来设计，很少会产⽣平庸以外的东⻄。）
• 产品有能⼒做应该做的⼯作
产品经理的⼯作基本上有三种⽅式，基本只有⼀种⽅式才能取得成功
“The honest truth is that the product manager needs to be among the strongest talent in the company.”
“必须承认，产品经理必须是公司最优秀的⼈才之⼀。”
27. PM Key Responsibilities
产品经理关键责任
负责评估机会，并确定构建并交付给客户的内容
通常会描述为需要在产品储备需求池(Product Backlog)中构建什么
难点是确保产品需求确实值得构建 Evidence / 证据
“When a product succeeds, it's because everyone on the team did what they needed to do. But when a
product fails, it's the product manager's fault.”
“当产品成功时，是因为团队中的每个⼈都做了他们需要做的事情。
但当产品失败时，这就是产品经理的错。”
28. Smart, Creative and Persistent
“The successful product manager must be the very best versions of smart, creative, and persistent.”
“成功的产品经理必须是聪明、有创造⼒和坚持不懈的最佳版本”
聪明 - 好奇，快速学习，应⽤新技术为客户解决问题，触达新受
众，或启⽤新的商业模式
创造⼒ - 跳出圈外来解决业务问题
坚持 - 以令⼈信服的证据，不断的沟通，并在顽固的抵制下跨职
能部⻔架起桥梁，将公司推离他们的舒适区。
30. Engineer
“There's probably no more important relationship for a successful
product manager than the one with your engineers”
“对于⼀个成功的产品经理来说，可能没有⽐与你的⼯程师的关系这
更重要的关系了。”
⼯程师的⼠⽓在很⼤程度上是你作为产品经理的作⽤。你的⼯作是
确保他们是传教⼠⽽不是雇佣兵。你需要让他们深度介⼊到你试图
解决的客户痛苦和你⾯临的业务问题中。不要试图隔离他们，⽽是
与他们公开地分享这些问题和挑战。
Tips:
Take Computer Science Class
31. Good / Bad Product Development Team
• 优秀的团队拥有令⼈信服的产品愿景，他们以传教⼠般的热情追求。差团队是雇佣兵。
• 优秀的团队从他们的愿景和⽬标、观察客户的挣扎、分析客户使⽤其产品所产⽣的数据以及
不断寻求应⽤新技术来解决实际问题中获得灵感和产品理念。差团队从销售和客户那⾥收集
需求。
• 优秀的团队了解每个关键的相关决策者是谁，他们了解这些相关决策者所处的约束条件，并
且致⼒于“发明不仅适⽤于⽤户和客户，⽽且还适⽤于业务约束的解决⽅案”。差团队从相关
决策者那⾥收集需求。
• 优秀的团队善于运⽤多种技术快速尝试产品想法，以确定哪些想法真正值得构建。差团队召
开会议以⽣成优先功能路线图。
• 优秀的团队喜欢与公司内聪明的思想领袖进⾏头脑⻛暴讨论。当团队之外的⼈敢于建议他们
做⼀些事情时，差团队会被冒犯。
• 优秀的团队有产品、设计和⼯程并肩⽽坐，他们接受在功能、⽤户体验和技术之前的取舍。
差的团队坐在各⾃的⼯位⾥，要求其他⼈以⽂档和安排会议的形式请求他们的服务。
• 优秀的团队不断尝试创新的新想法，但这样做的⽅式既能保护收⼊，⼜能保护品牌。差团队
仍在等待运⾏测试的许可。
• 优秀的团队坚持要求团队的技能，例如强⼤的产品设计，创造成功产品的必要条件。差团队
甚⾄不知道什么产品设计师事⼲嘛的
32. Good / Bad Product Development Team
• 优秀的团队确保他们的⼯程师每天都有时间试⽤Discovery中的原型，这样他们就可以为如何
使产品变得更好贡献⾃⼰的想法。差团队在Sprint计划期间向⼯程师展示原型，以便他们进⾏
评估。
• 优秀的团队每周直接与最终⽤户和客户接触，以更好地了解他们的客户，并了解客户对他们
最新想法的反应。差的团队认为⾃⼰是客户。
• 优秀的团队知道，他们最喜欢的许多想法最终不会有效，⽽那些有效的想法需要多次迭代才
能达到他们所期望的结果。差的团队只需构建路线图上的内容，并对会议⽇期和确保质量感
到满意。
• 优秀的团队理解速度的必要以及迭代的快速性是创新的关键，他们理解这种速度来⾃正确的
⽅法论，⽽不是强迫劳动。差的团队抱怨他们速度慢，因为他们的同事⼯作不够努⼒。
• 优秀的团队在评估请求并确保他们有⼀个可⾏的解决⽅案，可以为客户和业务提供帮助后，
做出⾼度诚信的承诺。差的团队抱怨⾃⼰是⼀个以销售为导向的公司。
• 优秀的团队会检测⾃⼰的⼯作，以便他们能够⽴即了解他们的产品是如何使⽤的，并根据数
据进⾏调整。差的团队认为分析和报告是⼀个不错的选择。
• 优秀的团队不断地集成和发布，知道持续不断的⼩版本流为他们的客户提供了⼀个更稳定的
解决⽅案。差的团队在痛苦的集成阶段结束时⼿动测试，然后⽴即发布所有内容。
• 优秀的团队关注他们的样板客户。差的团队对他们的竞争对⼿着迷。
• 优秀的团队会庆祝他们对业务结果产⽣重⼤影响。差的团队会庆祝他们最终发布的东⻄。
