How to Write a Product Requirements Document (PRD)

Published 02-17-2017 00:00:00

What is a Product Requirements Document and why is it important?

This document is an initial one, the starting point in the process of developing your new product. Basically, it describes all the features, specifications, and functionality of a product, and also declares the conditions and stages for design and development. Writing a good PRD is similar to the place where the marathon of creation begins. The better you explain the rules before the race starts, the better the chance that everything goes smoothly and correctly.

In PRD, you gather all the essential details needed for the process of development. You also mention goals and objectives, as well as expected results of each stage of work, time required for the development of MVP, and any additional technical details that might be of help when the actual work begins. Remember that this is not a list of dream descriptions, but a technical document based on research and extensive analysis with a main goal to minimize the risk of misunderstandings, and necessity of implementing changes due to those misunderstandings.

The Five W’s to Think About Before Writing the PRD

  1. Who is my product’s target audience? Car owners in big cities.
  2. Why does the audience need my product? Everyone who has a car wants to find convenient parking with minimum hassle when they go out.
  3. When do I need it by? I would like to launch SafePark in six months.
  4. What do I want to build? A mobile app (for iOS, Android, and Windows phones) and website.
  5. How do I build it (using what languages)? Consult with developer, but generally Swift or Objective-C for iOS, Java for Android, C++ for Windows phone, and Ruby on Rails for the website.

What components should be included in your Product Requirements Document template?

Now we are going to go through the components of a well-developed Product Requirement Document that can be used as a template. Once you understand the idea behind each section, you will have no problem looking at it from an experienced product management specialist’s point of view while creating your own docs. Here are the essential components, which may still be somewhat flexible in sequence, depending on what business you have or other factors:

  • Overview
  • Target Users
  • Main components and sitemap.
  • Initial and future features.
  • Non-functional but also important requirements.
  • Wireframes.
  • Potential risks.
  • Analytics.
  • Release Criteria

One-page PRD

As you can see from the example below, it is a well-designed one-page product requirements document. You may use this sample as a template to explore what elements should be, or may be, included in your one-page PRD. Also, based on this example we can see the main benefits from having a smaller PRD.

First of all, it saves you, and everyone else, the time learning about the product since all the key information is presented in a concise manner.

Secondly, short PRD gives more space for change. It is much easier to cut a piece or replace it. Plus, surprisingly, smaller size leaves more space for creativity, there is no need to follow the same standard format as you’d have to with a bigger PRD. Overall, a one-page document can fit exactly as much context as you need to explain your product in simple terms.