Thinking of writing an MRD? Stop!!

I have been writing Market Requirement Documents and teaching people how to write MRDs for close to 20 years. But I am happy to say, that I think I have finally found a better way!

I have worked hard to perfect writing MRDs over the past couple decades and still feel strongly that MRDs are a good practice for the following reasons:

  • They allow you to completely think out the product and strategy in advance

  • They make sure you do your homework before the programming starts

  • They give everyone involved a concept of the scope of the product you are working on

For all these reasons, I don't completely want to do away with the MRD. I still believe that an MRD must be written for each product/release. However, I would like to suggest that you consider how the MRD will be written and implemented. The problems with the MRD (at least in high-tech) are the following:

  • The market moves so quickly that the priorities of today are not always the priorities of tomorrow.

  • You are trying to cram so much information into one document, it takes forever to produce and then it is outdated almost as soon as it is done.

  • I don't like the idea of Marketing throwing a document over the wall to engineering, I have always thought that it needs to be a much more interactive process.

For all of these reasons, we have adopted a different way of doing MRDs at my current company. We still use my template, but section five (required/desired characteristics) is just a very short summary and section six (estimated development costs) does not exist. Yes, those are typically the most important parts of the MRD.

You maybe asking yourself why bother with an MRD at all if the meat isn't there? Using this method, the MRD simply becomes a framework that other smaller documents fit into. At my current company, we have borrowed the concept from "Extreme Programming" of "stories". Instead of listing out all new features and functions in the MRD we create small separate documents with large sections of functionality broken into smaller, well-defined tasks. We create these with the programmer involved and we create them as we move through the development of the product. The following are the steps involved:

  1. The MRD is created to define the direction of the release or product. It has a general summary (very short) of all features that we would like included.

  2. The highest priority feature is broken down into small bite-size tasks. Each task becomes a "story" that is written up with both the product manager and the developer involved.  The developer provides a time estimate for the implementation of the story.

  3. Once a story is agreed upon, it is distributed to the team. The developer starts to work on it and the QA department figures out how they will test it. The product manager moves on to the next highest priority story with the next developer.

  4. Ideally, the product manager gets a customer involve with the feature design with the developer.

  5. When the developer completes the work of the first story, work starts on the second story.

  6. We chose a release date and the stories that are completed by that date go into the release (with lots of negotiation depending upon current customer requirements.)

This process has the following advantages:

  • The product manager sets the priorities while the release is in progress, providing built-in flexibility without jerking developers around.

  • The product manager becomes more closely involved in the initial design so that there are fewer surprises later on.

  • QA gets involved earlier and gets more information on what is going to come at them, and when, in the release.

  • Developers are involved in the process from the beginning so there is a much better understand of what is needed.

  • Customers can also be easily involved in the process - reviewing the stories to make sure that the product meets their needs before it is produced.

  • Progress can be measured immediately and time estimates verified for their accuracy.

  • The product manager's time is better used by defining stories throughout the entire development cycle rather then dedicating themselves to a single MRD (that will be outdated as soon as it is written) for several weeks upfront.

  • Individual customers are involved in developing features that they feel most strongly about.

So what are the disadvantages to this MRD method?

  • It is a very different mindset.

  • It takes a lot of coordination on the part of the product manager to keep all the stories moving forward.

  • It also takes a bit of administration to make sure all the stories are well documented and properly distributed.

  • It does not supply a single document for potential investors to review (only a potential problem for a pre-revenue company

  • Additionally, and most important of all, it takes buy-in from both the engineering management and the marketing management to work in this way. Without the full support of both teams, this just isn't going to work.

If you are not convinced and need to write a plain old MRD, see my write-up, How to Write an MRD

After a year of using this methodology, I am more convinced than ever that this is a better way to do MRDs. Especially when you can get customers involved.

Copyright ©2018 Barbara Tallent