摘要：本文主要以笔者自身的工作经历介绍了一家三方支付公司的产品与系统的演进之路。
笔者在第三方支付行业工作近十年了。本文就以自身的工作经历为基础，聊一聊对第三方支付产品、系统以及行业的理解。支付是一个普遍的现象，任何经济活动都离不开支付，有商业活动就有支付。但正是这种普遍性让不同的人对支付有不同的看法与认识。一个小商户与一个电商平台对交易与支付的理解肯定是不同的。而第三方支付公司对支付业务看法与认知又与使用支付的商户有着很大的差异。下面笔者就站在第三方支付公司的产品经理的角度来讲一下我理解的支付产品与系统。
三方支付系统的复杂性差不多十年前我第一次进入这个行业时对支付产品还没有什么概念。但它给我的第一印象就是复杂。当时任职的支付公司还处于初创阶段，业务还没有起量，但研发团队已有几百人。经历了大半年的开发已经搭建了一套比较完整的支付架构。据说当时各种子系统超过100个。以至很少有人能了解公司支付体系的全貌，如何运作的。它带来的问题是一个新的业务在设计时，不知道它会涉及哪些子系统，它对现有的系统流程会有什么影响，该如何调整。那时最大的感受就是经常开会，任何一个小需求都可能叫上一屋子的人开会。还好当时公司里有专业的架构师负责分析业务涉及的子系统，拆分、拍板决定每个子系统的职责范围与开发任务。还有专门的项目经理负责推进开发落地，产品经理可以专注业务。后来公司也察觉这个问题，因为这不仅效率低更埋藏了风险。于是由资深的产品经理调研画了一张公司内部的系统架构图，并组织重要模块的leader向产品经理讲解每个模块的职责、功能、运作方式等等。我就是从那时起开始了解三方支付公司的系统架构的。
相比之前我做过的保险核心业务系统、预付费卡系统，第三方支付系统要复杂的多。后来我也总结了三方支付系统之所以复杂的原因。保险核心业务系统只是面向内部用户，用于保险公司内部的运营相对封闭。预付费卡系统是个相对专业的系统，面向的场景也是固定的。而第三方支付公司的支付系统面向的是各种交易场景，开放性的场景决定了系统的灵活性。另一方面支付公司的底层连接的是各家银行，内部称为通道。打通各银行并维护其可用，还要考虑各银行的处理差异、交易成本等等各种因素，也是非常复杂。除了两头在外，内部的账务处理、风控系统、资金的清结算等内部系统逻辑也很复杂。第四个原因是与资金处理相关的系统都有高可靠、高可用、一致性的要求，这必然导致系统设计的复杂性。在网上很容易搜到一些支付宝系统架构的介绍，这些介绍可以管中窥豹，也足以感受到支付系统的复杂性。 最后就是交易的规模，这是一个量变到质变的过程。一个小规模的单体应用系统与可以支撑50万笔/秒的支付宝的单元化分布式系统肯定是不同的。当然这属于技术层面的问题了，产品经理更关注业务造成的系统设计差异。
业务决定系统我前后呆过两家支付公司，同样是做支付由于定位与业务不同支付系统的设计也有着很大的差异。第一家支付公司是一个金融集团下属的支付子公司。最初定位是做C端钱包，为集团的金融客户提供服务。由于母公司财大气粗所以成立之初不急于做业务而是全力开发支付系统，搭好一个完整的支付体系。正如我前面所说业务还没开始做，研发团队已有六、七百人。基于底层稳定的架构搭建上层钱包APP，然后从集团接入各类金融服务，包括各子公司的客户成为用户，最后从外部引流拓展用户。尽管中间有一些挫折，但大方向是对的，最终还是取得了成功。
我入职的第二家支付公司是一家老牌的三方支付公司，起步早发展模式完全不同。最早从航空票务领域起家，深耕了这个垂直领域。航空领域成功之后又不断拓展其它领域，线下POS收单、餐饮、教育、医美等。由于面向B端提供支付服务，不同行业的差别巨大，所以几乎每一条业务线都有自己独立的业务系统。这样的好处是灵活，可以快速支持业务拓展，坏处是四处冒烟囱、系统、数据相互孤立。最典型的就是线上支付与线下支付是两套系统，如果一个客户即要用线上又要用线下收款就要两个系统都开户。但引来的问题是两边的收款记录不能统一查询、账务、结算是分开的……另一个问题是重复建设，几乎每套业务系统都有自己的商户进件、交易、账务……而且随着业务做大，需求增加系统功能变的越来越复杂，维护成本很高。
如果比较两家支付公司产品与系统的不同，那么首先是战略定位的差异，2C与2B定位差异决定了后来的公司发展路径。系统的演变是支持公司战略与业务发展的结果。两种模式没有优劣，只是看谁的战略更清晰、执行力更强。
产品的演进之路2016年公司启动了一款独立的线上支付产品的研发。其实当时公司在P2P资金托管领域有非常高的市场占有率，有几百家的P2P对接了我们的支付托管系统。那时P2P还是合法的。当时我们提供的是一个“账管家”产品，包含了线上支付接口 虚账户 资金沉淀的功能。这应该是公司早期的很成功的支持在线支付地产品。当时不只是这条业务线有线上支付产品，航旅业务条线也提供了一些对外线上支付接口。另外线下事业部也遇到一些客户需要线上支付。原本想拉这些客户对接“财管家”产品，但由于是跨事业部存在一些壁垒，沟通成本高、响应不及时，所以最后我们事业部决定做一款独立的线上支付产品“支付 ”。一开始资源投入比较少，一个产品经理写了三四个月的需求，又花了三四个月开发，产品上线已是2017年初了。最初的定位是给中小商户及APP开发者一套线上收款功能的接口，主要包括快捷、网银、代扣等支付方式。但当时的接口设计不是很好，联调的成本高，体验差。更重要的是中小商户的交易量小，要有大量商户接入才能产生效益。公司没有太多的互联网基因主要依靠销售拉客户，获客成本高效率低。后来公司做了调整：
- 由于微信、支付宝的市场占有率扩大，中小企业对这两种支付方式的接入需求量很大。于是公司调整产品功能，推出了一款以微信、支付宝聚合支付为主的支付产品“Adapay”。借鉴了Stripe面向开发者友好的理念对接口做了对象化的封装、优化。大大降低了联调的难度、提高了效率。收费模式上考虑到中小企业交易不会很大，偏重收取接入费而不是交易手续费。这款产品取得了成功，成为拳头产品。
- 重新定位“支付 ”产品方向，为大型客户提供行业解决方案。但大客户或行业解决方案需要的不只是支付工具，还要更多服务。线上支付产品逐渐加入聚合支付能力，主要用于日益旺盛的微信、支付宝的线上支付、线下扫码。活期理财功能对小B增加沉淀资金的收益，对C端则是为了帮助商户黏住用户。消费分期则是为满足美容、家装等行业的业务场景增加的服务。信贷服务是与保理公司合作提供支付迭加垫资的服务。由于单纯地增加增值服务，没有抓住客户的痛点，产品推进的并不顺利。
随着产品的演化，至2018年下半年我们基于之前线上支付产品的经验打造了一款新的线上支付产品“企账通”。当时国家在强化支付行业监管，禁止“二清”行为。很多电商平台沉淀小B资金的行为被禁止。一些大平台开始收购支付牌照合规化自身的经营，但更多小平台没有实力收购牌照只能对接支付公司。所以我们以此为切入点提供支付工具迭加账户、分账、资金管理（与银行合作提供资金监管服务）及一些增值服务。这个产品成为我们承接大客户与行业解决方案的主要产品。
企账通产品在推广的过程中从纯线上产品向着线上线下一体化的方向转变。其间也尝试与国内的各SAAS服务商、行业龙头、大型商圈shoppingmall合作。为了加强合作我们还曾调研了餐饮SAAS、宠物行业的SAAS服务商、收银系统SAAS服务商、生鲜连锁经营类平台希望能找到深入合作的伙伴。比如通过收购、购买系统源带码等方式快速切入一些行业，但效果并不理想。由于接了一些大商户定制化的功能比较多，所以后续的产品迭代、维护成本会较高。
随着SAAS服务产品的兴起，2021年初公司高层决定做一个SAAS化的支付产品——斗拱。希望通过对支付业务重构抽象，打造成通用的支付能力对外开放。面向的客户不只是企业商户、平台型客户，还包括软件开发商(ISV)、SAAS服务商、银行、四方支付等合作伙伴。不仅要实现支付还要帮助合作伙伴通过支付及增值服务实现创收，最终实现多赢。我们用了四个月时间酝酿、规划，五个月的时间开发终于在9月份上线。
以上大致就是当前公司支付产品的演变过程。
从产品层面看三方公司的支付产品从最初的拼通道、拼成本价格，转向拼支付能力、拼解决方案、服务。当然这是指为B端服务的支付企业。为了适应产品层面的变化，我们的系统也要相应改造实现对产品的支撑。
从支付到SAAS服务系统层面看支付系统从第三方支付公司内部的业务系统，也是对外提供支付服务的系统。这个系统跟随市场与产品的要求逐渐向外扩展，向着提供越来越多不同类型的SAAS服务演变。为了适应这种变化，系统做了很多改造。首先是底层整合，从技术层面的整合开始。比如账务系统。由于历史的原因我们先后有三套账务系统，一些老业务的账务系统甚至包含了业务功能。我们通过功能兼容、数据打通、新业务使用新账务系统、历史数据迁移等多种方式逐步迁移到新的账务系统。
其次是增加抽象分层。比如对接银网联的通道层是统一的，但各业务系统都直接对接通道。由于通道层返回的信息差别很大，各业务系统都各自处理交易之后逻辑比如入账、返回信息的封装等等。所以又统一封装了一层内部使用的收银台，负责对交易之后的通用逻辑做统一处理。比如交易之后的入账，返回信息的封装与透传。收银台也按支付方式与通道的不同分为扫码、之后所有的业务系统都接内部收银台。
再向上就是交易处理层。原来的交易只负责资金类的交易，站在三方公司的角度交易处理是连接客户的业务订单与内部支付指令的核心枢纽。现代复杂的商业场景、各种利益相关方的利益诉求都要在交易环节处理完成。我们对交易场景的内涵做了扩展，以适应各方的利益诉求。比如一笔交易会涉及电商平台的服务费、渠道的分润、消费者货到付款的利益保障、监管法规的要求……我们通过实时与延时的分账来满足各方。还有线上平台、线下shoppingMall会搞各种营销活动，需要打通对方的会员、积分、优惠券等营销系统，交易时不但要完成资金交易还要查询会员、核销积分、优惠券等。现在银联、微信、支付宝也会搞各种补贴活动，渠道商、商户也会有很强的参与需求，我们的系统也要对接各方的营销活动接口。
最上层是业务系统层。业务层的整合难度就不只是在技术层面，而是内部业务条线的分割。业务条线的整合并不容易解决，它涉及公司的经营与历史发展路径、组织架构调整、各部门销售的利益等问题。业务方向通常是由公司管理层依据销售反馈、市场调研决定要拓展哪个行业市场。然后依据这个市场的特点设计合作模式，商业合同条款、招商展业的方式、运营流程设计，新的业务系统搭建或老系统的改造，交易系统的改造。之后才是寻找种子客户、打磨系统与产品。如果顺利打开市场就进入成长期。目前我们除了整合产品功能也在做一些用户体验的优化。举个例子，一开始对外只提供支付接口，然后提供SDK。SDK是对接口的封装，比如：将接口联调必须的加解签功能封装到SDK中。将接口功能按应用场景封装成对象方便开发调用等。SDK提供的是后端的开发服务，对于前端开发我们在控台上提供收银台的可视化设计。通过拖拉拽控件快速生成页面及可下载的代码包，客户的开发可以将代码包集成到项目中，进一步提高开发效率。前面这些产品形态都是基于客户有开发能力来设计的，最后我们还提供了托管支付产品，只要客户注册后完成进件就可以获取一个收银台页面链接，通过线上收银台直接收款不需要开发。我们希望通过这些产品设计逐步向客户靠拢，满足各类不同开发能力的客户。
最后要提一下其实在做SAAS化支付系统之前，公司就开始升级内部的运维监控系统。实现了对内部核心系统的实时监控，建立了报警、统计、支撑服务。有了这些服务不仅可以实时了解系统运行的状态，也为异常事件处置提供了快速定位与技术保障。结合运维系统定期报告、故障复盘流程为不断优化系统提供了机制。使交易系统的可靠性、可用性达到三个9甚至4个9。这些内部支撑服务与监控体系未来将不只用于对内保障交易的稳定与可持续性，未来SAAS化之后也将成为SAAS化服务的一部分。
运营程流的优化以上是系统层级视角的，在产品层面我们也在做整合。这部分的优化包含两块：数据整合与流程整合。最初我们做的是业务基础数据的整合。由于各业务系统都是各自为政的，商户签约、进件、联调、上线、对账等都有差异，且基础数据也是各自管理的。我们首先尝试对商户、用户数据做简单的归集，公共的数据统一存放，各业务系统特殊的字段数据，比如配置信息、费率信息各自独立管理。
另一方面我们也对业务运营流程做了分析，了解各业务的运营流程现状，设计一套兼容各业务条件的运营流程。然后基于这套流程设计系统，准备将各业务系统的流程最终都迁移到新的系统。最终的目标是整合内部流程统一中台，实现统一进件与开户。
目前来看这部分工作还未完成。
- 公共基础数据的统一规范特别重要；它不仅是选择需要公共管理的字段，按照DDD的方法论，需要对所有字段做含义明确的定义，这样便于业务、产品、开发做沟通。
- 尽管我们希望能有一套统一的业务流程与规范，然后再由系统承接统一后的流程与规范。但问题是很多业务流程差别很大，比如标准商户进件流程是先提交材料、审核通过、开通业务、微信/支付宝入驻、联调、生产上线。但有些业务为了提高效率与客户体验，客户先提供基本信息，开通业务、微信支付宝入驻、联调、生产上线，然后在规定期限内补交材料、人工审核。既然完全统一运营流程很难，那就换一种思路通过引入规则引擎实现流程的可配置。目前我们已实现了运营审核流程的可配置，但商户进件流程比较复杂，涉及跨部门诉求、跨系统落地，需要大量的准备与分析工作。这部分工作还未开始。挑站可能还不只这些，即使已经在使用运营规则引擎也涉及大量复杂的配置。我希望未来我们可以实现系统可以自动扫描系统中各类主体的信息与状态自动与业务规则匹配，决定下一步的操作。如果足够智能这个系统不仅可以提示运营内部操作，还能够对外向客户推荐产品与服务。当然这己经超出了简单的规则引擎的应用。
在业务层面我们尝试对内部各业务系统的功能做沉淀，比如Adapay系统可以为二级代理商做分润结算，我们在斗拱SAAS系统也做了这样的功能。企账通系统支持集团、连锁机构的层级管理、资金归集，这个功能也沉淀到斗拱SAAS系统。这样做一方面是丰富斗拱的功能与支持的业务场景，另一方面是为以后将所有业务都整合到斗拱系统做准备。
除了做系统层面的功能沉淀，公司也做了内部组织调整建立一个部门专门对外输出已有的能力。就是将底层的能力整合为某一特定商户或行业提供解决方案。通常的定位是通用的需求沉淀为产品能力由底层系统实现，定制化的内容由解决方案部定制化开发实现。
总体上讲这部分工作只是部分达到了预期。首先是存量业务如果处于衰退期的业务我们可以停止纳新维持现状等待正常退出。如果是比较成熟的业务就很难迁移，特别是涉及需要商户配合改动的会比较困难。如果不能迁移那就只能正常迭代维护，唯一可以做的就是在新系统实现所有业务功能，业务上将新客户引导至新系统。但如果存量的商户长期不能迁移，那就需要维护新老两套甚至多套系统，维护成本会不断升高。新系统堆叠老系统的功能并不是一个最好的方案。
当前的工作流程优化当前仍聚焦于流程优化与系统整合。举个例子商户进件，按商户来源分：渠道商进件商户、业务直销商户、自主进件商户。按进件的方式分：渠道商控台进件、运营内控台进件、网站自助进件、接口进件（可细分为纯接口进件、带网页的进件，封装了完整的流程方便SAAS商户做集成）。按进件流程分：标准进件（提交材料、审核、签约、联调、生产上线做交易），后补进件（先联调、上线交易、后补材料审核）。还有为了提高进件效率提供费率模板、电子签约流程……不同的场景对系统的设计都会有影响。而且这些场景也是不断迭代与演化出来的，系统的调整伴随着演化的过程。 还有进件的运营流程中所有操作环节都可以优化，比如：补交材料、后审、电子签约、业务配置模板、分润结算、电子发票、OCR识别……每个环节的优化都会提升的进件的效率。
除了对现有的流程最优化，也会有新的功能与流程需要设计，比如原来支付公司只向渠道商结算分润，渠道商下属的代理商的分润都是渠道商自己负责。后来代理商也希望支付公司直接结算分润给他们不通过渠道商结算。这里不只是流程变化，首先法律关系上如果支付公司直接向代理商提供了结算服务，与代理商之间有了直接的资金往来就需要协议条款支撑。其次因为有了新的签约条款，代理商的进件需要调整运营审核流程。
业务模型设计流程的优化与新增需要修改的不仅是系统，更需要设计出合理的业务模型与系统模型。由于第三方支付公司有很多不同类型的客群与服务主体。比如：付款的个人用户，收款的商户、合作银行、清结算机构（银联、网联），帮助拓展商户的渠道商、代理商……不同类型的主体在整个支付业务中诉求是不同的，有些是支付公司提供服务，有些是提供服务给支付公司，也有相互依赖的。需要根据业务流程中他们的角色与职责设计好业务模型。业务流程会不断变化，业务模型既要稳定又要能适应变化的流程。 比如在标准的交易场景中支付流程只关注用户付款给收款商户，这个场景中业务模型很简单只有两个主体。但在电商平台这样的场景中，由于平台主导了业务场景提供了交易撮合的服务，也会有收费服务费的诉求。所以每笔交易都会有抽成。这时交易就从两方变成了三方。在业务模型设计时就要考虑如何支持这样的场景？什么样的主体可以参与交易的分账？是实时还是延时分账？分账金额或比例的限制……更复杂的是交易时的营销补贴。在模型设计时就要考虑，谁来补贴？资金从哪里来，流到哪里去？手续费由谁来承担？退款时手续费与营销费用的处理方式，不同的场景处理方式可能是不同的，是否每种方式都要支持……这些问题首先要业务确认，之后按照前面DDD的方法论需要通过事件风暴描述整个业务流程、规则将业务问题拆分到系统的域模型中。DDD是领域驱动设计的方法论，它将业务与系统划分为不同的域分而治之。比如核心域（交易、账户、资金、商户）、通用域、支撑域（增值、会员）等等。其实就是划分边界，然后分析业务描述中的名词、动词转换为聚合根、命令、事件、实体等模型，并根据模型来设计系统。在一个有清晰边界的限界上下文内分析出值对象、实体对象、聚合根、领域事件。系统的改造并未完全使用这套方法论，但至少按域对系统做了划分。分而治之的方式对底层做优化。
中台本质是业务模型，通过DDD这样一种设计思想，它可以指导中台业务建模转换成微服务设计，从而实现系统的落地。个人认为SAAS系统好坏很大程度上取决于模型的构建。构建好的业务模型不仅有助于理解与沟通，也是构建稳定的系统模型的基础。这里的关键是构建领域知识与模型是需要持续不断的投入资源维护的，包括统一的术语字典、模型文档的维护、多方参与的事件建模流程……这是一个需要长期坚持不断迭代的过程，坚持往往很难。
下一阶段的工作站在产品的角度下一阶段要思考的问题是：如何将支付更灵活地嵌入客户的业务流程中。支付天生就是商户活动的一个环节，而且是闭环的最关键的环节。它的天然属性就是要嵌入商户的业务流程中的。这里的差别是嵌入有多深。举个例子，传统POS的功能只有收款，并未与商户的业务系统打通。如果将POS与商户的业务系统打通，那么业务系统的订单信息自动传送到POS上。完成收款后再通知商户的财务系统、仓储、物流……那就实现了系统层面的闭环效率就高了很多。目前我们已实现的webhook功能就是基于这种想法的一种尝试。如果再与商户的会员、营销系统打通，在收款的同时支持打折、销券等操作，那嵌入的领域就更深了。如果支付环节还支持银行的消费分期、花呗分期、提供交易流水数据作为流水贷的依据，那支付所提供的附加价值就更高了。在我看来将简单的支付扩展为复杂交易的处理是必然的趋势。支付只是资金处理，交易包含了客户业务属性、流程。做B端的支付产品就是在帮B端解决交易问题。
另一个更重要的问题是：如何快速地维护各种商业关系？这个问题有点抽象，它的提出是基于以下的判断。三方公司之间的支付能力的差异正在缩小，以前看谁接的银行通道多，成本低。断直联后大家的通道能力差异大大缩小。后面2C类支付比拼的场景，基本被微信、支付宝占领。2B类的支付场景由商户主导，支付公司能做的是对商户业务场景的支持。支付本质是商业主体之间利益关系的体现，所以支付的基础是两点：商业主体在系统中的创建，然后是商业主体之间利益关系的维护。不管是交易、分账、营销活动等等这些商业行为的处理，本质都是利益关系的反映。所以交易是利益关系的最终体现，只是目前是通过交易系统来实现数字化处理。目前我们关注的业务流程还是如何快速高效地在系统中创建各种类型的商户，如前所述，不管是渠道商进件、直销进件、自助进件都是将商户主体数字化。下一阶段我们将关重点关注这些主体之间的商业关系的构建。商户与商户之间的利益关系这是两种完全不同的业务实体。商业主体的信息多是静态的，创建好了就很少变化，而商业主体之间的关系可能是动态的，而且关系的类型是多样的。比如简单的买卖关系、渠道代理与商户的关系、供应链的上下游、连锁机构总部与加盟店之间的关系……两个不同的主体之间的资金往来都是由它们的商业关系决定的。我们现在决定一笔交易涉及到哪些主体依赖的是主体进件时所决定的角色与审核过的业务场景。比如一个平台下面有一个小B商户、一个C用户，业务场景多是C用户付款给小B，平台获取佣金。之后如果商业关系发生变化，有一个代理商进驻平台，它可以从一笔交易中抽取佣金。如果是基于商业关系来设计，只要增加一个关系实体，比如一份合同，描述了平台、代理、商户、用户之间的关系，系统就会自动按合同来完成交易。
当然基于关系来设计系统模型会变的更灵活但也会增加复杂性。不只是交易系统、商户管理子系统，可能风控系统也要大改造。现在风控是基于主体的角色来控制交易，而之后会依赖商业关系来进行风控，这些都是巨大的变化。更重要的是从公司战略层面看，第三方支付公司的主业从支付、交易转向了商业关系的维护。支付从物物交换到贵金属、纸币、电子货币、数字货币，支付形态不断变化处理方式也不断变化。相比支付形态的变化，支付背后的商业关系永远存在。这也是我个人认为这种转型重要的原因。
大约十年前我还在国内一家专业做预付卡交易处理的公司做开发。当时支付宝的一位总监来我们公司谈合作。他说：支付宝的未来目标是要取代现金。我当时觉得他的口气好大，现在十年过去了，电子支付已经非常普及，钱包已成了过时的东西。所以十年之后数字货币或许可以取待现在的电子支付，这种转变对当下的三方支付公司而言影响是巨大的。因为数字货币的本质就是要取代中心化的交易，这是要革三方支付公司的命。目前中国的数字货币并不是完全去中心化的，按现在央行对数字货币运营流程的设计，是央行与金融机构双层运营体系。央行把数字货币发给金融机构，金融机构再兑换给公众。支付公司属于准金融机构能否获得这一资格难讲。可能微信、支付宝这样头部的支付机构还有机会。而现在的数字货币的费率是万几，不可能支撑现在支付公司的运营成本，个人认为未来支付公司一定会转型。这可能就是未来第三方支付公司一个发展方向，成为商户关系维护机构，帮助商业机构快速解决交易场景问题。在交易的同时完成各种商业关系与利益的计算分配然后获取服务费，而不是依靠交易规模收取手续费。
这种模式需要在支付环节能够关联更多的服务。支付公司提供能力越多，可以接入的商业关系越多优势也就越大。比如：银联、银行的营销活动……寻找各种可以合作的商业伙伴，比如银行、基金、消费金融机构、SAAS服务商……SAAS服务商即是我们的客户也可以是我们的合作伙伴。支付公司可能会转变为各种资源的整合机构。这或许就是支付公司的转型方向，当然也会成为产品、系统设计的方向。
经验与教训最后谈一些我所经历的经验与教训。
客群定位要准确支付SAAS面临最大的挑战就是客群的定位。SAAS服务是要挑客户的，因为SAAS的价值就是提供通用产品与服务，可以复制拓展给一批同类客户使用，以降低前期开发成本提高边际收益最终实现盈利。如果客户比较散产品就很难聚焦，这是一个比较头大的事情。
不要贪多求快刚上线阶段要保障基础功能有很好的体验，不要堆叠新功能。比如提供了对外的API接口，但没有人维护站点商户对接一步一坑。如果不能保证功能的体验会影响产品的口碑，2B的产品这一点很重要。体验差这还是小事，我之前任职的支付公司系统刚上线，就试图全面开花接入各种场景，开发人员爆增开发成本爆长，摊子铺的太大亏损严重。但刚上线的系统难免有各种问题，一时又没有找到好的场景打造出爆款产品，结果公司人事动荡。投入太大成本快速增长会影响到公司的运营，即使你有充足的资源也会有很大的风险。
需求管理个人认为对需求的统一管理分析是有助于产品迭代的一项好措施。这里的需求不仅是指商户需要的功能，更重要的是需求背后的利益诉求。相比功能的变化，利益的诉求要稳定的多而且更普遍。比如：电商场景中有大量的交易需要延时分账，我们的实现方式是为商户建立中间账户，管理延时分账交易的资金。这种中间账户不对外开放也不可见，但电商的财务说他们要能查看延时账户中的资金余额。我们增加了余额查询接口的功能，支持了中间账户。其实更深层的分析这个需求，背后是对电商这样的拥有大量在途资金的客户都会有在途资金管理的诉求，我们应该如何深挖这样的场景把体验做好。再举个例子，一些平台需要我们提供电子回单用于证明一笔交易发生或存在。平台需要向他的小商户提供这些电子回单。对商户而言这是斗拱系统提供的一个功能，而这个功能的背后是第三方支付公司对交易背书与证明，与银行提供的回单是同样的性质。支付公司不只是提供交易还要提供交易甚至资产的证明，这也是可以深挖的需求。当我们深度分析这些需求之后就可以在产品规划、系统设计中做预留，而不是不断地打补丁。
内部培训支付系统是庞大复杂的，很多产品、开发leader各管一摊，很少有人能把控全局，更别说销售了。所以需要有系统架构图、产品能力地图，以及不断地内部培训，包括销售、产品、运营、运维等各角色的专门培训。
以上就是这些年工作经验的简单总结吧。
,
