Writing the Market Requirements Document

By Pragmatic Marketing
November 04, 2011

This document is written for product managers in technology companies who are chartered with writing product requirements and the Market Requirements Document (MRD).


Writing requirements is not a mysterious black art although it may sometimes seem that way. Requirements convey details of a customer's problem to the reader (usually a designer or developer). A requirement reveals the information necessary to create an innovative solution to the problem, perhaps in ways not anticipated by either the requirement's writer or the associated end-user. Understanding the market is the first step in creating innovative products. The collection of market requirements is the body of what’s often called a “Market Requirements Document.”

The Five Steps of Innovation

Successful organizations use five steps for developing innovative products:

  • Find a problem
  • Analyze it
  • Design an innovative solution
  • Code to the design
  • Test the result

Sadly, these steps are not always followed. Many product managers fail to communicate lucid requirements grounded in the market; too few developers analyze the problem and design an innovative solution. Yet successful technology organizations routinely and consistently follow all five steps.

Alan Cooper, in his book The Inmates are Running the Asylum, says most technical products aren’t designed for the user; they’re designed for the developer. Or worse, they’re not designed at all. Poorly designed products frustrate customers.

Whether using traditional methods or agile ones, we need to understand the problem before building a feature. You’ll need a design before you begin building. Agile methodologies aren’t just about coding; agile teams learn to move through the five steps of innovation quickly and efficiently, usually completing an entire development cycle in a few weeks.

In many organizations, the product management function is ill-defined. Ideally, a product manager finds problems in the marketplace and conveys them to a Development or Engineering organization. When product managers (sometimes called product owners) are also competent in development areas, they’re often recruited to assist in other areas of product development. Since many come from a technical background, they have a natural tendency to work on activities they enjoy and where they have skills, even though these activities are not product management responsibilities. As a result, product managers are often overwhelmed with tactical, technical activities that tie them to their desks; activities that prevent them from spending time in the market. For more on the role, see The Strategic Role of Product Management e-book.

A product manager owns the first step in creating innovative products: finding market problems. These are communicated to Development in the form of requirements—the problems to be solved. The remaining steps of innovation are owned by the Development or Engineering departments. A product architect or designer controls the middle steps (analysis and high-level design) with a team lead in charge of the detailed design, coding and testing. If there is no designer, then analysis and design falls to the Development team. Another critical role is QA. The quality assurance lead is responsible for both internal and external testing. That’s why QA should head up the alpha and beta testing projects. The QA lead validates that the specifications (written by Development) address the problems articulated in the requirements (written by product management) and then tests the result to ensure the requirement is met; this verification role is more effective than merely attempting to "break the code" in clever ways.

So the functions (and roles) are:

  • Find a problem (product manager)
  • Analyze it (product architect or designer)
  • Design a solution (product architect or designer)
  • Code (developer)
  • Test (QA lead)

Nowadays, we see personas and problems increasingly used as the primary method of defining complex projects, with an associated reduction in the old "reqs and specs" approach. An emphasis on personas and their problems focuses the team on the final result, rather than the tedious implementation of individual features. This approach requires more analysis and design by Development, making it more attractive to competent development organizations.

At Pragmatic Marketing, we have long been advocates of personas, both for the users of the product as well as for buyers. Buyers have one set of requirements; users have another. And for most technology products, the buyers and users are different people in the organization. A buyer persona is involved in the purchase of the product; a user persona actually uses the product. The buyer persona is concerned with value while a user persona is more concerned with capabilities. A persona defines an archetype of the buyer or user of your product with a biography that includes context to guide the team. For example, knowing a typical customer—a user persona—is adept at spreadsheets suggests we don’t need a report writer but can implement an export capability instead.

Personas have problems. Stated in the context of a specific persona, a problem represents a situation that our product should be able to address. Problems are specific situations that can be clearly expressed.

The persona definitions and the list of their problems are the basis of the Market Requirements Document (MRD). MRD articulates the new product or new release plan. Some companies call this document a Product Requirements Document (PRD). Some organizations have both an MRD and a PRD but then struggle to define which is which and what each should contain.

Let’s keep it simple:

A business plan defines the overall product opportunity with a financial plan; a requirements document defines the next version or model of a product with a list of problems to be solved.

Do we really need more documents than this?

Traditional Requirements

According to the IEEE definition, a requirement is a statement identifying a capability, physical characteristic, or quality factor that bounds a product or process problem for which a solution will be pursued.

Focus on the ending phrase: Requirements state a “problem for which a solution will be pursued.”

Traditional requirements are categorized into these five types:

  • Functional. Observable capabilities that must be present for the persona to complete their goals or perform the task specified by the use scenario
  • Performance. Characteristics of capacity, speed, concurrency
  • Constraints. Conditions that legitimately limit the design
  • Interface. Defined interaction with hardware and software components
  • Security. Compliance with government mandate and customer privacy
Page 1 / 2

About the Authors

  • Pragmatic Marketing

    Pragmatic Marketing, Inc. has continuously delivered thought leadership in technology product management and marketing since it was founded in 1993. Today, we provide training and present at industry events around the world, conduct the industry’s largest annual survey and produce respected publications that are read by more than 100,000 product management and marketing professionals. Our thought-leadership portfolio includes the Pragmatic Marketing Framework, eBooks, blogs, webinars, podcasts, newsletters, The Pragmatic Marketer magazine and the bestseller “Tuned In.”

    To learn more about our courses and join the growing international community of more than 85,000 product management and marketing professionals trained by Pragmatic Marketing, please click here.

Post a Comment


Allowed HTML: <b>, <i>, <u>