业务需求、用户需求和功能需求这三个概念，对于产品新人来说，经常容易混淆，但了解这些是身为产品经理的一个基本功。

问：业务需求对于产品经理来说很重要么？

答：业务真的是很重要。并不是说功能逻辑和交互不够重要，事实上功能逻辑和交互是一个产品的基本功。选对商业模式、快速迭代，才能让一个产品活下去。首先需要保证的是整体的方向和准则不会出问题，这才能保证产品是可用的，细节是在方向和准则的大前提下去根据产品本身去思考的，才能保证产品是易用的。

需求的分类

上面的问题是和朋友聊天提到的问题，但是实际在工作中可能有些小伙伴经常会弄混淆业务需求、用户需求和功能需求这三个概念，那么怎么去区分这三个需求呢？

1. 业务需求 ：通常是基于市场营销部门、业务部门根据自己的业务需求和后续策划的活动方法所整理成的需求文档。
2. 用户需求：描述的是用户的目标，是用户能通过这个产品在什么场景（什么情况下）能完成什么动作（做什么）。
3. 功能需求：是指产品通过需求池筛选内容后，整理成此版本需要迭代的内容，往往功能需求需要配合流程和原型逻辑，让项目团队伙伴有清晰了解。其实业务需求和用户需求也不能完全转换成功能需求。

需求的分类不仅仅包含这三个需求，比如我们在产品规划中依托于公司未来业务发展的方向制定的规划型需求和对于竞品在同阶段所实现的竞品需求，由于此篇文章主要是针对于趋向于业务需求，所以这儿就着重的去看业务需求和附带关联的用户需求、功能需求。

其实在深入的去思考业务需求的具象时，我们去梳理业务需求、用户需求和功能需求三者之间存在的联系，都知道需求最终是为了产品目标服务的，所以我们需要清晰的明确为了解决产品目标，我们应该怎么把控需求？

产品目标与需求之间的关系点

其实我们回过头来看产品设计，目的不仅仅是一个用户体验好的产品，更是一款成功的产品，它包括业务侧和用户侧两方面。基于此，在具体设计的之前要分析一下四个方面，否则容易陷入仅仅是为了设计而设计，却无法解决核心问题的情况。

分析业务需求：我们需要明确业务部门为什么要做这个产品？所期待的产品成果是什么？

分析用户需求：谁来使用这个功能？方便新用户还是老用户？便于拉新还是促活？以及这部分用户为什么要使用这个功能？

明确产品策略：通过将业务需求和用户需求进行匹配，通过一句话来解答就是：通过某种策略给某群用户带来某个价值，来实现某类业务目标需求。

设定数据指标：通过产品实现目标业务价值回溯对应的数据指标是否达成。

分析业务需求

业务部门反馈的业务诉求。产品需要与业务部门讨论进行梳理讨论整理，进而明确变成产品业务需求。可以通过三个点进行分析：

1. 分析业务目的和业务目标；

2. 整理对应的业务流程图；

3. 整理产品的场景和规则。

接下来每个点一步步聊下：

第一步：分析业务目的和业务目标（就是去了解业务需求）

一般情况，业务人员会从自己做业务遇到的“阻碍”，这个“阻碍”可以帮助我们理解业务之间的干系，从中我们可以得到这些信息：

1. 这个需求涉及的业务干系人（用户来源）；

2. 这个需求的关键操作（功能拆分来源）；

3. 这个需求的操作流程（流程来源）。

我们可以总结业务模块的需求池：

有了上面的理解，就大致知道了需求是干嘛的，那实际的业务中，是如何操作的呢？经过了什么样的流程节点呢？

第二步：整理业务流程图

这个阶段需要整理业务流程图草图和梳理规范的业务流程图：

（1）流程图草稿：把理解到的都用流程图的方式表达出来，不分泳道、不纠结流程节点命名、也不用在意这个节点该不该画出来，画出最粗又是最细的流程图。粗是因为不分泳道很多节点也不合理，细是因为把听到的理解的都作为节点画出来。

这时候不要画泳道图，因为对业务还模糊不清，抽象不出合理的泳道，如果一开始就设计泳道图，反而会花费较多时间和精力，但效果并不理想。

举个例子：A同学去超市购买商品的业务场景流程：

（2）细化流程图：通过和业务方不断调研和沟通，这时候可以逐渐的整理泳道图来进行操作流程和用户之间的协同点。

这时候输出的流程必须是泳道划分合理，流程节点粗细适宜，节点命名合乎业务的。但是这时候的流程有一点还是会有欠缺，异常流程和判断节点往往会缺失。后面在实现功能流程会去整理异常情况和判断的节点。

这一节点应该输出：

一是流程图草稿（只给自己最初理解业务用）；

二是业务流程图（用于向其他团队成员讲解和帮助他们理解业务）。

第三步：整理产品场景和规则

有了流程图和状态图，就可以抽象出不同的业务场景。再根据场景逐个细化调研，从而获得业务规则，其中，业务规则细化到每个信息类型和细节处理等等信息，才算真正走到业务点场景中。

（1）抽象场景：抽象场景其实在个人理解中就是模块化的需求，业务方针对场景的描述，产品经理将场景划分各个模块，针对模块制定对应的功能需求点，并将功能需求进行串联（通过流程图）。这阶段需要输出的是业务需求池、业务功能导图和业务规则流程图。

这样做的好处是：场景划分便于理解查看和维护，但又不会落下细节和特殊情况，保证产品设计的完整性。

（2）细化规则：一旦有了场景，并且有了场景下的不同情境，就可以针对各个情境下的业务限制规则进行梳理和调研了。

这一节点应输出：业务场景划分列表、业务细节规则列表，应该注意规则列表是对业务场景的细化和深入。

分析用户需求

用户需求是针对于用户在使用产品时候，结合业务方描述的场景形成梳理，希望用户在场景完成某件事。分析用户需求是从目标形成过程中的重要环节，它包含两部分内容，即：

明确目标用户，洞察用户痛点——如果我们想要去明晰用户诉求，必须结合用户当前所处的场景。场景的藐视是业务诉求中去寻找目标用户和目标用户能为我们带来的价值共同去界定的，更能够帮助站在用户视角，去了解当前场景并去分析目标用户动作。

将用户痛点转化为需求——就像“用户要的是更高效的移动，而不是一匹更快的马”，用户能想到的解决方案都是基于其认知本身，对此，产品需要挖掘需求背后的真正诉求，进而从根源找到解决方案。

举个例子：现在英语类知识付费学习平台案例，整体分析情况如下：

第一步：明确目标用户

第二步：将用户痛点转化为用户需求

第三步：明确产品策略

产品目标一定是以业务为导向，以用户为中心出发的，通过业务诉求和站在用户的角度上去思考的，只有这样，才能提炼产品真正的价值。

在英语学习的场景中，为了更好的将业务需求和用户需求更好的匹配，通过业务用户关联表可以一一进行解决：

通过业务用户关联表可以针对不同人群给予不同的解决方案，进而形成产品策略。确定了产品策略后，还需要根据公司资源投入和预估ROI以及上线时间确认产品需求的优先级，然后进而和项目组确认上线周期，这儿就先不去赘述。

设定衡量产品目标的数据指标

由产品目标可以演绎出的东西不少，其中最直接、最具有指导意义的就是数据指标。数据指标是对目标价值这种抽象概念的数据化表达，它能为所有参与角色形成一个具体的关注焦点，建立一个统一的坐标体系和判断标准，直观的反应方案效果与目标价值之间的差距，成为后续迭代优化的思考源头。所以，设定数据指标是非常重要，也是十分必要的。

比如英语学习平台最后需要收集的数据指标包含：课程参与人数、拉新、留存率、UV、反馈数值（用户完成课程）等。

当然对于产品经理来说，这仅仅是前期去梳理业务需求，针对于“梳理业务→产品模块整理→需求池（功能整理）→梳理版本计划→功能导图→功能流程图→原型设计→PRD文档→产品评审→开发→测试上线→数据分析→产品迭代”，梳理业务是项目生命周期的第一环节，后面每个内容将通过一篇文章来聊聊。

后记：产品经理并不是大家口中的“做不好运营、敲不了代码，就去做产品吧！”希望小伙伴们持之以恒，继续努力。共勉之……

本文由 @john 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议