产品设计:B端产品如何应对个性化需求?

3 评论 13817 浏览 82 收藏 11 分钟

编辑导读:不同于C端客户的普适性,B端产品面对的是有着不同需求和不同行业的用户。所以,在产品的设计上,如何能以灵活的方式在同一个应用体系上满足不同客户的个性化需求,是B端产品经理的必修课。本文作者分享了B端产品个性化需求的设计思路,供大家一同参考和学习。

B端产品大致分为四个阶段:

  • 第一阶段基础产品完善期,这个阶段需要满足核心场景的需求。这个阶段要不断增加功能、稳定系统、完善服务;
  • 第二阶段行业产品深入期,这一阶段需要满足重点行业的个性化需求,要有更深度的行业解决方案,更多的客户成功案例,更完善的客户服务体系;
  • 第三阶段生态建设期,这个阶段要满足大多数的个性化需求,要有个性化定制,开放平台和开放的服务生态。
  • 最后一个阶段属于再创新,让产品迈向更高阶段,探索新的卖点,挖掘用户的痛点,寻找市场的空白点。

B端产品必然会有个性化需求,尤其是在第二阶段和第三阶段。

个性化需求就是对于大部分用户而言,非通用的需求,属于偏定制化的需求;面对个性化需求的时候,切记不要抱着抗拒的心理,如果抱着抗拒的心理,很多时候无论对方说什么,你都会认为这是不合理的,很容易被这种心态遮蔽了眼睛。

其实很多个性化需求对于提出的业务方而言,都是有真实需要的,我们需要用心地去分析需求,尽可能找出个性化需求的核心点,将个性化需求变成一个具有共性的个性化需求,从而帮大家解决问题。

01 如何决策个性化需求是否应该实现满足呢?

针对一些B端软件最直接的就是通过 ROI(投资回报率)去评估,通俗点说就是完成需求直接带来的利润率越高越应该优先做。这样的做法特别适合传统的B端软件,传统B端软件大部分都是一锤子买卖,个性化需求带来的收入如果不能覆盖成本大概率是不会做的。

SaaS产品很难通过单一客户的收入覆盖个性化开发的成本,不太适合用 ROI 评估,可以通过下面4个维度去进行评估。

  1. 深度:个性化需求对于目标用户群体而言,是否为痛点,而且要看这个痛点到底有多痛;
  2. 广度:主要是看覆盖面,除了看深度,还要看功能做出来了,可以帮多少用户解决问题;
  3. 战略意义:有些个性化需求,深度和广度都不是好,但是对于公司战略和品牌会有帮助,这种就需要去做;
  4. 技术评估:除了上三点外,还需要考虑一下技术层面,是否现有技术可以实现,难度是否非常的高。

核心宗旨就是需求是否能提升产品卖点,解决用户痛点,属于市场空白点。在产品初期,把拳头产品打造得足够好,远远好过对次要功能进行扩展。

举例说明,

案例一,最早做考勤类SaaS产品时收到学校用户的一个个性化需求,学校教职工使用app进行上下班打卡,希望只记录教职工的出勤,不显示迟到和早退。这个需求是相对个性化的,这个需求我们也曾咨询其他用户,考虑到场景通用性不是很高,并且缺少此功能不会影响成员日常推广营销,教育用户也并不是我们主要用户群体,所以最后没有实现此需求。

案例二,做了一款OA产品给客户使用,主要包含几个固定的审批流程,客户提出了可以随时调整审批流程和表单模板。 考虑到不同行业、不同客户审批流程肯定是不一样的,随着使用的客户越来越多,这种需求必然成为一个共性需求。虽然这个需求实现成本相对比较高,这个需求最终我们实现了。如图所示,表单控件和审批流程都改成了可配置项。

针对个性化需求实现的先后顺序,可以通过对深度、广度、战略意义、技术评估综合打分,根据分值高低得出。例:

02 B端产品需要保证一定的灵活度,用来支持不同公司的不同需求

灵活度主要指的是产品支持角色、界面、权限、功能模块等方面的自由配置。配置包括俩个大类:

  1. 由产品供应商配置,从系统层面进行配置,适用于业务流程与现有方案差别大;
  2. 由客户自己配置,从功能层面进行配置,适用于业务流程与现有方案差别小。

在进行产品设计的时候,要规划好什么样的配置功能是开放给客户的,什么样的配置功能是供应商自己用的,原则上为了避免客户的复杂度,尽量开放最小范围的配置功能给到客户自己使用。

一般来说产品供应商对于客户功能的配置主要包含如下:

  1. 不同客户功能模块不一样。基于不同的收费方式,有些功能需要额外收费,可以根据不同的客户购买情况灵活配置;需要产品模块尽可能的高内聚,低耦合。如图所示,某HRM产品支持按模块开通。
  2. 不同客户同一个功能看到的内容和使用体验不一样,这个配置可能包含界面布局,字段是否显示,页面风格,导入导出的模板等等。为了节省实施的工作量,可以考虑设置一个或者多个基库版本,实施在基库的基础上面进行简单调整就可以。产品的一个核心指标就是低成本交付,将实施的工作量降到最小,最佳的方式的不需要实施。通过工具升级,实现人才降级,没有标准切记不要复制推广。

基于公司的产品配置一般都是供应商公司来实施配置,还有一部分配置的功能是开放给客户自己进行配置的,这部分配置一般来是客户数据级别的需要配置的内容,包括如下。

  1. 角色,角色权限,这个部分如果业务可以将角色标准化固化下来尽量标准化下来,如果不能,就需要允许进行配置。例如项目管理软件禅道就可以设置不同角色和角色权限。
  2. 用户对应角色,用户数据权限,企业里的用户是不固定,软件的管理员是可以转让、变更的,这块一般是用户必须可以配置的。
  3. 一些跟客户业务相关的数据字典,这个部分的配置一般由实施人员在上线的时候帮助客户初始化配置完成,以后如果万一有调整的时候,可以由客户自行配置或者寻求产品供应商支持。

03 个性化配置要把握灵活度

我经常会问一些从业者,你的客户是谁。如果你的客户范围很大,你的产品很可能很平庸。

如果产品非常灵活,一切可以配置、个性化,会大大牺牲易用性。当你产品非常灵活,可以兼容不同的客户的时候,意味着你功能很难做到贴身,极大的配置灵活度是牺牲了所有用户的易用性。这就是一些针对垂直行业,比较窄特定用户群体的产品有市场空间的原因,因为它可以做得非常贴身。选择的赛道不够细分,也很容易被巨头用免费产品挤出了市场。

灵活性过高会让开发成本直线上升,做过开发的人都明白程序写死是最简单的,同时也是最难维护的,为了保持灵活性就必须付出几倍的开发成本和测试成本。把握产品灵活的程度是B端产品设计的最高技巧之一,只有综合业务发展,产品发展,技术实现以及扩展,团队情况的多个因素来能来找到相对最佳路径。

最后

总结一下, B端产品个性化需求一定是存在的,最终的目标是实现标准化和低成本交付,产品经理需要掌握好方向和把握好灵活度。

一点经验分享给大家,欢迎沟通交流。

 

作者:老于;公众号:老于的笔记

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

题图来自 Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 最后一段个性化写得蛮好,事实上,这对于SAAS来讲,是很重要的。

    来自浙江 回复
  2. 写的很有条理,文笔很舒服。对于产品灵活度的把握还真是一项功夫。不过在说案例一考勤APP的时候,只描述了考虑需求的广度,没有首先考虑深度,我觉得是不是先做一下需求挖掘更好,当用户提出非常规需求的时候问问为什么往往有意外收获。从“客户不太适宜的个性化需求”里挖掘出通用需求也是一个角度

    来自北京 回复
  3. 关于表单控件,其实在APP端,像是否这种可以直接显示出来的,不需要别的交互

    来自湖北 回复