需求分析是产品经理梳理需求的第一个步骤，需求分析的能力是以识别业务目标为开始的。只有找到正确的业务目标才能确保设计的需求是合理的。

• 业务目标是什么

• 产品设计中业务目标的作用

• 如何识别业务目标

业务目标是什么

业务目标首先是一个结果值，很多时候我们在日常工作中，经常会看到如下场景

业务同学A：我有一个需求希望你能帮我做下，我希望你能帮我过滤下金额不正确的订单，这类订单帮我打个标记

产品同学B（心想：根据我学的课程上说每个需求都需要去确认业务目的）：请问你这个需求业务目标是什么，希望能达成什么样的效果.

业务同学略微思索了下，于是说到:我的目标就是能够不去履约这些金额不正确的订单。因为金额不正确代表他是有问题的，这类订单我处理的时候每次都需要人工操作在去挂起或者取消，非常麻烦了。希望尽快能帮我处理这个。

产品同学B：那我明白了，我复述下你的业务目标，你看我理解的对不。你希望做对订单打标记，标记金额不正确的订单做拦截。业务的目标是处理异常订单，减少人工处理，提高人效。

业务同学A：对对对。是这个意思，需求明白了的话，帮我看看什么时候可以上线。。。。

产品同学B：我回去跟开发商量下，后续给你回复

这是一次简单的需求沟通的场景。看起来一些都是很正常的。产品同学也按要求去整理PRD。 需求内部评审的时候，产品B的领导问了一个问题：“这个需求希望解决什么问题？”

产品同学B：（这个我当时幸亏我问了，赶紧回答）这个业务反馈希望能够解决异常订单的处理，提高人效。

领导听到后微微皱了下眉头，考虑不打击产品B的积极性，于是又问了一个问题：所以你这个需求是要批量处理异常订单吗。那处理后的异常订单怎么办，拦截以后是取消吗还是怎么样呢？

产品同学B有些紧张，于是按着自己的理解回答道：嗯是取消

领导追问道：你确定取消，那么这些单子的收入是不要了吗。业务说的还是你猜的。

产品同学B：我理解是这样了。。。。

问题问道这里基本已经进入死胡同了。领导对于产品同学B的印象是逻辑不清晰，搞不明白目的。

为什么会出现这样的情况呢？其实很简单，这上面这个例子中讲到的业务目标，其实是一个过程值，而不是结果值。解决人效在一些时候确实是可以作为结果的。但是在这个例子中人效只是从对方岗位的角度出发得出来的结论。而没有从业务结果出发思考得到什么样的收益。

按照人效推导会发现目的是拦截异常订单。但是拦截异常订单对于业务上的影响或者希望达成的效果没有阐述清楚，是希望降低业务风险或者坏账订单数量，还是希望修正后保证这部分订单的收益可以正常计入财务结算呢？

业务目标应该是一个从业务结果出发的结论，例子中得出的人效提升其实是业务结果的二级甚至三级结果了。按着这个场景来划分。业务结果有这么几层

1.订单收入是否正常，异常的订单是否能够处理后正常计入。对业务产生增量

2.异常订单处理后如果无法正常计入，是否会产生取消情况，取消情况是否可以快速处理，减少用户投诉的量

3.在处理过程中，考虑到人员成本和效率，是否可以在满足上面两个条件的情况下，提高人效，减少人员操作的时间

对于产品经理业务目标如何看待

大多数情况通过和一线业务的沟通，能够获取到的业务目标都是第三层的内容。因为从执行者的角度来看。他们更关注的是省时省力，这个对他们来说收益最高 。但来到更高层面会发现关注点就会不太一样。比如主管级别的可能关注的是整个环节运行的是否良好，比如是否有投诉，是否解决投诉等。

而若从业务角度来看则需要明白他们这么做的本质是要解决什么问题，能够带来对业务的帮助是什么。

这也是很多产品经理在初入职，甚至工作很多年以后一致没有意识到的一个问题。产品经理和业务的角度和思维方式是有很大差别的。

一般情况下业务人员，无论是一线人员还是运营人员都是线性思维，清单式处理方式。这个怎么理解呢？

大家多观察一下日常的工作中业务表达的方式和内容你就会发现，大多数的业务执行者甚至不少基层管理者，他们都是按照一条或者几条独立的任务线进行安排的。他们的工作内容往往是一个又一个的独立任务，通过完成一个又一个的独立任务得到他们的结果。

比如打单的时候会列出任务的干系人，阻碍，成交意向的内容，这些作为独立的任务由销售人员逐个解决。找不到对方负责人，就重点找线索去打听，遇到有不同意的人影响签单，就会想办法让他同意，成交金额打不成共识就会反复试探达成共识。这些任务处理的时候就像是疏通下水桶一样，确保下水管每一个弯都没有东西堵塞就可以让水流通畅。

这样的思考方式我称之为二维思考方式，主要考虑点线面。

而产品不是这样。产品需要的是三维思考方式，即点线面以外，还要考虑纵向和横向跨度。

在遇到同样的问题时候，产品思维就和业务思维有所差异。他不是线性思维，而是多维度的立体思维。

比如像上面这个图就是产品思维的路径。

产品思维不只考虑如何得到快速推进的路线。而是要考虑多维度推进，比如当调研完成以后，业务思维是一个节点一个节点解决问题。而产品思维是将问题分类，一类问题的节点一起解决，然后再进入下一个节点。所以会同时有多个节点并行前进的情况。

比如在确定业务意向和诉求后，我们需要从业务和系统两个维度去思考产品方案。即要从我们现有的产品架构设计中提高复用性，避免过多的个性化设计增加系统不稳定性和成本。也要从客户业务角度得到业务的痛点和关注的核心链路。确保能够有效的达到业务目标。

我们常说saas服务会是60分及格到80优秀之间。很少有人尝试做100分（当然对外宣称是另一个事情了）。

而为什么能确定是这个分值区间，就是因为我们是三维思考模式去推动进行的。这是一个综合平衡后的结果。

产品思维有点像一个魔方，而把二维思维的业务逻辑放进来，是无法填满魔方的，所以，还需要产品根据逻辑进行推理和补充。这就是为什么产品思维和业务思维不同的地方。如果产品经理仅仅只按业务二维思维进行产品设计，出来的东西就会显得好像能解决问题，但是无法长期稳定持久。

还拿上图的事情举例，如果打单的时候产品经理只是根据调研整理的业务诉求，然后直接根据诉求进行产品方案设计和合同设计。看起来是可以满足业务诉求和招标的要求。但出来的设计往往是高度定制化的，他的情况会变成先有业务想要的诉求设计方案，然后根据这个方案硬套我们现在的产品架构，然后做补丁式开发。即缺哪打个逻辑补丁。这种系统出来几乎不能长期服用或者使用，不是一个好的产品解决方案。

所以我们可以看到业务目标在产品思维下理解是有所不同的。他是蕴含多维度考量的判断。不是单一把业务要的诉求原封不动转述过来了。

下面几个例子可以诠释这个逻辑，大家尝试看看这个业务诉求、目标应该如何去理解和判断。

• 作为行业头部企业，希望接入三方平台开店进行线上销售，产品需要搭建销售能力。产品架构应该有什么？

• 我们的商品同时接入了多个平台，包括美团，京东等。但管理起来难度太大，希望产品系统提供自动化管理能力。业务需要的产品能力都需要哪些？

• 商品的库存是实时变化的，希望提供一套看板来帮助业务管理库存的调整。业务目的是什么，是应该按照业务诉求只提供一套看板吗？

我们总结下刚才讲的内容，业务目标解析是要多维度，包括定量定性，业务产品等。不要仅仅只是翻译业务的表述诉求。

拆解业务目标是一个复杂的工程，大到对业务运营的拆解和分析，小到功能点背后的底层逻辑，我们都可以视为对业务目标的拆解。

我以一个例子帮大家做下分析和解读如何使用这个公式。

• 我们的商品同时接入了多个平台，包括美团，京东等。但管理起来难度太大，希望产品系统提供自动化管理能力。业务需要的产品能力都需要哪些？

在解读这个问题的业务目标，我们要从逻辑推导过程来阐述目标是否对题，而不仅仅是从业务描述的诉求来入手。很多时候业务描述的诉求是带有主观性的。

下面是模拟的调研问答场景

业务A：我希望能够自动化管理商品，目前多平台的管理实在是在麻烦了，效率特别低。

产品B：那我先确认下自动化管理都有哪些场景呢？或者说你们现在都做哪些运营动作进行管理呢？

业务A：比如我们平时的上下架，商品信息修改，一些店铺的资质修改，包括价格、库存变化的更新

产品B：那我整理下，场景包括：商品上下架、商品价格修改、商品库存更新、店铺资质修改，对吗

业务A：是的，主要就是这些场景

获得了调研的基本信息后，首先分析业务动机，即为什么要做这个，这个是最容易调研到的，可以以业务描述的内容作为切入点，我们提炼出来两个动机：

1. 商品管理接入多平台

2. 提供自动化能力

从上面分析的内容可以看出，业务希望达成的效果是自动化管理商品接入平台。这个是最终的目标，但是我们再实际落地的时候要判断是否需要进行阶段性拆解

很多时候我们不能做到一次性达到业务的要求目标。那就需要制定阶段性目标。

根据业务效果或者阶段性业务效果，我们来通过调研和分析获得业务行为动作。

这样通过沟通和基本的分析，我们可以拿到如上的业务动作清单，大家可以使用穷举的方式，不用担心不完整，业务表述时往往是按照优先级进行的，所以我们优先涵盖重要的场景，其他的可能在后续发现了在持续添加。

目前已经梳理的场景包括

1. 商品上架

2. 商品下架

3. 商品库存更新

4. 商品价格修改

5. 店铺资质更新

从上面的描述我们提炼出两个点的诉求。我们来看下着两个点的诉求分别应该如何理解指标。

提供管理能力，提供多平台管理能力，从结果指标来看要到达管理的诉求关注的是平台接入的稳定性，时效性，准确性。

稳定性的指标主要是技术指标，这个我们不在这里详细讨论了。

时效性代表的是同步的时效，即发生运营变化后的更新及时性。这里面就需要确认更新场景作为业务行为，这个一会我们再梳理。继续看下下个指标

准确性，由于涉及多个平台的交互，在系统交互原则上来看，系统交互方越多，越难保持准确，一致。所以数据在单位时间内的一致性是结果指标。

根据对业务侧的调研分析，我们可以梳理出来我们真实获得的需求是什么？

1.自动更新，包括上下架、商品变化更新。价格修改等

2.监控更新情况，做预警。

最后，一句话总结：实现一个业务效果的功能，可以支持业务行为，满足结果指标/过程指标。