prd|5000字教你写ToB产品需求文档

编辑导语：撰写一份合理有效的产品需求文档，有助于产品团队进行后续管理，进而在后期有序地推动产品迭代升级。本篇文章里，作者总结了撰写B端产品需求文档的方法以及相关小贴士，也许读完之后，你能更清晰地了解PRD撰写。

文章插图
从各大招聘市场来看，B端产品经理需求日渐旺盛，越来越多的产品新人和C端产品转而投入了toB行业。在这样的大背景下，越来越多的产品新人需要学习如何撰写B端产品需求文档（以下简称PRD：Product Requirement Document）。
那么，B端产品PRD到底好不好上手撰写呢？
答案是否定的。最近，笔者在招聘产品实习生时发现了这样一种现象：大部分实习生的初作品都是围绕校园生活的C端产品，鲜有B端产品文档；即使有一部分新人报名参加了一些产品培训，其作品也大多以C端为主。
这个现象从侧面说明了注重交互和用户体验的C端较好入门，因为产品经理本身就可以尝试代入角色进行体会。而角色权限众多、业务庞乱、流程复杂的B端产品则为新人树立了一道无形的门槛，只有厘清和理解业务之后，才可能撰写出一份高质量的B端PRD。
因此，笔者想和刚刚入行B端亦或是头疼写文档的你分享自己的PRD框架，帮助你又快又好地撰写一份高质量PRD。此外，还会额外与大家分享2个非常实用的PRD撰写小tips，帮助你在保证质量和准确度的前提下，提升撰写速度。
话不多说，直接上干货。
一、我们为什么要写PRD？PRD的本质是文档，而文档的本质只是大脑产物的一种承载形式。那我们为什么不可以使用口述、绘制草图等方式来进行沟通和信息传递呢？
并不是不行，在产品初期和团队人员较为精简的情况下，有些公司会使用口述和手绘草图等方式进行沟通。但随着时间的流逝和团队成员的壮大，这些方式不便于大范围传播和归档，而落笔有声的文档则可以肩负起记录、参照和流传的责任。
因此，当达到一定的产品和团队阶段，我们就需要通过PRD来保证多方目标和需求理解一致，让整个迭代井然有序的运行。
那么，我们写产品需求文档是为了让读者了解什么呢？
首先，B端PRD的读者和C端有很大差异。
B端PRD的读者除了研发、老板之外，还包含需求方。不同于C端，B端的用户往往是较为明确的一些职位和角色，他们会直接将一些需求和问题反馈至公司的销售或是客服团队。这就意味着，公司内的销售部门、业务部门、客服部门等都会是用户or客户的传话筒，从而成为我们的需求方。
其次，只有明确了读者范围，我们才能写出他们真正需要了解的内容。在参考一些前辈的思路之后，我们需要向读者传递下列3个方面的内容：

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

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

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

文章插图
1）迭代人员
按照不同职责列出项目迭代负责人及成员，并明确各个成员的职责。
2）评审记录
用户记录需求评审的里程碑会议及结论。这里需要提醒大家一点，写需求评审记录时除了记录那些确定要做的需求之外，还需要记录确认不做的需求并尽量说明决策原因。
记录决策原因是一个帮助我们回顾和复盘的好方法。依据几个月之前的决策思路，我们能很快回忆起当时的出发点，在对比当前的实际现状之后，能更好地寻求成长和突破。