5000字教你写ToB产品需求文档( 二 )

其次，只有明确了读者范围，我们才能写出他们真正需要了解的内容。在参考一些前辈的思路之后，我们需要向读者传递下列3个方面的内容：

我们在解决xx用户在xx场景下的xx问题；
我们使用xx资源、提出了xx方案，并期望收获xx结果；
实现这个方案给我们带来了xx价值（用户价值、商业价值、公司价值）。

在上述3点中，上游的需求方（客户、销售部门、客服部门等）需要重点了解我们在解决哪些用户的问题？场景是什么？大致的解决方案是什么样的？下游的实现方（研发、测试等）则需要大致上了解用户的需求场景，并重点关注实现方案及迭代目标。
二、PRD框架及内容
前面向大家传递了PRD的价值和目标，第二部分就来和大家细讲一下如何组织PRD的内容、每一部分的侧重点是什么以及怎样才能又好又快地撰写一份B端PRD 。
如下图所示，笔者的B端PRD框架整体分为三大模块：项目信息、需求&调研、方案信息。下面我们分别就3大模块进行详细介绍。

本文插图
1. 项目信息
一次迭代就是一个小项目。因此，这里的项目信息则是我们从项目经理的角度出发，向各方阐明本次迭代的总体规划、团队资源及职责、并对相关评审及变更做出记录。

本文插图
1）迭代人员
按照不同职责列出项目迭代负责人及成员，并明确各个成员的职责。
2）评审记录
用户记录需求评审的里程碑会议及结论。这里需要提醒大家一点，写需求评审记录时除了记录那些确定要做的需求之外，还需要记录确认不做的需求并尽量说明决策原因。
记录决策原因是一个帮助我们回顾和复盘的好方法。依据几个月之前的决策思路，我们能很快回忆起当时的出发点，在对比当前的实际现状之后，能更好地寻求成长和突破。
3）变更记录
用于记录迭代正式开始后的需求变更，便于追溯和复盘。其中，变更类型包含但不限于产品遗漏、逻辑设计缺陷、研发评估遗漏、老逻辑影响、新增业务、临时方案赶工、版本拆分等等。
2. 需求&调研
利用金字塔原理，我们先和大家同步了项目的大致规划，让大家心里有了一个底。这一部分，我们就来和团队同步我们是「在解决谁在什么场景下的哪些问题」？
不同于模棱两可、千人千面的C端产品， B端产品往往有较为明确的需求方和用户。那么，我们还有必要向团队再阐述一遍需求到底是什么吗？