rule: write the MRD first

I can't count how many times in my career I've had to write a MRD for a product that has already gone to market. It's sad, actually.

Because when you find yourself asking fundamental questions like...

Who are we selling this product to?
How are we going to sell this product?
What is the competitive landscape we're selling into?
What are the sizes of our buyer segments?

...and you don't have a single place you can go to get the answers, you realize, lovely, time to write the MRD. Again.

The MRD - or Market Requirements Document - may be a dirty word to the Extreme Programming crowd, but that doesn't mean it is any less valuable. Maybe what they object to is the common (and unfortunate) practice of writing one then sinking it in Lucite for everyone to worship.

IMO, the MRD is a living document, since what it describes is your understanding of a market problem and what it takes to solve that problem in a compelling, unique way.

Maybe what they object to is the equally unfortunate habit of combining the market perspective found in the MRD with the feature/function perspective described in other documents. They're right. These two things shouldn't mix.

Why? Because the MRD is just one of three key documents you should be writing in partnerhsip with your product management counterparts:

1. The MRD (Market Requirements Document) describes the problem, who is having the problem, who else is trying to solve the problem, and what your unique, compelling solution to the problem is. Think sizing, dollars and risks.
2. The PRD (Product Requirements Document) describes the universe of features required to address the problem described in the MRD.
3. The RDD (Release Definition Document) describes those features in the PRD that you're going to carve off and attack in the context of a given public release.

One thing (among many) I learned from Steve Johnson over at Pragmatic Marketing is that all the key stakeholders need to sign off on each of these. And when I say "sign off", I mean literally "get their signature". If the release changes mid-flight, get agreement on that too.

So back to my premise. When you find yourself swimming without a MRD, you have no guiding principles with which to fashion all the other goodies you've being asked to create, like segment-specific positioning, customer metrics, ROI calculators, sales training and enablement tools. . . you know, all the good stuff that product marketing needs to drive. And without the MRD, how can your market intelligence people tell you if you're winning or losing? They can't, because you have no benchmarks to use to measure your progress other than revenue and costs.

So write the MRD first. It's not as much fun as doing a prototype, or slapping up a webpage, or meeting with potential customers, or even chatting up investors. But you need it to frame your thinking and structure your work.

Sigh.