B端产品经理注意了这七个设计思维请收下

C端重交互,B端重逻辑。看过很多关于C端产品设计的方法论,但对B端产品的设计宝典却少之又少。构思了一个月,增增减减,总结了几条关于B端的产品设计思维,抛砖引玉,欢迎各位朋友一起查漏补缺!

小Q最近在思考一个问题, 工作5到8年以上的高级产品经理和1到3年的初中级产品经理,除了趟了更多的坑以外,在产品设计能力上到底有哪些优势?作为供应链这一类的典型B端产品经理,随着年龄的增长,咱们的沉淀到底体现在哪些方面?如何保持持久的竞争力而不被后生们埋汰?

经过一段时间的观察思考,小Q发现产品技能本身并不是衡量高中级之间的标准,基本上干满3年以上的产品经理们,都具备足够的需求分析技巧和系统设计能力了(如果还不具备,那是不是要考虑一下自己是否适合这个行业了?)。

但随着阅历的增长,高级产品经理们会更加注重积累自己的产品设计思维和知识体系,而这些思维并不是一两个项目就能够快速催生出来的技能,而是需要在无数的经历中不断的提升自我认知,最终找到的一套自己独有的放之四海而皆准的设计法则。

01 业务思维

做B端产品,首先要培养的就是业务感。在做产品设计时,你代表的不是产品经理,也不是技术,而是设想一下自己作为一个真正的需求提出方,你面临到问题是什么,希望系统提供怎样的支持?

如果不能有很好的代入感,不能深刻的理解业务痛点,那么设计出的产品一定会有所遗漏,如同保姆和亲妈带孩子的区别一样,虽然保姆技巧足够,但情感投入相差千里,自然孩子的感受也就相去甚远了。

设计建议

  1. 服务心态。要明白所有的系统都是为业务做支撑的,解决不了业务问题的系统设计的再华丽也只是浮云一片;
  2. 同理心。跳出系统和自己的岗位,站在需求提出方的视觉来充分体会业务痛点,并以此思考解决方案。这样你就能很清楚的知道自己的设计是否实用,是否有遗漏和改进空间。如果你能做到在业务和产品经理双重角色中切换自如,那你就具备极强的业务感了;
  3. 流程和系统的结合。设计系统功能之前,将业务流程从头到尾梳理清楚,充分考虑线上和线下操作的联动,再在流程中需要系统支持的环节中加入系统功能,让线下流程和线上功能完美贴合。流程和系统是相互成就的,系统是为了更好的辅助流程,千万不要本末倒置,让流程来迁就系统。

02 极简思维

刚出校门那会,总以为能够设计出一套比别人复杂的系统就是牛叉,本来一个很简单的功能,一定要锦上添无数的花,每天沉浸在自己制造的复杂的逻辑和交互里无法自拔;也曾经天真的认为那些看起来简单的功能是设计者的失职,直到无数次的锤炼和洗礼以后才慢慢明白,什么是真正的“大道至简”。

无论是系统功能,还是流程上,我们都要尽量追求极简,极简的流程可以极大的减少人工成本,极简的系统操作起来更加流畅更容易上手

但是,极简并不意味着简单,而是要求我们能够分清楚主次,充分提炼,对于重要的功能和流程,一个都不能少,但对于可有可无的功能,能少则少,能系统自动处理的就不要人为操作,能操作一步就不要用两步来实现。

设计建议

  1. B端系统,流程大于交互,首先要思考流程的极简,再考虑如何基于流程来实现系统的简洁;
  2. 交互设计上,可以向C端设计取经:突出页面核心功能区,让用户一眼就明白主次;核心按钮摆放在更加显眼的位置,以突出重点;
  3. 由于B端功能状态和逻辑比较多,可以根据不同的场景和状态展示不同的功能,不要一股脑都罗列出来,形成乱花渐入的局面;
  4. B端功能以成本和效率为首要目标,设计时让系统代替人工,极力减少人为操作和人为判断成本。

03 积木思维

好的产品设计和架构一样,也是符合SOA理念的,理想的B端设计模型是将已有庞大复杂的流程化繁为简,先碎片化为一个个可以独立使用的服务,将这些服务都存放进工具箱里,然后再根据业务场景提取相应的服务,像搭积木一样,重新组装为业务需要的模块,快速适应业务变化。如此可以极大的降低研发成本,这也是目前广为流传的中台化思想。

设计建议

1)很多服务是在业务发展过程中慢慢被提炼出来的,当一个功能能够被多个业务共用时,就可以考虑将其抽象出来,作为一个独立的服务。

比如订单取消,由于客户、客服、库房都可以发起,所以就应该将各个系统的取消逻辑统一为一个取消服务,供各个系统调用。

2)服务的拆分和重组的颗粒度需要根据实际需要来制定,太粗了可复用性不高,太细了又容易增加开发成本。可以将常用的关联性强的功能一起封装打包为标准服务,若业务需要更粗或者更细粒度的服务,再定制化开发。

例如:常规场景下分配发货仓库和占用库存是一体化的服务,可以统一封装为一个分仓服务;若某些情况下只需要占用某仓的库存,则再封装一个库存预占服务,只提供占用库存的功能。

3)积木虽好,但终有其局限性,当一个工程的需求超过了当前所有积木能够组装的范围,强行组装往往会适得其反。同理,服务化和中台化也不是万能的,它们更适用于支持标准化业务场景,当业务的发展超过了当前服务所能覆盖的范畴了,就需要制造新的积木块了。

04 脉络思维

B端产品设计工作中,80%的时间都是在梳理错综复杂的流程和业务逻辑,特别是遇到一个突如其来的大项目时,业务的同事往往不可能考虑的一应俱全,这就需要产品经理协助梳理。

如何将一团乱码的需求化解成一条条清晰明了的可落地执行的需求点呢?这就需要我们具备脉络思维。

脉络思维要求我们像庖丁解牛一样,先找到需求的主骨架,顺着骨架继续拆解四肢、内脏、筋骨,一步一步拆解到最小颗粒度,做到游刃有余。

设计建议

1)先理清主干场景和次要场景。主干场景往往是业务方提出需求的初衷,最需要支持的功能,此类需求优先级一定最高;次要场景一般是搭配主干场景使用的,再没有主干之前,实现了也没有用,所以优先级较低。

2)再基于主干场景扩展出辅助场景和异常场景;辅助场景和异常场景,业务方往往不会考虑太多,需要产品经理在梳理主干和次要场景的过程中进行完善。比如设计采购录取功能,万一提交以后发现录入错误了该如何补救?

3)当一个流程中包含多个功能,涉及到多个角色或者多个操作步骤时,就要考虑充分解耦,分成多个场景需求来处理,千万不要强揉到一起,否则会变得不伦不类。

例如:库房需要增加盘点的审核功能,要求盘点员提交盘点差异数据,由仓储经理审批。

很明显,此需求中涉及到两个操作角色(盘点员和仓储经理),两个操作页面(盘点差异提交和盘点审核),尽管页面差不多,也要分开为两个功能,一个页面是专门为盘点员提供的所有盘点数据,以及提交差异功能,另一个页面是仓储经理查看并操作的盘点差异审核功能,此页面权限只能开放给仓储经理。若两个页面合到一起,万一盘点员不小心操作了审核,后果岂不是很严重?

05 全局思维

全局思维是一种大局观,要求我们站在一个更高更广的视角俯视全局,做到心中有数,不要在单个细节的得失处理中迷失自我了。

设计建议

1)明确方向,目标为王。

做为某个产品的总设计师,产品经理往往充当着船长的角色,在航行过程中,经常会遇到风雨坎坷和烟雨迷雾,这就要求船长能时刻保持清晰的目标感和方向感,分主次、懂取舍,带领船队突破阻碍,到达目的地。

2)大局意识,合纵连横。

设计一个点,要考虑到一个面,由面再及点。在设计单个功能时,要考虑到上下游系统的联通,以及本系统横向模块的影响,不能只考虑到此功能本身。

例如库房新设计了一套借出流程,满足了临时将商品借出库房的需求,但若只考虑到WMS本身改造,就狭隘了,因为涉及库存的变动,一定要考虑到ERP和营销侧系统的联动。

3)以终为始,反向演绎。

项目中经常会遇到倒排期的情况,这就需要我们具备反向演绎能力,根据项目的目标,结合资源、时间等因素综合评估,反向推演出各个里程碑和阶段性目标,并以此做取舍,保证大目标的实现。

4)审时预判,提前规划。

产品经理要懂得审势,根据自己的经验和公司战略,提前做出一些预判和规划,以防事情到跟头了措手不及。

例如年初公司确定OKR,提到今年要从线上业务向线下发展,作为供应链产品经理,就要提前考虑到采购、库存、仓储这些系统是否能支持到线下业务的开展,设计系统时提前做好规划。

5)适时归零,空杯心态。

新环境新业务面前,为了更好的掌握全局,我们要学会适时的归零,多吸收,懂变通。如果没有这种心态,我们可能会变得不思进取,顽固不化,而我们最傲娇的旧经验终会变成自己前进路上最大的绊脚石。

06 回路思维

无论我们设计的现场动线,还是流程,还是系统功能,都要有很清晰的路径,路径包括正向和回路,除了能正向操作达到目标以外,还需要能回转到上一阶段。有来无回的,就是死路。

设计建议

1)设计上要实现自闭环,不要过分的依赖于外部系统和因素。比如应该使用系统自己的内部单号做流转和逻辑处理,并与外部系统做好映射就可以了,而不是直接用外部系统单号来处理逻辑,如此可以避免因外部系统的规则变更而影响系统本身。

2)系统流程上和操作设计上要充分考虑逆向流程和异常流程,而往往这些是最难却最容易被忽视的。

比如:当操作提交到下一步以后,若发现了错误,是否还能返回上一步继续修改?在一个关键节点开启之前,是否有足够的规则校验和容错机制?如果出现了异常情况,流程和系统上该如何应对等。

3)系统新功能上线时,要考虑到新老功能切换的间档期的数据处理和老功能的正常使用,比如正在老功能里运行中的数据该如何处理,历史数据该如何处理,查询报表是否会受影响等。

07 开放思维

业务是进化的,系统也要跟着进化。在一个系统设计之初,需要我们有开放的心态,尽量考虑到未来与内外部业务和平台的协同,打破孤岛效应,让系统联通协作起来,如此才能产生更大的价值。

设计建议

  1. 在以某个需求为出发点的设计时,思考此功能是否可以支持其它业务的发展,若有其它类似的业务发生的可能性,那就可以提前做好预留;
  2. 设计新系统时,思考与其它系统的协同和联通,开放自有数据、服务、接口,让数据自由流转,产生单个系统无法实现的价值;
  3. 实现公司内部业务的功能时,思考未来能否为外部业务赋能。例如履约、采购、库存、仓储、配送能力的开放、系统的开放等。

一、B端产品的价值是什么?

在回答小满CRM的核心价值之前,我想先回答一个问题,B端产品的价值是什么?

B端产品为企业服务,企业为B端产品带来的价值买单,购买原因可能有很多:可能是为了增加销售额(开源)、降低成本(节流)亦或事降低企业法律风险等等。这些原因的最终目标只有一个,即提升企业的利润。

所以B端产品一定要在企业的利润链上产生价值,对企业的利润产生贡献。对最终的利润正向贡献越大,产品的价值也就越大。

这也是为什么能直接帮企业获客的阿里巴巴的会员年费,可以比效果不是很明显的CRM贵很多的原因;这也是为什么阿里、百度(为企业直接提供真实客户流量,对企业利润贡献明显)可以成为巨头,而国内的saas厂商如销售易、纷享销客(企业信息化工具,对企业利润贡献不明显)举步维艰。所以,我们在做B端产品的时候,除了考虑市场环境、公司资源和竞争对手外,一定还要思考两个点:

1.在我们服务企业的利润链上我们的产品是否能产生较大的正向价值?

2.我们如何才能提升正向价值?

如果一个B端产品没有对服务企业利润链产生正向价值或者价值极小,那这款产品肯定会销声匿迹,无论描绘的产品愿景多么宏伟也无法改变毫无价值的本质。

二、小满CRM的核心价值是什么?

回到文章开头提到的,小满CRM的核心价值是什么?

在聚会上,X哥提出这个问题的时候,大家的答案五花八门:“提升客户管理效率、避免客户流失、提升外贸主管团队精细化管理、提升邮件质量等等”。

这当时让我很吃惊,对于CRM的核心价值,产品经理们居然观点全都不一致,那大家如何聚焦发力呢?小满科技高管们可能要思考这个问题,核心价值都不明确的情况下,会导致产品方向混乱,产品核心能力停滞,最终产品核心价值缺失、竞争力不足。

所以小满CRM的核心价值到底是什么呢?

和其他B端产品一样,企业为核心价值买单,那为小满CRM的哪项核心价值买单呢?首先,我们来看在CRM服务的外贸客户中,该产品处在企业利润链的哪个节点。

外贸企业购买小满CRM给外贸业务员使用,外贸业务员对于公司的价值是成交订单,那作为外贸业务员的辅助工具,小满CRM的目标只有一个:提升外贸业务员的成单效率。其他的观点如避免客户流失、提升外贸主管团队精细化管理、提升邮件质量不都是在为提升外贸业务员的成单效率贡献力量吗?

当我在聚会上提出这个观点的时候,大家有两点质疑:

1.质疑一:小满有那么企业和他的客户邮件往来,以及那么多企业经营数据,这些数据不是核心价值吗?我们可以用这些数据做互联网金融、或者让企业的客户也加入进来,成为阿里巴巴这样的平台不是价值更大吗?

对于这个观点,我有2个回答:

  • 即时利用数据做互联网金融或者成为平台价值爆棚,那也不是CRM的核心价值,那最多只能算CRM帮助小满金融类产品或小满巴巴贡献价值;
  • 数据的利用或者连接买家和卖家说起来感觉前途无限好,但要考虑公司的资源、市场环境、竞争对手等等,想法和实现天差地别。

这里我想到了有一款saas产品,叫今目标-企业圈,这款产品理念是:让今目标的300万企业来今目标-企业圈发生连接,企业即可以成为卖家,也可以成为买家。这其实和阿里巴巴直接成为竞争对手,为什么企业采购要来今目标,而不是阿里巴巴?早就过了黄页时期,今目标-企业圈不可能成功。后面我登录看了企业圈的一些商品数据,的确如我所想的那样,冷冷清清凄凄惨惨戚戚。

2.质疑二:“太虚了,效率是最虚的,怎么落地?”。ok,所以下面的第三小节,我会解释如何通过产品功能做到实实在在的效率提升。

三、我们如何通过产品功能实现小满CRM核心价值——提升业务员成单效率?

首先,我们看下图,业务员成单效率的公式:

这个公式可以很粗旷的说明业务员成单效率的因子组成,但因为不同类型的客户其实转化率和客单价都是不同的,我们可以继续优化公式如下图:

再用数学公式整理一下:

所以,如果小满CRM围绕着此公式的因子来布局产品功能,是可以实现产品核心价值的,如下图所示:

那围绕着上面的目标,我们可以定位到功能:

上面只是简单的进行公式拆分来找到关键因子,从而确定产品目标及功能布局。现实情况还要复杂很多,但是按照这种公式化的分析方法可以非常有逻辑的布局功能,最终实现产品核心价值。当然其实我们在做这些产品功能的时候其实并没有想到是否围绕着提升业务员成单效率这个目标,幸运的是逆推公式的时候,发现我们还是很多功能走在正确的路上。

四、那其他B端产品应该如何规划功能?

上面的小满是一个例子,简单的阐述了如何从核心产品价值,总结核心公式,从而确定产品目标及功能布局。很多B端产品的核心价值也是可以由公式组成,我们需要找到这些公式,围绕核心价值来布局功能。那公式如何寻找?这就需要产品经理懂行业、懂业务、懂用户、有逻辑了。

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/3000.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息