笔者围绕自己的两段工作经验——TO C的第三方支付公司，TO B TO C的医疗信息化公司，展开了产品经理需要不需要懂技术的分析讨论。

从事产品工作好几年了，依然没有成为产品大神，仍然是一个产品菜逼，所以以下观点都是个人胡扯，参考价值待定，只是从自身的角度出发，总结而来。

最近又看了一遍《给产品经理讲技术》，原来是通过公众号推文看的，不如书中的篇章排列。同时，在微信群中，有作者的前同事又组织了一波该书的分享，群中多人从自身经验出发讲述书中的一些篇章。通过语音的收听，对该书的认识又深刻了一些，同时，也生出一些感慨，为什么同样是产品经理，别人可以对技术如此有想法和见解，竟然如此优秀，深刻认识到了自己与优秀之间的差距。因此借着刚看完该书，尚有一些模糊记忆，来探讨产品经理需要不需要懂技术这个话题。

产品经理听这名字好像很高端，然而却不是经理，手下不一定有人，要做的时候却很多——从产品的孵化，到产品的落地及运营，各个阶段都需要参与，并且不仅能和需求方撕逼，更要与开发舌枪唇战，做的很多，又有点杂的样子。

但是因为《人人都是产品经理》这书，导致人人都觉得可以胜任产品经理。

有段子说：去互联网公司面试，面试官问：你会什么？答：什么都不会。面试官说：很好，来我们公司做产品经理吧。

所以很多人都去转产品，毕竟提意见和需求，看起来谁都会。而我也是这样子入门的。做产品好几年，一路走来，从产品菜鸟变成了老菜鸟，同时经历了两家不同类型的公司，TO C的第三方支付公司，TO B TO C的医疗信息化公司。通过两家公司工作的对比，来看产品经理需要不需要懂技术这个话题。

一、TO C的支付公司

TO C的第三方支付公司，业务说简单也挺简单的，就是银行卡收单，说复杂的话也挺复杂，交易规则特别多。先看下图的整体架构，因为原先的公司做的产品都是TO C的产品，所以我这边就画了入口为C端产品。

前端产品与业务系统进行交互，根据制定的业务规则进行交易，发生的交易上送到收单交易系统通过交易路由和支付引擎与清算机构发生交易，由银联或者网络对交易人的银行卡或者相关网上账户进行扣款。

当交易发生后，通过清结算系统进行相应的D+0、T+1等清算对账，进行对商户的结算，通过代付系统，向存管银行发起代付指令，把相应的钱付到商户的账户里。

而风控系统通过风控引擎和风控规则，通过对交易的监控，来发现风险商户，以及更新风控规则。

报表系统则是汇总业务系统和收单交易系统中所有的交易数据，进行数据的清洗、筛选和渲染，进行数据分析，总结业务和营销得失，来反过来支持业务。

因此通过上述描述，可以知道，这业务的流程还是比较直线清晰的，完成业务的系统处理一般都是线性下去的，同时网络方面，因为就用户的产品是互联网，内部都是内网，银联网联都是专线，网络也比较清楚。

所以在这里面当产品经理，就我个人来说，对技术的理解没什么必要，每个系统有每个系统的产品经理，同时以业务驱动为主，底层的清算和代付及支付的逻辑是通用的，更重要的是业务和逻辑的理解。

接下来，来拆解下业务系统来支撑我上面说的业务和逻辑的理解，还是先看下业务系统的整体架构。

底层服务这块都是由开发人员和技术人员自己搞定，所以产品经理更多的是专注于业务系统和收单交易系统，而清结算系统、代付系统等更多面向内部、且变动较少，而且我也较少接触，就不在这里描述。

看业务系统的这些组成：会员系统、库存系统、返佣系统、套餐管理、代理商平台、运营管理、业务管理、账单管理，这些更重在的是设计，设计业务规则、业务逻辑，基本上不用了解什么技术，只要你思路清晰、逻辑明确，能够理清楚前端业务，把业务转化成一些可配置、可视化的页面，就可以是一个很好的产品经理了。

再来看收单交易系统，灵活展业平台、商户池、支付引擎，收单交易系统是核心，要做支付都得这来支持。而这里面最多的也是规则，展业规则的配置、商户池跳码规则、商户轮询规则、基础交易规则、选择哪个支付渠道。

因为支付机构牌照的限制或者高风险区域的存在，所以需要灵活进行展业设置，也是个可视化的配置，这过程无需懂技术也可以设计好产品。

而跳码、轮询商户、支付渠道选择、基础交易规则这些更是要懂业务和逻辑才行，意味着一笔交易从开始到完成的通路，里面也不怎么需要技术知识。

再来看看业务链路。一笔交易从APP端发起时，到这个完成，里面提到最多的就是规则和业务，大部分都是规则的调用，且因为系统都是内部系统，按照规定的规则通路就可以走下去。业务链路也和上面的业务系统架构相对应，是业务逻辑和规则的体现。所以在我自己认为，要设计好这个业务，技术非必须，需要的是产品经理去深入了解业务，业务之间的结构和耦合，规则之间的逻辑和共存、串行还是并行，需要的是把流程图梳理得清楚，业务涉及的规则罗列清晰。

所以，根据我自己的经验，在TO C的第三方支付公司里，成为一个好的产品经理，技术不需要了解，更多的是要理解业务，有着清晰的逻辑思维，能够理清楚各种规则，以及制定出各种灵活适用的规则，对政府政策、公司内部业务政策熟悉，具有数据敏感度。

二、TO B TO C的医疗行业

接下来讲讲我目前所在的行业，TO B TO C的医疗行业。TO B是因为客户是医院或者区域政府，TO C是这产品最终使用者是医生和患者等普通老百姓。

所以产品要满足客户的刚需，同时需要要好的用户体验，当然客户的刚需是硬性要求。

因为行业的特殊性，所以相关的产品也是不同于C端的产品，仅仅需要考虑好用户体验就行的，涉及到方方面面，需要比C端多了解不少知识。

1. 网络

医院看病，涉及到普通用户、医院，同时有些服务涉及到卫健委及医保，这就是四方了。所以设计一个产品时，很可能四方都需要进行相关的访问。

信息化嘛，普通用户，肯定是使用互联网来访问相应的服务的，但是医院为了保护内部信息的安全，大部份的服务都是只能通过医院内网访问的，同时，用户如果做医保业务的话，又要访问医保服务，医保又只能通过医保专线访问，而访问卫健委相关的服务，又要通过政务网访问，所以做一个业务就可能涉及到四种不同的网络，并且这网络之间可能存在多种访问路径。

如果不懂一点网络知识的话，那么设计的产品去找开发交流，那么会被鄙视的体无完肤，会完全不知开发和项目经理所云何物。

要不要专线，专线是做什么用的，走互联网区还是走政务网，以及不同网络之间怎么访问，开发一堆问题抛出来，说这个服务网络间不通不能做，因为啥也不懂，就算被忽悠也无力反驳，只能GG了。

2. 系统

医院的系统可谓是多，HIS、LIS、PACS、EMR、EHR等等，少的七八个，多的十几二十个系统，而做医院信息化，免不了和这些系统打交道，一个产品和其中几个系统有交集，同时自己产品内部可能也会涉及到有两三个系统，这复杂程度就上去了。

医疗信息化，有个特点就是，很多时候前端页面其实不多，但是后端服务很多。不像支付产品，走的流程很顺，一条线走下去。

医疗信息化，多个系统在一个服务中可能存在相互间藕断丝连的关系，纠葛在一起，来来回回。

对内：

产品经理如果停留在前端设计界面和流程的话，因为不清楚自己公司的后端各个系统的交互，设计出来的产品，在内部开发间就没定义清楚是哪个组来开发，那么到时候就是开发要自己梳理，几个组的开发来问这东西是我开发还是那东西是我开发，那么开发对产品的鄙视就进一步加深了。有时候没定义清楚，哪个组都没做，等到要上线时，发现少某个功能，那就欲哭无泪了。

对外：

因为产品涉及到医院很多已有的现成系统，肯定要这些系统提供能力。这时候产品经理又承担着外部对接人的角色，需要梳理清楚要医院现有系统提供什么接口，医院哪些系统需要改造。

因为医院现有系统改造，都涉及到改造费用，所以对外时，需要梳理清楚，哪些是需要的，哪些提供了有没有用。

不懂技术的话，对方扔个接口文档给你，还要找开发看有没有自己需要的，或者医院让你说清楚各个系统间怎么进行交互，提供服务，如果仅限于前端页面的流程，那么这一步也说不清楚，会被留下不专业的印象，也容易被忽悠，或者对方提供的接口方式不是自己系统这边需要的，明明要服务端接口模式调用，提供个JS调用文档给你，那也是对对接工作很不利的。

3. 个人真实体验

之前自己在支付公司做产品也是懵懵懂懂，不怎么了解技术，所以到现在的公司时，开始阶段经常碰到很懵逼的事情，比较吃力。

有次去医院和客户交流一个支付相关的事项，当医院问这支付相关的消息怎么推送到医院公众号上。以我原先的经验，往公众号、APP推消息，不就是后台系统发布消息，前端接受消息就好了么。所以我说到时候把消息推给公众号就好了。但是医院又问怎么推，以及公众号去取行不行。

这时候开始懵逼了，按照原先C端那套行不通。后来才知道，原来别人要的是公众号开个接口来给我们系统推啦，还是我们系统开个接口，让公众号来轮询消息推送，这就和技术有点关系了。

同时自己经常碰到要对接外部相关的支付渠道时，原来简简单单不用理会什么支付方式，反正系统开个接口给前端APP调用就行，也不用管APP支付还是H5支付。

现在却经常碰到，对方抛个接口文档过来，有时候是H5接口，有时候是SDK的，这时候产品就要关系这个东西在各种APP或者微信公众号里能不能调起，怎么调起，还得了解下微信小程序web-view是怎么回事。

反过来，当对方要自己这边提供能力时，内部输出的H5或者SDK文档，要能够说明白给对方听，为什么是H5的，是APP SDK还是服务端SDK，这为什么需要这种方式提供。我的天，这些在C端时，都不会碰到这些问题的。

所以以我目前的境地来说，懂一点技术还是好的，这些不管是对内还是对外，许多点都能够更加清晰明白，至少开发抛出个名词能够理解，或者少被开发忽悠。

但要不要理解很深，这个就无法下结论了，毕竟自己在目前的行业也只有一年经验。

当然技术、系统、网络，也可以当做是对名词的理解，了解其中的作用，明白能够干什么的，也是能够做到游刃有余。

那么说回标题：产品经理需要不需要懂技术。

在个人认为学习屠龙技，虽然没有龙屠，但是也可以吹吹牛逼，万一哪天有龙屠时，也有可能成为屠龙勇士。技多不压身，多掌握一点技术，多点生存之本，即使搬砖技术也不例如，也许哪天就真要搬砖了，早学习早上岗。

屠龙技也好，搬砖技也好，总归是自己的才是好的。

最后，引用下狄更斯的：

这是一个最好的时代，也是一个最坏的时代；这是一个智慧的年代，这是一个愚蠢的年代；这是一个信任的时期，这是一个怀疑的时期。

这是一个光明的季节，这是一个黑暗的季节；这是希望之春，这是失望之冬；人们面前应有尽有，人们面前一无所有；人们正踏上天堂之路，人们正走向地狱之门。

本文由 @夜月沉星 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议