编辑导读：所谓业务思维，即是站在业务方的角度，关注市场格局，行业情况、数据、业务，关注能落地的结果。与C端产品不同，ToB产品面向的是企业级消费者，这就更加要求了B端产品必须要具备业务思维。本文作者从2个方面对此展开了梳理分析，一起来看看~

我们都知道ToB产品是面向企业级消费者，可以理解为为企业提供平台、产品、或服务，支持企业经营，管理，业务运转。一开始ToB系统出现的意义，是提高企业效率和效益，但是现在市面上大部分的ToB产品关注点都在怎么满足不同企业的定制性需求或者怎么多卖几套软件出去，这是做ToB产品时需要着重考虑的问题。

我讲讲我在中小型企业做toB产品时遇到的关于业务方面的经验，希望能带给大家一些启示。

一、满足业务and优化业务

ToB系统可以拆分为一个个模块，而模块是由一个个业务组合而成，在业务的基础上才产生需求。

当你开始规划产品功能的时候，那你必须清楚整个业务流程的运转。不清楚业务的流转就开始进行规划产品功能，只能导致一次又一次的推翻重做。

业务变动频繁不怕，产品拥有迭代更新的能力是最基础的事，公司里都会有专门的人负责某些业务。找到业务人员了解业务，满足业务需求不难，功能上的堆砌就可以，难的是如何精简业务流程，为企业节省开销成本。

• 找到业务的目的：业务目的是整个业务流程存在的意义。只有弄清楚业务的目的，才能更清楚的让我们去认识业务流程，缺了这个流程，业务是不是走不通，目的是不是达不到。这样能避免我们后面的流程梳理出现错误或遗漏。
• 对相关业务人员进行访问：了解业务目的后，联系需求的提出者，明确业务涉及部门，再细化到涉及的业务人员名单，进行一对一调查访问。带上你的笔和纸就行，不要提前准备问题，业务人员天天走业务流程，对该业务的理解程度绝对比你深。让业务人员讲解一下自己在业务当中的每个步骤，从开始到结束路径一定要清晰，量化到目标或任务具体明确,可以清晰度量。这样可以帮助我们了解业务了解的更仔细。向业务人员请教业务当中是否发现有可改进或删除的不必要流程。相信我，业务人员会给你惊喜。
• 优化业务流转路径：如果业务人员提出了流程改进或删除，一一记录下来，业务人员提的建议不一定对。后面自己用改进或删除的流程和原来的流程进行对比，选择最简单、能满足业务目的的流程。将业务流程进行一一组装，看看能不能形成闭环。如果不能形成闭环，查看什么环节出现错误，再找当事人就业务流程重复沟通，对业务流程双方进行意见沟通，达成一致。直到业务流转路径形成良好闭环为止。
• 和业务人员确定业务流程图。整理梳理好的业务流程图，和涉及的相关业务人员进行流程确认，确保业务流程没有出现遗漏或失误，保证业务的真实性和有效性，达成一致后再根据业务流程开发系统功能。

在满足客户的业务需求时，尝试能不能优化业务流程，让业务能以更简单的方式满足业务目的。毕竟，满足业务需求能不能赚钱我们不知道，但是精简业务流程节省人力成本实实在在看得见，这是PM必须发力的一个点。

二、隐藏在需求后面的业务

我曾经接到过公司内部反馈的一个需求：A同事负责追踪沟通A学员，邀约A学员上门了解情况，A学员和她朋友B学员一起来到公司，然后两人都报了名。A同事并没有联系过B学员，在不知道有B学员报名的情况下，问我B学员的绩效该怎么算。

问题出现了，A同事联系了A学员，A学员带来了B学员，B学员的绩效归谁。

一种看法是B学员是A学员带来的，而A学员是A同事沟通后邀约上门的，没有A同事就没有B学员，可以看作是A同事的绩效；另一种看法是A同事没有和B学员进行过任何沟通，别人是主动报的名和A同事无关，不能看作是A同事的绩效。

这个需求我们仔细想想，其实可以分为两类：

1. 系统缺乏绩效评判功能
2. 公司业务流程不规范导致无法落实绩效归属

B学员的绩效归属不是产品经理和产品来决定的，而是公司绩效的相关条则来决定的。成熟的企业之所以能够实施客观性绩效考核，就在于其内部业务流程的规范。这里有可以使用的产品需求吗？

有。我们可以在产品上做一个报名绩效归属选择的功能。具体实现功能我就不讲了，解决的方法多种多样，我们讲的是思维。

当我们拿到需求时，除了思考我们的产品缺失什么功能，也要思考公司业务流程出现的问题。

在我们做ToB产品的时候，产品经理在做产品功能的同时，也要想着向业务流程优化这个方向前进，毕竟大家是做产品经理，不是做功能经理。

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

题图来自Unsplash，基于CC0协议