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 what you need; maybe you need a website for your business, some software that will help you process payments, or a way of understanding results from information pulled out of your data. You typically have a “why” in your head; you approach a meeting with a problem to be solved. In this blog we would like to let you know more about Product Requirements Document.
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, and whether it is feasible, marketable, and 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 that clearly explains what you need this software to do and how the task can be accomplished. It is a high-level description of the work to be done. It provides a roadmap to the developers to ensure the project remains focused. It includes all the necessary parts for your product, the timeline, and much more.
The PRD won’t necessarily include information about how the project will be accomplished but is a set of clearly defined goals. Before any work can be done on the project, it’s essential to develop the ‘what,’ the ‘how much, and the ‘when’ of any job.
Getting Started
First, it is essential to understand that a good PRD is much work, so before you begin, here are a few quick tips to ensure the process goes smoothly.
- Have a whole discovery process completed before beginning. This will make it much easier to move forward, as you already have sketched out most of what you need to know.
- 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 it 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 essential elements which can be crucial to the overall success of the project
- Use a template. It’s easier to fill in things from an outline than to do this off the top of your head. If questions remain 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 the pieces you considered before are necessary.
Structure of the PRD
Below is a brief explanation of each of the pieces that should go into your PRD.
Purpose
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.
Assumptions
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?
Whom are you trying to reach with this product? If it is for the public, you will need to identify which segment of the people. Rarely is any project designed for everybody (unless you are Facebook, which even started as an app for Harvard University college students). 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, or college students)
You can define users by their needs or wants, even if it is not a precise demographic. It may be helpful to define your target as “people who are interested in doing A or B.”
Who are the Stakeholders?
Whom is this project being made for? This does not just mean the people who brought this to you, but everyone who will be affected by the development of this project. This includes the client, inter-office personnel, support staff, etc. Are there any external investors involved?
Environment
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 essential to specify which operating systems are necessary. What sort of devices are required to be able to use this? Are there any other requirements explicitly related to the target user group?
Constraints
Included within the environment are the scope and limitations of the project. For instance, if there are necessities built-in that will require the use of cloud hosting or local hosting, this needs to be specified. It will typically be out of the project’s scope if it is not set.
Dependencies
If any requirements fall outside the project guidelines, these need to be specified. For instance, if a project requires specific infrastructural changes to be completed before a feature of a project is to be implemented, these should be described here.
Features
This section will break down the project into specific features or modules. This is an excellent place to explain each part and how it meets the overall goal of the product. Including everything that is intended to go into the project is essential. 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 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 express, you can have an optional section on secondary characteristics. If there are 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 possible future enhancements.
User Flow
This 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 to making a purchase, should be described. If it is a back-office application, you will want to create a diagram of how work flows from one user to another.
A visual flowchart should be created to demonstrate the product’s architecture. For example:
Use Cases
Beyond the top-level view, use cases describe individual tasks 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 an explanation of how the process will be handled with the software.
Analytics
Many products will have some essential measurement criteria built in. For instance, if it is a website, typically, you will want to have some measurement of the site, with everything from how many people are using the site, how they are using it, and some measure of whether or not the intended goal was accomplished. With back-office type software, it could involve productivity statistics by the 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 that 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
Support
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 correctly. 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 on what types of support will be needed; methods of handling this should be well defined.
Timeline
One significant 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 an excellent 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 trackable, measurable, and within range.
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 essential to remember to amend the PRD to include these steps. The agreement or contract itself may need to be amended to include any changes. However, if you stick with this approach, projects will run more smoothly, with clearly defined, measurable, attainable goals.
You can download the template we created for you here .
