B端产品经理,你会做需求分析吗?

营销管理
陈文中小站
 1.07w
2019-10-08

随着云计算、AI、教育、智能制造和产业互联网的兴起,这些新技术、新方案首先从B端企业开始渗透,因此市场上对B端产品经理的岗位需求大增。

但目前行业内对产品需求的方法论,大部分是针对C端产品的,所以本篇文章的主题来谈谈如何对B端产品进行需求分析和设计。

既然要谈“B端产品”的需求分析,那么首先我们要搞清楚一个问题,B端产品和C端产品在产品设计的本质差异性在哪里?

C端产品设计的逻辑在于“轻流程、重体验”,以抖音这种短视频工具为例,只有2个简单的流程:发布视频和观看视频。并且把观看视频的流程简化到了极致—没有流程,在强大的推荐算法机制下,用户无需思考要观看什么,只需要向下滑屏,就可以实现不中断的沉浸式观看体验。

所以C端产品侧重的是用户的感受和体验,在产品设计时,精心对页面和交互进行打磨,大到优化版面结构,小到改变一个按钮的大小、颜色及位置,都可能会极大影响用户的行为,对产品的运营数据产生深刻的影响。

而B端产品呢? 其产品设计的逻辑是“重流程规则、轻体验”,一个母婴电商公司的老板,购买一套电商ERP系统的目的是什么呢?

是让员工操作的体验更舒服、更放松?一定不是!

他在意的是怎么把手忙脚乱、错误百出的客服从20个人降到2个人,从而降低紧张的资金压力;他在意的是怎么把拣货流流程由人拿着单子满仓库跑,改为流水线式自动化作业,从而降低出错率;他在意的是把财务从每个月末抱着一堆单据通宵做账解脱出来,改为系统自动对账,从而让企业的财务数据清晰、透明,为经营决策提供准确、可信的依据。

所以,B端产品最终的目的是通过互联网IT技术对企业业务流程进行重构、优化、从而降低成本、提高效率。

从上面可以看出,C端产品经理像是一个感性的匠人,在产品设计时,带入同理心、想象力、简化用户心智,在产品设计时精心打磨用户感受和体验。

而B端产品经理更像是一个理性而严谨的“业务专家”,他们具备强大的系统性逻辑思维,富有理性的对企业业务进行全面梳理和诊断,并给出合理有效的解决方案。

由于B端产品业务流程复杂、功能庞大、用户角色众多,所以对B端产品经理的需求分析能力,提出了很高的要求。

但我在实际工作中发现,目前互联网公司对复杂B端产品具有完整驾驭能力的并不多见,甚至包括工作5年10年以上的产品经理,输出的产品规划文档,常常给人以“只见树木,不见森林”的印象。

真正具有复杂B端产品需求分析能力的是资深的程序员、架构师、但他们写出来的东西、技术术语过多、复杂、晦涩难懂。

既然B端产品业务流程复杂、功能庞大、用户角色众多,那么它一定是一个“系统性的工作”,必然得有一套“系统性的方法论”来去支撑B端产品的业务需求分析。

以肯尼迪发起的“阿波罗”登月工程为例,耗资数百亿美金,历时11年,动员了整个的国家力量。这种“系统性的工程”,你不能上来就讨论登月舱结构,火箭推力设计的细节问题。

你得有“工程性思想”去支撑,把问题分解3大步骤,1“双子座计划”,2.绕月 3.登月 ,再层层分解,逐步细化,论证,才有可能完成这种系统性任务。

那么B端产品需求分析和设计,有哪些“系统性思想”来支撑呢?


一、确保理解背景


这是很多新手产品会犯的一个致命错误。例如和客户交流完后,客户需要一个ERP产品,结果发现,客户需要的只是一个订单打印小工具。

所以客户眼中的"ERP",一定不是你眼中的"ERP"。

任何一个B端产品和解决方案,一定是在某个特定的阶段满足企业的某种价值,这种价值可以很小,也可以放的很大,这是一种平衡和取舍,所以产品经理一定要搞清楚这个产品需求产生的背景是什么?

你的客户目前是什么现状?组织的复杂度?使用你的产品是为了解决什么问题?是业务转型的问题,还是流程改革和优化的问题?

另外从某种程度上来讲,企业经营也是管理者个人意志的体现,boss对产品或解决方案的诉求是为了达成什么样的目的?你确保了你理解他的诉求?

对背景的理解和解读,一定是你产品文档的开篇部分。


二、搞清经营模式


在理解背景的基础上,我们需要搞清楚企业的经营模式,经营模式决定了产品分析和设计的框架。

很多产品没有把业务理解清楚的根本点在于,没有充分理解企业的经营模式,经营模式理解不清楚,会出现严重的系统设计偏差。

特别是一些复杂的平台级产品,例如钢铁B2B交易平台,涉及到行业生态上下游厂商、大大小小的贸易商、终端客户、仓储公司、物流公司、金融企业等众多的参与方,每个参与方又有不同的职能部门需要在平台作业。

很难想象没有搞清楚经营模式,产品需求分析和设计如何进行。

但搞清楚经营模式,也不是非常困难。任何再复杂的业态,一定有一条主干经营流程,这条主干流程简单的来说,就是以下几个问题?

卖什么?怎么卖?挣什么钱?

买什么:这个企业经营什么产品或服务?有多少种?差异性在哪里?...

怎么卖:产品或服务的销售流程是什么样的?是通过互联网,还是通过线下渠道?如果是,这些渠道怎么管理?当前存在哪些问题....

挣什么钱:企业是如何盈利的?是靠销售产品或服务吗?还是羊毛出在猪身上,狗来买单?...

一旦你把这条主线梳理清楚,就可以清晰的知道企业的经营模型,有哪些供应商、客户、合作伙伴等各种参与方,为接下来的需求分析,打下坚实的基础。

经营模式可以用一张图表来说明,它是你产品设计的蓝图。通常需要用不同的线条把信息流、物流、资金流标识清楚,来搞清楚企业是如何运作的。

下图说明了一个家电售后平台的经营模式运作图。


三、析出业务角色


到这里,才真正从商业分析部分进入到产品分析和设计部分。

如何把需求从商业概念转化为产品分析和设计概念,我目前看到最具有系统性的是UML,其设计思想,贯穿了从需求分析到系统设计的整个过程。

但UML本身是软件工程的产物,概念繁多:图、依赖、泛化等各种概念。本身太过于庞大、复杂、笨重,并且难以学习。

不过其“系统性工程”思想可以值得我们借鉴学习。

为什么,产品分析和设计的第一步是分析出业务角色?而不是画流程图(这是很多人的做法)

因为业务角色是产品需求的源头,所有的产品需求一定来自于全部业务角色需求的集合,B端产品的复杂度决定了必须从业务角色分析着手,才不会出现遗漏和偏差。

并且B端产品越复杂、业务参与方越多、你会发现这种分析越有价值。

在上一步搞清楚经营模式的基础上,会会对该经营模式涉及到的所有业务角色有了个完整的了解,接下来的工作,就是把业务角色分离出来。

下图说明了一个B2B平台的业务角色图。


四、推导出业务用例


有了业务角色后,我们可以推导出业务用例(也即业务角色需求)。

UML的业务用例图,最大的好处是用一张图可以把整个系统的需求以全局的方式,生动、完整、清晰的表达出来。

有了这种图,我们可以很方便的和业务、开发、测试方便的去沟通需求,对系统需求有个整体的认识。

推导出业务用例的过程,我们可以通过以核心业务角色为重点,交叉验证思维来快速构建整个业务用例。

例如下图的B2B交易平台,我们只需要以该平台最重要的业务角色采购商为切入点,再来交叉验证:采购商需要采购下单,必然需要供应商发布商品、供应商发布商品必然需要平台监管人员去审核和管理...,这样基本可以搞清楚各种业务角色80%的需求。


五、细化出业务流程


再接下来,我们需要把重要的业务需求,细化为业务流程。

业务流程可以用UML的活动图来展示,在to B复杂的业务场景中,我们往往使用的是跨泳道流程图,例如一个取消订单的业务流程,涉及到ERP、客服、财务不同的业务角色。

这样在构建业务流程的过程中,我们对系统设计如何实现,也有了一个完整的概念。

另外,业务流程图的最最要的一个原则是线条不能交叉,无论流程如何复杂,保证线条不要交叉,很多新手犯的错误,就是把流程图画的纵横交织像一个蜘蛛网,非常难以看懂。


六、绘制可视化页面原型


至此,我们通过对业务角色分析、不同角色的业务需求分析,核心业务需求的业务流程确认,我们实现了从商业概念到业务概念的建立。

接下来,我们需要把上述业务需求转化为产品系统的设计,这是一个更加细致的工作,我们最熟悉的Axure工具就正式上场了。

当然从“抽象的业务需求”到“具象的系统需求”,也存在一个巨大的鸿沟,这个需要参考同类产品的设计思想,从中吸取精华,并结合互联网设计,做一定程度的创新。

例如,采购商反馈说,通过购物车下单太麻烦了,需要一个“批量下单”功能,你单凭想象是难理解这个需求的。

最好的办法是到用户的工作现场,观察和感受下他平时工作是如何处理订单的。

等你到了现场,你会发现和2C用户的下单场景截然不同:用户的桌面是堆积如山的文档、忙碌的电话接入,长达几页的订单要等待录入...

你会发现B端产品设计的首要目的是快速、准确、无误的帮助用户提高工作效率,节约用户的时间,其他都是耍流氓。

所以你需要去大量观摩和学习一些B端成熟软件的设计逻辑,再结合一些移动端的特性,例如GPS定位、拍照识别、语音,去构思一些创新的设计,可以帮助用户大大提高工作效率。


七、其他补充


产品设计过程中,非常重要的一点是,明确业务规则。

在一个项目团队中,由于背景、工作经验、领悟能力各不相同,如果业务规则不明确,同一个概念,每个人的理解不同,会造成鸡同鸭讲,争执不下,浪费大量时间。

所以一些核心、重点、复杂的业务规则,产品经理需要举出详实的例子来,把各种情况一一枚举出来,并进行阐述。

例如在互联网交易平台,涉及到商品、SPU、SKU这3个概念,产品经理可能对这些概念很熟,但业务方、开发人员不一定对这些概念很清楚。

如果在页面上只是简单的描述为“点击此按钮,将此SKU加入购物车”,会引发大量的困惑和争议,我看到过一个产品经理的需求会,为此争执和讨论了半个小时。

理想的做法,把这些重要的概念和规则,用数据实例呈现出来,并指出他们之间的结构关系,这样在讲解业务时,确保所有人的理解是一致的。

再例如互联网交易平台的交易流程,包括各种正向流程、逆向退换货流程所有的单据状态,这些单据状态互相交叉,互相影响。他们是系统设计的骨架和脉络,如果不定义清楚他们之间的互动关系,会造成严重的混乱和缺陷。


总结


整体上来说,分为三个过程,商业分析—业务分析—系统设计。

商业分析:1.确保理解背景 2.搞清经营模式

业务分析:3.析出业务角色 4.推导出业务用例 5.细化业务流程

系统设计:6.绘制页面原型 7.明确业务规则

参与讨论