好的平台化产品应该像一款乐高

好的平台化产品应该像一款乐高

编辑导语：本文作者围绕刚刚完成的一款营销业务中台产品，从平台化产品的设计要点，以及To B产品中小微企业与大型企业的区别这两个方面，对平台化产品进行了分析，一起来看一下吧。

在过去的2个月里，笔者和团队小伙伴们一起完成了2件事：从0-1搭建了一款营销业务中台产品，同时也完成了该中台产品的一次升级。

这个从0-1的过程让我很兴奋，也让我积累了非常多的写作素材，甚至在第一次写这篇文章的初稿时，写了4000多字都感觉还有一堆想说的没有写进去。

所以，今天核心围绕这款营销业务中台产品，想来和大家先分享其中一个感触最深的主题：平台化产品。

为什么会突然把话题引入到平台化产品呢？

这是因为自己所面对的客户规模发生了巨大的变化。

以前笔者所负责的产品核心面向小微企业，而现在却以大型企业为主，二者在组织人事、业务流程、付费能力&意愿上等有着巨大的区别。

而这些区别逐渐倒逼产品由单一纵深的业务场景逐渐转向注重平台化、高度复用化的方向，倒逼自己也需要尽快开始调整以往的产品设计理念和思路。

因此，本文想站在一个刚刚入行平台化产品2个月、曾经从事小微SaaS产品2年半的产品视角，和大家分享自己对平台化产品的一些体会，因入门时间有限，故以分享为主，如有不对，欢迎大家指正与探讨。

本文将分为以下2个部分：

1. To B产品中，小微与大型企业的3大区别
2. 平台化产品的3个设计要点

enjoy～

01 To B产品中，小微与大型企业的3大区别

虽然早在进入To B行业之前就了解过大型企业在组织人事、业务流程等各方面与小微企业的差异，但只有亲身经历之后，才能真正感受到其巨大的区别。

区别一：组织/流程/角色差异巨大

以前做教培SaaS，一个培训机构最多就十几或者几十个员工，部门也很简单，除了老师比较多之外，其他人员如前台、财务、教务基本属于一个部门一个人，甚至大部分情况下，这些角色多是身兼数职，一个人干着2、3个人的活。

在这种组织架构之下，基本不需要什么复杂的流程，甚至像报名订单的提交、审核、收款一个人就操作完了。

总而言之，小微企业在组织/流程/角色上的特点是：组织架构简单、员工身兼数职、流程简单但也有比较混乱。

而大型企业则截然不同。

大公司大多是专人专职、分工明确，这就保证了整个工作流程相对明确，但角色多、链路长，跨部门配合极多。

例如，大公司的运营人员要创建一个营销活动，他会经历以下5个步骤：

1. 在线下做好完整的活动方案规划
2. 交予领导汇报沟通
3. 沟通通过后，在线上营销系统进行对应的活动创建
4. 创建成功后，需要交由领导和财务等进行层层审批
5. 审批通过后，再考虑推至C端使用

如果是小微企业，可能一个运营人员和老板面对面沟通好了之后，就直接在后台操作并进行活动上架了，几个小时就能搞定；但大公司里，这个流程一走可能就是几天甚至几周，没错，流程复杂且冗长，但也有效降低了出错的风险，保证营销活动不会出现大面积的灾难。

因此，从上述的例子可以看出，小公司在做事上更「快」，而大公司则相对更侧重于「准」；再投射到我们所提供的To B产品上来看，就会在诉求上有非常大的区别。

区别2：小公司需要契合度80分的产品，大公司却需要99分

在两段工作经历中所面向的客户对比之下，小公司往往在契合度达到80%左右就会产生一定的付费意愿，采购者核心看重整个产品中自己最需要的那部分能力（而不是全部）。

因为对于小公司而言，生存下来才是王道。通过软件或者系统来改善和提升自身盈利是一件锦上添花的事情，那在这样的诉求之下，性价比就变得很重要。毕竟如果真的要花几十几百万去买一款完全符合自身诉求的产品，首先，产品也很难带来量变的价值，其次，公司的盈利都不一定能够这笔开销，甚至没准产品还没摸透，公司都垮了。

而大公司则可以用财大气粗来形容了。只要开了标就意味着已经划好了一定的预算区间，那么他们在采购To B产品时，则会以一个甲方的角度来看待产品，更多关注在明确的预算之下，哪一家公司能够更高的契合自身业务。

除此之外，小公司就像一条小船，可以轻松地调整方向，即通过灵活的业务调整去适应系统；而大公司因为角色众多、利益链复杂，就像一艘难以轻松掉头的巨艇，很难做到为了一款外部的产品而去改变自身的流程。

这也就造成了两者对于To B产品诉求的巨大差异。

区别3：小公司付费能力弱、替换成本低，而大公司截然相反

前面是从企业、产品的角度来进行对比，现在我们从商业的角度来看待不同规模的公司。

小公司生存至上，因此在付费能力和意愿上较弱，但也因为数据量小、组织轻量化等原因，产品替换成本也相对较低，容易接受新产品；而大公司虽然付费能力强，但替换成本极高，因此对于采购更为谨慎，但好处是一旦采购，至少几年内都是较为稳定的合作关系。

从上面的对比我们可以看出，2者在付费能力、替换成本等方面都有很大的区别。在这种情况下，同一行业内的To B产品对待不同规模的公司市场在打法上、产品定位上也会产生很大的不同。

小公司往往是一种长尾流量式的打法，付费能力虽弱但数量多、更新换代的频率高，因此走的是量，更看重市场占有率；而大公司则是一种抓重点抓关键的打法，大客户客单价高、替换成本高，一旦搭上线，那就是稳定且大额的长期收入，走的是质。

（马太效应下，大企业和小微企业占据大头）

通过上述的3处对比，大家是否能够清晰的感觉出2类客户之间巨大的差异呢？当然，这巨大的差异也在倒逼笔者尽快调整自己的产品设计思路，从单一的业务纵深方向逐渐跳出来，从更为平台化和高度复用化的角度去打磨自己当前所负责的产品。

那么，第二部分就来和大家分享下在这短暂的2个月中，自己体会到的3个平台化产品设计要点。

02 平台化产品的3个设计要点

前面主要在进行2大客户类型的对比，现在我们把其中对于大客户的特点抽离出来单独看看：组织上——流程复杂、专人专职、角色众多；产品上——需要99分业务契合度的产品；商业上——付费能力强、替换成本高。

从组织和产品上来看，面向大客户的To B产品势必难逃「复杂」和「定制」二字。面对每家大型客户都需要99分业务契合度的诉求，难道产品都要挨个定制吗？这当然是不现实的。

因此，产品除了要提炼出核心标品之外，还要逐渐打造出平台化的能力。那么，将产品逐渐平台化需要考虑哪些要点呢？鉴于笔者目前有限的经验，可能很难整理地非常全面，但希望以下列出的思路能够给予你一些帮助和启发。

思路一：高内聚低耦合

高内聚低耦合是一个刚入行时就耳朵听到起茧的口号，但真正能否做到、做到什么程度却是需要持续去思考和精进的。

用一个具体的例子来一起感受下：当我们在管理优惠券的时候，为了保证优惠券使用时对于成本的把控，需要将一部分库存专门拿给A活动进行使用。那么问题来了，如何保证这批库存和A活动的关系呢？

这里给出3种方式，你会pick哪一种？

1）运营人员创建时，手动保证一个活动对应一批券

• 当运营人员创建优惠券时，手动为一个活动创建一批库存，在对内的命名上做一个标记，例如618老用户专用7折优惠券
• 选择活动时，直接选择对应这个名字的优惠券即可，系统不做任何绑定关系的干涉

2）在活动使用100张券时，通过冻结逻辑，为该活动锁定这100张券

• 运营人员创建好200张优惠券
• 在A活动需要使用这批优惠券时，选择其中100张
• 活动创建好后，需要调取优惠券系统的冻结接口，调取成功后，系统自动冻结这100张库存「冻结意味着这100张券只能给A活动使用」
• 当活动结束后，需要调取优惠券系统的解冻接口，将未发完的优惠券释放回库存池里

3）优惠券以模板+批次为模型进行创建，活动选择的是券的批次

• 管理员创建好优惠券模板
• 运营人员申请并创建好为A活动使用的券批次，并将其命名为618老用户专用7折优惠券
• 选择活动时，直接选择对应名字的批次即可，系统不做任何绑定关系的干涉

以上3种，都是目前市面上比较常见的优惠券管理方案，没有绝对的对错。如果现在让你做一款面向不同活动系统、不同发放渠道的平台型优惠券系统，你认为其中哪个是更符合高内聚低耦合设计思路的呢？

个人心中的答案是第3种。

方案1中，券的模板和制作被融合为了一个动作，两个业务高度耦合，未来很难符合大公司对于两个动作分别赋予权限进行管理的诉求。

方案2中，将库存冻结/解冻的逻辑也与外部活动系统进行了高度耦合，这意味着任何一个需要拿优惠券的活动系统，都需要在适当的节点再额外调取冻结和解冻的接口，提升了系统间的业务耦合度。

而方案3将券的模板管理和制作抽象为了两个动作，未来能够满足更具个性化的管理诉求；同时，引入了批次的概念，无论是什么外部系统，都可以通过批次这一个概念与优惠券系统进行交互，无需适应冻结/解冻这样耦合的业务逻辑。

如下图所示，微信支付营销工具里的代金券就是通过标准的批次API进行交互的：

那方案3如此高度抽象和解耦，为什么市面上的系统都没有用这样的方案呢？

这是因为方案1和方案2本身虽然看起来不够解耦，但如果你的优惠券系统只需要和内部的活动管理系统进行对接，方案1和方案2其实对接起来足够简单，即使有业务耦合度也没关系；同时，用户在使用优惠券系统时，路径也会简单很多、学习成本很低。

所以，解耦和体验有时候真的是天平的两端，解耦度高虽然对于系统而言是好事，但也意味着两个模块的业务会存在一定的割离，用户体验上会有一些不流畅。这也就需要你在两者之间努力尝试寻求一个最佳的平衡点了。

思路二：多层抽象，灵活配置

在思路一中我们讲到了券模板和批次的这个模型，顺着这个案例，我们来引入平台化设计的第二个思路——多层抽象、灵活配置。

如果你在创建优惠券的时候，按照A客户对优惠券的诉求，把对应券的规则字段写死，没错，A客户在创建时直接创建了所需要的实例，确实省了很多事。

但你有没有想过3个问题：

1. A客户未来会不会有新的优惠券类型和规则需要创建？
2. 其他客户对于优惠券的字段如果和A不一样该怎么办？
3. 未来有新的大客户希望券本身的规则管理和制券是2个权限该怎么办？

从这个例子我们可以看出，大公司本身个性化诉求会比较多且强烈、对功能点的管理粒度要求会非常细致，同时，客户的需求也可能会随着市场的变化而不断调整。

那在这种情况下，我们就需要将一些功能抽象为多层，只有多层才能保证更为灵活的配置。例如，这里就可以将券模板和实例进行分开管理，同时，券模板层支持用户自定义字段进行配置等。

当然，这个案例不一定非常贴合你自身的业务，但是整体的思路是我们要通过更具杠杆率的产品来获得营收，那就势必倒推我们的产品也需要通过多层抽象和灵活的配置做成高杠杆的功能，千万不能来一个客户改一次。

思路三：强大的对接能力

笔者之前在做小微SaaS时发现，大部分小微企业基本核心就用1-2款管理系统，你的管理系统基本会是一个小微商户所用系统中的主角。但在大型企业中，你的产品很难成为客户整家公司中的主角，大部分情况下只是众多流程中的一环。

这就意味着我们需要对接各种各样的客户自有系统和客户采购的三方系统。

当然，对接这里具体的技术细节我不太擅长，但这里想提醒大家的是：

• 务必要从长远的角度考虑如何与更多客户对接
• 尽可能多调研大部分客户的现有能力是什么样
• 关注客户在对接上的实际诉求到什么程度

通过综合以上3种信息，再去考虑如何给出一个解耦度高、标准能力更强的接口规范。

这里分享了一些在特定场景下收获到的小经验，还有待未来持续完善，但个人觉得好的平台化产品也应该像一款插座一样，外部系统无需过度耦合、只用接入插口，即可快速连接并使用产品。

以上，就是笔者这2个月来对于平台化产品的一些浅见。虽然还不够深入，但对于此前更多关注纵深业务的我来说，自己的视野和思考的广度都有了一定的提升（格局打开）。

打一个可能不太恰当的比喻：重业务型的产品就像迪士尼乐园一样，给你在特定场景下沉浸式的体验，但很难复刻、也很难响应更多游玩的需求；而重平台化的产品就像一盒乐高，无法给你过于场景化的体验，但却赋予你无限可能。

作者：冰冰酱；公众号：产品冰冰酱

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

题图来自 Unsplash，基于CC0协议。