写给产品经理自己看的产品白皮书

　　一、产品白皮书的定义
　　在日常工作中产品经理需要编写许多种文档：
　　产品规划环节：竞品分析、产品规划、MRD
　　产品设计环节：需求列表、PRD
　　产品运营环节：用户手册&FAQ、产品运营报告
　　但我认为除了上述这些文档，产品经理还需要时刻维护一份白皮书，记录自己所负责产品的完整视图，至少包含如下内容：
　　1、产品介绍
　　产品简介、产品在公司整体产品矩阵中的位置及与其他产品的关系、产品演化方向、各个迭代版本的重要新增功能。
　　2、系统架构
　　产品架构图、各个系统模块的作用及关系、业务流程图、系统时序图。
　　越多了解系统架构的知识，就越能深入理解产品运行的系统机制，有助于与开发同学高效地沟通需求。
　　3、产品功能
　　产品功能列表、前置及后置条件、分支及异常逻辑、产品规则及各类配置参数。
　　举个例子，假设让你接手目前很火的Apple Pay产品，那么你不光要了解正向支付流程，也要关注逆向退款流程，如果产生退款时用户的付款信用卡已销卡导致无法退款，这种情况下退款资金将滞留在哪里？后续如何将资金退给已销卡的用户？这些分支逻辑都是需要了解的。
　　4、产品后台
　　客服、运营、数据统计等后台功能介绍。
　　如用于受理客户投诉的后台查询功能；用于查询产品新登、活跃、流失的数据日报月报及数据趋势图，关键业务流程或功能的数据量；业务监控报警等。
　　二、为什么需要产品白皮书？
　　为了能够全面熟悉自己所负责的产品并做好产品的知识传承工作。
　　具体解释下：
　　互联网产品是迭代发展的，在一个产品的生命周期内，将面临由于人员和业务不断变化造成的种种问题。
　　人员变化：随着部门调整及员工流动，一个产品对应的产品经理、开发测试同学在几年内可能更换了多轮。
　　业务变化：随着业务不断发展，一个产品会经历无数个迭代发展，不断有新功能上线、老功能下线甚至系统重构。
　　上述两种变化将导致产品的业务规则、特殊逻辑和各种坑越积越多。而描述产品细节的文档却散落各处（各种PRD、开发文档、用户手册、邮件等）甚至缺失。使得新任产品经理无法快速掌握产品各种细节，有些产品分支或异常逻辑只能找开发同学看代码才能确定，浪费了大把时间。更为可怕的是，如果新任产品经理不了解产品全貌，不了解各种坑，那就有可能犯前任犯过的错或者给后人挖了新坑。
　　由此可见，如果新任产品经理能拥有一份记录产品完整视图的文档，将会极大提升工作效率，并能降低犯错的概率。
　　新任产品经理的烦恼
　　三、如何编写产品白皮书？
　　大家在接手一个新产品后，首先要多多使用产品，把主流程和分支异常流程都走几遍，同时找相关的产品、开发、运营等同事收集各类产品资料，为编写白皮书做好准备。
　　需要收集的产品资料包括：
　　1、产品类文档：
　　MRD、PRD、竞品分析报告、用研报告、需求列表。用于了解用户、需求、市场发展趋势及现状、竞争对手情况、产品功能及业务流程。
　　2、开发类文档：
　　系统架构文档、开发设计文档。用于了解系统架构。
　　3、运营类文档：
　　客服文档、产品运营报告、数据分析报告。用于了解产品运营现状。
　　在体验产品和收集资料后，就可以参考文章开头介绍的产品白皮书结构开始编写。编写过程很像玩拼图游戏，最初白皮书的内容会很散，但随着你对产品不断深入理解，不断解决产品出现的各种问题，不断地完善白皮书内容，那么几个月下来，就能拼出完整的产品视图文档。
　　就我自己而言，每当我解决了一个产品问题，并把解决过程中发现的产品细节纳入白皮书时，眼见着白皮书内容不断完善，不断拼出全貌，就很有成就感。
　　需要强调的是，这份白皮书不是写出来就完了，而是要不断更新，以保证内容的准确性。
　　四、产品白皮书的好处？
　　以我自己为例，曾经在5个月内，持续利用零散的碎片时间，为自己负责的产品整理出120页的产品白皮书。虽然期间花费了很多精力，但写完后发现带来的好处溢于言表：
　　别人问起产品细节时，因为对各种逻辑及规则了如指掌，所以马上就能给出答案，提高同事对产品经理的信任感。
　　排查产品问题时，因为对产品的前后台功能逻辑，异常分支都很清楚，所以能很快就能定位问题原因，节省了很多时间。
　　新产品设计时，考虑得更加全面。
　　老产品优化时，因为对产品的各种坑都很熟悉，结合业务发展现状，能制定出更有针对性的优化策略及方案。
　　有新人加入团队时，使用产品白皮书进行培训，让新人快速了解产品全貌，少走弯路。同时也降低因人员流动给产品造成的巨大影响。
　　正是由于编写产品白皮书有如此多的好处，所以我在此极力向大家推荐这种工作方式，希望能够帮助到各位同行。