如何对产品需求进行复盘？这里提供了一个有效的复盘思考框架.docxVIP

如何对产品需求进行复盘？这里提供了一个有效的复盘思考框架 PAGE 9 如何对产品需求进行复盘？这里提供了一个有效的复盘思考框架 通过这个复盘框架，可以有效的帮我们梳理清楚当时需求提出的背景、依据、执行的大致过程，以及是哪个环节的问题导致了失败的结果，从而使我们不断的反观自我，从失败的经验中快速总结与提升。前段时间读孙陶然的书，其中提到的一个观点我挺赞同的：人的学习途径有三种：一是向书本学习，二是向先进学习，三是向复盘学习，而向复盘学习也是最为重要的。所以我逼迫自己养成了一个习惯：阶段性的对过往的产品需求进行复盘。不复盘不要紧，一复盘吓一跳，在我对近四个月的产品需求进行系统性的复盘后，我发现自己所做的需求中有38%属于失败需求（对数据产生了负面的影响），有31%的需求属于中性需求（对数据并未构成明显影响），而另外31%的需求属于正向需求（对数据有积极影响）。这其中有我的原因，也有公司的原因（部分失败需求是被迫提上线的），但归根到底是我的原因。当然这不是今天我要说的重点，今天的重点是和小伙伴们分享一下这次复盘时我所用到的思考框架，希望对大家有所帮助。通过这个复盘框架，可以有效的帮我们梳理清楚当时需求提出的背景、依据、执行的大致过程，以及是哪个环节的问题导致了失败的结果，从而使我们不断的反观自我，从失败的经验中快速总结与提升（要知道这些可都是血淋淋的代价）。一、需求提出方是谁？产品？运营？推广？技术？老板？很多时候需求的提出方可能并不是我们自己，是由他人提出的。记录需求的提出方是谁有助于我们重新梳理当时的决策过程，如果提出的是失败需求，就算不是我们自己。那么也应当思考：为什么自己没有阻拦这次需求，反而是让失败的需求顺利的上了线？当时如果提出了质疑，为什么我们没有继续说服别人？如果是我们自己提出的，就更应当反思了，当时在做出决策的时候是哪个方面的原因使我们产生了误判？这种误判是自己的思维习惯还是思维漏洞？这些都是值得我们深刻反思的。在这次复盘的过程中，我发现一个失败的需求：社群功能。这个需求当初就是由推广团队提出并且坚持要做的，需求讨论的时候，我和推广团队之间还发生了巨大的分歧，但是谁也没能说明谁，最后只有妥协以MVP的方式去进行尝试。结果耗了一个月的开发资源去做，上线后转化率和付费率都是极低的。以至于这件事情过后，我立了一个规矩：所有的需求都必须有明确的需求依据，缺乏明确依据的需求一概拒收。二、需求的依据是什么？数据分析的结果？用户调研的结果？竞品分析的结果？个人的经验判断？从上面四个依据中，不难发现：数据分析的依据是最难的，需要对需求的详细分解和推断之后才能给出结论，并且产品上线后也需要持续的观察数据的变化，以判断产品的改动是否符合预期。用户调研往往也需要耗费一定的时间和精力，需要搜集一定量的用户数据后经过分析才能得出一些初步的结论。而竞品分析相对不是很靠谱，在很多人理解起来就是竞争对手做撒，我们跟着做就好了。而个人经验是最简单的，也是最不靠谱的，全凭个人的感觉和判断，也就是纯粹的个人YY。在我对需求进行复盘的过程中，我发现失败的需求大多有个特点：有着极强的个人主观经验判断，而缺乏严谨的数据分析和用户调研。大多时候是由什么内部的“决策层头脑风暴”之后提出的，严重缺乏数据的依据和用户的反馈。这是非常值得我以后警惕的。三、需求的目的是什么？提升产品核心数据？优化产品核心体验？测试新的用户需求？修复重大产品问题？复盘需求的目的其实是对我自己的一种反思，我发现自己存在这样的习惯：紧跟着版本节奏，快速的推进产品的迭代，然而迭代之后具体的数据追踪和结果跟进工作却做的比较少。事后我反思：发现自己做一个需求的时候，目的是比较模糊的，所以导致数据追踪和结果根据方面并没有思考太多。对于需求目的进行复盘也就是帮助我们梳理清楚以下几个问题：需求的目的是否清晰？结果是否达到了我们的目的？从而也帮助我们检讨自己，是否在后续产品设计中，加入了很多与产品目标无关的需求。四、需求的类型是什么（KANO模型）？基本需求？期望需求？兴奋需求？在做产品时间长了之后，我越来越发现：明确产品的发展阶段很重要！清晰自己这个阶段什么能做、什么不能做很重要！我们都知道产品是有生命周期的，不同阶段产品的侧重点也是不一样的。我们也都有这样的经历：在做产品的时候突然的灵光一现，想出一个极好的创意，兴奋的不行。但是如果把这个创意放在KANO模型中思考一番后，我们发现产品当前还处于需求验证阶段，最核心的任务是验证需求的真伪，而自己想出来的很多创意往往只是一种兴奋需求——有了更好，没有也影响不大。用KANO模型进行分析的主要目的是