The Market Requirements Document (MRD) describes a business case for developing a new product and the requirements for that new product that would satisfy the business case.

It’s typically written by product managers. It’s presented to management for their approval and to engineering for project planning.

An effective MRD launches new a product development effort in the direction of competitive advantage, growth, and profitability.

However, if you want all the good that can come from a well-developed MRD, you need to make sure that you don’t fall victim to these five MRD myths.

Myth 1: MRD’s Can’t Change

You have to have sympathy for the new product development side of the house. The last thing they want is for the goal posts to keep moving.

Unfortunately, that desire is unrealistic.

Markets and competitors will move in ways that were not anticipated when the original MRD was conceived. This is especially true given that new capital equipment development projects often take more than a year to complete.

These changes must be accounted for in the development program, or you run the risk of bringing the wrong product to market.

Instead of resisting changes in the MRD, insist that MRD’s are re-validated at key milestones during product development. That way if the environment has changed, you can adjust before it’s too late.

Myth 2: Engineering Only Needs the Spec’s

Engineering often feels that all that mumbo jumbo in the MRD’s front matter isn’t relevant to the work that they must do. Only the specs are needed.

Au contraire mon ami.

That front matter (a.k.a. the business case) contains the target customer description, competitors’ capability, the vision for value and competitive advantage, and rationale for timing and cost targets.

During product development, engineering will be faced with daily trade-off decisions. The business case in the MRD provides them with the context for navigating those decisions.

Myth 3:  MRD’s Don’t Require Management Approval

This is perhaps the most common myth. Most equipment companies have a formal process for approving product development plans.  What’s troubling is that the same cannot be said for MRD approval.

The product plan contains all the detail for schedule, budget, targets specifications and the like.  It answers the management question, “Can we do it?”

But there’s a question that comes before that.  It’s “Should we do it?” It’s the MRD that contains the answer.

The management team that gives little weight to MRD approval is a management team that may make the product right, but runs a high risk that they’ll make the wrong product.

Myth 4: The MRD and Product Plan Must Match

The back and forth goes something like this. Marketing completes the MRD and reviews it with engineering. Engineering responds with a product development plan. It’s inevitable that the plan shows specifications and timing that don’t perfectly line up with those in the MRD. But it’s a reasonable plan that substantially satisfies the business case and is approved.

Then comes the order to update the MRD to match the product plan. This is folly.

The “M” in MRD stands for “Market.’  Much to our chagrin, the market doesn’t change to match the capability of the supplier. If you change the MRD to match the product plan, you no longer have an MRD. You just have another copy of the product plan.

It’s OK if the product plan deviates from the MRD, as long as everyone agrees that it represents worthy commercial endeavor.

Caution marketing managers – when you sign off on the product plan, you’re agreeing that it is an acceptable plan of record. It’s foul play to point back to the MRD when the program runs into trouble and say “But that’s what I really wanted.”

Myth 5: Engineering’s Signature on the MRD Means They Agree

Wrong. Engineering’s agreement and commitment to execute are embodied in the product plan, not the MRD.

Their signature on the MRD means they understand the product requirements well enough to respond to them. It doesn’t mean that they can meet them.

Don’t let this myth stall an MRD’s approval.