观后感：
唐韧作为一个技术转的产品经理，这本书可能有一半多都是和技术转产品经理相关的，不过从其他视角看的也是很不错的了，我把有价值的好段落给放到下边了
uv，pv指标，是一个开发人员产品经理和老板都特别需要的一个指标，它可以让我们看到这个产品的转化率，看出来她的价值体现，体现在使用量
而我最喜欢的还是，如何和工程师沟通这章和下边的一些
工程师的智力和记忆力一般都不差，所以他们对逻辑细节的记忆和把握能力一般都比较强
所以大部分工程师是“自负”的，不喜欢被产品经理说自己负责的模块，有bug，不过换一种方式就好很多了，例如，有个问题需要和你商量一下，用提问的方式
多用“我们”去代替“我”
而在最小化可行产品概念中，我觉得这不只是一个做产品的思维，而是做任何事情的思维，例如想要学一个东西，或者，摆地摊，等等，最重要的就是以最小的成本进行最快的上架开始
另外一点：为了消除这种陌生感，产品经理可以主动和技术团队的人建立关系，可以是平时的闲聊或者一块吃饭，方式有很多种
这也不只是适合产品经理和工程师，它可以适用到所有的你想要需要的人际关系，好的关系让人更愉快
另外一个与人沟通的方式，特别是对于产品需求这类，我们需要提出问题，和二次确认，然后说出解决方案，这样可以减小理解偏差
然而这个文章最符合我做事风格的是：聚焦答案
什么意思呢？就是说，不要过于关注问题，是因为什么什么，怎么怎么样导致这样，而是说要怎么做，如何做，具体的做法和时间规划去解决问题
产品思维与技术思维
对产品经理这一职能来说，需要掌握更多的语系，因为产品经理是信息的衔接者
产品经理和工程师分别有各自的职能属性。产品职能属于信息上游，负责发现并定义需求，将用户需求通过具体的产品功能设计呈现为用户可用的产品，包括需求分析、功能定义、原型设计等。
技术职能属于信息下游，负责从技术实现角度评估产品设计，设计技术方案，最终将产品设计实施落地为用户可用的产品。在这个过程中，工程师需要先理解需求，
工程师思考方式：工程思维往往是理性的逻辑思维，从实现的难以程度和系统的角度去定义产品和设计产品
弊端：脱离实际
入门产品经理的思考方式：功能思维，是从软件产品本身角度出发的思维模式，是从系统功能的角度来评判产品的完整性和实用性
高级产品经理的思考方式：产品思维是一种结合工程思维，功能思维的以及商业思维的的综合思维模式，包括对商业目标的理解、对目标用户以及用户使用场景的理解
程序是指按照一定的规则和顺序的任务执行过程，是一套指令集合，在软件开发中，程序由数据结构和算法组成
程序=数据结构+算法
产品经理学数据库
数据库运行在服务器中，类似于一个进行数据存储的仓库，数据按照一定的规则存储，可以对数据库中的数据进行增删改查的操作
对于技术人员来说，数据库再熟悉不过了，尤其是后端的同学，所以说实话，这本书很多内容不需要慢慢看，要快慢结合
关系型数据库是一种基于关系模型的数据库，关系模型折射现实世界中的实体关系，将现实世界中各种实体及实体之间的关系通过关系模型表达出来
SQL（Structured Query Language）即结构化查询语言，是一种用来操作关系型数据库的编程语言，可以理解为对数据库的操作命令
非关系型数据库是一种相对松散且可以不按照严格的结构规范进行存储的数据库。非关系型数据库一般叫作 NoSQL（Not Only SQL），非关系型数据库没有关系型数据库那样严格的数据结构约束，在存储的形式和使用上有别于关系型数据库
redis,MongoDB 和 CouchDB
产品经理学客户端技术
Android 应用开发完成后，需要被打包成一个扩展名为“apk”的文件，APK 的意思是 AndroidPackage，这个文件是一个完整的 Android 应用安装文件
类似于我们在 Windows 系统中使用的“.exe”的安装文件
iOS 是一个闭源系统（也就是不开放源代码的系统），该系统只能由苹果公司在自家的移动设备上使用
iOS 界面布局与 Android 不同，iOS 使用的是绝对布局，也就是说，每一个控件在界面上是通过指定控件的绝对位置进行显示的
苹果在技术上也推出了类似Android 布局方式的相对布局，通过响应式布局来调节界面控件的显示方式
iOS 应用打包是通过苹果推出的开发工具 Xcode 完成的
通过浏览器访问的网页通常被称为 Web 页，每一个 Web 页都有一个唯一的地址，不同的地址组合在一起，通过链接相互跳转，最终形成一个网站系统
URL（Uniform Resource Locator）的全称是统一资源定位符
URL 通常分为三部分，第一部分是协议部分，也就是上例中的“http://”， HTTP协议（Hypertext Transfer Protocol）全称超文本传输协议，是互联网的基本协议。字面意思是通过该协议我们可以在互联网上传递除了文字以外的其他内容，例如网页、音乐、图片等。
HTTP协议（Hypertext Transfer Protocol）全称超文本传输协议，是互联网的基本协议。字面意思是通过该协议我们可以在互联网上传递除了文字以外的其他内容，例如网页、音乐、图片等。
现在有很多产品是使用 Web 和 Native 混合实现的方式，混合实现是指在一个原生 APP 产品中嵌套一部分 Web 实现。
产品经理学服务端
负载均衡服务器是用来处理大规模请求的服务器，通常对于一些访问量比较高的系统来说，负载均衡就显得尤为重要，负载均衡服务器的作用是将同时进来的大量访问请求根据应用服务器的忙碌程度进行动态调度，可以把负载均衡服务器理解成服务端的调度中心，它负责流量的动态分配，根据对应的应用服务器的负载情况，动态分配请求到不同的应用服务器。
数据接口是指客户端与服务端进行数据传输和交互的数据协议，数据接口是一种数据交换的标准
在实际应用中有两种常用的数据接口的结构，分别是 JSON 和 XML
JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，也是一种用来表示数据接口结构的形式。JSON 结构灵活性高，可以进行丰富的数据结构表达，JSON 结构易于理解和阅读，也便于计算机进行解析和表达，一个简单的 JSON 结构如下。
{
"username":"ryan"，
"password":"123"
}
XML（Extensible Markup Language）的全称是可扩展标记语言
XML 的基本元素是由一个一个的标签构成
中国
黑龙江
哈尔滨
大庆
广东
广州
深圳
珠海
湖南
长沙
株洲
“utf-8”是一种统一转换编码格式，可以支持繁体中文、简体中文及英文、日文、韩文等的解析
产品经理学数据
数据指标是指产品在各个方面所记录和统计出来的数据结果，是对过去进行回顾和对未来进行预测的参考标准
UV（Unique Visitor）是网站独立访客和独立用户的意思，指访问某个网站的独立 IP 的数量，通常计算的周期是当天的 0 点到 24 点。UV 可以反映出用户活跃度，
也可以反映出在某一个固定周期内用户使用产品的情况。
PV（Page View）通常是指网站的页面访问量，和 UV 不同的是，PV 统计的是用户打开网站的次数
DAU（Daily Active User）是指日活跃用户，记录一天内独立用户登录或使用产品的次数。
MAU（Monthly Active User）是指月活跃用户，记录在一个自然月内用户的活跃度情况
GMV（Gross Merchandise Volume）全称为商品交易总额，是一种反映平台交易总量的数据指标
GMV 是商品交易总额，并不是成交总额
转化率是统计一个大范围的运营活动或者产品动作转化出有效用户的比例
留存率是指用户进入产品后，在一定的周期过后留存在产品中的用户数量
产品经理如何写一份高质量的 PRD
PRD（Product Requirement Document，产品需求文档）由产品经理负责撰写。产品需求文档是产品经理用来与技术人员或其他相关人员进行信息传递和沟通的工具
PRD 至少应该包括三部分，分别是变更日志、需求描述和功能设计
需求描述是用来介绍产品功能所满足的业务需求和用户需求的，如果产品经理在设计产品时不知道产品功能满足了什么需求，那么这个功能就很有可能成为一个无用
功能。若无必要，勿增实体
用户需求是指该产品功能在用户的使用场景中为用户解决了什么问题，用户通过这个功能能完成什么用户任务
PRD 是产品经理与相关人沟通和传递信息的主要辅助产物，PRD 的目标读者有工程师、测试人员、其他产品经理、业务市场人员甚至是老板。通常，PRD 的主要
读者是工程师
沟通永远是产品经理需要不断学习和提高的技能，好的产品经理肯定是个会讲故事，而且能站在不同角度讲故事的人
如何与工程师正确沟通
工程师的思维方式是一种线性而且逻辑性比较强的方式，考虑问题或者做出行动时往往会按照严密的顺序和逻辑进行，他们认为一件事情肯定是按照固定的流程执行，不喜欢中间突然变化或者出错，因为这会使他们感到沮丧
工程师又是一群极为“自负”而且追求极致的人，这种“自负”并不是贬义的自负，而是一种对自己所做的东西的自信，这种自信超出传统的自信，所以用“自负”
来描述这种超额自信
工程师的智力和记忆力一般都不差，所以他们对逻辑细节的记忆和把握能力一般都比较强
所谓形象化提问就是产品经理利用自己同理心优势，将自己不了解的技术问题通过一种比较形象化的方式描述出来，以提问的方式让工程师帮忙解答
产品经理作为变化的驱动者，需要把握产品变化的原则和如何去驱动变化，驱动变化的过程中需要做好的第一步是变化前的沟通。人的本能都是拒绝变化的，面对拒绝变化，产品经理首先应当从事情的本质层面进行探究
多用“我们”去代替“我”
遇到工程师说某个功能做不了时，反问三个问题。
第一个问题，“这个产品需求在现有技术条件下是否可实现，是不是存在技术边界”。
第二个问题，“既然是可实现的，那做不了的原因是否是因为我们目前不具备这样的技术？”
第三个问题，“既然不存在技术边界也不存在技术储备不足，那是因为开发进度和时间导致做不了？”
在工程师的世界里，BUG是一种贬义词，是因为代码或者逻辑出错而导致的功能性错误
工程师接收到 BUG 时，心里通常是不爽的，自己写的程序代码出了故障，这是很难接受的。
产品经理的自我修养
严格来说分为三类，分别是用户体验型产品经理、业务型产品经理和数据型产品经理
产品是技术与艺术的结合
所谓最小化可行产品是源自精益创业的一个概念，意思是构建一个能基本满足需求的产品，去掉多余的细枝末节，只保留主干功能，快速投入市场让用户开始使用，然后收集和整理用户在使用过程中出现的问题，经过分析后基于这些问题提出解决方案，再将这个解决方案应用到产品改进中，接着再快速投入市场，再次验证和修正，如此反复后
而乔布斯作为产品经理，他是事情的发起和组织推动者，这才是产品经理应该做的
为了消除这种陌生感，产品经理可以主动和技术团队的人建立关系，可以是平时的闲聊或者一块吃饭，方式有很多种
产品经理工作中会遇到的问题及解决方法
因为很多时候不是我们解决不了问题，而是我们根本就没搞明白问题是什么。
第一是找到问题本身的事实情况，
第二是判断问题的影响范围。前者确定问题是真实存在的
一个公司要做的事情首先是从老板的战略出发，战略指明了方向，在这个大方向之下，产品经理负责通过产品将战略以用户可用的产品的形式落地
通过提问的方式明确战略意图
然后提出可能的解决方案让老板进行二次确认
聚焦答案”要求问题解决者把解决问题的重点放在如何解决问题上，而不是一直关注问题是什么，以及问题带来的现象和影响
发现问题不难，难的是发现问题的本质和一般规律，洞察力就是一种发现并获取这种本质的能力
洞察力不仅仅是一种解决问题的能力，更是一种创造答案的能力，所谓以不变应万变就是利用深度洞察力去理解问题的本质