A PRD (Product Requirements Document) is the most critical stage of a product.  It’s where conception, ideas, and features get shaped and formed.  You should always remember that a PRD is ever-changing and evolving, but the initial phase is always the most important one.

Get ideas down on paper; actually, get more ideas than you really need.

It is far better to have too many details in a PRD, then not enough.

In this instance, I’m going to describe how I took a PRD, wrote it, shaped it, and detailed out use-cases extensively to create a thorough PRD.

First, set the objective of the PRD.  Describe what you want the product to do.  Do not dig too deep into how you want it to function, but more about how you want the end-result to function.  Be brief, again, not too deep.

Second, dive into the user interface requirements.  What kind of options does the user have?  How will they be navigating the product?  Is it a dropdown or a radio button?  What is the flow of how you want the user to interact?  This is very important because this is going to begin the structure of how you want the service to work.  Talk about specifics, be very specific; be descriptive.

Third, talk about administration or moderation.  How are the administrators going to interact?  Will your company be the only administrators or will you allow end-users to have a master account and control their own userbase within.  Talk about reporting, archiving, how you want the delete button to work, or how you want a specific function to translate on the page.  Do not talk about design yet.  Design is not part of the PRD.  This document is purely for the requirements of the product, not the design of it.

Fourth, talk about use-cases.  Talk about a specific scenario where you can see a user coming to the product, interacting, how the administrator would interact – whether it’s real-time or not, and give a detailed outline for what the experience would feel like.  Remember, I said feel, not look (keep design out of this still).

Lastly, include a wireframe or two..or three, or however many you want.  A wireframe of what you envision being the layout for the product.  Maybe it’s just boxes arranged in a simple manner.  But include a wireframe, to give a general idea of what you envisioned.  Note, this is still not design, design will be in a later document and a completely separate process.

After you’ve followed these steps, you will have your first version of your PRD.

The next step now is to go through it and read it.  Hash it out, talk about it, and really think through the words and ideas you put on paper.

This is a simple step by step guide, a real brief top-overview, of how to write a PRD.