产品撸技术方法论PM相关杂文

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

2016-02-24  本文已影响3687人  酷拉皮卡
一、产品白皮书的定义

在日常工作中产品经理需要编写许多种文档:

1、产品规划环节:竞品分析、产品规划、MRD

2、产品设计环节:需求列表、PRD

3、产品运营环节:用户手册&FAQ、产品运营报告

但我认为除了上述这些文档,产品经理还需要时刻维护一份白皮书,记录自己所负责产品的完整视图,至少包含如下内容:

1、产品介绍

产品简介、产品在公司整体产品矩阵中的位置及与其他产品的关系、产品演化方向、各个迭代版本的重要新增功能。

2、系统架构

产品架构图、各个系统模块的作用及关系、业务流程图、系统时序图。

越多了解系统架构的知识,就越能深入理解产品运行的系统机制,有助于与开发同学高效地沟通需求。

3、产品功能

产品功能列表、前置及后置条件、分支及异常逻辑、产品规则及各类配置参数。

举个例子,假设让你接手目前很火的Apple Pay产品,那么你不光要了解正向支付流程,也要关注逆向退款流程,如果产生退款时用户的付款信用卡已销卡导致无法退款,这种情况下退款资金将滞留在哪里?后续如何将资金退给已销卡的用户?这些分支逻辑都是需要了解的。

4、产品后台

客服、运营、数据统计等后台功能介绍。

如用于受理客户投诉的后台查询功能;用于查询产品新登、活跃、流失的数据日报月报及数据趋势图,关键业务流程或功能的数据量;业务监控报警等。

二、为什么需要产品白皮书?

为了能够全面熟悉自己所负责的产品并做好产品的知识传承工作。

具体解释下:

互联网产品是迭代发展的,在一个产品的生命周期内,将面临由于人员和业务不断变化造成的种种问题。

1、人员变化:随着部门调整及员工流动,一个产品对应的产品经理、开发测试同学在几年内可能更换了多轮。

2、业务变化:随着业务不断发展,一个产品会经历无数个迭代发展,不断有新功能上线、老功能下线甚至系统重构。

上述两种变化将导致产品的业务规则、特殊逻辑和各种坑越积越多。而描述产品细节的文档却散落各处(各种PRD、开发文档、用户手册、邮件等)甚至缺失。使得新任产品经理无法快速掌握产品各种细节,有些产品分支或异常逻辑只能找开发同学看代码才能确定,浪费了大把时间。更为可怕的是,如果新任产品经理不了解产品全貌,不了解各种坑,那就有可能犯前任犯过的错或者给后人挖了新坑。

由此可见,如果新任产品经理能拥有一份记录产品完整视图的文档,将会极大提升工作效率,并能降低犯错的概率。

新任产品经理的烦恼
三、如何编写产品白皮书?

大家在接手一个新产品后,首先要多多使用产品,把主流程和分支异常流程都走几遍,同时找相关的产品、开发、运营等同事收集各类产品资料,为编写白皮书做好准备。

需要收集的产品资料包括:

1、产品类文档:

MRD、PRD、竞品分析报告、用研报告、需求列表。用于了解用户、需求、市场发展趋势及现状、竞争对手情况、产品功能及业务流程。

2、开发类文档:

系统架构文档、开发设计文档。用于了解系统架构。

3、运营类文档:

客服文档、产品运营报告、数据分析报告。用于了解产品运营现状。

在体验产品和收集资料后,就可以参考文章开头介绍的产品白皮书结构开始编写。编写过程很像玩拼图游戏,最初白皮书的内容会很散,但随着你对产品不断深入理解,不断解决产品出现的各种问题,不断地完善白皮书内容,那么几个月下来,就能拼出完整的产品视图文档。

就我自己而言,每当我解决了一个产品问题,并把解决过程中发现的产品细节纳入白皮书时,眼见着白皮书内容不断完善,不断拼出全貌,就很有成就感。

需要强调的是,这份白皮书不是写出来就完了,而是要不断更新,以保证内容的准确性。

四、产品白皮书的好处?

以我自己为例,曾经在5个月内,持续利用零散的碎片时间,为自己负责的产品整理出120页的产品白皮书。虽然期间花费了很多精力,但写完后发现带来的好处溢于言表:

1、别人问起产品细节时,因为对各种逻辑及规则了如指掌,所以马上就能给出答案,提高同事对产品经理的信任感。

2、排查产品问题时,因为对产品的前后台功能逻辑,异常分支都很清楚,所以能很快就能定位问题原因,节省了很多时间。

3、新产品设计时,考虑得更加全面。

4、老产品优化时,因为对产品的各种坑都很熟悉,结合业务发展现状,能制定出更有针对性的优化策略及方案。

5、有新人加入团队时,使用产品白皮书进行培训,让新人快速了解产品全貌,少走弯路。同时也降低因人员流动给产品造成的巨大影响。

正是由于编写产品白皮书有如此多的好处,所以我在此极力向大家推荐这种工作方式,希望能够帮助到各位同行。

上一篇下一篇

猜你喜欢

热点阅读