什么是产品需求？待实现的产品功能对于产品来说就是产品需求。
在实际工作中，我们很容易将“用户反馈”、“用户需求”与“产品需求”的概念相混淆，这主要是因为它们很多时候所表达的内容是相同的。例如“首页页面上应该有一个搜索功能”，这是用户的反馈信息，同时它就是用户真实的、具体的需求，而产品需求也就是要在首页页面上增加一个搜索功能。
但是事实上，“用户反馈”、“用户需求”、“产品需求”三者之间有着本质的区别。我们可以用一个简单的例子来说明这一点：
用户反馈：固定电话听筒的电缆应该有10米长。
用户需求：可以拿着电话在房间的任何一个地方通话。
产品需求：无绳电话。
从这个例子我们可以看到，“用户反馈”并不等同于“用户需求”，也不等同于“产品需求”。如果我们直接将“用户反馈”当成“用户需求”或是“产品需求”，那么我们最后很可能在自己毫无察觉的情况下做出错误的产品决策——将固定电话听筒的电缆做成10米长。因此，对“用户反馈”、“用户需求”和“产品需求”进行严格的界定是非常有必要的。
产品经理首先从用户那里收集反馈信息，然后从用户反馈中分析出用户需求， 再根据用户需求规划产品功能，这些待实现的产品功能对于产品来说就是产品需求。
收集用户反馈，分析用户需求，最终的目的都是为了产生产品需求。产品的用户需求是无限的，相应地产品需求也会大量积压在产品经理手中。为了便于记录、评估和跟踪产品需求，产品经理需要创建和维护一张产品需求列表，对所负责产品的产品需求进行系统的管理。
一、将用户需求转化为产品需求
用户需求的来源有很多，而且非常零散，可能来自某次用户调研、某次头脑风暴会议、某次数据分析，也可能来自高层突然的决策。我们并没有能力在短时间内满足所有的用户需求，如果没对这些需求进行系统的整理和管理，那么时间一长，很多需求就会丢失，而一些关键需求的遗漏对于产品来说是重大的损失。
我们习惯将用户需求转化为产品需求再进行管理，因为多数时候凭借经验根据用户需求制定初步的产品解决方案并不需要耗费多大的精力，却可以让我们更加深入地理解用户需求以及用户需求和产品之间的关系，同时也方便我们准确地评估满足用户需求的产品方案的技术可行性和优先级。
针对不同的产品，我们进行产品需求管理所要记录的内容也不尽相同。下面是一张用Excel表格制作的简单的产品需求管理列表。
表中每一行记录了一个产品需求。
需求名称：产品需求名称就是根据用户需求规划的产品功能的名称，也就是我 们期望提供给用户的功能，例如“换肤”、“订单物流信息”。
需求描述：需求描述是用简洁的语言对该产品需求进行解释。需求描述不用考虑产品功能技术层面如何实现，而是要以用户的视角说明产品提供了哪些功能，这些功能是如何被使用的。需求描述建议按“谁可以执行什么操作，获得什么好处”的格式来写，例如“已下单的买家可以查看订单物流信息，以了解并跟踪订单物流”。这样写就能够说明产品要提供什么功能，用户能够获得什么好处，整个需求也就非常清晰、具体了。
二、记录产品需求的属性和信息
选择性地记录产品需求的一些重要属性，将有助于我们更好地管理产品需求，如产品需求所属模块、产品需求的需求类型等。
需求所属模块：一个产品往往是一个复杂的功能系统，为了使它更容易分析和开发，我们会将产品分解成若干功能模块，每个功能模块负责完成一部分系统的子功能。需求所属模块就是产品需求所隶属的模块，用来直观地说明产品需求在产品结构中的具体位置。如果产品较复杂，那么我们还可以对模块进行多级划分。产品的模块划分要能够体现产品的功能结构和信息架构。比如，我们按照功能结构将一个视频网站的一级模块分为：首页、搜索页、列表页、详情页、专题页……然后按照信息架构将详情页下的二级模块分为：电影详情页、电视剧详情页、视频详情页……
需求类型：对产品需求进行必要的分类，不仅可以帮助我们更好地管理需求，而且可以帮助我们更好地分析需求，对每个需求的价值大小做出更加准确的判断。同样的产品需求可以按照不同的维度进行分类，具体采用哪种维度可以根据实际需要来决定。比如，一个C2C（Consumer to Consumer，个人对个人）电子商务网站可以按照用户身份的不同，将用户需求分为买家需求和卖家需求；一个客户端软件可以按照功能技术实现方式的不同，将用户需求分为客户端需求、服务端需求和Web（客户端内嵌网页）需求。
另外，产品需求背后还有一些重要信息，如果这些信息将来有可能成为产品需求决策评估的重要依据，那么它们也应该被记录下来。比如某个产品功能要实现的前置条件、某个bug重现的具体操作步骤等。
个别产品需求特有的背景信息可以记录在该需求的备注中。有些背景信息是每个产品需求所共有的，而且非常重要，那么这些信息就需要对每个需求进行记录，例如需求方代表。
需求方代表：需求方代表就是最初提出该用户需求的人员，比如，某运营人员代表用户提出了一个用户需求，那么相应的产品需求的需求方代表就是该运营人员。在产品需求的具体实施过程中，可能由于诸多原因（如原方案在现有技术条件下无法实现等），需求方案不得不不断调整，如果这时候产品经理不确定实现原产品需求的最初出发点，那么就有必要和需求方代表进行沟通，确保新的产品需求能够正确无误地反映用户的真实意愿。
三、确定产品需求优先级
确定产品需求的优先级是我们进行产品需求管理的主要目的之一。在产品需求管理列表中，我们可以很方便地对产品需求进行横向的比较，确定产品需求的优先级。
那么为什么要确定产品需求的优先级呢？
首先，对于互联网公司来说，时间总是有限的。互联网是个瞬息万变、高速发展的行业，大部分的互联网公司都崇尚“天下武功，唯快不破”的产品开发理念。在这样的环境下，即使是一款在行业内遥遥领先的产品，也可能在短短几个月内被竞争对手全面超越。这样的案例不胜枚举。
其次，对于互联网公司来说，资源总是有限的。一方面，有限的资源只能开发有限的产品功能；另一方面，要实现的产品功能过多必然会导致项目复杂度增加，一旦项目变得不可控，那么所要耗费的资源成本就会不成比例地大幅提升。
因此，大部分互联网公司都主张“小步快跑，快速迭代”的产品开发方式，每个阶段只选取最重要的产品需求进行开发，力争以最快的速度将产品新版本投入市场，通过不断地收集用户需求、不断地版本迭代来逐步地完善产品。为了确保每个阶段总是在开发最重要的产品需求，就需要通过确定各个需求的优先级来对产品需求进行取舍。
确定需求优先级是个非常重要的环节，它最终决定了产品会提供哪些功能，产品会长成什么样。不同的需求组合会导致完全不同的产品结果，优秀的产品经理应该在确定需求优先级上有自己清晰的思路。
判断产品需求优先级的主要依据是产品需求的产出投入比，即产品需求的产出价值与投入成本之间的比例。产出投入比越高，代表产品需求的效益越大，产品需求越值得我们开发；反之，产出投入比越低，代表产品需求的效益越小，产品需求越不值得我们投入资源。
价值：产品需求的价值包括它给用户带去的用户价值和它能给公司带来的商业价值。我们最终需要的是商业价值，但是商业价值往往是由用户价值带来的，产品的用户价值越高，产生的商业价值一般也越高。因此，产品需求价值的评估重点在于确认用户使用该功能可以获得什么利益，该功能满足了用户什么需求，有多少用户有这个需求，用户期望产品满足这个需求的迫切程度……然后我们对由此而产生的用户价值和商业价值进行综合评估，最后判断得出产品需求价值的大小等级。
成本：产品需求的成本指的是实现产品需求需要投入多少成本，包括开发产品功能要投入的人力成本、维持产品功能正常运行所需的硬件投入、产品功能后续的维护成本、产品功能所需的日常运营成本，等等。其中，大部分产品功能只需要投入人力成本将其开发出来就能够供用户正常使用，而在人力成本中，开发资源的投入往往是最大的，开发资源常常是产品实现过程中最大的资源瓶颈，因此，一般情况下，对产品需求成本的评估只要考虑开发资源的投入成本即可。产品经理可以凭借自身经验粗略地评估开发成本，也可以在开发人员的协助下完成这项工作。由于这时候产品需求的细节还不明确，开发人员只能给出大概 的开发成本评估结果，但是无论如何，这个结果对于我们确定产品需求的产出投入比已经有非常大的参考价值了。
确定了产品需求的价值和成本，我们就可以得出它的产出投入比了。如下图所示，需求A、需求B、需求C、需求D就是按产出投入比来确定优先级的。
除了产出投入比以外，产品需求优先级的判断还需要重点考虑以下一些因素。
（1）需求的紧急程度
有些产品需求虽然不重要，但是很紧急，它仍然应该被给予较高的优先级。我们可以将产品需求的紧急程度加权折算到需求的价值里，也可以单独对它进行考虑。
比如，上图中需求E是一个严重影响用户基础功能使用的bug，所以应该尽快解决。
（2）与产品策略的契合程度
产品策略用于指导一段时间之内的所有产品工作。它包括我们对产品的目标用户、产品定位、商业模式的设定，还包括我们根据市场环境等因素制定的产品竞争策略和产品发展路线。在确定产品需求优先级时，我们要充分结合产品策略进行考虑：一些与我们的产品定位不相符合的需求，即使产出投入比很高， 但为了不影响产品定位的清晰传达，仍然应该放弃；每个产品的自身情况都不一样，产品要有自己的发展节奏，每个阶段实现的产品功能要能够服务于这个阶段的产品目标；并不是所有重要的需求都要一下子推出的，有时候故意忽略人们非常需要的一个功能，反而能够激发起人们对它的渴望，当用户之后得偿所愿，获得这个功能之后，就会更加高兴……
比如，上图中需求I是用户非常期待的一个功能，实现起来成本也并不高，但为了制造期待效应，我们将它推迟到后续版本中实现。
（3）需求之间的潜在关系
产品需求之间往往会存在大量的潜在关系，只有充分考虑这些潜在关系，才能保证最后确定下来的优先级是合理的。
比如，上图中需求G和需求F都是要对产品的同一个功能模块进行改动，需求G如果和需求F一起实现只要1人日，但如果不与需求F一起实现则要5人日，那么我们就应该考虑让需求G与需求F一起实现。
再比如，上图中需求H与需求F有依赖关系，要实现需求F的前置条件是要先实现需求H，所以需求H必须先于需求F进行开发。
（4）实际可调配的资源情况
产品需求的优先级还要依据实际可调配的资源情况去调整，要让产品团队成员的工作量达到完全饱和，以实现整体资源利用的最大化，避免资源的不必要浪费。
比如，上图中产品需求分为客户端和网页两种实现方式，需要客户端开发团队和Web开发团队分别负责开发。由于网页需求需要和客户端需求一起发布，预计Web开发团队会先于客户端开发团队完成所有高优先级产品需求的开发，所以我们将产出投入比并不高的需求J的优先级提高来提前实现，这样Web开发团队就可以在客户端开发完成前开发更多的Web功能。
四、跟踪产品需求进展
产品需求管理是一个持续的动态过程，新的产品需求不断产生，同时一批批产品需求被实现。产品经理要负责对产品需求的进展进行跟踪，并时刻更新它们的状态。
需求状态：产品需求状态指的是产品需求在这一时刻所处的情况。常见的需求状态有：待确定、未开始、开发中、已完成、搁置、取消。“待确定”说明该需求还不够明确，需要产品经理和需求方代表做进一步的沟通确认；“未开始”说明该需求已明确，等待开发中；“开发中”说明该需求正处于开发实施的过程中；“已完成”说明该需求已开发完成，用户已经能够使用这个产品功能了；“搁置”说明该需求因为某种原因被闲置了，暂时不予以考虑安排；“取消”说明该需求已被彻底放弃。
除了需求状态以为外，一些和需求进展相关的重要信息也应该被记录，比如已完成需求的完成时间、搁置需求被搁置的主要原因，等等。