Market Requirements Document – Anatomy of a Strong MRD Template

A market requirements document (MRD) is used to define high-level market requirements for a product. It’s usually written by the product manager or product marketing manager and typically includes the product’s high-level market requirements.

Product Requirements Document Template

The MRD is primarily used by the product manager and senior executives to outline the product that’s going to be built and the problems it’s trying to solve. Other users of the MRD include business analysts, marketing and sales. The engineers define user and technical requirements based on the MRD and the release’s goal. They may also use the MRD to create a product requirements document (PRD), depending on the organization. The engineers can then use the PRD to develop the product. Some organizations combine the MRD and PRD into a single document, according to Actuation Consulting. Product managers use the MRD to identify problems that people will pay to have solved and prioritize those problems based on the needs of the user personas.

High-Level Requirements

The increasing consumer expectations in the modern business environment are making frequent communication between manufacturers and customers a more critical aspect of product development. Fritz Morgan, vice president of engineering for Color Kinetics, says, “We generate a market requirements document with initial forecasting information that we use for the first build.” This forecast of features is essential for prioritizing software requirements, especially the first release. Product managers may use categories like “must have,” “surprise and delight,” and “more is better” to prioritize requirements. It’s particularly important to ensure that all “must have” requirements are included in the first release. Must have requirements are based on what the market has identified as must have, not what the product manager has identified.

The MRD should make use of simplifying assumptions to facilitate the communication of ideas to its readers, allowing each reader to determine the MRD’s applicability to his or her unique situation. For example, the MRD for a software application often uses personas that encompass multiple users. A software engineering team typically address this layer of complexity by scheduling use cases across multiple releases of the software, since these cases must be enabled for different user classes. Market problems should drive this schedule to ensure that developers focus on the problems that people will pay to solve.

A development team that uses an iterative development methodology such as agile can easily accommodate changes in the must have requirements as the project progresses. A release is based on a combination of budget, features and time, although no release ever meets all three of these requirements. As a result, the development team may need to re-class features as the release date approaches. The MRD can be changed to accommodate these changes.

The release schedule for SaaS software is dictated by the market. This schedule may be shortened if a prospective client needs a problem solved immediately and is willing to pay for it. However, the product manager can’t really assign a timeframe to this process. SoberIT advises that business objectives may necessitate trade-offs between features and time-to-market.

Persona Definitions

The definition of personas and their associated problems provide the market requirements in the MRD. The product manager should write these requirements in the persona’s business language, rather than provide a technical definition. The description of each requirement should be brief, usually no more than a paragraph or two and never more than two pages. The key to this brevity is to avoid suggesting any solution for a problem to the software engineering team. A requirement for a new product should state a persona’s business problem, whereas a requirement for an existing product could also state a usage problem. The product manager will then combine these individual requirements into a cohesive whole when adding them to the MRD.

A persona’s problem should clearly express a situation that the product should be able to address. Product managers are increasingly more likely to use personas as the primary method of defining complex problems and less likely to use the traditional requirements-and-specifications approach. The use of personas allows the development team to focus on the end result rather than implementing each individual feature. This strategy is more attractive to expert software development teams because it involves more analysis and design at the beginning of the project.

Pragmatic Marketing advocates the use of personas for both the buyers and users of the product. These two groups are usually different people in the case of software, since software buyers have different requirements than software users. Buyer personas are primarily concerned with the software’s business value, while the user persona is more concerned with its capabilities. Each persona includes a biography that provides the context needed to guide the development team. For example, a user persona that’s adept at creating spreadsheets indicates that the development team should focus on the software’s export capabilities rather than its ability to generate reports.

Major Feature Sets

The MRD also includes a description of the software’s major feature sets, which is especially useful for framing decisions on large products. The product manager should prioritize these features according to their expected frequency of use, especially when the development team is using a lean development methodology such as agile. Solving market problems is the key to driving value in software, so the product manager should consider adding a feature if it will increase revenue. The development of the MRD’s feature sets begins with an analysis of market requirements document, especially what problems the software will solve.

The MRD shouldn’t be a static document, so the product manager will continue to refine the marketing plan over time. A complete view of the product is needed to minimize the possibility of repeating the product development process due to the omission of a required feature. As Abraham Lincoln is purported to have said, “If I had eight hours to cut down a tree, I’d spend six hours sharpening the axe.”

The next phase in the development of feature sets is engineering validation, which is intended to align the product strategy with the customer’s expectations. This phase involves ensuring that the developers can actually deliver the desired feature sets on schedule, on budget and with the required quality. The product manager also needs to incorporate any new information on current market conditions before committing the project to full development.

The purpose of the design verification phase is to ensure that the development team can create a shippable product. This phase includes verifying the product specifications, including those of the interface. It also includes ensuring the software meets the relevant regulatory requirements for that industry, especially healthcare and financial software.

3Pillar Global brings out the best in agile with our Adaptive Product Lifecycle Management which makes breakthrough product ideas a reality. Contact us to learn more.