同时教育行业是碎片化的，不同业务之前的场景差异性比较大，某模块的中台产品经理如何才能快速的熟知所有业务的全部场景，这是一个难题 。
（2）中台产品经理和技术的分界线在哪里？
也许这不仅仅是做中台产品经理才需要考虑的问题，但在教育中台的很长一段时间内，我的疑问比以前任何时候都强烈 。中台里有太多的产品设计，可以由具备产品思维的研发人员来考虑，但更多时候是需要向技术深入一步的产品经理来组织研发人员一起设计的 。
举个极端的例子，为了降低各个业务产品在各个端(前端、后端、移动端)接入中台服务时的配置管理难度，我曾考虑改进中台服务里零散在各端代码中的配置管理，做到集中管理并且可灵活配置，还拓展出支持未来可能的中台服务付费需求；
为了描述清楚需求，我写的PRD里除了描述各种场景和功能外，还用伪代码描述了如何使用，虽然伪代码的水平可能会被研发同事鄙视，但达到了清晰表述问题的目的 。
本文我无意提倡PRD里要写伪代码，主要想要说明的是中台产品经理不要指望能够和技术有清晰的界限，应该坚定的跨过去一步，同时也把产品思维带到技术中去，搭起一座桥 。
（3）中台产品经理如何设计一个新功能模块能够满足各方需求，且推动其在各个业务产品上使用起来？
除了要求产品经理有极强的专业能力外，还需要具备极强的主动性、沟通能力、甚至是商务能力，在各个业务之间想尽办法把中台的种子种进去 。相关的经验在在本文的「组织架构层面」部分做了介绍 。
2. 技术层面在中台架构的设计之初，我们就定位了教育中台需要提供的不仅仅只是后端服务，一方面纯后端服务和Paas服务就没太多区别，另一方面由于教育中台所希望提供的服务的业务属性非常强，提供的服务复杂程度远高于常见的IM、视频云等常见的Paas服务，如果完全通过后端开放接口来使用，接口的数量会非常多，调用的逻辑关系也会很复杂，使用成本会远高于常见的Paas服务 。
因此我们希望教育中台提供的是前后端一体的服务，最终展现给用户的是前端模块/组件 。
理想的情况下，业务产品的前台页面只要嵌入中台某功能服务的前端模块，就可以使用该模块的完整功能 。这种方式最大限度的拓展了中台服务的价值，但也给中台服务在设计中带来巨大的难度 。经过一年反复的煎熬，我们也整理出了几条设计原则：
（1）数据结构的统一是底线
理想情况下，教育中台搭建完一个模块，各个业务产品一接入就能完美的用起来 。但实际情况下没有产品经理和研发具备这样的能力，反复是一定要的，甚至于有时候教育中台需要去做一个需求还不明确的功能(我通常反对中台新做功能来完成业务产品的需求验证，ROI太低了) 。
当面对这样的情况时，一定要坚守的底线是数据结构的统一 。研发同学都知道数据迁移是一个大坑，所以只要数据结构是统一的，任何逻辑和交互的变化都是可以接受的 。
（2）前台界面通用的边界
数据结构的统一，后端服务的共享是容易在思想上达成一致的，难的部分只是在执行 。但前端界面的统一的观点自始至终都在激烈的辩论中 。
对于一个2C产品的产品经理和设计师，往往对交互、视觉都非常敏感，这也是2C产品能够在第一眼就留住用户的最重要的点 。但中台服务为了做到重用，往往很难在一些细节的交互、视觉层百分之百的满足每个业务的需求，并且在这种用户体验的层面，往往没有谁能够说服谁 。
对于设计型的产品经理而言，不能把控自己产品界面里的设计，简直就是被亵渎，因此在前端界面统一的这件事情的争论有多激烈可想而知，我自己也在这件事情的立场也有摇摆 。在多个case的纠葛后，我们推动了几件事情，不敢说解决了这个冲突，至少是改善了问题：
推荐阅读
- 电脑键盘顿号怎么打出来，电脑上顿号怎么才可以打出来
- ps怎么批量改颜色，PS怎么才可以批量调色
- 应该怎样删除抖音里喜欢的作品，抖音里喜欢的作品怎么取消掉呢
- 用PS怎样才能修脸，ps如何修饰人脸阴影
- cad2006连续标注设置，ad连续标注怎么才可以操作
- 张家齐陈芋汐多高
- 苹果手机小窗口怎么设置，苹果手机那个圆圈怎么设置
- 每天早上吃两个煮鸡蛋会有什么坏处
- 鬼谷八荒灵气纯度有影响