在所有的工作中，并没有什么捷径可走，我们所能做的就是老老实实了解业务，摸透业务的本质。

笔者刚转入产品这个坑的时候，就是B端产品的坑，然而B端产品没有太多的经验可以借鉴，只能在行业内摸爬滚打。所以在此劝谏所有的新入行的B端产品新人们，不要想着有什么捷径可以走，老老实实的了解业务，厚着脸皮请教，摸透业务的本质，跟客户打成一片，有可能的话跟随客户进行业务办理一段时间，才有可能做出一款满足B端用户需求的产品。

一、 一款B端产品的实际业务需求

笔者所在的行业是某政府行业，该行业的业务相当复杂，据说某套系统就是几千万。客户的某部门，响应xx号召，需要建立一套大数据监督平台，对所有工作人员的业务办理进行监督业务流程图,数据流程图，规范业务动作。

因此客户提出的总体需求如下：

这套监督系统，不能增加工作人员的工作负担和心理负担，要做到让他们忽略了这套系统的存在。监督的粒度不要太细，也不要太死，只要做到对部门而非个人的监督即可；做到不用实时监督改善，只要可以起到督促作用，每月有改善即可；也不用监督到规定时间完成规范动作的100%，只要超过90%即可。监督的风险点，按照业务办理流程中的问题发生比较严重的8个领域展开，给了我们一个风险描述文档。关注的点是在未来的一段时间内，该部门的该风险情况，是否改善。要紧贴实际的业务办理需求，不要采用监督的方式，去约束工作人员的业务办理方式。二、产品设计的前期阶段，业务调研与需求核实

如上的5点需求，其实是可以形成需求文档，进行产品设计，进行开发。

如果我们真这么干了，这里就会有3个大坑等着埋我们：

客户提供的业务风险点，和实际业务风险大相径庭。与客户交流过程得知的业务流程，与实际的业务流程存在差异，因此造成了对业务数据的理解出现了严重的错误。在与实际业务办理部门交流过程中，新增一些业务部门具体的需求，提起来貌似有道理，然而会打乱执法监督系统的定位。

因此，如果我们在不填埋如上三个坑的基础上，设计出来的大数据监督系统，必然华而不实，甚至很有可能在一开始需要的业务数据都无法获取，也就根本无法做出一个大数据监督系统。

所以在这里，我们面对B端客户的时候，也需要“三省需求”：

产品需求的定位是否紧绕boss给的期望？需求是否真实有效？需求是否具有可行性？

产品的需求是无穷无尽的，怎么为产品的需求划下分界线，笔者看到了一句话，甚好——“必不可少和锦上添花”。

因此笔者秉持着这两个方向，深入基层，跟随业务部门进行一段时间的业务处理，深度体验业务流程，了解了基层业务办理的真实状况，以及业务数据流的流向，并逐一核对前期客户提出的风险监督点，评估风险监督点是否真实有效监督到了业务办理过程中最容易出问题的节点。

最终，笔者凭借对业务的理解、业务部门的多次交流沟通以及客户boss的沟通（在这里沟通没有任何技巧遵循：首先反复沟通；其次是有冲突的一定要多次两边核对协商寻找共赢方法；最后是一定要把自己理解的内容复述给客户从而保证理解的准确性 ），重新修改了风险监督点，并为每一个风险点画出业务流程图和数据流程图（画重点：数据流程图包括数据对象和数据属性），从而确定了最终的1.0版本需要开发的需求。

三、产品设计阶段——1.0版本

进入产品设计阶段了，终于可以踏着欢快的步伐，正常走入产品经理该干的阶段了。然而，产品经理，哪有这么好干的啊，处处有坑，你以为是康庄大道，实际上是，emmmm，暗箭不少。

首先，在产品设计的时候，要确定产品设计的基调。

什么叫基调？

举个例子：比如国家的财政基调是维稳，那么无论是银行也好，财政政策也好都是以维稳为核心，进行货币政策调整以及财政政策调整。

又是如何定基调呢？

产品定基调的方法，首先是要基于boss给的预期，明确核心点是什么；其次是根据boss给的时间点，对每个核心需求进行价值评估（价值评估的方法，参考《B端产品经理的成长之路》），对需求进行排序；最后就是根据开发人员的技术难度对需求进行可行性评估，对排序的需求进行取舍，保证在时间节点前，做出的1.0版本是尽最大可能性满足boss需求的。

笔者结合客户的时间点要求、业务需求、目标需求以及产品的MVP（问度娘）理念，确定了一版产品设计的基调：以异常数量展示为主，辅以趋势分析，结合数据分析的可视化展示方式，进行1.0版本的产品设计；考虑时间成本，页面设计上尽量复用；整个页面布局设计上，简单、大气。

确定了产品的设计基调，笔者就开始了原型图的设计。因为是大数据分析监督平台业务流程图,数据流程图，因此不涉及业务流程的设计。但是有一点很核心的，就是一定要清楚业务数据流，以及数据内容和来源。这在设计数据分析类的产品，有着至关重要的地位。

在进行可视化设计的时候，是有坑的。

（1）从页面颜色搭配上，最好3类颜色即可，颜色太少，页面显得单一，颜色太多，页面显得花哨，反而夺去了数据的焦点

（2）在可视化的数据展示上，千万不要为了追求图表展示而展示（类似：堆积柱状图、面积图、热力图、雷达图、形状图、云词条、气泡图），不同类型的图属性不同，比如仅仅是二维数据的展示，就简单的柱状图就很好。在图表展示上，若数据维度不超过3，最好一种颜色描述，会使得图表的数据化展示上简单、大气。

（3）如果页面上的图标可视化展示较多，建议背景用浅灰色，如果页面上的列表展示较多，建议背景采用渐变，这样会使得产品设计出来层次感很强，而且很容易获取到关键数据信息。

（4）由于主要涉及的是数据化的分线展示，因此一定要把页面的逻辑规划好，比如单位排名列表，可以跳转到某个单位的多维度分析页面；比如某类风险xx条，可以跳转到对应的列表详情；如果逻辑不清楚，开发完成之后，产品都不清楚产品的逻辑。

（5）可视化产品的主体设计逻辑上，一般分为两类：以数据可视化展示为主和以数据结论展示为主。

数据可视化展示为主是从数据推到结论，需要客户自己得出结论。而数据结论展示为主，是从结论推到数据，需要客户根据结论，主动去获取原因（即进入到数据多维度分析展示的页面）。

不过当前的第1.0版本，我采用的是第一类做法，然而在试运行阶段，才突发灵感想到了第二类（第二类，非常清楚了解客户关注的风险的权重，并对风险结论进行归类，计算出不同结论的风险指标，通过指标分析，转化成文字的方式直接展示结论，而不要用数字了）。

四、 产品原型评审阶段

因为是B端产品，因此，产品的原型评审需要两类人：公司内部的人员和客户。

（1）公司内部的人员进行第一版评审，然后进行原型调整迭代，并再次评审，直到通过评审。

公司内部的人员评审，这里就会遇到很多问题：

他们的业务可能没有你精通；每个人的角度不同（开发、设计、测试、技术总监等），看问题也不一致。

仅仅是这两点，就会导致他们对你设计的产品提出很多问题。比如：技术总监就会提出，页面设计有点简单了，功能点不够；开发人员会提出，这个功能点可能过于复杂，无法开发等等问题。

这个时候，我们就需要发挥自己产品经理的本领了，其实客户不仅仅是外部的客户，内部也有客户，所以也需要对他们进行安抚和讲解。

通过几个维度：客户的实际关注点、需求开发的成本周期、技术实现方式、业务实

来源【首席数据官】，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！