只有PRD？远远不够！“一档三表”才是产品经理应该交付给技术实现团队的

首先说明一下，我这里提到的“实现团队”主要是指RDMS中的“技术实现团队”。

对于产品经理而言，要把自己的产品构想形成产品介质，肯定离不开技术实现团队的支持，这个团队至少会包括研发团队，设计团队，和工程团队这些角色。

同时，我们也知道，我们通常会用一个文档来记录产品需求，这个文档我们习惯称之为PRD（其实还有一些其它的叫法，这里仅以IEEE的命名为准），也就是说，PRD是市场需求和技术规格之间的一个中间文档，三者之间的关系大家看下图：

当然，对于产品经理来说，有个PRD就可以了，因为这个文档记录了我们对市场需求的分析过程和结果，但是对于下一阶段的技术实现团队而言，他们其实并不关心你是如何分析每个市场需求的过程的，他们的关注点是在“我用技术要去实现哪些需求”。

因此， PRD可以成为产品经理记录产品需求的“数据仓库”，但却很难成为交付给技术实现团队的介质，因为太庞大了，因此，这就需要我们把“数据仓库”中的，技术实现团队关心的“数据”经过处理后，用一些合适的形式呈现给他们。

也就是说，我们交付给技术实现团队的，和产品需求有关的，规范的载体，都应该包括什么呢，从整体的角度看，应该包括“一档三表”。

1、一个文档

产品需求文档：PRD

关于PRD我就不详细介绍了啊，不仅在咱们联盟的官网上有资料可以学习，网络上对于PRD的介绍也是汗牛充栋，哪怕产品经理们对产品管理中的很多工作有认识差异，但这个工作却难得能够形成普遍的共识。

甚至可以这样说，有些产品经理其实直到现在，也就会做这个文档。

总之，还是前面提到的那个观点，对于产品经理而言，PRD就是记录你分析产品需求过程和结果的“数据仓库”，所有和产品需求的有关的交付物，都要从这个数据仓库中取出。

这里顺便说一点，有朋友会说了，我有原型，是不是就不用写PRD了？

错了，第一，原型本质上只是对PRD的一种具象体现，没有PRD，原型就没有了依据；第二，原型的首要作用不是具象体现PRD，而是面向目标用户的一种验证产品需求正确性的载体，这点呢，其实很多产品经理，很多企业都没搞明白。

很多企业的产品经理把原型做完后，直接让技术团队去开发了，这完全错了。

2、三个表格之一---需求-原型联系表：RPRL

需求-原型联系表：RPRL，Requirements-Persona Relation List。

我们知道，所有的需求都是来自于现实的消费者，我们对这些消费者进行细分之后，就会形成一个个目标市场，但是，这还不够，因为我们必须得通过一个有代表性的消费者形象来指代目标市场，这个形象就是用户原型。

因此，我们在完成PRD后，为了更为直观和清晰的表示需求和目标市场（也就是用户原型）之间的联系，我们需要做一个表格来对这种关系进行细节上的说明，具体怎么来做呢，大家看下图：

表格内容很简单，一共就三列：PR ID；原型；需求细节说明。

PR ID：这个编号继承自PRD，编号务必要和PRD中的需求编号一致；

原型：原型名称和原型类型是必填项，原型身份（这里以职业为例）可选。

用户原型名称是很多产品经理在管理原型时忽视的一个地方，就如同我们会给目标市场细分起个名字一样，用户原型也必须有个名字才能在团队中进行更好的交流。

原型类型也是需要填写的，因为在用户原型中，我们通常会分为“主要用户”和“可选用户”，我们必须在列表中界定哪个需求是哪类用户原型涉及的。

需求细节说明：我们在PRD中对产品需求的说明是经过了分析后的高度概括的结果说明，那么，这些需求的详细情况是什么，是在什么环境中产生的，这就是需求的细节，用专业的话说，就是在什么样的现实场景中出现了什么样的需求。

这个必须要说明，否则你没有办法印证你要实现的某个需求是客观存在的。

这个需求细节说明的内容来自于《用户用例文档》。

3、三个表格之二---产品需求/功能优先级分析表：PFLM

产品需求/功能优先级分析表：PFLM，Priority Functions List Matrix。

这个在《【模板】从设计《产品功能优先级自动化分析工具》看产品经理的业务思维》一问中已经有详细介绍，在此不做赘述。

4、三个表格之三---产品需求/功能列表：LoF

产品需求/功能列表：LoF，List of functions。

这个表应该是实现团队最关注的一个表格了，因为在这个表格里呈现的就是实现团队最关心的信息，大家看下图：

这个表看起类内容多，但是并不复杂，关键内容都是来源于PRD，具体怎么填这个表就不多讲了，关键地方我都有解释。

其实这个表可扩展，可缩减，如果在此基础上扩展一些市场方面的信息，就可以以列表形式呈现MRD，同样，如果在此基础上缩减到只剩下PR ID，需求说明，优先级，那么也是可以的。

这个就看个人的习惯了，总之，只要能把技术实现团队关心的信息体现出来就可以。

5、总结

在第一张图中，我们应该看到了，我们定义产品需求，是为了让技术实现团队完成技术规格设计的工作，同时呢，产品需求又来自市场需求，因此，这个一档三表其实扮演的是对需求的承上启下的作用，大家看下图：

当然，如果再往上导，市场需求如何来自问题，问题又如何来自痛点，这个在本篇中就不介绍了，有兴趣的朋友可以选择《构建产品管理个人知识体系学习资料包》获取相关知识。

同样，如果往下走，那么其实就是涉及到RDMS的工作规范了，产品经理就不好干涉太多了。

尽管我们在交付技术实现团队的介质上用了一档三表，但其实仔细看这些表格的内容，就会发现，说到底，还是在说明：

1、用户是谁：用户原型；

2、他们所处的环境：用户用例/使用场景；

3、他们希望解决的问题是什么：需求说明。

而这些涉及到的工作和体系就要包括：

1、目标市场细分；2、用户原型塑造；3、用户用例说明；4、使用场景构建（业务流程设计中的一部分）；5、需求管理体系（RPM模型中四大管理体系之一）。