中台产品经理是做什么的(万字长文：重新定义中台产品经理)

所以中台除了提供通用化、可拓展、可沉淀的业务服务能力外，最底层的逻辑还是优先保证业务的延续性，在延续性的大前提下再去探讨如何让中台业务更好的支持前台业务的发展。②业务模式业务模式是针对商业模式的业务实现形式，还以上面提到的京东B2C业务为例，为了满足向消费者售卖官方商品获取差价利润收益的商业模式，京东就需要有供应链采购、商品维护、商品促销定价等一系列的业务模式搭建。

万字长文：重新定义中台产品经理

编辑导读：中台并不是一个新概念，它从国外引入，已经在互联网行业发展很久了。要想理解什么是中台产品经理，首先就要理解，中台产品在解决什么？如何解决？本文作者对中台产品经理重新进行了定义，一起来看看吧。

做业务中台产品也有3年多的时间了，这三年多的工作实践其实也是将方法论落地的一个过程，在这个过程中不断加深对业务中台的理解，不断通过实践/复盘去倒逼产品知识体系的完善。将这些产品认知及工作经验总结成了本文，也是对初入职场的中台产品新人/想转行做中台的同学提供一些方法论的参考：回归到产品经理的本质，中台产品在解决什么？如何解决？在文章的最后还有一部分关于产品综合能力的分享，这部分适用所有希望更进一步的产品人。

中台并不是一个全新的概念，从国外互联网公司的实践到国内互联网大厂的引入，在互联网行业也发展了很久的时间，这里借鉴国内外中台的案例来理解一下，什么是业务中台。

1）美军在伊拉克战争中的中台战略

美军在伊拉克战争后期，面对城市巷战的复杂环境，为了避免不必要的伤亡、提升作战效率调整了作战策略，从地面部队进入城中一条街、一条街地打、挨家挨户地打，改为空中力量和地面特种作战部队空地协同的中台打法。

地面特种作战部队分成许多小组潜入巴格达城内，他们的任务并不是与伊拉克的守军进行战斗，而是对巴格达城内的变化情况进行实时的情报搜集：如兵力集结变化，火力配置变化，主要指挥地点变化等，并根据掌握的情况通报给火力充足的空中力量，空中待战机群基于信息立刻飞临目标空域，特种作战小组通过指示器材指示目标，由战斗机集群对目标进行攻击，完成前台（特种部队作战小组）+中台（空中战斗机集群）协同的作战动作。

2）部落冲突/皇室战争风靡的底层逻辑

芬兰移动游戏公司supercell，堪称世界上最成功的游戏公司，旗下著名的移动游戏有《部落冲突》、《皇室战争》、《海岛奇兵》和《卡通农场》，之所以能在极短的时间内制造大批量的现象级游戏，都要归功于supercell的中台组织架构。

supercell将游戏开发过程中公共和通用的游戏素材和算法整合起来，提供工具和框架，保证每个小的游戏开发团队可以快速试错，快速找到引爆点，对于用户反响好的游戏继续迭代优化，对于用户反响不好的游戏果断放弃，再去探索新的方向。

3）阿里共享业务事业部

阿里巴巴在2009成立了共享业务事业部，也就是基于阿里巴巴集团旗下多业务线而组建起来的阿里中台架构，一方面与阿里高管参观访问supercell受到的启发有关，另一方面也是受阿里业务的快速发展所驱动，在共享业务部创建之初，只有淘宝和天猫接入了中台服务体系，随着聚划算等后来一系列前台业务的出现，共享事业部变成了整个阿里集团的中台，所有阿里的前台业务都接入到了阿里的中台架构内；结合下图可以看到，共享业务事业部将用户、商品、交易、评价、搜索、店铺、数据、营销这些通用化的功能进行了抽象和聚合，形成一个个共享服务单元，对上层个阿里前台业务提供服务支持，每一个新的业务在0-1的过程中，都不用在为通用化的功能搭建付出额外的成本，通过对接中台化的能力快速完成启动上线。

（截图来自《企业IT架构转型之道 阿里巴巴中台战略思想与架构实战》）

对不同业务线的相同功能进行抽象，形成通用化的服务能力，并能够结合业务形态的演进对能力进行广度和深度的拓展， 以此为基础为业务使用方提供稳定的服务。

1）能力共享

中台概念兴起之前，如果一家互联网公司存在多条业务线的时候，每条业务线为了保证业务流程的闭环会组建各自的产品研发团队，结合自己业务形态搭建相对全的系统能力，这种烟囱式开发模式会导致很多可以复用的功能模块被重复开发，从而造成产品研发成本的损失。

中台的出现，将可以复用的功能抽象成了中台的服务，通过搭建一套相对完整服务体系提供给不同业务线使用，解决了烟囱式开发模式的成本损失弊端，通过能力共享的模式让各业务线在业务搭建过程中减少开发成本，快速接入服务能力，保证业务的快速上线运行。

2）能力拓展

能力共享让同一个服务可以同时提供给不同的业务线使用，但是不同业务线业务形态的差异或多或少会有各自的特殊性，这就需要中台能力具备拓展性，可以针对不同业务线的一些特殊诉求提供针对性的拓展服务。

以用户中心这个中台模块来说，如果一个公司的业务线有C端业务和B端业务，那么用户中心的服务就需要既支持C端用户体系的搭建也需要支持B端用户体系的搭建，这就是所谓的拓展性，既可以做用户的抽象也可以基于业务形态做用户服务的拓展。

3）能力沉淀

单纯的能力抽象和统一服务是中台架构最基本的价值体现，但是如果想让中台发挥出更大的价值、可以为业务进行更多的赋能，那么能力的沉淀是必不可少的。中台提供的服务并不是一成不变的服务，而是要结合业务的发展和演变不断完善业务能力，甚至是去颠覆原有的业务体系，中台能力一定是和业务一起成长的，接近业务一线的业务中台才能更大的发挥它的价值。

4）业务延续性

业务中台为各个业务线提供服务，这也就决定了中台服务的可延续性要足够强，一旦中台业务挂了，就会导致所有业务线的业务无法运转，对于前台的用户来说是致命的打击。所以中台除了提供通用化、可拓展、可沉淀的业务服务能力外，最底层的逻辑还是优先保证业务的延续性，在延续性的大前提下再去探讨如何让中台业务更好的支持前台业务的发展。

09年阿里提出了共享事业部的概念，15年逍遥子提出了大中台小前台的集团战略，20年底逍遥子又提出拆中台的观点。这让很多正在做中台或者初见成效的中台企业或者产品对是否还要继续做业务中台这件事产生了疑惑。

这里先提出笔者的观点，中台有必要做，阿里所谓拆中台有两个前提条件：第一个是阿里做业务中台做了很久，已经积累了足够多的实践经验，并且在现有的业务架构下在持续发挥着价值；第二个阿里所谓拆中台也是基于一定的业务形态前提下的不在依赖中台，并不是将中台全盘否认。

这更多的是从宏观层面提出了一个问题：什么业务适合做中台，什么业务不适合做中台？

笔者这里提供两个思考的方向：当前业务发展的阶段、当前业务的类型：

1）当前业务发展阶段

如果一家公司当前业务处于从0-1的阶段，这个阶段更多的解决的是PMF问题，即业务和市场、用户之间需求匹配度的问题，是通过业务的不断试错去验证需求存在合理性的阶段，这个阶段业务形态不稳定，不适合过早构建或接入中台能力。

2）当前业务类型

当前所做的业务属于延续性创新业务还是颠覆式创新业务，延续性创新是在原有业务模式下，通过提高效率、提升体验的方式实现业务的增长。而颠覆式创新，更多的是脱离原有业务体系寻找新的方向，这种创新模式存在极大的不确定性，成败的概率甚至高于成功的概率，所以颠覆式创新也不适合接入中台能力，除非当颠覆式创新的业务模式已经成长为成熟业务。

对业务的理解力是业务中台产品经理必备的能力之一，所有的产品决策、产品设计都依赖于对业务的理解，只有清晰的理解业务现状和业务中的痛点，才能结合业务快速发展的需求去提供产品能力，通过中台的能力去推动业务的健康、高速发展。

1）业务是什么

在笔者看来，业务会分为四个层级：商业模式、业务模式、业务架构、业务流程，业务流程是最表象的业务运转逻辑，最底层的则是商业模式，也就是能支持这个业务能长期运行的“第一性原理”。

①商业模式

简单来说，商业模式就是一家公司如何赚钱？以盈利为目的而搭建起来的公司内部、公司与外部用户、供应商、渠道等主体之间建立的连接关系，并能基于这种连接关系持续运转的系统机制。

公式化的表达，可以理解为商业模式是通过为X用户提供Y服务，赚取Z收入。以京东商城的B2C业务为例，京东商城通过为消费者提供官方商品的售卖服务，赚取售卖价格与从供应链渠道采购价格之间的差价收益。

②业务模式

业务模式是针对商业模式的业务实现形式，还以上面提到的京东B2C业务为例，为了满足向消费者售卖官方商品获取差价利润收益的商业模式，京东就需要有供应链采购、商品维护、商品促销定价等一系列的业务模式搭建。

③业务架构

业务架构指通过组织架构，业务系统模块的规划，完成对上层业务模式的支持，下图是从业务视角进行的业务模块的划分示意，并非真实的京东内部业务架构体系。

根据公司的业务线、组织架构等的不同，业务架构的规划也各有不同，对于多业务线且希望打造业务中台的组织来说，会根据业务形态，将可复用、抽象的能力统一化，形成共享服务能力提供给不同业务线进行业务的调用。

④业务流程

业务流程即为满足某个业务场景的需求，各个业务系统之间是如何交互的，通常会有单一业务系统内部的业务流程和多个系统之间的交互业务流程两大类。

举个用户购买产品到下单发货的业务流程，其中会涉及多个业务模块之间的业务交互，下图业务流程仅为示意，不代表真实业务流程

2）如何算理解业务？

不管是一个刚做业务中台的产品新人还是一个产品老兵，在工作中都需要不断的问自己三个问题：业务现状是什么？当前业务合理么？业务还能再优化么？

业务现状其实就是上文提到的商业模式、业务模式、业务架构和业务流程是什么？业务合不合理要去看业务的目标用户（C端用户/B端用户）的诉求是不是被满足了，是不是被很好的满足了。业务优化是结合业务中台的特点，对现有业务进行通用性、拓展性的优化。

当然，对于产品新人或者初入一个新业务的产品来说，对业务合理性和业务优化方案的把控会有所欠缺，需要通过不断的产品、业务实践去提升对业务认知和理解，之后才能对业务合理性进行可观的评价以及提出业务优化的合理方案。

3）提升业务理解力的方法

如何快速从0-1理解业务，这里推荐两个方法：结构&还原、类比。

先来说解构和还原，简单来说就是挖掘业务的本质，只有理解了本质才能理解围绕本质去做的各种解决方案，这里推荐古希腊哲学家亚里士多德提出的第一性原理理论，亚里士多德提出每个系统中存在一个最基本的命题，它不能被违背或删除。

这个理论在今天被大众广泛认知的典型案例就是有“钢铁侠”之称的埃隆马斯克，马斯克对新能源电动汽车行业进行第一性原理的拆解后，将影响新能源汽车产业成本最关键的电池成本降到尽可能的低，从购买成品电池到通过市场购买组成电池的最基本原材料后自己组装成电池同时优化电池的使用效率，提高了新能源汽车电池使用效率也最大化降低了电池的成本，让特斯拉变成“人人”都买的起的新能源汽车，当然马斯克践行第一性原理的案例遍布他的所有创业项目当中包括spaceX、Hyperloop。

上面提到的解构和还原是帮助你理解业务本质的方法，而类比则是帮你理解业务为什么是现状并思考是不是合理，一个业务能运转起来一定是有存在的意义的，如何理解为什么这样，可以通过类比的方式进行理解。

任何一门互联网生意都脱胎于互联网诞生之前的线下生意，互联网的出现除了改变了生产效率之外还在一定程度上改变了生意的形式，但是无论是生产效率的提升还是交易模式的创新都是基于原有线下模式的发展与变革。所以在理解一门互联网生意的时候，可以去类比一下在互联网出现之前，要完成这样一个交易在线下是如何交互的，基于原有线下的业务模式，再去看互联网是如何改变这么生意的，是不是向着效率提升和模式创新的方向在发展。

除此之外，还可以和互联网其他产品之间做横向的类比，其他产品不单单是同行业的竞品，也可能是同商业模式下的其他参与者。以共享经济为例，无论是共享出行、还是共享住宿其背后都是基于闲置资源的再利用去带来商业的变革，那么只要在这个赛道之上，都可以进行相互的学习与借鉴，帮助你更快、更好的理解业务。

业务的理解力是做业务中台产品的必备能力之一，任何一门业务都不复杂，只要有充分的时间都能对业务有深刻的了解，但是如果你想对业务有深刻的认知，还需要拥有主动思考为什么的驱动力，看行业、看生态，能主动对业务提出自己的观点和看法。

1）服务形式

中台产品的服务形式大体上分为两个方向，一个是提供工具类或平台类产品，给到内部业务团队使用，实现特定业务场景下的业务。例如客服平台，通过提供客服操作平台，让不同业务线的服务团队可以通过客服平台处理用户的问题。那么这个客服操作平台就要具备对于不同业务线的业务的理解，在操作平台有针对性的提供客服业务查询、处理的能力。

另外一种是对于中台与前台、中台与中台系统模块之间的业务实现，这种业务交互通常通过API接口的形式，基于某个特定的业务场景，将需要的业务数据在不同系统之间进行交互以完成特定的业务闭环。以京东实体商品购买为例，用户提交订单支付成功之后，那么这个订单就会通过交易系统将订单信息传递到仓储模块进行库存的使用、快递配送等流程以实现将物品在规定时间内送达到用户手上的目标。

2）如何定义服务

对于工具产品或平台产品来说，和前端用户产品的职能有些类似，都是面向用户提供能力，但是这里的用户不是我们通常意义上的C端用户，而是B端用户，主要是公司、团队内部的用户，这个用户可能是业务团队也可能是服

务团队等等。

和用户端产品一样，在定义如何提供服务或者说如何设计产品环节，都要考虑用户角色、流程、功能划分，然后形成整体的产品原型进行设计、开发落地。（这些有成熟的方法论，就不在本文进行详述了）

和用户产品不一样的是，对于中台产品来说，要理解所提供的服务面对的业务团队以及背后需要实现的业务流程，这个工具可能是帮助业务团队完成整个业务流程闭环，也有可能作为其中一个或多个业务节点来提供业务支持。这就对中台产品提出了更高的要求，要能清晰的认知自己提供服务在整体业务当中的定位和边界，同时还要考虑多业务线场景下的服务适配及服务拓展。

接口服务相对来说更加抽象，它脱离了可操作的用户界面及功能，更多是系统层面的数据交互。从技术视角来看，接口服务分为读、写两大类，从数据操作视角来看，接口服务分为增、删、改、查四大类。

接口分为服务的使用方和服务的提供方，使用方需要按照接口定义的入参进行传入，接口接收到入参后通过接口内部定义的业务逻辑进行处理，根据处理结果，通过接口输出业务处理结果（成功/失败）及对应业务数据。

我们以用户注册为例，用户在前端输入手机号、密码、验证码提交注册，前端页面会调用中台会员模块的会员注册服务接口，入参会传入手机号、密码、验证码，接口接收到这些参数后，会做几件事情（仅仅模拟一个最简单的用户注册接口交互，实际业务逻辑远复杂于事例）：

校验参数是否正确，验证码和发送给用户的验证码是否一致、手机号格式是否正确、密码格式是否正确；校验当前会员数据库中是否有该手机号注册信息，如果有返回注册失败，没有则继续；3）将手机号、密码写入到会员数据库当中，生成该用户的一条注册会员记录；接口返回注册成功或注册失败及对应失败原因；

上面这是一个简单的接口层面调用事例，那么对于中台产品来说，在设计接口业务逻辑过程中，无论是服务使用方还是服务提供方，都需要考虑几个关键的问题：

接口调用失败的异常场景如何处理？接口调用超时拿不到预期的结果，如果降级保证接口使用方能继续正常业务开展？接口的使用场景，调用频率及调用峰值（QPS/TPS）能否支持？

这里举一个简单的案例来说一说对于接口调用异常的设计策略：还是以电商网站为例，用户下单购买一个实体物品，使用微信支付以及部分积分抵现，那么在提交订单时，中台交易模块要与支付系统和会员积分系统进行交互，在这个环节如果调用支付系统异常或调用接口超时，需要终止当前交易流程并且要求用户重新预定；但是如果调用会员积分系统接口超时，其实可以降级允许用户成单，后续异步扣除用户的会员积分，即使扣除失败，积分所带来的交易成本远比用户预定失败后流失要低的多。

在设计接口交互异常处理逻辑时，不是单纯以某一个原则进行设计，而是要根据实际的业务场景，以及你所设计的逻辑背后带来的业务影响、收益有非常密切的关系。在产品设计环节，多想想业务本身，最终方案才可能对用户、对公司更有利。

3）服务与功能的区别

通常我们所说的产品经理大部分都是功能产品经理，功能即为了帮助用户完成某一个需求而实现的解决方案，还以电商类平台为例，电商平台的客服团队为了能帮助下单购买了商品的用户解答问题，就需要在用户来电进线后可以看到用户购买商品的订单信息，给客服提供这个查询订单信息页面就是一个功能。

那么什么是服务呢？服务本质还是功能，只是相对于功能有了通用性、拓展性能力，上面提到的电商平台如果是阿里巴巴，对应的客服查询信息功能由阿里共享事业部的中台服务团队进行提供，就要同时考虑不同业务线如C2C的淘宝、B2C的天猫、B2B的1688等各种售后业务场景，结合各个场景可能存在的服务诉求，提供相对通用户的服务页面或订单信息查询能力，这样能保证当有某一个业务线接入中台客服能力的时候可以使用，避免过多的个性化开发。

所以服务更多是业务中台产品经理需要考虑的问题，对于中台产品来说，设计的每个功能都可能是通过服务的形式提供出去，那么如何让功能相对灵活的适应个性化的业务场景就是产品经理日常工作中最需要思考的问题。

同时，服务还是可“进化”的，可以基于接入的业务进行自我能力的提升，不单单是提供服务，还能结合服务过程中所积累的业务经验进行价值的沉淀，从被动服务到主动学习，让服务不仅仅满足业务需求，而且还可以提供超出预期的服务能力。

上面提到的如何定义服务、如何理解服务更多的是从产品经理业务能力、专业能力上的提升，这些都是成为一个优秀中台产品经理必不可少的条件。

下面分享的这些关于产品经理软能力的经验，可以说是所有想在产品经理这条职业路线上不断提升的同学都需要具备的。下面这些不仅仅是我自己在产品经理这条路上的实践总结，也是在过去一段时间观察初级产品经理的工作过程中的一些反思和思考。

如果你想在产品的这条专业路线上不断提升，向更高阶产品经理去努力，那么建议可以结合下面提到的这些软能力复盘一下，哪些是自己目前所具备的，哪些是要在接下来去提升的。

1）学习力

如何定义学习以及如何学习，在互联网上已经有很多成熟的方法论进行介绍了，在这里我想表达的是，你现在的学习方法是否达到的了“学习”的效果。简单来聊一聊表象学习和深层学习，表象学习指通过学习你了解了现状是什么，而深层学习指通过表象的理解，能思考明白为什么表象是这样，表象是否可以优化，之所有没有被优化是因为哪些因素导致的。

我们说深层学习，更多的是结合思考、经验的学习，能够不局限在对于表象的认知，而是能够基于表象了解表象背后的因果。

这里分享一个可以提升学习效果的方法，在克里斯坦森教授的破坏式创新理论中，在针对任何一个商业现象的观察和分析时都会提出三个问题：这个商业模式为什么产生？（背后解决的本质问题是什么）这个商业模式合理么？（现状背后是否还有需求没有满足）这个商业模式可以再优化么？（找到优化的方向，或许就是颠覆式创新的突破口）

我们在学习任何一个“知识”的过程中也可以不断问自己这三个问题，现状是什么，现状合理么，现状还能更好么；结合这三个问题进行解答，在提问回答的过程中，你就会真的学会“知识”而不只是学“知识”。

2）执行力

聊执行力之前，先来举个例子：假设你正在通过12306购买一张出行的火车票，在选好车次后点击预定时，发现钱支付了，但是页面迟迟不会告诉你是否购买成功，你的心理状态是什么样的？

在笔者上学期间，读过一本计算机专业非常经典的书籍《算法导论》（当然，这本书笔者没有读的很深，就像每一个号称要好好背单词的孩子一直停留在词汇书的abandon一样），但是这本书序言中关于算法的定义我记忆尤深：算法=输入+处理逻辑+输出。计算机、程序、算法在数字世界甚至影响现实世界的过程中，都是通过输出一个明确的结果来让这个世界可以更好的运转下去。

相信大家应该能理解我想表达什么了，执行力就像通过外部因素或内部因素给你自己输入了一个“任务”，这个任务需要你完成后将这个任务的完成结果“输出”给自己或者给你任务的人。

那么对于一个人的执行力评价，就取决于“任务结果”输出的准确性和时效性，所以对于提升执行力来说，有两个关键因素：

对于索要执行任务的理解，这就包含你所执行任务的内容以及这件事的紧迫程度，需要在什么时间内完成（简单来说，定义一个事情的紧迫程度可以使用重要-紧急四象限方法来定义）。时效性在执行力的评价里尤其关键，即使执行的效果不理想也要通过及时反馈的方式告诉别人不是不执行而是执行过程中遇到的问题需要更长的时间或者外部的帮助。如果因为不会做或者不愿意做而迟迟不反馈，那么最终只会给人留下执行力差的印象。从被动执行变为主动执行，这其实是执行的进阶模式，即在执行之前问问自己，为什么要执行这个事情，按照既定的执行方案是最优的么？如果不是，如何才是最优？是不是可以按照最优方案去实现？从一个单纯的被动执行者，转变成一个经过思考和决策后的主动执行者，对于完成任务或者自我提升都有更大的帮助和价值。

共情或同理心，简单来说就是换位思考，这是一个说起来简单但做起来很难的事情。无论在需求沟通过程中、还是在产品设计/规划过程中，共情都尤为重要。

以需求沟通为例，对于中台或者后台产品来说，需求提出方往往是公司内部的成员，这不像用户产品经理那有面对的用户需求都是“虚无缥缈的”，内部成员的需求都是基于某一个业务场景需要解决或需要提升解决效率的问题。在这种需求沟通的过程中，产品经理不应该面对“用户”提出的需求时，不应该局限在产品的主观思路上去评估一个需求，而是应该站在真实的用户视角去评估，为什么用户会提出这样一个流程或者一个功能，让自己处于用户的环境中去思考这个需求要不要做。

当然，共情并不代表要满足用户的所有需求，有一定工作经验的产品同学都知道，业务团队提出的需求不一定都是合理的，这其中有真需求也有伪需求，在评估需求的过程中也要保留产品经理的思辨能力，不仅仅要能站在用户的视角去思考这个问题如何解决，还要去思考为什么这个问题会出现，也许找到问题出现背后的原因并解决掉，用户的需求就不存在了。

以售后服务团队的一个需求沟通案例来讲一下，如何通过产品的思辨能力去沟通需求、评估需求。

服务团队提了一个需求：用户在购买了某个产品后会发现自己额外购买了一个自己不需要的附加产品，用户在来电要求取消掉这个附加产品时，客服团队操作流程复杂影响问题处理效率，希望产品经理能做一个一键取消指定产品的功能，提升客服针对此类问题的处理效率。如果是一个初级产品经理，可能就会和客服团队沟通，将这个功能加在哪个页面的哪个位置可以最大化提升客服处理效率。但是对于有一定经验的产品经理来说在接到这个需求后就会去想，为什么用户会遇到这个问题，是页面帮助用户默认勾选了附加产品，还是系统bug导致用户没有勾选但是还是替用户勾选了，然后基于反馈的badcase进一步排查，最终发现是系统问题导致，解决后客服团队的需求也就不再是需求了。（本案例纯属虚构，如有雷同纯属巧合）

结构化思维能力主要体现在逻辑能力和表达能力，在日常工作当中常常会发现产品新人或者初级产品必犯的一个问题：需求讲不明白，解决方案没有层次性，这其实都可以归结为结构化思维能力有待提升上。这里简单分享SCQA模型的使用方法，快速提升结构化表达能力。

SCQA模型：其中S指情景/背景，首先引入大家熟悉的情景事实；C指冲突，即实际情况与我们期望实现诉求之间的矛盾；Q指疑问，面对冲突，要解决什么问题；A指回答/解决方案，即如何解决问题。

在我们日常表达过程中，往往会只表达A而忽略了前面的SQC，这就会让接收者无法理解或不好理解，下面举一个电商平台提升用户支付转化率的例子：

S（背景）：用户通过某电商平台下单购物，发现下单后存在大量不支付订单C（冲突）：不支付的订单最终会取消，既消耗库存使用又降低平台收益转化Q（问题）：找到用户不支付的原因，通过激励策略提升支付转化率A（解决方案）：解决方案分两个方向，一个方向是通过用户行为、路径分析，进一步挖掘用户不支付原因；另一个方向是通过页面交互或提醒机制引导用户支付，如待支付页面通过倒计时及文案提醒增加支付紧迫感，通过短信提醒用户支付，通过限时立减红包引导用户继续支付等等。

介绍结构化表达的相关书籍有很多，其中《金字塔原理》是其中的经典之作，有需要的同学可以进一步学习。

复盘一次源于围棋术语，指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。后来演化到美军军事行动后的AAR（After Action Review），在每一次军事行动之后都会总结行动结果与目标之间的达成效果，在下一次行动中更好的完成目标。

通用化的复盘方法分四个步骤：回顾目标、评估结果、分析原因、总结规律。

回顾目标：做这个事情的目的是什么？期望达成的目标或者里程碑是什么？评估结果：基于实现效果与目标进行对比，评估是否达成或达成了多少分析原因：基于目标与达成之间的差异，找到原因，这其中既包含成功的原因也包含失败的原因总结规律：对于成功的经验，更好的延续下去；对于失败的原因，找到解决方案，在下一次的行动中避免

在复盘过程中，要保证求真：实事求是；求实：内容和原因；求学：改进与提升；求内：反思与自我剖析；求道：找本质和规律；

复盘的价值在于对做过事情的思考，并能基于思考为下一步行动作出指导。把失败转化成财富，把成功转化成能力。

系统思维是一种逻辑抽象能力，简单来说就是对事情全面思考，不只是就事论事，而是是把想要达到的结果、实现该结果的过程、过程优化以及对未来的影响等一系列问题作为一个整体系统进行研究。

从业务中台产品的视角去看待系统思维主要有两个方面

基于对业务、角色、系统模块的理解，将业务全流程形成系统化架构，刻画在大脑中和日常工作实践中在做需求、规划过程中，能基于对系统的理解去定义合理性

先说第一个方面，永远不要将自己局限在自己所负责的那部分工作中，就像那句不想当将军的士兵不是一个好士兵。站位高一层甚至多层，这样你才能具备更高的视角以便于向更高能力的职位提升。对于偏向业务的产品来说，对于业务全局性的把握，可以让你hold住任何一个业务需求（基于业务线的跨团队大需求也不在话下），不管你是不是需求的主导者，你都能提出建设性的意见来提升这个需求最终实现效果。

第二个方面是对于业务合理性的理解，对于业务中台来说，很多业务都是涉及多个业务系统模块交互的。在系统设计领域一直遵循着高内聚、低耦合的设计思想。这指的就是在系统内部尽可能的高内聚，避免业务逻辑的分散；涉及系统间交互的，尽可能低耦合、保持业务交互的边界清晰。在涉及跨团队业务需求的沟通过程中，站在系统角度去思考这个功能或者这个流程需要哪个业务模块实现更合理，才能提出让人信服的意见，避免系统模块之间的无意义撕逼。

业务中台产品经理是基于业务+产品两条专业路线的集合，在业务领域和产品领域都要做到足够精、专，才能在中台产品这条专业路线上走的更远。同时产品经理的综合能力又是任何一个领域的产品经理都需要掌握或具备的，产品路很长，不断做、不断错、不断改，谁足够快谁走的远。

记小忆，公众号：PM龙门阵，人人都是产品经理专栏作家，OTA中后台产品经理。

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

题图来自 Unsplash，基于 CC0 协议