产品经理必备技能1——面对复杂的需求，如何高效落地.docxVIP

产品经理必备技能1——面对复杂的需求，如何高效落地 在我们日常的产品工作工作中，有两个模块非常核心： 设计/产出需求文档 上线后拿到效果 客观来说，完整地执行好这两部分，需要很多的精力和经验才能不踩坑。 很多高阶产品经理，在面对一个项目(多个需求的集合)时，依然不能高效落地，原因就在于没有一套方法论，或者没有很好地复盘之前踩的坑。 今天，我们主要来说一下，作为一个想要晋升/已经高阶的产品经理，如何做到高效、高质量的落地。 首先，很多需求/项目是需要做AB实验、分析埋点、或者用户调研来看清效果的，简称为“实验”需求（即这个需求不是100%有正向收益，需要实验后才能明确）。 其次，实验是一套新的方法论，相较于做一些普通功能来说，有以下特点/难点：流程长、复杂度高、易遇突发问题、考量因素多。我们做的重点需求/项目，基本都是实验需求。 一、以例子开头 有个需求是「给体验不好的用户发券，降流失」，遇到了几个问题： 上线后出现bug：需求文档上写明了——只适用于新用户，但后续环节出现问题、导致老用户也收到了券。不仅实验进度受了影响，而且花出去的钱浪费了。 改了老bug，来了新bug：基于1的问题，技术改了，没想到又引发新问题。实验暂停。 取不到数，无法进行分析：由于底层数据的问题，出现了意料外的情况，实验进度受了影响。 实验效果有负向，怎么办：是不是需要优化实验方案？还是放弃这个实验方向？还是数据分析有问题？ 以上问题易发，产品经理只能被动解决。虽然不完全是产品的锅，但作为owner，会受到各种质疑和责问，长此以往将失去老板、协作方的信任。 二、掌握主动权，产品经理可以做什么？ 实验=做不明确的事，要快、准、狠地找到解法/结论。 首先要准（方向），找准方向，事半功倍。（经验/数据/用研的指导） 其次要快（效率），天下武功、唯快不破。（落地不delay） 再次要狠（成本），学会决策，不断迭代。（实验不成功，及时转变方向/调整方案） 以上为实验的指导方针，那么具体怎么做到呢？ 首先，定义实验中的关键流程和约束条件。 关键流程：我总结为四要素，好设计→控时间→保品质→拿结果。 约束条件：时间(要求最晚上线时间)，人力资源(需要开发、运营、数据分析师、客服等协同)，不能有PR/法务风险，ROI投入产出比必须≥1.5，等等。 其次，规避“关键流程”里的“约束条件”下的坑。 在前面列举的约束条件下，会踩很多坑，不如： 求快，那么开发周期就要缩短，质量和功能完整度就会打折扣。 ROI约束，那么发券的范围、优惠额度会收窄，导致验证不出实验效果。 那么，如何找到最优解、尽量避坑呢？ 1. 好设计：磨刀不误砍柴工 追求短时间的快，可能带来长时间的慢。 a. 功能设计：实验一般都先做一个MVP极简版本，需要明确定义核心要素——保留对实验结果影响较大/有指导意义的要素。 比如要做用户任务、完成任务给予奖励，需要同时保留后端逻辑和前端感知（均对任务完成率有较大影响），任务配置后台就不用做。 b. 实验设计： 并联效率≥串联，分多个实验组，验证多个猜测、更好地指导迭代。比如： 给用户发券，想了解哪种券ROI最高，可以分几个实验组发不同金额的券。 评估实验效果，数据分析师写sql跑数 or 实验后台能直接看到数据，当然后者更方便且错误率低。 c. 定义实验指标： 指标直接关系着效果评估、实验成败，放在后面环节来说。 d. 技术方案设计： 缺失该环节，可能导致取不到数/取数不准/迭代困难。 在需求评审or开发阶段，需要和数据分析师、技术一起明确技术方案（关注要点即可，不必面面俱到）。 比如底层表里没有某项数据，大家均自信认为有，结果到了评估阶段，技术发现问题、数据分析师发现取不到数。 2. 控时间：定好排期后、减少delay Q：如何防范delay风险？ A：排除掉外部因素，基本就是人的因素，所以我们要针对人。以下主要说核心参与人员的避坑。 针对能力尚缺的人（评估失误），复杂的实验需要技术评审且技术leader要在，double确认排期、并确认开发难点（凭经验）有无问题； 针对没有承诺意识的人（不去弥补、认为提前告知风险就没有责任），和技术leader一起沟通、复盘问题； 同时，PM需要强调“排期准确性的重要程度=实验质量”，排期即为ddl（最晚上线时间）。 举个例子，实验A逻辑比较复杂，需要多部门协同，技术变更了两次排期。 第一次变更：技术开发了一半，发现开发时间要拉长。 第二次变更：技术反馈开发复杂度高、测试需要更严谨、又拉长了测试周期。 在做复盘时，大家对问题产生的原因描述如下（不讨论各人能力问题）： 技术：产品急着要排期，所以对时间评估不充分。 产品：很委屈，早前和技术确认、给了几天完整的时间用于评估，且技术从未反馈时间不够。 产品：第二次时间变更，未提前告知我