平台型产品功能设计的需求抽象与升维适配|专访宜信郭建伟

嘉宾 | 宜信郭建伟

记者 | 宜信成芳

本文为采访实录。原创内容，转载请留言获取授权。

郭建伟：正好在宜信的这段工作经历中，参与过一次公司战略级的业务模式创新项目——火凤凰项目，将网贷业务中间人模式升级为直接借贷模式。有一些经验体会可以分享给大家：

首先，要明确自身在项目中的定位，目标清晰。通常业务模式升级类项目都是公司级项目，参与部门比较多，产品团队和技术部门虽然是落地过程中最重要的一环，但一般还会涉及公司内一系列系统外的工作推动，甚至外部合作方、监管机构的协调，往往不会由产品团队或技术部门来主导，所以要明确自身在项目中的角色，充分理解项目的业务目标，转化成具体的系统建设目标，并以此在项目前期和需求方达成一致，这是明确项目范围、管理预期的关键，也是系统建设的基础；

其次，是对旧业务模式、历史数据的兼容问题。在重大业务模式升级的项目中，对于平台型系统而言这是关键问题之一。这个方面我有两个体会：

1、要进一步细分兼容问题的类别，缩小范围、制定差异化解决方案，来降低兼容问题的复杂度、工作量。参与过类似项目的同事应该都会有这样的体会，对旧模式兼容、历史数据处理的工作量，完全不亚于投入在新模式建设上的工作量，所以作为负责人，优先考虑的不是“硬刚正面”，而是“战略性回避”，适当拉长新旧过渡期，在项目既定周期内，让团队聚焦新模式建设，为后续存量处理留出工作空间即可；

2、与业务团队沟通讨论，充分挖掘业务方在存量处理上的作用。技术团队往往第一时间考虑的都是技术解决方案，但在存量处理的问题上，处在更上游的业务方的一些小变通，往往能给我们提供非常有效的支持，不要一味只在下游、自己熟悉的范围内寻找解决方案，最优方案往往需要上下游协同。

最后，是试点支持的重要性。不论业务方是否要求试点，不论对自身研发、测试团队的能力多有信心，我的建议是面对大型业务模式升级，对试点功能的支持都是必不可少的。在IT层面，是对系统功能升级的验证，控制影响范围、监控性能问题等；在运营层面，新模式一方面平滑推广，一方面在逐步推广过程中，会持续调整，推广的过程也是一个收集反馈再升级的过程。

郭建伟：我认为面向C端的业务产品经理最重要的是“对客群理解”，核心工作内容是通过产品的调整，增加“客群”与“产品”的匹配度。客群的特点与痛点是C端产品经理工作围绕的中心，并以此调整自己的产品；相反固守自己产品，而去不断教育用户、创造需求，成功的例子并不多。另外往往我们的产品经理并不是自己产品的目标客群，跳出自己的认知习惯，去精准把握另一个群体，是C端产品经理的重要能力。

B端平台型产品经理最重要的是“对业务的结构化理解”。这是我个人的一个说法，从这里能看到两个层面的含义：一个是要对某“业务”领域知识足够熟悉，这是平台型产品经理的工作前提；另一个是“结构化理解”，也就是抽象能力，需要我们具备基于对业务流程的认识，抽象为对业务模式的结构化理解，这是平台适配性、扩展性的关键所在，是平台型产品经理的关键能力。

郭建伟：我认为“科技赋能”要根据不同业务所处的不同阶段，采取不同的“赋能”方式，大家常看到由于技术落后业务发展进程而产生的问题，而容易忽略技术过于超前同样会引发问题。

一般情况下，我把“赋能”分为多个阶段：

1、支持阶段，这个阶段一般在业务的起步期，业务流程不稳定，需求变更较多，系统的按时交付、保障业务开展是这个阶段的关键。

2、提炼阶段，这个阶段一般业务进入发展期，业务流程逐渐稳定，平台建设的技术团队对业务形成一定理解，进入对业务抽象提炼的阶段，这个阶段的目标还是通过对业务的理解、抽象，更好地建设系统，以适应业务的发展，着眼点还在系统提升本身。

3、赋能阶段，这个阶段业务已经持续发展，业务量稳定，业务本身促进增长方面出现瓶颈，需要技术不仅仅是在效率、自动化方面支持业务，而是基于对业务的理解，直接着眼业务，结合技术手段做出改进提升；

4、引领阶段，我认为并不是每一项业务都适合、或都能够进入到技术引领的阶段，处在这个阶段时，将打破“业务”与“技术”的边界，技术变革做出的引领，本身就是业务的一部分。

郭建伟：我一直反复地和团队的平台产品经理强调一句话：系统建设不是照搬业务流程实现自动化的过程，而是先对业务流程做抽象提炼，再去反向适配具体业务需求的过程。这个认识也一直指导我在宜信的每一个系统建设工作。

抽象能力无疑是平台产品经理最关键的一项通用能力，谈抽象能力时，我常提的一个通俗例子就是“客户要一匹更快的马，我们应该给他一辆车”。这个例子中，一方面体现产品经理对客户真实需求“更快到达”的挖掘；

另一方面也体现了抽象作用，之所以从“要马”到“给车”，中间其实是有一个抽象升维的过程，就是抽象成“交通工具”，再从“交通工具”降维到“车”，这恰恰就是上面的“先抽象提炼”再“反向适配具体业务需求”；

另外这里我还强调我们能顺利完成抽象、适配，其实还得益于我们对“交通工具”领域常识的了解，如果这个例子换到医疗领域“客户要某药品A，我们应该给他另一药品B”，如果我们不具备病理、药理的领域知识，就无法完成抽象、适配。所以“业务领域知识”+“抽象能力”都是平台产品经理的重要能力体现。

郭建伟：前面提及了C端产品经理和B端产品经理的区别，这里我简单谈一下我对用户体验的理解。

对于平台型产品而言，谈“用户体验”时，我们谈的并不是界面美观与交互流畅与否，而应该是“用户是否能更便捷达成他的期望”，所以“用户的期望”才是用户体验的核心。

举个简单的例子：一个界面美观、交互流畅、动效酷炫的纯手工功能，和一个界面粗糙的自动化功能，对于B端用户来说，会毫不犹豫选择后者，因为那更贴近他的“期望”。在这个理解的基础上，再去考虑提升界面美观、交互流畅等，这是B端产品经理应该注意的。

郭建伟：中台建设我并不专业，宜信科技中心有团队专注这个领域，我简单说说我自己的一些认识。

首先，中台概念的兴起是和业务量级密不可分的，并不是所有业务都需要中台，为了建设中台而建设中台是没有意义的；

其次，中台是和组织结构有关联的，中台建设本身也在促进“组织分层”，以便进一步在各层配置不同的能力模型和资源，各层或分散、或集中，达到提升组织整体运营效率的目的；

最后才是系统建设方面，避免重复造车轮，增加系统共用，降低成本，加快业务需求交付速度等等。

郭建伟：B端产品经理的工作相比C端产品经理工作，有些枯燥，所以

首先大家要有耐心，不断学习积累。

其次，要加强业务领域知识的学习，行业领域知识对B端产品经理的重要性，要高于C端产品经理，择业时尽量注意在某一大领域内选择；

最后，不论是哪种产品经理、哪个行业，产品经理都应该是善于发现问题、解决问题的那类人，所以保持好奇心，勤于思考，提升商业敏感度是非常重要的。

希望大家除了在自己工作中是个合格的产品经理之外，动用产品经理赋予你的种种，让自己在“职业道路”、“人生道路”这个产品上，也能成为一名合格的产品经理。谢谢大家。

⭐️⭐️⭐️欢迎加入“宜信技术交流群”。进群方式：请加小助手微信（微信号：18910316664）。

如需转载请与小助手（微信号：18910316664）联系。发现文章有错误、对内容有疑问，都可以通过关注宜信技术学院微信公众号（CE_TECH），在后台留言给我们。我们每周会挑选出一位热心小伙伴，送上一份精美的小礼品。快来扫码关注我们吧！

⏬点击“阅读原文”查看更多技术干货