在产品管理领域，技术知识的重要性一直是备受争议的话题。一方面，有人认为产品经理的核心职责是理解用户需求和市场趋势，技术细节可以交给开发团队处理；另一方面，也有观点认为，不懂技术的产品经理在与开发团队沟通时会面临诸多障碍，甚至可能影响产品的最终质量。本文将深入探讨产品经理是否需要懂技术，以及如果需要，应该掌握哪些技术。

这是一个产品经理领域老生常谈的话题，知乎上也有相应的话题，大约有660+答主回答了该问题，问题关注者1.5万人+，问题浏览量超过234万。

2019年6月我在博客上简单写过一点自己的理解(后来因为访问不了godaddy解析不了新iP，博客算是废了)，时隔6年我在原文的基础上扩充一些发在公众号上面。

1.产品经理要懂技术

首先给出我自己的观点：产品经理要懂技术。原因如下：

我了解的很多程序员都会有一种“习惯性拒绝”，当你提出一个稍稍复杂的需求时，他可能会觉得麻烦或给他加了工作量而随口拒绝。

而他给出的理由往往是：接口查询过多影响效率、数据表结构不支持扩展、当前系统架构耦合较高、我们不具备XXX能力，XXX三方平台的接口不支持等。

这个时候如果您懂技术，就可以和他正面撕逼。而我们平日做的项目有些是由乙方/丙方多方协作来完成的，如果你懂技术，就可以大致了解他们提供的项目工时和方案是否靠谱，避免被忽悠。

产品经理会技术，等于流氓会武术。

前百度产品副总裁、首席产品架构师俞军前辈给出的答案是下面这样的。

• 不同业务的成功关键可能是技术/产品/运营/销售/投资等不同点。
• 一个业务的不同发展阶段，上述关键点的重要性也可能变化。
• 作为一个创业小团队，团队成员对“产品经理”的定位和期望，很重要但也会影响答案。所以，要结合你创业的领域和团队寻找答案。当然，即使非技术出身，做上产品经理后，该领域的技术你也应该是越来越熟悉，避免在做产品决策时拖后腿。

再来回答第2个问题：产品经理要懂哪些技术？

这个问题其实上面俞军的观点里面已经给出了答案：需要懂你当前行业/领域的技术，比如支付产品经理和硬件产品经理的技术栈要求就不一样。

再引申出第3个问题：技术要懂到什么程度？

做到这三点挑战，产品经理只会不断升值

好的产品经理是很稀缺的，懂用户、懂商业、懂数据的产品经理走出互联网，依然是抢手货。相反，如果只做简单传话、低效执行、浅层思考的产品经理，恐怕走不过未来3-5年的洪流。

查看详情 >

我之前写过一篇文章《领导是浅薄的全面，专家是深刻的片面》，我的观点是产品经理对技术要做到浅薄的全面即可。

为了让读者加深理解，我下面会用几个案例进行说明。

2.正则表达式

以下是某个电商平台的供应商入驻页面截图，当供应商输入手机号时系统会提示：请输入有效的手机号。

产品经理根据提示信息应该能看出前端校验时识别出195号段不是有效号段，但普通入驻商家可能不知道具体原因(虽然页面给出了提示)。

遇到问题就要解决问题，产品经理在提解决方案前需要知道问题出在哪，很大可能是开发同学在做前端校验逻辑的时候直接用了号段枚举，如130/131/133….188/189，而并没有用正则表达式。

别笑，我以前听过/见过的项目里面还真的出现过这种情况，出现的次数还不少。测试和产品同学在功能验收的时候，可能用的都是比较成熟的号段，所以新号段的覆盖不全，这个地方的BUG就没有测出来。

再有就是开发小哥的正则表达式可能没写好或者没写对，或者写的时候漏掉了几个字符，所以就会出现上面的提示。

手机号码通常由11位数字组成，以数字1开头。为了校验手机号码，我们可以使用正则表达式来匹配符合特定运营商号段的手机号码。

以下是一个常用的手机号验证正则表达式示例：

const phoneReg = /^1[3456789]d{9}$/;

const phoneNumber = ‘13800138000’

console.log(phoneReg.test(phoneNumber)); // 输出: true

这个正则表达式使用了特殊字符^和$来限制字符串的起始和结束位置。其中[3456789]表示手机号的第二位数字必须是3、4、5、6、7、8、9中的任意一个，d{9}表示后面跟着9位0-9的任意数字。

注意事项

• 号段更新：由于运营商的号段可能会更新，所以在使用正则表达式时需要注意是否包含了最新的号段信息。
• 虚拟运营商：此外，还需要考虑虚拟运营商的号段，这些号段通常以170、171等开始。
• 国际号码：如果项目中还需要处理国际手机号码，那么正则表达式可能需要进行相应的调整以适应不同国家的手机号码格式。

产品经理如果懂技术，就应该知道此处应该通过正则表达式的方式来做手机号段的校验，而不是通过号段枚举值的方式(毕竟号段更新速度太快了)。

产品经理如果技术懂的再多一点，就会跟开发提要求：我们平台有很多个业务场景都需要校验手机号(获取验证码)，手机号校验可以做成一个通用模块，这样后期的维护成本会降低很多。

3.注册页面的字段校验

下图是一个产品经理都很熟悉的典型的PC网站注册页面，在这个注册表单页面有4个字段需要校验，那么问题来了：这4个字段需要怎么校验？

有读者可能会说，这4个字段需要分2步校验，先校验输入的字段是否符合输入规范，例如中国手机号是1开头的11位纯数字，电子邮箱必须符合xyz@abc.com(或cn/net)的格式，密码必须不低于6位字符……

基本上所有的产品经理都能给出上述的回答，但这个回答只能说答对了一半，还应该考虑上述字段在前端还是服务器端进行校验。

前端校验

前端可以简单理解为用户可以看得见的页面前端，后端指用户看不到的服务器或系统后端。

前端校验顾名思义，就是该字段直接在前端页面先行校验。如上图所示，用户输入12开头的手机号(或者非数字1开头的数字如83)，这时前端应该立刻进行校验并提醒用户“格式有误”。

因为目前国内手机号都是以13/14/15/…19开头的，根本不存在12或者其他数字83开头的手机号，用户显然是输错了，如果等到用户输完了11位数字点击“获取验证码”时再进行校验，显然体验不好。

邮箱字段同理，如果用户输入ABC.或者ABC@XYZ这样的内容，显然这不是一个合乎规范的输入项，所以就需要前端即时校验并反馈。

前端校验的优点如下：

• 即时反馈：如手机号位数不对，号段不正确，邮箱格式错误。
• 减少无效请求，节省服务器资源。
• 格式校验：如邮箱/手机号格式/密码长度。
• 必填项检查：如用户名 / 密码未填写。

后端(服务端)校验

以上文为例，前端校验已经过滤掉了一些无效/不合规的输入，此时为了保证手机号/邮箱等关键数据的唯一性，此时必须要去后端(服务端)进行校验。

为什么要先做前端校验，接着才是后端(服务端)校验呢？主要原因是即时性、成本和体验3方面的因素。虽然前端的这些字段都可以拿到后端去做，但有些确实没有必要。

比如用户输入8位数的手机号和ABC@的邮箱，这种显然没有必要向服务端发送请求进行校验，前端凭”肉眼”即可把这些不合规的输入拦截掉，直接实时给出用户提醒：你输入的格式有误。

前端校验可以理解为第1道防线，后端(服务端)校验可以理解为第2道防线。

后端(服务端)校验的优点如下：

• 防御恶意请求：如SQL注入、脚本攻击。
• 确保数据一致性：如唯一性校验、关联规则。
• 执行敏感操作：如密码哈希存储。
• 绕过前端的非法请求：如用户禁用JS或通过Postman直接发送请求。
• 业务规则验证：如手机号/邮箱的唯一性、短信验证码有效性。
• 安全风险拦截：如SQL注入、XSS攻击、敏感词过滤。

前端校验是用户体验优化手段，不可替代服务器端校验。服务器端校验是数据安全的核心屏障，必须强制执行。

两者结合才能兼顾用户体验与系统安全。例如：前端实时提示格式错误，后端最终校验数据合法性并返回全局错误，如“用户名已注册”。

上述案例中，产品经理如果不懂技术，可能只会给出前半截的回答，如果产品经理懂技术，可能会给出较为完整的回答，也可以在跟开发测试沟通需求的时候，不会被他们牵着鼻子走。

开发同学如果在实现该功能的时候全部用了后端校验，懂技术的产品经理也可以及时指出并进行纠偏。

上述技术和原理，产品经理只需要知道整体的流程和逻辑即可，没有太大必要详细深究数据交互是POST还是GET方式，接口字段怎么传，哪些必传等等。

4.防欺诈盗号

以下是一个H5的活动报名页面，需要用户输入手机号和验证码进行报名。但是页面顶部的红色防欺诈提示确实有些吓唬人，这会让很多用户放弃当前操作，影响活动转化。

遇到这个问题，很多产品经理会直接拿着页面截图去问开发，但部分没有经验的开发同学可能也不清楚问题原因，于是产品经理就会继续在微信好友和业界同行中去咨询，或者去百度或deepseek。

其实这个提示是可以通过简单的设置去掉的，只要在你的服务号通过了支付功能的审核，然后将如下页面的域名设置到业务域名的位置，就可以去掉这个提示了。

我上面的这个例子可能比较简单，通过问人或者问百度大概率都能解决，但如果遇到一些复杂的棘手的问题，产品经理如果不懂技术，可能就束手无策了。

5.网站(页面)加载慢

比如你现在在做一个电商APP，很多用户反映商品列表页加载速度很慢，平均都要5秒以上，于是你给开发提了商品列表页加载优化的需求。

那么问题来了：需求内容应该怎么写？

有些产品经理会说将商品列表页的加载速度优化到2秒以内，over。但部分不靠谱/不负责/没经验的开发同学可能会直接回怼你：目前已经没有优化的空间了？阁下又该如何应对？

产品经理如果不懂技术，可能就会直接懵逼，或者直接跟开发小哥软硬兼施，或者去找开发领导/自己领导寻求帮助(告状)。

产品经理如果懂点技术，那么他就可以给开发小哥提出一些比较明确的优化思路和建议，参考如下：

1. 优化图片资源的格式：商品列表中图片或视频的大小对加载速度影响较大，因此在保证图片质量和清晰度的前提下，尽可能的使用高压缩率的图片格式，比如优先采用webp格式的图片替换掉jpeg、png和bmp格式的图片。
2. 限制图片上传大小：很多后台商品维护人员对图片大小没有概念的，我在公司就见过很多人直接上传10M以上的商品图片，试想下商品列表默认加载20个商品，总计200M的图片大小，以用户4G的网速多久才能加载完？所以管理后台必须要限制缩略图、头图和详情页图片的张数及大小。
3. 使用CDN存储静态资源：CDN是一种静态内容分发网络，它在每个省甚至每个城市都部署有自己的服务器，用于分发这些静态内容，那么当某个城市的用户要拉取某个资源时，他会首选从本地的CDN服务器上拉取，这样可以保证他最快速的获得该资源。将网站所有的图片、视频等静态资源全部上CDN。
4. 展示性图片，如商品或banner应进行延迟加载技术。防止首次请求数过多，以及下载内容过大。
5. 减少页面的接口请求数：比如去掉商品列表页上面显示的优惠券、促销、特价、预售、仓库和库存量等的接口查询和icon图标显示，去掉一些非必要的计算数据，如商品的销售量和销售排名。
6. 去掉非必要信息：例如初次加载时去掉商品价格排序、销量排序等，只有当用户点击按销量或价格排序时才通过接口查询并进行排序。
7. 商品信息提前计算：针对B端电商平台客户规模不大的情况，可以提前计算好每位客户的可见(购买)商品并结构化存储，后台更新商品价格等信息时同步或异步更新客户可见商品内容，客户登录或访问商品时直接显示提前算好的内容。
8. 减少默认加载数量：将默认加载的条数由20条改为10条或6条。
9. 资源分布式加载：顾客查看前6条商品信息时，先展示商品文字和价格等信息，稍晚些再展示商品缩略图。查看前6条商品时，再加载该分类下的6条商品信息。

产品经理如果不懂技术，可能就无法给出上述9条优化思路和建议。如果产品经理懂技术，可能在你的启发下，开发人员还会提出更多更好的优化建议来。

上述思路同样适用于其他页面，比如商品结算页面优惠券、促销和积分等叠加使用的场景。

6.网站SEO

早些年做过PC网站的产品经理对SEO这个词应该不会陌生，虽然近些年PC网站衰落移动应用(APP和小程序)蓬勃发展，但不可否认的是PC网站还是有很多人在用。

比如，打工人上班期间摸鱼可以刷会知乎/汽车之家/CSDN/淘宝网等，PC网站屏幕尺寸大的优点是手机和pad所不具备的，所以PC网站的SEO还是得有相应的重视。

很多TOB行业的公司或者产品，比如销售易CRM、网易七鱼客服系统、聚水潭ERP以及金蝶等，PC网站是其获客的重要途径。

而PC网站获客主要是依赖于搜索，很多需求明确或不明确的客户会通过百度/搜狗/Bing等进行关键字搜索，有了搜索就有了SEO。

如果你想自家的网站出现在百度/搜狗/Bing等搜索结果的靠前位置，就需要懂一点SEO技术，毕竟搜索带来的流量是相对持续且免费的。

SEO是由英文Search Engine Optimization缩写而来， 中文意译为“搜索引擎优化”。SEO是指通过对网站进行站内优化和修复(网站Web结构调整、网站内容建设、网站代码优化和编码等)和站外优化，从而提高网站的网站关键词排名以及公司产品的曝光度。

互联网上关于SEO技术的文章数以百万计。我这里分享一个做PC网站最简单粗暴却行之有效的方法，就是做网页的TDK，即在网站标题Title、描述Description和关键词Keyword里面“填满”关键字，然后让搜索引擎来爬取这些关键字。

你打开任意一个页面，鼠标右键中打开“查看页面源代码”，即可出现下图所示的内容，网页头里面即会出现网页的TDK信息。

我们生活中经常会用到这样的场景，你在阅读、学习或浏览网页的过程中遇到了生词abandon，想去查询下单词abandon的意思、翻译、音标、用法和例句等。

于是你就会通过百度去搜索，搜索时搜索内容可能就是“abandon、abandon是什么意思、abandon翻译、abandon音标等等，无论怎么搜，搜索结果大概率都会是下面这样的页面。

查看该页面的TDK信息，如下图所示。

金山词霸通过技术的方式给每个单词生产一个静态页面，这些页面的标题Title就是XXX单词是什么意思、XXX单词翻译、XXX音标、XXX读法等等。

而搜索引擎返回结果并排序的时候，有较大权重是查询的网页TDK的匹配度(当然还有网站PR、网站Alexa排名等其他因素)，这样金山词霸网站在搜索结果中的排序就会比较靠前。

英文有多少单词，有的说17万到100多万不等，我们按平均值60万算好了，金山词霸为这60万个单词生成了单独的页面。每天总有些用户会在这几十万的单词里面搜索，想想都觉得长尾流量很大。

上面这招看似简单，但金山词霸从2008年起用到了今天，整整17年。就这么简单的一招，每年至少可以为金山词霸节约数百万元的广告投放费用。

其实分类信息网站诸如赶集网、58同城和百姓网的SEO做的是很不错的，想想看全国多少个区县、多少个乡镇、多少个街道和商圈，而分类信息网又有多少项服务项目，通过“地域+项目”的方式可以生成：成都市租房、高新区租房、孵化园出租房这样的独立列表页，每个独立列表页又有很多内容页，通过此该网站的独立原创页面难以估算。

其它网站涉及到区域信息的，也在采用这样的方式，如下图的土流网，都获得了不错的PR值和收录。

如果产品经理不懂SEO相关的技术，那么就会白白浪费掉百度/搜狗/Bing等搜索引擎带来的免费的巨大流量，而流量就意味着真金白银。

SEO在很多公司都属于灰色边缘地带，感觉产品经理和运营、市场等都搭边，但又不怎么搭边，我就看过很多网站几乎没怎么做SEO。

但如果产品经理懂技术，能主动把这个事情揽过来，就能以小博大，以极低投入换来极大产出。

APP的搜索优化有专用名词ASO，ASO的底层逻辑跟网站SEO类似，但具体操作方式和方法上有些不同，后面有机会再讲，此文不做展开。

综上，产品经理如果懂点技术，那么在工作的开展和跟开发测试的沟通交流中，将会做得更好。至于懂技术的程度，个人认为浅薄的全面即可。

可能有人会说豆包和deepseek可以帮助我解决上述的所有问题，乍一看好像也没毛病，但细想就会发现，产品经理如果不懂技术，能在豆包等AI工具中提出问题么？能在AI工具返回的结果建议中甄别出有效的信息么？

所以，产品经理还是得懂技术。

以上，希望本文能对您有所帮助。