简介产品经理的经典三件套——BRD、MRD、PRD是产品从商业论证到落地开发的核心工具。资源聚焦商业需求文档BRD系统拆解其7个必备板块修订说明、背景和目的、市场背景、产品介绍与方案、产品规划、收益与成本预估、风险预估并给出每部分的撰写要点例如用修订说明记录版本与作者用市场背景分析行业趋势和用户需求用收益成本预估和风险应对说服决策层投入资源。同时对比市场需求文档MRD与产品需求文档PRD的不同受众和使命MRD面向运营营销部门展示市场机会与潜力PRD面向开发团队定义功能、设计与体验从而串起产品生命周期中的完整文档链条。整个资源为单个doc文档压缩包大小27KB已有209人学习浏览。适合产品经理新人快速搭建三类文档的基本框架也可作为在职产品人撰写BRD时的结构参考与自查清单帮助系统提升商业分析、市场洞察与需求定义能力。1. 产品经理有3宝先分清BRD、MRD、PRD是写给谁看的“这款产品我们不做明年可能会后悔。”当产品经理把这句话放到评审会上时手上至少得有一份能扛住追问的BRD。产品经理有3宝BRD说给老板听MRD说给市场听PRD说给研发听。很多刚转行的人把这三份文档混着写BRD里全是按钮和页面PRD里全是商业模式评审会被打回来两轮还找不到问题在哪。这份《产品经理有3宝BRD、MRD、PRD》文档资料把三份文档的定位和结构拆开讲清楚了尤其把BRD的7个内容块逐层做了展开。适合正在补文档能力、准备晋升答辩、或者刚接手产品规划的人。看完照着套框架至少能写出“该有的都有”的第一版但想写出能过会的版本还得注意后面几章的坑。2. BRD七段式框架从修订说明到风险预估每一段写什么才能过会BRD的7个部分看起来像填空题实际是一条说服链。修订说明和背景目的解决“为什么现在要做”市场背景解决“这个方向有没有空间”产品介绍与方案解决“我们具体做成什么样”收益与成本预估解决“这笔投入划不划算”风险预估解决“最坏情况能不能兜住”。顺序不能乱。我见过不少BRD把产品功能放在市场背景前面老板读到第三页还在问“市场到底多大”节奏一断后面对数字的信任感就弱了。写BRD不是写产品说明书是替决策层把账算清楚。2.1 修订说明与背景目的先建档再讲事修订说明是文档的门面字段不多撰写人、版本号、撰写时间、相关备注。很多人把备注栏空着其实这里有个加分的用法——写清“本次修订基于哪次评审意见、改动了哪一段”。老板翻到第2版时一眼能看到这版改了什么东西比正文里自己找差异快得多。哪怕只是“根据6月12日立项会意见调整市场切入点为华东区域”也让文档显露出协作痕迹。背景和目的这一段最容易翻车的地方是写成公司介绍。“公司成立于2010年深耕行业十年……”这种开头放在BRD里没有任何决策信息。背景要写业务痛点不是写公司编年史。我一般用的句式是当前业务场景存在问题导致后果本产品通过方式为目标用户解决问题目标达到可量化结果。用这个句式写出来的背景每个词都有信息量老板读完就知道为什么要做。撰写顺序有个小技巧修订说明放在文档第一页但实际是最后填。原因很简单版本号、日期、备注内容都会在撰写过程中变化先填就等于给自己埋了个“文档改了但版本没更新”的坑。先写正文写完后统一回填修订说明确保版本号、时间和定稿内容一致。另外注意背景段落控制在半页以内决策层不会在一段背景里花超过三分钟。2.2 市场背景别把行业报告抄成散文市场背景是BRD里篇幅最大的部分也是最容易变成“行业报告粘贴墙”的部分。资料里给的框架是六段行业前景与现状、市场规模与容量、商业模式与价值、用户类型与需求、行业头部产品发展、行业机会与技术门槛。每段要回答的问题都不一样写的时候心里要带着问题落笔而不是把搜到的报告按顺序堆上去。我习惯先拉一张表把每段要回答的问题写在前面再往里面填材料。行业前景与现状回答行业处在什么周期趋势向上还是向下市场规模与容量回答总盘子多大、增速多少、我们能切哪个细分市场商业模式与价值回答这个行业靠什么赚钱我们的价值主张在哪里用户类型与需求回答谁在付费、谁在使用、最痛的需求是什么头部产品发展回答对手解决了什么、还有哪些需求没被满足机会与技术门槛回答为什么是现在、为什么是我们。每一段写完后强制加一句“这意味着什么”否则就成了数据搬运。市场背景段落要回答的问题常用数据来源行业前景与现状行业在上升期还是下行期行研报告、行业协会统计市场规模与容量大盘多大、增速多少、切哪个细分咨询机构报告、头部公司财报商业模式与价值行业怎么赚钱、我们赚哪份钱招股书、公开访谈用户类型与需求谁付费、谁使用、最痛的点用户访谈、问卷、客服记录头部产品发展对手覆盖了什么、留下什么空位竞品体验报告、应用商店数据机会与技术门槛为什么是我们、为什么是现在内部能力盘点、预研结果“数据结论”的具体写法可以参考这样××市场年规模约××亿元年增速××%其中××细分场景增速高于整体现有产品在××场景渗透率低主要原因是××这意味着新的进入者有机会用××方式切进去。注意这里一定要出现“这意味着”三个字它是区分“抄报告”和“做分析”的分水岭。2.3 产品介绍与方案先写清定位再列功能产品介绍与方案这段资料里的顺序是产品定位与愿景、产品价值与目标、产品形态与业务模式、产品主要功能、盈利模式、运营模式。这个顺序本身就是逻辑链定位决定价值价值决定形态形态承载功能功能服务盈利盈利靠运营实现。很多人习惯一上来列功能清单反而把这条逻辑链打断了。产品定位只需要一句话结构是“为谁解决什么问题凭什么有效”。比如“为中小电商卖家提供自动化对账工具解决多平台账单核对耗时问题基于规则引擎异常提醒实现分钟级对账”。这一句要是写不出来说明产品概念还没想清楚后面功能列得再细都是空中楼阁。产品主要功能这一段要克制。BRD里的功能清单是“证明模式成立的最小功能集”不是给研发看的全部功能。写的时候要把每个功能挂到盈利模式或运营模式下面这个功能支撑哪个收入来源或者支撑哪条用户增长链路。挂不上的功能要么砍掉要么留到PRD再展开。盈利模式重点回答三件事谁付费、付什么费、怎么收。运营模式回答另外三件事内容或供给从哪来用户怎么增长留存靠什么手段。这两块写完了产品形态才算立体起来。2.4 产品规划MVP阶段怎么圈定产品规划部分资料里分成MVP阶段、完善产品阶段、发展阶段三个阶段。写规划表比写叙述更容易让决策层理解。列一张四列的表阶段、时间范围、阶段目标、功能范围与关键指标。MVP阶段的圈定是这份BRD最容易暴露水平的地方圈大了显得失控圈小了显得没想清楚。MVP阶段的目标只有一个验证核心假设。假设可能是“用户愿意为这个功能付费”也可能是“这个场景确实存在高频需求”。所以功能范围只保留一条主链路加上一个付费或留资验证点。我一般会建议MVP阶段砍掉后台管理系统、砍掉角色权限、砍掉消息推送、砍掉积分体系这些都属于“完善产品阶段”的范畴。MVP的排期控制在3到4个月比较稳超过6个月大概率是功能划多了或者验证范围定得太宽。完善产品阶段的目标是留存和转化补齐运营后台、推荐策略、性能优化这些支撑规模化运营的能力。发展阶段的目标才是横向复制到其他客户群或者纵向做增值服务。写规划时把三个阶段各自的目标和成功指标写清楚决策层就能判断这不是一份“只想着把产品做出来”的方案而是一份考虑了产品全生命周期的商业计划。3. 收益与成本预估让老板拿到算得过的账而不是形容词BRD第6、7部分是决策层盯得最紧的两块。前面写得再好到这两块数字对不上整份文档的可信度都会被打折扣。老板批项目只关心三件事要花多少钱、多久能回本、最坏亏多少。成本估算回答第一件收益估算回答第二件风险预估回答第三件。这一章把这三块怎么算、怎么写、常见错在哪讲透。3.1 成本估算至少拆成四类成本估算最常见的错误是全篇只有研发人力成本。实际上一个产品从立项到跑通商业模式成本至少拆四类研发成本、运营成本、资源成本、机会成本。研发成本是产品、设计、前后端、测试的人力投入运营成本是渠道投放、市场推广、客服人力资源成本是服务器、云资源、第三方接口调用费机会成本是“如果不做这个产品团队还能做什么”。人力成本常见做法是按人日口径算。研发人日单价各公司差异很大通常在1500到2500元之间波动关键是口径要统一这个单价是纯工资还是含管理摊销、办公场地、五险一金的全成本。口径不统一会导致估算结果差一倍评审时被财务追问就露馅。写BRD不需要每笔都精确到个位但每个数字后面要能说出依据。成本项计算口径说明研发成本参与人日 × 人日单价产品、设计、开发、测试全包含运营成本渠道预算 推广人力按首年收入的一定比例预留更稳资源成本服务器费用 第三方接口费用按用户量峰值估算别按最低配算机会成本团队同期可做的替代项目定性写清即可3.2 收益估算三种算法要一起上收益估算比成本难写因为拍脑袋的空间很大。老板不怕收益低怕的是没有依据的收益高。我一般会同时用三种算法交叉验证直接营收法、降本增效法、战略价值法。直接营收法适用于有明确付费产品的场景公式是用户规模 × 付费转化率 × 客单价注意按年份分阶段测算第一年覆盖期转化率通常低于稳定期。降本增效法适用于内部工具或替代型产品算的是替代原有人工流程后每年节约的成本。收益表的结构建议做成收入来源、测算方法、关键假设、第一年、第二年、第三年。其中关键假设这一列最重要它决定了数字有没有讨论基础。假设写“首年付费转化率8%”就要说明这个8%是从哪个竞品公开数据或者自有渠道测试里来的。没有假设依据的数字在评审会上活不过第二轮。战略价值这部分不直接算钱但可以定性加粗略定量比如数据资产覆盖了多少用户、卡住了哪个生态位。写清楚“三年内不占这个位置后面要花五倍代价追”就足够了。3.3 风险预估带应对动作的风险才是风险风险预估是BRD里最容易被误写成形式的章节。“存在技术风险”“存在市场风险”这种一句话风险等于没写。风险不是用来预言的是用来提前安排下一步动作的。每条风险拆成三列触发条件、影响、应对动作。触发条件写清楚什么情况下风险会发生影响写清楚发生后对哪个指标产生多大影响应对动作写清楚风险发生后立刻启动什么措施。风险类型触发条件影响应对动作市场风险竞品提前发布同类产品用户获取成本上升、增速不及预期转投差异化细分场景同步推进B端定向合作技术风险核心算法效果达不到商用线产品体验不达标、留存下降MVP阶段先上规则引擎兜底算法后置优化投入风险成本超预算、进度延期上线时间后移、窗口期被压缩按阶段拆预算每阶段设置评审点不达标及时止损写风险应对动作时要具体到可以执行的程度而不是“加强调研”“紧密关注”这类空话。决策层看到“如果A发生我们就启动B方案”他对这个项目的判断就不一样了——你不是在向他汇报坏消息而是已经替他想好了退路。这也是BRD和普通项目计划的区别BRD的风险部分本质上是在替老板做压力测试。4. 从BRD到MRD再到PRD一次需求的三次转译BRD、MRD、PRD不是三份独立的文档而是同一个需求在不同阶段、对不同读者做的三次转译。BRD用商业语言告诉决策层“值不值得做”MRD用市场语言告诉运营和市场“卖给谁、怎么卖”PRD用研发语言告诉开发“做成什么样、怎么验收”。顺序不能跳直接写PRD的多半没想清楚商业逻辑只写BRD不落PRD的产品永远停留在汇报层面。4.1 三份文档的定位矩阵把三份文档放在一张表里看区别一目了然。BRD的读者是决策层核心问题是“要不要投入资源”产出物是商业方案评审标准是ROI和战略价值。MRD的读者是市场、运营、销售核心问题是“目标用户在哪、怎么触达”产出物是市场策略和用户需求分析评审标准是市场空间与获客可行性。PRD的读者是研发、设计、测试核心问题是“做什么功能、按什么规则跑”产出物是功能说明和流程定义评审标准是开发可执行性。三份文档的评审时点也不同。BRD在立项评审会上过过了才配资源、给人、给预算。MRD在正式开发前过用来统一市场侧和产品侧对目标用户的理解。PRD在排期评审前过过了才进开发。实际团队里MRD经常被压缩甚至跳过导致运营拿着自己想当然的用户画像去找客户和市场真实反馈对不上。我一般建议最少也要把目标用户分层和核心场景定义从BRD里抽出来单独过一遍哪怕就一页纸。4.2 从BRD转到MRD把商业语言翻译成市场语言BRD里的市场背景是宏观视角“市场规模年增速30%”这种结论在MRD里必须要变成具体动作第一批目标用户是谁在哪里能找到他们他们现在用什么替代方案一次获客成本大概多少钱。BRD说“机会空间大”没用MRD要说清楚“机会从哪个渠道能被抓住”。MRD的结构资料里没有展开但常见做法是包含六块市场机会、目标用户分层、用户需求与场景、产品能力与卖点、渠道与运营策略、关键指标。目标用户分层这步尤其重要BRD里写“目标用户为制造业中小商家”就够了MRD要把这批用户再拆层是老板直接决策还是运营操盘月销售额在哪个区间用Excel对账还是已经上了ERP。不同层级的用户需求表达方式和付费意愿完全不一样。用户需求和场景每一条都要写成一个完整的叙事“谁在什么情况下遇到了什么问题现在是怎么凑合解决的”。这个叙事越具体后面转PRD时功能定义就越容易。比如“一家月销50万的淘宝店老板月底花两天时间核对三个平台的账单经常对不上账”比“用户对账效率低”更容易翻译成功能。渠道与运营策略这块要写清楚首批用户从哪里来是内容引流、渠道投放、还是行业协会合作以及估算单用户获取成本这个数字直接喂给BRD的成本部分。4.3 从MRD转到PRD把市场语言翻译成研发语言MRD到PRD的转译是把“用户想要什么”变成“系统做什么”。MRD里写“用户想快速判断一款产品值不值得入手”PRD里要落地成“产品详情页包含评分、用户评价摘要、参数对比功能评分数据实时展示详情页加载耗时不超过2秒”。转译的跨度越大信息损耗越严重。我见过太多次MRD里写的目标用户是95后到PRD里默认场景按35岁用户设计中间没有任何人意识到口径已经变了。转译过程遵循三条原则。第一一段话只面向一个读者不要在一个PRD里既写给开发看又写给领导看。第二一件事在全套文档里只展开一次在BRD里讲了商业模式MRD里就不再复述商业模式只写它对市场策略的影响。第三能用数字就不用形容词把“用户体验好”换成“首屏加载低于2秒”“注册流程少于3步”开发不用猜测试也不用吵。PRD的基本内容一般包括需求背景、功能需求列表、功能详情、业务流程、规则逻辑、异常处理、埋点需求、验收标准。需求背景放一段简短说明即可重点写清楚这个功能解决哪个MRD里的用户场景方便开发回溯。功能详情里每个功能要写清入口、操作流程、前置条件、后置结果、异常分支。规则逻辑是最容易被遗漏的优惠怎么叠加、超时怎么处理、并发下怎么保证数据一致这些不写清楚开发就按自己的理解做。当研发提出“这个做不了”的时候我习惯用双层倒查法。第一层回到MRD看这个功能对应哪个用户需求如果需求本身站不住砍掉如果需求成立继续第二层回到BRD看这个功能支撑哪个商业目标支撑的话就调整实现方案而不是删除需求不支撑的话连同需求一起砍。两层都通过才改PRD。这套方法能拦住大部分需求漂移也避免PRD在开发中期被一句“技术实现困难”带偏方向。5. 三份文档的翻车现场五类高频问题与排查思路写文档写到能过会光知道“怎么写”不够还得知道“怎么写会死”。这一章整理的是我在实际评审和文档评审中见过的高频翻车点每条按现象、原因、解决三步走你可以拿来自查。5.1 BRD写成PRD老板问“你到底让我批什么”现象BRD里一半篇幅在写功能详情、按钮、页面流程决策层翻完文档不知道市场机会在哪也不知道要批多少钱。原因是把BRD当PRD的上位版用写功能的思路写商业文档或者对市场理解不够只能用功能细节充篇幅。解决方法是写BRD时先不打开PRD模板强制自己按7个框架走写完检查一遍凡是属于“产品主要功能”以外的实现细节全部丢到附录或者直接删掉。判断标准很简单删掉所有功能细节后BRD还能不能完整陈述背景、市场、收益、风险能就是合格的BRD。5.2 市场背景堆数据每个数都真整体没有结论现象行业报告截图、市场规模、增速数据贴了十几页看完不知道这个产品该做还是不该做。原因很直接只做了信息搬运没做信息判断。每个数据都是真的但它们之间没有形成结论。解决方法是给每个数据后面补一句“这意味着什么”并在市场背景写完时加一段“市场机会判断”收尾。比如“头部产品集中在××场景我们在××场景有差异化机会”用一页纸把前面所有数据的结论串起来。5.3 成本只算研发不算运营和渠道现象成本预算表里只有研发团队人力上线后市场推广、渠道分成、客服人力全部没算。老板问一句“获客成本呢”当场卡住。原因是成本口径按“做出来”算而不是按“卖出去”算。解决方法是把成本拆成四类研发成本、运营成本、资源成本、机会成本逐项填。运营成本哪怕暂时只写“按首年收入的30%预留”也比完全空白强。注意口径要统一别研发按全成本算、运营按纯工资算两类口径放在一张表里数字会失真。5.4 风险只做标题党有标题、没动作现象“存在技术风险”“存在市场风险”一句话完事。评审时被问“风险发生后怎么办”答不上来。原因是没有把风险当项目计划的一部分只当形式化章节在凑数。解决方法每一条风险必须写全“触发条件—影响—应对动作”应对动作要具体到能直接启动的程度。风险表写完自查一遍把“加强关注”“持续跟踪”这类空话全部删掉换成“启动备选方案”“切换技术路线”“转向B端合作”这种能落地的动作。5.5 MRD和PRD口径漂移两份文档自相矛盾现象MRD里写目标用户是30岁以下PRD里的默认场景却是35岁家庭用户MRD说核心功能是A开发排期里做的却是B。原因是文档写于不同时间点缺少统一的口径表中途改动只改了一份。解决方法三份文档共用一个口径表至少包含目标用户、核心场景、核心功能优先级、成功指标四个字段。任何一份文档需要改这四个字段时其余两份文档同步更新评审前先对口径表再对正文。这个习惯能挡掉一大类“文档在场上一套、开发做另一套”的协作纠纷。6. 最后一招评审会前十分钟自检与一页纸对照卡文档写完了怎么判断能不能上会我后来养成一个习惯评审会前十分钟不做别的只做四件事。三分钟看商业逻辑问自己“这份BRD删掉所有功能描述后能不能说清做还是不做”三分钟看用户人群问自己“MRD里的目标用户画像和PRD里的使用场景是不是同一批人”三分钟看验收标准问自己“PRD里每个功能有没有可以不吵架的验收标准”最后一分钟看版本号和口径表确认三份文档的修订记录和关键字段一致。检查维度看哪份文档合格标准商业逻辑BRD删掉功能描述后仍能独立说清做与不做的判断用户人群MRD目标用户分层与PRD场景中的用户一致验收标准PRD每个功能都有可测试的量化指标口径一致性三份文档共用口径表目标用户、核心场景、优先级、成功指标一致之后我又加了一步每写完一份BRD放一天第二天假装自己是老板重新读一遍。手里拿一支笔遇到形容词就画圈要求自己改成数字遇到功能清单就画杠问它属于哪个框架。如果读完整份文档还说不出“做还是不做”这版就不能上会再回去磨。这套动作不复杂但每次都能在评审前捞出至少三处逻辑漏洞。把配套的资料放在案头下次写BRD直接按框架走能少熬两个晚上。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/12 19:34:47 · 阅读 1.2k 产品经理必备：BRD、MRD、PRD三份需求文档的写法与转译指南
简介产品经理的经典三件套——BRD、MRD、PRD是产品从商业论证到落地开发的核心工具。资源聚焦商业需求文档BRD系统拆解其7个必备板块修订说明、背景和目的、市场背景、产品介绍与方案、产品规划、收益与成本预估、风险预估并给出每部分的撰写要点例如用修订说明记录版本与作者用市场背景分析行业趋势和用户需求用收益成本预估和风险应对说服决策层投入资源。同时对比市场需求文档MRD与产品需求文档PRD的不同受众和使命MRD面向运营营销部门展示市场机会与潜力PRD面向开发团队定义功能、设计与体验从而串起产品生命周期中的完整文档链条。整个资源为单个doc文档压缩包大小27KB已有209人学习浏览。适合产品经理新人快速搭建三类文档的基本框架也可作为在职产品人撰写BRD时的结构参考与自查清单帮助系统提升商业分析、市场洞察与需求定义能力。1. 产品经理有3宝先分清BRD、MRD、PRD是写给谁看的“这款产品我们不做明年可能会后悔。”当产品经理把这句话放到评审会上时手上至少得有一份能扛住追问的BRD。产品经理有3宝BRD说给老板听MRD说给市场听PRD说给研发听。很多刚转行的人把这三份文档混着写BRD里全是按钮和页面PRD里全是商业模式评审会被打回来两轮还找不到问题在哪。这份《产品经理有3宝BRD、MRD、PRD》文档资料把三份文档的定位和结构拆开讲清楚了尤其把BRD的7个内容块逐层做了展开。适合正在补文档能力、准备晋升答辩、或者刚接手产品规划的人。看完照着套框架至少能写出“该有的都有”的第一版但想写出能过会的版本还得注意后面几章的坑。2. BRD七段式框架从修订说明到风险预估每一段写什么才能过会BRD的7个部分看起来像填空题实际是一条说服链。修订说明和背景目的解决“为什么现在要做”市场背景解决“这个方向有没有空间”产品介绍与方案解决“我们具体做成什么样”收益与成本预估解决“这笔投入划不划算”风险预估解决“最坏情况能不能兜住”。顺序不能乱。我见过不少BRD把产品功能放在市场背景前面老板读到第三页还在问“市场到底多大”节奏一断后面对数字的信任感就弱了。写BRD不是写产品说明书是替决策层把账算清楚。2.1 修订说明与背景目的先建档再讲事修订说明是文档的门面字段不多撰写人、版本号、撰写时间、相关备注。很多人把备注栏空着其实这里有个加分的用法——写清“本次修订基于哪次评审意见、改动了哪一段”。老板翻到第2版时一眼能看到这版改了什么东西比正文里自己找差异快得多。哪怕只是“根据6月12日立项会意见调整市场切入点为华东区域”也让文档显露出协作痕迹。背景和目的这一段最容易翻车的地方是写成公司介绍。“公司成立于2010年深耕行业十年……”这种开头放在BRD里没有任何决策信息。背景要写业务痛点不是写公司编年史。我一般用的句式是当前业务场景存在问题导致后果本产品通过方式为目标用户解决问题目标达到可量化结果。用这个句式写出来的背景每个词都有信息量老板读完就知道为什么要做。撰写顺序有个小技巧修订说明放在文档第一页但实际是最后填。原因很简单版本号、日期、备注内容都会在撰写过程中变化先填就等于给自己埋了个“文档改了但版本没更新”的坑。先写正文写完后统一回填修订说明确保版本号、时间和定稿内容一致。另外注意背景段落控制在半页以内决策层不会在一段背景里花超过三分钟。2.2 市场背景别把行业报告抄成散文市场背景是BRD里篇幅最大的部分也是最容易变成“行业报告粘贴墙”的部分。资料里给的框架是六段行业前景与现状、市场规模与容量、商业模式与价值、用户类型与需求、行业头部产品发展、行业机会与技术门槛。每段要回答的问题都不一样写的时候心里要带着问题落笔而不是把搜到的报告按顺序堆上去。我习惯先拉一张表把每段要回答的问题写在前面再往里面填材料。行业前景与现状回答行业处在什么周期趋势向上还是向下市场规模与容量回答总盘子多大、增速多少、我们能切哪个细分市场商业模式与价值回答这个行业靠什么赚钱我们的价值主张在哪里用户类型与需求回答谁在付费、谁在使用、最痛的需求是什么头部产品发展回答对手解决了什么、还有哪些需求没被满足机会与技术门槛回答为什么是现在、为什么是我们。每一段写完后强制加一句“这意味着什么”否则就成了数据搬运。市场背景段落要回答的问题常用数据来源行业前景与现状行业在上升期还是下行期行研报告、行业协会统计市场规模与容量大盘多大、增速多少、切哪个细分咨询机构报告、头部公司财报商业模式与价值行业怎么赚钱、我们赚哪份钱招股书、公开访谈用户类型与需求谁付费、谁使用、最痛的点用户访谈、问卷、客服记录头部产品发展对手覆盖了什么、留下什么空位竞品体验报告、应用商店数据机会与技术门槛为什么是我们、为什么是现在内部能力盘点、预研结果“数据结论”的具体写法可以参考这样××市场年规模约××亿元年增速××%其中××细分场景增速高于整体现有产品在××场景渗透率低主要原因是××这意味着新的进入者有机会用××方式切进去。注意这里一定要出现“这意味着”三个字它是区分“抄报告”和“做分析”的分水岭。2.3 产品介绍与方案先写清定位再列功能产品介绍与方案这段资料里的顺序是产品定位与愿景、产品价值与目标、产品形态与业务模式、产品主要功能、盈利模式、运营模式。这个顺序本身就是逻辑链定位决定价值价值决定形态形态承载功能功能服务盈利盈利靠运营实现。很多人习惯一上来列功能清单反而把这条逻辑链打断了。产品定位只需要一句话结构是“为谁解决什么问题凭什么有效”。比如“为中小电商卖家提供自动化对账工具解决多平台账单核对耗时问题基于规则引擎异常提醒实现分钟级对账”。这一句要是写不出来说明产品概念还没想清楚后面功能列得再细都是空中楼阁。产品主要功能这一段要克制。BRD里的功能清单是“证明模式成立的最小功能集”不是给研发看的全部功能。写的时候要把每个功能挂到盈利模式或运营模式下面这个功能支撑哪个收入来源或者支撑哪条用户增长链路。挂不上的功能要么砍掉要么留到PRD再展开。盈利模式重点回答三件事谁付费、付什么费、怎么收。运营模式回答另外三件事内容或供给从哪来用户怎么增长留存靠什么手段。这两块写完了产品形态才算立体起来。2.4 产品规划MVP阶段怎么圈定产品规划部分资料里分成MVP阶段、完善产品阶段、发展阶段三个阶段。写规划表比写叙述更容易让决策层理解。列一张四列的表阶段、时间范围、阶段目标、功能范围与关键指标。MVP阶段的圈定是这份BRD最容易暴露水平的地方圈大了显得失控圈小了显得没想清楚。MVP阶段的目标只有一个验证核心假设。假设可能是“用户愿意为这个功能付费”也可能是“这个场景确实存在高频需求”。所以功能范围只保留一条主链路加上一个付费或留资验证点。我一般会建议MVP阶段砍掉后台管理系统、砍掉角色权限、砍掉消息推送、砍掉积分体系这些都属于“完善产品阶段”的范畴。MVP的排期控制在3到4个月比较稳超过6个月大概率是功能划多了或者验证范围定得太宽。完善产品阶段的目标是留存和转化补齐运营后台、推荐策略、性能优化这些支撑规模化运营的能力。发展阶段的目标才是横向复制到其他客户群或者纵向做增值服务。写规划时把三个阶段各自的目标和成功指标写清楚决策层就能判断这不是一份“只想着把产品做出来”的方案而是一份考虑了产品全生命周期的商业计划。3. 收益与成本预估让老板拿到算得过的账而不是形容词BRD第6、7部分是决策层盯得最紧的两块。前面写得再好到这两块数字对不上整份文档的可信度都会被打折扣。老板批项目只关心三件事要花多少钱、多久能回本、最坏亏多少。成本估算回答第一件收益估算回答第二件风险预估回答第三件。这一章把这三块怎么算、怎么写、常见错在哪讲透。3.1 成本估算至少拆成四类成本估算最常见的错误是全篇只有研发人力成本。实际上一个产品从立项到跑通商业模式成本至少拆四类研发成本、运营成本、资源成本、机会成本。研发成本是产品、设计、前后端、测试的人力投入运营成本是渠道投放、市场推广、客服人力资源成本是服务器、云资源、第三方接口调用费机会成本是“如果不做这个产品团队还能做什么”。人力成本常见做法是按人日口径算。研发人日单价各公司差异很大通常在1500到2500元之间波动关键是口径要统一这个单价是纯工资还是含管理摊销、办公场地、五险一金的全成本。口径不统一会导致估算结果差一倍评审时被财务追问就露馅。写BRD不需要每笔都精确到个位但每个数字后面要能说出依据。成本项计算口径说明研发成本参与人日 × 人日单价产品、设计、开发、测试全包含运营成本渠道预算 推广人力按首年收入的一定比例预留更稳资源成本服务器费用 第三方接口费用按用户量峰值估算别按最低配算机会成本团队同期可做的替代项目定性写清即可3.2 收益估算三种算法要一起上收益估算比成本难写因为拍脑袋的空间很大。老板不怕收益低怕的是没有依据的收益高。我一般会同时用三种算法交叉验证直接营收法、降本增效法、战略价值法。直接营收法适用于有明确付费产品的场景公式是用户规模 × 付费转化率 × 客单价注意按年份分阶段测算第一年覆盖期转化率通常低于稳定期。降本增效法适用于内部工具或替代型产品算的是替代原有人工流程后每年节约的成本。收益表的结构建议做成收入来源、测算方法、关键假设、第一年、第二年、第三年。其中关键假设这一列最重要它决定了数字有没有讨论基础。假设写“首年付费转化率8%”就要说明这个8%是从哪个竞品公开数据或者自有渠道测试里来的。没有假设依据的数字在评审会上活不过第二轮。战略价值这部分不直接算钱但可以定性加粗略定量比如数据资产覆盖了多少用户、卡住了哪个生态位。写清楚“三年内不占这个位置后面要花五倍代价追”就足够了。3.3 风险预估带应对动作的风险才是风险风险预估是BRD里最容易被误写成形式的章节。“存在技术风险”“存在市场风险”这种一句话风险等于没写。风险不是用来预言的是用来提前安排下一步动作的。每条风险拆成三列触发条件、影响、应对动作。触发条件写清楚什么情况下风险会发生影响写清楚发生后对哪个指标产生多大影响应对动作写清楚风险发生后立刻启动什么措施。风险类型触发条件影响应对动作市场风险竞品提前发布同类产品用户获取成本上升、增速不及预期转投差异化细分场景同步推进B端定向合作技术风险核心算法效果达不到商用线产品体验不达标、留存下降MVP阶段先上规则引擎兜底算法后置优化投入风险成本超预算、进度延期上线时间后移、窗口期被压缩按阶段拆预算每阶段设置评审点不达标及时止损写风险应对动作时要具体到可以执行的程度而不是“加强调研”“紧密关注”这类空话。决策层看到“如果A发生我们就启动B方案”他对这个项目的判断就不一样了——你不是在向他汇报坏消息而是已经替他想好了退路。这也是BRD和普通项目计划的区别BRD的风险部分本质上是在替老板做压力测试。4. 从BRD到MRD再到PRD一次需求的三次转译BRD、MRD、PRD不是三份独立的文档而是同一个需求在不同阶段、对不同读者做的三次转译。BRD用商业语言告诉决策层“值不值得做”MRD用市场语言告诉运营和市场“卖给谁、怎么卖”PRD用研发语言告诉开发“做成什么样、怎么验收”。顺序不能跳直接写PRD的多半没想清楚商业逻辑只写BRD不落PRD的产品永远停留在汇报层面。4.1 三份文档的定位矩阵把三份文档放在一张表里看区别一目了然。BRD的读者是决策层核心问题是“要不要投入资源”产出物是商业方案评审标准是ROI和战略价值。MRD的读者是市场、运营、销售核心问题是“目标用户在哪、怎么触达”产出物是市场策略和用户需求分析评审标准是市场空间与获客可行性。PRD的读者是研发、设计、测试核心问题是“做什么功能、按什么规则跑”产出物是功能说明和流程定义评审标准是开发可执行性。三份文档的评审时点也不同。BRD在立项评审会上过过了才配资源、给人、给预算。MRD在正式开发前过用来统一市场侧和产品侧对目标用户的理解。PRD在排期评审前过过了才进开发。实际团队里MRD经常被压缩甚至跳过导致运营拿着自己想当然的用户画像去找客户和市场真实反馈对不上。我一般建议最少也要把目标用户分层和核心场景定义从BRD里抽出来单独过一遍哪怕就一页纸。4.2 从BRD转到MRD把商业语言翻译成市场语言BRD里的市场背景是宏观视角“市场规模年增速30%”这种结论在MRD里必须要变成具体动作第一批目标用户是谁在哪里能找到他们他们现在用什么替代方案一次获客成本大概多少钱。BRD说“机会空间大”没用MRD要说清楚“机会从哪个渠道能被抓住”。MRD的结构资料里没有展开但常见做法是包含六块市场机会、目标用户分层、用户需求与场景、产品能力与卖点、渠道与运营策略、关键指标。目标用户分层这步尤其重要BRD里写“目标用户为制造业中小商家”就够了MRD要把这批用户再拆层是老板直接决策还是运营操盘月销售额在哪个区间用Excel对账还是已经上了ERP。不同层级的用户需求表达方式和付费意愿完全不一样。用户需求和场景每一条都要写成一个完整的叙事“谁在什么情况下遇到了什么问题现在是怎么凑合解决的”。这个叙事越具体后面转PRD时功能定义就越容易。比如“一家月销50万的淘宝店老板月底花两天时间核对三个平台的账单经常对不上账”比“用户对账效率低”更容易翻译成功能。渠道与运营策略这块要写清楚首批用户从哪里来是内容引流、渠道投放、还是行业协会合作以及估算单用户获取成本这个数字直接喂给BRD的成本部分。4.3 从MRD转到PRD把市场语言翻译成研发语言MRD到PRD的转译是把“用户想要什么”变成“系统做什么”。MRD里写“用户想快速判断一款产品值不值得入手”PRD里要落地成“产品详情页包含评分、用户评价摘要、参数对比功能评分数据实时展示详情页加载耗时不超过2秒”。转译的跨度越大信息损耗越严重。我见过太多次MRD里写的目标用户是95后到PRD里默认场景按35岁用户设计中间没有任何人意识到口径已经变了。转译过程遵循三条原则。第一一段话只面向一个读者不要在一个PRD里既写给开发看又写给领导看。第二一件事在全套文档里只展开一次在BRD里讲了商业模式MRD里就不再复述商业模式只写它对市场策略的影响。第三能用数字就不用形容词把“用户体验好”换成“首屏加载低于2秒”“注册流程少于3步”开发不用猜测试也不用吵。PRD的基本内容一般包括需求背景、功能需求列表、功能详情、业务流程、规则逻辑、异常处理、埋点需求、验收标准。需求背景放一段简短说明即可重点写清楚这个功能解决哪个MRD里的用户场景方便开发回溯。功能详情里每个功能要写清入口、操作流程、前置条件、后置结果、异常分支。规则逻辑是最容易被遗漏的优惠怎么叠加、超时怎么处理、并发下怎么保证数据一致这些不写清楚开发就按自己的理解做。当研发提出“这个做不了”的时候我习惯用双层倒查法。第一层回到MRD看这个功能对应哪个用户需求如果需求本身站不住砍掉如果需求成立继续第二层回到BRD看这个功能支撑哪个商业目标支撑的话就调整实现方案而不是删除需求不支撑的话连同需求一起砍。两层都通过才改PRD。这套方法能拦住大部分需求漂移也避免PRD在开发中期被一句“技术实现困难”带偏方向。5. 三份文档的翻车现场五类高频问题与排查思路写文档写到能过会光知道“怎么写”不够还得知道“怎么写会死”。这一章整理的是我在实际评审和文档评审中见过的高频翻车点每条按现象、原因、解决三步走你可以拿来自查。5.1 BRD写成PRD老板问“你到底让我批什么”现象BRD里一半篇幅在写功能详情、按钮、页面流程决策层翻完文档不知道市场机会在哪也不知道要批多少钱。原因是把BRD当PRD的上位版用写功能的思路写商业文档或者对市场理解不够只能用功能细节充篇幅。解决方法是写BRD时先不打开PRD模板强制自己按7个框架走写完检查一遍凡是属于“产品主要功能”以外的实现细节全部丢到附录或者直接删掉。判断标准很简单删掉所有功能细节后BRD还能不能完整陈述背景、市场、收益、风险能就是合格的BRD。5.2 市场背景堆数据每个数都真整体没有结论现象行业报告截图、市场规模、增速数据贴了十几页看完不知道这个产品该做还是不该做。原因很直接只做了信息搬运没做信息判断。每个数据都是真的但它们之间没有形成结论。解决方法是给每个数据后面补一句“这意味着什么”并在市场背景写完时加一段“市场机会判断”收尾。比如“头部产品集中在××场景我们在××场景有差异化机会”用一页纸把前面所有数据的结论串起来。5.3 成本只算研发不算运营和渠道现象成本预算表里只有研发团队人力上线后市场推广、渠道分成、客服人力全部没算。老板问一句“获客成本呢”当场卡住。原因是成本口径按“做出来”算而不是按“卖出去”算。解决方法是把成本拆成四类研发成本、运营成本、资源成本、机会成本逐项填。运营成本哪怕暂时只写“按首年收入的30%预留”也比完全空白强。注意口径要统一别研发按全成本算、运营按纯工资算两类口径放在一张表里数字会失真。5.4 风险只做标题党有标题、没动作现象“存在技术风险”“存在市场风险”一句话完事。评审时被问“风险发生后怎么办”答不上来。原因是没有把风险当项目计划的一部分只当形式化章节在凑数。解决方法每一条风险必须写全“触发条件—影响—应对动作”应对动作要具体到能直接启动的程度。风险表写完自查一遍把“加强关注”“持续跟踪”这类空话全部删掉换成“启动备选方案”“切换技术路线”“转向B端合作”这种能落地的动作。5.5 MRD和PRD口径漂移两份文档自相矛盾现象MRD里写目标用户是30岁以下PRD里的默认场景却是35岁家庭用户MRD说核心功能是A开发排期里做的却是B。原因是文档写于不同时间点缺少统一的口径表中途改动只改了一份。解决方法三份文档共用一个口径表至少包含目标用户、核心场景、核心功能优先级、成功指标四个字段。任何一份文档需要改这四个字段时其余两份文档同步更新评审前先对口径表再对正文。这个习惯能挡掉一大类“文档在场上一套、开发做另一套”的协作纠纷。6. 最后一招评审会前十分钟自检与一页纸对照卡文档写完了怎么判断能不能上会我后来养成一个习惯评审会前十分钟不做别的只做四件事。三分钟看商业逻辑问自己“这份BRD删掉所有功能描述后能不能说清做还是不做”三分钟看用户人群问自己“MRD里的目标用户画像和PRD里的使用场景是不是同一批人”三分钟看验收标准问自己“PRD里每个功能有没有可以不吵架的验收标准”最后一分钟看版本号和口径表确认三份文档的修订记录和关键字段一致。检查维度看哪份文档合格标准商业逻辑BRD删掉功能描述后仍能独立说清做与不做的判断用户人群MRD目标用户分层与PRD场景中的用户一致验收标准PRD每个功能都有可测试的量化指标口径一致性三份文档共用口径表目标用户、核心场景、优先级、成功指标一致之后我又加了一步每写完一份BRD放一天第二天假装自己是老板重新读一遍。手里拿一支笔遇到形容词就画圈要求自己改成数字遇到功能清单就画杠问它属于哪个框架。如果读完整份文档还说不出“做还是不做”这版就不能上会再回去磨。这套动作不复杂但每次都能在评审前捞出至少三处逻辑漏洞。把配套的资料放在案头下次写BRD直接按框架走能少熬两个晚上。希望帮到你。本文还有配套的精品资源点击获取