开发产品，有两个永恒的关键字：差人、加班。
为了解决这个问题，第一反应是从项目管理层面去使劲。开发效率高不高？管理方法先不先进？有没有使用更多的管理工具？
关注点在「怎么做好」。
其实有些问题的答案从本质上看非常简单。
拿减肥来说，只用保证每天消耗的热量大于吸收的热量即可。
同样，差人和加班的问题，答案也很简单：少做点需求呗。
虽然简单，但不是人人都控制的好。因为在我们的传统认知上都有个默认设置，只要资源更多，就代表更好。开发产品时，也容易被这个默认设置牵着鼻子走，最终把大量的工作都浪费在了价值很小，或者无用的功能上。
这么来看，「少」不是单纯的指数量，而是强调需求的价值要高，关注点实际在「做不做」上。
要解决的问题也就变成，如何去识别「需求价值」？
关于需求价值，网上有很多定义标准，抽象、具体的都有。推荐两个即好理解，又实用的方法。
方法一：需求价值=需求刚性*需求广度*需求频率*可替代方案。
举个例子(为了便于理解，尽量选择大家都知道的背景)：
海底捞除了常规的饮料和水果，还可以提供可乐，服务员一般不说，除非你主动找他要。
套用公式分析该需求的价值：
既然有人主动要，肯定目的明确，一定是刚需；
不是所有人都喜欢，需求广度一般；
由于海底捞人流量大，可乐又符合大众口味，每天要的客人肯定多，需求频率也就随之很高；
考虑到成本，其他火锅店很少提供免费可乐，使得服务比较不容易复制。
综合来看，该需求价值就很大，尤其在“可替代方案”上，形成了竞争壁垒。
再举个反例：
微博上的计步功能。
计步只是刻意锻炼者的刚需，需求广度一般；
通常每天晚上才会查看总步数，需求频率不高。
微博既不主打运动，和微信比起来又缺乏熟人关系链，很容易被其他APP替代。
综合来看，该需求价值很小。
方法二：需求价值=需求收益-需求成本。
在产品迭代过程中，需求来源很多，尤其是运营口过来的需求，往往涉及到产品营收，个个十万火急。这就更需要在开发之前，定义好需求价值，理性的去判断紧急程度。
比如，运营有个需求，可以提高产品收益，必须要在本次迭代周期上线。遇到这种情况，产品经理应该和运营一起把该需求带来的收益和投入的成本尽量试算清楚。
假设该需求上线后可以为产品的每个季度收入多贡献1万，但开发需求投入的人力成本是3万，也就说明需求上线后要三个季度才能收回成本。
是否还继续做？是否还急着做？
把需求价值反应在一个定量的数字上，方便运营和产品双方去做出合理的判断。
如果对每个需求价值都能够定义清楚，排序后会发现，真正值得做的需求并没有那么多，「少」变成了自然的结果。
当然，这两个方法并不适用所有情况。
有些需求缺少对标数据支撑，有些需求是BOSS层面直接空降，这些都导致没办法用需求价值去定义。加上大部分的产品经理并不能100%去控制产品边界，有时不得不蒙眼干活。
所以，心中有把尺子的好处就在于，虽然你不能控制偏差，但是可以感知偏差，而「需求价值」就是这把尺子。
