听说你还在纠结PM到底要不要懂技术？
文/一个低调的J先生
【全文目录】
1 写在前面
2 核心要点
3 程序与功能
4 客户端技术
5 服务端技术
6 数据库
PS：若时间有限，可直接跳转到第二部分核心要点，全文精华；
1 写在前面
诶？
听说你也想转产品？
听说你又担心转产品需要懂技术？
听说......
行了行了，我和你一样。
作为一个半路出身PM，专业和产品甚至可以说没有半（pi）毛线相关。
一切源于2018年8月中旬的某个下午.......
一次毫无事故的临时起意。
然后，我进入某互联网大厂产品技术培训生。
故事就这样开始了。
既然是半路转行，其中的辛酸和苦水，不用说你也懂；
不过既然开始了，发现自己还有点喜欢；
不对，是非常喜欢。
那自然要好好干；
作为小菜鸟，怎么干？
打怪升级，刷副本，刷经验，刷boss......听说游戏里好像都是这样。
有点道理，但除了这个，我还想写若干系列的文章，记录一下PM转行过程中踩过的坑、绊倒的坎，当然还有跌倒后爬起来拍拍灰尘不认怂的那点——“骄傲”。
供所有转行或即将转行或想转行的PM一起分享学习；
这是第一篇，来自起点学院唐韧老师的《产品经理的技术必修课》全部课程笔记。
啊？你问我为啥这么干？？？
我只是觉得这样做有点酷hhh；
2 核心要点
（1）这是一张思维导图：
（2）以下是全文最重要的几个要点：
1）什么是产品思维和技术思维？
产品思维是从用户价值出发，在满足商业战略和业务目标的同时寻求产品路径满足用户需求；
产品思维关注焦点：用户价值、使用场景、商业价值、业务闭环；
技术思维是从功能和工程实现出发，在满足产品需求的同时寻求可复用技术架构和低成本开发；
技术思维关注焦点：实现方式、技术架构、技术价值、开发成本；
两者的交叉范围：需求、设计、功能；
2）产品经理需要对技术懂到什么程度？
明白技术思维 ≠ 技术能力；产品经理需要的是技术思维而非技术能力，了解技术思维是为了更好地判断功能的复杂度；
3）何为优秀的产品？
产品思维和技术思维的结合体，扎实的技术基础和良好的用户体验相结合的产物；
产品思维先行（更重要），技术思维是确保产品能成为现实的有力前提和必要工具；
懂用户比懂产品重要，懂产品比懂技术重要；
4）如何建立技术思维？
建立产品设计中三个层级的基本认知：
功能及界面设计——功能的逻辑效率，界面设计的简洁统一；
用户体验设计——关键路径设计，信息架构及交互方式；
技术实现逻辑——技术合理性和产品兼容性；
找到关键节点，对症下药。
5）如何更好地和工程师沟通？
多注意培养沟通技巧：
成为沟通的组织者，而非命令或质问；
明确问题，针对问题展开讨论而非本末倒置，协调参与方聚焦解决方案并达成一致；
沟通具体过程中，多用“我们”替代“我”，多用“大家”、“一起”、“共同”替代“你”，多用“你怎么看呢”代替“就是这样”，遇到不懂的技术问题，多引导和转移，多请教和理解；
6）技术思维判断产品问题的三点参考原则。
做新需求比改老需求更加容易；
对原有产品方案做需求变更，会涉及新老版本数据兼容问题；
业务逻辑越复杂，对应的技术方案越复杂；
（3）紧跟的几张配图：
3 程序与功能
（1）什么是编程语言
（2）程序的定义
程序 = 数据结构 + 算法；
程序块是程序的最小执行单元；
（3）产品功能与程序块之间的关系
4 客户端技术
（1）客户端技术分类
分为移动端、网页端、桌面端几种，使用的技术和编程语言各不一样，工程师的职能也不一样；
1）三种客户端技术
2）工程师职能分类：
（2）Android和iOS技术特点
1）技术特点比较
2）常用控件及其命名
（2）网页技术基础
1）网页技术基础
2）两种语言的具体示例
3）H5、Native、混合应用技术的特点
4）几个案例
（3）微信小程序
1）微信小程序介绍
2）微信小程序技术原理
3）微信小程序 VS APP
5 服务端技术
（1）为什么PM要学习服务端技术
（2）服务端技术架构
（3）数据传输过程
（4）服务端技术架构的机房组成
（5）服务端与客户端的接口格式：其中JSON应用的更为主流；
（6）服务端与客户端数据交互模型：服务端与客户端通信按照“请求——响应”模型规则进行，通过一问一答来完成一次交互；
（7）POST与GET
6 数据库
（1）数据库定义
（2）关系型数据库（主流） VS 非关系型数据库
（3）数据库“表”和“关系结构”，每个“表”对应一个实体，用来表达和定义实体规则，包括表名、表字段、表主键、表关系；
数据库表之间的关系：反应不同实体表之间的对应关联关系，包括1:1、1:n、n:n；
（4）数据库字段
（5）数据库操作语言
（6）数据表基础操作
课程PPT截图及课程内容总结于唐韧老师《产品经理的技术必修课》，侵删。
