以需求管理为例，产品经理如何打造自己的需求分析能力

我始终认为产品经理拥有批量化复制自己能力的能力是一种很高级的能力，这篇文章以需求管理为例，讲的是产品经理何如模型化（批量化）自己的需求分析能力，希望产品同学们阅读后有所启发。

文章框架：

1. 需求管理引擎的定义&框架；
2. 管理引擎框架串讲；
3. 关于能力批量化复制能力的一些思考。

一、需求管理引擎的定义&框架

定义：需求管理引擎是一个框架模型，规范了从需求分析到需求逻辑产品化过程中的所有思考路径和思考边界，有利于培养模型化思维。

框架：如下图，需求分析引擎主要分为四个模块：

1. 需求分析；
2. 需求立项；
3. 需求（产品）研发；
4. 归档，下文会串讲这四个模块的主要内容。

二、管理引擎框架串讲

2.1 需求分析

2.1.1  需求分析框架闭环

需求分析框架闭环的意思是我们面对一个新的需求，思考的时候要形成逻辑闭环。这里引用了经典的思考模型——3W模型：what，why，how ，既这个需求是什么，为什么会产生这样的需求，如何将需求转化为产品进行后续的价值分析。

what 层：需求来源&需求分类

what 层主要让我们标记需求的来源和分类，需求的来源又分为两个维度：方式 & 对象。方式维度：用户访谈，竞品分析，数据分析等产品经理通过某种行为而获得的需求。对象维度：用户，产品经理，其他，对象维度指的是需求的提出对象。

需求分类主要分三种：

1. 以前没有过的需求，归类为新增需求；
2. 以前有过的需求再次优化，归类为迭代优化；
3. 以前的需求存在缺陷进行修复，归类为缺陷处理。

why 层：陈述事实，表达感受，说出期望

很多时候用户提出的是他们认为的解决方案，而并不是真实的需求，产品经理进行需求分析的时候一定要多问几次为什么，询问的时候尽量的让用户陈述需求当前的事实，表达内心感受，说出自己的期望。

《乔布斯传》中提到一个细节，如果亨利福特在发明汽车之前去做市场调查，他得到的答案一定是大家想要一辆更快的马车。这里我们不去讨论产品经理要不要去做用户调研，而是回到上个世纪初，模拟一下福特如果进行用户调研会是什么样的场景。

场景一：

福特：你们的需求是什么？

用户：我们想要一辆更快的马车。（表达期望，并没没有陈述事实以及表达感受）

福特：一辆更快的马车会满足你们的需求吗？

用户：是的。

福特：好的，我们会造出世界上最快的马车。

场景二：

福特：你们的需求是什么？

用户：我们想要一辆更快的马车。（表达期望，并没没有陈述事实以及表达感受）

福特：为什么你们希望要一辆更快的马车。（引导用户陈述事实）

用户：因为我们能更快的出行和运输，现在的马车出行和运输都很慢。（表达感受）

福特：所以你们是为了更快的出行和运输吗？ （引导用户说出期望）

用户：是的 （说出期望）

福特：那我们可以创造出比世界上最快的马车还快的东西，你们愿意用吗？ （需求逻辑产品化建模）

用户：当然愿意。

通过以上场景分析，我们在需求分析时，应该以why的形式引导用户说出内心的真实需求，用户的世界里面也许只有马车，但是你也许能为他造出更快的汽车。

How层：需求逻辑产品化建模

在why层我们已经明确的用户的真实需求，接下来需要在思考层面对需求逻辑进行产品化建模，为后续的需求价值判断做准备。

需求建模的方法很简单，在已知的产品模型工厂里筛选合适的产品模型进行建模，产品工厂参考如下图：

产品工厂中列出了不断拓展完善的基础系统和通用体系，在进行需求逻辑产品化建模的时候，最终的产品模型都是由这些基础系统和通用体系组合而成的，只要平时的产品学习进阶过程中有计划的去研习这些基础系统和通用体系的产品设计方法论，就能快速完成需求逻辑产品化建模。

很多产品同学接到新需求的时候往往不知道设计什么样的产品来满足，原因自己产品工厂里面的基本产品模型太少了。阅尽天下A片，心中自然无码。

2.1.2  需求（产品）价值判断

在完成需求逻辑产品化建模后，脑海里大概有了一个可满足需求的产品基本模型。这个阶段已经确定了需求的真实有效性以及有了基本的产品模型，接下来就是对产品模型进行价值评估。

一般的价值评估维度分为两个方面：

1. 用户层面的使用价值；
2. 商业层面的研发价值。

用户层面的使用高价值主要的分析维度有：1.用户规模；2使用频次；3.必要性；4.其他维度。

商业层面的研发价值主要的分析维度有：1.研发资源；2.研发成本；3.研发风险；4.稀缺性；5.其他维度。

一个需求（产品化）的是否有价值，做与不做需要根据用户和商业两个层面的多种维度综合判断。

2.2 需求立项

在进行需求价值判断后，筛选出的需求需要进行需求立项。

需求立项主要分为六个阶段：

1. 需求优先级分配；
2. 需求逻辑产品化；
3. 初审（产品+需求提出者）；
4. 需求逻辑可视化（产品+需求方）；
5. 二审（需求方）
6. 终审 （产品，项目，设计，技术，测试）。

2.2.1 需求优先级分配

需求立项的第一步，确定需求的优先级。一般判断需求优先级的维度有：

1. 按照紧急程度（紧急维度）；
2. 按照价值权重（价值维度）；
3. 资源配置最优（资源维度）；
4. 按照实现难易程度（难易维度）；
5. 按照上级指示（老板维度）；
6. 按照需求产生的时间顺序（时间维度）。

一个需求的优先级判断通常是多种维度综合的判断结果。

2.2.2  需求逻辑产品化

与之前需求分析阶段的需求逻辑产品化建模不同，需求逻辑产品化建模更多是基于思考层面的，而需求逻辑产品化则是强调输出层面的，接到可行性需求后开始输出基本的产品方案，输出物包括但不限于产品蓝图（产品架构图），思维导图，原型图demo等。

这个阶段跟多的输出产品的大的可行的方案的框架，设计理念和产品逻辑闭环等，还没有具体到细节原型和流程图的输出。

2.2.3  初审会（产品+需求方）

需求逻辑产品化后需要开初级评审会，用需求逻辑产品化阶段的输出物向需求方介绍产品大方向的设想，如果评审通过则证明大方向上的可行性，不通过则继续修改复审。

2.2.4  产品逻辑可视化

初审通过后，接下来进行的是产品逻辑可视化。之所以会有初审的原因是，我们设计产品就像修建大楼一样，需求逻辑产品化就是确定大楼地基和蓝图的过程。如果这个过程没有问题，接下来的产品逻辑可视化就像装修添砖加瓦一样，不会有大的问题。反之，如果已经输出了细节的原型图和流程图再去评审，那么一旦评审失败返工将会花费大量的时间。

产品逻辑可视化阶段就是在确保大楼的地基和框架没有问题后，添砖加瓦的过程。这个过程主要的输出物一般是原型图，流程图&PRD文档等。

2.2.5  二审（产品+需求方）

二审是对具体的产品细节和流程细节逻辑进行评审，评审通过后就可以进入开发阶段了。这个过程中如果评审失败，产品经理只需要花很短的时间修改表层逻辑，不需要做框架层面的修改。

2.2.6  终审 （产品，项目，设计，技术，测试）

终审就具体的产品可行性进行评估，确定具体的项目排期计划。需求排期表最为一个基本的里程碑式的交付物，表示需求进入正式的开发阶段。

2.3 需求研发

需求研发阶段主要阶段有：1.设计&开发；2. 测试 ；3.验收；4.发布上线。这个过程中产品经理主要跟进需求的研发进度，以及保证整个过程中的信息对称，以及对一些突发的需求修改给出可行性方案。

2.4 需求归档

需求归档环节主要有两个过程，输出项目复盘报告& 输出迭代计划。

• 项目复盘报告主要是对整个项目进行总结，取得的成绩以及存在的问题和不足。
• 迭代计划，主要针对一些需要二次迭代的需求进行迭代计划输出。

截止到需求归档，标志着一个需求从需求分析到价值校验以及需求逻辑产品化到最后的研发上线归档全生命周期的结束。

三、关于能力批量化复制能力的一些思考

我始终认为产品经理拥有批量化复制自己能力的能力是一种很高级的能力，这篇文章以需求管理为例，讲的是产品经理何如模型化（批量化）自己的需求管理能力。不仅仅是需求管理，产品很多知识都可以模型化，框架化的输出。

衡量一个产品经理是否优秀，如果只有个一个标准的话，我觉得应该是看他是否能快速培养一个和自己同样优秀的产品经理，因为快速意味着你的所有知识输出都是基于方法论层面的模型和框架，就像需求管理引擎一样，掌握了这套管理引擎，所有的需求只需要交给大脑按照标准模式处理，实现真正的规范和高效。

这篇文章不仅希望大家能理解这套需求管理引擎，更希望读者们能培养模型化思维，拥有批量复制自己能力的意识，从而打造适合自己的需求管理引擎。

#专栏作家#

AllenDan