图书在版编目（CIP）数据
数据产品经理高效学习手册：产品设计、技术常识与机器学习/张威编著．-- 北京：人民邮电出版社，2020.4
ISBN 978-7-115-52638-0
Ⅰ．①数… Ⅱ．①张… Ⅲ．①数据处理-产品设计 Ⅳ．①TP274
中国版本图书馆CIP数据核字（2019）第271739号
编 著 张威
责任编辑 张丹阳
责任印制 马振武
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
涿州市京南印刷厂印刷
开本：690×970 1/16
印张：15
字数：260千字
印数：1-3 000册
2020年4月第1版
2020年4月河北第1次印刷
读者服务热线：（010）81055410 印装质量热线：（010）81055316
反盗版热线：（010）81055315
广告经营许可证：京东工商广登字20170147号
本书主要讲解了产品设计思维框架和具体操作流程，帮助读者快速了解产品设计的全过程；同时讲解了产品研发的技术常识，包括前端研发、后端研发、数据库设计等，帮助读者成为“懂技术”的产品经理；此外，还通俗易懂地讲解了机器学习原理，帮助读者成为一个掌握前沿知识的数据产品经理。
本书适合对数据产品感兴趣的读者，有志于从事数据产品经理职业的读者，希望了解产品研发技术常识、需要提升自我能力的产品经理，以及希望了解机器学习原理，想要转型为数据产品经理或人工智能产品经理的读者。
本书旨在帮助对数据产品感兴趣或者有志于从事数据产品经理职业的广大读者，系统全面讲解了产品设计的思想与流程方法、产品研发的技术常识和机器学习原理的前沿知识，帮助读者快速补充数据产品的相关知识。
产品经理已经成为热门职业，未来还会有更好的发展，因为我们所处的时代主题仍然是信息化改造世界，从而提升各行各业效率。但是随着大数据和人工智能的发展，产品经理职业方向有了一些新的变化，那就是产品经理的数据化转型，也就是产品经理开始向数据产品经理转型。5G时代来临后，物联网和数据通信会有更大的发展，数据量会呈现爆发式增长，利用好大量数据打磨出符合消费者、公司和客户需求的产品，是数据产品经理义不容辞的责任。
本书主要内容分为4个方面：（1）介绍产品设计思维框架和具体操作流程，读者朋友可以通过这部分快速了解产品设计的全过程和具体实施方法，包括产品设计环节、用户需求发掘、产品设计的信息路径规划、信息点功能设计、产品原型与需求文档编写等；（2）介绍产品研发的技术常识，包括数据库是什么，客户端技术如HTML、CSS和JavaScript，服务端与客户端交互过程，数据接口类型，常见的编程语言，数据分析方法，数据可视化方法，常见后台模块等；（3）重点介绍了机器学习的原理方法，如机器学习的算法原理、调参优化的处理过程等，帮助读者了解最前沿的热点知识；（4）介绍了如何从“产品总监”或者产品创始人角度来看待产品，包括企业战略究竟是什么、企业运营效率分析框架，使产品经理能够站在更高、更广的角度和层面看待产品本身。
读者通过阅读本书，可以快速建立产品设计的整体思维框架，掌握数据产品设计的方法和流程；可以了解产品研发前后端的相关技术常识和机器学习原理和过程，有助于更好地利用新技术和新方法来设计创新的数据产品；有助于理解企业战略逻辑和产品战略规划，理解企业运营效率来源，培养“跳出产品看产品”的思维方式，具有“产品总监”的思考格局。
作者
2019年12月
• 产品设计环节有哪些
• 用户需求如何发掘
• 产品设计逻辑是什么
• 产品原型及需求文档
产品经理的一项重要工作就是根据用户需求进行产品规划和设计，直接表现为根据用户需求输出产品原型图和产品需求文档。从某种程度上讲，产品经理的作用就是搭起一座“用户需求”和“产品设计”的桥梁，将“用户需求”转化为具体的“产品设计”。所以，产品设计逻辑和流程可以分为3个环节：用户需求调研梳理、产品设计流程和产品原型及需求文档，如图1-1所示。
一是用户需求。用户需求是产品规划与产品设计的逻辑起点和需求源头，产品其实就是用户需求的具体实现。
二是产品设计。产品经理在掌握了“用户需求”之后，需要按照一定的逻辑和流程来把“用户需求”转化为“产品功能”。这是产品设计的难点，也是很多讲解产品经理类内容的书籍容易忽略的地方。
三是产品原型。产品经理将“用户需求”转化为“产品功能”，其中最直观的“产品功能”载体就是产品原型和产品需求文档，这也是产品经理需要完成的主要工作任务。
下面将分别讲解这3部分内容，从而更好地帮助读者了解产品设计的整个流程和关键环节。
数据产品的本质是更好地为用户提供信息服务。数据产品设计的关键点和起点在于深刻准确地把握用户需求，而用户需求的调研需要注意“两个重点，一个难点”，如图1-2所示。
（1）重点①：对象与内容
产品提供给谁？提供什么信息？不同对象所做的决策不同，所需的“信息”内容也就不同。例如，公司副总更关注公司整体的经营情况，如现金流情况、资产周转率、客户需求变化等；而库管员工更关注库存商品存货量、每日进出库房货物数量等。因此，提供的信息内容必须“因人因事而异”。所以，用户需求调研首先应该明确产品使用对象和信息内容。
（2）重点②：环境与状态
用户需求调研，不仅需要明确产品使用对象是谁，用户需要哪些数据信息等，还要考虑用户接收信息的环境和状态。用户接收信息的环境状态不同，信息传递的效率和效果也就不同。产品经理想要达到好的信息传达效果，就必须有“跳出产品看产品”的思维，也就是考虑用户的使用场景。例如，销售人员经常在路途上奔波，那么产品经理在设计产品时就要考虑到销售人员接收信息的环境状态，尽量让手机界面只显示少数关键指标或者在关键指标预警时通过手机短信通知他们。
（3）难点：如何通透地理解需求
有时候即便产品经理就是用户本人，也不一定能够清晰完整地明确自己的产品需求，更何况大多数情况下产品经理并不是用户本人。所以，能否通透地理解用户需求是决定数据产品成败的关键，也是用户需求调研和产品设计的难点。不过，总结来说，下面几个常用的方法与技巧或许有助于产品经理更好地理解用户需求。
第一，沉浸。通过反复与用户沟通，把自己“沉浸”在用户角色之中，从而更好地体会用户需求。具体如何做到“沉浸”呢？首先，产品经理需要研究用户的岗位职责与工作内容。理解用户的需求概况，理解用户的决策事项，进而理解用户完成决策任务所需的信息要素构成情况。例如，究竟要解决哪些问题，针对这些问题做决策需要哪些信息，哪些信息是可以获得的，等等。其次，产品经理需要迅速把自己想象成“小白”，时刻体会自己第一次见到产品时所接收的信息和作出的反应。这也就是：1秒把自己变成对产品毫无所知的“小白”用户，仔细体会自己初次接收信息时的反应。最后也是最重要的，就是反复和用户沟通确认。
第二，防止被误导。很多时候，用户一上来就告诉产品经理他需要某个详细的功能，这时注意千万不要被用户牵着鼻子走。产品经理必须问清楚几个问题：你为什么需要这个功能？你想用这个功能做什么？这个功能解决了你业务上的什么问题？有没有更好的方式或方法满足你的需求？
第三，明确主次。有些用户需求是重要的，而有些是次要的；有些功能要求是重要的，而有些是次要的。产品经理进行用户需求调研和数据产品设计时必须优先解决重要的、核心的需求，这样才能保证在有限的时间和精力下实现最优的效果。
产品经理进行用户需求调研、搜集用户需求之后，还需要对用户需求进行梳理，从而方便产品经理和研发人员更好地理解业务流程和用户需求点。下面介绍几种用户需求和业务流程梳理的工具。
1. 业务流程图
业务流程图是用来描述业务流程的一种图示方法，通过符号和连线来表示具体业务的实际处理步骤和过程，进而描述任务流程走向。典型的业务流程图如图1-3所示。
一般来说，业务流程图通过开始（结束）、判断、连接线等元素来表示业务过程，如表1-1所示。
产品经理或需求研究人员在绘制业务流程图时，需要注意几个原则。
（1）先梳理战略，后梳理流程
不管是ToC（To Consumer，即面向消费者）产品还是ToB（To Business，即面向商业组织）产品，首先都要明确产品的战略定位。因为只有产品的战略定位明确了，产品经理才知道哪些流程是重点和关键，哪些流程是次要和辅助，进而才能明确流程梳理过程的轻重缓急。
对于ToB产品而言，这条原则尤其重要。因为很多ToB产品都是服务于企业内部人员的。企业所有人员的活动都服务于企业战略目标和核心竞争力的培育，所以建议所有ToB产品经理要特别注意去理解企业或产品的战略定位，从而更好地梳理业务流程。
（2）先主干流程，后枝叶流程
业务流程按照不同的颗粒度可以划分为详细度不同的流程。这也就是说业务流程可简可繁，关键是产品经理对提取信息颗粒度的选择。那么如何选择合适的颗粒度呢？根据人的认知规律，短时记忆一般为5~9个事物，所以建议主干流程活动步骤为5~9个。更加详细的信息可以在二级或三级枝叶流程中再展示，如图1-4所示。
通过以上分级展示，既可以保证主干流程的清晰明了，又可以保证关键细节的梳理展示。这样，通过业务流程图绘制，产品经理和相关研发人员对于产品所描述的业务过程容易产生一个整体的认识。
2. 数据流程图
业务流程图虽然能够帮助产品经理和研发人员理解业务逻辑，但是研发人员更关注的是业务流程中数据的流转过程，所以需要进一步从数据角度来探讨整个业务流程，这就是数据流程图的作用。
数据流程图是全面描述系统数据流程的主要工具，它用一组符号来描述整个系统中信息的全貌，综合反映出信息在系统中的流动、处理和存储情况。数据流程图有两个特征：抽象性和概括性。抽象性指的是数据流程图把具体的组织机构、工作场所、物质流都去掉，只剩下信息和数据存储、流动、使用及加工情况。概括性则是指数据流程图把系统对各种业务的处理过程联系起来考虑，形成一个整体。数据流程图包含的基本元素如表1-2所示。
典型的数据流程图如图1-5所示。
数据流程图绘制是从确定外部实体开始的，然后进行流程梳理，重点关注流程中数据的流转过程，包括多个步骤，如表1-3所示。
3. 实体关系图
如果说数据流程图更多的是动态展示数据流转的过程，那么实体关系图则更多的是静态展示某个环节的逻辑对应关系。
实体关系图是由美籍华裔计算机科学家陈品山发明的，是概念数据模型的高层描述所使用的数据模型或模式图，主要是用于数据库和表结构的设计。典型的实体关系图包含4种元素，如表1-4所示。
实体关系图能够帮助我们理解数据之间的关系，一般有3种关系。
（1）一对一关系
例如，淘宝用户账号与支付宝账号关联之后，进行免登录支付时，淘宝用户账号和支付宝账号就是一对一的关系。用实体关系图表示，如图1-6所示。
（2）一对多关系
例如，一个淘宝用户账号可以下达多个订单，这里的淘宝用户账号和订单之间就是一对多的关系，如图1-7所示。
（3）多对多关系
例如，一个淘宝用户账号可以购买不同的商品，一个商品可以被不同的淘宝用户账号所购买，这里淘宝用户账号和商品之间就存在着多对多的关系，如图1-8所示。
数据对象包含很多属性，而属性也是一类数据，所以绘制实体关系图时要注意区分实体和属性。在实践中，某个事物是作为实体还是属性并没有明确的界定，需要根据具体情况和需要而定，一般遵循如下准则。
①属性不可再分。属性不再具有需要描述的性质。
②属性不能与其他实体发生联系，关系只存在于实体与实体之间。
4. 各种图的联系和区别
上面分别讲述了需求梳理过程中常用的几种工具，如业务流程图、数据流程图、实体关系图，那么它们有什么联系和区别呢？
①流程图的作用是帮助我们理解业务过程，也就是搞清楚事情究竟是怎么流转的。但是流程图不够详细和细致，还不能直接提供给开发人员使用。这就需要产品经理站在开发人员的角度进一步细化流程，主要是从数据流转和各个对象逻辑关系角度去描述事情的过程，也就是需要用到实体关系图和数据流程图。
②实体关系图和数据流程图分别从逻辑关系角度和数据角度描述业务过程，这两者有什么区别呢？简单说来，实体关系图是静态描述，更像是“照片”；而数据流程图是动态描述，更像是“视频”。数据流程图从数据角度来梳理业务流程，明确数据的流入和流出过程；实体关系图主要关注某个数据流转环节中实体之间的逻辑关系。
“用户需求”实际上是一系列用户需求点的集合，可以简称为“用户需求集”。“产品原型”实际上是一系列产品信息点和功能点的集合。产品经理设计产品时一个很重要的工作就是将“用户需求”有序地组织和转化为“产品原型”，具体体现就是设计出合理有序的产品原型图。产品设计可以细分为“数据信息”和“展示交互”两个层面，其中数据信息是展示交互的前提和基础。数据信息层面既包括信息点之间的次序和路径，也就是信息路径设计，也包括单个信息点的设计；而展示交互层面主要体现为单个信息点的信息展示和交互操作。从这个意义上讲，数据产品设计的核心逻辑包括：信息路径设计和信息点功能设计。
1. 什么是信息路径
很多人会直观地把产品经理的工作内容等同于“画原型”，毕竟产品经理最重要的交付物就是产品原型。实际上产品原型只是产品方案的一个直观体现，是一个阶段性的交付物。产品经理在开始动手画原型之前还有一个重要的工作要做，那就是设计信息路径。笔者认为，可以将产品设计从“数据信息”层面分为“信息点”与“信息点之间依存关系”两个部分，也就是说设计产品时不仅要考虑展示哪些信息点，还要考虑信息点展示之间的次序和关系。这里所说的“信息点之间的依存关系”就是“信息路径”。
当我们逛商场购买剃须刀时，我们会先看看商场的导视图，确认超市处于商城的哪一层；然后进入超市区域，再查看超市的导视图，找到日用品货架位置；走到日用品货架位置，最终找到自己需要的剃须刀。这里，我们通过导视图使用了“楼层-区域-货架-位置”这样的定位路径，很便捷地找到了自己所需要的剃须刀。其实，商场设计的“楼层-区域-货架-位置”信息展示路径，就是一个“信息路径”的案例。
回到数据产品中来，有些数据产品或某些网站信息层级清晰明了，这让用户使用或浏览起来非常便捷。而有的产品或网站信息杂乱无章，导致用户体验极差。这其中的差距大多由于两者信息路径设计水平的差别。信息路径设计完成之后的成果，有的书籍或文章也将其称为“信息架构”。这里需要补充说明的是，本书中提出的“信息路径”更侧重于从用户接收信息的全过程来思考产品设计，而“信息架构”侧重于从最后产品呈现的结果状况来描述产品设计，本质上都是表示“信息点之间的依存关系”。
2. 信息路径设计思想
信息路径设计能更加准确、快速、高效地传递信息要点，便于用户更高效、更舒适地接收和反馈信息。设计信息路径时主要考虑两方面因素：第一，人类固有的信息认知规律，例如，信息接收的层级与路径（如宏观-中观-微观）；第二，使用场景对于信息接收的影响，例如，滴滴司机在开车过程中接单，接收的订单信息必须简单明了。我们进行信息路径设计时必须依据上述两方面因素，如图1-9所示。
3. 信息传递规律
数据产品的作用从某种意义上讲就是将数据中蕴含的信息点高效地传递给用户。用户接收产品信息的效率和效果会受到人类固有认知规律的约束，所以了解用户信息接收规律对于产品设计具有重要意义。产品经理需要了解一些基本的认知规律。
（1）短时信息容量
哈佛大学心理学家乔治·米勒发现，普通人的心智不能同时处理7个以上的单位。我们可以随机询问朋友使用的某款产品，询问他是否记得同类产品的其他品牌。大部分情况下，普通人只能记得1~3个竞争品牌的名字，极少数人能够记得超过7个品牌名称。这也佐证了人类大脑短时记忆的规律：不能超过7个信息点。
（2）大脑厌恶混乱的信息
心理学中有个著名的“格式塔效应”，揭示了我们大脑倾向于从混乱中寻找模式，极力从不同的信息点中寻找规律和联系，而厌恶混乱的信息。
（3）大脑认知抗拒改变
大脑认知还有一个特征就是一旦形成了固定认知，改变起来极其困难。例如，由于宝洁公司大量的广告轰炸，人们一想起“去屑”就会想到“海飞丝”；一想到“柔顺”就会想到“飘柔”。再如，虽然淘宝的物流速度大大提升了，但是一想起“送货快”，人们还是首先想起“京东”。市场营销中的“定位”学派，正是利用人类认知的这个特征，通过各种营销手段来抢夺用户的“心智”。
4. 用户使用场景
用户接收信息的效率和效果不仅受到人类固有认知规律的约束，也受到用户产品使用场景的影响。比如，滴滴司机开车过程中接单的页面，信息就必须简洁清晰，字体尽可能大，字尽可能少。
产品经理设计产品时需考虑用户产品使用场景，从信息角度来看，就是要考虑产品使用场景的时空因素对于用户接收信息的影响，这也是信息路径设计时需要重点关注的方面。
（1）使用场景的时间特征
关注产品使用场景的时间特征就是关注产品使用的时间长度和时间分布。产品经理需要明确用户主要在什么时间点使用、使用时长为多久，从而考虑信息点呈现的数量和次序。
（2）使用场景的空间特征
关注用户产品使用场景的空间特征就是关注用户产品使用的空间位置和特点。例如，用户是在户外使用还是办公室使用？用户是在静止环境下使用还是在移动环境下使用？
总的说来，用户使用场景也是影响用户信息接收的一个重要因素，不仅会影响信息路径的设计，也会影响单个信息点的呈现形式。
5. 常见的信息路径
产品经理进行信息路径设计时既要考虑用户的认知规律，也要考虑用户的使用场景，从而清晰地知道用户信息接收的具体特征，便于设计对应的信息路径。
人们认识事物总是首先关注宏观和整体概况，从而有个全面的图景和认识；然后关注细微层面的东西。例如，人们听到某个地址，习惯的思维是先了解这个地址是哪个国家、哪个省、哪个市、哪个区、哪个街道，呈现一种“宏观-中观-微观”的信息递进路径。
同样，设计产品时一种常见的信息路径设计思路就是：首先向用户传递宏观层面的信息，让用户有个整体的感知；然后传递中观层面的信息，让用户能够聚焦到某个行业或区域；最后递进到微观层面，让用户了解具体的详细信息。这样，用户就像是查看地图一样，从宏观层面到中观层面再到微观层面，根据自己的需求不断递进，不断细化信息颗粒度。从“宏观-中观-微观”角度层层递进展示信息，是一种常见且有效的信息路径。
不过，有时候用户会对某个或某些信息点特别关注，这就需要产品经理使用另外一种信息路径“重要-次重要-次要”。
另外，在一些情况下，信息点的时间维度特征非常明显，例如，设计一款监测系统，对于“事前”“事中”和“事后”的监测指标数值的展示，就要考虑从时间维度展开进行信息路径设计。
总的来说，信息路径设计并不是一成不变的，它更为重要的意义在于提醒产品经理重视信息点之间呈现的关系。常见的信息路径可以归纳为以下几种。
①按逻辑关系区分：宏观-中观-微观。
②按用户关注度区分：重要-次重要-次要。
③按时间维度区分：事前-事中-事后。
除了上面的信息路径设计思路，实践中也有一些常见的经验做法可供借鉴参考和补充。
（1）按照功能相似性进行信息分类
产品经理在设计信息路径时，经常把相似功能模块放置在一个大的模块下，作为大功能模块的一部分。例如，微信中的“消息”包含了好友消息、群消息、订阅号消息、文件助手消息、陌生人消息等。虽然各种消息在存在差别但是都属于消息大类，所以我们会发现这些消息子模块都在归集在“微信”功能模块下面。而探索性质的或者时效性要求不高的模块，则归集放置在“发现”功能模块下。例如，“朋友圈”“扫一扫”“摇一摇”“看一看”“搜一搜”“附近的人”“购物”“游戏”等子模块都归集在微信产品的“发现”功能模块下面，如图1-10所示。
（2）按照使用频率来设置展示位置
哪个功能使用频率高，就应该把哪个功能放在用户最容易浏览或者交互的地方。例如，支付宝的“收付”功能是使用频率最高的功能，所以“收钱”和“付钱”放在顶部位置。对于大众来说，“付钱”功能使用频率会比“收钱”功能更高，所以“付钱”功能排在“收钱”功能前面。而“付钱”功能中扫码付钱相对于被别人扫码付钱发生的频率更高，所以“扫一扫”功能又放在了“付钱”功能前面，如图1-11所示。
（3）按照功能之间的业务关系来规划层级关系
功能与功能之间，一般有并列、递进、互斥等几种关系。功能之间如果是递进关系，设计信息路径时可以考虑纵向递进关系，例如，在京东商城购物时，“下单”和“支付”就是递进关系，用户需要先“下单”，之后才能够进行“支付”。
产品设计不仅要考虑“信息点之间的依存关系和次序”，也要考虑单个信息点的交互与展示，这就是信息点功能设计。信息点功能设计可以分为“交互”和“展示”。其中，交互主要是指信息的“增删改查”，展示则是指信息的“可视化展示”。
①信息增添：在进行信息点功能设计时，有时候需要用户通过交互按钮实现信息的录入或添加。例如，淘宝网购物时的“新增收货地址”等交互。
②信息删除：在进行信息点功能设计时，有时候需要用户通过交互按钮实现信息删除。例如，用户可以在电子商务平台删除过往的购物记录。
③信息修改：在进行信息点功能设计时，有时候需要用户通过交互按钮实现信息修改。例如，用户修改“收货地址”或“联系电话”等。
④信息查询：在进行信息点功能设计时，经常需要用户通过交互按钮实现信息查询。对于大部分数据产品而言，信息查询是用户使用频率非常高的功能，需要重点关注。例如，时间筛选、区域筛选、文字搜索、排序等都是信息查询常见的功能设计。
而信息点的“展示”主要体现为“可视化”设计，这部分内容将在数据可视化章节进行详细讲解。
产品经理从用户需求出发，依据产品设计逻辑和流程将用户需求转化为产品原型和需求文档后，研发人员才能够根据产品原型和需求文档开始研发工作。所以，产品原型和需求文档既是产品设计流程的结果，又是产品研发流程的开始。
原型图，也被称为线框图，是产品经理将用户需求转化为产品解决方案的重要载体，是产品经理与研发人员进行沟通的重要工具。根据原型图与真实页面的仿真程度，可以把原型图分为高保真、低保真两类；根据原型组件交互描述的详细程度，可以把原型图分为高精度、中精度、低精度三类原型图。
（1）两类保真度原型图。
高保真原型图在布局和画面上尽可能还原了真实的页面状况，能够很好地体现出真实效果，用户体验较好，但是实现成本较高，需要花费大量的精力和时间处理，适用于产品方案已经确定的阶段。低保真原型图布局和画面的仿真程度较低，有时甚至使用笔来简单勾画出草图，方便讨论和修改，适用于产品方案构思的初期。
（2）三类精度原型图
除了按照原型图对真实页面的仿真程度进行分类，还可以按照原型图交互细节描述详细程度进行分类，分为高精度、中精度和低精度原型图。
高精度原型图：高精度原型图详细展示原型中各组件的操作细节和交互细节，往往使用大量图文说明来描述产品细节和设计意图。
低精度原型图：低精度原型图使用页面流程图等简易方式，快速展示主要操作逻辑和流程，集中力量展示关键组件的展示逻辑。
中精度原型图：中精度原型图介于高精度原型图和低精度原型图之间，各个组件的操作交互细节描述的详细程度也介于两者之间。一般而言，典型的中精度原型图包括页面布局、导航栏、关键组件、文案说明等内容。
（3）两种分类的区别和联系
高保真、低保真原型图和高、中、低精度原型图既有联系又有区别。高保真和低保真原型图是以原型图对真实页面的仿真程度进行划分的，高、中、低精度原型图是以原型图组件操作交互描述详细程度进行划分的，两者的划分标准不一致，这是两者的区别；但是实践中，一般高保真原型图对于组件操作交互的描述也会特别详细，而低保真原型图为了满足快速交流的需求，仿真程度较低，同时组件交互描述也往往较为粗略，所以高保真原型图往往也是高精度原型图。
产品设计是一个将用户需求由抽象概念转化为具象化产品的过程，经常需要借助文字或图像进行展现，这就是产品需求文档（Product Requirement Document，PRD）。PRD主要是给设计、研发等相关人员阅读的文档，目的是告诉这部分人员产品页面内容、交互规则和输出结果等详细信息，像是一份详细的产品功能需求说明书。
1. PRD概述
PRD是产品经理用来跟技术开发人员和其他相关人员进行沟通的辅助文本工具，由产品经理负责撰写。这里有两点需要注意。
第一，它是文本工具。这也就是说，相对于口头沟通，PDR能够使沟通过程和沟通意见落在纸上，同时也为后期沟通提供了文字记录，便于查询。
第二，它是辅助沟通的工具。PRD不是用来划分责任归属的，而是用来辅助沟通的。大量的沟通还是要通过产品经理和技术开发人员口头交流来完成，PRD只是把沟通的关键性结果做一个留档和备份，便于后期随时查询使用。
一般说来，一份完整的PRD至少包括3个部分：需求描述、功能描述和变更记录。
2. 需求描述
需求描述是告诉技术开发人员和相关人员“为什么要设计开发这个功能”，是产品存在的基础和前提。很多产品会越设计越复杂、越设计越臃肿，就是因为产品经理设计添加产品功能时并没有严肃认真思考每个功能的需求情况，经常灵光一现随意增加产品功能。产品需求根据对象的侧重不同可以区分为：业务需求和用户需求。
业务需求：业务需要表达的是组织或客户高层次的目标。业务需求侧重描述组织为什么要开发该款产品或者希望通过这款产品达到什么目标，它通常表达的是项目投资者、产品购买客户等的需求。
用户需求：用户需求是指产品的功能满足了用户某个场景下的使用需求，解决了用户的某个问题。这主要是从用户角度来定义和阐述的需求，描述了用户能使用系统来做些什么。例如，用户需要对产品的全球销售情况有一个直观和宏观的印象，这就需要给用户提供一个可视化界面，直观地展示产品全球销售的关键信息点。
3. 功能描述
功能描述规定了开发人员需要在产品中实现的软件功能，用户可以使用这些功能来满足其业务需求。功能描述既可以从人和系统的旁观者角度来描述，也可以从产品角度来描述。前者叫用例描述，后者叫功能点描述。实践中，功能点描述多采用在Axure原型图旁边注释的方式，而用例描述更多采用PRD方式来详细论述。
无论是用例描述还是功能点描述，其最终目的都是希望研发人员能够快速清晰地理解产品功能需求。所以，一般包括以下内容。
交互规则：交互规则是指使得产品元素状态发生改变的规则和规范，既包括用户交互规则，也包括元素状态自动变化的规则。例如，用户操作产品页面上各种交互元素和组件（筛选按钮、滑动条）使得产品状态发生改变；或者系统自动设定了元素状态变化规则，如电商平台自动设定了打折时效期，一旦过了该段时间，商品价格自动复原等。
数据规则：数据规则主要是指数据产品展现层与数据库进行数据交互的规则。例如，用户通过注册页面输入信息并存储在数据库中，那么就需要指明注册页面包括的字段、每个字段的类型及长度等内容。
4. 变更日志
变更日志的编写并不复杂，但是一些产品经理常常因为怕麻烦而忽略了，这往往给产品研发带来不小的隐患。
产品需求变动其实是很正常的事情，但是如果需求变动没有及时记录，那么可能会出现这样的情况：产品经理想表达的是A，结果表达成了B，技术开发人员听到的是B，理解的内容却是C，最后因为客观限制把产品做成了D。如果及时把需求变动记录在PRD上，那么技术开发人员和产品经理沟通就不仅限于当时口头沟通的“一瞬间”，而是有了可以进一步细致讨论的基础和材料，使得双向细致的沟通成为可能。
另外，如果产品需求变动不及时记录，一段时间后可能会因为遗忘导致各种问题。现实中，很多时候产品需求发生了变化，产品经理即时与技术开发人员进行了沟通，但是忘记将变化结论记录在PRD中。一段时间后，产品经理或者技术开发人员可能就遗忘了这个变化，导致最后上线产品跟预期效果不一致。
最后，产品原型不可能一步到位。凡是有实践经验的人都应该深有体会，每次产品原型进行更改后，如果不及时记录更改的地方，技术开发人员肯定是“头大加火大”。因为他们完全不知道你修改了哪些地方。这些情况下，及时更新日志就显得很重要了。有了更新日志，大家一看日志就知道产品经理改了哪些地方，进而直接锁定修改目标，大大提升研发效率和开发进度。
因此，一个合格产品经理一定要养成及时记录变更日志的良好习惯，也要对变更日志给予足够的重视。
