一、与优秀的业务一起成长
中台产品的超前发展是一件很困难的事情，因为存在的理由并不充分。除非有公司级别的战略目标的支撑，中台大力投入并超前发展，然后多个前台业务赛马发展。
所以一个中台产品必然是从一个前台业务孵化和发展起来的，并且一个优秀的中台产品背后肯定有一个优秀的前台产品，就像快手的音视频SDK是与快影共同成长起来的。
优秀的业务方有几个特征：
- 业务认知：优秀的业务方一定对产品及用户理解到位的，对行业最佳实践有清晰的认识。
- 业务愿景（北极星目标）：对于C端产品，业务目标通常是留存或者活跃用户数，而B端业务的业务目标通常是收入。愿景通常是一句通俗易懂的话，比如一年之后达到广告日消耗达到2千万。
- 目标共建（短期目标）：优秀的业务是有短期目标的，每双月业务指标是什么。
- 需求拆分：优秀的业务方会依照当前中台等能力提出合理的阶段性需求，哪些需求是需要中台承担的、哪些需求需要前台主导中台配合的。当涉及到多个中台中台协作时，能把多个中台产品的边界划分清晰。
- 人力诉求：中台产品是为前台业务服务的，人力诉求是根据前台业务目标中规划出来的，优秀的前台业务在规划年度HC时会把中台产品的人力诉求规划在内，需要各个中台产品投入多少独占人力。
- 项目排期：优秀的前台业务有较强的控场能力，根据人力和目标合理地规划排期和优先级。
- 成功共赢：优秀的业务方能带着中台产品一起发展，取得成果时能分享胜利果实。
二、中台产品发育指南
遇到优秀的业务方是完美的状况，最佳的合作的状态是与业务方分工明确，一起成长和合作共赢。但是项目合作过程中总会遇到各种不可控状况。当项目协作过程中遇到各种状况时，我们应该如何应对?
比如以下协作问题，可能很多中台产品同事都遇到过:
- 需求急。本周提需求，下周就需要上线，临时性需求较多，甚至只有口头需求
- 被甩锅。业务目标完成不了，甩锅给中台产品，被列举出哪些功能没有对齐竞品。
- 效果差。猛提需求，加班上线之后使用率低的可怜，中台产品团队受挫。
- 缺共识。对业务愿景缺乏共识，各干各的，中台产品总是无法满足业务方需求。
中台产品通常是弱势群体，尤其是项目早期，被投诉只有挨骂的份，毕竟可以被说出有哪些功能的缺失。能拿A绩效的大多是前台业务。但前台业务发展好了不一定有中台产品功劳，但是发展的不好很可能把中台产品拖出来背锅，这是由中台产品属性决定的。
一旦发生问题，早期选择「硬刚」我觉得是不可取的，就像打王者荣耀，中台产品是前期弱势型英雄，本该前期打野和猥琐发育，却偏偏要选择中路硬刚，白送人头同时错过发育的最佳时机。
乙方怼甲方需要很强的实力才行，我希望能找到各种方法化解问题。项目的成功有很多因素制约，比如创新业务的成功概率不到10%。但我们中台与前台产品合作过程一定要顺畅的，需要我们灵活找到方法主导项目，化解协作问题，同时谋求中台产品的长期发展。
1、主动学习业务（最重要）
做中台产品的PM通常有一个错误的思路，只是被动接受前台业务的需求，各自做好擅长的事情即可，最终的结果可能是互相撕逼，互相不满意。两方达到顺畅合作的状态，必须有一方能起到主导作用，要么甲方懂乙方的产品能力，要么乙方熟悉甲方的业务诉求。
在我看来，做中台产品的难度不在于功能开发，而是需要熟悉多个前台业务逻辑、抽象需求和控制不切实际的预期。当我们支持多个前台业务时，不能要求他们对中台产品有清晰的认知，最好的做法是我们自行深入业务，与业务方并肩作战，主动性一定要强。
2、服务心态
做中台是苦活，服务心态要好，「大爷」心态是做不好中台产品的。当你提供支持，业务方可能会觉得是理所当然的，按时交付是中台产品本分工作。做C端产品时，只有功能超出用户预期时，用户才会满意。同理只有中台产品提供的支持超出业务方预期，业务方才会满意。
上次去政府部门办事，墙上贴了一张告示挺有意思，写着服务规范「五步法」:笑相迎、问需求、办业务、求评价和说再见，还有服务群众「三不准」:不准说不、不准推诿和不准怠慢。这些要求和我最近总结的一些中台做事方法相似：
- 响应及时：小问题当天解决，大问题解决给予明确的时间点。中台产品可能被吐槽的点之一就是慢，割裂像两个团队。
- 定期同步：同步是双向的，一是了解业务方当前的进展是什么，业务方是否有新的规划、需求或者问题，二是对齐中台产品当前进展，是否按预期开发，每周要互通信息，千万不要憋大招，给对方一个意外惊喜。想起来我曾经被叫到总部开会，讨论某技术中台定位，推翻之前讨论的框架，事先没有沟通和走立项流程，上来就是硬怼，场面非常尴尬。
- 需求收集。所有需求都需要罗列到表格或者team里，做与不做都需要给予明确的答复，不能有遗漏。排期共识。在中台产品所能承担的范围内，没有不能接的需求，无非是工作量和优先级问题。 C端产品核心指标之一是留存，能对留存产生影响的功能优先级最高，B端产品的核心指标是收入，对收入产生正向影响的功能优先级最高。优先级排序规则上，前台和中台可以保持一致，并一定要有共识。否则多个业务方同时提需求，多个功能无法并行，交付时间点会不达某一个业务方需求。
- 拆解问题。这一点挺能体现中台产品经理的能力的，当收到某项需求，业务方误以为完全需要你支持，而拆解之后发现需要多个中台产品协作时，你会如何做呢？答复说做不了，只是提供某项能力即可，瓶颈不在你这，还是把完全方案描述出来，用自己的专业工作态度帮助业务方解决问题呢？
- 评价反馈。这一点是跟快手技术中台学习的，定期对业务方做调研，及时发现协作过程中不顺畅的地方，尽早暴露问题。
3、目标一致
业务方对中台产品吐槽最多的问题之一就是目标不一致，业务方背收入，而中台产品如企图躲在安全范围内只负责功能交付，会导致团队产生割裂。据我观察，50%以上矛盾都是由此产生的。强势并且发展好的业务方，通常会要求业务闭环。中台产品据理力争，但立足点是比较脆弱的，要么浪费人力，要么功能重复开发，只要业务的发展的好，浪费点资源其实并不是大问题。
4、需求规范
我司通常有项目经理协助，项目开发流程通常是规范的，但是业务方提出的需求差异非常大，当收到口头需求时应该如何应对？上周提的需求，下周要求上线怎么办？我采取的做法是反向约束业务方，一是每双月强行对齐需求，未来双月上线哪些功能，有清晰的表格呈现，同时逼迫业务方提前准备好需求；二是树立需求规范的典型，打压口头需求，没有文档及预期收益的需求都是要流氓，这类需求可以在完善之后再进入中台产品迭代周期。另外，以我自身过去的业务经验，是可以对对方能力做一个初步的判断。短期业务背景知识可能不如对方，但是产品基本方法都是相通的，通过提问去引导对方思考或者完善需求。当对方需求描述不清楚的时候，要么对方的业务整体愿景和目标很可能是不清晰的，要么对方的能力存在问题，
5、横向发展
当从某个前台业务成长起来之后，能横向支持多个前台业务发展的产品才能称为中台。 一是被多个业务需要，中台产品能发展会更大的价值。二是被多个业务打磨，产品能力会逐步强大。三是抵抗风险，只有一个业务方，被吐槽的话，只有被吊打的份，而有多个业务方时，只有其中一个说做的不好，也许是业务方本身存在问题。 当然也见过极端情况，多个业务方同时吐槽，那中台产品负责人该滚蛋了。
学习来源：商业化产品部的老师
