第08期：产品经理要懂的技术

更新于 2026-09-15

产品经理要不要懂技术？懂到什么程度？本期讲清该懂哪些技术、怎么学，以及需要了解的关键术语。

1 产品经理要不要懂技术？

领导让我懂一点技术以方便工作，但领导说的不明确，自己又不好意思继续追问，要怎么办？作为产品经理要懂技术吗？要回答这个问题，我们要把它拆开来回答

1.1 常见问题

案例一：

  • 开发：这个做不了。
  • 产品：…… 案例二：
  • 开发：这个功能至少要开发2周。
  • 产品：啊，这么简单的功能要这么久啊？等上线了热度都过了。
  • 开发：是的…因为…算了，跟你说也不明白。
  • 产品：……

在日常工作中，产品经理可能有以下类似的烦恼：

  • 提出的需求被开发觉得异想天开，需求被拒，经常返工；
  • 觉得开发评估时间过长，自己很无力；
  • 需求评审会被开发批的体无完肤、一无是处；
  • 听不懂开发说的内容，开会时云里雾里，安排任务效率低；
  • 不知道技术的优劣，做决策拖后腿；
  • 出了问题不知道找谁，开发相互推诿，用户的问题无法得到快速解决；
  • 对项目进度无法掌控，版本经常延期；
  • 上线跟打仗一样，问题还特别多；
  • 开发的领导好难打交道，感觉很凶；
  • ……

网上讨论最多的就是案例中所描述两个的场景，很多人为之苦恼，感觉自己经常被开发忽悠，事情推进不了就算了，开发说的话还阴阳怪气，说话夹杂着嫌弃，眼神充满了鄙夷，非常的没面子。

1.2 找到问题本质

很多人认为之所以出现上面的情况，就是因为自己不懂技术，当产品经理懂技术之后，开发也就无法再忽悠，没有了鄙视和嫌弃，以上问题也能迎刃而解；即便没有解决，自己的技能树上又多了一个技能，总比只懂产品要强。这种想法对吗？不一定。这种想法实际上是在用战术上的勤奋来掩饰战略上的懒惰，开发是一个很看重实战的岗位，我们利用业余时间学习的一些皮毛，就想和在实战中厮杀多年的开发掰手腕，那就把开发岗位看太轻了，在他们眼里，我们和刚入行的开发没区别。退一步说，哪怕你天赋不错，学到了一些技术，开发想忽悠你还是一样，因为你不了解实际的代码情况。即使同样能力的开发，面对陌生的项目、不熟悉的框架和代码，在做评估的时候，都会选择保守，你也不能代替他们去开发，这种情况尤其以跨部门沟通时更加明显，因为你根本指挥不了他们。开发说“做不了”，你说“可以做”，开发说“你来？”。开发说“这个功能最少要3天”；你说“少唬我，我可是练过的，最多1天半就够了”；开发说“我就要3天”，接下来你有两个选择：

  1. 当场揭穿他，可能会上演全武行；
  2. 向他领导告状，领导可能和颜悦色的告诉你，要相信专业的；也许领导这次帮你解决了，下次呢？

因此，懂技术不一定能解决“做不做“和“忽悠”的问题，或者说要解决以上的两个问题和懂技术不能划等号，那可以给以后找工作加分吗？绝大多数情况不行，除非你在一个项目里即是产品，又是开发，而且项目完整跟完并上线运营，并且这个项目和这家公司类似（需要运气），这样的懂技术才可能成为加分项，否则很难。因为我们面试的不是技术岗位，级别越高价值也越低；产研负责人岗可能有价值，但这时就不是加分项，而是必要条件。有人不服气说，怎么就不是加分项，懂技术可以很好的和开发沟通，是的，可能，但这里的重点是沟通能力，技术只是其中的一小部分，也不能划等号，你是不是听过很多程序员都不擅长沟通的例子。当然，以上的分析不是说懂技术没有价值，而是不希望将懂技术当成唯一的阻碍，产品做不好是因为开发不配合，开发不配合是因为我不懂技术，我很苦恼，我没有办法。将问题推给环境，推给外在因素，没有思考对问题的本质，但是，产品经理恰恰是需要去思考问题本质的岗位。懂技术可以辅助你把工作做的更好，但不懂也不是阻碍你推进产品进度的关键因素，绝大多数人面临推进难的问题，究其本质，在我看来就三块：

  1. 甲方的优越感

说出来你可能不信，开发在公司里面其实是弱势群体，作为最下游的执行方，很多时候是很被动没有话语权的，甚至经常要背黑锅。而产品经理作为甲方，习惯把开发当成纯执行者，听话就好别乱说。优越感带来的第一个问题，是无法接受对方提出的修改意见和建议，觉得在挑战自己的专业，你一个开发懂什么？（这句话开发也经常对产品说，你啥也不懂），有时实在无法说服对方，就耍赖说“我不管，我就要，实现不了是你的能力问题，怎么实现是你们的事”。优越感带来的第二个问题，是在需求被拒时挫败感很强，内心觉得被开发鄙视了，其实真的想多了，开发一般都比较单纯，不会因为某个人不懂技术而看不起他，绝大多数问题是因为某个人的态度导致。所以解决问题第一步，端正态度，实现和开发平等对话，不是甲方乙方的关系，而是战友关系，将双方拉到统一战线。

  1. 能力的不自知

需求来自来自用户的诉求、老板的想法，产品经理很容易成为传声筒，没有去思考逻辑和细节是否合理，绝大多数开发与产品间的争吵，都是因为产品需求逻辑的问题。在需求评审会中，面对开发的疑问，无法在逻辑上讲通，产品经理很委屈，觉得这不是自己的错，明明是用户的需求，老板都答应了，开发怎么还这样呢？这不是刁难人吗？面对开发的不配合，没有去思考自己的问题，而是怀疑开发在针对自己，给自己的错误找很多借口。人与人之间的合作，不会因为对方不懂己方的专业而嘲笑，而是因为对方不自知、不虚心、不学习，才会让人看不起。学会调整自己的心态，认识自己的不足和知识盲点，不明白的地方虚心请教，承认自己不足有时比去学习一项新技能更难，主动避险是人的天性，我们习惯为问题找外部原因，而忽略了对自己内心的建设。

  1. 和研发之间的信任缺失

我们习惯用“怼”和“甩锅”来构建产品和开发之间的爱恨情仇，从内心就已经将产品和开发摆在了对立面，在双方划了一条信任鸿沟，需求评审会就变成了博弈游戏，认为对方是欺负自己不懂（当然也有可能是真的，但不常见）。你觉得开发在偷奸耍滑，开发效率这么低，每天不知道在做什么，开发觉得你在异想天开，啥也不懂，脑子瓦特了。懂技术似乎是一个构建信任关系的桥梁，但其实重点是如何和开发建立信任关系，而不是一定要去学习技术，其他方法可以尝试，如共同兴趣爱好，日常的交流关怀，都是不错的方法。在自己领域足够强也能增加信任度，需求够专业，逻辑性够强，思考有深度，上线有结果等等，人性是对强者会有天然的崇拜感，做出成绩就是最好的信任背书，开发也不会因为你不懂技术而轻视你，因为相信你肯定能做好。因此，合作的基础是信任你同部门的队友，双方不是你死我活的拉锯战，而是为了实现共同目标的攻坚战，通过统一目标也可以成为自己人，信任每个人在自己擅长的领域能做出最好的判断。如果你做不到对每个人的信任，那可以招一个你信任的资深开发，让他来帮助你做判断也是一个有效的方法，没有了信任，你再懂技术也没有用。倘若是跨部门，在对方的阵营中找到一个可信任的战友是有必要的，这个战友最好是团队中比较资深的那种，亦或者是有想法、责任感比较高，可以帮助你解决很多问题，时不时的请教，也能让你做事情事半功倍。排除了以上三点问题，先认清自己，认清环境，找到关键因素，看看懂技术是不是真的是你遇到问题的解法。

1.3 懂技术的正确姿势

（1）懂技术的目的

要不要懂技术，先要想清楚自己的目的，以终为始才能做到有的放矢，不同的目的，所需要学习的内容和程度会有所区别，但不管是什么目的，有一点可以肯定的是：技术是一个需要持续学习的领域，每隔几个月就会有新的技术诞生，永远也学不完。只有清楚自己的目的，才能清楚学习边界，才能在有限的时间内快速掌握所需要的知识，并在实际工作中使用产生价值，任何不能对你的目的产生帮助的都是鸡肋，要及时止损。

  • 你是想减少原型的返工次数？出需求时考虑的更加全面？
  • 还是想更好的和开发打成一片？推进工作时更加高效？
  • 还是想对产品迭代掌控力更强？更快的出结果？
  • 还是想有没有更优的解决方案？提高用户体验？
  • 还是想在产品的商业决策更自如？决策效率更高？

（2）懂到什么程度

列出自己的目的，才能知道自己要学习到什么程度，以及学习哪些内容，并不是要所有的都要学，所有的都要懂。想要和开发交流时跟上节奏，那就要懂一些行业内的专业名词或技术专业名词。因为技术讨论方案时基本上的内容是“关键词+逻辑”，逻辑我相信大家能听懂，只是夹杂着关键词会出现断层的情况。因此理解了关键词的含义，就能明白开发所表达的意思，才能切入解决方案讨论，接下来他们各自的分工和估时，能有效提出个人见解。想要减少需求的返工几率，推进需求开发效率，要了解现行技术边界，公司研发能力边界，清楚哪些能做哪些不能做。清楚岗位的分工、职责，和完整的产品开发流程，大概知道什么样的问题应该去找谁解决。了解一些不同岗位用到的软件、工具、技术名词、专业术语等，时不时能请教下开发，这种好学的求知欲能让开发认为你是自己人，也乐于去做一回老师。既能和开发打成一片，也能在提出需求时考虑到实现难度，自己能提前进行规避。想要对产品迭代掌控力更强，那就要掌握一定的项目管理知识，包括流程和管理工具，清楚团队中每个人的开发能力和效率，学会拆解开发任务，掌握正确的估时方法，对常见功能估时心里有底，掌握日常跟进内容，具备风控能力，并在出现延期时进行有效决策。想要了解更优的产品解决方案，提高用户体验，那要熟悉产品所在的技术生态，看生态内开放了哪些接口和能力（如公众号和小程序生态，可以看开放平台），关注行业技术升级动态，找到能提高产品体验的结合点。清楚行业内的技术栈能解决什么问题，优缺点是什么。想要找到产品突破点，提高决策效率，要对数据埋点技术有所了解，清楚不同的数据收集方式的应用场景，掌握数据库的基础知识，比如表、字段、视图等，学会使用sql查询语句，或者一些BI工具，这样可以根据自己的想法去拉取想要的数据，不需要每次求助开发，让决策更高效。产品经理对于技术的懂，只要做到知道是什么，有什么用即可，至于怎么用，好不好用，可以让技术来把握。如果你是一个创业者，觉得研发总是拖后腿，产品节奏跟不上，自己从头学技术肯定不是最好的方案，要不就找一个技术合伙人，要不找一个信任的外包团队长期合作，还可以使用低代码开发平台，也能满足80%的标准化需求，把自己不擅长的剥离出去，创业更要聚焦。如果你负责工具类的产品，尤其像给技术人员使用的，比如数据中台、无代码开发平台、可视化平台、云平台等，是必须要精通这个行业的技术的，请无视上面的内容。

2 产品经理要懂的技术

2.1 学什么？

（1）了解产品经理和技术的分类

技术本身是一个十分笼统的概念，我们先对技术进行分类，分为四个大类：

  1. 工程

通过Java、C语言等写脚本实现系统的某一功能或者是通过数据结构的改变提升系统某一性能。

  1. 算法

理解业务需求，完成数据清洗构建正负样本，构建特征工程；再基于Python语言，调用库包现成模型如GBDT等完成模型训练和测试；最终对模型进行部署上线。

  1. 数据分析

基于对业务的了解构建一整套的数据分析体系，然后通过Sql和Hive等数据分析语言完成数据分析。

  1. 大数据

基于海量的数据源开发各类底层的数据表格和数仓，通过Hadoop、Spark等构建各种数据流任务。我们基于产品经理的工作内容将市场上的产品经理分为6大类：

（2）不同产品经理需要了解哪些技术

下面我们根据每一类产品经理的工作内容进行实际分析需不需要懂技术，以及懂哪个技术栈。先放一张汇总的图，后续细细展开。

  1. 传统产品经理

工作内容：传统产品经理包括交互产品经理、业务产品经理等。交互产品经理主要负责产品的界面样式和产品内交互流转流程，通过研究用户习惯和系统之前的交互流程，设计流程更加顺畅，体验更加友好的产品。常见的有APP交互产品经理、ERP系统产品经理、平台产品经理等。业务产品经理专门是做功能设计和对接业务需求的，尤其是在一些非互联网行业，比如金融信贷产品经理、金融理财产品经理等。这一类的产品经理更需要懂的是业务知识，并不是技术能力。技术要求：无太高的技术要求，传统产品经理其实不需要懂太多底层技术，核心需要洞察用户、了解业务。对于各类技术名词（前端、后端常见名词）稍作了解即可。

  1. 策略产品经理

工作内容：以前这类产品经理比较少，但随着互联网和AI的发展，对于推荐系统&搜索引擎&反欺诈&金融科技的需求越来越多，要求也越来越高，需要有专门的产品经理来进行策略设计提升系统整体的效果指标，比如CTR&履约率等。这类产品经理的工作不再是单纯设计功能，更多的是基于数据驱动和用户反馈的策略设计。技术要求：算法 + 数据分析。策略产品经理首先得懂数据分析，基本的SQL和Hive要十分熟悉，基于数据分析结果，发现数据的异常提出策略优化意见。然后也要对常见算法的数学原理和模型评估指标很清晰，这样才能和算法童鞋进行无缝链接，比如什么是多路召回，什么是召回率，什么是精准率，GBDT算法的原理、梯度下降是什么等等。同时需要对于推荐系统+搜索引擎的架构十分熟悉，如果还能够自己用Python写机器学习模型那就最好了。

  1. 数据产品经理

工作内容：互联网早期也没有专门的数据产品经理，很多都是兼任做数据分析。后来随着移动互联网的发展数据量爆炸，越来越多的数据需要专人分析，同时需要更丰富的数据分析工具以及数据看板等，从而产生了一类专门和数据打交道的产品经理岗位。技术要求：数据分析 + 大数据技术。基本的SQL和Hive要十分熟悉，同时如果对于更底层的大数据处理技术（比如：Hadoop、Spark等）了解的话，那么在工作上也会有比较大的帮助。

  1. 商业产品经理

工作内容：单独将商业化产品经理拎出来也是因为这类岗位目前在互联网很吃香，影响公司的收入。互联网公司积攒了大量流量，而互联网公司需要基于这些流量进行商业化变现，从而产生了专门负责商业化的产品经理岗位，主要负责搜索&推荐等流量场的商业化变现，需要既懂搜索&推荐等流量分发策略，又需要懂广告的业务知识。而在商业化里面仍然做数据&用户等的产品经理，我们认为和其他方向的数据&用户产品经理并没有什么差异。技术要求：算法 + 数据分析。商业产品经理除了对广告业务知识十分清楚外，技术能力要求基本和策略产品经理一致，因为像搜索+推荐场景的商业化变现都需要对推荐系统+搜索引擎的架构十分熟悉，然后在整个系统里各环节应用的模型策略原理和数学原理也要比较清晰。

  1. AI产品经理

工作内容：因为近些年AI的蓬勃发展，专门产生了AI方向的产品经理。AI产品经理有两个大的方向，一种是将AI应用到实际场景的产品经理，还有一种是构建AI平台，方便AI科学家们更好地进行特征选择、模型训练、部署上线等。技术要求：算法 + 数据分析。数据分析技能是一个基本技能，AI是和数据打交道的，AI产品经理必须要会数据分析。AI产品经理需要会的算法可能就和策略产品经理不一样，AI产品经理更多要了解一些机器学习建模的全流程，对一些神经网络比如CNN&RNN等要清晰。尤其是做视觉和语音识别相关的AI产品经理，AI产品经理要更懂底层的一些技术。上述的对应是说，你想成为这个方向优秀的产品经理，你就得懂这些技术，有些甚至就是基本要求，比如数据产品经理就要会数据分析。你懂这些技术是为了更好地和技术人员进行交流。当技术人员和你说Auc指标时，你知道Auc指标怎么计算的；当技术人员和你说Auc=0.7时，你知道这是一个效果不错的模型，还是效果很差的模型；当技术人员和你说多路召回，全局最优时你知道对方是什么策略，而不仅仅只是一个提需求的工具人；当技术人员和你说这几天他都在调参时，你不再是满脑子疑问调参是什么？这里并没有要求产品经理懂“工程”，是因为工程本身很多时候是一个体力活，有很多的数据结构知识在里面，并不涉及到逻辑策略。所以产品经理可以不懂，但是一个优秀的算法工程师就必须既懂算法，又懂工程，不然开发的模型根本无法部署上线。产品经理需不需要会技术，和“篮球 or 足球教练需不需要自己球打得也很好”一样：实操可以很差，但是得懂。就像教练自己上场不一定打得很好，但他必须懂球。教练需要看过无数的录像，做过大量的战术分析，这样才能根据对手的情况，队员的情况制定比赛的战术，要求队员进行严格执行。需求的规划和落地其实也是一样。

2.2 怎么学？

（1）数据分析

数据分析完全可以自学，这是一个零基础就可以学习的技术栈。当然如果你如果想写出非常高级的SQL脚本，代码既简单运行效率又高，这个是需要在实践中和专门的数据工程师请教的。

  • MySQL入门

MySQL本身入门相对比较简单，B站上有很多免费的公开课程，差不多一周的时间就可以学会很多基础的查询语句，后续在实际工作中去提升自己的SQL能力。

  • 数据分析体系入门

SQL和Hive只是工具，很多时候工具学起来简单，但是如何构建数据分析体系和学会数据分析的思路这个更重要。比如如何构建用户画像，用户画像分为哪些维度等等，这些是需要一定业务知识的。

（2）工程开发

  • 前端与后端的区别

工程开发产品经理主要需要了解和区分前端和后端，了解前后端的分工不仅可以帮助我们更好的推动产品方案落地，还有助于在出现bug时，更加快速定位到问题来源与对应开发人员。前端：“前端”是与用户直接交互的部分，包括你在浏览网页时接触的所有视觉内容--从字体到颜色，以及下拉菜单和侧边栏。这些视觉内容，都是由浏览器解析、处理、渲染相关HTML、CSS、Java 文件后呈现而来。前端开发，就是要创造上面提到的网站面向用户的部分背后的代码，并通过建立框架，构建沉浸性的用户体验。为了实现这个目标，开发需要熟练运用下列语言、框架、工具库。后端：为了让服务器、应用、数据库能够彼此交互，后端工程师需要具有用于应用构建的服务器端语言，数据相关工具，PHP框架，版本控制工具，还要熟练使用 Linux 作为开发和部署环境。后端开发者使用这些工具编写干净、可移植、具有良好文档支持的代码来创建或更新 Web 应用。但在写代码之前，他们需要与客户沟通，了解其实际需求并转化为技术目标，制定最有效且精简的方案来进行实现。

2.2.0.1 前端
  • 基本功：HTML和CSS

首先学习HTML和CSS，理解Web网页如何被开发出来的，包括结构、样式等。然后学习JavaScript，并能够做到与页面进行联动，通过这个过程可以了解到页面的“交互”是如何实现的。HTML、CSS、JavaScript，是前端的基本功。

  • JQuery

然后可以学习JQuery。这是一个非常老牌的JavaScript框架，它可以让我们更加简单地控制页面元素（DOM）。它可以它的语法也非常轻便和简单，非常易于上手，也非常易于让技术小白了解前端交互的实现逻辑。以上内容可以去到w3cschool或菜鸟教程中学，免费，知识完善，而且它们都提供的编辑器，供大家边学习边编程，可以有效提升学习效果和学习体验。同时，为了增加一些趣味性。在学习的过程中，也可以捣鼓一些前端库。font-awesome可以让我们非常简单地网页面中增加emoji图标，而animate.css则可以让我们非常方便地为网页元素实现动效，例如点击按钮后按钮的震动、弹跳等效果。还有很多很有趣的库正在等待你的挖掘。

  • 进阶学习：前端框架

再往后，可以进阶学习前端框架，如vue.js，以便更好地理解“工程化”、“组件化”、“前后端分离”等概念。同时，也可以学习一下微信小程序的编程，其编写方式与vue.js是十分相似的。

  • 稍加了解

自从出现了“大前端”的概念后，前端框架如雨后春笋一般，每天都有新鲜玩意。但作为产品经理，学习技术的目的是了解技术的实现方式，并不需要去学习那么多新鲜的框架，只需要选择目前很成熟的、或较热门的技术学习即可。至于iOS和Android的前端开发，大可不必去学。因为其技术本质是相通的，只是使用的开发语言（Objective-C、Swift、Java…）和应用承载的平台（iOS、Android）不一样而已。也可以通过阅读苹果和谷歌的官方开发文档，了解一下各自系统所提供出来的数据或能力，这些都是为了达成产品目标所可以利用的资源。同时，你也可以了解到，Web页面是可以被挂载到iOS或Android应用上的。同时，Web页面可以与iOS或Android原生页面进行一定范围内的数据传递或交互。这一点对于产品经理在时间紧急的情况下设计APP的一些活动板块或临时性页面时尤为重要，因为一次开发就可以通用在iOS和Android的APP上。因此市面上也有Flutter这样的通用开发框架，一次开发，可以让应用同时运行在不同平台上。但这类开发框架，虽然节省了开发成本，但在部分场景下的体验和技术方面，也还是有它们自身的问题的，在此不展开详述。

2.2.0.2 后端
  • python php可以不会，但编程的逻辑关系要知道。自己可以尝试学习python这样的入门比较容易的语言，多试试用编程的逻辑考虑问题，产品和技术沟通更容易。python免费学习的地方很多，除了w3cschool或菜鸟教程外，还有廖雪峰的官方博客也是一个不错的学习处。学习python最好遵循一个顺序：先学习基本知识，至少搞清楚数据类型、函数、对象、属性、模块、正则表达式等基本概念，同时理解什么叫“面向对象”。然后你就会了解到，python作为“胶水语言”，有大量的第三方库可以使用。你可以通过这些库，去做一些你感兴趣的事情，以下是几个例子：
  1. 网页爬虫。可以通过requests、beautifulsoap、urllib等库，去爬取你感兴趣的网页内容，你甚至可以自己搭建一个爬虫脚本，帮助你定时获取信息。
  2. 数据分析。可以通过openpyxl等库，操作excel数据。可以通过pandas、numpy等库进行数据分析计算，并通过matplotlib进行数据可视化绘图。
  3. 图像处理。可以通过pillow对图片进行各种处理，体验一把用代码P图的感觉。
  4. Web开发。可以通过django或flask库体验网站开发的过程以及一些细节。
  • API

产品经理对于API及其调用方式也需要有基本的认知，进行考虑并体现在产品设计方案或者PRD中。以调用QQ分享接口为例进行说明：我们需要查看QQ开放平台API调用说明，明确各种API调用的效果以最终确定要选取的API，以及该API需要自定义哪些参数。下图是我的PRD的截图，指明了调用的API、调用效果以及需要自定义的参数值。在《headfirst python》这本书中，通过一个具体的例子，更加透彻的讲解了API的由来：在编程中，通过定义函数，可以减少重复代码；将函数保存在一个脚本文件中，使之转化为模块；将模块放入文件夹，同时增加元数据文件，就可以将模块打包准备发布；在web上发布你的文件（也就是API），以供他人下载、安装和使用，其他开发者可以使用API所提供的函数为产品增加功能。为了让更多人以不同方式更加灵活的调用API，我们在定义函数时可以使用可选参数（也就是为参数提供默认值），通过使用参数控制函数的行为与表现。

  • web开发

web应用的工作方式主要包括以下几种：

  1. 用户在浏览器执行操作，比如输入URL或者点击一个跳转链接。
  2. 浏览器将用户动作转换为一个web请求，通过互联网发送到服务器。
  3. 服务器收到请求并进行处理。在这里，如果请求的是静态内容，服务器会找到相应资源并把它作为响应返回给浏览器；如果请求的是动态内容（也就是需要运行程序才能输出），那么服务器会找到并运行相应服务端程序，并将程序的输出作为响应发给浏览器。这个生成动态内容的过程称为通用网关接口（CGI），符合这个标准的服务端程序称之为CGI脚本。
  4. 浏览器接收到web响应，通过改变DOM将之显示在用户的屏幕上。

（4）数据库

产品经理对于数据库的设计方式、作用方式有一定的了解，有助于评估产品功能的实现对现有数据库的影响，以及新的设计对原有数据的兼容性问题。另一方面，现在的产品设计往往需要参考大量的用户行为数据，进行下一步优化。这些用户数据往往存储在数据库中，产品经理有时需要使用SQL语句对数据库进行查询，因而对于数据库的了解也是大有帮助的。了解数据的结构，以及开发同学口中常说的“CRUD”。廖雪峰的官方博客也是学习数据库查询语言的好地方。

  • 关系型数据库与非关系型数据库

一般会先学习“关系型数据库”，了解行、列、字段、属性、主键等概念。“非关系型数据库”也需要接触一下，主要是了解它和“关系型数据库”的异同处，以及它的一些组织或处理方式。这些概念需要与在学习后端时所学到的对象、属性进行结合，会更好理解系统对象的构成。关系型数据库是一种基于关系模型的数据库，这种关系模型是对现实中实体关系的抽象表达。非关系型数据库，在存储的数据结构上没有那么严格的约束和规范，以更加灵活的方式定义数据存储。常用的数据库管理系统（软件）包括：Oracle、MySQL、MongoDB等。

  • SQL SQL是数据查询语言，学习它，能够让你更好地理解数据的组织方式。尤其是B端的同学，能够进一步地提升对系统各业务数据的流转的感受。

（5）AI&算法

AI的时代正在强势到来，学习AI相关的技术知识也显得非常有必要。要了解AI，首先要接触的是算法。这对于没有一定数学基础的同学来说会感觉很难入手。产品经理想熟悉算法非常难，甚至想入门算法就已经很难了。

  • python入门

入门算法首先要会Python，这是基础的工具。Python是我唯一建议产品经理去学习的一门计算机语言，不建议去学习Java、C语言&C++等，第一学习难度很大，第二学出来说实话对于工作没啥帮助。R语言和Matlab在工业界几乎不用，也没有学的必要。工业界算法都是用Python，因为Python里面太多可以直接调用的库非常方便。如果一个人能够通过上网课自学Python真的需要非常大的毅力，没有外界的压力推动的话很难学会，顶多懂一点皮毛。网课学习代码最大的难点就是没有人请教，不会改BUG。我以前没有读硕士之前曾经尝试过，后来放弃了。第一没有人请教，第二没有压力推动真的很难持续学习。这里我不推荐任何网课，因为真的很难靠网课学会。

  • 机器学习入门 如果想系统性地学习机器学习，我建议还是专门读一个相关方向的硕士，国外有很多一年制的Data Science和AI方向的硕士。在作业、考试和毕业论文等多方压力下，这一年只要你努力学习，肯定能够对机器学习有一个非常清晰的了解，甚至可以转岗做算法工程师。大家也不用担心本科毫无基础能否学习机器学习，我读硕士时班上计算机科班的同学没几个，大家都在学业的压力下逼迫自己学习，最终顺利毕业。专门读硕士是为了你有一个专门的时间来学习，一边工作一边学习机器学习真的很难坚持。
  • 策略入门

如果你既不想学习Python，也不想了解机器学习的底层数学原理等，至少得清楚这些策略基础原理，比如Item-CF和User-CF的基本区别和应用场景等。可以看一些别人分享的策略文章，人人官网和知乎上有很多算法工程师在分享这类文章。

  • 基础入门

可以先简单回顾一下高中曾经学习过的概率论和线性代数知识，然后了解机器学习的几个类型：如分类、聚类、回归、降维，以及他们对应的几种算法。在实际应用的案例（例如，垃圾邮件的分类，就是一种二分类算法），结合起来理解。推荐大家去百度AI平台，使用免费的额度，通过python去使用里面的一些AI方法，来帮助你更加深刻的理解AI应用。例如可以通过NLP（自然语言处理）对文本进行分类、理解、识别、打标签等，通过OCR（光学字符识别）体验从不同类型的图片中获取文本的乐趣等。在进一步地学习过程中，还需要了解到样本、特征、评估、模型、算法，及他们之间的关系。几乎所有的AI应用都基于该五要素。关于以上内容的学习，给大家推荐两本书：《策略产品经理：模型与方法论》和《人工智能产品经理：AI时代PM修炼手册》。如果你有不错的数学基础，则推荐《裂变：秒懂人工智能的基础课》。

  • 进阶学习： 大语言模型（LLM）、提示词工程（prompt-engineering）与langchain库
  • 大语言模型（LLM），大火的ChatGPT就是LLM的一种，同时也可以进一步了解一些垂直行业领域的LLM，如京东的产业LLM和彭博的金融LLM，了解LLM的运作原理和应用场景。
  • 提示词工程（prompt-engineering）了解如何与LLM交互和沟通。推荐prompt-learning网站，或B站吴恩达与OpenAI联合推出的prompt课程。
  • langchain库，进行一些简单的AI应用开发，能够帮助你更加深入地了解AI应用。
  • 如何成为一名AI产品经理和大数据产品经理

想成为AI产品经理和大数据产品经理注定需要先吃一番风霜苦。首先，自己有无抓住AI和大数据的红利期，实现从传统产品经理转型到AI大数据产品经理的思维方式；其次有无做好接受数据汇聚、数据存储、数据分析、算法针对行业业务的类型、模型在不同的数据集训练测试持续优化的准备，需要准备哪些呢？譬如：打破小产品的认知，走向大产品。学着做一个AI大数据产品的融资方案，市场规模调研，可行性分析报告，还有最最核心的以用户需求和客户要求做的具体的AI大数据产品的产品界面、功能、后台数据治理的文档。过程中需要懂的技术至少有：

  • 硬件基础层的CPU/GPU/FPGA/ASIC等；
  • 引擎框架层的高性能计算引擎如分布式计算框架/交互式分析框架/深度学习框架等，Hadoop生态圈组件的HDFS/Hbase/Kafka等，数据库的时序数据库/高性能的OLAP数据库等，还有容器云管理等；
  • 平台级产品层，大数据管理数据集成的流程/元数据管理/数据质量管理/数据资产管理/数据安全管理等，大数据AI机器学习的模型部署管理/边缘AI/可视化开发/IDE集成开发等，当然还有集群管理，用户管理，权限管理，监控管理等。

以上技术懂的尺度和边界是你所在的团队技术不懂的你得懂，技术懂的你得能跟他交流。

（6）项目管理

最后，最好也学习一下软件项目管理。因为项目管理的本质，是将不同角色、不同人员、不同分工进行串联的一门学问，让我们能够从一个更加宏观的视角去解决产品管理问题。传统的瀑布流模式可以简单了解一下，但更建议去深入了解当下较多使用的敏捷模式（如：scrum），推荐《敏捷革命》。深入地学习敏捷开发，不仅能够了解这种开发管理方式，同时也能理解“敏捷思维”，并将这种思维方式运用到自己工作的其他方面。

2.3 3.产品经理需要了解的术语

HTTP状态码（HTTP Status Code）：

  • 表示网页服务器响应状态的3位数字代码。1开头的为消息类，代表请求已被接受，需要继续处理；2开头的为成功类，代表请求已成功被服务器接收、理解、并接受；3开头的为重定向类，代表需要客户端采取进一步的操作才能完成请求；4开头的为请求错误类，代表了客户端看起来可能发生了错误，妨碍了服务器的处理，常常遇到的403、404属于此类。

Native App：

  • 基于智能手机本地操作系统如iOS、Android、WP并使用原生程式编写运行的第三方应用程序。能够调用移动硬件设备的底层功能，比如个人信息，摄像头以及重力加速器等等。

Web App：

  • 基于web的系统和应用，运行于网络和浏览器之上，目前多采用h5标准开发。只能使用有限的移动硬件设备功能。

Hybrid App：

  • native app 与 web app的混合，在native app里内置浏览器，合适的功能页面采用网页的形式呈现。既能保证流畅性的体验，就满足变更复杂等需求，实现动态运营。
  • 三者的对比：

App消息推送（Push）：

  • 对用户移动设备进行的主动消息推送的行为，基于app和后台的联系来实现，app和后台的连接方式分为两种，Pull（轮询），即不断地向后台请求；Push，即维持一条长连接通道（心跳机制）。

Reactive Native：

  • Facebook 在2015年4月开源的跨平台移动应用开发框架，是使用Javascript语言同时编写ios，andriod，以及后台一种技术。便于熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域。

数据交互：

  • 即前端和后台的数据交互，大致可分为四种：1）使用cookies对象（Cookie是服务器保存在客户端中的一小段数据信息），前提是客户端的浏览器需允许使用cookies。2）使用session对象（session对象表示特定会话session的用户数据），客户第一次访问支持session的Java Server Pages网页，服务器会创建一个session对象记录客户的信息。3）利用request重定向，设置setAttribute（重定向发生时，服务器会跟浏览器交互，它会让浏览器重新生成一个新的请求发送给服务器）。4）利用Ajax进行异步数据请求，得到的数据可以以json或xml格式返回，便于处理。

HTML、CSS、JavaScript：

  • 网页主要由 结构（ Structure） 、 表现（ Presentation） 和行为（ Behavior）三部分组成。
  • HTML，即Hyper Text Markup Language，定义网页的结构。
  • CSS，即Cascading Style Sheets，定义网页的样式，样式定义如何显示 HTML 元素。
  • Javascript，是一种脚本语言，定义网页元素的行为。

程序、进程和线程：

  • 程序是指令和数据的有序集合，是一个静态概念。
  • 进程（Process）是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。
  • 线程（Thread）是程序执行流的最小单元。线程是进程中的一个实体，是被系统独立调度和分派的基本单位。

同步、异步和回调：

  • 同步调用，即当程序1调用程序2时，程序1停下不动，直到程序2完成回到程序1来，程序1才继续执行下去。
  • 异步调用，即当程序1调用程序2时，程序1径自继续自己的下一个动作，不受程序2的的影响。
  • 回调（callback）和异步调用关系密切，通常使用回调来实现异步消息的注册。

浏览器渲染：

  • 对从服务器加载到的资源（HTML、JS、CSS、图象等），进行语法解析，构建渲染树（对各个元素进行位置计算、样式计算等等），然后根据渲染树对页面进行渲染（可以理解为“画”元素）。

流（stream）：

  • 在C++，Java等编程语言中，流是指用来从另一个地方不间断地获取数据。

缓存系统：

  • 一般分为两级，一级缓存也叫内存缓存，存取速度更快，程序退出数据就消失，不可一直保留，是一种以空间换时间的程序设计；二级缓存也叫硬盘缓存，容量大一点，速度慢一点，程序下次启动时候，依然可以使用。在一二级缓存超过某个阈值时，一般会使用LRU（Least Recently Used）算法进行淘汰。

定位：

  • 室外定位使用GPS，地球上任意一点都可以同时观测到4颗卫星，以保证卫星可以采集到该观测点的经纬度和高度。
  • 室内定位，一般采用基站和WIFI定位。运营商可通过查询手机连接的基站位置定位，WIFI定位则是通过手机连接的无线路由器的MAC地址。

“熔断”：

  • 如果【服务提供方】频繁超时，就把【服务调用方】调用【服务提供方】的请求，直接短路掉，不实际调用，而是直接返回一个mock的值。等【服务提供方】的服务恢复稳定之后，重新调用。

推荐算法：

  • 常见的为内容关联算法和协同过滤算法。内容关联算法基于对item内容的理解，提取内容形成taglist，剩下的事情和搜索引擎类似，通过merge用户喜爱的item，匹配tag进行召回，优势在于无需冷启动。协同过滤算法的原理是汇总所有<user,item>的行为对, 利用集体智慧做推荐，其原理很像朋友推荐。

数据库（DataBase）：

  • 按照一定的数据结构来组织、存储的数据的“仓库”。常见类型为关系型和非关系型。关系型把复杂的数据结构归结为简单的二元关系（即二维表格形式），如Oracle和MySQL。非关系型即NoSQL数据库，是对关系型数据库的补充，特点是模式自由、支持简易复制、简单的API等。

接口：

  • 提供具体能力的一个标准和抽象。通过接口的设计，一个系统被清晰定义成为了多种能力的集合，每一个开发者只关注自己模块的实现就好了，调用者负责完成整个程序的业务逻辑。

热补丁（hotfix）：

  • 通过线上推送一段修补 BUG 的代码，终端无需更新版本直接运行，可以做到在用户无感知的情况下，修复问题。该技术避免了当 App 发布之后，突然发现 bug 需要进行紧急修复时需要完成的重新打包 App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装等一系列复杂的操作。

“撞库”攻击：

  • 通过收集互联网已泄露的用户和密码信息，生成对应的字典表，尝试批量登陆其他网站后，得到一系列可以登录的用户。

TCP/IP协议：

  • 即TCP/IP协议族，TCP（传输控制协议）和IP（网际协议）为该家族中最早通过的标准。协议族可以分为四层：最上面的是应用层了，如http，ftp等协议；第二层是传输层，TCP和UDP协议在这个层次；第三层是网络层，IP协议就这一层，它负责对数据加上IP地址和其他的数据以确定传输的目标。第四层是数据链路层，这个层次为待传送的数据加入一个以太网协议头，并进行CRC编码，为最后的数据传输做准备。

Ajax：

  • 即“Asynchronous Javascript And XML”（异步 JavaScript 和 XML）。是一种无需重新加载整个网页的情况下，能够更新部分网页的技术。

DOM：

  • Document Object Model（文档对象模型），在网页上，组织页面（或文档）的对象被组织在一个树形结构中，用来表示文档中对象的标准模型就称为DOM。

HTTPS：

  • Hyper Text Transfer Protocol over Secure Socket Layer（超文本传输安全协议），简单来讲即是HTTP的安全版，在HTTP下加入SSL层，广泛用于万维网上安全敏感的通讯，例如交易支付方面。

URL：

  • 即统一资源定位符，对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。可以分解为：协议（如http://）+ 主机名（如http://v.qq.com）+ 路径和文件名（如/a/20160221）+ 参数（如?a=1&b=2，目的是带上一些本地信息给服务器）+ 端口号。

数据埋点：

  • 即在正常的功能逻辑中添加统计逻辑。有客户端（前端）埋点和服务端（后端）埋点之分。客户端的埋点是记录的用户在客户端的操作记录，服务端埋点则是记录的客户进行服务器请求的日志。客户端埋点一般都是采取key-value的形式，key代表某个事件，value代表事件发生的次数、状态值等。

生产者与消费者模式：

  • 在一个系统中，存在生产者和消费者两种角色，他们通过内存缓冲区进行通信，生产者生产消费者需要的资料，消费者把资料做成产品，从而实现服务的解耦。在这个模型中，最关键就是内存缓冲区为空的时候消费者必须等待，而内存缓冲区满的时候，生产者必须等待。其他时候可以是个动态平衡。

SDK和API：

  • SDK即软件开发工具包（SoftwareDevelopmentKit），第三服务商提供的实现软件产品某项功能的工具包。API即应用编程接口（Application Programming Interface），是操作系统留给应用程序的一个调用接口，应用程序通过调用操作系统的API而使操作系统去执行应用程序的命令（动作）。

架构：

  • Architect，可以类比建筑架构，抽象来看包含以下几个层次：
  • 1）根据要解决的问题，对目标系统的边界进行界定；
  • 2）对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
  • 3）并对这些切分出来的部分，设立沟通机制。
  • 4）保证部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

第三方登陆：

  • 实质是在OAuth2.0协议的基础上，利用外部的标识来获取帐号的内部标识然后完成登录的过程。具体的讲，就是将三方的帐号绑定到产品自身的帐号上，当查询到用户第三方的帐号已经绑定了平台的某个user_id时，直接登录对应的帐号。

外部标志：

  • 用来使用用户身份的标志，可以是用户名，手机号，邮箱等，每一个外部标识一定和一个内部标识相关联用以确定一个用户。需要注意的是，外部标识可能改变。如 open_id，union_id。

内部标志：

  • 即产品中用于标识用户唯一性的标志，例如user_id，必须有，不可更改且唯一，用户一般接触不到内部标识。当一个内部标识建立后，用户所有的数据资产都会绑定到这个内部标识上。如 user_id、app_id。

Unix时间：

  • 用一个正整数来表示时间与基准时间之间相差的秒数，常使用NTP协议（网络时间协议）来把计算机的时钟同步到世界协调时UTC。

控件、组件和框架：

  • 涉及到程序设计中的粒度划分。
  • 控件表示程序设计中最小粒度的可复用可编程的部件，比如常见的搜索框、按钮、单选框、复选框等。
  • 组件由控件组合而成从而具有一定能力/功能，它是功能复杂的最小单位。比如App的TabHost。
  • 框架是由很多控件、组件组装在一起的，并且能够在某一领域完成一系列操作。

加密：

  • 对原来为明文的文件或数据按某种算法进行处理，使其成为不可读的一段代码，通常称为"密文"，使其只能在输入相应的密钥之后才能显示出本来内容，通过这样的途径来达到保护数据不被非法人窃取、阅读的目的。可分为对称加密和非对称加密：
  • 对称加密即单密钥加密，双方用同一个密钥来实现信息的加密和解密；
  • 非对称加密使用两个密钥（公钥和私钥），公钥可以对外公开，私钥对外保密，公钥加密的信息，只有私钥能解密。

脚本：

  • Script，普通文本文件，是确定的一系列控制计算机进行运算操作动作的组合。

MVC模式：

  • 即模型(Model)－视图(View)－控制器(Controller)。用一种业务逻辑、数据、界面显示三者相分离的方法来组织代码。
  • Model 建立业务规则模型，该层返回的数据相对中立，可以提供给不同的页面。
  • View 即用户看到并与之交互的界面，在视图中其实没有真正的处理发生，它只是作为一种输出数据并允许用户操纵的方式。
  • Controller 接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

示意图：用户首先在界面中进行人机交互，然后请求发送到控制器，控制器根据请求类型和请求的指令发送到相应的模型，模型可以与数据库进行交互，进行增删改查操作，完成之后，根据业务的逻辑选择相应的视图进行显示，此时用户获得此次交互的反馈信息，用户可以进行下一步交互，如此循环。跨域与同源：

  • 跨域即不同源。同源即同域名，同端口，同协议。浏览器的同源策略限制了来自不同源的“document”或脚本，对当前“document”读取或设置某些属性，从一个域上加载的脚本不允许访问另一个域的文档属性。

重构：

  • 在保留现有功能的基础上，重新梳理软件中的代码结构，让原本杂乱无章的代码重新具有可读性、结构性和拓展性。

增量更新：

  • 传统做法下重新下载安装一个最新版的apk文件，比较耗流量，不利于用户体验。增量更新只下载当前app版本与最新版本的差异内容，然后与当前版本就行合并成最新版本再安装。

敏捷式开发和瀑布式开发：

  • 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。瀑布式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行，要到后期才能看到产品的样子。

响应式设计：

  • 是指根据不同设备浏览器分辨率或尺寸来展示不同页面结构、行为、表现的设计方式。实现上包含了响应式布局、响应式html和css、响应式媒体、响应式javascript

抽象、封装、类、实例：

  • 抽象是面向对象思维的最基本逻辑，是对问题领域进行分析，抽象出共性。封装是把对象的属性和行为（数据）结合为一个独立的整体，并尽可能隐藏对象的内部实现细节。类是对属性和功能集合的静态描述。实例是真正的载体和功能的执行者。

继承：

  • 继承是从已有的类中派生出新的类称为子类，子类继承父类的数据属性和行为，并能根据自己的需求扩展出新的行为，提高了代码的复用性。

“锁”：

  • 和资源占用相关的概念，为解决对同一资源操作的时间重叠问题，将「并行执行」变更为「顺序执行」。

程序中的数据：

  • 常量（“写死的”）、变量（赋值之后才能使用）、整型、浮点、字符、数组（同类变量的集合）、字符串。

静态网页和动态网页：

  • 静态网页是标准的HTML文件，是指没有后台数据库、不含程序和不可交互的网页。动态网页则能与后台数据库进行交互，数据传递，是结合了HTML以外的高级程序设计语言和数据库技术进行的网页编程技术生成的网页。

MapReduce：

  • 是面向大规模数据处理的并行计算模型和方法，将大量数据分解为独立的单元执行，然后将结果归并在一起，即先Map（映射），然后Reduce（归约）。

端口：

  • Port，是设备与外界通讯交流的出口，分为物理端口和虚拟端口。虚拟端口指计算机内部或交换机路由器内的端口，不可见，如网络数据收发用的端口号。

栈和队列：

  • 栈是一端受限，一段允许进行操作的线性表，遵循先进后出。队列也是一种特殊的线性表。不同于栈所服从的先进后出的原则，队列的原则是先进先出。

“引擎”：

  • 是一个软件产品中，最基础最核心的一个组件。比如搜索中的搜索引擎，实现最核心的爬虫、分词和索引；游戏引擎是用来开发游戏的工具和组件。

长连接：

  • 连接是指客户端和服务器基于TCP/IP协议联系起来并获取数据（通常三次握手建立，四次握手释放，所以每个连接的建立都是需要资源消耗和时间消耗的）。
  • 短连接是指通讯双方有数据交互时，就建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送。
  • 长连接是指建立的连接长期保持，不管此时有无数据包的发送，这时为给长连接保活，一般会定时向被检测系统发送心跳包，检测系统是否存活或者网络链路是否通畅。

位图和矢量图：

  • 位图使用像素点来描述一张图片，矢量图由点、线、多边形等图元构成（使用数值和方程式进行描述）。

表单：

  • 在网页中主要负责数据采集功能。一个表单由三个基本组成部分：表单标签（用于申明表单，定义采集数据的范围，HTML中的<form>）、表单域（包含了文本框、密码框、复选框、单选框和下拉选择框等）和表单按钮。

URL Scheme：

  • 苹果给出的一个可以让app相互之间可以跳转的协议。

“观察者模式”：

  • Observer，又称为源-收听者(Listener)模式，是软件设计模式的一种。在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。观察者设计模式定义了对象间的一种一对多的组合关系，以便一个对象的状态发生变化时，所有依赖于它的对象都得到通知并自动刷新。

SQL注入攻击：

  • 由于代码设计中没有对用户输入数据的合法性进行判断，用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据。

正则表达式：

  • 即Regular Expression，是对字符串操作的一种逻辑公式。

向前兼容、向后兼容：

  • 向前兼容即Forwards Compatibility，是对未来还没有做好的版本兼容。向后兼容即Backward Compatibility，是对已经发出去的老版本兼容。

状态机：

  • 描述一个事物多个状态之间相互切换关系的数学模型（常用有向图来描述），构成要素为现态（现在的状态）、次态（一定动作后达到的状态）、条件（执行动作的前提）、动作。

序列化：

  • Serialization，将对象的状态信息转换为可以存储或传输的形式的过程。通俗来讲，即是把数据对象转化为二进制。

JSON：

  • JavaScript Object Notation，是一种轻量级的数据交换格式，采用完全独立于编程语言的文本格式来存储和表示数据。易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。

Instant App：

  • 为了让人们能够像点击链接那么简单，节省掉安装App的痛苦，最快速度、最少流量的消耗，让用户体验到App级的用户体验，Google于2016年的Google I/O大会，发布了该技术，同年9月21日，微信小程序公开内测，但是二者在体积和页面解析（HTML vs Java）速度上有所不同。

参考文献：

  1. 辩证难题 | 产品经理要不要懂技术？https://www.woshipm.com/pmd/5579468.html
  2. 深度思考 | 产品经理要不要懂技术的底层逻辑https://www.woshipm.com/pmd/5239764.html#toc-
  3. 产品经理的技术学习之路https://www.woshipm.com/pmd/5818124.html
  4. 不行，产品经理就要懂点技术！https://www.woshipm.com/pmd/4156147.html
  5. 产品经理需要懂技术吗？懂到什么程度？https://www.woshipm.com/pmd/5741125.html
  6. 产品经理需要了解的技术基础（一）https://mp.weixin.qq.com/s/MvpEgYKzgcu\_\_eEg1m5GPA
  7. 掌握数据结构：产品经理必备的技术知识https://mp.weixin.qq.com/s/wa6fgnwkEGCeptoKsMD6Ww
  8. 每个产品经理都应该要掌握的设计技能！https://mp.weixin.qq.com/s/8P17UWNJkoxTRuHJzkqsuQ
  9. 产品技术沟通之道 | 如何与技术人员高效沟通？https://www.woshipm.com/pd/5246950.html
  10. 策略产品经理：深入浅出了解机器学习算法原理（中篇）https://www.woshipm.com/pd/5688128.html
  11. 写给产品经理们的技术分享——前端篇https://www.woshipm.com/pmd/2495256.html
  12. 写给产品经理们的技术分享——后端篇 https://www.woshipm.com/pmd/2537577.html
  13. 3招掌握AI与大数据产品经理的能力 https://www.woshipm.com/pmd/3000853.html
  14. 前端和后端分别是什么？ - 前端小姐姐的回答 - 知乎

https://www.zhihu.com/question/52319165/answer/1559551602

→ 产品兵器库 · 第08期（原始飞书文档）