There are a few cornerstones of each tech project that you’ve got to get right. If you don’t, you risk everything crumbling later on.
One of those is the product requirements document. This is the document your product managers use to outline what features should go in a particular release and how they benefit the end user.
The effects of cutting corners here might not be immediate. In some cases, the issues thrown up by a poorly-written product requirements document might not show up until right at the end of the development process, when it’s going to take a whole lot more time to fix than it would have done earlier on.
That’s why it’s super important to understand the purpose of a product requirements document and how to write one well before you start. Put simply, a great product requirements document puts you on track to create a great product. An average one…well, you know the rest.
Below, we’ll go into more detail about why you need a product requirements document, what you should include and how to go about writing one.
Why you need to write a product requirements document
Essentially, a product requirements document provides a single point of reference for everyone involved in the project. If you’ve written it well, everyone should know what the aim of the release is and the scope of any new features or changes you’re going to be making.
Your testing team, for example, will need to know exactly what a particular feature has been designed to do, so that they can measure how successful it is at meeting that goal.
If you’re sloppy about defining this, your testers might not be able to effectively assess whether acceptance criteria are met, and you could end up having to pick bugs and design flaws out of your product post-release.
Alternatively, if you’re using an external agency to design and develop your product, poorly-explained requirements can lead to receiving something quite different to what you had in mind. It’s therefore crucial to align business and product requirements during early stages and to involve all relevant parties.
In addition to keeping everyone on the same page and helping avoid misunderstandings, having a detailed breakdown of what your product needs to do creates a single user-focused source of truth that saves valuable time later on as stakeholders won’t have to chase anyone for more info.
With the right content, a product requirements document helps you avoid this nonsense.
Handily, this leads us onto…
What should be in your product requirements document?
Four things (because who doesn’t love a list?):
- The overall purpose of the document
- The features that need to be built
- Which users it’s going to be for
- How these users are going to benefit from it
If you take nothing else from this article, remember these. They’re that important.
Your product requirements document should list every single capability that you want in the release.
If some of these capabilities are relatively complex or broad-reaching, feel free to break them down into sub-capabilities – do whatever you need to make your requirements as easy to follow as possible.
With each capability (or sub-capability), you should also include:
- Problems: Allows us to address the “Why?” question. What are we aiming to improve or resolve in the grand scheme of things?
- Goals: What’s to be achieved once the problems are addressed?
- Stakeholders: Some features involve multiple parties. Listing them in a separate section and including descriptions can be helpful
- User stories: So your designers and developers understand when and how a particular feature would be used
- Any dependencies: If you need a feature to pull location data from Google Maps or use the device’s camera, you should specify here.
- Any assumptions: This allows you to add context or information that is not necessarily included in usability requirements, user stories, and system requirements
- Any system requirements: Which operating systems do you want to support this release? List them all, with specific version requirements.
- Any usability requirements: You might want mobile apps to be able to be operated with one hand, for example.
When building out which users it’s going to be for and how they’re going to benefit, it’s important to consult the product requirement document’s close cousin, the market requirements document.
“What’s a market requirements document?” you might ask? Well…
What is a market requirements document, and how’s it different to a product requirements document?
As we’ve been discussing, a product requirements document is all about the user, and should center around the holy trinity of what the feature is, who it’s for and why they’d find it useful.
A market requirements document, on the other hand, is based around the customer. It’s all about establishing whether there’s a demand for a certain product or update, identifying market potential and ultimately laying out a business case for it.
Product requirements documents typically follow on from market requirements documents. This is because your organization probably wouldn’t want to build anything they think will incur a loss.
But. There’s more to it than that.
A market requirements document establishes whether your customer base would like a certain product or update, and what they’d be looking for to consider your product over one from a different company.
A good product requirements document uses this information to define the second two points listed above – that’s the ‘who’s it for’ and ‘why will they find it useful’. Essentially, you’re translating what a customer says they would like to something that will be useful for individual users.
How to write a product requirements document
- Read and understand your market requirements document
As we’ve just discussed, this is essential to identify how a release should benefit your users – so read it thoroughly.
Then read it again.
Then have your whole design and development team read it.
Then get them to read it again too.
Understanding it is essential to finding that brilliant, user-focused product your design team (and your CEO) dreams of creating. There’s no such thing as ‘too much reading’, so go through your market requirements document with a fine tooth comb to gain as deep an understanding as possible of what you’re aiming to do
- Get together to discuss some ideas
Once everyone’s had a chance to read and digest, arrange some time to talk through what the market requirements document demands, and what challenges it throws up.
This phase is an opportunity to let your designers do what they do best and just design stuff. Give them time to flex their problem-solving muscles and perhaps knock up a couple of quick sketches of what they think these will look like.
- Draw up a draft product requirements document and share it with key stakeholders
Get a series of regular meetings in the diary to refine these ideas into a draft product requirements document, complete with use case examples, dependencies and system/usability requirements.
Once you have a first-draft, it’s essential that you share it with key stakeholders for feedback. If your designers did some preliminary sketches or created a rough prototype, it’s a good idea to send these around with the product requirements document as people respond well to visuals – though it’s not a necessity.
Depending on the structure of your organization, key stakeholders could include:
- Product team: more likely than not, they researched and drew up the market requirements document, so could have some useful input into whether your solutions would hit the right note with your customer base.
- Developers: will be able to tell you right off the bat if you’ve suggested anything that is beautiful but impossible to build (hey, we can all dream).
- Testers: does your document make it crystal clear what each feature should do and how users should benefit? Get your testers on board to double check.
- Legal/compliance: have you accidentally come up with something that will land you in legal hot water? These guys will be able to tell you so you can rethink appropriately.
- Marketing: marketers make sure your brilliantly designed product appeals to potential customers. It’s worth looping them in early so they can get their creative juices flowing.
- Finance: particularly useful to have onside if you think this project will need extra resources like freelancers or an expensive software update.
- General C-suite, or HoDs: depending on the size and structure of your organization, you might have to run all major product decisions by senior management. See it as a useful opportunity to get some input from fresh eyes – there’s always benefits to having ‘outside’ commenters having a look.
- Your software development agency: if you’re not planning on developing in-house, it’s important to make sure you send a draft to your agency for feedback. They can then make sure that they understand the brief and have time to ask any questions before the development process begins.
Once you’ve gathered feedback, adjust your product requirements document as necessary and send it around once more for final approvals.
- Establish how your product requirements document will fit into your workflows
Product requirements documents have been a staple of the ‘waterfall’ methodology for over 40 years.
If your team works like this, great!
If you’re an agile company, don’t worry. You can still make your product requirements document work for you.
One way of doing this is by reformatting it from a static document to something more interactive, like a task board. This shifts it into line with working in sprints and makes it easier to work with than a static document. Static documents aren’t ideal if you’re not completing an entire phase at once.
- Design, develop, test, repeat
Everything is finalized. You know what your product needs to do and who it needs to do it for.
You’ve laid out, in painstaking detail, what your usability requirements are, which operating systems it should run on and what external integrations it might need to rely on.
Now everyone understands your key product requirements, it’s time for your team to throw themselves into the product development process, and all the highs and lows that come with that – – or to hand over your product requirements document to a software development agency and let them work their magic.
In other words, you’re good to go
Enjoy the ride!
