产品经理的中台思维
产品经理对中台的误区
提到中台，大部分小伙伴都会觉得跟产品经理角色关系不大，这更多的应该是架构师或者研发应该考虑的范围嘛。
但在实际工作中，经常会发现产品A会用到服务A，产品B也会用到服务A。举个简单的栗子，比如淘宝的订单中台，不管淘宝/天猫还是去啊，都要经过创建订单，订单拆分，订单支付等流程，那如果每个产品线都自研，对公司来说是重复开发，造成资源浪费同时也影响效率；对客户来说可能是体验不一致，增加学习成本。
所以对于产品经理，在产品开始规划阶段就要甄别可复用/可调用的信息，整合公司现有资源，快速推出MVP版本。
中台的概念和优势
中台其实是把一些公共、通用的部分从前台业务中抽离出来，形成可复用的服务，让前台业务之间的信息形成互通和增强的能力。
中台的思路最早来源于军队，以美军作战阵型为例，以7-11人组成的小团队去前线作战，这个小团队是最灵活也是核心竞争力和打击能力最强的组织。背后其实有非常强的导弹指挥系统做支撑，才能支持这么小的团队快速做出判断，并引领整个进攻完成。
举个麦当劳的案例，麦当劳作为全球性连锁餐饮品牌，在全球有3.6万多个门店，大部分人会认为麦当劳的管理模式是方案A，参看下图。但其实麦当劳有个强大的数据中台，各门店的销售数据每15分钟就回传到数据中台，各层决策者可以直接在线查看并分析某个门店的运营情况，并及时做出决策方案参看下图方案B。
中台的优势
从上面2个例子，其实可以看出中台的优势所在。
避免重复工作，减少浪费；
同时为多个产品赋能，让前端产品跑的更快；
简单清晰的调用关系，
底层数据穿透 共享，各个产品不再是各自的孤岛，决策层也能全面高效的获知准确的底层信息；
同时中台和前台又相互赋能 彼此成就。中台为前台提供稳定的服务支撑，让前台更轻量更灵活更快速的创造业务价值；另一方面中台也从前台多样化的业务需求中获得滋养，不断的自我提升，以提供更丰富的能力，供更多的前端产品来使用。
中台思维的实践案例
前面提到了中台的概念和优势，但其实这种中台架构的改革应该是自上而下的，如果你（pm）当前正处于这种组织架构下，那么建议可以逐步培养这类思维方式，通过合理的拆分，有效的整合，将产品团队及个人打造成可以应对复杂环境变化的组织或产品人。
回顾多年前在xc的经历，部门小伙伴经常会自发的分享一些竞品分析报告、用户调研报告、读书心得或经验干货，目的是把自己工作中的有价值的方法总结提炼出来，分享给其他同事，从而让他人少踩同样的坑。
一些大型互联网公司的ued部门也会有独立的团队来制作一些guide，目的都是把一些通用的、复用性较强的控件独立出来，做成统一的规范。其他人在遇到争议的问题时，有个参考的依据；同时guide也不是一成不变的，会随着业务场景的不断细化，新交互行为的出现，用户习惯的深入挖掘，及时的进行优化调整。
对物流快递公司来说，最头痛的就是网点位置信息不准确。网点由于各种原因也不愿意录入真实的地址，这就导致客户在前台查询的时候，没办法获取到真实的信息。后来我们就通过底层数据来透传，比如通过让网点在APP里更新店铺照片，来获取位置信息；或者获取业务员收派件的常用操作位置；或者前台支持客户自主举报错误信息等方式，来全方位的采集信息，尽可能的完善和修正网点信息数据库。
这几个例子其实都不是BAT所讲的大中台的概念，只是一种日常工作中的思维方式或者工作方法，感兴趣的可以从小的分享来尝试下~
推荐阅读
《企业IT架构转型之道 - 阿里巴巴中台战略思想及架构实战》你将了解到阿里布局“大中台 小前台”的战略背景和目标，如何通过组织架构调整和技术方式搭建中台（偏技术），以及在实际案例中的应用成效。
《赋能 - 打造应对不确定性的敏捷团队》你将了解到作为领导者如何紧盯目标，监控流程，合理拆分，聚焦整合，最终对组织整体负责；
关注公众号【零点零壹】 ，在产品的路上 和玉米大人一起 每天进步一点点；
