Let’s Hear it For Documentation! (applause)

Note: For starters, most people refer to a Product Requirement Document or a Project Requirement Document as a PRD for short.

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 a Product Requirement Document. I remember the first one…it 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 facets of web development, the PRD (Product Requirement Document) became my safeguard, my shield, and my savior.

Now that I have written over thirty product requirement documents, some small and 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!

A Product Requirement Document 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) or project brief has been finalized and delivered. The scope of the PRD could be some bullet points or it could be a massive bundle of documents. Remember this is not the technical document, just a brief of the important parts.

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.

Product Requirement Document Outline

• What is the product exactly?
• What’s the title?
• How does it work in a general sense? What are the meat and potatoes of this product?
• Give a brief on what is does
• How does it work in a general sense? (This is not the FSD. Don’t worry about the codebase here)
• Who does it affect?
• Does it compromise anyone else’s requirements?
• Will this affect 3rd party relationships? (affiliates or remote connections?)
• 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 or vendor relationships?
• Potential pitfalls? Where could things go wrong?
• Who might build it?
• Who might bug fix it?
• Who might maintain it?
• Costs? (design, build, hardware, people, etc.)
• Who needs to sign-off?
• How will you measure success?
• Use cases.

Big Tip: 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 Product Requirement Document

This is the “what” and the “how”. I wanted to detail this part of the PRD out. It is one of the biggest “doh!” parts of the PRD. The more detailed of an account given, the better. This will give the designers a pretty accurate account of what you want comp’d. You can then give these robust comps to the developers so they can begin to ask questions, meet and write the FSD. This will save tooooons of time and minimize the amount of push backs and surprises. Don’t be in a hurry.

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 PRD-ness

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 yourself!