产品经理需要知道产品功能在技术上是如何实现的吗？
作为产品经理在接到需求，经过分析之后，设计功能满足需求，需不需要知道这个功能在技术上是怎么实现的？
我的答案是：最好要懂，可以不用具体到每一个技术细节，但是实现原理及流程一定要懂。
懂技术不等于会写代码，懂技术实现的目的是：了解自己产品方案实现的底层逻辑，当出现问题时可以知道是客户端解决还是服务端解决；当然懂技术实现，也会让你在规划后续功能时，提前知道是否存在技术限制，避免设计出明显在技术上不可实现的产品方案。
作为毕竟不是专业的开发人员，作为产品经理，只但是需要知道如下几点：
?从技术角度看，一个互联网产品的结构是怎样的，各自承担什么功能（例如：前端、客户端、后端、资料库等）。
?从技术角度看，当用户进行某种操作后，程序运行的基本逻辑是 什么（例如：前端的操作控制项如何提交请求到后端伺服器，经过什么样的处理，如何返回结果等）。
?对其他常用的技术细节有概念。
所以，在这举两个例子，相信你就会对程序的运行逻辑有个全面的了解。
案例1：在网页上登录（B/S结构）
B/S结构即浏览器（Browser)和伺服器（Server)结构。我们访问一个网站，输入正确的用户名和密码后，点击「登录」按钮，过一会儿，我们就看到了自己账户中的内容（例如余额数 字）。这个过程司空见惯，但是从技术角度来讲，上述这句话描述的过程的具体实现逻辑可能是下图所示。
第1步，用户在浏览器中输入网址，按回车键，这时浏览器通过网路连接到伺服器，向伺服器索取这个网址所对应的网页内容。
第2步，伺服器找到对应的网页内容（源代码），然后通过网路将这些内容传输给浏览器。
第3步，浏览器得到这些源代码，然后将其解析成网页展现给用户。此时用户看到两个输入框，分别是「用户名」和「密码」，同时有一个「登录」按钮。用户输入正确的用户名和密码， 点击「登录」按钮。
第4步，浏览器再次连接伺服器， 将用户输入的内容传输给伺服器，并告诉伺服器，用户要执行登录操作。
第5步，伺服器知道了用户的意图，获取到用户输入的用户名和密码这两个数据之后，紧接著连接资料库，将「用户名」这个内容传给资料库， 要求资料库提供相对应的「密码」栏位内 容。
第6步，资料库找到相应的内容， 然后将「密码」信息返回给伺服器。
第7步，伺服器将用户输入的「密码」与资料库返回的「密码」内容做对比。假设对比的结果是「一致」。
第8步，伺服器找到该用户登录之后应该看到的网页内容，但是「余额」这个具体数值伺服器不知道，于是它再次向资料库（注：不一定跟上一次是同一个资料库）询问这个用户的余额 是多少。
第9步，资料库接到请求，找到余额数据，并返回给伺服器。
第10步，伺服器再次将这些网页内容（源代码，包含余额信息）传输给这个用户的浏览器。
第11步，浏览器得到这些源代码，然后将其解析成网页展现给用户。用户看到了登录后的网页上面有他的余额数字。
由此，我们可以得到下述结论：
1、一个简单的登录操作，在最简化的模型中，是由浏览器、伺服器 和资料库这三个环节协同完成的 (实际情况更复杂，可能还涉及 DNS解析等）。
2、浏览器可以解析伺服器传来的内容，显示给用户，就成了用户看到的「网页」。点击网页上的「登录」按钮，网页可以向伺服器提交数据，伺服器可以处理这些数据，是因为网页和伺服器上都有相应的「程序」。
3、在上面描述的过程中，浏览器就像是一个空売，其内部显示的不论是内容本身（例如「余额数字」），还是非内容的UI和功能部分（例如「『登录』按钮」）都是由服 务器传输给它的。
4、所有的关键数据都存在资料库中。
案例：在手机客户端上的发图片(C/S结构）
C/S结构即客户端（Client)和服务 器（Server)结构。如果你正在微信发朋友圈，或者发微博，从手机相册中选择一张图片，写几句话并发送，过一会儿，你的好友就可以看到这张图片和这几句话。这个过程听起来也很简单，但是从技术角度来讲可能会经历下图所示的逻辑过程。
第1步，用户A打开手机上的某社交类应用客户端，想要选择一张图片。这时，该应用客户端程序向手机操作系统（如i〇S或Android)请求访问手机相册，得到允许后，列出相册中的所有图片供用户选择。用户A选了一 张，原图的大小为5MB，并写了几句话，按下「发送」按钮。客户端程序发现这张图片太大了，使用4G传输会很慢而且会耗费大量的流量，于是自动将其进行了压缩。
第2步，客户端程序使用网路连接伺服器，并将压缩过的图片和那几句话传输给伺服器，同时告知伺服器， 这些内容是「用户A」产生的。
第3步，伺服器接收到客户端程序传来的内容，连接资料库，将这些内容存储在资料库中，并标记好是「用户 A」的内容。
第4步，资料库完成存储工作，然后通知伺服器，存好了。
第5步，伺服器接收到资料库的通知，然后通过网路将这个信息通知给用户A手机上的客户端程序。这时，客户端程序在用户A的手机屏幕上显示一 个「发布成功」的提示。
第6步，这时，用户B也打开了安装在其手机上的该社交类应用的客户端程序，他跟用户A是好友，程序自动通过网路向伺服器发出数据请求，要求伺服器返回用户B的所有好友的内 容。
第7步，伺服器接收到请求，连接资料库，希望得到某个时间节点之后用户B的所有好友的内容。
第8步，资料库找出用户B的所有好友在这个时间点之后产生的内容(其中包括刚才用户A发送的图片和文字),然后按一定格式返回给伺服器
第9步,伺服器接收到资料库传来的数据(有图片、文字),然后将其通过网路传输给用户B的手机客户端程序。
第10步,用户B的手机客户端程序接收到数据,然后刷新用户B的手机屏幕上的内容。这时,用户B看到了用户A发送的图片和文字。
通过这个案例,我们可以得到更复杂一些的结论：
- 客户端软体往往不只是一个用来装内容的壳子,它还具备一些功能逻辑,例如压缩图片的功能，这些功能都是开发工程师写代码实现的。
- 在上述流程中,客户端程序和伺服器之间交换的是纯内容数据,不包含UI和功能部分,因为后两者都已经做在客户端程序里面了
- 一般情况下,客户端的使用体验应该比网页更流畅一些,因为它与伺服器只需要相互传输内容数据,不需要传输UI和功能。同时,网页与伺服器之间的数据交互需要通过浏览器这个媒介,所以必然要受到浏览器的一些限制;而客户端则直接与伺服器交互,听起来后者应该性能更好,可以做到的事情更多一些。
综上所述,我们可以看出,即便是两个最简单、最常见的操作流程,背后对应的技术实现逻辑也是非常复杂的。作为产品经理,要能够理解这些基础的技术逻辑,这样才能与工程师相对流畅地沟通。
以下知乎高赞答案也许同样对你有帮助：
产品经理可能用到的专业术语有哪些？
2020 年校招，最值得加入的互联网公司有哪些？
为什么这么多人想转行做产品经理？
通过BAT、网易、京东产品经理的简历大概什么样？
产品经理需要懂技术吗？懂到什么程度？
产品经理不想做产品了能去做什么？
产品经理面试用的笔试部分问题和答案有哪些？
如何在群面中表现自己？
薛老板：产品经理面试必备常见10道题及解析
薛老板：2020年，写给想转行做产品经理的你
??看完两件事??
看完这篇内容之后如果对你有帮助，我想请您帮我三个忙
1、点赞，让更多的人看到这篇内容（收藏又点赞，手拉手好朋友 ）
2、关注我和专栏，让我们成为长久的朋友关系，精彩回答可以第一时间收到
谢谢您的支持！
需要了解，尤其是TO B的产品经理，面对复杂的系统，若不了解技术实现，有时候甚至完成不了需求分析。
A）TO C产品：一般而言，产品功能实现较为简单，研发团队较小，产品经理甚至可以和每一位开发同学进行沟通，对需求细节进行确认，自己不懂的情况下，开发侧也可以做有效补充，这时，对产品经理的技术理解要求较低；
B）TO B大型系统（如广告、支付等）：产品系统较为复杂，往往由数千人的研发团队合作完成，异地协同开发是常态。一般几十个子系统相互嵌套，子系统对产品效果产生协同/拮抗影响。开发同学相互不知道对方的工作内容，甚至有时实现逻辑也不能确认。
这时，若产品经理不了解简单的技术实现原理，是很难准确提炼需求的。
以广告系统为例做一个简单的讲解
1.基础的技术实现逻辑
上面附图是，广告系统中最核心的一环，即一个广告是如何展示给用户的。
广告主原始需求：多（带量多）、快（来量快）、好（用户质量高）、省（客单价成本低），很明显，这里很多需求是互斥的，有些还会损害平台利益。
以「多」举例，让广告主在广告系统上获取更多用户，技术原理上可实现的路径有：
A）广告检索：覆盖度更高的标签标注；
B）广告粗排：放宽限制条件，给予粗排ecpm的buff加成；
C）广告精排：放宽限制条件，给予精排ecpm的buff加成；
D）竞价曝光：放宽流量策略限制。
上述方法理论上都可以让广告获得更多的量，每一种方法的实现成本是什么呢？潜在的风险是？
若产品经理对广告曝光逻辑不了解，则很难提出准确的需求。
一般而言，会是在粗排阶段进行优化，有兴趣的同学可以深入交流。
2.基础产品逻辑的拆解
上面以一个具体的功能点进行了简单解释，这对于一个产品显然是不够的。产品经理需要在更宽广的场景里面思考自己的问题。如：在产品看来，广告的本质是什么？广告系统由哪些模块组成？我们的目标是什么？实现路径呢？
A）这里就需要产品经理对整个广告系统做定义；
B）对各个模块做拆解、组合；
C）规划产品迭代及实现路径。
在规划产品迭代路径时，需要产品经理对整个系统的结构有所了解，不然很容易在复杂的细节中迷失方向。
3.最后，到目前为止，最优秀的产品经理大多是技术出身
上古时代如：求伯君、雷军、马化腾、李彦宏、丁磊、张小龙、周鸿祎等
现在如：张一鸣、王兴、黄铮、蒋凡等
A）出色的沟通能力：技术出身的产品，与开发团队沟通有天然优势，毕竟相互理解是沟通的基石
B）快速迭代验证的能力：这里是我最想说的，会发现上述产品都是自己出去创业了，技术背景的产品，可以在事情起步时，自行开发，快速验证自己的商业逻辑，快速迭代成长。而一般的产品经理，只能反复构思，由于缺少实践的锻炼和检验，很难完成心理建设和成长。
以上，互联网一开始本是工程师的产物，尊重和了解技术，是一个优秀的产品经理的必修课
好问题！我建议：需要了解，了解到对体验的影响是必须的，再深入的了解看意愿和能力。
关于对体验的影响，有以下几项是需要考虑的：
1、正常情况的处理
1）子系统之间的信息流是怎样的？
比如每个子系统需要哪些必要信息、提供哪些信息；这决定了用户看到的信息是否完整、真实；
2）子系统之间的控制流是怎样变化的？
比如每个子系统是及时处理并返回结果（同步处理）还是稍后处理再返回（非同步处理）。这决定了用户体验上流程设计，是暂停并等待处理结果返回（比如页面loading），还是先提示用户「处理中」之后等待处理结果返回（比如订单支付过程）。
2、异常情况的处理
1）对于可能处理数据量较大、处理时间较长的特殊环节是怎么处理的？
当前的处理能力是多少？是否考虑了临时扩容来应对突发的大量处理请求？具备临时扩容的话，扩展出来的资源从哪来，怎么占用，怎么还回去？这决定了用户在每个环节的体验具体是怎样的，什么情况下会出问题，一旦系统上出现了问题，业务层面是否准备了应急处理方案，来确保用户利益。
2）对于操作失误或系统处理失败，是否有撤销或者回滚？
是否保存了历史情况？保存了哪些历史信息？是按照时间还是按照什么标识保存的？怎么恢复的，新增还是覆盖，是交给用户操作还是系统自动恢复？这决定了用户使用过程是否有足够的安全感。
3、结合前两方面，对于可能出错的地方，是否设计了校验？
校验参考数据从哪来？校验过程是怎样的，信息流和控制流是怎样的？出错后怎么处理？这保证了用户基本利益。
保证现有的用户体验不受技术设计的影响，这是本职工作的范畴。其他再深入的了解，就看个人了。比如，在现有的处理速度上，能不能更快一点？在现有的吞吐量上，能不能处理更多数据？在现有的出错概率上，能不能进一步降低，维持系统稳定？在现有的功能上，能不能提供更创新的功能？
当然，需要了解技术架构与框架对功能实现、性能、扩展性、兼容性等方面的影响，不仅仅是当前功能实现，更要看的远一些，宽一些。否则以后一定会听到「重复造轮子、挖坑填坑、打补丁、开飞机换引擎……」诸如此类，烦不胜烦。
不需要知道的太过具体，但是要了解，知道流程。
很多时候产品经理和程序员的矛盾就是沟通不到位，想要顺畅沟通就需要产品经理懂技术，产品经理懂技术，就能在设计产品功能的过程中在功能的实现上做取舍，才能明白快发能做什么，也能明白开发所说的话是什么意思，能够站在他们的角度去思考问题。
而产品经理需要懂技术到什么程度的？说简单点就四个字：点到为止
因为你不是提开发去实现需求，你只需要大体了解开发框架，技术的生命周期以及其优点缺点，技术成本以及设计模式就够了。一定要以产品为出发点，不要过度关注技术层面问题。
毕竟，产品经理的主要能力是以下技术：
除了技术学习，项目实践经验也是非常重要的。
我组建了一个产品经理的自学团，在团里会严格监督大家学习打卡，形成良好的学习习惯。给大家分享最新的学习资料，给大家匹配互相督学习的学习伙伴，定期组织大家进行项目实战。想要加入的小伙伴可以私信我或是给我留言。
推荐阅读：
