聊聊需求的价值如何度量

这是鼎叔的第九十篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

前文说过，度量需求的数量和时间比较容易，度量需求大小（颗粒度）要麻烦些，那么，度量需求的价值呢？

outcome比output重要，价值比需求规格重要

我们最终给用户交付的是具体的价值，而不是平台统计的需求个数。如何保障我们以价值交付为中心？

度量需求价值的方法很简单，但要落地不容易，来自产品团队的阻力可能会很大，需要高级管理者的支持。

产品团队对需求价值度量可能会敏感，就好像开发对于用有效代码量或缺陷数量度量自己的成果，也很敏感。我们务必树立一个共识：交付需求的价值评估，不会用于衡量产品经理的绩效，仅仅用于集体协作和自我改进。

“价值”这个词本身就是手提箱词汇（suitcase），你可以从任意一个角度去定义价值，这反而导致团队从实践的第一步就开始纠结。选错了定义的维度，会不会导致很难看到进步，会不会带来虚荣业绩？

其实这个不重要，只要产品经理给出一个锚定价值的任何指标，需求价值提升活动就成功了一半。

度量需求交付的价值，两步法：

第一步，产品负责人要在需求讨论阶段定义价值指标，而且指标足够简单透明，比如：

• 本需求是满足用户的紧急需求，度量指标就是用户通过UAT验收。

• 本需求是提高用户在某个场景的满意度，度量指标就是用户对该场景的反馈满意度上升了多少个点。注意：老板也是需求的一类用户。

• 本需求期望用户在本场景的渗透率提升，度量指标就是渗透率从XX%提升到XX%。

• 本需求期望通过新特性达到拉新效果，度量指标就是通过新特性入口，上线1个月吸引新用户注册数XXX人。

• 本需求期望提高老用户活跃度，度量指标就是埋点场景的用户使用次数提高XX%，UV提高XX%。

不同的干系人从不同的收益角度会有自己的指标看法：

• 不同产品发展的阶段，会有不同的侧重指标；

• 有的指标看重短期效果，有的指标看重长期价值；

• 有的指标体现了用户场景的普适性，有的指标体现了需求的长期稳定性，还有的指标体现了产品战略的一致性。

最终还是应由产品负责人确定哪个是关键指标。产品负责人有权决定指标多少是符合预期，且每个需求的指标都可以不同，不鼓励拿通用指标管所有需求。

只要有这个指标就很好，其他角色不用质疑指标是否合理。

第二步，成功的另外一半，来自需求上线后的集体复盘。成功上线一定时间后，在团队复盘会上，对需求是否达成价值目标的数据进行快速确认，如果没有达成目标，产品人员进行原因分析并记录教训。

我们系统从组织层面会度量这几个关键数据：

• 多少需求在开发前设定了价值指标？

• 多少需求上线后进行了价值是否达成的复盘？

• 多少需求达成了价值目标？没达成目标的需求，是否留下分析记录？

从大型组织层面，只要有这几个指标能跑起来，就会走向胜利，不用关心不同小组的产品目标是否有进取心。团队自己会养成闭环改进的舒适习惯。

PS：还有一个万能的价值交付度量指标，用户NPS。 不过为了精确度量本需求带来的价值，团队可能需要在功能生效时马上让用户填写本场景的NPS，但这门槛也挺高呀

产品经理很排斥度量需求价值的两个理由，很有意思，我们剖析一下：

一 以前我说清楚需求规格，你就吭哧吭哧去实现了，大家精诚团结多好。现在你还要质疑我的需求，还要秋后算得失，狗子你是不是不爱我了？

二 产品需求就是要各种尝试啊，不试我们怎么知道用户喜不喜欢呢？不多试试我们怎么达成考核目标呢？谁能保证预估的价值一定能达到？

回归精益需求的本质，小步快跑探索试错是对的，但是跑之前不定目标，跑之后不复盘，就没有办法有效提升交付水平。

需求的技术实现和验证，耗费总成本远大于需求规格制定成本，用精准的价值描述有利于让整个团队理解用户和商业，让技术任务更有目标导向。

其他相关知识：KANO指标模型。聊聊精益需求的产生过程