​东瓶西镜同学：深度拆解产品架构设计的相关方｜李宽wideplum

公司在3月初通过立项，形成决议，要在下半年完成供应链金融平台的搭建，该建设平台按照规划包括多款产品，第一款产品由我的一个同事负责，已经在6月底了完成了上线，她现在负责迭代优化工作。

现在要进行平台的第二个产品设计，由我独立负责，从0到1进行新产品的搭建。

当然，我背后有一个在中信银行工作近10年的产品老鸟来做把关，同时，我们公司总裁也是近二十年的金融资深人士，我虽然是一个半吊子工程，不过，守着这么好的资源，不好好学习实在是可惜。

因此，我也准备将平台搭建过程中的产品经验，总结记录一下，写个系列文章，用来丰富和强化知识记忆。

这个系列主要针对产品设计中的有价值的信息，包括通用的产品设计经验、金融产品的专业知识、过程成果文档的分享以及一些评审沟通会或者领导对未来产品的规划或者思考。

总之就是围绕着供应链金融产品这个核心，在搭建平台的过程中，对于产品有帮助或者有启发的事情，全部记录下来，既强化知识的积累，也希望能有一些思考能帮助到同路人。

闲言少叙，今天的主题是：在进行产品架构设计时，有哪些容易被忽略的相关方。

产品架构设计的相关方

我们都知道，做产品设计第一步先是需求收集，针对业务需求，进行业务调研和可行性分析，确认目标用户并进行用户画像，收集并梳理用户需求，然后再进行产品架构设计、业务流程设计、逻辑功能设计，原型设计与需求说明书的编写，组织需求评审，跟进开发与测试，进行产品验收测试，上线跟进，需求优化迭代等等，这是基本的产品设计流程。

不过呢，因为之前已经针对新产品做了一定的需求收集和业务调研，也做了竞品分析，基本确定了两个产品方向，一个是针对电商平台的预付款融资的供应链金融产品，一个是关于产业园的仓单融资，接下来的工作是针对这两个方向，最终定下来一个作为新产品来设计，那接下来的节点工作，首要便是进行产品架构设计，输出产品架构图并组织架构设计的评审。

这里多分享一点，我一直觉得产品设计树立节点思维很关键，比如，前期的需求调研时就以需求调研报告为关键节点，形成了需求报告就意味着需求调研内容的关键里程碑的建立，评审需求报告就意味着需求调研的结束。

很多同学会说，不都是这样吗？其实，不然，有里程碑意识，用预期结果倒逼自己做好过程管理，我觉得是一种产品思维。我身边有很多同学总喜欢早点进入内容设计，上来就要做需求调研的具体内容，既没有列举计划清单、依次推进，也没有完整的《需求调研报告》的评审作为结束节点标识，眉毛胡子一把抓，反正是调研了，你一问具体的调研事项，有些都清楚，但没有系统化整理，始终会忽略掉很多信息。

如何避免忽略相关方

在进行架构设计时，有些相关方极易被忽略，这里有几点经验分享一下，仅做参考：

第一，单独的产品设计一定要符合平台产品的架构规划。

前文已经说了，这个将要设计的独立产品属于我们公司供应链金融平台中的一个，而平台有多个产品，那新产品就必须要先结合整个平台的架构规划，单个服从整体，这也是很多产品经理在进行类似的设计时，容易忽略的，总想快速进入产品设计，殊不知，前期的方向把控十分关键，一旦与整体平台定位有偏差，就容易造成不可预测的沉默成本，平台的价值就会大大偏差。

黄奇帆老师讲到，金融本质要从三个层面来看待，一是为有钱的人理财，为缺钱的人融资；二是，信用，风险和杠杆；三是，金融一定要为实体企业服务。

以供应链金融产品来说，众所周知，供应链融资基本就三类，一是应收账款类融资，二是库存融资，三是预付款融资，我们平台的定位是一揽子的综合服务商，平台下面有三条产品线，包括数个产品，比如，我们已经上线的产品就是保理融资，而结合平台的定位，我们要作为运营平台，解决信息不对称问题，并且平台是不能触碰资金的，但要考虑信息流，实现“四流合一”。

不怕大家笑话，当我组织产品经理内部评审我的初步产品架构时，就有好几点忽略了平台的定位，比如，其中我就考虑了搭建账户体系进行线上支付结算，实际上，对于我们的平台来说，前期是不具备线上管理资金的应用可能的，这就是单纯的考虑单个产品，忽略了整个平台架构所导致的方向偏差。

第二、要结合业务场景并且要让业务人员提前参与进来。

产品一定要服务于业务场景，这个大家都很清楚，要实现这个战略目标，我觉得有两点很关键：

一是，前期一定要实地调研业务需求，将自己的理论知识和业务场景结合起来。

比如，我在设计之初，结合我以往的工作经验以及从网上搜集而来的大量资料，做了高层级的产品架构设计，唯独忽略了去调研业务场景，结果犯了不少错误。

举了例子来说，我们的金融产品主要服务于钢铁领域，核心企业可能是钢铁厂，也可以是钢铁电商平台，其中有个产品功能，最初我设计的是钢铁厂要和银行签订回购协议，结果去现场调研才发现，在钢铁行业，钢厂属于强势企业，根本不可能签什么回购协议，据说，排着队付全款都不一定卖你钢材。

所以，你看，如果我没有去实地调研，去沟通交流，那我的产品大方向就会错，后续影响就会很大，就容易产生很大的沉没成本。

二是，一定要让业务人员提前参与进来。

明白了理论和实践相结合，未必能做好架构设计，未必就一定能把准产品的脉，因为，术业有专攻，产品对于业务的理解不一定到位。

这一点也是踩过坑之后深有感受，最初我想，新产品要服务于客户，要让供应商（借款人）使用的舒心，体验性好，产品经理都有用户思维嘛，在这个认知驱动下，我对产品架构的设计便倾向于金融需求方，替他们考虑很多，比如，在授信管理上，考虑落地便捷性就多于风控严谨性，结果一直到后期，产品架构快成型的时候，我让业务总监一看，人直呼我外行。

金融产品更多的是要考虑流动性提供方，也就是资金方（银行、保理公司等）的需求，他们关心的首先是风控和合规，那相应的设计就需要调整。

所以，前期一定要多和业务人员交流，将自己的产品专业性和业务人员对场景理解的专业性，相结合起来，才能最大限度避免产品误差。

第三，需要结合公司技术现状，并且提前让技术架构师参与评审。

B端产品一个很重要的特征是客制化，几乎每个场景都不完全一样，尤其是对于供应链金融产品来说，本身就是场景金融，每个不同的应用场景，可能都需要定制化开发。

那这就需要建立中台系统，将公共服务的产品进行中台化处理，从而降低后续开发成本，提高市场试错效率。

在这方面，我其实犯了两个错误：

其一，在设计产品架构的过程之中，没有考虑技术的可行性，也没有同技术架构师进行请教和沟通；

其二，在产品架构评审时，也主要是在产品内部进行，业务同事有参与，但我起初竟然没有通知技术总监，还是在开会时，领导让我通知技术总监参与评估，果然，对于类似于“授信管理”、“额度管理”、“协议管理”等公共模块的中台化设计，需要技术提前做很多的规划与工作，并且，与已经上线的平台另一个产品也存在调整的地方，都需要提前考虑。

所以，对于产品架构的评审的认识要到位，由于是方向性、纲领性的设计，那就需要提前进行业务规划、技术规划，一定要提前进行跨部门沟通，最好在设计过程中就参与协作，切忌产品独狼行动。

第四，要考虑公司的战略定位。

每个公司对于新产品都有相应的战略定位，产品的设计一定要服从公司的战略定位，这一点也是我忽略的。

最初，我完全是按照市场化产品来进行的产品设计，在设计一周后，我在向领导汇报时，领导对几个产品功能的定义都不满意，因为公司对产品的定位首先是服务于集团的产业，首先要在电商交易平台板块、产业园板块得到应用，对我们的公司的定位是赋能部门，而非利润中心，那产品定位就需要找个平衡点，要在集团内部应用和市场化发展之间找个平衡。

显然，我只考虑了市场化，忽略了公司的战略定位，之前领导发我的产品资料里面，其实是有这一块的内容的，我想着只是公司的介绍资料，就没有在意。

实际上，任何公司产品的定位都需要保持同全局的战略一致性，产品经理在主导产品架构设计时，如果有更高的高度，同公司或者集团的战略高度保持一致，这样就会有更好的竞争优势，产品方向也更不容易出错。

第五，要结合公司的事业环境因素。

事业环境因素（EEFs）是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。这些条件可能来自于组织的内部和（或）外部。事业环境因素是很多项目管理过程，尤其是大 多数规划过程的输入。这些因素可能会提高或限制项目管理的灵活性，并可能对项目结果产生积极或者消极的影响。

我想说的是，对于设计产品架构来说，容易忽略掉的事业环境因素，主要是指产品开发团队实力现状和时间进度要求。

很多时候，我们产品规划时，考虑的都非常全面，但是，却容易忽略技术实力现状，导致很多产品设计都无法落地，有时候就会陷入沟通死循环里：产品就是这样设计的，你们开发这样做就行了，可在开发看来，现有的人员根本不具备这样的实力，所以，脱离技术现状，单纯的认为产品来驱动开发来讲，并不是有效的解决方案，架构设计时，一定要结合公司的开发团队实力。

还有，为了适应市场的快速变化，很多产品都是敏捷开发，甚至边设计边开发，对时间要求很紧，这就要求产品设计的全面性，要与不同时间节点匹配，如果时间有限的话，就不能设计的过于细节，这样不利于整体的产品进展，比如，我在规划产品的授信管理时，最初考虑的有多级工作流审批，而且工作流可以定制配置，这样确实体验比较好，但对开发时间要求比较高，在和技术沟通后，决定前期先做成静态的，不做成动态配置的。

所以，产品架构设计离不开公司的组织环境因素，脱离开客观条件，不考虑技术落地性，一味地拔高产品的定位，哪怕是锦绣山河，也只能让人望而却步。

总结

上面几点就是我在产品架构设计时，踩过的坑，事实上，最大的感受便是，产品经理一定要把自己定位成开发系统，不能关起门自己闭关修炼，想着一朝做出优秀的产品惊艳所有人，这有极大的难度，要多利用身边的资源，产品的相关方尽可能考虑周全，必要的话，都让提前参与进来，只有调动相关方，聚焦并服务于产品，才有可能设计好产品架构，才能尽可能避免产品的方向性偏差。

产品架构设计其实就是对于产品方向的决策制定，优秀的产品经理应当是个出色的指挥官，正如《史记》所说：夫运筹策于帷幄之中，决胜于千里之外 ，吾不如子房；镇国家、抚百姓、给饷馈、不绝粮道，吾不如 萧何 ；连百万之军，战必胜，攻必取，吾不如 韩信 。三人者，皆人杰也。吾能用之，此吾所以有天下也。

但愿你我，都能早日“大风起兮云飞扬”。

作者介绍：

东瓶西镜同学是有七年经验的互联网产品总监，现任某集团公司金融产品总监，文笔洒脱，擅长辅助，他在产品大峡谷等你集合打团。

—— 如果觉得文章还OK，请转发 ——

特别提示：关注本专栏，别错过行业干货！

PS：本司承接 小红书 / 淘宝逛逛 / 抖音 / 百度系 / 知乎 / 微博/大众点评 等 全网各平台推广；

咨询微信：139 1053 2512 (同电话)

首席增长官CGO荐读：

• 《首席增长官 – 增长黑客 Growth Hacker》
• 《小红书 – 增长黑客 Growth Hacker》
• 《视频号 – 增长黑客 Growth Hacker》

更多精彩，关注：增长黑客（GrowthHK.cn）

增长黑客（Growth Hacker）是依靠技术和数据来达成各种营销目标的新型团队角色。从单线思维者时常忽略的角度和高度，梳理整合产品发展的因素，实现低成本甚至零成本带来的有效增长…