MRD Writing Tips – Ten from Michael Shrivathsan

Michael wrote five (and another five) tips on writing a market requirements document (MRD). Michael has written a good set of tips with detailed explanations and anecdotes. We’ll extend the conversation here…

Michael’s list:

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

We have re-organized these tips into three general areas of guidance and provide our thoughts.

1. Good communication (tips: 1,2,3,4,10)
2. Good requirements (tips: 5,6,7,9)
3. Good requirements management (tips: 8)

Good communication

The purpose of the document is to communicate. Writing for our audience is essential to communication. Using templates to create a predictable structure and flow makes the content easier to absorb. Using clear, unambiguous language (no contrived terms or jargon), makes the ideas easier to grasp and remember. Providing a glossary of terms to provide domain context for the readers is essential for many projects.

A software developer who is an expert at load-balancing a web server may not have any idea how to calculate incremental margin for sales beyond forecast. “Incremental margin” may seem like jargon, but it is a standard term (within the management accounting domain). Use that as your rule of thumb – is the term company-specific, or would anyone in the domain understand it. If the former, its jargon. The latter should have a glossary entry.

A picture is worth a thousand words, certainly. It isn’t clear that using screenshots or mockups is the best way to capture requirements in an MRD. Because they are so powerful, it is impossible to get the intent, without being influenced by the form. This is an area where a lot of smart people agree to disagree. We’ve written about the dangers of using screenshots or other implementation cues that can be interpreted as ‘how’. As Michael points out, often ‘how’ is the appropriate way to communicate with other members of the team – it depends on the team. Barbara Nelson, a product management instructor for Pragmatic Marketing, stresses that the product management role is strategic, and getting into details isn’t. It may be required, but if the product manager is doing it, who’s doing the strategic work?

On the flip side, Alan Cooper is promoting Interaction Design. In an interaction design process someone is responsible at a level analogous to an MRD for determining both what and how. This is basically an interpretation that the how is an element of the what, not just an implementation detail. Combining interaction design with classical structured requirements might look like this amalgam.

Good requirements

Prioritization is the most important element in the document (other than the ideas being prioritized). One goal of an MRD is to communicate the vision of the software. Understanding what and why, with the context of which is more important, is the mechanism of communication to the engineering team. This message provides the framework in which they operate.

MRDs are also the right focal point for driving much of the outbound communication. The vision in an MRD identifies which white papers should be created. The (market) positioning provides guidance to sales people in individual account positioning. (Sales) demos should highlight the most valuable capabilities of the product. Roadmaps and the multi-release schedule are driven by prioritization. Schedules may be managed in timeboxes and delivered in use-case-sized chunks, but the driving prioritization is in the MRD.

Good requirements management

MRDs are not carved in stone and aren’t found in a cave high in the desert. They are not an end, they are a means. A means to communicate a vision. One thing that the Agile proponents clearly have right is that change happens. The market is a moving target. A vision for dominating that market better move with it. And the resulting MRD is going to change.

Product Managers are also not infallible. Left to our own devices, we will write some horrible requirements. We require feedback from the implementation teams in order to write great requirements. A great example is documenting what Kano would define as a “more is better” requirement.

The optimal point is not the revenue-maximizing feature, it is the profit-maximizing feature. We’re driven by ROI. We need an understanding of the cost function to combine with the price function to result in a profit function. We must solicit and respond to that feedback from our engineers.

This is the level of execution expertise that can differentiate our teams, and our products.

Summary

An MRD is critical to capturing product strategy information. Capturing the right information is critical. The goals of capturing that information are to disseminate the ideas, and for the team to collaborate on them. Techniques that make it easier for our target audience to read the MRD are important. And having a good approach to managing the document as it evolves is what can set us apart from other teams, or make us more competitive.