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 a product requirements document. People used to follow the Waterfall Model 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 frankly, no one likes writing (or reading) a verbose 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.
This article will help you write a product requirements document that will be good enough to get a reasonably accurate software project estimation from a dev shop. You can do this on your own, or by using our freely available tool to help with the process. For the purpose of this article, I’ll be using a ToDo app as an example project, since ToDo apps are familiar ground and common tutorials in the development sphere. When determining requirements, we want to strike the right balance between being prepared and being agile. In other words, the bare minimum effort needed to get started building a great product.
What is a Product Requirements Document?
A Requirements Document should act as the starting point for your product: outlining its purpose, who will use it, and how they will use it. It 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 example of a To-Do app, but this could easily apply to creating a mobile app or software program.
Why is this worth doing?
Software projects are notorious for going over time and over 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 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.
THE ‘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. 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 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.
Enough preamble, below are the sections I suggest for a simple product requirements document:
- Goals
- User Personas
- User Stories
- Screens
- Emails (and messaging)
- Functional Requirements
- Non-Functional Requirements
- Other Resources
Not all of these sections are “required” for every software project, and you can use your judgement 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.
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:
- What is the purpose of this project?
- What are the problems it will solve?
- What improvements does your product offer over current solutions?
- What is the product vision?
For the case of building a ToDo app, our primary purpose is creating 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 PRD. If you already have some answers to these questions, you can start filling out a PRD document for your project today.
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.
- Cover the primary types of users. You don’t need to create a persona for every kind of user, just enough to illustrate the main groups who will use your product. For simple applications, 3 good profiles will cover more than 80% of your user base. If your application is complex, it may be helpful to develop additional personas for the different use cases you may have.
- Focus on what you know and the key activities for each persona. Making up inconsequential “filler” details is a distraction.
- Start with these 5 attributions. Occupation, age, gender, location, education. They will be the framework for your profile.
- Name your personas. It’s easier to relate to “David the Executive” than to “End User D”.
- Give each profile an objective. Each user needs a goal that fits their profile. This will be their raison d’etre.
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 login 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:
- Kelly Tort, full-time mom. Kelly has millions of things to do, between wrangling kids and running errands. She has a lot of tasks and commitments to remember, all while being distracted by her kids and day-to-day responsibilities. The app will need to make sure that nothing falls through the cracks.
- Jack Foster, professional plumber. He’s busy with a lot of clients, each with their own list of needs and deliverables. Jack needs to have quick access to what has to be done for each client as he proceeds throughout his workday.
- Adam Jefferson, a software engineer working for the company that created the ToDo app. Adam needs to access an “admin” view to see reports and statistics on how people are using the app in order to improve the product for future iterations.
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.
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?
- Limit yourself to high-level (and must have) stories. These high-level stories are known as Epics and can be broken down later into smaller more manageable stories.
- Your stories should be short and specific.
- They should describe who needs what and why
- They must be user-centric. Remember you can use your personas.
Here are some example stories for the user personas of our ToDo app:
- As an External User, I want to be able to sign up for the app so that I can start using it.
- As an External User, I want to be able to create a new task list so that I can organize all of my errands.
- As an External User, I want to be able to create tasks and add them to my lists so that I can organize my day.
- As an External User, I want to be able to search so that I can easily find a task regardless of which list it belongs to.
- As an External User, I want to mark a task as completed so that I can remove it from my lists.
And here are some for the internal Admin role:
- As an Admin, I want to be able to login to the administration system so that I can review user data.
- As an Admin, I want to be able to delete user accounts so that I can remove inactive or abusive users.
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.
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 PRD 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:
- Name: A distinct name that’s easy to refer to during the design and development phase, such as the “Login Screen”.
- Description: A high-level overview of the screen’s purpose. Eg. it should allow users to access the app, create an account, or recover their password.
- Elements: Key items on the screen. For the login, it would be an email or username input, password input, submit button, forgot password link, and a create account link. These elements are typically listed in order of their importance over position since that is communicated in the following point.
- Images: Wireframes or mockups representing the screen to illustrate the overall layout and placement of key elements, sometimes annotated with relevant notes. They’re not complete designs, rather a rough outline for the core of the product.
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 impression of staffing requirements. Point four (representative images) are especially beneficial to have when planning a project and are worth discussing in further detail.
Wireframes
Wireframes are simple page layouts that outline the size and placement of elements, 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), 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 it can be shifted to the design phase of a project. When a Product Owner provides us with 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.
Emails
Similar to the screens 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.
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:
- API operations and endpoints to perform actions such as creating and retrieving a user’s ToDos
- Scheduled tasks for the internal system, such as periodically generating reports or performing database maintenance
- Details such as how tasks and task lists should be sorted by default
Non-Functional Requirements
So far, the bulk of the product requirements document 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:
- The application must be built in Ruby on Rails
- The application must be hosted on AWS
- The application must use Stripe for payment processing
- The application must work in all modern browsers
- The application must be responsive (work well and look good on all screen sizes)
- The application must be able to support 1000 simultaneous users
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, 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 PRD contains a catch-all “notes” section at the bottom to capture anything that hasn’t been covered anywhere else in the document.
Conclusion
Hopefully, this article has demonstrated how a good product requirements document will save both time and money throughout the life of a project. To further speed up the process for you, we’re making the PRD tool we use here at Scalable Path free for everyone, regardless of whether or not you’re part of our network. You can also see an example PRD for the ToDo app discussed in this article.
If you’re looking for a Google Docs version of our PRD tool, it can be found here. It lacks some of the features that make the web-based version great, but it’s available if you prefer to use it.
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.
Are you looking for help with your next software project?
You’ve come to the right place, every Scalable Path developer has been carefully hand picked by our technical recruitment team. Contact us and we’ll have your team up and running in no time.
Editor’s note: This article was originally published on January 18, 2017 and was updated on May 19, 2020.