产品是PM的最终输出，对PM的KPI考核是产品的各种数据指标，所以产品规划、产品设计、产品文档、产品迭代等显得尤为重要。
七、产品规划
产品规划的来源主要是各类数据指标，主要市场表现情况，而这些情况不仅仅是通过第三方查询，而且还有存在于产品本身的埋点数据，所以做好埋点是一个PM的分内工作，尤其是C端产品经理。
7.1、产品规划过程中，往往需要数据进行辅助
（1）如何利用用户的使用数据来为后续的产品迭代提供依据；
（2）如何向上级领导汇报产品成果；
（3）如何做精细化的运营活动；
7.2、埋点文档的定义、分类以及数据平台
7.2.1、什么是埋点文档
（1）例如账单-开销，记录钱花在哪里了，哪里该花哪里该省，有类别，有调整；
（2）就是定义好的产品账本，记录产品的收支情况，例如哪些功能被哪些用户使用多少次，哪些页面用户流失率高，哪些内容被哪类用户喜欢；
7.2.2、埋点文档的分类
（1）前端埋点
记录用户在客户端的使用数据，包括但不限于网页、APP、PC客户端等；
优势：事无巨细的统计到用户的行为数据；
劣势：为了性能考虑，不会实时上报数据，所以数据在时效性和准确性上不会做到100%精确无误；
（2）后端埋点
记录程序接口的调用情况，例如接口访问次数，接口返回各个状态次数的统计等；
有时候：统计的数据实时且精确，采用接口将数据在指定的触发条件下上报至服务器；
7.2.3、前端埋点的三种方法
（1）代码埋点
在程序中加入用户统计数据的代码，当指定的触发行为发生的时候，就统计用户的使用数据；
例如：统计某个活动页的运营效果，则触发行为是用户点击活动页的入口，并且同时上报用户本身的数据，如ID；
优势：可以根据使用者的需要任意地选择在什么时候发送什么数据，并且可以自定义丰富的数据属性；
劣势：对于PM对业务的理解程度和用户的理解程度要求较高，需要知道什么数据需要被收集；每一次加入埋点代码都会带来相应的工作量，每一次更新埋点代码会引起新旧版本的不兼容问题；总会有一些用户不会更新到最新的版本；
（2）可视化埋点
一般由第三方数据平台提供，可以通过非常直观的形式管理数据追踪点，通过圈选页面元素来实现数据的收集；
例如：talkingdata的灵动分析；
优势：每次更新埋点的时候不需要等待程序更新，而是把数据统计的代码在程序启动的时候通过网络更新配置，解决了产品临时想要加入或修改埋点的需求；
劣势：不能灵活的自定义事件，只能使用平台提供的一些通用性事件，例如点击次；无法支持，产品希望收集到用户在文本框中输入的内容，或者产品需要做大数据分析或人工智能推荐系统等要求；
（3）无埋点
又称全埋点，尽可能的收集所有控件的操作数据，然后通过界面配置的方式添加一些需要统计的数据；
优势：可以解决数据的回溯问题，即使之前的版本没有对某一个控件做精确的埋点，一样会收集这个控件的数据；
劣势：不能灵活的自定义事件，仅能分析用户在产品中的交互行为；会产生大量不必要的数据，给服务器带来更多负载；
7.3、如何写埋点文档
7.3.1、选择数据平台
（1）第三方数据平台
Google Analytics、百度统计、talkingdata等；
（2）自有开发数据平台
（3）购买数据平台进行私有化部署
7.3.2、查看平台技术文档
（1）数据上报的限值
（2）字段命名的差异
（3）重要功能
（4）如何集成
7.4、埋点文档实例
（1）eventID：定义页面的ID号和名字 -- 英文字母+数字 -- 例如：A01-首页；
（2）label：定义用户在这个页面上的使用行为，从属于eventID -- 例如：A0101-点击搜索按钮；
（3）上报时机：说明这个埋点事件根据什么条件来触发 -- 显示时触发（曝光量）、操作时触发（转化量）、构建曝光-转化的漏斗模型 -- 例如：用户点击时/页面显示时；
（4）上线时间：说明该埋点什么时候上线 -- 例如：2019/1；（注意：最好是时间，而不是版本号，产品不同平台的版本号码不一样，会导致混乱。版本号无法体现埋点的生效时间，需要通过历史的产品文档查找对应的功能才能知道，不够直观）
（5）优先级：代码埋点需要开发花费时间来进行代码的编写，所以与功能需求池一样，需要标注埋点的优先级，以便评估工作量 -- 例如：P0；
（6）备注：进行一些说明；
7.5、自定义事件
代码埋点的核心是自定义事件的属性，也就是在上报事件的时候，同时上报这个事件定义的属性；
7.5.1、什么是数据字典
定义自定义事件属性的文档
（1）key：核心内容，表示的是属性的名称，例如user_ID；
（2）注释：对key字段的解释，用来说明key值代表什么，便于后续查询；
（3）数据类型：分为名义数据、等级数据和连续数据（统计学知识）；
（4）value：key对应的值，限值kay的范围；
（5）全局字段global：某些key值是需要所有的事件都要进行统计的；
7.5.2、如何给key命名
（1）驼峰命名法
小驼峰命名法：userName；
大驼峰命名法：UserName；
（2）下划线命名法：User_Name
7.5.3、将自定义事件的属性添加到事件中，就是把自定义事件加入埋点文档中
7.6、埋点文档注意事项
（1）埋点文档只可增加，不可修改和删除：需要自始至终都在原有的基础上进行填写；可能会导致同一编号的功能点，在不同版本中上报了不同的事件内容；
（2）事件必须独立：例如不同的返回按钮，有不同的编号和名称；每个编号对应一个事件；
（3）数据字典不重复：所有数据字典中的每一个key都是唯一的；需要不同的PM和项目组之间随时沟通；
（4）注意平台限制：不同的埋点平台可能对于事件和属性有上限的限制；
（5）埋点测试：确保埋点的数据上报正确；
八、产品设计
这里主要介绍交互心理学相关的知识，引导产品设计。
虽然拙劣的设计俯拾皆是，但是设计出易于理解、方便使用、令人愉悦的产品并不困难；
8.1、费茨定律
8.1.1、定义
（1）目标越大，越容易点击或操作；
（2）两者的距离越近越容易操作；
8.1.2、公式
（1）t = a + b log2 ( D / S +1 )；
8.1.3、案例
（1）按钮越大越容易点击：nice、闲鱼、转转的发布栏按钮；
（2）相关联的功能按钮放在一起更容易点击：淘宝、高德地图底部操作栏相关联的功能按钮靠在一起；
（3）次要功能的按钮可以放小一点：淘宝商品的详情页面，去购买的功能层级明显大于点赞、评论、收藏；
（4）功能类型不同的按钮要放得远一点：UC浏览器详情页面的底部，返回和评论、收藏、分享功能类型不同，相隔很远；
8.2、格式塔原则
8.2.1、定义
（1）Gestalt强调经验和行为的整体性，认为整体不等于部分之和，意识不等于感觉元素的集合，行为不等于反射弧的循环；
（2）整体与个体的关系，整体和个体之间并不是单一的对等关系；
8.2.2、应用
（1）相似性：当人们看到相似特征的元素会自动将其归为一组 -- 通常参考：大小、形状、颜色、纹理等 -- 案例：贝壳租房的“资讯快递”模块；
（2）延续性：人的眼睛会自然的从一个物体移动到另一个物体，我们也更加倾向于把部分具有一定规则的独立的个体看成一个整体 -- 案例：fancy页面的活动模块下的功能入口 -- 案例：微信的发现页面；
（3）封闭性：人眼会自动将带有一定动向趋势的不完全闭合的图形看成一个整体 -- 截断式设计 -- 案例：横向交互，会在屏幕右侧故意露出一部分，告诉用户通过滑动可以看到更多内容；
（4）邻近性：人们会将邻近的元素自动归为一组 -- 案例：微信的发现页面；
（5）简单性：具有对称、规则、平滑的简单图形特征的各部分趋于组成整体 -- 案例：UC浏览器的详情页和闲鱼以及京东金融的首页，整体布局都趋于对称、规则和平滑；
8.3、本能反应
8.3.1、定义
（1）用户第一眼见到产品时的感受，而此时用户还没有与产品产生交互；
8.3.2、应用
（1）并非漂亮美观就等于本能设计；
（2）营造出干净漂亮，具有美学设计的界面更容易受到用户青睐：fancy极简化设计；
（3）注重情感设计，关注细节：淘票票的电影详情页，将预告片置顶；
（4）兼顾易用性，避免华而不实的设计：贝壳租房按区域查找房源的按钮设计和功能设计；
8.4、色彩心理学
8.4.1、定义
（1）从视觉开始，到知觉、感情，再到记忆、思想、意志、象征等，其反应与变化是极其复杂的；
（2）重视因果关系，即由色彩的经验积累而变成对色彩的心理规范；
（3）当受到什么刺激后能产生什么反应，将是色彩心理所要探讨的内容；
（4）是一种注重因果关系的心理学说，侧重于观看色彩后产生的感受；
8.4.2、应用
（1）信息指示：经过社会长期的发展和培养，人们对色彩已经有相对成熟的认知，色彩能够帮助产品传递信息 -- 案例：贝壳租房的详情页中的底部操作栏；
（2）建立印象：色彩往往是能给人建立第一印象的重要因素 -- 案例：每日故宫的界面设计；
8.5、7+-2法则
8.5.1、定义
（1）人在处理信息的时候同时最多可以处理9个，最少可以处理5个；
（2）当用户操作任务的数量越少，分散的注意力越少，正确率越高；
8.5.2、应用
（1）信息分类：用组合方式，减少用户的记忆方式 -- 案例：手机号的模块组合；
（2）优化选项：案例：APP顶部导航栏，虽然可以横轴滑动，但显示区域只保持7+-2法则；
（3）页面布局：将同类型的内容组合模块，用户可以先查询模块再寻找具体内容，提高效率 -- 案例：支付宝首页的布局；
8.6、西科定律
8.6.1、定义
（1）人在面临选择越多的时候，所消耗的时间成本越高；
（2）心理物理学定律，表征人的信息传递时间与刺激的平均信息量之间呈线性关系的定律。；
（3）公式：RT = a + B log2（n）。RT表示反应时间，a表示跟做决定无关的总时间，b表示根据对选项认知的处理时间认证衍生出的常数，n表示同样可能的选项数字；
8.6.2、应用
（1）提高选择效率：尽可能避免过多的选择摆在用户面前，否则会因为选项过多而犹豫不决，造成时间成本直线上升；保持选项足够简介，排除多余选项 -- 案例：网易云音乐，左滑删除歌单；
（2）提高信息获取效率：通过同类信息的组合提高用户对信息的接受度，使信息更加容易阅读；减少对信息进行检索再组合认知的过程；减少用户的成本输出，提高用户的阅读效率 -- 案例：淘票票的用户详情页；
（3）提高用户体验：将所有选项拆解、归类让用户按照一定的步骤在每一页尽量做少的选择；营造一种较为舒适的用户体验 -- 案例：same创建频道；
（4）建议：将任何选项，包括按钮、图片、页面保持在最低限度，消除不必要的选择，使产品的可用性更高；切勿绑架用户，限制用户的选择；
8.7、莱斯托夫效应
8.7.1、定义
（1）相对于普通事物，记住独特或特殊事物的可能性更大；
（2）特殊事物才容易被人牢记；
（3）与当前背景不同或经验不同，莱斯托夫效应就会发生；
8.7.2、应用
（1）背景不同：当前环境下，与周围元素具有明显的不同 -- 案例：闲鱼和转转的底部导航栏中的icon；
（2）经验不同：当现在发生的事情与过去经验有显著不同 -- 案例：每年的电商购物节，明显区别于日常的主界面；
（3）建议：强调重要模块或核心功能；但不能处处强调，那等同于所有的事情都不重要。
九、产品文档
本章介绍流程图UML（统一建模语言）。
9.1、意义
（1）流程图的背后是逻辑清晰的表达和思考；
（2）先有流程图，再有原型图；
9.2、如何画
（1）流程图是为了完成某一任务而描述的相关活动的执行顺序；
（2）活动的概念：主语+谓语+宾语 -- 一个人做了什么事 -- 活动之间用箭头的线连接在一起，称之为转移 -- 表示做完了一个活动可以转移到下一个活动；
（3）起点和终点；
（4）判断和并行；
（5）汇合和合并；
9.3、注意事项
（1）流程图中不应有非活动的内容；
（2）流程图不同于状态图；
（3）流程图的逻辑需要仔细思考；
十、产品迭代
10.1、好产品是迭代出来的
（1）真正的用户需求是在用户使用产品中不断被发现和满足的；
（2）用户总会有新的需求；
10.2、为什么迭代（1.0-2.0版本）
（1）解决遗留问题（1.0版本）：如未修复的bug、为满足的需求、未开发完成的版块等；
（2）新增需求或功能点（1.1-1.N版本）：运营需求、也无需求、财务需求等相关部门；
（3）产品本身迭代（2.0版本）：在用户调研、需求调研、市场调研完成后，随着市场变化、思维变化、理念变化，保证产品与时俱进，大胆创新；
10.3、如何迭代
10.3.1、流程
各部门提出需求-产品汇总需求-发起需求评审会-确定需求，判断优先级（签订需求评审单）-产品设计原型-原型评审-UI评审-开发；
10.3.2、挖-判-定
（1）挖：挖掘用户对产品的真实评价及建议，挖掘让用户爽的爆点等；
（2）判：判断所有需求的可行性、明确性；
（3）定：确定需求，评审会；
10.3.3、经验：
（1）做好用户沟通：多方式、多渠道了解现存问题，筛选有价值需求；
（2）做好迭代规划：根据时间节点，确定需求优先级，跟进研发排期及上线；
（3）做好需求评审：确定需求后签订需求确认单，最大限度避免需求变更，降低开发成本；
（4）做好原型评审：确定原型设计与需求相符，符合需求方要求；
（5）做好上线验收：确保功能的准确完善，无bug、无遗漏，符合上线要求；