10 Tips for Writing Better MRDs - Part 2

In my previous blog entry titled 10 Tips for Writing Better MRDs - Part 1 - I covered five tips for writing better MRDs. I know you've been waiting with bated breath for the next five tips. Wait no more, I've covered them below! 

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

If you haven't read the first five tips yet, please read them first. I will wait here. Okay, you are ready?

Here are tips 6 through 10.

6. Specify What & Why - But Not How

   Product managers are responsible for understanding customer needs, and using this understanding to define what should be developed and why.
   
   The one thing, more than anything else, that causes developers to get mad with steam flowing out of their ears so fast that the accompanying whistle can be heard miles way - is an MRD that specifies *HOW* to implement each and every requirement in excruciating detail.
   
   Consider the following two approaches for specifying "Login" functionality for a customer relationship management (CRM) software that your company is developing. 
   
   

   ---

   
   Recommended - Specifying *What*:
   Mike is a sales manager. When he opens our CRM software, he sees the login screen. (...) The login screen also provides a "Remember me" checkbox. If Mike checks this checkbox before clicking the 'Login' button - our software will remember and auto-fill his username the next time he comes to the login screen.
   
   Not Recommended - Specifying *How*:
   Mike is a sales manager. When he opens our CRM software, he sees the login screen. (...) The login screen also provides a "Remember me" checkbox. If Mike checks this checkbox before clicking the 'Login' button - a cookie will be written to his PC hard-drive using Javascript to save his username. Username/password will be sent to server only after this cookie is written to the PC hard-drive. The next time Mike comes to the login screen, Javascript will be used to read his cookie. After successfully reading it, Javascript will use the appropriate DOM command to prefill the username in the login screen.
   
   

   ---

   
   Just as good product managers are experts at understanding customer needs and specifying whatneeds to be done, good engineers are experts at deciding how to achieve it. Good engineers want the freedom to decide the best how to achieve the desired what.
   
   I've noticed that product managers with technical background are especially guilty of specifyinghow. If this describes you - just say no to it from now on. Engineers will thank you.
   
   P.S. There are some rare exceptions to this rule - instances where it is necessary to specify howalong with what, as the best and/or the only specification of what in these instances is the how.

7. Cover Non-Functional Requirements

   Whereas "Functional" requirements specify the features of the product, "Non-Functional" requirements specify system characteristics such as:
   
   a) Performance
   b) Scalability
   c) Availability
   d) Internationalization
   e) etc...
   
   I've noticed that these are often omitted from MRDs as many product managers and product marketers consider these "technical details". I've found these to be very important part of my MRDs and engineers have really appreciated these requirements being defined in MRDs.
   
   Important: When writing non-functional requirements, make them easily measurable (testable) whenever possible. Otherwise, QA cannot test it and you will have no way of knowing whether the finished product meets these specifications or not.

   

8. Review & Update

   I have a friend - we will call him Matt (his real name is Steve). Matt works as a product manager at a successful company in the valley. He had an interesting story to tell when I met him for lunch recently. 
   
   They had hired a new product manager with about three years experience. Within a few months of being hired, he had somehow managed to alienate many of his fellow product managers as well as engineers.
   
   His crime? He basically considered his MRDs to be sort of like decrees. He wrote them, but did not want to review with anyone or modify it based on feedback. He just wanted the engineering team to take it and implement it without asking any questions! 
   
   Don't be like Matt's coworker. Make sure to review your MRD with your fellow product managers and the development team. Keep an open mind and update the MRD based on the feedback in these reviews. This will help you create better MRDs, engineers will like you more (or at least hate you a lot less!), and your team will create better products.

9. Define Target Market & Positioning

Most MRDs I've seen do a pretty good job of covering the Target Market (who will buy and use your product) and Positioning (how your product will be positioned versus competing products). 

I have seen some MRDs that don't and the argument that I usually hear in these cases is along the lines of: "Why do engineers need to know this? Isn't defining what needs to be done enough?"

While that question certainly has some face value, I've found that many engineers want to know why a certain product or feature is being developed, who will be using it and what are their alternatives.

This information helps them and other members of the product team visualize the end users and as a result do a better job of creating winning products. My suggestion is to include this information whenever possible - it doesn't have to be very detailed, just a couple of paragraphs will suffice.

Like This Article? 

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

10. Include a Glossary

    If your MRD uses new terms or common terms in an uncommon way - make sure to include a Glossary at the end.
    
    This will help ensure all of your readers (some of whom may not be technical) understand what you mean when you say things like "Our software will provide SME users the option to be billed a MRC via WAP or PSMS".

There you have it - tips 6-10 of my ten tips for writing better MRDs. I've shown the entire list below for easy reference as well:

1. Write From User's Perspective
2. Use Screen Shots
3. Write Using Simple Language
4. Use Templates - But With Care
5. Prioritize Requirements
6. Specify What & Why - But Not How
7. Cover Non-Functional Requirements
8. Review & Update
9. Define Target Market & Positioning
10. Include a Glossary

Here is to better MRDs, better products, and more success...

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

About the Author: I'm your author, Michael Shrivathsan, an expert in product management and product marketing with successful experience spanning two decades. I live in Silicon Valley, USA. For my day job, I manage the product management group at an exciting software startup.