不少刚入门的产品经理在面对复杂的需求时很难推动项目的高效落地，毕竟很多项目是要通过实验需求才能看清效果的。面对这种情况，产品经理可以做什么？本文作者解答了在推动产品落地过程中的常见问题，一起来看看吧。

在我们日常的产品工作工作中，有两个模块非常核心：

1. 设计/产出需求文档
2. 上线后拿到效果

客观来说，完整地执行好这两部分，需要很多的精力和经验才能不踩坑。

很多高阶产品经理，在面对一个项目(多个需求的集合)时，依然不能高效落地，原因就在于没有一套方法论，或者没有很好地复盘之前踩的坑。

今天，我们主要来说一下，作为一个想要晋升/已经高阶的产品经理，如何做到高效、高质量的落地。

首先，很多需求/项目是需要做AB实验、分析埋点、或者用户调研来看清效果的，简称为“实验”需求（即这个需求不是100%有正向收益，需要实验后才能明确）。

其次，实验是一套新的方法论，相较于做一些普通功能来说，有以下特点/难点：流程长、复杂度高、易遇突发问题、考量因素多。我们做的重点需求/项目，基本都是实验需求。

一、以例子开头

有个需求是「给体验不好的用户发券，降流失」，遇到了几个问题：

1. 上线后出现bug：需求文档上写明了——只适用于新用户，但后续环节出现问题、导致老用户也收到了券。不仅实验进度受了影响，而且花出去的钱浪费了。
2. 改了老bug，来了新bug：基于1的问题，技术改了，没想到又引发新问题。实验暂停。
3. 取不到数，无法进行分析：由于底层数据的问题，出现了意料外的情况，实验进度受了影响。
4. 实验效果有负向，怎么办：是不是需要优化实验方案？还是放弃这个实验方向？还是数据分析有问题？

以上问题易发，产品经理只能被动解决。虽然不完全是产品的锅，但作为owner，会受到各种质疑和责问，长此以往将失去老板、协作方的信任。

二、掌握主动权，产品经理可以做什么？

实验=做不明确的事，要快、准、狠地找到解法/结论。

首先要准（方向），找准方向，事半功倍。（经验/数据/用研的指导）

其次要快（效率），天下武功、唯快不破。（落地不delay）

再次要狠（成本），学会决策，不断迭代。（实验不成功，及时转变方向/调整方案）

以上为实验的指导方针，那么具体怎么做到呢？

首先，定义实验中的关键流程和约束条件。

1. 关键流程：我总结为四要素，好设计→控时间→保品质→拿结果。
2. 约束条件：时间(要求最晚上线时间)，人力资源(需要开发、运营、数据分析师、客服等协同)，不能有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逻辑比较复杂，需要多部门协同，技术变更了两次排期。

• 第一次变更：技术开发了一半，发现开发时间要拉长。
• 第二次变更：技术反馈开发复杂度高、测试需要更严谨、又拉长了测试周期。

在做复盘时，大家对问题产生的原因描述如下（不讨论各人能力问题）：

• 技术：产品急着要排期，所以对时间评估不充分。
• 产品：很委屈，早前和技术确认、给了几天完整的时间用于评估，且技术从未反馈时间不够。
• 产品：第二次时间变更，未提前告知我，是测试介入时间拉长、才发现的。

Q：怎么约束人的行为？

A：在实际情况中，我们能做的有限。

这类人在工作中遇到的并不多，以后的需求留个心眼，做一个仅对ta催命的PMO。

另外，遇到此类情况，需要及时复盘，减少以后出现的概率。

3. 保品质：bug降发生、及时发现

• bug的出现：源于测试case的不完整，特别是边界case、不好构造的场景、测试不知道的改动点。（不是说测试人员有问题，而是整体协作的问题）
• bug的发现：反馈渠道有限，比如进线、自己遇到、达到阈值报警，也有可能直到实验全量都不会发现。

Q：如何保障实验质量？

A：最担心的两个问题：

-实验没法看效果（没生效或出了bug或数据紊乱）；

-实验影响了别人（造成事故）。

所以，站好owner的岗，必须做好以下4件事：

1. 定义最小验收成本：定义能保证实验正常运转的产品验收case；推动测试case评审。

2. 定义最大适用范围：需求文档里专列一个模块，标注适用和不适用的情况，和RD、QA强调一定要测试到。

3. 监控：基于实验风险程度和重要性去评估要不要做。有两大作用：控制风险——超出阈值代表着「量级超出预期、可能存在bug」，比如大范围发券，一定要有阈值控制。保证质量——低于阈值代表着「量级太小，不满足评估条件、或者实验未生效」，用于及时发现问题。

4. 改动必回归：每一次的改动，都要及时回归，可以找测试帮忙。比如改了bug后、又影响了其他地方，如果没有监控、且未回归，就容易留坑。

4. 拿结果：≠拿收益，只是验证对错

我们需要正视的是，实验结果不一定是好的，甚至有可能负向。此时，我们应该有两种思路：

实验结果是准确的吗？——尝试去验证/发现问题。

实验结果是可改变的吗？——尝试去迭代/优化。

如果以上均告失败，那么，该转变实验方向了。

Q：没提升「某一核心指标」的实验=失败？

A：不是。 拿转化率来说，它可能是一级/核心指标，但不是衡量成功失败的唯一指标。如果一个实验没能提升用户的转化率、但提升了用户留存率，从长期来看也是成功的。

1. 每个实验指标不是唯一的，可以有很多辅助指标（用户频次、活跃、留存、功能埋点等），帮助分析问题、review实验价值。
2. 转化率的特性在于当时的刺激（比如优惠券刺激转化）等，如果要看实验的长期潜价值，可能需要其他指标的辅助（比如用户留存）。

Q：如何定义辅助指标？

A：需要基于公司大目标、实验内容来灵活调整。比如公司大目标是订单量增长，那么：

核心指标应该是订单量。

二级指标，比较通用的是用户量、人均下单频次、转化率这些。

三级指标，需要基于单个实验内容，比如曝光、点击、停留时长等。

Q：效果不达预期怎么办？

A：有三种情况。

一是环节问题，太多地方能出问题了——方案设计不合理、存在bug、取数口径…

二是评估问题，可以精细化拆解，通用方式是城市差异、新老用户差异等。

三是方向问题，没有bug、没有错误，只是因为实验方向不对、对未来预判错误，不过这个点比较难被接受。

以上，希望能帮到你。欢迎补充和提问~

本文由 @小乔 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议