10 Tips for Writing Better MRDs - Part 1

An MRD – "Market Requirements Document", is a document written by Product Managers or Product Marketing Managers to specify the requirements that a product must meet. This document is used to propose a new product or to revise an existing product. It is used by the engineering team to develop the product.

At some software companies in Silicon Valley, MRD only covers high-level features. In such cases, product managers create another document - usually referred to as PRD (Product Requirements Document) to define more detailed product requirements.

In this article, I use the term "MRD" to collectively refer to all such documents created by product management and/or product marketing teams for the purpose of conveying product requirements to engineering team.

Ten Tips for Writing Better MRDs (Part 1)

1. Write From User's Perspective

   Write requirements from the perspective of users. Make use of 'Use Cases' and 'User Personas' to achieve this. Consider the following two approaches for specifying "Login" functionality for a sales force automation (SFA) software that your company is developing.
   
   

   ---

   
   Approach "A":
   Software shall allow users with privileges to log into the system through a login screen which shall ask the user to provide credentials to login. Software shall authenticate these credentials and upon authentication shall permit the users to access sections of the software that they have access privileges for.
   
   Approach "B":
   Mike is a sales manager and Cathy is a sales rep. When they open the software, they see the login screen. They enter username and password in this screen. If the username/password is correct, they are able to log in. Once logged in, Mike can access all sections of the software. Cathy can only access those sections of the software available for sales reps.
   
   

   ---

   
   Which approach is easier to read and understand? In my opinion, without any doubt, "Approach B". Plus, it is also much less boring to read!

2. Use Screen Shots

   Use screen shots or mockups to explain what you mean. Most of us have heard the saying "A picture is worth a thousand words". When it comes to writing MRDs, a screen shot is worth a thousand words!
   
   For example, look at the following screen shot - how many words do you need to describe this? I'd guess probably more than a thousand.

   

3. Write Using Simple Language

   One thing I've noticed often (much to my chagrin!) during my 11+ years in the industry are MRDs that use a very contrived language. I think this is primarily caused by the misconception that MRDs need to sound formal and professional.
   
   Instead, imagine that you're writing the MRD for your friend who works in the engineering team. Your goal is to help him understand what you need so that he can develop the product to meet those needs. This will help you avoid falling into the trap of contrived language that turns off the readers - sometimes to the point where they shred your MRD and feed the shreds through the shredder again!
   
   Plus:
   a) Keep sentences short. Break up long sentences into smaller ones.
   b) Avoid large blocks of text. Break them into smaller paragraphs.
   c) Break up large bodies of text with screen shots, tables, bulleted lists, etc.

4. Use Templates - But With Care

   

   I've found MRD Templates to be very useful. They offer several benefits including:
   
   a) Templates provide a standard format that makes it easier for readers who have to read multiple MRDs.
   b) Templates make it is easier to bring new product managers up to speed in writing MRDs - as MRD contents vary from company to company.
   c) Templates help ensure you don't forget to cover all aspects that need to be covered in MRDs.
   
   However, some companies go way overboard in using templates. One of the largest companies in Silicon Valley has a template that runs about 60 pages and in which all sections are mandatory. I've heard that it feels very oppressive and has several negative effects:
   
   a) Product managers dread having to write MRDs - almost as much as having to go on a south Texas quail hunting trip with Dick Cheney!
   b) Engineering teams dread having to read MRDs.
   c) It takes a long time to write as well as read the MRDs.
   
   I recommend you to use MRD templates, but make sure they're not overly long. Plus make sure that the product managers have the leeway to skip sections that are not applicable and to create new ones if needed.

   Like This Article?
   
   Why not share it with friends and colleagues? Just click here...

5. Prioritize Requirements

   In all these years, I've never worked on a full-scale project where the engineering team was able to implement all the features that were included in an MRD - often due to factors beyond the control of any of us!
   
   This means product managers, as MRD authors, should provide a way to help the engineering team decide which features to implement and which to defer when the need arises to make this determination.
   
   This is best achieved by prioritizing the requirements. I've found that classifying requirements into categories like P1, P2, P3... works just fine. In this categorization - P1 is the highest priority, P2 is the next highest and so on.
   
   The best way to decide the priority of a given requirement is the benefit of implementing that requirement - both to your customers and your company. In practice, other factors come into play as well.
   
   I recommend that you only include P1, P2 and P3 requirements in your MRDs, as lower priorities are unlikely to get done in most projects anyway. Plus it makes the MRD easier to read.

写好MRD的10种技巧-第一部分

        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在南德克萨斯打猎时意外的打伤了和自己一起去的打猎伙伴）。
        b) 工程师团队害怕但又不得不阅读MRD。
        c) 写MRD和读MRD都需要花大量的时间。

        我推荐你使用MRD模板，但确保他们不要过分的长。还有如果需要，确信产品经理可以灵活的跳过模板某些部分和创建新的内容。

5、区分需求的优先级

        在这些年里，我从来没有碰到一个工程师团队实现了MRD里包括的所有特性的没有删减的项目-通常由于那些我们控制之外因素！

        这就是说作为MRD作者的产品经理，当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。

        区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1，P2，P3...这样工作的刚刚好。在这个分类中-P1是最高优先级，P2是第二高优先级等等。

        最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括你的客户和你的公司。在实际实践中，最好是和其他多种因素一起综合决定。

        我推荐你只要包括P1，P2，P3的需求在你的MRD中，在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。