PRD (Product Requirement Document)

July 13, 2007 – 6:45 pm

Sometimes equated with Project Requirement Document

The PRD and Me

If you are in the web / internet industry, then you have more than likely heard this acronym float past your ears a dozen times or more. It is one of the most important documents a project/product can have. At first, it was like pulling teeth to get me to write one of these “things”. I remember the first one reminded me of those papers I used to crank out at the last minute in college, but as time wore on and I became more involved in all web processes and the PRD became my safeguard, my shield, my savior.

Now that I have written over twenty product requirement documents (some small, some large), I can give some good guidelines for the concept, format and content. Marinade on these items below and you’ll make everyone happy including yourself. Finger lickin’ good!

My PRD Definition

A PRD is a document that outlines all the requirements that should be met for building a product. The PRD is created when the MRD (Marketing Document) has been finalized and delivered. The scope of the PRD could be a few FSDs (Functional Specifications Document) or it could be a massive bundle of documents.

Special Notes: A PRD and an MRD may be merged depending on the size of the project. Generally, the larger the project, the more documents you will have.

PRD Outline

• What is the product exactly
• Give a title
• How does it work in a general sense
• Give a brief on what is does
• How does it work in a technical sense. (*The FSD is supplied by the technical department)
• The FSD usually follows the PRD as a technical guideline of how it will be built
• Who does it affect
• Does it compromise anyone else’s requirements?
• Will this affect other relationships
• What parts of the site will it affect?
• Will pricing change?
• How does it fit into the information architecture?
• Does it affect your policies
• Conditions of use?
• Privacy?
• Sales contracts?
• Potential pitfalls?
• Where could errors develop?
• Maintenance?
• Who needs to sign-off?

Depending on how strict your company is or what template they are using, you can always just copy the bulleted list down and provide some answers underneath each bullet point.

The “Meat and Potatoes” of the PRD

This is the “what” and the “how”. The more detailed of an account given, the better.

Here is an example:

* On each product page there is “this”
* Clicking on this link does this
* Advanced view shows “this”
* My mouse does “this” and “this” when I rollover something
* A drop down does this, etc, etc.
* A link goes back to this page
* Purchase options are here

Again, depending on how strict your company is or what template they are using, you can always just create some comps (web lingo for composites, or image examples) which give a visual treatment to all of the above

Further PRDness

The illustration above is a perfect transition into use cases - “a description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more scenarios that convey how the system should interact with the users to achieve a specific business goal or function”- Wikipedia.

You can present different ways the product could affect or interact with the user. If a user goes “here”, then “this” will happen. If the user goes “here” instead, then this will happen instead. Basically, you take the the comps you created above one step further and provides different ways the user could interact with your product. Could they have a different experience if, let’s say Javascript was turned off? Is the content dynamic? Is there only one path the to product? These are the fine tuning that creates a really nice document and remember, there’s no exact way of writing a PRD. See what works for you or your business and go from there.

Enjoy!