PH囧ENIX的Weblog

什么是MRD？我会不会太废话了些？还是先简要说一下什么是MRD吧

Market Requirements Document,简称市场需求文档。市场需求文档的主要功能是描述什么样的功能和特点的产品（包含产品版本）可以在市场上取得成功。产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现 商业目的，功能/非功能需求分哪几块，功能的优先级等等。

一般来说，我们最常见的PRD是在MRD的基础上产出的，当然，产出PRD还需要原型、思维导图还有Feature List之类一堆东西的辅助。

作为产品经理，我参与过好几个项目，从大公司到小公司，产品经理的角色，一直都在实际上处于很尴尬的位置。上周末的UCD广州年会，帽子男发问“能够参加自己公司核心战略会议的请举手”—-会场上举手者寥寥无几。关键，白鸦问的是“参加”而不是“参与到”，如果问的是后者，估计人就更少了。

产品经理这一概念，在05～07年产品的理念刚刚插入中国互联网时，是很火热很强势的。产品经理的角色定位通常都是公司总裁或者副总裁的直属员工，管理的产品部门属于公司的直属部门，会参与到公司整个市场分析、战略、决策、运营、推广等各方面中去；那个时候，MRD是属于产品经理的重点工作之一，尤其那个时候的大部分产品经理都是由市场转型过去的。

最近几年，产品的概念在中国互联网开始深化。一方面，产品经理慢慢退出公司战略与决策部门，取而代之的是通过数据研究去知道决策的UED部门（初期这个也是产品经理的工作之一）；另外一方面，产品经理的更多精力也开始投放在产品细节上，并且与UED部门进行协作式产出PRD文档；当然，还有一个不好的方面，当产品的概念泛滥以后，部分PD、前端甚至美工也开始自称产品经理，这些“产品经理”自然无权写MRD了。

有些朋友告诉我，他们公司是把MRD合并在PRD里面一个文档完成的。我想，这是不是有点多此一举的味道在，一般来说，PRD文档是交付给开发部门的文档，MRD写在里面，第一方面是没人看，第二方面是你写那么多东西给到下面开发部门，他们根本就看不懂（或者根本不愿意去看懂）。产品和开发从来就是一个不可调和的矛盾体，有些是运营做调解有些是根本就是产品部门去直接对接。妄想以MRD去告诉开发部门哪些功能非常重要切勿删掉还不如直接在PRD上以红色粗体说明更有意义（just kidding，我很多时候是真的想这么做的）。

那，到底MRD是在哪里产出的？我们看看产品流程—

首先是UED部门接到通知或者经过公司战略会议，决定去开发这么一个新产品。然后交由UED部门进行竞争产品分析，然后是领域调研，然后与公司高层会议签署决定，再进行产品定位、用户分析、产出产品概述。在产出产品概述这个过程中，UED部门一般会邀请产品经理参与，产品经理会参与这个讨论并产出思维导图（这个其实自己用的机会多，当然也可以帮忙理清UED部门的头绪）。把产品概述整理好并得到UED部门的确认后，产品经理根据产品概述以及思维导图以及自己的思维，可以写Featue List，然后再把Feature List整理好以后，再上交UED部门，共同产出MRD。MRD首先要经过公司高层确定，放可以交由产品经理去产出概念模型。

所以，产品经理需要写MRD吗？事实上，MRD应该是由UED部门与产品部门共同合作产出，但是主要是由UED部门做的。但是，实际上，大部分公司都不包含UED部门（或者UED部门只是产品部门的一个下属部门），那MRD就是由产品经理（总监）去做的了。当然，这样的坏处就是，整个产品就有可能会被产品经理一个人误导的可能性。

所以说，现在的产品部门的架构还是相当地混乱。我认识的人里面充满了毫无实权的产品经理（和PD差不多），也有至高无上的（就是总裁直属）。前者只是在默默地做产品模型，后者一旦出事就要自己把整个黑锅背着走。

我最后还是说句废话，MRD应该由产品经理以及公司战略决策部门（如UED啊市场啊啥总裁办啊之类的）共同产出；产品经理到底用不用写MRD是由中国国情以及公司实际情况决定的，能不能写MRD是由产品经理本身对市场的理解能力决定的，想不想写是由产品经理自身决定的（妈的，不想写的时候就不写！）

相关日志

• 2009/10/22 -- 关于本人 (1)

No related posts.