Marty Cagan 是一位产品大师，《启示录》一书的作者，担任许多知名公司的产品教练与顾问，2019年11月第一次来台湾演讲的消息，已经躺在我的微信收藏里很久了。整个演讲70分钟，网上也有一些关于此次演讲内容的整理。
相比40多分钟的译文阅读，周末我尝试花更多的时间来消化演讲的视频，我想这样除了能够有更身临其境的感受外，更多的是自己有更多的时间思考重点段落内容。
下面是一些「演讲内容」结合产品团队现状的一些思考。（非全部演讲内容）
稳定高频的发布节奏。团队的产品&研发组织，具备频繁发布的能力，意味着每个流程和交付物都被明确定义并达成一致，「教师双端」从三周甚至月版本，现在调整到两周一版已经持续了一个季度，PMO明确各方职责和时间点，进度由PM推进，实现了快速迭代，也完整的支撑了对线下转线上的项目调整。
PM被赋权。PM的赋权是敏捷的前提，被赋权的意思是「交由团队来找解决问题的最佳方法」，明确问题而不是告知ToDo项，这也是在「教师双端」迭代中我正在尝试践行的运作方式，伙伴们最近也陆续感觉到透传到他们身上的「问题」比ToDo明显增多。
但其本质对我个人来说，需要花的精力相对透传ToDo会多一些，主要精力在「提高重点问题分析和产出的敏捷度协作」上，以及现在会更加关注「伙伴解决问题的思考&决策路径」和「产品效果论证」，而不是ToDo本身。在风险可控的前提下，锻炼解决问题的能力、赋权与问责，是产品团队的长期价值，有信任才会有成长。
产品设计中有两种方向的设计思路：
「探索向产品」(Product Discovery)
「交付向产品」(Product Delivery)
它们在RoadMap上最核心的体现是：
如果你在设计一款产品or功能，如果它恰恰属于「交付向产品」，无论出于哪方的资源紧张或其他理由，PM被迫需要先上一版「MVP」来解决当下问题，那么请最好有两个心理准备：
1）需求不会被根本满足；
2）当前做的产品设计很快会被替代掉。
同一款产品不同的发展阶段，会在「探索向」与「交付向」之间进行相互转化，基于不同的目标、背景与阶段，我们应该采取不同的迭代策略来应用到产品设计中。
eg：授课端的「巡场面板」则是一个「交付向产品」的典型案例。
在大班场景中，「巡场面板」核心目标是营造授课感，而进入小班场景中，「巡场面板」承接了更多的个体场景诉求（看到每个孩子、指导孩子听课状态、在线状态、硬件设备等等）。
这场景的变化，需要在「巡场面板」底层重新设计产品逻辑，目标是确保每个学生的视频展现及状态是准确，表面上是产品策略的调整，实际上则是一套稳定可扩展的、需要重新定义的、完整的产品交付。对于这类诉求完整且稳定产品的设计，我们则不能适用敏捷迭代的思路来实践。
eg：虽然B端产品团队中「交付向」设计会多一些，但也不乏「探索向」的点。
「未来黑板」是一款主讲授课工具，我们发现很多老师站&坐立的情况下，「选择\笔触」的切换有较高的频率，但操作条的「上滑」又往往会造成直播课中的很多误操作和站立直播跨越全屏的上下操作。
我们要解决这个问题，满足老师可以授课中快捷切换的需求，这就是一个典型的「探索向产品」类需求，我们用一个灵活的悬浮窗，来快速解决当前的问题，让老师可以快速切换的同时，可随意拖动避免遮挡课件，这一定不是最终的产品形态，但一定能够敏捷解决问题的同时探索新的需求满足度。
在产品设计中，在产品经理接到了问题后，建议先判断属于「探索向」还是「交付向」，选用不同的设计和实践思路来落地。
Marty Cagan在《INSPIRED（启示录）》书中，介绍了产品失败的4大风险：
1）实行性风险(Feasibility Risk)：团队明确需求，但手边并没有解决问题的技术，或技术尚未成熟，就是「我们知道要做什么产品，但是做不出来」的状况
2）易用性风险(Usability Risk)：顾客想用这个产品，但不知如何使用，或太少人克服使用门槛，就是「产品做出来了，但是好多顾客看不懂、不会用」的状况
3）价值风险(Value Risk)：这个产品并没有解决顾客需求，为顾客带来价值，就是「产品做出来了，某些顾客也会用了，但后来都不继续用，因为没有满足需求」的状况
4）商业可行性风险(Business Viability Risk)：这个产品对公司没有商业价值，或无法在市场竞争中存活，就是「产品做出来了，顾客也爱用，但是无法赚钱，或拿不到更多预算与资金，或无法赢过竞争者」的状况。
我们也应该在工作中更加关注以下三个方面：
1.是否在产品上线前，避免了「4大风险」
在产品设计过程中，产品经理就应该在方案初步成型时考虑「4大风险」是否会在当前方案中被触发，尝试在方案设计中避免或选择更优解来替代。
2.如何解决可能存在的「4大风险」
我们常说一个完整产品的交付需要众多角色来配合实现，而产品方案中背景&价值介绍则是团队中各角色需要共同明确的点，一个问题可以用交互方式的调整、视觉设计的强调、技术方案的重构来解决，将问题在团队中拉齐认知，让所有角色All In 问题的解决任务中，共同讨论输出的最终方案，是最大限度可避免「4大风险」的方式。
3.「目标的达成」大于「功能的上线」
上述两点都会基于一个前提「产品团队被赋予的是问题，而不是功能」。这意味着，整个产品团队各角色的交付产出是「问题的解决成果」而不是「功能List的上线」，产品经理自己甚至协作团队各方来达成一致解决问题才是其最大的存在价值。
作为产品经理在团队协作中，无论当前的方案落地所涉及的各个角色是否是「平台化共用的」、「临时组成的」或者「新接手的」，都应该在团队中明确「一致要解决的问题」并从各方角度寻求解决方案，验证问题的解决和方案的收益，让各方参与者获得更多的价值感，而不是把产品方案做成「制造业的流水线模式」，这样整个团队才是一个完整的有内驱性的「Produce Team」而不是「Feature Team」。
一款产品如果只做针对线上问题及用户反馈的功能迭代，那多半这款产品正走在逐渐消亡的路上。产品的生命力在于持续「对多变用户需求场景的挖掘」和「超预期方案的探索」。
无论是面对市场上其他产品的竞争还是自己产品本身的新旧体验更迭，能够提出有「非常明显优势」的产品方案是做产品最难的一点。我们曾在2019年在线教育直播课堂千篇一律的产品中，探索小组课形态、探索智能笔产品、探索客厅场景价值......
持续努力的突破自己、突破团队设限，努力的产出并验证「非常明显优势的超预期产品方案」，是一种很宝贵很值得学习的能力。
我常常在产品团队内部分享时候说一句话，大意是，如果你只能对一个问题提出一
