实际工作中，不管是来自主管还是其他部门，相信产品经理的需求都会受到一些合理质疑，主要质疑是：做了这个需求，能有什么效果？我看到部分产品经理在面对类似情况的反应不是一时语塞，就是回复“符合产品定位”“上线之后产品体验更好”等等较为无力、空泛的回答，做不到让所有人信服。

本文旨在针对上述问题，提出以下思路，来做到对产品常规需求有效衡量。

首先在需求层面，将需要衡量的需求划分为 4 类。分别为：

  • 完整新功能；
  • 线上已有功能优化需求（已有业务需求）；
  • 产品交互需求；
  • 产品性能优化。

其中比较好衡量「完整新功能上线」和「产品性能优化」这两类。对于完整新功能，这部分没什么可说，找到衡量新功能“北极星”指标（用户完整走完核心流程），在需求文档中定义注明需要打点数据字段，在上线后观察数据，并且同步团队。

产品性能层面的优化，根据具体性能优化目的，来决定是直接通过日志打点的单一方式还是日志打点加上用户反馈验证。用户反馈收集按照一定的方法论收集就可以做到。这部分不是难事。主要是部分需要日志打点的方式，需要在前期和技术沟通好。这类需求最好是和技术一起主导，既能增加技术人员参与感，也能在细节验证环节提供专业建议。

另外两类，可以统称为「功能优化」，具体细分为业务功能优化和产品交互优化。这两类可以根据需求优化目的来来决定衡量方式。如果是为提升核心流程转化率，那就看优化前后转化漏斗数据；如果是为提升用户效率，那就寻找“时间维度”数据，例如：用户走完核心流程页面跳转数、用户页面停留时间、用户完成核心流程时间等。另外这两类衡量方式也可以使用用户回访工具，根据用户反馈作出定量结论。

按照这个思路，常规需求都可以得到量化验证。但是现实情况往往复杂很多，这里通过极端举例再延伸说明：

如何验证产品经理修改功能文案的效果？

例子比较极端，但是是合理的，因为产品经理每个决策都需要付出成本。回到这个问题，目前我认为理想思路是不要直接去想文案需求的衡量标准，而是把它作为 OKR 某个 Task，把时间周期拉长，小任务对应到大目标，例如把文案修改效果归属到大目标某个功能转化率目标上。

所以方法论上，通过单一任务效果衡量方法加上把时间周期拉长，小任务对应到大目标的方法，不仅可以回答“做了这个需求，能有什么效果？”，还能回答“为什么要在现阶段来做这个需求？”。

方法论部分并不难，难得是实际运用并且形成一套固定模式。要真正做好我觉得还需要具备 2 个条件：要有效果验证意识和有的放矢。

有效果验证意识才能提前准备数据埋点，毕竟效果验证是一个量化过程，需要前期数据收集。尽量避免临时需要数据验证，然后发现没有数据的情况。

要有的放矢。并不是每个需求都需要去对应到一个效果结论，把握项目重点，团队认可就行。下面给出一个范例：

  1. 新/大项目，需要产品经理在项目开始阶段的需求原型中准备好需要的数据打点。一般情况下，在新项目上线一周后，项目数据同步到项目组成员，并且给出结论，当前数据表现好坏。（如何定义大项目：超过 4 人开发团队，开发时间 3 周及以上）；
  2. 非细节优化需求，需要项目经理认可（专家判断）。

以上，是对衡量产品需求效果的思考。