Developing an app? Whether it's mobile or browser-based, iOS or Android, you're going to need a PRD. What's that? Why does it matter? And how to write one? Read on to find out what you need to know to get your project moving with a high quality PRD.
A PRD (Product Requirements Document) is used by developers, startups, and other organizations to define the essential features of a proposed digital product.
The PRD is a key project management tool because it provides clarity to all stakeholders about the precise objectives of the development process.
During the development project, project managers and developers alike will refer back to the PRD, using it to decide the features to work on based on what the product needs to do.
For clarity, let’s return to an example we’ve used earlier in this series; Fromage2U, the cheese sharing app for budget-conscious dairy lovers.
This hypothetical app is intended to help users get their hands on expensive cheeses by giving them a way to team up and buy pricier products at scale, reducing the hit to their wallet.
To prepare a useful PRD to help guide the development of this product, our starting point is asking what the app is required to do.
Some core requirements include:
This list is non-exhaustive, and a real project planning meeting would doubtless bring other product requirements to our attention. However, this is enough for any quality digital product agency to get started by thinking about technological solutions to these requirements.
For example, because Fromage2U requires a mapping solution so that users can find each other and cheese vendors, the developers may decide to embrace the Google Maps Platform, which is available Android, iOS or Web apps, and even via HTTP web services.
After deciding this, the developers might go on to decide which API (Application Programming Interface) they need to use for their app to integrate properly with Google Maps.
For Google services like this, there are some helpful resources available to help developers choose the right solution - such as the API Picker for the Google Maps Platform.
It’s worth remembering that a PRD doesn’t need to specify the exact implementation or technical solutions a development team will use. It’s simply a matter of offering the requirements for those solutions to be matched to.
You can think of it as a shopping list.
Project management isn't easy. Make the process of developing your app or other digital product easier with the help of a PRD.
“There is no favorable wind for the sailor who doesn’t know where to go” - Seneca.
Without a clear objective and a focus on what needs to be achieved in terms of functionality, development projects very quickly become open-ended and lengthy processes without a clear criteria for success.
In our experience, the best projects consistently refer back to the originally stated objectives of the development work.
If they don’t, or these concrete outcomes are never openly stated or go unrecorded, crucial choices are likely to be driven by the preferences of the developers for particular solutions or technologies, rather than the optimal solution for the product.
The importance of having a document that clearly states what you want your product to do is clear.
However, by including the three following types of information too, a PRD can prevent lack of clarity from undermining the success of the project in other ways:
Key assumptions: By acknowledging your underlying assumptions you can prevent later problems for you and your users. For example, if you’re assuming users may not have internet access and connectivity while using your app it’s best to be clear about that with your development team who will need to allow for offline access.
Significant constraints: Are you on a budget? Make it clear that your implementation costs can’t exceed a certain amount. Is there some technology you need to avoid for strategic reasons? By making that clear in the PRD, your team will know your constraints and try to work within them.
Software dependencies: We used the example of Google Maps earlier as an example of an outside piece of technology you might use to meet the functionality requirements of your product. It’s important to list out all of these, if only for risk management purposes. What would you do if a third-party technology became unavailable or was no longer being maintained? PRDs help you plan.
Now you know exactly why it’s worth your team’s time to put together a product requirements document, it’s time to look into what makes them distinctive as well as their key characteristics in more detail.
Without a clear sense of purpose and clear objectives , coordination between team members is likely to result in a fractured and open-ended project. With a PRD to refer to, your team will know what they're aiming for and when they've accomplished their mission.
A product requirements document functions as a list of key criteria that the first release of the digital product must fulfill at launch. It is therefore a narrowly focussed document that builds on but does not contain previous work around market fit.
What does this mean?
The PRD lists what the digital product must be able to do but not necessarily why. The reasons the product has to have certain functionalities are determined in the research phase of the development cycle when it’s being established what features users will value.
By contrast, the MRD (Marketing Requirements Document) makes the business case for the digital product with its various features. It’s not a document that every development project includes, as many subsume this kind of information into the broader business plan.
The marketing requirements document (MRD) usually includes:
As this implies, the MRD focuses on the business context of the product to be launched, while the PRD is aimed solely at facilitating product development.
The MRD provides content useful to anyone writing a PRD, but they're not the same thing.
A product requirements document (PRD) should include:
Beyond the required functions of the app, the writers should include broader systemic or environmental requirements.
For example:
To recap on PRD requirements, be sure to include:
Now you know what a PRD is, why it’s important to have one, how it differs from an MRD, and what to include, it’s time to get down to business with how to write your product requirements document.
A PRD doesn't have to be hundreds of pages long, but it does have to contain certain key pieces of information.
Your first step is to make sure you understand the context for the digital product to be developed. Unless you’re working in a hyper-small team or are the person responsible for preparing the information in the MRD, you will need to consult with the people who did.
You may simply refer to the MRD itself. In fact, we recommend you do this first to learn what you can before discussing it with your team - this will save them time because they won’t have to cover basic information and you can focus on important nuances best explained face-to-face.
By arriving at a thorough understanding of the business case and market context for the product, you’ll make sure that the developers deliver a product that meets the necessary requirements.
If you skip this step, you may find that your development team produces a product that fails to serve the needs of your users which may ultimately have severe consequences for your business. It’s best to get things right the first time, if you can.
Now you know the aims of the product release, it’s time for the exciting part where you start to see your PRD taking shape.
Your MRD or discussions with your team should have produced notes on each of the areas we listed out in the section What should a PRD contain?
As with any large writing project, getting started can be the hardest part. Rather than sweating over the enormity of what you’re trying to do, begin with any boilerplate or proforma information required at your company. Even just creating the document itself without any content can be enough to give you the motivational boost you need to move forward.
With that done, make sure you clearly label your document and state its purpose. Store it in an easy-to-find location available to everyone who will need to refer to it later or will be involved in the review process. Make sure to notify them directly of its location and send them the link. Don’t forget to tell them why it matters.
Make each of the required elements of a PRD a heading (or H2) within your document, rather than trying to write it from start to finish. By listing each point you need to cover as section headings, you break up your task into smaller more manageable chunks.
Make sure to include a table of contents, listing each heading and the page number where the relevant information can be found. Not everyone is going to need the entire document, so make it easy for people to find what they need for their specific role.
Schedule a time to complete each section in your calendar and what was a large unwieldy task becomes a series of small steps with a clear plan for completion.
Once you have your first draft prepared - be sure to proofread to avoid silly or unprofessional mistakes - have the document reviewed by all relevant stakeholders:
Make sure any developers who will have to refer back to it understand what’s contained, especially if it’s written in a non-native language. Confirm with the executive suite, management, marketing, or those responsible for the business-side of the company that the requirements described in your PRD match their expectations for the product.
Getting the PRD right may take several rounds of review. That doesn’t mean you’ve done a bad job the first time round. It’s an inevitable consequence of preparing a highly important document with multiple stakeholders involved upon which may rest the success of the business. Accept feedback in the spirit in which it is meant.
Producing a well-written PRD can be a time consuming process, which is worth taking into account during project planning. However, even with multiple rounds of revisions, it's a valuable step towards developing your app or other digital product.
You now have all the know-how you need to get started preparing a product requirements document (or PRD). You know what it is, why it’s important, what it contains, how it’s different from an MRD, and even how to write one.
It’s time to get started.
