☊ | 第十八节:四大文档-产品需求文档(PRD)

在上一节课中,我提到了,写不好MRD的有两个原因,其中有一个就是把MRD和PRD混在了一起。

那好,在本节课开始的时候,我们就先来了解一下MRD和PRD本质上的区别,大家看PPT1:

PPT1

简单对这张PPT的内容做个解释。

1)MRD用来记录市场机会、市场问题和由此产生的市场需求,它是对“市场需求集”的描述。MRD根据用户需求和从用户的角度定义产品目标。它需要从用户视角来考虑。

2)PRD源自MRD,它用来提供解决方案,预期用途和相关的功能与特征,它是对“产品功能集”的描述。也就是说,PRD提供的是一个解决市场问题和满足需求的方案。它从产品解决方案的角度定义产品功能和特征。它需要从产品的视角来考虑。

3)技术规格文档源自PRD,它是对解决方案的设计、属性和标准的高度详细描述,是关于如何构建解决方案的指导。它需要从技术实现的视角来考虑。

简而言之,MRD记录市场需求;PRD描述要满足这些市场需求的产品及其功能和特征;技术规格文档包含产品属性和构建产品所需的详细技术规范信息。

这三个文档在产品管理中,被称为是:产品定义基础文档,并由不同的团队来完成。

好,我们了解了MRD和PRD的区别,那么,PRD的结构是什么样的呢,大家看图1:

图1

接下来,我就对目录结构中的重点章节做一个介绍。

我们先来看第三章节,产品环境。

怎么来理解这个产品环境呢?

撰写说明中有解释,就是要提供详尽的信息来说明指导和限制产品前景、功能和未来发展的约束和假设条件。

产品经理应该都知道,我们做的产品不是放到任何环境下都能够完全表现出我们所定义的性能来的(或是用户具体的使用环境的多样化,或是用户对产品操作能力的不一致化),比方说电动汽车,它的电池续航水平就会受到气温的影响,春秋季的续航水平可能会比较接近标准,但是在夏冬季,续航水平就会降的很低,我问过很多开电车的出租车司机,冬天续航水平差不多会降低20%,甚至还要高。

简单来说,这部分就是要求我们定义出哪些情况会影响到我们产品性能的正常发挥,因此,我们要在这个章节把可能会影响到产品正常发挥效能的两类条件-约束条件和假设条件-说明。

3.2 约束条件

约束条件是指限制在构建产品时,开发人员会受到限制的核心因素。

比方说,刚才讲到电动汽车的续航里程会受到季节温度的影响,这就是约束条件,因为对于整车厂商来说,电池只是他们的关键配件之一,而他们生产的电动车,实际续航里程如何,其实和自己并无太大关系,关键还是在于电池厂商能否在电池技术上有革命性的突破。

在写这部分的时候,我们只需要用列表来表示就可以了。

我还是用DD来做为案例,大家看图2:

图2

3.3 假设条件

假设条件又是指什么呢?

简单说,它就是指对用户具体使用产品的一种评估。

比方说还是电动汽车,我们已经知道车的续航里程是会受到季节温度影响的,这是目前制约电动车发展的一个关键因素,但是,具体到电动车的使用场景中,那么,就会有一定的差别,电动的出租车和家庭用车就不一样,出租车在巡游场景中会更快的耗费电力,而家庭用车通常来说是有比较清晰的目的地才使用的,在耗费电力上就不会那么多,因此,同样的一款车,同样是在冬季,出租车的续航里程就会少于家庭用车。

这就是假设条件,因为我们只能假设出尽可能多的产品使用场景来说明产品的效能会受到何种影响。

同样,假设条件还是用列表的形式来说明就可以了,大家看图3:

图3

之所以要写约束条件和假设条件,主要有两个作用:

1)这俩条件定义的越详细,越准确,那么,产品的标准化程度就会越高,这样对于后面技术人员去写技术规格文档就有利。

2)这俩条件不但有利于技术团队,其实对营销团队也有帮助,比方说,假设条件确定后,推广团队在宣传产品特征的时候,就可以避免宣传失误,宣传不准确。

这里有个撰写思路,一般来说,约束条件更多集中在内部开发团队上,假设条件更多集中在外部消费者上。

这里再提醒一点,如果你负责多个产品,也就是存在产品组合,那么,在写假设条件的时候,也要写清楚产品之间可能存在的影响,不一定会出现,但咱们必须得假设一下,对吧。

比方说,DD和我们的另一个全文翻译产品KC,就会存在功能上的一些交集,我们就要假设用户必须以哪个产品的词库为准。

接下来就是PRD的核心章节了,第四章,产品需求。

尽管是核心章节,我其实觉得没必要讲太多,因为大家日常尽鼓捣这部分了,那我就挑一些我认为需要注意的地方来讲讲。

1)每一个产品需求都必须清晰简明地记录,而不是长篇大论或者段落的形式。在PRD中不要描述产品的技术设计。PRD是来源于产品视角用来描述产品"是什么"的。PRD不用定义产品"如何做"。避免提供技术设计和实现规格的细节。

这是对这个章节撰写的说明,重点在于我们在写这个部分的时候,千万不要落入“技术实现思维”中,千万不要写太多和技术有关的内容,这点尤其对于那些技术转型的产品经理更需要注意。

2)格式一定要清晰简洁,最好用表格的形式,比方说对于篇幅可能最多的功能性需求而言,格式可以是这样的,大家看图4:

图4

在这个表格中,PR ID,约束条件和MR ID都好写,这个使用说明是不是我们通常理解的使用流程呢?

其实不是,它是指一种指导技术规格的指令,指令是什么,就是一种指导的命令,换到PRD中,它就是指要在使用说明中说明和指导产品某个方面要做什么或应该有什么。

在国外的PRD中,关于使用说明的撰写规范,其实是有要求的,大家看图4中的格式规范。

比方说,针对高频词汇自动识别的需求,我们可以这样来写:

DD应该提供【可以根据用户具体翻译语境的高频词汇自动识别】。

很简单,当然,一旦这个需求记录了下来,那么,约束条件就能确定出来了。

至于第四章后面的需求如何撰写,我就不说了,总之,大家牢牢记住一点就行,在PRD中,站在产品的视角去写就可以了,好像是句废话,呵呵!

最后说一点,可能很多朋友认为PRD是技术企业的产品经理才会写的,我了解的情况似乎也是这样,对于一些传统行业的产品经理,好像并不怎么写PRD,我觉得这是有问题的。

PRD,产品需求文档,第一,只要是产品,就一定会有需求,如果不写,拿什么来记录需求呢?第二,如果没有清晰的产品需求说明,那么,产品的标准化怎么实现呢?第三、如果没有PRD,又怎么来认定你作出的产品是符合用户期望的呢?

总之,一句话,只要是做标准化的产品,那么,PRD都得写,当然,如果你有其它的文档,但是不叫PRD来承载这个工作,那也没问题。