先交代一下背景。做产品这行写得最多的不是PPT而是需求文档。刚入行那会儿我最怕看到的就是这一串缩写BRD、MRD、PRD、DRD、FRD每个都叫需求文档每个又都不一样。后来带团队、做评审、给新人做培训发现绝大多数人卡住的不是会不会写模板而是根本不清楚这几份文档分别在替谁说话、解决什么问题。所以这篇东西我不想给你一套万能模板而是想把这几类文档的前因后果、编写逻辑、常见坑一次性讲透。全文会用一个贯穿的例子来讲某本地生活平台要做会员成长体系。这个项目不大不小正好能把这五类文档的差异全部照出来。你跟着走一遍基本就知道在真实的项目节奏里什么阶段该动哪份文档里面写什么、不写什么。1. 别急着找模板先搞清楚五类文档在为谁说话很多新人拿到这些文档名称第一反应是搜模板。搜完更晕同一个PRDA公司写成功能清单B公司写成原型加说明C公司干脆就是一个在线白板链接。模板之所以不通用是因为每家公司对文档的定位不同。但放在行业通用的视角里这五类文档其实有相对明确的服务对象和要回答的问题。先说结论BRD回答的是要不要做读者是决策层关注商业回报和风险。MRD回答的是做的东西市场认不认读者是管理层和产品委员会关注用户、市场、竞争。PRD回答的是具体做成什么样读者是设计、研发、测试关注功能、流程、规则。DRD回答的是数据从哪来、到哪去、怎么算读者是后端工程师和数据工程师关注接口、字段、口径。FRD回答的是每一个操作细节到底怎么表现读者是前端工程师和测试工程师关注交互、状态、边界。这五份文档不是五选一而是同一个项目在不同阶段的视图。BRD和MRD在项目还没立项时写用来论证和排优先级PRD在项目启动后写用来统领研发DRD和FRD在交互方案和技术方案并行推进时写用来做细节对齐。你甚至可以理解为BRD是给钱的人看的MRD是给方向的人看的PRD是给干活的人看的DRD和FRD是给较真的人看的。我见过最典型的问题是把所有内容塞进一份PRD里开头写市场分析中间写商业模式后面堆功能清单最后再挂一份接口文档。结果这份PRD又长又乱研发不知道哪段该自己看领导翻两页就关了最后谁都没获得有效信息。文档的价值不在厚在于在正确的时间、用正确的粒度、给正确的人看。下面用一个贯穿的例子来说明某本地生活平台的会员成长体系。这个项目要做一个用户等级、成长值、会员权益的闭环涉及运营策略、App前端改动、后端数据处理够复杂也够典型。2. BRD与MRD给决策层算账给方向层指路2.1 BRD一页纸说清值不值得做BRD的全称是商业需求文档Business Requirements Document。它最大的特征是短。我见过好的BRD只有三四页甚至有的是两页纸加一页附录。因为决策层的时间很少他们要看的不是细节而是三件事机会有多大、要投多少、回报靠什么。以会员成长体系为例。BRD里应该写清楚背景与机会平台现有用户复购率连续两个季度下滑而调研显示高活跃用户的消费频次是普通用户的3倍以上。通过成长体系锁定高价值用户可能带来整体GMV提升。商业目标用可量化的口径写。比如项目上线后12个月内会员用户的月均消费频次提升15%高等级用户占比达到20%。不要写提升用户粘性这种没法验收的话。投入估算研发侧需要多少人力、周期多长运营侧需要多少预算做权益采买市场侧需要多少资源做推广。粗算即可不需要精确到人天但要让决策层知道盘子有多大。风险与对策比如高等级权益可能被恶意刷取对策是风控规则前置低等级用户感知弱导致流失的对策是新手快速升级机制。写BRD最容易犯的错是把PRD里的功能列表抄进来。比如等级分为V1到V5V5享受专属客服——这些是PRD的活。BRD里只需要说通过设置明确的用户等级阶梯和差异化的权益激励拉动复购至于阶梯怎么分、权益怎么配不在这一层讨论。还有一点BRD一定要给一个明确的结论和建议。比如建议投入XX资源、在Q2启动该项目。不要只罗列数据让老板自己拍板——数据是支撑你建议的依据决策的成本应该由你来降低。2.2 MRD用户需求不等于产品功能MRD市场需求文档Market Requirements Document。它在BRD之后、PRD之前。BRD论证了值不值得做MRD要回答做的东西到底对不对路。换句话说MRD是把商业目标翻译成需求语言的关键一环。还是会员成长体系。BRD说我们要拉复购、提频次MRD就要进一步说清楚目标用户是谁不能只说所有用户。要细分成新用户、沉默用户、活跃用户、高价值用户。不同用户对成长体系的诉求完全不一样新用户想快速拿实惠老用户想要身份感和专属权益沉默用户需要一张召回券。使用场景是什么周末打开App点外卖前刷一下会员进度条看到再下两单就升级果断凑了一单——这才是场景。MRD里写场景不是写故事而是写触发条件、用户行为、心理预期。市场机会有多大参考同类产品的会员渗透率、用户调研数据、竞品分析。这里不是学术论文给两个维度的足够数据就行一是市场规模二是用户侧验证结果比如问卷调研中78%的用户表示愿意为成长值体系改变消费习惯。核心竞争力同样的会员体系别人也在做我们靠什么赢是平台已有的数据能力、还是供应链权益优势MRD常见的坑有两个。一是把用户需求直接等同于产品功能。用户在问卷里说我想要更多优惠券不代表产品要做一堆优惠券可能是需要更聪明的推荐机制让用户觉得券刚好能用上。MRD要写的是需求背后的动机和场景而不是急着给方案。二是只堆数据和报告没有决策。MRD结尾必须输出明确的结论比如目标市场确认建议按A方案进入PRD阶段让项目真的往前走一步。BRD和MRD的产出物经常是PPT或者在线文档因为要反复给不同的人讲。我建议保持一个习惯这两份文档永远用结论先行的叙事——先说是做什么、定不定再给依据。决策层耐心有限越早看到你的判断他们对你的信任建立得越快。3. PRD从方向对到做得对的那道关键转换3.1 PRD不该写成功能说明书PRD产品需求文档Product Requirements Document。它是整个文档体系里最重要、也最容易写烂的一份。好多团队把PRD写成功能说明书照着原型图把每个按钮、每个弹窗用文字描述一遍。这其实是FRD的活。PRD的灵魂不在于描述界面而在于解释为什么做这个功能以及这个功能在什么条件下成立。拿会员成长体系来说PRD开篇应该有一段需求背景为什么要做成长值、这个项目的成功指标是什么和BRD里的商业目标对应、目标用户是谁和MRD里的用户群对应。这看起来像凑字数实际上非常重要——它让每一个参与的研发和测试都知道自己在解决什么问题而不是单纯执行一个成长值规则。PRD的主体是需求列表。我会用这样的结构用户故事作为高活跃用户我希望每次消费都获得成长值以便更快升级到更高等级、解锁更多权益。功能清单成长值获取规则、成长值查询、等级展示、权益说明页、升级提示弹窗、等级有效期规则。每个功能下的详细规则这才是PRD的工作量所在。成长值怎么算是消费金额的10%还是按单固定给是否有上限退款时成长值怎么处理这部分我放到下一节讲。3.2 业务规则与异常流PRD的价值洼地有一次评审会上前端工程师直接问我用户用积分兑换了权益但订单在支付回调时失败了积分已经扣了页面显示什么我当时愣住了——因为我PRD里只写了兑换成功失败重试两个分支完全没考虑支付结果不确定的中间态。这是PRD最容易被抠出问题的区域业务规则和异常流。写PRD时每个功能都必须回答以下问题正常路径是什么用户下单 → 订单完成 → 成长值入账 → 等级提升 → 展示升级弹窗。分支规则是什么成长值按实付金额计算实付金额含优惠券抵扣部分不含运费退款时按比例扣减对应成长值如果扣减后等级下降已解锁的权益如何处理。异常路径是什么支付成功了但回调延迟、成长值到账失败需要补偿机制、用户注销后成长值是否保留。边界条件是什么单日获取上限、单笔订单上限、成长值有效期、等级每月保级规则。这些规则不是产品经理拍脑袋想出来的而是要拉上运营、财务、法务一起过一遍。尤其是涉及钱、积分、权益的规则每一条都要有口径。我习惯的做法是画一张规则决策表放在PRD里列清楚条件组合和对应行为。比如场景条件系统行为正常入账订单状态变为已完成按实付金额×10%计入成长值退款订单退款成功按退款金额对应比例扣减成长值退款后等级下降扣减后总分低于当前等级阈值等级同步下降未使用权益保留30天回调失败支付成功但回调超时系统按订单查询补偿用户侧显示成长值处理中把这张表写透研发几乎不需要再回来找你确认。这也是PRD和功能说明书最大的分水岭功能说明书告诉别人有什么PRD告诉别人在各种情况下它会发生什么。4. DRD与FRD决定交付质量的最后一公里4.1 DRD研发真正照着写代码的那张图DRD有两种常见解释一种是Data Requirements Document数据需求文档一种是Design Requirements Document设计需求文档。在多数互联网公司的实践中DRD实际承载的职责是接口与数据契约它和FRD一起把PRD的业务逻辑翻译成技术逻辑。为什么要单独写DRD因为PRD里的业务规则到研发手里会面临一个残酷的现实系统里没有成长值这个字段。DRD要做的就是告诉后端工程师数据从哪个表来、要新增哪些字段、接口怎么定义、返回什么结构、错误码怎么定。以会员成长体系为例DRD至少包含三块内容数据需求定义新增成长值流水表包含用户ID、变动类型获取/扣减/过期、变动数值、关联订单号、发生时间、过期时间。会员等级表包含用户ID、当前等级、当前成长值、升级时间、保级状态。数据字段要写清楚类型、长度、是否可空、默认值。接口需求定义比如查询用户成长值接口入参是userId出参是totalGrowthValue、currentLevel、nextLevelThreshold、expireGrowthValue。再比如成长值变动通知接口用于第三方权益系统对接。接口文档尽量沿用团队的现有规范字段命名要和PRD里的业务名词一一对应。计算逻辑与边界成长值的计算是实时的还是T1批处理如果用户一天内消费10笔是一笔一笔算还是累计到晚上统一算这些必须写死。写DRD最忌讳的是产品经理不懂技术但装懂。你不用写SQL但要听得懂研发说的这个字段要不要索引这个接口要不要加分布式锁是什么意思。DRD不是替研发做技术方案而是把业务规则以数据流转的方式复述一遍确保双方对齐。这里我特别想提醒一点DRD里的字段口径必须和PRD完全一致。比如PRD里写实付金额DRD里就必须明确实付金额 原始订单金额 - 优惠券分摊 - 平台补贴不含配送费。口径不一致后面测试阶段一定打架。4.2 FRD把应该怎么样变成就是怎么样FRDFunctional Requirements Document功能需求文档。有些团队把它叫交互说明文档或者界面需求文档。FRD的核心是把PRD里的功能点细化到每一个界面状态、每一次交互反馈。如果说PRD是灵魂FRD就是皮囊和筋骨。回到会员成长体系。成长值页面上有成长值数字、进度条、等级图标、获取攻略、权益列表。FRD要写的不是这些元素的名字而是它们在不同状态下的表现成长值进度条达到50%时是否有动画是否显示离下一级还差XX值用户成长值刚够升级进入页面时是从V3变成V4顶部是否有升级动效弹窗还是半屏浮层用户关掉之后从哪个入口再能看到权益过期了页面展示已过期标签还是直接置灰点击置灰权益是否弹Toast说明原因登录态失效、接口超时、网络断网各是什么状态空数据页面长什么样等级有效期剩余天数是用倒计时显示还是日期显示最后一天是否要额外提醒这些东西PRD不会写、也没必要写但研发一旦开始做页面就会来问你。如果FRD里提前写清楚前端工程师可以独立完成开发测试工程师可以直接对照FRD写用例产品经理也省得被反复打扰。写FRD有个实用的技巧用状态 行为的表格来组织。一个页面拆成N个状态每个状态对应一组行为。比如成长值明细列表状态前端表现交互行为正常加载显示成长值流水列表每条包含变动原因和变动值下拉可刷新点击单条弹出详情加载中显示骨架屏不少于3个占位块不可点击超过5秒显示超时重试按钮空数据显示空状态插画和暂无成长记录文案按钮引导去成长任务中心消费赚成长值加载失败显示加载失败和重试按钮点击重试重新请求接口FRD的篇幅通常很长但读起来应该很轻松——每一页都是是什么状态 → 显示什么 → 能点什么 → 点了之后怎样。写完FRD后我永远会做一件事让一个没参与过PRD讨论的人通读一遍如果他能靠这份文档还原出页面说明写到位了。5. 这五类文档最容易死掉的方式以及我的避坑方法5.1 文档死在没人看和不更新写了多年需求文档我总结出文档最常见的死法不是写得不好而是没人看 不更新。BRD和MRD通常只出现在立项评审会上评审通过后就被丢进网盘落灰。这问题不大因为它们本来就是一次性的决策文档。真正要命的是PRD、DRD、FRD的版本更新。产品经理最常见的操作是评审会提了一堆修改意见当场改了PRD里两段文字但FRD没同步、DRD没同步研发拿着旧文档做了两周最后做出来个四不像。我的习惯是每次评审会开完必须有一个人专门负责同步文档状态。要么在文档开头挂一个变更记录表格列清楚谁在什么时候改了什么要么建一个项目共享目录所有文档放在一起以PRD_v2.3的方式管理版本。最关键的是不允许出现口头同步——你说我上会说了研发知道,但等文档落到新人手里信息就断了。5.2 评审机制把文档变成会议的地基文档的价值一半在写一半在过。没有评审会的文档写完了基本等于白写。我观察到一个很普遍的现象不少团队把PRD评审开成了原型宣讲会产品经理对着图讲一遍这里是按钮那里是列表大家点头散会然后研发回去发现一堆细节没定。评审会正确的打开方式应该是参会者提前看过文档会上只聊分歧和缺陷。为了做到这一点我在发出评审邀请时会附带一份评审要点清单明确告诉与会者请大家重点看第三节的成长值获取规则这里的异常流我拿不准。会上讨论的话题永远是一个个具体的决策点而不是从头到尾把文档读一遍。DRD和FRD评审也一样甚至更需要。因为一份DRD里可能有几十个字段定义现场让后端一行行看效率极低。我会把DRD拆成数据字典和接口定义两个部分提前发给后端和数据仓库的同事让他们把意见直接批注在文档上然后开会只过批注。5.3 文档过细与过粗两头都是坑文档写太粗研发没法干活写太细文档就成了研发的茧房——他们照着文档做完全丧失判断力。我见过最极端的例子某项目的FRD详细到按钮在屏幕左上方12像素处结果设计稿一更新整份文档立刻作废产品经理每天的工作变成改坐标。我的判断标准很简单PRD管业务规则DRD管数据口径FRD管交互行为三者各管一摊不要越界。PRD里不要写按钮放左边还是右边FRD里不要写成长值按10%计算DRD里不要写页面加载失败后显示一个重试按钮。一旦越界文档之间的同步成本就会指数级上涨。再补一条文档的粒度要和团队的专业度匹配。如果前端团队经验丰富FRD可以只写状态和交互规则不写具体视觉表现如果团队里新人多FRD就要把边界情况写得细一点。不要为了显得专业而把文档写到三百页重点是每一页都得有人用。6. 几句实在话好的文档体系是产品经理的第二大脑讲了这么多最后还是想聊聊文档这件事的本质。我做过无数个需求从立项到上线最深的体会是写文档的过程本质上是在逼自己把问题想清楚。有人说产品经理的时间应该花在思考上不要花在写文档上这话我不同意。思考不落到纸面上永远会漏掉细节。你觉得自己想清楚了但当你必须把退款后等级下降、权益怎么办、30天内怎么提示写明白的时候才会发现原来还有一半场景没想过。五类文档组合在一起其实就是产品经理在项目推进过程中的第二大脑BRD和MRD帮你回答值不值PRD帮你回答对不对DRD帮你回答通不通FRD帮你回答细不细。它们相互印证、层层细化最终变成一套可追溯的逻辑链。任何一环缺失项目都会在某个阶段付出额外的沟通成本。最后分享几个我一直在用的实操习惯先搭骨架再填肉。写PRD前先把用户故事、功能清单、规则表、异常流的标题框架列出来再逐节填充。不要从第一个字开始顺序写那样很容易陷入细节出不来。一次只写一类文档。不要一边写PRD一边改FRD更不要同时写BRD和PRD。思维切换的成本远大于书写成本。尽早让研发和设计参与评审。文档不要自己闷头写完再给所有人惊喜。PRD写了三分之一就拉研发看一眼成长值这个字段你打算怎么接这个动作能帮你提前避掉大量返工。文档要有可搜索性。关键名词在同一份文档里全文统一不要这次叫成长值、下次叫经验值。给关键字段设置锚点链接方便别人跳转。说了这么多核心就一句话文档不是流程的摆设它决定了项目里信息的传递效率也决定了产品经理自己的思考深度。希望这篇东西能帮你在写BRD、MRD、PRD、DRD、FRD的时候少走点弯路。