当知道用户真正想要的是什么之后，需要去评估哪些需求或功能该做，哪些不该做；如果该做的话，哪些优先做，哪些后面做；接下来的工作就是确定优先做的需求或功能是在这个版本迭代实现还是下个版本迭代实现。管理需求这个环节，可从需求获取开始到需求的上线及其用户反馈结束，形成一个闭环循环的流程。前面阐述了产品的需求优先级是怎么定义的，本节将阐述：需求的工作量如何估算；研发优先级如何定义；使用什么方法或工具来管理需求；在项目迭代过程中遇到需求变更时怎么处理。
1.需求工作量的估算
在产品实践中，经常碰到这样的问题：完成某个需求的工作量有多大？如何去估算工作量？本小节就来介绍需求工作量的科学估算方法。常用的方法是斐波纳契数列（Fibonacci Sequence），又称黄金分割数列，指的是这样一个数列：1、1、2、3、5、8、13、21、…，这个数列从第三项开始，每一项都等于前两项之和，随着数列项数的增加，前一项与后一项之比越来越逼近黄金分割的数值0.6180339887…
下面以斐波那契数列为例，介绍需求工作量的估算（工作量以小时为单位）。
(1).选定参照物
选择一个中等工作量的功能或需求作为参照物，视为数字5。这里以微博的登录功能为例，功能主要有账户与密码的验证、记住登录状态和取回密码。登录功能的工作量视为数字5，这个数字5是工作量的参照数字，以它作为基准。
(2).团队成员定义工作量
以5~7人组成团队，每个人用斐波那契数列的数字1、2、3、5、8、13、21、…定义当前需求或功能的工作量，当然是基于与参照物数字5的对比。如果登录功能的工作量是5，那么发布微博的功能工作量有多大，5位团队成员分别给出数字答案：34、55、89、144、233。可以看出，5位成员给出的答案分歧很大。
(3).进一步明确需求
如果团队成员的分歧很大，需要澄清和进一步明确需求。分歧很大的原因是没有明确发布微博到底有哪些主要功能，这与在实际的产品工作中遇到的问题是一样的，只说产品要做某个功能，大概说了一下，就询问研发人员的工作量有多大，研发人员也估算不出来，因为需求不明确。所以当成员之间的数字分歧比较大时，需要相关人员明确到底有哪些功能，比如发布微博的主要功能有：发布最多有140个字的文本微博，或发布一张图片微博，或发布音乐、视频、话题和投票微博，需要有敏感词过滤功能，一段时间内不能发布相同的微博，账号被封的用户发布不了微博。明确主要功能之后，成员再次给出估算数字，这一次大家的答案是：34、55、55、55、89。从答案中可以看出，这一次团队成员的分歧不是很大。
(4).确定结果
如果团队成员的分歧不大，使用较高的那个数字作为需求或功能的工作量，或者使用出现次数较多的数字作为工作量。选取55作为发布微博功能的工作量，因为这个数字出现了3次。
按照上述方法逐条对需求定义其数字。通过这种方法，我们还可以估算转发、评论、私信等功能的工作量。
2.需求变更
产生需求变更在实际的产品工作中是正常的，没有需求变更是不正常的。导致需求变更的主要原因有：产品经理自己没有想清楚，比如，需求文档有逻辑漏洞，不细致，不准确；也有的是产品经理的“完美主义”情结在作怪；再有就是技术能力和资源的问题。对变更的需求进行评估，需要评估影响的范围有多大，是否有必要进行变更。确定需要变更时，还要看看是否一定要在当前这个迭代变更，有的变更可以放到下个迭代进行，也可以在下个迭代开始之前，有一个小的迭代版本，在这个小的迭代版本里实施变更。在需求已经通过评审并进入项目环节时，尽量减少不必要的需求变更。一旦确定需求需要变更，通常要以口头和书面文档形式通知相关人员。
3.需求管理工具
需求管理起源于需求获取，终结于需求的关闭，产品经理需要跟踪需求的进展和状态。在产品实践工作中，一般情况下虽然遵从上述规律，却研发的优先级等于商业价值除以工作量，但有的时候会碰到一些特殊的情况，那就是风险。在考虑投资回报率（商业价值/工作量）的同时，也要考虑同时带来的风险，这种情况下的解决方案是开发优先级先根据ROI排序，再根据风险、新知识、常识调整排序。内部使用的需求管理工具因公司而异，只要内部达成共识，建立体系规范，贯彻执行，需求和bug管理都可以使用诸如Trac、Jira或禅道之类的管理工具。
也许是经验不够，且入产品这行的时间不久，经常犯研发人员非常讨厌的一个毛病，那就是需求变更频繁。出现这种情况的原因很简单，就是自己也没有想清楚，说到底还是产品内功没有修炼到家。之前在估算需求工作量的时候，也基本上是拍脑门，有时甚至会被研发人员忽悠。现在好了，有方法论作支撑了，在版本和迭代规划方面，将会更加得心应手。
在敏捷开发模式中，经常会使用斐波那契数列来科学估算需求工作量。产品经理定义需求优先级之后，因为涉及需求工作量以及研发资源的调配等实际问题，还需要确定相应的研发优先级，研发的优先级等于商业价值除以工作量。研发的优先级定义的大原则肯定是先遵从需求的优先级，尽可能地按照需求的优先级来安排研发优先级。