How to Write a Great Product Requirements Document (PRD)

Any aspiring Product Owner looking to build a great software product could be forgiven for feeling overwhelmed. A quick Google search turns up a lot of conflicting, dated examples for Product Requirements Documents (PRD). That’s because people used to follow the Waterfall methodology and define everything their software would do at the outset (think bloated Use Cases and UML diagrams).

We don’t want to waste precious time trying to define every possible thing your software will do and, quite frankly, no one likes writing (or reading) a verbose PRD.

In this article, we’ll share how to write an effective PRD that will help you speed up development and ensure you ship the right features to your users. Referencing our easy-to-implement PRD approach, we’ll go over how to define goals, understand the user journey, and map out detailed requirements. We’ll also explain how PRDs can help facilitate getting a reasonably accurate estimate for your project.

Product Requirements Document Template

By making a copy of our PRD template, you can see a completed example and create your own PRD as you follow along. And if you’re interested in calculating a rough cost breakdown for your project, check out our estimation template as well.

Why do Agile Teams Need a Product Requirements Document?

Today, savvy project managers have shifted to the new, agile side of the spectrum where the product is released quickly, feedback is obtained and improvements are made iteratively. While I am a big believer in agile and Scrum, it is not sensible to just hire a development team and start building features without knowing what you are getting into.

On the whole, I believe that agile is a better methodology than Waterfall, but I think in many cases we have swung too far to the “agile” side of the pendulum and still will benefit from a micro-dose of planning before we just dive in and start developing.

When determining requirements, we want to strike the right balance between being prepared and being agile. In other words, the bare minimum effort that is needed to start building a great product.

For the purpose of this article, I’ll be using a ToDo app as an example, since ToDo apps are familiar ground and common tutorials in the development sphere.

What is a Product Requirements Document (PRD)?

A PRD is a document that communicates the overall vision of a product before it is built. It answers key questions like what’s the product, what’s its purpose, what problems it solves, who will use it, and if there are other similar products that exist on the market. PDRs bring clarity and help answer important questions right off the bat. The document acts as the starting point for your product and is an essential precursor to design and development.

This article should help you create a requirements document that straddles the line between concise and precise.

This article is for entrepreneurs and product owners who are looking to build a digital product. To avoid sounding too vague I have decided to use the example of a To-Do app, but this could easily apply to creating a mobile app or software program.

Why Do I Need to Write a PRD?

Software projects are notorious for going over time and budget. A principal reason for this is requirements that were not sufficiently defined early on in the planning process. If a developer does not have a reasonably good set of requirements, then any estimate they provide will not be very accurate.

Developers, frequently wanting to please, tend to be optimistic in their estimates, and when simplified descriptions of what should be built are given to them, the resulting time and cost estimates tend to be woefully on the low side.

Additionally, taking the time to write down your product requirements will force you to really think about what you want and increase the odds of getting the software you’ve envisioned at the end of the project.

Time spent producing a carefully considered PRD is time saved by multiples later on in the process, making it a valuable exercise for serious product developers.

Embracing an MVP and A Bare Minimum Framework

Often a product owner will have grand ideas for their project and all of the features it might have in the future. Dreaming big is great, but it’s extremely important at the outset to narrow your focus down to the minimum set of features that you need in the first release. This is called the Minimum Viable Product (MVP).

After you release your product and get feedback from your users, you can then decide what additional features you want to add, in line with the agile principles and methodology of software development. However, while you are writing your Product Requirements Document, clear your head of all those potential future features and just define those that will be included in the first version of your product.

Note: Of course, if there is a future feature that must be known about at the outset, then the development team should know it is coming and I’ll talk about how to include that.

7 Steps to Write an Effective PRD

Enough preamble, below are the steps I suggest for a simple PRD:

Not all of these sections are “required” for every software project, and you can use your judgment to decide if a given section is appropriate for your project. For example, if you are building an application that is purely text-based (like a Chatbot), you wouldn’t need the Screens section.

However, I encourage you to include all of the sections in your document unless you have a good reason for not including a specific section. The PRD tool we’ve developed is a bit more robust than the above list, which makes it a powerful resource during the planning process.

Step 1: Define Goals

The business goals and objectives serve as the context, showing the dev team why they are building what they are building.

Here are some common questions you can ask yourself when fleshing out this section:

In the case of building a ToDo app, our primary purpose is to create an app that lets users track and mark off their daily tasks and important commitments. It will help them stay organized and ensure they don’t overlook any items, without requiring much interaction from the user.

The app will need to perform well such that it stands out from its existing competitors, and ultimately act as a “better mousetrap” in terms of its usability and functionality.

Having these high-level goals in mind serves as a starting point for producing a Product Requirements Document. If you already have some answers to these questions, you’re ready to start filling out a PRD document for your project today.

Step 2: Describe User Personas

User Personas are hypothetical individuals who match your desired, or actual, audience. Thinking about the background of these users will improve your ability to create a product that meets their needs.

User personas are one of the areas that people tend to drown in. So let’s establish some rules to keep you afloat.

Essentially it boils down to this: your personas should be detailed enough to allow you to see the product through their eyes. Each profile should function like another person in the room when making a decision. “Would David log in to read his message or should we email it to him?”

With respect to our ToDo app, let’s take a look at three core personas:

Here’s an example from within our tool:

This should give you a picture of the types of personas that can be identified during the process of developing a PRD. With these personas, it becomes easier to derive specific requirements for your product when thinking from their perspective as users with certain needs.

Step 3: Write User Stories

User stories are short descriptions of a feature, told from the perspective of one of your newly created end-user profiles. They are typically structured in the following fashion:

As a [type of user], I want [some goal] so that [some reason].

User stories are a starting point, not a destination. It’s often best to think of them as pointers to your eventual requirements. These stories are vital because the discussions they start will help shape your content architecture and design.

So how can you use this concept to move your product forward without getting bogged down in hundreds of stories and feature ideas?

Here are some example stories for the user personas of our ToDo app:

And here are some for the internal Admin role:

You don’t have to write a user story for every little bit of functionality in your application up front. You should focus on the Epics (higher-level stories about broad objectives) because details will be fleshed out when wireframes and designs are created.

Epics are broken down into smaller stories in backlog grooming sessions. Remember, at this point, you are writing to give the designers and developers the minimum information needed to start a productive conversation about how to create your application.

Step 4: Identify Screens

Identifying the individual screens (for an app), or pages (for a website) are where a product’s shape starts to become clear. They are a distillation of the personas and user stories into a set of distinct sections that satisfy the needs and behaviors identified so far. The process of outlining an application’s screens may also highlight any requirements or considerations that have been overlooked up to this point.

Including these details in a Product Requirements Document may seem unconventional, an argument could be made that this work should be reserved for the design phase after beginning the project. That said, I think in many cases it makes sense for the person writing the requirements document to think deeply about the product and what screens it should have. This has the dual purpose of both contributing to a more accurate vision of the product early on, and serving as a jumping-off point for the time when designers do get involved. Remember: the work done here isn’t set in stone, rather the act of doing it facilitates the production of an accurate requirements document.

These are the four key pieces of information for identifying the screens in a prospective app:

Think of these four steps as a progression towards a fleshed-out picture of the final product as a whole. The better the detail the clearer the path for the project will become, facilitating more accurate estimates and impressions of staffing requirements. Point four (representative images) is especially beneficial to have when planning a project and is worth discussing in further detail.

Wireframes

Wireframes are simple page layouts that outline the size and placement of elements and features on a page. They are generally devoid of color, font styles, logos or any design elements.

Think of a wireframe as a blueprint that shows you the location of elements set apart from the design of those elements. Issues will often surface that may be only noticeable via a visual tool. I often find myself moving (or even removing), the features of a website when I get to the wireframing stage.

Due to the iterative nature of the process, I will sketch the first few attempts onto a notepad and then move into a simple prototyping tool like Balsamiq. The figures below show you the progression of my wireframes from paper sketches to a final version.

Wireframing is probably the most time-consuming step of this process and for some simple projects, it may be overkill. For complex projects where serious design thinking needs to happen, wireframes are an indispensable tool.

As the Product Owner, you may not have experience with wireframing, but I would encourage you to try doing it yourself. Doing sketches on paper and taking a picture with your phone can work remarkably well. I find that when entrepreneurs have taken the time to learn how to wireframe and deeply think about how their product will work, their development projects have gone more smoothly.

That said, wireframes are an optional part of the ‘bare minimum’ framework because they can be shifted to the design phase of a project. When a Product Owner provides all of the other information in this article, we have enough information to prepare a reasonably accurate estimate of the effort it will take to build the product and get started.

Additional Sections for Writing a Great PRD

Step 5: Map Emails

Similar to the section above, here you can document the template, content, purpose, and audience for notifications such as emails and messages in your product. Our PRD tool allows you to outline each communication and attach supporting files if you have them available at this point in the process. Communication with your user base is important and shouldn’t be overlooked during the planning phase of your project.

Step 6: List Functional Requirements

This section of the PRD is used to identify functionality that has not yet been covered in the previous areas. Typically this includes specifics on the internal workings of the app, as well as behavior worth noting but not significant enough for or easily attributable to a specific user story.

Think of it as a general bucket for functionality that’s required in your app, but isn’t covered by a specific screen, story, or high-level goal.

These are some examples of functional requirements for our ToDo app:

Step 7: List Non-Functional Requirements

So far, the bulk of the PRD defines how the software will function (functional requirements), this part of the document defines requirements that may be important to your business, but are not about how the software itself behaves.

This is a place where you can communicate any special parameters that the developers will need to take into consideration. Here are some examples:

External Links & Files

Here you can add links to external resources and attach additional files. This may include something like a link to a competing product, a website whose design is similar to the style which you want to achieve, image and logo samples, and so on.

You can also directly add attachments to the PRD such as design files, documentation and technical documentation, assets, or anything else that may be relevant to your project.

Risks, Future Iterations, and Final Notes

The PRD ends with three areas to record additional thoughts and considerations relating to the product and project in general.

When starting a new project, it’s important to consider the risks involved. Thinking about and documenting these risks help focus the mind on getting ahead of potential problems before they occur. When creating something like our ToDo app, competition from existing native and 3rd-party apps that serve a similar purpose will be our primary concern. To mitigate this risk, we might note that it will be essential that our app functions consistently across different devices and platforms, and that it provides a seamless user experience that’s superior to its competitors.

It’s also worth considering the potential future iterations of our product beyond the MVP phase. For our ToDo app, this may include various convenience features as well as seamless cross-device syncing behavior. Keeping these features in mind early on can help inform design decisions that will make them easier to implement in the future.

And finally, the Product Requirements Document contains a catch-all “notes” section at the bottom to capture anything that hasn’t been covered anywhere else in the document.

PRD Final Thoughts and Resources

Hopefully, this article has demonstrated how a good Product Requirements Document will save both time and money throughout the life of a project. As a final note, not every client has the time to create a requirements document on their own and that’s OK. We’re happy to take on this process by engaging in a brief discovery phase to help you define your requirements.

PRD Resources: