市场需求文档（MRD）评审：验证市场分析、用户痛点、产品定位、商业价值

MRD评审是硬件产品从“市场洞察”转向“产品定义”的关键决策节点。评审通过后，研发资源将被正式立项投入；评审不通过，则需退回进行补充调研或方向修正。本流程SOP旨在规范MRD评审的标准化操作，确保所有利益相关方对市场、用户、产品、商业四要素达成一致。

适用场景

1. 新产品立项：新品类、新赛道产品首次进入研发管线。
2. 产品线延伸：原有产品线增加新SKU或功能/形态变更。
3. 版本重大迭代：客户群、价格带、核心场景发生根本变化。
4. 对外投资/合作引入：需要第三方资金或技术方共同推进前的市场验证环节。

前置条件

• 已完成不低于2轮的桌面研究与实地用户访谈（单市场≥15人）。
• 已完成初步竞品库（按市场占有率/技术路线/价格带覆盖≥5家）。
• MRD草案经产品经理自检通过，并提交至项目经理处进行符合性检查。
• 确认评审委员会成员：产品总监（主席）、研发负责人、销售负责人、财务代表、供应链代表。
• 会议时间已协调，并于评审前72小时发送MRD正式版本及议程。

操作步骤

1. 申请启动：产品经理在项目管理系统中填写《MRD评审发起单》，上传MRD v1.0。
2. 预审分发：项目经理在V2.0前组织预审，收集各委员书面问题。
3. 会议评审：产品经理现场演示MRD核心数据（市场空间、用户画像、痛点频次、商业模型），重点回答“是否值得做”与“为什么是现在做”。
4. 分域决策：按市场分析、用户痛点、产品定位、财务预测四维度逐一表决。
5. 结论输出：评审结论分为三类——通过（可进入产品定义）、有条件通过（标注待补足项及负责人）、不通过（退回并输出退回理由）。

输入输出物

责任边界

• 产品总监：对评审方向把关，拥有最终裁决权；若因市场误判导致产品失败，承担主要责任。
• 产品经理：确保所有数据真实可查，对MRD内容的完整性和逻辑性负责。
• 研发负责人：从技术可行性角度评估产品定位的可实现性，避免出现“市场需要但做不出”的场景。
• 销售负责人：验证渠道铺货模型和定价逻辑，对商业模型中的收入预估负辅助验证责任。
• 财务代表：检查ROI、NPV和盈亏平衡点计算，对数字准确性独立复核。

记录材料

异常处理

• 数据存疑：当评审委员对核心数据真实性提出质疑时，暂停评审流程，由产品经理在3个工作日内出具《市场来源说明与交叉验证报告》。
• 论证重大分歧：若出现关键维度（如“真实用户痛点强度”）双方各执一词，引入第三方咨询公司或行业专家进行盲审。
• 评审结论为“有条件通过”但待办超期：项目经理需在截止日前1天提醒负责人，逾期未闭环者自动降级为“不通过”，产品重新进入调研期。
• 不同意评审结论：允许产品经理在评审后48h内提交《复议申请书》，但需附带额外50%的样本量调研结论或竞品数据。

验收标准

1. 评审结论明确标注“通过/有条件通过/不通过”，无模糊语义。
2. 所有评审委员的评分卡完成填写且理由充分（不得出现“不确定”或空白）。
3. MRD v2.0中所有关于市场规模、目标客群、用户痛点、产品定位、商业模型的表述均已得到会议一致确认或分歧项已记录并指定后续验证责任人。
4. 若为“有条件通过”，待办清单中每项必须有负责人、截止日和完成标志物，且审查周期不超过15个工作日。
5. 输出物中MRD终版与评审纪要版本号对应，且评审原始材料（录音/会议记录）已按规范归档。