12a. Marketing Requirements Document

Intro We are almost out of the problem space and into the solution space. I know . . . it’s taking a long time. Stay calm.

Next, we are going to talk about the Marketing Requirements Document (MRD). This is the  fancy title for a document that basically just tries to answer the question, “What should we build?”

We’ll talk about what it is, who writes it, when, why, and how. Basically, the 5 W’s of journalism except for ‘where.’ The MRD can be written anywhere, so I’m not going to talk about that.

Talking ‘Bout Synthesis

Consider all of the voice of the customer activities we talked about in earlier Chapters:

• Customer needs in general
• Design thinking (empathy, observation)
• Jobs to be Done
• Outcomes

All of these topics explore how to understand the customer, his or her needs, and the specifics of the problem space.

If you truly do all of those activities, you’re going to be sitting on a lot of information.

You, after researching the customer and his or her needs

In order to proceed in the product development process — moving along onto concept generation and prototyping — it’s helpful to organize this information into a more clear picture of what kind of solution to build.

By organize, I mean “process.” And by process, I mean “synthesize.”

Synthesis — the act of making sense of disorder.

The MRD is all about synthesizing the information you’ve gathered about the problem space in order to communicate WHAT to build.

12b. What is the MRD

The MRD. Yes, it is a three-letter acronym. Yes, it sounds like the TPS report.

It does not sound very fun. It sounds like a pain in the ass.

That doesn’t change the fact that it’s important.

What It Is

I’ve already alluded to this; the MRD is the document that describes, in general, what to build to solve the customer’s problem.

“The big question is, ‘For who are we building this product, and why?’” Steven Haines The Product Manager’s Desk Reference

MRD = Communicates WHAT to build

I highlight the word “what” there because that is the key term. More on that soon.

What Not How

The MRD should talk about what the problem space looks like and what a solution might look like. It does not describe HOW to solve the customer’s problem.

That is a big distinction, and so nuanced that I’m going to spend some more time talking about it.

If you’ve noticed, we haven’t spent a lot of time talking about concept generation thus far in the preceding Product Development Distillery chapters. The only thing we’ve really discussed in depth so far are customer needs.

But just because we haven’t yet explored/brainstormed/ideated/conceived of an exact product idea yet, doesn’t mean we don’t know WHAT to build. It just means we don’t know how to build it.

Confused? Here’s an example:

MRD Abbreviated Example:

Going back to the Milkshake analogy, consider this MRD based on that research. Disclaimer . . .this example is not a complete MRD, just a distilled flavor of one. 

Milkshake MRD

• Elevator pitch: Our customer is a commuter on the way to work. She is seeking a nutritious, sustainable, fun, entertaining experience that is convenient and inexpensive. Our solution will differentiate itself from competitors with its unique combination of positive associations and convenient value.
• Persona: Typical customer is a 35-year-old Marketing Manager driving her Toyota Prius to work at 7:28 a.m.
• Journey: Customer wakes up and gets her kids ready for school; customer uses drive-thru; customer drinks milkshake while driving to work; etc., etc., etc.

• Jobs to be done:
• Hiring a milkshake to feel full until around 10:00 a.m.
• Hiring a milkshake to provide some entertainment or activity during an otherwise boring commute
• Alternative hires: bagels, coffee, donuts
• Outcomes
• Key under-served outcome: customer feels positive about themselves (i.e., “I’m a healthy and good person”). Consuming a product does not incur guilt or negativity.
• Minimize the amount of time spent acquiring product (convenience)
• Increase feelings of social positivity associated with the purchase
• Increase interaction time with the product

• Constraints
• Must cost less than $4.99
• Must have
• Milkshake container must fit in a normal car cup holder
• Would like to have
• An app for ordering ahead
• Mustn’t have
• Plastic straw #gogreen

End of Example MRD

See that we don’t really know how to build a solution exactly yet? That’s OK. The MRD is not meant to explain HOW . . . just WHAT.

12c. Key Elements of the MRD

Now that you’ve seen an example let’s go through what belongs in the MRD.

Disclaimer — this is a distilled list. MRDs should fit the needs of the team; there is no one-size-fits-all MRD.

Problem Statement

The problem statement explains what the problem space looks like. Here’s what a leading consulting group lists as good content for the Problem Statement (or scenario)

280 Group

Personas

A persona captures the target consumer. A good persona has sufficient detail to paint the picture for the development team. It looks like a real human being — not just a random collection of demographic data.

From Ben Einstein, The Illustrated Guide to Product Development

Customer Journey

How does the customer go about interacting with the solution you are going to build? What are the motivations at each phase of the journey, what is the customer trying to accomplish, and what needs to happen in order for the customer to move from one step to the next?

Show the journey in pictures. Make a high-level diagram. Visuals are often better than words here.

Vendasta

Prioritize Requirements

Don’t be fooled by the name “Marketing REQUIREMENTS Document.” Not everything is a requirement. Some things are suggestions.

I like the framework below:

Notice that last one: “Mustn’t.” You probably don’t use that word a lot in real life, but in the MRD, it can be very powerful and effective. If something must not be a part of the solution/product, state that.

Other Key Things You Might Want to Put In The MRD

Pricing — What’s it gotta cost?

Elevator Pitch — A very short summary detailing your product offering and its value proposition.

Core Benefit Proposition (CBP) — Basically, the value proposition, the CBP states the benefits to the consumer; should be a clear and brief statement, highlighting unique and differentiating qualities.

Competitive Advantage — How the product stacks up against competitors, and where it has advantages.

“Unlike Our Competitors” — A useful way to begin a sentence describing the product, since it forces you to clarify the brand’s or product’s differentiating properties.

Product Objectives — be it objective performance (fuel economy) or subjective (taste better); good MRDs provide clear product objectives.

Jobs to be Done — include this as its own section of the MRD, or better yet, write the entire MRD using the framework that you’re describing a job to be done.

Cost Model — estimates of what the product can cost; a full-blown “model” means there is some algorithm set up and you can plug in values for various parameters and the model computes final cost; essentially you just need the “right” amount of cost guidance in an MRD — don’t over-do-it or under-do-it.

Business Case — The justification for undertaking a project or product, typically made using financial analysis (expected cost, benefit, profit, etc.).

Perceptual Maps — A graphic that displays information about the product; for example, a 2-D plot with “Easy to use” on one axis and “Powerful” on the other, and products plotted in comparison to each other.

12d. Y, Tho? Why Write an MRD?

Writing an MRD is critical to support the learning that will take place during prototyping, to keep the team organized and oriented in the same direction, and to make clear what the heck it is you’re trying to build.

Tell People What to Build

Unless you’re building a product alone in your garage, there will be multiple people involved with the product development process.

And the people who actually build products are not always the same people who did the Market Research.

Using our Milkshake example, that dude who stood out there talking to people who bought milkshakes — Mike — he’s not writing the code for the new app that orders milkshakes (that’s right, we’re going to build an app). That app is being coded by Karen. Karen needs to know what Mike knows.

“The product requirements are the bridge between the activities of product planning and the actual building or production of a sellable product.” — The Product Manager’s Desk Reference

A Statement of Record

The scientific method — something that has been pretty useful over the history of mankind — begins with a hypothesis. Tests are then conducted, and the results are compared to the hypothesis. If everything agrees, the hypothesis is good; if not, the hypothesis changes.

Prototyping is a very similar process. Prototyping is about learning and testing theories. The MRD is, in a sense, the first hypothesis about your product.

Prototypes of the product will be created and tested, and in doing so, new insights about the customer and market will be generated. The MRD will change to reflect this learning, much like the hypothesis in the scientific method.

So, basically, the MRD is a document used to capture assumptions and learning. It is a statement of record.

You Gotta Keep ‘em Oriented

MRDs keep everyone on the same page — not only people who build products but other people who are interested in the project (i.e., your boss).

The more people involved in development and the further they might be disconnected from the people who really understand the problem space, the more important it is to get them properly oriented.

Connects Needs/Jobs to Be Done and Specs/Metrics

Customer needs can get lost in the process of prototyping and refining a product. Developers can start to get super focused on features and specs.

It is critical not to lose sight of the fact that features should deliver benefits, and that means that you should connect features to customer needs. The MRD can always be referenced to understand, “what is the key need here?”

12e. MRD Wrap Up and Best Practices

Here are some nuggets of advice for writing an MRD.

Write the MRD as a Cross-functional Team

The contents of the product spec will affect a wide range of people. It’s a mistake to think that it should be written by anyone team.

While there is likely a single group of people (or person) who best understands the problem space (i.e., the team responsible for the Voice-of-Customer research), that doesn’t mean that they should write the document and “throw it over the wall” to the people who build products.

Throwing the MRD “over the wall” to the development team is a recipe for confusion and really, really big arguments.

Make it a Living Document

Another nugget of wisdom you’ll hear is that the MRD (or really any document written in a product development process) is not written in stone. The MRD is changeable and subject to new learning.

Don’t let anyone just change shit at any time they feel like it — but the key concept here is that specs should not become sacred just because they’re written down.

Focus on Benefits, Not Features

This hearkens back to the earlier section on “What, not How.” People often confuse features with benefits. Features and Benefits are absolutely not the same things. A benefit can be delivered via many different features.

Feature: Phone can be opened using a passcode

Benefit: Phone can only be opened by authorized people

Note that the feature leaves little room for innovation. The benefit could be solved in any number of ways, thus leaving room for the development team to get creative.

The MRD should only specify features if those exact features are required. Otherwise, just stick to the benefits.

The Right Amount of Planning

A lot of people advocate for simplicity in the first draft of the MRD. Don’t make the MRD 50 pages of single-space writing if it doesn’t have to be.

The amount of planning should be in alignment with the situation. More planning is needed if development costs are high, and markets move slowly (satellites). Less planning is needed if prototyping is cheap and fast, and things are going to change rapidly (some software).

The MRD serves a function: it helps the team get moving on the concept creation phase, prototyping, and continuing to learn about product-market fit. Don’t lose sight of that.

In Summary

There you have it. The MRD is written to capture WHAT to build, which is a critical step in your product development process, and it’s most useful to start it — remember, it’s a living document, you can edit it later — after all of your Voice-of-the-Customer research.

Source

Resources

Here’s one last nugget. A lot of Product Management books talk about the Marketing Requirements Document because it’s generally the Product Manager (i.e., Marketing) team who writes that document. A lot of technical Product Development books talk about the Product Spec or Product Requirements Document. The PRD and MRD are not the same. I’ll cover more on this later, but try to identify what you’re reading when doing further research. The MRD is about “what to build,” and the PRD is about “specifications” and more technical detail.

Marty Cagen’s Inspired. This book is really focused on digital products, and when discussing the Product Spec, he places a big emphasis on building out a prototype rather than making a big document people won’t read.

The Other Side of Innovation — Vijay Govindarajan. This book has some great content about executing within an innovation project, so it touches on recording hypotheses and assumptions and running scientific method type studies.