产品经理需要写MRD吗?

摘要:什么是MRD?我会不会太废话了些?还是先简要说一下什么是MRD吧 Market-Requirements-Document,简称市场需求文档。市场需求文档的主要功能是描述什么样的功能和特点的产品(包含产品版本)可以在市场上取得成功。产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现商业目的,功能/非功能需求分哪几块,功能 ...

什么是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是由产品经理本身对市场的理解能力决定的,想不想写是由产品经理自身决定的(妈的,不想写的时候就不写!)

源地址:http://www.phoenixlaw.nam……/2009/11/121/



无觅评论,优化体验,加强品牌价值

无觅相关文章插件,快速提升流量