Earlier this week I got a friendly email from a reader. She asked me whether I could write an article comparing the different requirements document formats used in the software industry. You know - BRD, MRD, PRD, FSD, PSD, SRS, IRS, etc.

I'm frequently asked many variations of this question - so I'll try and explain all of these briefly in this article. Well, all except that last one!

Alphabet Soup
If you're like me, you grew up with a variety of alphabet snacks - alphabet cereals, alphabet biscuits, alphabet soup, and many other snacks shaped like alphabets. I guess most of us must have really liked them - or were really tormented by them! I don't know which one for sure - but the net effect is they seem to have had a deep influence on most of us.

Now we're all grown up and rarely eat those alphabet snacks any more - but in nearly every profession, the industry jargon is an alphabet soup overrun by TLA's (three letter acronyms). FBW (for better or worse)!

Product management and product marketing is no different - especially when it comes to requirements documents. We have BRD, MRD and PRD; we also have FSD, PSD and SRS; and many different variations of these.

As if that is not enough, all organizations do not use these terms in the same way. What one organization calls MRD, another may call PRD. Sometimes I can't help but LOL (laugh out loud) when I see yet another new TLA. That said, let us try and get our hands around these.

Useless Trivia Question: Using only the uppercase alphabets in English, how many different TLA's can you create?

P.S. If you got this far and don't know what TLA stands for, shame on you! Please reread from the start, will ya?

All The News That's Fit to Print - About Requirements Document Acronyms
Let us take a quick look at the most common acronyms used while referring to requirements documents:

1. BRD
2. MRD
3. PRD
4. FSD
5. PSD
6. SRS

1. BRD - Business Requirements Document

   A Business Requirements Document (BRD) focuses on defining the business needs of a project. The BRD identifies one or more business problems faced by customers that can be solved by the company's product. It then proposes a solution - usually a new product or enhancement to an existing product to address these problems.

   It may also include a high-level business case -- such as revenue forecast, market & competitive analysis, and sales/marketing strategy.

   It is usually written by someone with the title of Product Manager, Product Marketing Manager or Business Analyst. In small companies, it may be written by senior execs or even founders.
   
   It is usually a Word document running 1-3 pages, or a PowerPoint document running no more than 10 slides.

   ---

   Example:
   Let us assume your company is developing a customer relationship management (CRM) software.
   
   The BRD may focus on problems faced by sales managers in keeping track of all ongoing deals and being able to create reliable forecasts. It may identify:

   • Who have the pains
     • Sales Managers at Fortune-500 companies
   • What the pains are
     • No real-time visibility into deal status
     • Inability to create reliable forecasts
   • Proposed solution
     • Create web-based software to track deals and create forecasts

2. MRD - Market Requirements Document

   A Market Requirements Document (MRD) focuses on defining the market requirements for a proposed new product or enhancement to an existing product.

   Whereas the BRD identifies business problems and solutions to those problems - the MRD delves deeper into the details of the proposed solution. It may include some or all of these details:

   1. Features required to solve the business problems
   2. Market and competitive analysis
   3. Functional and non-functional requirements
   4. Prioritization of features/requirements
   5. Use cases

   It is usually written by someone with the title of Product Manager, Product Marketing Manager or Business Analyst.
   
   It is usually a Word document running 5-25 pages, or even longer in some organizations as described later.

   ---

   Example:
   Let us continue with the above example of a company developing a customer relationship management (CRM) software.
   
   The MRD may focus on identifying and prioritizing requirements, as well as describing use cases. Requirements include functional and non-functional requirements such as:

   • Functional Requirements
     • Must work in Internet Explorer (version 6.0 and above) and Firefox (versions 1.5 and above)
     • Must use SSL to ensure security
     • ...
     • User should be able to enter data through browser interface for: customers, companies, contacts, opportunities, deal size, etc.
   • Non-Functional Requirements
     • Must be able to support up to 100,000 simultaneous users
     • Must have uptime of greater than 99.9%
     • ...
     • Need comprehensive user guide in English, German and Japanese

   Please check out this article on writing MRDs for further details.

   ---

   Alert: Some organizations combine MRD and PRD as described here into one document, and call the resulting document MRD. In this case, the MRD will include what is described in this section as well as what is described in the PRD section below - and may run more than 50 pages.

Like This Article? Why not share it with friends and colleagues? Just click here...



3. PRD - Product Requirements Document

   A Product Requirements Document (PRD) focuses on defining the product requirements for a proposed new product or enhancement to an existing product.

   Whereas the MRD focuses on requirements from the perspective of market needs, PRD focuses on requirements from the perspective of the product itself. It usually delves into more details on features and functional requirements, and may also include screen shots and user interface flows.
   
   In organizations where the MRD doesn't include detailed requirements and use cases, the PRD covers those details.

   It is usually written by someone with the title of Product Manager, Business Analyst or Product Analyst.
   
   It is usually a Word document running 20-50 pages, or even longer for complex products.

   ---

   Example:
   Let us continue with the above example of a company developing a customer relationship management (CRM) software.
   
   The PRD may focus on detailed requirements such as:

   • Login screen should include username and password fields. It should also include a 'Forgot Password' link.
   • 'Contacts' screen should include fields for first name, last name, phone, email,...
   • ...
   • 'Forecast' screen should have a 5-step wizard that walks user through the steps required to create annual forecasts. Each step should be as described below...

   The PRD may also include detailed use cases.

   ---

   Alert: Some organizations combine PRD and MRD as described here into one document, and call the resulting document PRD. In this case, the PRD will include what is described in this section as well as what is described in the MRD section above.

4. FSD - Functional Specifications Document

A Functional Specifications Document (FSD) defines the complete details of a product's functional requirements with a focus on implementation. FSD may define the product specifications screen by screen and feature by feature. This is a document that can be directly used by engineers to create the product.

Whereas the MRD and PRD focus on requirements from the perspective of market needs and product, FSD focuses on defining the product details in a form that can be implemented by engineers. FSD may also include complete screen shots and UI design details.

It is usually written by someone with the title of Product Analyst, Engineering Lead, or Program Manager - the author(s) usually belong to the engineering department.

It is usually a Word or similar document running several dozen pages.

5. PSD - Product Specifications Document

   Product Specifications Document (PSD) is a less popular acronym, but in organizations that have such a document, it is by and large the same as the Functional Specifications Document (FSD) described above.

6. SRS - Software Requirements Specification

   A Software Requirements Specification (SRS) is another less popular acronym. In organizations that create an SRS, it has contents and details somewhere close to what is described above for PRD or FSD.

Okay, there you have it - 6 requirement document acronyms deconstructed and explained. Just want to alert you again - all organizations do not use these terms in the same way. Think of these documents as points on a spectrum. Each organization defines which documents to create and where in the spectrum those documents fall - depending on what best fits their unique needs.

Useless Trivia Answer: Using only the uppercase alphabets in English, the total number of TLA's (three letter acronyms) you can create equals:

26³ = 17,576.

You know what this means, right? Be mentally prepared to learn another 17,570 TLA's related to requirements documents.

Alrighty then - our tour through the wonderful land of requirements document acronyms is over. As Tigger would say, TFN (ta-ta for now)!

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 05:30 PM | Permalink | TrackBacks (0) | 3 Comments | Post Comment

I was going to write an article titled "The Soul of a Product" this week emphasizing the importance of design. But then, my plans changed as I went to an event organized by the Silicon Valley Product Management Association this past week.

In that event, Michael Sippey, the VP of Products at Six Apart (a blogging software company whose product 'Movable Type' powers my blog) gave an excellent speech on product management.

The best way I can think of to summarize his speech is: "Get everybody in the van, and do a DILO"! Actually I can think of better ways - but this is a pretty catchy way (I think!) to get you to read further so you can understand what the heck that means.

It is well worth it, so let us get going.

Getting Everybody in the Van
Michael's speech was focused on how things have changed dramatically from the beginning of his career at companies that made packaged software, to now - where he is managing a hosted software product (TypePad).

Michael talked about how much many of the product practices have changed - such as 24-month release cycle vs 2-week release cycle, extensive specification documents vs lightweight specifications using wikis, building a product vs iterating a service, etc. He said the one thing that hasn't changed at all is "Getting everybody in the van". What did he mean by that?

When he started his career in a successful financial software company, one of the key lessons he learned was the importance of understanding customer needs. The way that company did this is by visiting customers at their offices and observing them work. They would get the product manager, engineering manager, and other relevant personnel into a van and drive to the customer sites.

Once there, they would watch them work and ask them questions to understand what needs they have - which ones are being met by their products and which ones are not. This practice enabled them to constantly enhance their products to keep their market lead, as well as create successful new products by unearthing unmet needs.

When they had a new idea, Michael said (I'm paraphrasing):

When we had a new idea, we had to call and set up meetings with 30 prospects. If you don't get 30 prospects to agree to a meeting about a product idea, you don't have much of a product idea.

Well said Michael! All high-tech companies would be well advised to practice this.

I've seen many high-tech companies, both startups and large companies, first create a product because a VP or founder thought it was cool ("I want to do something that uses AJAX"), and then start looking for a problem it happens to solve! Then many of their competitors copy it and pretty soon all of them have got a product looking for a problem.

What is a DILO?
Now to the bonus part of this article, where you will be learning a cool new thing called DILO. What is it, you ask?

Well, it is a totally cool sounding FLA (which itself stands for 'Four Letter Acronym'!) guaranteed to impress your friends! And if you happen to be in consulting, it is guaranteed to pull in 2X hourly rates. I'm so confident about this that I'll refund 100% of your subscription fee to my free blog if you don't get this result, okay?!

DILO = Day In the Life Of

It refers to understanding the "Day in the life of" a customer. The best way to do this is to "get everybody in the van" - and observe customers using your product in context, and asking them questions.

Get the Van Started
Now that you know what "Getting everybody in the van" means, start implementing this into your own product practices. Those of you in product management and product marketing should especially spearhead this. Check out this earlier article for some concrete steps you can take, and get the ball rolling.

As Thomas Huxley, the 19th century British biologist wrote:

The great end of life is not knowledge but action.

Here is to better products, happy customers and more success...

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 02:42 PM | Permalink | TrackBacks (0) | 7 Comments | Post Comment

In my previous blog entry titled 10 Tips for Writing Better MRDs - Part 1 - I covered five tips for writing better MRDs. I know you've been waiting with bated breath for the next five tips. Wait no more, I've covered them below!

Here, I use "MRD" to collectively refer to all documents created by product management and/or product marketing teams for the purpose of conveying product requirements to engineering team.

If you haven't read the first five tips yet, please read them first. I will wait here. Okay, you are ready?

Here are tips 6 through 10.

6. Specify What & Why - But Not How

   Product managers are responsible for understanding customer needs, and using this understanding to define what should be developed and why.
   
   The one thing, more than anything else, that causes developers to get mad with steam flowing out of their ears so fast that the accompanying whistle can be heard miles way - is an MRD that specifies *HOW* to implement each and every requirement in excruciating detail.
   
   Consider the following two approaches for specifying "Login" functionality for a customer relationship management (CRM) software that your company is developing.
   
   

   ---

   
   Recommended - Specifying *What*:
   Mike is a sales manager. When he opens our CRM software, he sees the login screen. (...) The login screen also provides a "Remember me" checkbox. If Mike checks this checkbox before clicking the 'Login' button - our software will remember and auto-fill his username the next time he comes to the login screen.
   
   Not Recommended - Specifying *How*:
   Mike is a sales manager. When he opens our CRM software, he sees the login screen. (...) The login screen also provides a "Remember me" checkbox. If Mike checks this checkbox before clicking the 'Login' button - a cookie will be written to his PC hard-drive using Javascript to save his username. Username/password will be sent to server only after this cookie is written to the PC hard-drive. The next time Mike comes to the login screen, Javascript will be used to read his cookie. After successfully reading it, Javascript will use the appropriate DOM command to prefill the username in the login screen.
   
   

   ---

   
   Just as good product managers are experts at understanding customer needs and specifying what needs to be done, good engineers are experts at deciding how to achieve it. Good engineers want the freedom to decide the best how to achieve the desired what.
   
   I've noticed that product managers with technical background are especially guilty of specifying how. If this describes you - just say no to it from now on. Engineers will thank you.
   
   P.S. There are some rare exceptions to this rule - instances where it is necessary to specify how along with what, as the best and/or the only specification of what in these instances is the how.

7. Cover Non-Functional Requirements

   Whereas "Functional" requirements specify the features of the product, "Non-Functional" requirements specify system characteristics such as:
   
   a) Performance
   b) Scalability
   c) Availability
   d) Internationalization
   e) etc...
   
   I've noticed that these are often omitted from MRDs as many product managers and product marketers consider these "technical details". I've found these to be very important part of my MRDs and engineers have really appreciated these requirements being defined in MRDs.
   
   Important: When writing non-functional requirements, make them easily measurable (testable) whenever possible. Otherwise, QA cannot test it and you will have no way of knowing whether the finished product meets these specifications or not.

   

8. Review & Update

   I have a friend - we will call him Matt (his real name is Steve). Matt works as a product manager at a successful company in the valley. He had an interesting story to tell when I met him for lunch recently.
   
   They had hired a new product manager with about three years experience. Within a few months of being hired, he had somehow managed to alienate many of his fellow product managers as well as engineers.
   
   His crime? He basically considered his MRDs to be sort of like decrees. He wrote them, but did not want to review with anyone or modify it based on feedback. He just wanted the engineering team to take it and implement it without asking any questions!
   
   Don't be like Matt's coworker. Make sure to review your MRD with your fellow product managers and the development team. Keep an open mind and update the MRD based on the feedback in these reviews. This will help you create better MRDs, engineers will like you more (or at least hate you a lot less!), and your team will create better products.

9. Define Target Market & Positioning

Most MRDs I've seen do a pretty good job of covering the Target Market (who will buy and use your product) and Positioning (how your product will be positioned versus competing products).

I have seen some MRDs that don't and the argument that I usually hear in these cases is along the lines of: "Why do engineers need to know this? Isn't defining what needs to be done enough?"

While that question certainly has some face value, I've found that many engineers want to know why a certain product or feature is being developed, who will be using it and what are their alternatives.

This information helps them and other members of the product team visualize the end users and as a result do a better job of creating winning products. My suggestion is to include this information whenever possible - it doesn't have to be very detailed, just a couple of paragraphs will suffice.

Like This Article?

Why not share it with friends and colleagues? Just click here...

10. Include a Glossary

    If your MRD uses new terms or common terms in an uncommon way - make sure to include a Glossary at the end.
    
    This will help ensure all of your readers (some of whom may not be technical) understand what you mean when you say things like "Our software will provide SME users the option to be billed a MRC via WAP or PSMS".

There you have it - tips 6-10 of my ten tips for writing better MRDs. I've shown the entire list below for easy reference as well:

1. Write From User's Perspective
2. Use Screen Shots
3. Write Using Simple Language
4. Use Templates - But With Care
5. Prioritize Requirements
6. Specify What & Why - But Not How
7. Cover Non-Functional Requirements
8. Review & Update
9. Define Target Market & Positioning
10. Include a Glossary

Here is to better MRDs, better products, and more success...

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 08:31 PM | Permalink | TrackBacks (0) | 6 Comments | Post Comment

An MRD – "Market Requirements Document", is a document written by Product Managers or Product Marketing Managers to specify the requirements that a product must meet. This document is used to propose a new product or to revise an existing product. It is used by the engineering team to develop the product.

At some software companies in Silicon Valley, MRD only covers high-level features. In such cases, product managers create another document - usually referred to as PRD (Product Requirements Document) to define more detailed product requirements.

In this article, I use the term "MRD" to collectively refer to all such documents created by product management and/or product marketing teams for the purpose of conveying product requirements to engineering team.

Ten Tips for Writing Better MRDs (Part 1)

1. Write From User's Perspective

   Write requirements from the perspective of users. Make use of 'Use Cases' and 'User Personas' to achieve this. Consider the following two approaches for specifying "Login" functionality for a sales force automation (SFA) software that your company is developing.
   
   

   ---

   
   Approach "A":
   Software shall allow users with privileges to log into the system through a login screen which shall ask the user to provide credentials to login. Software shall authenticate these credentials and upon authentication shall permit the users to access sections of the software that they have access privileges for.
   
   Approach "B":
   Mike is a sales manager and Cathy is a sales rep. When they open the software, they see the login screen. They enter username and password in this screen. If the username/password is correct, they are able to log in. Once logged in, Mike can access all sections of the software. Cathy can only access those sections of the software available for sales reps.
   
   

   ---

   
   Which approach is easier to read and understand? In my opinion, without any doubt, "Approach B". Plus, it is also much less boring to read!

2. Use Screen Shots

   Use screen shots or mockups to explain what you mean. Most of us have heard the saying "A picture is worth a thousand words". When it comes to writing MRDs, a screen shot is worth a thousand words!
   
   For example, look at the following screen shot - how many words do you need to describe this? I'd guess probably more than a thousand.

   

3. Write Using Simple Language

   One thing I've noticed often (much to my chagrin!) during my 11+ years in the industry are MRDs that use a very contrived language. I think this is primarily caused by the misconception that MRDs need to sound formal and professional.
   
   Instead, imagine that you're writing the MRD for your friend who works in the engineering team. Your goal is to help him understand what you need so that he can develop the product to meet those needs. This will help you avoid falling into the trap of contrived language that turns off the readers - sometimes to the point where they shred your MRD and feed the shreds through the shredder again!
   
   Plus:
   a) Keep sentences short. Break up long sentences into smaller ones.
   b) Avoid large blocks of text. Break them into smaller paragraphs.
   c) Break up large bodies of text with screen shots, tables, bulleted lists, etc.

4. Use Templates - But With Care



I've found MRD Templates to be very useful. They offer several benefits including:

a) Templates provide a standard format that makes it easier for readers who have to read multiple MRDs.
b) Templates make it is easier to bring new product managers up to speed in writing MRDs - as MRD contents vary from company to company.
c) Templates help ensure you don't forget to cover all aspects that need to be covered in MRDs.

However, some companies go way overboard in using templates. One of the largest companies in Silicon Valley has a template that runs about 60 pages and in which all sections are mandatory. I've heard that it feels very oppressive and has several negative effects:

a) Product managers dread having to write MRDs - almost as much as having to go on a south Texas quail hunting trip with Dick Cheney!
b) Engineering teams dread having to read MRDs.
c) It takes a long time to write as well as read the MRDs.

I recommend you to use MRD templates, but make sure they're not overly long. Plus make sure that the product managers have the leeway to skip sections that are not applicable and to create new ones if needed.

Like This Article?

Why not share it with friends and colleagues? Just click here...

5. Prioritize Requirements

   In all these years, I've never worked on a full-scale project where the engineering team was able to implement all the features that were included in an MRD - often due to factors beyond the control of any of us!
   
   This means product managers, as MRD authors, should provide a way to help the engineering team decide which features to implement and which to defer when the need arises to make this determination.
   
   This is best achieved by prioritizing the requirements. I've found that classifying requirements into categories like P1, P2, P3... works just fine. In this categorization - P1 is the highest priority, P2 is the next highest and so on.
   
   The best way to decide the priority of a given requirement is the benefit of implementing that requirement - both to your customers and your company. In practice, other factors come into play as well.
   
   I recommend that you only include P1, P2 and P3 requirements in your MRDs, as lower priorities are unlikely to get done in most projects anyway. Plus it makes the MRD easier to read.

There you have it - the first five of my ten tips for writing better MRDs. I'll cover the rest of the tips in my next article. Until then...

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 09:35 PM | Permalink | TrackBacks (0) | 5 Comments | Post Comment

A common question that comes up in discussions is what qualifies as a Requirement and what qualifies as a Feature.

I've always thought of a Feature as something that would go as a bullet point in a product datasheet or brochure. A Feature is a capability that provides an end user the ability to achieve a business goal.

A Feature then is usually made up of a set of Requirements.

EXAMPLE
A Feature of Amazon.com is "One-Click Purchase".

Some of the associated Requirements may be:

• Software shall check to see whether the user has enabled 'One-Click Purchase' in his preferences
• Software shall retrieve all items stored in the cart
• Software shall process order using default credit card and shipping address stored in the account
• etc...

A Feature thus consists of a set of Requirements that need to be implemented to provide the user the ability to achieve a goal.

Posted by michael at 12:15 PM | Permalink | TrackBacks (0) | 2 Comments | Post Comment

I just read an interesting post by Jason at '37 signals' blog on Essential vs. Non-Essential requirements.

He discusses the process their team went through to prioritize requirements while developing their Campfire software that was released recently. In essence, it involves classifying requirements into Essential (must have) and Non-Essential (nice & cool).

This leads to the question of what is the best way to prioritize requirements? And is there a "best way" really? How exactly do you decide which requirements fall under the "Essential" bucket and which don't?

How is it done in most companies?
Product managers and Product marketing managers routinely go through this exercise of prioritization. For a high-value B2B software, any requirement demanded by a large customer gets Essential status while those that someone at the company came up with get Non-Essential status. In small startups, the requirements the founder(s) really want could end up getting the Essential status.

In other words, which requirements get the Essential status is often decided by the importance of the originator of that requirement! Is this the best way?

What is the best way?
In theory, capital should be allocated to maximize ROI (return on investment). ROI can be defined in many ways - but is usually defined in terms of a financial metric such as NPV (net present value).

If that is the case, requirements should be prioritized in terms of financial return they will generate. We can grossly oversimplify (for the purposes of this discussion) and say that requirements should be prioritized in terms of incremental revenue they can generate. I say "revenue" instead of "profit" (more accurately "free cash flow") since it is usually easier to estimate.

Your customers will pay the highest incremental price to those features that provide them the most incremental value in achieving their own goals.

Once we are able to estimate the incremental revenue generated and incremental customer value added by each requirement, we should be able to arrange them in a prioritized list. Sounds simple enough, right? Wrong!

Some challenges
The most common challenge is: How do you estimate the incremental revenue generated by each requirement?

This is usually done via some guesstimation work by the product/marketing manager. They usually use some third party reports (IDC, et al), data analysis of customers, and some guesswork. Sometimes customer feedback is solicited as well - but could be very cumbersome. Net, this is a very inexact science.

The next common challenge is: Strategic fit. What if a requirement can indeed generate high incremental revenue but does not align with "Corporate/Product Strategy"? This fit is usually decided by someone in the executive team and is the most common means through which execs contribute to prioritization.

Another common challenge is: Technical fit. What if a requirement can indeed generate high incremental revenue but does not fit with the technical expertise of the company? This fit is usually decided by an engineering/development manager. This is the most common means through which engineering management contributes to prioritization.

Final word?
When all is said and done, prioritization of requirements is an inexact, social activity. Lot of things need to be taken into account - in the case of larger companies, even some corporate politics!

Two factors: 1) ROI to company, and 2) Value added to customers should be the dominant factors - but other "soft" factors should be taken into account as well.

Posted by michael at 06:23 PM | Permalink | TrackBacks (0) | 7 Comments | Post Comment