分析需求的商业价值。
一个公司做任何产品，一个产品做任何需求，最终都是要满足一定的商业目的的，所以需求的商业价值是最关键的内容。使用重要性，紧急度，持续时间三个指标来衡量商业价值。有条件的团队最好利用群体智慧，举行需求讨论会。
某个用户是老板的朋友，通过大老板天外飞仙的提过来一个需求，就很可能是一个超级紧急的需求，但重要性未必很高。持续时间是指需求是有生命的，有的长寿，有的短寿。比如迎合过年过节的运营活动需求，一般就比较短寿。商业价值（或者叫商业优先级），是对上述几种商业价值指标的综合评判，是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向。
还可在列表里增加一列商业价值描述，即这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。如此重要的商业价值评估，是在需求讨论会上由产品团队集体讨论，再叫上有必要的干系人，比如销售、实施等。对于某个需求，需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解做一番陈述，主观定个级别，比如高中低，然后再由大家讨论，上述那么多的维度可以加权平均，得到综合的商业价值。所以在这个讨论会之前，每个人都应该做好功课。
绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做了。我们现在知道了每个需求的商业价值，接下来决定做哪个，还需要另一个关键的指标，那就是实现难度。有时候我们会叫上技术人员代表参与需求讨论会，当场确定这个指标，但更多的情况是留给做技术的同学一点儿时间。会后与相关的人员讨论确定。
但实现难度太难量化，把工作量简化为开发量，项目各类人力资源有产品开发，测试，服务等，但一般情况下，团队里产品人员资源相对富裕，测试资源可以调配，服务资源可以临时补充，所以开发资源经常成为瓶颈。于是我们一般评估每个需求的开发工程师的工作量来表征其实现难度，这背后的道理是以团队里的瓶颈资源为评估标准，这个时候需求其实并不明确，只知道要做哪些，还是比较粗略的，而具体怎么做根本都没有考虑，所以有的技术人员呢会觉得无法评估开发量。这一点很正常，他们说了你们不明确每个需求怎么做，他们就无法准确评估开发量，我们说没有那么多时间明确每个需求该怎么做。你们不评估每个需求的开发量我们就不知道有哪些值得进一步分析怎么做而哪些又不值啊，于是就死循环了这类先有鸡还是先有蛋的问题。
其实也无需纠缠，实际的开发量是非评估不可的，把它叫做初评，允许误差，而且会要经验丰富的人来评估，通常是技术经理或者系统分析师，架构师，他们做出简单的评估，并且靠不断的实践来反复修正。评估者通常估计自己做这个需求要多少时间，然后乘以一个系数，这个系数大于一，反映着相应技术团队的平均技术能力这里的评估一般用人天为单位。某个需求需要一人天，意味着一个人做一个工作日。相对于初评，在项目启动之后，制定项目开发计划的时候，还会有一次更精确的评估，那个时候需求怎么做已经知道有哪位开发工程师来做，可以推算出相对准确的工期。工期和工作量是有很大区别的。比如生一个小孩儿需要一个女人十个月的时间，工作量可以说是十人月，但十个女人一个月的时间同样十人月是绝对完成不了。这个任务的不管几个人工期都只能是十个月。
我们已经做了需求采集；把用户需求转化为产品需求；知道了某个需求的基本属性、种类、商业价值、开发量。现在似乎应该开始写文档干活了吧？但经验告诉我们不是这样的，绝对不能因为某个需求的实现难度小，就马上去做。也不能因为另一个需求的实现难度大，就不做。说实话，能在列表里出现的需求，严格意义上讲没有任何一个是没有价值的，也没有任何一个是做不了的，那么到底先做哪个后做哪个呢？不要试图满足所有用户，一切皆看性价比，性价比等于商业价值除以实现难度，其中实现难度可以简化为开发量。那么现在可以做决定了。我们把产品需求列表按照性价比一列从大到小排序，先做排在上面的就可以了。实际工作中，对于性价比的判断还是会经常有偏差。一个原因是自己经常和哪类人接触，和工程师直接接触，经常听到他们抱怨某个需求太麻烦之类的，综合考虑的时候有点儿倾向于做实现难度小的；而如果经常和销售运营的同学一起开会，就会倾向于更多的考虑这个商业的价值。