需求

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

产品需求是在描述产品是什么，以此指导研发人员开发产品。如果把需求写成文档，就是产品需求文档。

对互联网产品而言，产品需求文档覆盖流程图、原型图、原型逻辑等内容，这些都是在说明产品是什么。

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

产品需求描述的是产品是什么，用户需求描述的是用户的需要。这种需要通常是主观的、因人而异的，体现了用户期望达到的某个状态。很多内容都可以视为用户需求，比如马斯洛的心理需求、低成本交易需求、用户场景化需求。

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

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

不论是产品经理采集的，还是用户主动提报的，未经分析与整理的需求都是用户需求。用户需求中可能夹杂若干混合诉求，它们可能是痛点描述，也可能是用户提出的解决方案。产品经理通过分析挖掘用户需求，找到痛点，形成软件产品设计方案，从而形成产品需求。

产品需求应该是颗粒度清晰、逻辑严谨完整的产品诉求，作为产品经理提供给研发人员的软件设计方案。

用户需求是对最原生态需求的描述，充满不确定性；产品需求则是分析问题后的解决方案，或者是初步的思路拆解，要具备确定性。

用户需求在处理过程中可能被拆解成多个产品需求，也可能与其他用户需求合并成同一个产品需求。用户需求和产品需求是多对多的关系。产品需求可能会对应多个研发任务和测试任务。

当然，在口头交流中，为了方便，我们往往将用户需求和产品需求混在一起讨论，不会做严格区分。但在正式的需求池管理中，必须对二者进行区分，否则会带来管理和执行上的混乱。

在 B 端产品开发中，需求本身也会存在层次。但马斯洛的模型并不完全适用于 B 端产品设计与需求管理。

因为 B 端产品面向企业或组织，帮助其解决某类经营管理问题。对于客户来讲，需求的本质在于业务管理，无法通过马斯洛模型来定义和描述需求。

此外，B 端产品的关注对象除了管理人员，还有一线用户。而一线用户的需求动机，也无法通过马斯洛模型来解读。

B 端产品的需求来源和场景比较复杂，很难像 C 端产品那样，基于马斯洛模型，从单一维度去做需求洞察。但是，B 端产品仍然可以从几个维度来审视需求的类型和层次。

首先，我们可以从表达深度来划分。

方案级需求，是指用户想要的功能，是从技术实现角度描述的，通常不够可靠。

问题级需求，是指用户想要解决的问题，是站在用户视角、业务视角描述的。通常可以回答：如果没有提供这样的功能，会对当前业务有什么影响？要做好这个层次的需求分析，业务知识和业务理解能力是关键。

有时候，需求还可能涉及更深层次的原因，这可能与需求提出者的动机相关，我们可以称之为人性级需求。对于行业应用系统而言，通常不需要在这个层次上进行分析；但如果是 ToC 产品，则经常需要分析到这个层次。

我们还可以从功能维度，将需求划分为功能性需求和非功能性需求。

功能性需求是产品经理工作的重点，但非功能需求也需要产品经理在设计产品时考虑。

如果把功能性需求和非功能性需求汇总，汇总后的模型可以形成 PURPS+ 模型：

Primary 主要需求：包括功能、内容、安全性。
可用性需求（Usability）：包括用户体验、帮助、培训文档之类的。
可靠性需求（Reliability）：包括故障率、维修时间等等。
性能需求（Performance）：包括响应时间、并发数、吞吐量等等。
可支持性需求（Supportability）：包括可维性需求、可移植性需求等等。
其他次要需求：包括数据分析需求、许可需求、接口需求、包装需求等等。

上述这些需求需要产品经理来处理。有些需求在产品经理提供信息之后，再由研发人员确定；有些需求以研发人员为主、产品经理为辅。但无论是哪种情况，都需要产品经理对上述需求有全面的理解。

最后还可以根据需求的来源和价值，把需求分成业务需求、用户需求、技术需求。

业务需求是自顶向下的需求，往往来自中高层管理人员，或者来自监管部门、政策，基于业务运营管理的直接诉求和要求。

在业务需求分析过程中，往往采用了很多经典的传统软件需求分析设计思路。重点是通过业务诊断分析、抽象建模，也就是领域驱动建模设计思想和流程再造的方式，进行需求分析和设计工作。

所以，业务需求承载了 B 端产品的业务价值，也就是帮助某一业务单元完成业务目标。

但这里我们说的是业务价值，并非商业价值。商业价值往往要上升到企业层面，而 B 端产品在多数情况下是为单一业务部门服务的，承载的更多是业务价值。

用户需求是自下而上的需求，来自一线业务用户和基层管理人员。通常来说，这体现了业务人员对业务规则、流程、系统交互的改进诉求。

我们在梳理 B 端产品的用户需求时，可以借鉴 C 端产品的需求管理方法论，从而实现以用户为中心、关注场景和体验的产品设计理念。

用户需求体现用户价值。在互联网思维下，即便 B 端产品也需要重视用户体验和用户价值，包括功能满意度、操作效率等。尤其是对于工具型、基础服务类产品，解决了一线用户的痛点，就是解决了业务的痛点。所以，用户需求和体验设计就显得更为重要。

最后是技术需求。B 端产品复杂程度高，在建设过程中要考虑，要时刻考虑功能复用的问题，以及与其他系统架构设计和交互问题。技术需求往往不具备明显的业务价值，但是，在软件系统结构的合理性设计上，它具备显著价值。除了让架构合理，还能避免重复开发带来的人力浪费。某些情况下，它也可能具备用户体验价值，比如灵活的视图编辑器可以提高用户的使用满意度。

这里我说一下我对需求的价值类型的理解。

首先是商业价值，如果是商业化售卖产品，产品经理首先要判断的是，需求的商业价值是否符合产品本身的定位和规划？是否遵循产品商业化售卖的战略诉求和竞争要求？如果是对内使用的产品，商业价值是指针对企业自身经营的价值。

然后是业务价值。B 端产品除了承载商业价值，还需要帮助客户、用户在业务上取得成功。这就是 B 端产品的业务价值。B 端产品对企业来讲承担的，提升收入、降低成本、提高效率、保证品质。控制风险的任务，这些都是 B 端产品的业务价值。

其次是用户价值。B 端产品本质上是为了解决业务问题而存在的，但设计过程中也要考虑到终端用户的体验问题，包括是否能够提升一线员工的效率和满意度，这就是产品的用户价值。很多时候赋能用户其实也是在赋能业务，因为提升了用户价值，也就提升了用业务价值。提升整体的使用体验，可以提高员工的工作效率。实际上也提升了企业整体的运作效率，尤其是针对工具型和基础服务型产品。

最后是技术价值。软件产品在构建过程中，自身也存在技术层面的优化点。

无论你用哪种需求分析方式，都必须贯彻业务驱动的思想。换句话说，产品经理必须抛开具体的技术实现，站在用户视角，审视用户想要解决的问题、想要达成的业务目的。

作为产品经理，一定要分析需求背后深层次的原因，而不是马上上手进行功能设计。只有理清了背后的问题，才能做出合理的方案决策，确定优先级，并结合产品规划进行通盘考虑。

B 端产品成功需求分析的前提，永远都是理解业务。如果自身业务知识底子不够扎实，学习再多需求分析技巧也派不上用场。

作为产品经理，不能苛求用户提出合理且严谨的需求。这不是用户的责任和义务，而是应该通过自己的专业能力来完成需求采集工作。