## 背景

曾经被问到 MRD 包括哪些模块，当时有点懵，因为之前写 PRD 比较多，当然 MRD 也写过，但不同团队不同要求，一般都是内部要个模板，然后往里填内容。这里存在两个问题：一是当被问到这个问题时，要有自己的答案；二是平时写需求相关文档时要注意格式，这会让我们显得专业，很多时候形式的重要性不输于内容。

## 思路

### 需求认知

需求 是什么？说人话就是问题，那么这是一个多大的问题：有多少人遇到了该问题（范围）、严重与否（程度）、未来是否还会遇到，问题的确认方式包括但不限于访谈、数据调研等，其中用户愿意花钱的一般是大问题。

产品是什么？说人话就是解决方案，涉及用户价值（含社会价值）和商业价值。其中用户价值要考虑 竞品 （“用户价值 = 新体验–旧体验–迁移成本”），竞品即现在、未来满足同一需求的产品，同时终极竞品是持续变化的用户需求，而 商业价值= 用户数 * 付费率 * 客单价 * 复购频次，最后，产品价值 = 用户价值 + 商业价值。

市场情况如何？包括市场的天花板和现状（初期还是成熟期，如果是初期，为什么进场者少，如果是成熟期，是否有新的变量出现）、供需两侧的情况包括供给侧产业链上下游（设计生产制造）的状况、市场上的直接间接竞品等。

### 需求满足

做产品涉及规划、落地和运营。在规划落地方案时，至少开两次会：一是需求沟通会，针对问题，包括需求背景（价值 & 目标）、预期解决方案、优先级、上线时间等；二是需求评审会，针对解决方案，方案有没有漏洞、有没有更好的方案、排期有没有要调整的地方，这两部分都要看看业务方、产研团队的意见。整体而言，可以说产品是需求的集合、迭代，而公司是产品的集合、迭代。

最后回到开头那个问题，文档是产品方法论的附加产物，BRD、MRD 和 PRD 的区别在于阶段不同（也是一个前中后阶段的关系）、阅读对象不同、侧重点不同（why、what、how），具体格式可以参考网上的一些观点，比如 需求文档的区别与联系、产品需求文档模板 1、模板 2 等。

基于前段时间参与的项目，重新思考了下产品工作的方法论。

首先，工作层面，按照定义、分析、解决问题的步骤进行。其中定义问题是核心，方向错了，后面的努力多是无用功。定义、分析问题的过程中，对内主动沟通，单独问人或组织会议；对外调研竞品，包括产品试用、FAQ 阅读。这部分的核心更多的是沟通，需要注意的是尊重领导、同事的意见，除非能提出明显更好的方案。

至于解决问题，有些子场景未必要通过产品的形式解决，在当前阶段，线下处理也许更合适，当然汇报时要将当前先线下处理未来再线上化这部分包含进去，这是思考没有遗漏、有产品规划的体现。整个方案先完成再完美，之所以要小步快跑，一方面是灵活，后续好调整；另一方面任何解决方案都有 ROI，都是在与时间赛跑。

其次，产品层面，先对齐需求、功能、流程，再设计原型，从宏观到微观，其实这是比较基础的原则，只是知晓原则的同时还要想办法坚守原则，毕竟前三者一变，很多原型就白画了，本身产品原型中的字段、交互跳转就比较花时间，当然在对齐需求的过程中，如果某些内容是绝对明确不会变的，也可以先设计。

其中，需求层即明确问题，核心是主动，通过一切途径包括找一切可能了解业务的人去了解需求，然后和领导确认。功能层，基于对需求的梳理，明确每个功能的价值。流程层，可以视实际情况细分，比如先画简单的步骤图（流程图或简版流程图），如果这部分确认没问题，再开始泳道图（跨职能流程图）的设计。

再说原型，首先，文案层面 “说人话”，标题、正文、按钮、表头等要一目了然，不要让看的人有歧义，这点在评审阶段尤其要多听听大家的意见，因为存在 “知识的诅咒”，而破解之法是开放的心态，只要一个沟通方有困惑，那就想想有没有更好的说法；其次，数据层面要尽量拟真，比如不要出现列表页订单号都是同一个、列表页跳转详情页的订单号对应不上等问题。为了实现以上两点，一是可以复制线上的真实数据，稍加修改；二是平时要有素材积累，方便复用。