常常有人问我怎么写prd，在深受市面上流行的功能需求模板“残害”之后，我现在一般不会向别人推荐任何所谓的“模板”。

需求文档是产品需求的表达方式，而其中需要描述什么内容取决于产品经理想要描述什么，即产品经理的需求。如果产品经理的需求是明确的，而且产品经理脑中有物，那么需求文档自然而然就出来了。最可怕的是产品经理自己都不知道自己要描述的是什么内容，这个时候即使有模板，写出来的东西也是一团糟。

互联网产品以用户为中心，所以prd也应该站在用户的角度来描述，如果不知道自己要写什么，在写文档之前产品经理可以先问问自己以下4个问题：

用户需求是什么？

通过产品，用户能得到什么？

如何满足不同用户的使用场景？

产品应该做什么？

这四个问题凝聚了End2End思想的核心，站在用户的角度给需求，在Jesse James Garrett的《用户体验要素》一书中，被分别称为范围层（问题1，2），结构层（问题3），框架层（问题4）的用户体验。

>>>>用户的需求是什么

按照需求出生的先后排序，需求分别是：

用户需求

功能需求

即先有用户需求，才有功能需求。此文开头已经提过，笔者曾受功能需求模板误导，所以下文中仅描述用户需求。举个例子，用户希望买到物美廉价的商品，那么对于用户而言，用户需求其实就是以下几点：

如果是B2C平台，还得考虑到B端用户的需求，那么用户需求列表就是：

>>>>用户可以得到什么

这个问题，其实也是思考产品的有用性，即产品这么做对用户能产生的价值。

在上面这个B2C电子商务平台的例子中，B端用户通过在系统中发布商品，供C端用户购买，可以给B端用户带来收益，加入了优惠券之后，B端用户在系统中发放优惠券，系统通过优惠券可以刺激C端用户消费，此时B端用户给C端用户提供了折扣，拉动消费后C端用户会给B端用户带来更多的收益，图形化后的表达为：

此图可称为用户价值链

>>>>如何满足不同用户的使用场景

满足不同用户的使用场景，又称作用户场景分析。

接着上面的例子，在用户的两个需求中又包含了不同的场景，其中商品需求的场景包括浏览、下单和付款，优惠券需求的场景包含了获取和使用，于是用户场景（use case）主要表现为：

发布商品是对B端用户而言

在浏览商品这个场景中，不同的用户有不同的使用场景。一部分用户是有目的的，他们知道自己想要的东西叫什么名字，可能只是想知道在这个产品中该商品的价格，所以产品需要提供搜索功能来应对这种用户场景。然而大部分用户都是无目的浏览，为了满足这种用户的需求，只需将商品罗列出来就好。电商平台常见的分类展现、价格范围等等功能都是为了满足介于有目的和无目的之间的用户场景，分析方法类似，此处不再展开描述。

浏览商品之后是下单，有的用户习惯把看起来觉得还不错的商品全部放在一起，先比较比较，再决定是不是要购买，有的用户属于冲动消费或者消费目的明确，这些用户通常看到一个商品觉得还不错，就直接下单了。所以下单这个场景，又有两个用户场景，一个是添加到购物车再下单，一个是直接下单。

最后是付款，付款的方式有多种，有的用户喜欢用支付宝，有的喜欢用微信，有的喜欢用银联等等。这些场景都是现实存在的，但是产品经理需要过滤哪些场景是频繁的场景，哪些是不频繁的。比如，如果这个B2C平台是建立在微信上的，那么用户用支付宝和银联付款的场景就显得很弱，如果是淘宝或者天猫，毋庸置疑，支付宝一定是频繁场景，如果是独立的电商平台，那么可能以上几种场景都需考虑在内，甚至还需要再多加入几个支付场景。

优惠券为大家所知，获取的途径通常有两种，一种是系统发放，一种是主动领取。

通过以上描述，不难得出以下用户场景分析图：

>>>>产品应该做什么

描述产品应该做什么的过程，是prd最核心的部分，也是研发人员最关心的部分。因为只有研发人员看了到产品应该做什么，他们才知道自己应该怎么做。

互联网产品重交互，所以用户与系统之间的互动是最好的描述方式。在测试中有一种方法被称为黑盒测试，用在这里，再合适不过。简单地说，就是用户输入什么，系统输出什么，即：

左边一列描述用户的动作，一行仅与用户的一个动作关联，右边一列描述对于用户的这个动作，系统做出什么样的反应，包括达到什么页面，展示什么信息或者跳转到哪个页面。

结合我们的例子，由于这个例子中有“两个”用户，我们的C端用户和B端用户，所以表格需要做一点小改造：

以其中B端用户发布商品和C端用户搜索商品为例，展开描述，可得到如下用户事件流（user story）：

将其他场景拓展开之后，prd文档基本完成。在此基础上，不管系统应对的用户多么的复杂，都可以自如地化繁为简。

微信时代男婚女嫁
我为什么写BRD 过年回家，亲戚们给我一道思考题：“什么样的女生适合做你老婆？”我答不上来，只好说我去找找看才会知道吧！抵宁后，积极参加了几个圈子活动，深入接触了 业内猎婚人士，调研过现状后，决定把方案汇成 BRD（Business Requirement Document），方便有需之人品读，也作为有心人项目启动决策评估的重要依据。
1项目背景

6年前的互联网时代下，婚恋三巨头如日中天。随后不久，佳缘小龙女转做在线教育，随后各大创始人逐渐失去对婚恋行业的敏感度。随着移动互联网的兴起，并未 看到三巨头有任何的创新，只是亦步亦趋的做了APP，把网页版平移到了APP中，维持着市场份额，黑马频频杀出三巨头依然麻木，比如：有缘网注重移动端布 局，过年期间注册用户一亿三千万，在中央1台春节联欢晚会前做广告；面对如此挑衅，三巨头选择集体麻木哑火，让我们清楚的看到他们的保守，既然他们不创 新，那么我们的机会来了，该做点事情了！

2项目时机

微信的崛起让我们清楚的知道：在这个平台上最起码可以聚人，通信便利带来的高活跃度与用户粘性越来越大，经过3年的用户习惯培养，已经成为人们日常生活中不可或缺的一部分，衍生出的社交需求将我们的生活紧紧捆绑起来。
85后的相亲交友方式随着微信的普及发生着较大变化，碎片化、移动化、全天在线的需求特征是婚恋三巨头无法给予满足的需求，意识到三巨头原有的商业模式 （发信付费）在今天看来已经不合时宜（微信人多且免费），但新的模式又没有出来，三座大山貌似符合经济学中的“得利不动原则”，新时代下的“愚公移山”也 没有出现，似乎这个巨大的市场需求似乎被人们遗忘了。

3项目规划

“抢红包”是微信上使用频率最高的功能，人人分润的模式已被微信用户熟知，基于这个模式上延伸到人人红娘，即猎婚需求者发红包，应征者符合猎婚者需求后，转发传播人即红娘收获分润。

需要明确的是人人红娘模式不是分销模式，有多级关系，有多级分润体系。话句话说，作为一个猎婚平台，猎婚者是有红娘责任人的，可以有多对一红娘服务，但不存在红娘下线有红娘的上下级关系，想当红娘是需要平台注册认证的，只有同意条款扮演红娘后才能分润。

对于发布悬赏的猎婚需求方，采取“担保交易”的支付宝模式，保障平台双方权益，核实期限为7天，当然，这个核实期限可设置时间长短。

对于报名的应征者，根据悬赏人的条件来判定是否需要报名费，悬赏人是二三四线城市低收入群体那么一律免费，不组织见面会。悬赏人是高富帅，应征者报名就要缴费，婚恋机构会找场地组织见面会。
应征者的实名制审核离不开婚恋机构，这个模式是离不开线下实体而独立存在的，诚信体质建设线上线下通力配合，这就需要平台与机构紧密的合作，提高准入门槛与复制成本，才能适应国情尽快落地，形成O2O商业模式。

更具体的功能描述，产品细节，详见产品需求说明书PRD（Product Requirement Document）

4发展规划

预估市场投入期在1年，保守期望，以100万注册用户为目标，度过第一年的瓶颈期，直到平台用户与机构供需和谐，会进入快速爆发期。平台本身并不能靠用户给予的资金力量发展，而是要靠投资机构资金的注入来取得井喷式发展，投资的获取能力考验领导们的领袖魅力。

5成本预算

产品制作：

手机前台静态页面25页，500元/页，共12500元
PC管理后台静态页面，5000元
PHP程序，2人，8000元/人月，16000元
测试，1人，5000元/人月，5000元
服务器与域名：7500元

合计：46000元

6风险预估

产品用户体验感达不到期望
同质化竞争对手的出现
地推合作人员跟不上

7预防对策

将前台界面外包继续优化
启动新一轮融资，加大补贴力度
启动招商加盟政策，让代理商协助地推