How to create a Product Requirements Document (PRD)

How to create a Product Requirements Document (PRD)

by Anand Suresh

When beginning with any large development project, typically your company will go into a meeting with a development firm with a set of ideas about what you want. You have a general idea of something you need. Maybe you need a website for your business. You may need some software that will help you process payments. You need a way of understanding something out of your data. You typically have a “why” in your head; you approach a meeting with a problem to be solved.

Any good firm will spend some time with you and go through a discovery phase to identify what is available to meet your needs, what can be done, whether a product exists already that can help you meet your goals, whether it is feasible, marketable, and/or a good idea.

So you’re ready to go, right? Not so fast. Before any work can be done, in most cases the firm will want a Product Requirements Document, or PRD.

A PRD is a document which will provide a clear explanation about what you need this software to do and how the task can be accomplished. It is a high-level description of work to be done. It provides a roadmap to the developers to make sure that the project remains focused. It includes all of the necessary parts that need to go into your product, the timeline, and a lot more.

The PRD won’t necessarily include information about how the project will be accomplished, but is instead a set of clearly defined goals. Before any work can be done on the project, it’s important to develop the what, the how much, and when of any job.

Getting Started

First of all, it is important to understand that a good PRD is a lot of work, so before you begin, here are a few quick tips to making sure the process goes smoothly

  • Have a full discovery process completed before beginning. This will make it a lot easier to move forward, as you already have most of what you need to know sketched out.
  • Write everything down on paper first. Don’t expect it to be perfect right away. Brainstorm first, and then organize later. Create a rough draft, and modify as you go along.
  • Make sure that as many of the stakeholders and participants in a project are involved in at least the early stages of the PRD. It’s easy to forget things, and potentially miss important elements which can be crucial to the overall success of the project
  • Use a template. It’s a lot easier to fill in things from an outline than to do this off of the top of your head. If there are questions remaining to be answered, you will be tipped off right away by gaps in your outline.                       
  • Don’t try to complete it all at once. After you have your rough outline and your draft, sleep on it. Give yourself some time to absorb what you have written down. As no work should be started on a project until the PRD is done, you want to be sure that nothing is left out. You also want to determine whether pieces you were considering before are absolutely necessary.                 

Below is a brief explanation of each of the pieces that should go into your PRD.


What problem will this product solve?

The first thing you will want to do is to come up with a “problem statement.” What are the current conditions? What do you want this product to do? Is it to provide a place to purchase widget X? Is it a way of making an office run more efficiently? Be as specific as is necessary.


Any project will have a basic set of assumptions that drive the creation of this product. For instance, “X people need a product to accomplish Y, which can be made easier if Z.” It may take a while to identify these. Typically this can be drawn out through discussions with the developing firm, who may not know your business as well as you. Many of these will have been fleshed out during the discovery phase. These assumptions should be based on the empirical data obtained through this process, and stated clearly in your PRD.

Who is the target user?

Who are you trying to reach with this product? If it is for the public, you will need to identify which segment of the public. Rarely is any project designed for everybody (unless you are Facebook, which I’m gathering you are not). Typically it is for some subset. In some cases, the target is clear, such as a subset of an industry (e.g. “network engineers,” “family owned businesses,” etc)

Even if it is not a clear demographic, you can define the user by their needs or wants. It may be helpful to define your target as “people who are interested in doing A or B.”

Who are the Stakeholders?

Who is this project being made for. This does not just mean the people who brought this to you, but each of the people who will be affected by the development of this project. This includes not just the client, but inter-office personnel, support staff, etc. Are there any external investors involved?


The section on the environment will describe the physical or digital space where the project will exist. For instance if this is a standalone application, it’s important to specify which operating systems are necessary. What sort of devices are required to be able to operate this? Are there any other requirements, that are related specifically to the target user group.


Included within the environment are the scope and limitations of the project. For instance, if there are necessities built-in that will require use of cloud hosting or local hosting, this needs to be specified. If it is not specified, it will typically be determined to be out of the scope of the project.


If there are any requirements that fall outside of the project guidelines, these need to be specified. For instance, if a project requires certain infrastructural changes to be completed before a feature of a project is to be implemented, these should be described here.


In this section, you will break down the project into specific features or modules. This is a good place to explain each feature and how it meets the overall goal of the product. It is important to include everything here that is intended to go into the project. Anything that is not included here will be considered to be out of scope. You will want to be as detailed as possible about each feature that will go into the product.

Here are few examples:

Mobile capability: Users must be able to access all features of the website through a mobile device with no reduction in functionality

APIs: A series of API hooks need to be created for external developers to be able to retrieve core metadata in JSON format.

Performance: The website should be able to handle X number of transactions per second during high volume periods.

These of course vary from project to project, but every element that needs to go into the project needs to be clearly defined.

If you have future features that you would like to define, you can have an optional section on secondary features. If there is planned future development, it is generally a good idea to include this information, as it will help the developers plan to make sure that the product is scalable to meet future possible enhancements.

User Flow

This is a high-level view of how work will be processed using this software. For example, if this is an e-commerce website, a description of how users would pass through from looking for products through to making a purchase should be described. If it is a back-office application, you will want to create a diagram of how work is to flow from one user to another.

Ideally a visual flowchart should be created to demonstrate the architecture of the product.  For example:

User Flow

Use Cases

Beyond the top-level view, use cases are descriptions of individual tasks that will be handled using the product. Each one of these should be defined including the following: the type of user, the goal or objective, and a description of the task, with a explanation of how the process will be handled with the software.


Many products will have some basic measurement criteria built-in. For instance if it is a website, typically you will want to have some sort of measurement of usage of the site, with everything from how many people are using the site, how they are using it, and some measurement of whether or not the intended goal was accomplished. With back-office type software, it could involve productivity statistics by user. Define what sort of reporting the application should have. Include any methods for catching errors along the way. (For example, analytics software should be able to identify if someone attempted to reach a page on a website that does not exist).

Release Criteria

Release criteria should essentially be a checklist which will make it possible to move forward toward releasing the product. In this section, you will want to define the criteria for measuring whether the product has met its goals in each area, and when it can move forward. Each piece can be treated as an individual module, and will help identify when a segment is complete

Typically these would include the following criteria:

  • Functionality
  • Usability         
  • Reliability        
  • Performance

Most products will require some level of support. For example, if it is a website, you will want to make sure the site is running at all times, and whether it is functioning properly. You will want to have a system in place to enable you to address any issues that come up. Before starting the project, an agreement should be made as to what types of support will be needed. Methods of handling this should be defined.


One very important factor of project management is defining a clear timeline for how work will progress. This should be part of your PRD as well. A clear set of definitions with target dates for each segment should be included. While these may vary from project to project, here is a good basic template  from which to start.

  • Wireframes
  • Alpha
  • Beta
  • Release dates, etc
Final Notes

It’s important to note that a PRD is just the beginning. It does help define the scope and direction of a project and make sure that it is clearly trackable, measurable, and within scope.

However, by using an Agile methodology, it is always possible to modify and add extra modules at some point in the future. If changes occur during development, it is important to remember to amend the PRD to include these steps. The agreement or contract itself may also need to be amended to include any changes. However if you stick with this approach, projects will run more smoothly, with clearly defined measurable, and attainable goals.

You can download the template we created for you here .

Anand is a Senior Technical Project Manager at Practical Logix. Having worked on many enterprise software systems as a lead developer and Project Manager, Anand is responsible for implementing and managing processes for development, QA, DevOps, Release Management and Support and Maintenance. He possesses a wealth of experience from managing projects with 60+ team members, including designers, strategists and engineers. Anand holds a Master of Science degree in Computer Science. He is also a Certified Solutions Architect with AWS.

Leave a Reply

Your email address will not be published.