简介
MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。
在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD(产品需求文档)来定义更加详细的产品需求。
在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。
写好MRD的10种技巧(第一部分)
1、从用户角度的编写
从用户角度编写需求内容。使用“用例(Use Case)”和“用户角色(User Personas)”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA(sales force automation)软件的“Login”的功能性。
方法A：
用户通过一个要求用户提供证书的登陆界面，然后软件允许用户带着特定的权限进入系统。软件鉴别这些证书，在鉴定通过的基础上允许用户访问那些他们有权限访问软件的功能部件。
方法B：
Mike是一个销售经理，Cathy是一个销售代表。当他们打开软件，他们看到登陆界面。他们通过用户名和密码进入系统。如果用户名和密码是正确的，他们能登进系统。一旦登陆进系统，Mike能访问软件所有的功能部件。Cathy只能访问那些对销售代表有有效的功能部件。
哪个方法更加容易阅读和理解?就我的看法,毫无疑问，”方法B”。还有，它同时减少了令人烦恼的阅读!
2、使用Screen Shots
使用Screen Shots或者mockup来你的想法。我们中很多人都听说过“一张图片好比一千个文字”。当提到写MRD的时候，一个screen shot好比一千个文字!
举个例子,看看下面这个screen shot，你需要多少字来描述?我想可能不只一千个字。
3、用简单的语言编写
在我超过11年的行业中，我通常注意到的(更多是令我懊恼)一件事是用很做作的语言来写的MRD。我想这个主要是因为MRD听起来是正式的和专业的原因吧。
相反，想象你写的MRD是写给你的在工程师团队工作的朋友。你的目标是帮助他理解你需要什么，以便于他能开发产品实现这些需要。这个将有助于你避开陷入那些令读者人厌烦(有时他们会把MRD撕碎然后再碎片喂给碎纸机)的用做作的语言的陷阱。
还有：
a)保持简短的语句，把长的语句分解成多个小的语句。
b)避免大篇幅的连续文本，把他们分解成多个小的章节。
c)把大块文本内容分解成，screen shots，表格、重点列表等等。
4、小心的使用模板
我发现MRD模板非常有用。他们的几个好处包括：
a) 模板提供了一个标准的格式，使那些不得不阅读大量MRD的读者更加容易阅读。
b) 模板让新的产品经理快速的写MRD变得容易，因为公司与公司之间的MRD内容是不同的。
c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分;
然而，一些公司过分的使用模板。一个硅谷最大的公司之一有一个所有部分被强制使用的近60页的模板。我觉得这个让人觉得非常难以忍受并且有几个负面的作用：
a) 产品经理害怕但又不得不写MRD - 几乎和不得不和Dick Cheney去南德克萨斯打猎一样(译者按：美国副总统Dick Cheney在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴)。
c) 写MRD和读MRD都需要花大量的时间。
我推荐你使用MRD模板，但确保他们不要过分的长。还有如果需要，确信产品经理可以灵活的跳过模板某些部分和创建新的内容。
5、区分需求的优先级
在这些年里，我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素!
这就是说作为MRD作者的产品经理，当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。
区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1，P2，P3…这样工作的刚刚好。在这个分类中-P1是最高优先级，P2是第二高优先级等等。
最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中，最好是和其他多种因素一起综合决定。
我推荐你只要包括P1，P2，P3的需求在你的MRD中，在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。
译者: Tigerkin 来源：译言网 原文

简介
MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。
在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD(产品需求文档)来定义更加详细的产品需求。
在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。
在我前面名为“写好MRD的10种技巧-第一部分”Blog文章中，我描述了写好MRD的5种技巧。我知道你一定迫切的想看到其他5种技巧，不用再等了，下面我就描述它们!
在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。如果你还没有阅读前面的5个技巧，请先阅读它们，我会等在这里，好了，你准备好了吗?
以下是写好MRD的10种技巧-第二部分(6-10)
6、说明”是什么”和”为什么”，但不要”如何”
产品经理为理解客户的需求负责，然后基于这些理解定义什么和为什么需要开发.
有一件比任何事情让开发者发疯就像在几英里外都能听到的汽笛在他们耳边尖叫一样的是一个令人痛苦的详细描述了怎样实现每一个需求细节的MRD。
考虑你们公司正在开发的以下两种描述CRM“Login”功能的方法。
推荐-描述“是什么”
Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面…登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框，我们的软件将记住并且在他下次来到登陆界面时自动填写他的名字。
不推荐-描述“怎么样”
Mike是一个销售经理，当他打开我们的CRM软件，他会看到一个登陆界面…登陆界面建议提供“记住我”复选框。如果Mike在点击登陆按钮之前选择了该复选框-将通过Javascript 保存他的名字以cookie的方式写到他的硬盘。当cookie写到硬盘后，用户名和密码将被发送到服务器。下一次Mike来到登陆界面时，Javascript 将读取他的cookie，成功读取后，Javascript 将是适当的DOM命令填充登陆页面上的用户名。好的产品经理擅长理解用户的需求和描述什么需要实现，好的工程师擅长决定怎么样实现它。好的工程师希望能自由的决定怎么样最好的实现用户希望得到的东西。
我注意到有技术背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你，应该从现在开始不要再做这样的事了。工程师们将会感谢你。
附：这里有一些例外的情况-当在描述“是什么”中描述“怎么样”是必要的，当描述“是什么”的最好的方式和/或唯一的方式就是描述“怎么样”的情况。
7、覆盖非功能性需求
尽管功能性需求描述产品的功能，非功能性需求描述系统特性，如：
a)性能
b)可伸缩性
c)可用性
d)国际化
e)等等…
我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”，而在MRD中被忽略。我发现这些是我的MRD中非常重要的一部分，工程师们会非常感激在MRD中定义这些需求。
要点：当写非功能性需求的时候，尽可能的是使他们可度量(可测试)。否则，QA不能测试它们，你将没有办法知道完成的产品是否已经实现了这些非功能性需求。
8、评审&修正
我有一个朋友-我们叫他Matt(他的真名叫Steve)。Matt在硅谷一家成功的公司做产品经理工作。最近我在午餐的时候碰到他是告诉我一个非常有趣的故事。
他们雇用了一个有三年经验的产品经理。在他被雇用的几个月里，不知何故他让他的产品经理同事和工程师一样疏远他。
他是罪犯?他基本上认为他的MRD就像一个法令。他写了它，但不想和任何人评审或在反馈的基础上修改它。他仅仅想工程师团队没有问任何问题的拿着它并实现它们!
不要像Matt的同事那样。确信做到和你的产品经理伙伴和工程师团队评审你的MRD。保持一个敞开的思想然后在评审反馈的基础上更新MRD。这将帮助你写出更好的MRD，工程师将喜欢你(或者至少少恨你一些)，你的团队也将创造更好的产品。
9、定义市场目标和定位
大部分我看到过MRD在覆盖了市场目标(谁将买和使用户你的产品)和定位(与竞争对手的产品比你的产品定位怎么样的)的方面做的很好。
我还看到过一些没有描述市场目标和定位的MRD，他们通常会这样争辩：“为什么工程师们需要知道这些?拿到定义了什么是需要的还不够吗?”
这些问题(谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的)的确有一些正面价值，我发现许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。
这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的(在MRD中)包含这些信息。- 它们不一定要很详细，只要包含几个段落就足够了。
10、包含一个术语表
如果你的MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一个术语表。
当你像这样说“我们的软件将提供SME用户通过选择WAP或PSMS开MRC帐单”时，术语表将确保你的所有读者(有些可能不是技术人员)理解你的意思是什么。
来源：译言网 译者: Tigerkin 原文

来源：译言网 作者：sam 原文 ：原文
在我以前的工作中，曾经设计过产品经理职位的核心能力模型，今天看到Michael的文章，和我思路非常相像，翻译整理出来和大家共享。
1、沟通能力
优秀的产品经理一定是个成功的沟通者， 沟通能力包括口头沟通能力和文字沟通能力。产品经理的一个最主要角色是做为沟通的中心，如下图所示：
产品经理的沟通能力不仅体现在和不同工作岗位的人进行有效沟通，同时还体现在如下方面：
和不同个性的人沟通。例如，大部分工程师的性格偏内向，而大部分销售和市场人员则很外向
和不同工作岗位的人沟通时采用不同的”语言” 。如果要进行高效沟通，很重要的一点是说沟通对象关注和易于理解的”语言”。比如，在和市场人员沟通和与工程师沟通时，要采用不同的沟通方式：对于市场人员说太多诸如”数据库性能”、”内存管理算法”之类的东西，无疑会让他们郁闷不解;而对工程师谈话过于概念化，也无助于他们设计真正的实现细节;类似的，在同老板们沟通时，则应该更多聚焦在较高的层面上，避免过于深入细枝末节的事情。
2、无授权领导能力
成功的产品经理是优秀的领导者，即便是没有明确的授权。
产品经理通常需要在多个领域执行领导工作，包括领导项目团队、领导产品战略和蓝图指定，以及领导跨团队的产品活动等。但是在大多数情况下，产品经理通常没有得到公司正式的授权。此时，是否具有”无授权领导能力”就成为成功与否的关键。
如何在无授权的情况下领导团队，我的建议是–综合运用影响力、协商、人际关系及其他类似技能。
3、学习能力
IT产业是一个快速变化的产业，”不变的也许只有变化”，新技术不断涌现，今日的新产品在几个月后就会变成大路货，甚至更快。优秀的产品经理必须能够快速学习，即便是在比较新的领域。具备此能力才能相对容易地在不断变化的市场和技术趋势下管理好产品。.很多公司在招聘产品经理的时候会犯一个错误–他们过分看中既有经验。比如，一个公司要做安全软件，他们就回在招聘时说明”需具有安全软件领域5年以上工作经验”。这其实是个错误的方法，更好的做法是寻找在软件领域有工作经验的产品经理，同时善于快速学习。
4、商业敏感度
优秀的产品经理对商业有极好的感觉，他们清楚如何发现市场机会，了解竞争差异化的重要性，并能提出制胜的产品战略、定价、推广策略、合作计划以及盈亏分析等。
看到这些，别以为产品经理就该是MBA毕业。实际上，大多数优秀的产品经理并没有上过什么MBA，但是他们对商业有很强的敏感。
5、热爱产品
优秀的产品经理对产品有发自内心的热爱。他们孜孜不倦地尝试各种新产品，注册各种产品的测试版，下载产品的试用版并仔细揣摩，一有时间就去网上看各类新产品的网站。他们对设计优秀的产品喜爱有加，即便这些产品并非自己公司的;他们鄙视那些没品的产品，即便那是自己公司开发的。最重要的是，他们醉心于创造优秀的产品–无论是全新的产品或是既有产品的改进。
6、注重细节，追求完美
优秀的产品经理对细节孜孜以求，注重细节是开发优秀产品的最重要先决条件，正所谓”细节决定成败”。Steve Jobs曾说：
iMac笔记本并非只是透明颜色和外壳外形与众不同，这个产品的核心理念在于成为最精致的消费电脑。
在最新的iMac中，我们坚决去掉了散热扇，因为我们认为使用一台不嗡嗡作响的电脑工作更令人愉悦。当然，并不是我决定就可以取消散热扇，它需要工程师们付出巨大的努力，找到管理电源和散热的更好办法。这是产品设计之初就存在的核心理念。
这也是用户愿意选择我们产品的原因–追求每个细节的完美，从而能让用户更方便愉悦地使用他们的电脑。
优秀的产品经理不但注重产品设计的细节，在其他事情上一样追求完美，比如进行竞争状况分析、制作项目计划，以及所有其他自己负责的工作。
7、日常产品管理能力
优秀的产品经理具备良好的日常产品管理能力，包括：
撰写市场需求文档(MRD)和产品需求文档(PRD)
进行竞争状况分析
规划产品路线图
制作产品演示PPT
设计用户界面
分析产品数据等.
以上这些核心能力不但有助于产品经理的自我提升，同时对于招聘产品经理也有参考价值。
如果你对产品经理的职责有补充，欢迎给我来信，也可在评论中发表高见。

来源：译言网 译者: sam 原文
做为一名新进产品经理，甚至一名资深PM，你可能都或多或少对这个职位产生某种迷惑。到底什么是产品经理?这个职位的主要职责是什么?在IT产业的不同领域，甚至在同一领域的不同公司，这个职位的定义似乎都有不同。
本文尝试根据自己多年的产品经理经验，给出产品经理的主要职责。 虽然在不同的公司，产品经理的角色和职责互有差异，但是有一些关键职责是任何一个产品经理都应承担的。可以将其归纳为如下六个方面：
1、市场调研
市场调研是指研究市场以了解客户需求、竞争状况及市场力量(market forces)，其最终目标是发现创新或改进产品的潜在机会。
可以通过下面的方式进行市场调研：
与用户和潜在用户交流
与直接面对客户的一线同事如销售、客服、技术支持等交流
研究市场分析报告及文章
试用竞争产品
仔细观察用户行为等
市场调研最终会形成商业机会、产品战略或商业需求文档(BRD)，详述如何利用潜在的机会。
2、产品定义及设计
a) 产品定义是指确定产品需要做哪些事情。通常采用产品需求文档(PRD)来进行描述，PRD可能包含如下信息：
产品的愿景
目标市场
竞争分析
产品功能的详细描述
产品功能的优先级
产品用例(UseCase)
系统需求
性能需求
销售及支持需求等
b) 产品设计是指确定产品的外观，包括用户界面设计(UI，User Interface)和用户交互设计(User Interaction)，包含所有的用户体验部分。在大型公司里，PM通常和UI设计师或互动设计师一起完成产品设计，不过在小公司或者创业公司里，产品经理也许需要全包这些工作。
这是产品经理工作中最有价值的部分， 如果产品经理工作中不包含这部分内容，那几乎可以肯定滴说，那不是产品经理的工作。
3、项目管理
项目管理是指带领来自不同团队的人员(包括工程师、QA、UI设计师、市场、销售、客服等)，在预算内按时开发并发布产品。其中可能包括如下工作内容：
确保资源投入
制定项目计划
根据计划跟踪项目进展
辨别关键路径
必要时争取追加投入
向主管领导报告项目进展状况等
在大型公司里，通常会有项目经理来处理大部分项目管理工作，产品经理只需提供支持。不过在创业公司里，产品经理通常需要自己进行项目管理。在有些公司，技术负责人也可能做为项目经理，处理大部分项目管理事宜。
4、产品宣介
主要包括和内部同事如老板、销售、市场、客服等沟通产品的优点、功能和目标市场，也可能包括向外界如媒体、行业分析师及用户宣介产品。
大公司的产品经理通常都有产品市场、市场推广和媒体关系(PR)团队帮忙进行对外的产品宣介。
这是除了产品定义和设计之外，对产品经理而言价值第二高的工作，尤其是在向老板、市场同事宣介产品并让他们感到兴奋的时候。
5、产品市场
主要是对外的信息传播——告诉外界有关产品的信息。通常包括制作产品数据表、手册、网站、Flash演示、媒体专题以及展会演示等。
在大型公司，产品市场工作通常不会由PM来负责，这些公司会有专门的产品市场经理来打理此项工作。当然，这种分工最大的缺点就是导致沟通效率较低，并会削弱对外传播。
在某些公司，“产品管理”和“产品市场”被认为是同义词，会由一个人担当两者的职责。而在那些将产品管理团队和产品市场团队分开的公司，后者会打理本节所提及的工作职责，同时他们也可能会承担“市场调研”、“产品宣介”和“产品生命周期”管理的部分工作。
6、产品生命周期管理
指那些随着产品经历概念化->发布->成熟->退出市场整个生命周期中的产品管理活动。
主要包括的工作有：
产品定位
产品定价及促销
产品线管理
竞争策略
建立或收购合作伙伴
识别并建立合作关系等
产品经理和产品市场、BD及市场沟通同事一起完成这些工作。
希望这篇文章有助于你了解产品经理(包括产品市场经理)，以及他们在公司中密切合作的部门，并祝你成长为一名优秀的产品经理。