产品经理实战篇-面对复杂的需求，如何高效落地？

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

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、没有错误，只是因为实验方向不对、对未来预判错误，不过这个点比较难被接受。

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

本文作者 @小乔 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！