写BRD、MRD、PRD这篇东西其实是我一直想做的事。干了这么多年产品面试过不少人也带过不少新人发现大家对这三份文档的理解常常是混乱的。有人把PRD写成MRD有人在BRD里堆满线框图还有人干脆三份文档合成一份“大杂烩”领导看完不知道要拍什么板研发看完不知道要做什么功能。说到底BRD、MRD、PRD不是三种叫法不同的同类文档它们出现在产品生命周期的不同阶段面对的是完全不同的读者要回答的也是完全不同的问题。这篇文章我就把这三兄弟掰开揉碎讲一遍讲清楚它们各自是什么、给谁看、怎么写、写多细最后再附上我在实际项目中踩过的坑和常用的模板思路希望对正在做产品或者准备转行做产品的朋友有帮助。1. 三种文档各管什么先搞清楚读者再动笔1.1 BRD给决策层看的“投资方案”BRD全称Business Requirements Document商业需求文档。这个“商业”两个字是核心它本质上是把产品当成一个投资项目来论证回答的问题是这个东西值不值得做。所以BRD的读者只有一个核心人群能拍板的人。可能是CEO可能是VP也可能是投资委员会。这些人没有时间看你的线框图也不关心你这个按钮放左边还是右边他们只关心三件事市场有多大要投多少钱能赚多少钱。很多人写BRD容易犯一个错误就是把它当成一份“大而全”的产品说明书什么用户调研、功能列表、技术架构全塞进去。这是本末倒置。BRD的篇幅控制在10到15页PPT以内就够了核心就是要让决策者在半小时内做出“做还是不做”的判断。我见过写得好的BRD开头第一页就是结论我要做什么需要的资源是什么预计多久回本。后面再展开讲市场分析、竞品格局、商业模式、风险预案。这种“结论先行”的写法对决策者极其友好也更容易拿到资源。1.2 MRD给协作团队看的“作战地图”MRD全称Market Requirements Document市场需求文档。它在三份文档里位置最尴尬也最容易被跳过。很多人觉得BRD有了、PRD有了MRD就是多余的。但实际上MRD解决的是BRD和PRD之间的鸿沟BRD说了“我们要做”但没说“为什么要这么做”MRD就要把市场逻辑和用户逻辑讲清楚。MRD的读者是产品团队内部、运营团队、市场团队、设计团队以及部分核心研发。它的核心任务是回答“为谁做”和“做什么方向”包括目标用户是谁、痛点是什么、市场机会在哪里、竞争对手怎么样、我们的差异化定位是什么。我自己的习惯是MRD一定要放用户画像和场景故事。比如我之前做一个面向中小商户的记账产品MRD里就写了一个典型用户“王姐”的故事她开了三家奶茶店每天最头疼的是月底对账经常忘记哪笔钱没收回来。这样的场景故事比干巴巴的数据更能让团队成员建立共情后续做PRD的时候大家就会主动去想“王姐在什么情况下会用到这个功能”。MRD不需要写具体的交互细节和字段规则那是PRD的事。但如果MRD做得足够好PRD的撰写会非常顺畅因为方向已经定死了剩下只是怎么落地的问题。1.3 PRD给研发设计看的“施工图纸”PRD全称Product Requirements Document产品需求文档。这是你在一线干活时花时间最多、也最需要较真的文档。如果说BRD是投资方案MRD是作战地图那PRD就是施工图纸——施工队拿到图纸就能盖楼研发拿到PRD就能写代码。PRD的读者是研发工程师、UI设计师、测试工程师以及后续接手的运营和客服团队。它要回答的问题非常具体这个功能怎么交互、有什么状态、异常情况怎么处理、数据怎么统计、权限怎么控制等等。一个合格的PRD应该让研发在开发过程中不需要跑过来问你“这个地方逻辑是什么”。当然这很难做到百分百但至少你要把能想到的边界情况、异常分支都写清楚。我见过很多刚入行的产品经理PRD里只写了“正常流程”结果一开发测试提了一堆问题断网怎么办、重复点击怎么办、数据为空怎么办、权限不足怎么办——全都没写。这种PRD不仅拖慢开发进度还会让团队对你的专业度打问号。关于PRD的写法细节我会在第三部分展开讲这里先建立一个基本认知PRD的颗粒度至少要细到每一个字段、每一种状态、每一条错误提示。2. BRD、MRD、PRD的演进逻辑从“要不要做”到“怎么做”2.1 三份文档的本质差异对照为了更直观地看清楚三份文档的区别我整理了一张对比表可以帮你快速定位它们在不同阶段的用途维度BRDMRDPRD核心问题要不要做为谁做、做什么具体怎么做目标读者高管、投资人产品、运营、市场、设计研发、UI、测试决策层级战略决策方向共识执行落地核心内容商业价值、成本收益、风险评估用户画像、竞品分析、市场机会功能清单、流程逻辑、交互细节篇幅10-15页PPT20-30页文档或PPT按功能模块拆分可长达几十上百页常见产出立项审批方向统一研发排期生命周期项目启动前BRD之后、PRD之前开发、测试、上线阶段这张表可以当作你的“文档导航图”。拿到一个需求先问自己我现在卡在哪个阶段如果还不知道要不要做去写BRD如果已经确定要做但方向还没统一去写MRD如果方向已经定了团队就等着开工别再磨蹭赶紧写PRD。2.2 三层“翻译”的过程需求是如何一步步变具体的我经常把BRD到PRD的过程类比成“把一句想法变成一栋楼”的过程。BRD是“我要建一栋楼”。决策层关心的是地皮贵不贵、盖起来要多少钱、能不能租出去赚钱。这时候你不可能拿施工图纸去汇报老板没时间看也看不懂你要讲的是投资回报。MRD是“我要建一栋什么样的楼”。这时候你要研究周边住的是什么人、他们的居住习惯是什么、附近有没有同类楼盘、我们的差异化是主打学区还是主打江景。这个阶段建筑设计师、营销团队都要参与讨论统一“这栋楼为谁而建”的共识。PRD就是“施工图纸”。每一面墙怎么做、每根水管怎么走、每个插座在哪个位置都要画清楚画明白。这时候工人进场按图施工不需要施工队自己去猜“这里是不是该留个窗户”。如果他们需要猜就是图纸不够细。这三层翻译每一层都在丢失一些信息也在增加一些信息。丢失的是上一层的宏观背景增加的是下一层的执行细节。一个成熟的产品经理要能在三层之间自由切换知道自己在哪个层级该多宏观、多细微。我见过不少产品经理要么从头到尾只写PRD从来不关心商业逻辑结果功能做出来没人用要么天天沉迷于写BRD和战略分析一到PRD就敷衍了事结果开发出来的东西根本不能用。这两种极端都是要避免的。2.3 什么时候可以“砍掉”某份文档这里必须说句大实话不是所有项目都需要三份文档都写全。我自己的判断标准是这样的如果是全新的产品线、投入超过一个季度人力、涉及跨部门资源协调BRD不能省如果是已有产品的功能迭代BRD基本可以跳过从MRD开始写如果是Bug修复、文案调整、样式微调连MRD都可以省直接PRD甚至不需要PRD在需求池里记一笔就行。但MRD这件事我强烈建议不要跳。即使是一个很小的功能你也至少要在PRD开头用两三段文字说清楚这个功能是给谁用的、解决什么痛点、有没有更简单的替代方案。这样做有两个好处第一逼自己想清楚再动手第二让研发和测试知道“为什么做”他们在遇到方案问题时能帮你判断取舍而不是机械地执行。很多时候研发说“这个功能逻辑有问题”不是故意找茬而是他真的理解了这个需求的本质发现了你想得不周到的地方。3. PRD的核心结构与实操写法把颗粒度做到位3.1 PRD的“骨架”一份标准PRD应该包含哪些模块虽然各家公司的PRD模板千差万别但核心模块基本趋同。我习惯把PRD分成七个部分你可以根据项目类型灵活调整但千万不要省掉其中任何一个核心模块第一部分是需求背景与目标。用3到5行说清楚为什么做这个需求产品目标是什么怎么衡量成功。这里会放核心指标比如次日留存提升到某个数值、转化率提高多少个百分点。没有目标的PRD开发完也不知道做得好不好。第二部分是名词解释与全局规则。很多产品有自己的特定术语或者在整个产品体系中已经有既定的规则比如“会员等级怎么计算”“积分是否支持抵扣现金”这些要在全局说明中交代清楚避免每个功能文档里重复写。第三部分是功能需求详述。这是PRD的主体每个功能模块单独一个章节包含用户故事、功能描述、交互逻辑、异常流程、数据埋点。这部分我会在下面单独展开讲。第四部分是页面与交互说明。如果公司有专门的交互设计师这部分可以简化如果没有产品经理就要把关键页面的布局、交互状态、跳转关系用线框图加文字的方式描述清楚。第五部分是数据埋点需求。这个经常被新手忽略但非常重要。每一个核心按钮、每一个关键页面都要提前定义好埋点事件和参数。等上线了才想起来要数据那就只能等下一个版本补埋点白白丢了一波数据。第六部分是权限与兼容性。哪些角色能看到这个功能是否需要灰度发布是否要兼容低版本客户端Web端和移动端是否同步上线这些都要写清楚。第七部分是依赖与排期。这个功能依赖哪些接口依赖哪些第三方服务上下游有没有阻塞项建议的开发和上线时间节点是什么。这部分不需要写很细但要让项目管理者一眼看出卡点在哪。3.2 功能详述的“血肉”用户故事、逻辑流程、异常状态功能详述是PRD里最耗精力的部分。我常用的描述方式是“用户故事逻辑规则异常状态”三段式。先说用户故事。比如做“购物车批量删除”功能用户故事可以这样写用户勾选多个商品后点击“删除选中”系统弹出二次确认框确认后将选中商品移除并提示“已删除N件商品”。这个描述直观研发下一秒就知道要做什么。然后是逻辑规则。写在用户故事后面用条目化方式列出具体规则。比如“勾选上限为50个”“删除后不可恢复”“清空购物车按钮与批量删除按钮并存时优先提示清空操作的影响范围”。规则要尽量穷尽宁可多写不要漏写。最后是异常状态。这是拉开普通PRD和优秀PRD差距的地方。什么叫异常状态网络超时、接口报错、数据为空、并发冲突、重复提交、权限变更、极端输入值等等。每一条异常状态都要给出对应的交互反馈和容错处理。举个例子一个“发布文章”的功能正常流程很好写就是填标题、写正文、点发布。但异常状态有多少草稿没保存就退出怎么办标题超过限制长度怎么办正文包含敏感词需要二次审核怎么办发布过程中断网怎么办同一篇文章被两个管理员同时编辑并提交怎么办。这些问题每一条都要写清楚。如果研发在开发时遇到你文档里没覆盖到的场景他只能自己拍脑袋拍对了是运气拍错了上线就是事故。3.3 数据口径与埋点写清楚才是对团队负责数据这块是新手产品经理最容易敷衍、但实际上对产品后续影响最大的部分。我见过很多PRD里写“进入页面时埋点”就这么一句话连事件名都没定义。开发听了不知道怎么埋最后自己起了个名叫“page_view”等要数据分析的时候发现有五个“page_view”事件来自五个不同页面数据根本对不上。我的经验是每个埋点事件都要写清楚三件事事件名、触发时机、参数列表。字段名建议统一用大写字母加下划线比如SUBMIT_ORDER、CLICK_SHARE_BUTTON参数要和后端定义好的字段一致。PRD里最好附带一张埋点表列名包括“事件名称”“触发页面”“触发条件”“参数名”“参数说明”“埋点方式”。这张表不仅是给开发看的也是给数据团队和测试团队看的。测试会根据这张表逐条去验证埋点是否生效数据团队后续基于这张表做报表和分析。另外一个容易踩的坑是“数据口径不一致”。同一个指标业务方说“新增用户”数据团队说“新增设备”研发说“新注册用户”三方吵起来都不知道听谁的。所以在PRD里凡是涉及指标都要在括号里标注清楚口径定义。比如“新增用户当日完成注册且未注销的设备数”这样所有人都按同一个规则来。3.4 给新人的PRD自查清单写完PRD后我建议你在发给评审会之前用下面这份清单自己过一遍。每一条不过就改改到全过再发。每一个功能模块是否有明确的“用户故事”描述所有的业务规则是否条目化且不存在歧义异常状态是否覆盖了网络异常、数据为空、重复操作、无权限这四类场景按钮文案、页面提示语、空状态文案是否都已写清楚关键操作是否都定义了数据埋点字段名是否统一兼容性要求是否声明Web/App/微信小程序/不同操作系统版本是否标注了风险点和依赖项不需要开发的纯运营配置是否注明上线后需要运营或客服关注的事项是否单独说明我的一位老领导跟我说过一句话我一直记着“PRD写到什么程度代表你对这个产品上心到什么程度。”你糊弄文档团队就糊弄你。4. BRD和MRD的写作要点别把方向性文档写成PRD4.1 BRD的写作结构结论先行数据支撑BRD这块的写作我推荐一个实战中很实用的结构总共六个板块第一个板块是项目概述。用一页纸说清楚产品是什么、目标用户是谁、解决什么问题、项目周期多长、预算多少。记住写BRD不要写“我们要打造一个什么平台”要写“我们准备投入XX万元在X个月内做出一个XX产品预期在第X个月开始产生收入”。第二个板块是市场分析。包括市场规模、行业趋势、政策环境。市场规模不要只会引用别人报告里的数字要算一下。比如做一个面向宠物主的社区产品你可以用“养猫养狗的家庭数量×年均宠物消费金额×我们可获取的渗透率”来估算市场空间。数字不用分毫不差但逻辑要能自洽。第三个板块是竞品分析。BRD里的竞品分析不需要像MRD那么细但要说清楚这个领域现有玩家有谁他们做得怎么样我们的机会在哪里。这里最怕写“市场空白、没有竞争者”这种话决策者一眼就看出你没做功课。真正的市场空白极少大部分情况是竞品做得不好这才是你的机会。第四个板块是商业模式。你靠什么赚钱交易抽佣、广告收费、会员订阅、增值服务这个板块不用写到财务报表那么细但要说清楚收入模型和大致测算。我常用的做法是做一个简化的单用户经济模型一个用户获取成本是多少生命周期内能贡献多少收入毛利是多少。第五个板块是风险与对策。政策风险、技术风险、市场风险、团队风险列个两三页就行。好的BRD不是说自己没风险而是说我知道了有哪些风险并且有相应的应对方案。第六个板块是资源需求与里程碑。要多少人、要多少钱、要几个部门配合分几个阶段什么时候上线什么时候验证。这部分越具体越好决策者可以按这个排计划不用后续再反复沟通。4.2 BRD里最容易被挑战的三个问题写BRD被挑战是常态我总结了三个最高频的问题以及应对思路。第一个问题是“你的数据哪来的”市场数据如果是引用外部报告一定要标注来源如果是自己估算的就要把估算过程写出来让老板知道你是有分析依据的不是拍脑袋。第二个问题是“为什么是我们做”这个问题本质是问你团队的核心竞争力。比如你有独家渠道资源、有核心技术壁垒、有现成的用户流量池这些都是你的护城河。如果什么都没有那你要诚实说明同时给出如何快速建立优势的方案。第三个问题是“不做行不行”这个问题要回答的是机会成本。如果这个需求不做会损失什么竞品会不会抢先现有用户会不会流失你不仅要讲做的好处还要讲不做的坏处。很多时候“不做”的代价比“做错”的代价更大把这个逻辑讲清楚你就赢了。4.3 MRD的写作要点用户画像、场景故事与竞品交叉分析MRD的写作我推荐按四个模块来组织第一个模块是目标用户定义。不要只写“18-35岁、一线城市、月收入过万”这种人口统计学标签这些太虚了。你要写用户的深层需求、行为习惯、使用场景。比如“关注性价比的妈妈群体”“每天通勤超过1小时的白领”会比“30岁女性”有用得多。第二个模块是用户痛点与场景故事。每个核心用户画像配1到2个场景故事。场景故事要有细节有情绪让人读完之后能感受到“这确实是真事”。我自己写完场景故事后会拿去给身边的目标用户看如果他们觉得“这不就是我吗”说明场景抓准了。第三个模块是竞品分析。MRD的竞品分析比BRD要深入不要只列“功能对比表格”要看竞品的定位差异、目标用户差异、运营策略差异。我习惯用“用户-功能-场景”三个维度交叉分析。比如两家做健身App的竞品一家主打家庭健身场景靠内容付费另一家主打健身房场景靠SaaS服务收费。表面上看是竞品实际上用户、场景、商业模式完全不同。这种分析才有深度。第四个模块是产品机会与定位。基于前面的用户分析、竞品分析明确我们的产品切入点是哪里定位语是什么三个关键词形容产品调性比如“简单”“可靠”“有趣”核心功能优先级排列MVP阶段做什么、后续迭代做什么。这个模块是MRD和PRD之间的桥梁优先级排清楚了PRD的范围就不会跑偏。4.4 MRD常见的“变体”与写法取舍不同公司对MRD的叫法和要求不一样有的叫“市场需求文档”有的叫“产品概念文档”有的直接叫“立项报告”。核心内容大同小异你只需要抓住“市场用户”这条主线。MRD的长度没有硬性要求但我的经验是控制在10到20页之间。太短说明你没想透太长说明你还没从细节里抽离出来。一个有用的小技巧每页PPT只讲一个核心观点尽量多用图表少用大段文字。MRD是要在评审会上讲的视觉化的表达能显著降低沟通成本。5. 从立项到评审的完整实操流程需求文档是怎么流动的5.1 一份需求从0到PRD的完整路径很多新人对需求文档的生成过程有误解以为一份PRD是坐在工位上凭空写出来的。实际上一份靠谱的PRD背后往往有一条完整的项目流。我按时间顺序拆解一遍。第一步是需求收集阶段。需求来源包括用户反馈、数据分析、竞品监控、业务方提需、老板指令。这一步的关键是“广撒网”但不要做任何筛选先全部记录下来。我会用一个统一的需求池表格字段包括需求来源、需求描述、提出时间、提出人、优先级、状态。第二步是需求筛选与分析。这一步要做的是把需求池里的内容进行归类、去重、优先级评估。最常用的方法是价值和成本二维矩阵价值高的先做价值高成本低的立刻做价值低成本高的直接埋掉。这个阶段如果需求足够大就该启动MRD了。第三步是MRD撰写与共识会。MRD写好后约上运营、市场、设计、核心研发一起过一遍。这个会的目的不是“通过”而是“对齐”——所有人对用户是谁、方向是什么达成共识提出异议并解决。这个阶段改方向的成本最低千万不要拖到PRD写完再改。第四步是PRD撰写。MRD共识会开完方向定了就可以基于MRD拆功能模块逐个模块写PRD。PRD的写作顺序建议先搭框架再填内容最后补异常。第五步是PRD评审会。评审会一般分技术评审和需求评审两场。技术评审侧重可行性和排期需求评审侧重业务逻辑和范围。评审会上要过的是功能清单、核心流程、关键规则、埋点需求、里程碑计划。评审会后要出评审纪要和修订计划。第六步是开发、测试、验收与上线。PRD定稿后产品经理的工作并没有结束你还要在开发过程中随时解答疑问在测试阶段和测试对需求理解复核在验收阶段按PRD逐条核对功能是否符合预期。第七步是数据验证与迭代。上线后要按PRD中设定的指标去做数据观测出一份简要的数据结论。功能好不好用不是上线那一刻说了算而是数据跑了一两周之后才能下判断。5.2 评审会上最容易被围攻的五个环节评审会是产品经理的“大考”。我在无数次被围攻中总结出五个高发环节你可以提前做准备。第一个高发点是需求价值说不清。评审会一开始如果研发或业务方问“我们为什么要做这个功能”而你只能回答“老板说的”或者“业务方提的”那这场会你基本就失去了话语权。所以PRD第一部分的需求背景与目标一定要自己先想透能用数据说明的尽量用数据。第二个高发点是异常情况没考虑到。评审会上最尴尬的时刻是测试在下面轻描淡写地来一句“那如果用户连续点了十次呢”而你答不上来。我的应对习惯是在发评审通知之前先请一位资深的研发或测试朋友帮忙预审一遍PRD专挑异常场景来问被问倒了就补上再发正式评审会。第三个高发点是规则前后矛盾。比如PRD里在模块A写明“所有金额保留两位小数”在模块B却出现了“价格显示取整”的描述。这种低级矛盾最伤信誉而且经常被挑出来。解决办法是在提交评审前一遍一遍通读全文特别注意数字单位、状态定义、权限描述是否前后统一。第四个高发点是工作量与排期争议。评审会上研发说“这个需求排不过来”产品说“下个月必须上”针尖对麦芒。这种局面不是说谁对谁错而是你需要提前准备好“最小可行版本”的切割方案——什么功能这期非做不可什么功能可以放到二期哪些是P0哪些是P2。你不能比研发更懂排期但你可以通过优先级排序帮团队做减法。第五个高发点是埋点和技术成本被忽略。很多PRD重功能和交互轻数据和技术改造评审会上被后端一句“你这个需求要改老接口风险很大”给卡住。提前和研发做技术预沟通把依赖和风险项标注清楚评审会就会顺畅很多。5.3 文档版本管理与协作多人迭代时怎么不“打架”一个复杂项目的PRD动辄几十页还可能有多个产品经理同时维护不同模块。文档版本混乱就是灾难的开始。我的做法是第一整套需求文档统一放在可以多人协作且可追溯历史的工具里比如飞书文档、Confluence、语雀。第二文档顶部标明当前版本号、最近修改时间、修改人、修改说明。第三每次评审会之后一定要更新版本号并且把评审会决议里的调整点逐条列在“修订记录”里。第四所有重大变更都应该在IM群里同步一次而不是只改文档不说话。特别提醒一点PRD是“活文档”不是写完了就封印的。开发过程中发现逻辑漏洞、交互冲突、实现复杂度超标都需要及时修订PRD并同步给团队。但修改不是随心所欲的要经过口头确认、文档标注、群通知三个步骤避免改来改去最后谁都不知道哪个版本是准的。6. 常见问题与排查技巧实录那些年我踩过的坑6.1 一套高频问题速查表我把日常带新人时反复出现的问题汇总成一张表每一项都是我或我身边的人真金白银换来的经验。你可以把它当作自查工具每写完一份需求文档就对照一遍。问题表现根本原因解决思路老板说“你写的我看不懂”BRD里堆了太多产品术语和功能细节回到商业视角只讲市场、收益、风险开发说“这个需求没法做”PRD没做技术预沟通存在隐性依赖写PRD前先和研发对一轮技术方案评审会不断开每次都改逻辑MRD阶段没有统一方向导致PRD反复横跳把MRD共识会做扎实方向不统一不准写PRD测试提了一堆“你没写”的异常异常状态覆盖不全只写了正常路径自查清单中强制检查异常四类场景上线后想复盘数据发现没埋点数据需求写得太晚开发已提测埋点表在PRD评审时必须同步提交多人在同一篇PRD上改覆盖了别人的内容文档协作机制混乱指定唯一负责人分模块编辑用可追溯工具用户反馈说“这个功能完全不是我想要的”跳过了MRD用户画像和场景没有拉齐哪怕是大迭代也要花半天时间写用户场景故事开发完成后发现页面文案不一致PRD里没有统一文案规范风格全靠UI自由发挥PRD中附带关键文案列表按钮/提示/空状态写死6.2 新人最容易踩的五个“埋雷式”错误除了上面表格里的共性问题还有五个错误是新人特别容易踩而且踩了之后很难发现的。第一个错误是把PRD当成“合同”而不是“沟通工具”。有些新人PRD写得极其详尽但开发阶段几乎不参与也不和研发沟通结果上线效果和预期差距巨大。PRD只是一个静态文本动态的信息同步、方案讨论、问题澄清才是让项目顺利推进的关键。第二个错误是“大而全”思维。一个版本的PRD想把所有东西都写了结果每个模块都很浅评审会开不完。我的建议是宁可砍范围也要把核心流程做深做透砍掉的放到二期继续。第三个错误是过度依赖竞品。看到竞品有直播带货于是自己也要做直播带货竞品上线了拼团于是自己也拼团。关心竞品是好事但你要先回到你自己的用户和场景里去判断这个功能是不是真的适合你的产品形态。照搬竞品做过的东西往往只抄到了外壳没抄到内核。第四个错误是不写“为什么”只写“是什么”。PRD里特意留出位置记录决策背景和考虑过的方案比如“为什么不用弹窗而用侧滑面板”“为什么默认选中A而不是B”。这些“为什么”在开发阶段很有价值研发遇到bug时可以根据你留的背景信息选择更符合预期的修复方式。如果你只写“是什么”过三个月回来看自己都想不起当初为什么要这么设计。第五个错误是脱离数据做设计。功能上线后从不看数据也不复盘。我知道有些产品经理把“需求上线”当作终点然后马上扑向下一个需求。长期来看经验没有沉淀同样的错误会在不同项目里反复出现。我的习惯是每个版本上线后写一份极简复盘记录实际数据和预期数据的差距以及下次可以怎样调整。6.3 一份让我印象深刻的PRD案例复盘说一个我自己早期的项目那是给一个B端后台管理系统做权限模块的PRD。当时我把所有精力都放在了“角色管理”“菜单配置”“数据权限划分”这些正常流程上写了一大堆页面交互和字段规则自我感觉良好。结果评审会上测试提了一个问题“如果一个用户被同时分配了管理员和运营两个角色他的权限取并集还是交集以哪个角色为准”我当时就愣住了。两个角色的数据权限不一样页面菜单也有重合和冲突我没有定义角色冲突时的优先级规则开发只能按默认逻辑来处理而默认逻辑很可能不是我想要的。这个问题的根源是我只想到了“单一角色”的静态场景没有覆盖“多角色并存”的真实业务场景。那次之后我复盘了两个经验第一B端系统的PRD一定要写“权限矩阵”横轴是角色纵轴是功能点交叉处标注“可见/可编辑/不可见”这样权限关系一清二楚。第二凡是涉及“多对多”关系的功能都要追问一句边界是什么冲突怎么处理默认值是什么。从那以后我写PRD就多了一个习惯在一个模块写完初稿之后逼自己站在“最刁钻用户”的角度去挑刺——什么情况下这个功能会出问题、用户会怎么误操作、两个功能叠加会产生什么化学反应。这个方法帮我提前拦下了很多上线后才能发现的问题。6.4 文档之外的能力需求文档真正锻炼的是“想清楚”的能力最后说点务虚的。很多产品新人以为写BRD、MRD、PRD练的是文档排版、写作用词、工具熟练度。但做了这么多年产品我越来越觉得这些文档真正锻炼的是“把一件事从模糊想清楚”的能力。BRD逼你想清楚“值不值得做”MRD逼你想清楚“为谁做、为什么这样做”PRD逼你想清楚“每一步到底怎么落地”。这三层想清楚了产品经理的很多其他能力包括沟通能力、项目管理能力、数据分析能力都会跟着长出来。我自己带新人的时候不太在意TA用的模板有多漂亮、工具多熟练更在意的是TA能不能把一个需求从商业逻辑一路讲到交互细节、中间没有任何断档。能讲清楚说明TA真的想明白了讲不清楚十有八九是没想明白而不是语言表达的问题。7. 写在最后的一点私货这篇文章写了很久也梳理了很多东西。如果只总结成一句话带回家我会说BRD、MRD、PRD这三份文档表面上是不同阶段的产出物本质上是你对一个产品从商业、市场到执行层层递进的理解。我给团队的建议一直是写文档不要追求一步到位也不要追求华丽美观先求“逻辑闭环”。每一份文档写完自己先读一遍读的时候不断挑战自己——这里有没有漏洞那里的假设成立吗换个角度看还成立吗当你能把自己的文档读“薄”讲到任何一个模块都能脱口而出背后的理由时这份文档就已经超越模板本身了。如果这篇文章能帮你少走一点弯路让某个产品经理新人从“不知道怎么写”变成“知道什么阶段该写什么、写到什么颗粒度”那这就算值了。多说一句文档是手段不是目的。真正推动一个产品往前走、让团队一起朝同一个方向使劲的永远是那个“把事情想清楚、说清楚”的你。祝各位在产品这条路上越写越明白。