From MRD to PRD: The key to defining a spec

By Scott Sehlhorst | January 24th, 2006
brought to you courtesy of Tyler Blain


They key to writing a great spec is knowing how to specify software that mets our customers’ needs.

It can be a daunting task. First, we have to define what our customer needs. High level requirements are just requirements that are too vague or high-level to be directly actionable. “We must reduce our cost of fullfilling orders by 20%” is a high level requirement. We can’t start writing code with only that information. In an early post, we talked about functional requirements being written at the right level – don’t confuse the level of clarity required for writing a functional spec with that required to define goals.

A market requirements document (MRD), as we discussed earlier, discusses the problems (to be solved) or the needs of the market. When working with a customer, that customer will identify one or more strategic objectives.

As an aside – this case study demonstrates use of the OST (objectives, strategy and tactics) approach to initiating and managing projects. Check it out for context. You can just skim the bold parts in the OST sections if you want to stay on topic with this post.



The question is – How do we get from an MRD to a great PRD?

A product requirements document (PRD) captures the capabilities of the software in order to address the market needs. From these key capabilities comes the design of the software. How do we get from needs to ideas?

This is an ideation task. A product manager must apply high level design skills when writing the specification. Haven’t we said repeatedly that requirements should not describe the implementation or design? Yes. Previously, we talked about the importance of asking why, this is the same issue, approached in the other direction – starting with the why and askinghow.

We’re not talking about specifying implementation details – just articulating capabilities. Here is a list of “market need : product capability” that demonstrate the transition from MRD to PRD.

1. Customers are cancelling 5% of their orders because of shipping delays : Software will enable shipping within 24 hours of order
2. Our competitor is gaining market share by offering free plugins : Software will support a plug-in architecture
3. 80% of potential customers (visitors) leave our website without ordering : Navigation must be simple on the website
4. Our software keeps crashing and we don’t know why : Software will send error information from client to server

One of the things that makes this requirements design activity so difficult is that we have to have good ideas about how to solve the problems we are tasked with solving. Look at example number three – there are many different ways to attempt to solve the problem – the challenge is in picking the right one. Requirements elicitation will unearth the required capabilities.

Organizing, validating, and prioritizing these capabilities is the hard part. The output of this effort is a PRD. A product roadmap (a vision of what a product will be capable of doing, over time) is another potential output.