用户在使用产品时就是在使用功能，如搜索功能、下单功能等，这些功能也是功能性需求。但是用户的非功能需求也要满足，如安全性、易用性、可靠性等。这些非功能性需求对功能性需求起支撑性作用，是功能性需求的根基。很多非功能性需求要在早期确认，因为这些需求决定了软硬件的架构，而架构的调整并不容易。所以为了避免返工，产品经理应该咋早期仔细确定。

非功能性需求虽然有很多，但是内容相对固定也比较容易梳理。

一、用户需求和产品需求

对产品经理而言，福特造车的故事是尽人皆知的。福特汽车创始人曾经说：“在汽车出现以前，如果我去问人们需要什么，他们肯定会说需要一匹更快的马。”但福特造了一辆汽车。因为福特知道，用户的需求不是一匹马，而是快速到达目的地。通过这个例子我们发现，用户需求和产品需求本身就是两件事。接下来我们还以造车为例来深入探讨这些需求的差异。

用户说：“我的需求是一辆马车。”但产品经理告诉研发人员：“我们要给用户造一辆汽车，用户的需求是尽快到达目的地。”

用户说：“我的需求是把车加长。”产品经理问：“你为什么要加长？”用户说：“这样显得有气派。”产品经理说：“加长后费用增加很多，我给你配上天窗和真皮座椅，这样显得更有档次，而且价格还不高。我把这个需求告诉研发人员，让他们去造高档次车。”

用户说：“我的需求是买一辆车。”产品经理问：“你为什么要买车？”用户说：“我要每天按时把孩子送到幼儿园。”产品经理说：“你不用买车了，因为接送的距离不远，并且你的预算有限，我们给你提供两轮的电动车就可以了，其接送的时间比汽车还短，而且价格还便宜，我把这个需求告诉研发人员，去造一辆电动车。”

通过上面的案例，我们发现大家都在谈需求，但需求的含义显然是不同的。当一个词被赋予了太多含义时，这个词就容易被用错。因此，我们要用更好的方式来表达不同的“需求”。我们把需求分成两类，一类是产品需求，一类是用户需求，两者的区别如下。

凡是能指导开发的，就是产品需求；凡是不能指导开发的，就是用户需求。

按照这个标准，我们再区分产品需求和用户需求就容易多了。

产品需求：

产品需求在描述产品是什么，这样就能指导研发人员来开发产品。在造车的例子中，属于产品需求的是：造一辆车、造一辆有天窗和真皮座椅的车、造一辆电动车、在出行App里提供接送儿童服务。这些需求都属于产品需求，都是从开发角度看到的问题，告诉研发人员要开发什么。

如果把需求写成文档，就是产品需求文档（Product Requirements Document，PRD）。对互联网产品而言，产品需求文档涵盖流程图、原型图和原型逻辑等内容，这些都在说产品是什么。PRD也被称作“产品描述文档”，该文档要求研发人员按照其内容做开发。

显然，产品需求文档要由产品经理要来写，而不是由用户来写。产品经理要写产品需求文档，就应当挖掘用户需求，而不是挖掘产品需求。

用户需求：

产品需求在具体描述产品是什么，用户需求在描述用户的需要，这个需要通常是主观的和因人而异的，体现了用户期望达到的状态。很多内容都可归为用户需求。我们常说的马斯洛心理需求，低成本交易需求、用户场景化的需求等，都可归为用户需求，下面我们分别说明。

马斯洛心理需求：用户想要一辆豪华车，背后的需求可以是认同感，也可以是获得尊重，这就是用户的心理诉求，属于马斯洛心理需求的范畴，这些心理需求显然是主观的和因人而异的，也体现了用户期望达到的状态。

低成本交易需求：用户要打车回家，此时的用户需求是用更少的时间和成本打到车，出行软件有时可帮助用户达成目标。在大多数情况下，出行软件比路边拦车能更快速地和更省钱地找到车，而更快和省钱是主观的和因人而异的。

用户场景化需求：如果用户着急赶飞机，那么就愿意付出更多成本打车，这就体现了在该场景下用户的特定需求。同样，该需求也符合用户需求的定义。通过以上的例子，我们知道用户需求是复杂的，但只要紧紧把握住用户需求是主观的和因人而异的，就很容易分辨出什么是用户需求。

用户需求体现了用户期望达到的某种状态，用例（用户故事）体现了用户为达到该状态要做的事，产品需求就是要实现用户需求和用例，也就是对产品形态做定义。

用户需求是用户想要的，用例（用户故事）是用户要做的，而产品需求就是帮助用户完成所想，完成所做。

比如，公司同事们要聚餐，背后的需求是促进友谊、进行社交活动，这属于心理需求。为了达成该需求，用户需要在网上预订餐厅，预订餐厅就是一个用例。其具体步骤包括选择餐厅、确认预订等几个步骤，这些也是用例。产品经理在描述完用例后，就要将其转化成产品需求，就要定义功能、流程和界面等。

区分产品需求和用户需求，一方面是为接下来要讲的各种类型的产品需求做铺垫，另一方面，将有利于我们更好地挖掘用户需求。