#本文为人人都是产品经理《原创激励计划》出品。

不同产品具有各自的“能力边界”，作为产品人，你知道一款中台产品应当做好哪些工作、具备哪些能力吗？当面对需求时，你能否判断该需求应不应当开发？本文作者就结合实际工作经验，总结了中台产品的“三做”与“三不做”，也许可以解答你的困惑。

在入职公司前，笔者只知道产品分为B端C端、PC端或移动端等；入职公司后，才知道原来还有一种产品叫做中台产品，与前台产品、后台产品同属于一个分类。在查阅资料的过程中，笔者发现中台并不是今年才出现的概念，而笔者在此前作为一个产品求职者，却从未关注过，深感惭愧。

于是，笔者在边摸索边踩坑的状态中，开启了职业生涯之路，也在接下来的实际工作中总结出了关于中台产品的三个“要做”和“不做”。

一、要做通用能力，不做定制能力

故事发生在今年7月。彼时，笔者还是一名刚入门做中台的产品新人，进入职场仅一个月。

笔者所在的中台团队下，积分模块刚完成了服务升级，需要在公司范围内寻找相关团队接入中台，避免相同服务在多处维护，浪费人力资源。笔者的任务，就是引导业务团队A将原来的服务迁移至中台，由我们中台对积分模块进行统一管控。

在初步需求沟通过程中，问题很快就浮出了水面。在业务团队A原来使用的系统中，获取积分的途径是固定不变的，但是每次可获取的积分数量是可变的，且操作人员可以在前端展示页面中输入任意一个大于零的自然数，允许灵活修改。而在我们中台的积分模块中，获取积分的途径是代码里预置好的，每次可获取的积分数量及积分获取规则也是在代码里预置好的，这些数据均不能在前端展示页面中人为修改。

于是，业务团队A提出希望中台在页面中增加一个可配置的文本框，用于操作人员灵活配置发放的积分数量。由于缺乏实战经验，对于这个需求我迟迟拿不定主意，于是我找到身经百战的研发负责人，询问他的建议。

研发同学立刻听出了团队A的弦外之音，原来是想让我们中台给他们做定制化需求呢。于是当机立断，给出建议：我们中台不做定制需求，如果他们非要积分可配置化，那就先酱，再酱，最后再酱，OK。笔者表示感谢：原来如此，我本来还觉得他这个需求蛮合理，差点就同意了~

最后由笔者的leader牵头组了一个会议，业务团队A同意将原有的积分获取规则进行管理和整合，对于每次可获取的积分数量，也整理出一些可选值在代码中提前预置好，操作人员可以在这些可选值中灵活配置。

二、要做预处理，不做过度处理

在笔者刚入门做中台产品的时候，曾经做过这样一个需求。在电商订单盛行的当下，可能会由于运营配置错误、用户巧妙“薅羊毛”、被黑客攻击系统等原因导致积分不正常亏损，因此要对积分支付过程中可能出现的风险进行控制。

经过一番思想的碰撞，笔者最终产出了一份自认为比较完整的解决方案：

前台各业务端在系统中埋点，将用户的操作日志数据传给我们中台，中台自行落库得到日志数据库。

中台对原始数据进行计算，得出多个数据指标，这些数据指标大多是对用户的历史消费习惯进行概括，比如积分消耗区间、每次支付行为平均消耗积分数量等；已经计算好的数据指标用于支撑风险判断接口，以每次交易的基础数据作为请求参数，比如本次交易需支付的积分数量等。

接口逻辑大概可以归纳为：将历史消费习惯与本次交易做比较，如果本次交易的数据与历史消费习惯不符，则将本次交易风险等级置为y，需通过对应的校验才可继续完成交易。

但是当笔者与leader沟通想法的时候，却得到了leader“你还是不懂中台”的评价。

leader指出中台最多做到日志统计报表这一步就够了，而风险判断接口的各种判断应该由各业务端根据不同的应用场景，做差异化的处理和判断。

笔者幡然醒悟，中台产品对原始数据做预处理的目的是更好地服务各前端业务线，但忌过度处理，或是做了本该各业务线做的工作。

后来笔者查阅了很多文章和书籍，恶补中台的概念及设计思想，终于找到了比较合理的解释。

《中台产品经理宝典》一书中，作者将互联网公司的研发中心比作一个厨房，将研发新产品的过程比作做菜，从而将做菜这个过程拆解为：买菜、配菜、炒菜三个步骤。买菜小哥作为后台，为中台提供最基础的原料；配菜小哥作为中台，统一对菜做预处理，完成洗菜、切菜动作；炒菜小哥作为前台，则根据不同烹饪方式最终完成口味不同的菜品。

在这个例子中，如果配菜小哥不仅完成了洗菜、切菜的动作，还顺手完成了炒菜小哥的任务，则会导致炒菜小哥无任务可做，那么人员组织架构将会变得很混乱。

三、要判断需求是否符合产品定位，不要盲目接需求

中台向各业务团提供通用能力，目的是为了减轻各业务团的重复工作量，而不是为了减轻各业务团的工作量。要注意区分工作量和重复工作量，仅两字之差，其含义却相去甚远。

举个例子：

• 团队A需要开发功能模块a和功能模块b，最终得到一个完整的产品x；
• 团队B需要开发功能模块a和功能模块c，最终得到一个完整的产品y；
• 团队C需要开发功能模块a、功能模块c和功能模块d，最终得到一个完整的产品z。

那么功能模块a、功能模块c就是重复工作量，而剩下的功能模块b、功能模块d皆属于工作量，分别归属不同的团队。

笔者所在的中台团队下设不同领域的产品研发团队，分管不同的业务领域。

其中，在订单领域内，常常出现这样的情况：团队B需要与中台对接得到功能模块a和附加小功能e。功能模块a属于订单领域，由中台团队下的订单产研团队负责开发；而附加小功能e不属于订单领域，由中台团队下的其他产研团队负责开发。

由于附加小功能e的开发量比较小，团队B不愿意多对接一个团队，因此常常会有需求，希望订单产研团队直接开发功能模块a和附加小功能e，完成后对接给团队B。

显而易见，这种做法是不合理的。如果中台产品人将这样的方案推上需求评审会，不仅不会得到研发负责人的认可，还可能会被各位研发同事怼。毕竟，谁也不愿意做工作之外的工作，而我们产品人更不能因为自己身上不背负开发的重任，就随意接需求，把一堆额外的任务丢给开发。

更重要的是，作为一名中台产品人，把握需求的边界应该是我们的基本功~

四、写在最后

本文主要描述了笔者在真实的工作场景中遇到的问题，并从问题中归纳总结出做中台产品的三大原则。以上仅作为笔者的经验，供各位读者参考。而各位读者对于中台的思考，需要从实际出发、在实际工作中总结专属自己的经验，方可在中台领域内快速成长。

俗话说，读万卷书不如行万里路。对于刚入门的产品新人来说，不论看过再多道理、再标准的指导原则，也许都跟纸上谈兵无甚区别。实践是检验真理的唯一标准，关于中台产品到底应该如何做，相信一千个人有一千个哈姆莱特。

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

本文为人人都是产品经理《原创激励计划》出品。

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