非技术产品经理一直困惑的点，其中有一项就是和技术的沟通，因为自己不懂技术，在实际工作中，沟通起来有很多障碍，《产品经理必懂技术那点事》这本书详细的介绍了沟通过程中存在的问题、方法的介绍、技术知识、框架的介绍。
其实在实际的工作中，和技术接触后，对于技术有基础的了解，但是通过阅读这本书，对于与技术沟通有系统性的理解，书中还介绍了产品经理常常会遇到问题、进阶的方式。都有很大的启发。
这本书非常适合非技术产品经理去阅读，为这本书打CALL。
先上导图
总结
1 产品经理必须要懂技术吗？
why懂技术的目的：产品设计（技术边界）以及和技术沟通
how如何懂:
1）和技术沟通的时候，遇到不懂的问题，询问或者自己搞懂
2）有意识的学习技术的相关信息、书籍、视频、系统地构建对于技术实现方式的框架
how much懂多少
懂原理、懂实现的方式、懂技术名词
摘抄与腾讯的能力模型中关于技术相关的：
1）知道技术名词及概念
2）知道互联网开发过程中涉及到的主要技术名词等理论概念
不需要你写代码、编程序
为什么与技术沟通的时候会存在不理解、问题？
思维方式、原有的知识结构的差异
技术思维：实现程序的难度、成本、方式——理性、逻辑
产品思维：用户价值、商业模式、需求分析、功能设计、使用场景……
2 技术实现方式的框架
1）互联网技术与产品
2）数据库
关系型数据库
Sql
非关系型数据库
3）前端
常用的语言介绍
Android（多屏幕适配问题）
iOS
web
4）服务器技术
云服务器
3 与技术沟通的技巧
了解技术是什么样的人群：严谨、“自负”
知道自己的沟通目的：
双方是合作关系，不要带有主观偏见，觉得对方不肯合作
沟通技巧：
1 ）把事情表达清楚
2 ）沟通模型（表达核心观点、产品反馈理解、技术重复确认理解、产品二次确认理解）
3 ）用讲故事替代介绍功能
3.1 如何沟通
PRD文档严谨（功能架构、正常流程、异常流程、前置条件、显示逻辑、排序规则、加载方式、）
自己设计的功能站得住脚，功能设计合理。
3.2 做不了的时候如何处理
技术边界、技术能力、时间进度
3.3 改变需求时的沟通方式
想清楚为什么要变，变得理由、而不是一直在改变需求，这样会招致技术对于产品的不信任
需求背景、界面设计、技术调整、功能逻辑
3.4 遇到这不是BUG的该如何处理
BUG对于工程师而言，其实是代码或者逻辑出错而导致的功能性错误
产品经理要区分清楚，是否是BUG还是你自己的原型没有相关的说明？
总结：产品经理在了解技术基本原理的情况下，同时还要掌握沟通的方式，掌握技巧、换位思考
4 产品经理自我修养
4.1 三种类型的产品经理
4.1.1用户体验型
4.1.2业务型
业务流程和业务动作展开的流程设计
全局思维能力
沟通能力
4.1.3数据型
4.2 三项核心技能
4.2.1 让对的事情持续发生
利用需求分析的结果快速推动事情向前发展
4.2.2 让信息高效流动
确保各个关键角色都能对信息有充分的了解
面对各个职位的人，自己有一套自己的语言体系，产品经理是时刻切换频道
在目前公司，特别是创业公司，信息不流通导致，会导致很多问题
方法：在处理某些事情的时候，想一想，这件事情该让多少人知道
例如招聘目标：项目说明会确认招聘指标、同时需要通知（老板、HR、和此件事情相关的人）
4.2.3 让组织合作顺畅进行
产品经理事情的推动者，老板没有想到事情，自己都要推动者去做
老板只会告诉你一个大概的目标，或者方向，落地靠产品
这就需要产品经理对于产品项目的流程有很清晰的认识，自己通过和老板不断的沟通，明确战略and目标、目标拆解、具体执行、产品规划
