When commencing work on a new product, project or initiative, there needs to be a high degree of alignment between interested parties. This alignment ensures firstly that there is a legitimate need for the new product to be built, but also that the capabilities being delivered by the new product meet the stated needs of the project team.
Many documents may be created as part of the kick-off process for a new initiative, such as a PID (Project Initiation Document), a Business Case (showing the financial justification for building the product) , or a BOSCARD (Background, Objectives, Scope, Constraints, Assumptions, Risks).
Often, as part of these initial proposals, certain requirements will be documented. The requirements will detail what the product should do, how it should be done and what criteria need to be met (non-functional requirements).
What is a product requirements document?
A product requirements document (or PRD) is a document which captures details of the functionality that a product is required to provide and the method by which these objectives will be achieved (functional requirements).
For example, a PRD may state “Users must be able to search our online catalogue, filter by size, make a purchase and then pay by credit card”.
PRDs also state the problem or opportunity that is being addressed, the necessary metrics or other business benefits which should be improved or realised by the new initiative and how these are likely to be achieved.
Why are product requirement documents important?
The product requirements document prd is important for the following reasons:
- Provides a high degree of transparency right from the beginning of a project to all stakeholders who may be involved. This is key to ensuring that the entire project team is aligned from the very beginning of the project in terms of what is being delivered.
- Prevents the scenario where a project commences and it is found that key functionality is missing, thereby alienating certain interested parties.
- Ensures a successful product is delivered by preventing extensive rework and changes.
- Prevents the need for multiple projects to deliver missed criteria.
- Makes sure that everyone is on the same page and that key decision makers, such as product managers, business leaders, and technical staff, have had the chance to sign off on the approach.
How to write a product requirements document in 8 easy steps
First, start with why
The most important thing in any project is determining and defining why you are embarking on this new journey. With that in mind, it is important to start off with a good description of the business need or opportunity that you are trying to address.
Some projects fall into the trap of choosing a solution first and then attempting to shoehorn their requirements into that solution. This often occurs when people have chosen a commercially available, off-the-shelf solution. Such a practice is common where people have been lobbied by “shiny suited” salesmen, seen online advertising, or have come from other organisations where such a solution was already in place.
There is an old saying that “to a person with a hammer, every problem looks like a nail”, and so great care must be taken to ensure that you do not choose a solution before you have identified the need.
Instead, use the PRD as your opportunity to solidify and agree on the things that will be delivered by the project early on so that an objective assessment can be conducted of how the need will be met. Such success metrics may already in place by way of OKRs (objectives and key results) or KPIs (key performance indicators)
Many PRDs start with an “As-is” and “To-be” scenario, stating what the current situation is in the organisation (The “As-is”) and highlighting the perceived opportunities that exist. The articulation of the desired end state is often called the “To-be” and is a written state of intent for what the product will provide once delivered.
It is important to ensure that external factors are required, such as political, economic, social, technological and environmental (PESTLE) and a well-written market requirements document from a product owner or other similar role should cover these topics.
Once you’ve defined the need for the project, this will lead you to an informed decision about buying an off-the-shelf solution vs building something bespoke.
Identify your stakeholders
Early on in the project process, you should make sure you understand who your stakeholders are. A stakeholder is anyone with an interest in the product you are building and can be internal or external to your organization.
Early identification of and engagement with stakeholders is of the utmost importance, as this allows you to gather requirements from the broadest spectrum possible. This ensures that last minute changes do not occur unnecessarily.
Many business areas may appear not to be stakeholders at first, such as finance, procurement and HR, but if there are any elements of your system which touch on sales, need tools to be purchased or affect the staffing levels of the business, they may all need to be engaged at some point. Technical teams and product managers are also often key stakeholders in this process.
Engaging with different stakeholders from across the business will also allow you to build out a comprehensive list of user personas. User personas are representations of different users who may interact with a system.
For example, you may have a registered user, an unregistered user, a moderator and an administrator. You may have a product which serves many different types of user and therefore need to consider the system from multiple different perspectives.
Use a robust template
The best product requirements document template should cover a set of standard sections, which can be added and built upon as the need arises. An example list of headings would be:
- PRD Scope
- Problem statement
- List of requirements (possibly in user story format)
- User personas
- Product scope
- Business case, mission, goals and objectives
- Any available process flows, workflows, sample wireframes
- Non functional requirements
- High level user story map (if working in agile development)
This standard document should be stored in a central location so that the progress of completing the relevant sections can be viewed by all the relevant members of the team and wider stakeholder group.
Define what success looks like
The best products will identify specific metrics or success factors that the implementation will “move the needle” on. These could be tangible and measurable metrics such as increasing conversion on a website, or less tangible, such as improving employee satisfaction.
In established businesses, it’s common for PRDs to focus on replacing legacy systems, so the business case here may revolve around the cost and efficiency savings from decommissioning these old systems.
It’s entirely possible that the performance metrics you need to measure and improve aren’t yet accurately measured and available within your organisation. It may be an early task of your project to agree on the correct definition of these metrics and how they are measured, so that reporting tools can be put in place to allow a good initial gauge of performance.
It is very important to ensure that the goals of the project are directly aligned or supportive of the overall strategic business goals. If they are not, there is the likelihood that the project may not achieve sign-off or funding, due to being superfluous the current objectives.
An important part of defining success is also how to measure and track success once the project has been delivered. It’s very common for project teams to immediately disband once the major final milestone has been completed, without taking time to validate that the required benefits have been realised.
Don’t ignore the technical
An often overlooked factor of PRDs are non-functional requirements (NFRs). NFRs define the criteria a product must meet which aren’t visible to the end user. Examples of NFRs are speed, resilience, scalability, security and inter-compatibility.
Whilst these do not need to be defined extensively and exhaustively as part of the PRD, it is important to start identifying them early on as they could significantly dictate the direction and viability of the project. For instance, a website that takes 5 orders a day would be architected very differently to a website which takes 5 million a day.
Make sure you validate your non-functional requirements. Some projects make the mistake of utilising out of date sets of NFRs taken from a central storage location. This may cause the potential for over or under-architecting of the solution at an early stage.
It is therefore important to engage the subject matter experts for these criteria, such as the I.T. security, business continuity or data management teams, who will be able to give you a tailored view of these NFRs that is suitable to both the business need as well as the purpose and intent of your initiative. Your development team should have input into this, to ensure there is no disruption to the product development process.
Be clear about what’s out of scope
When building a product requirements document, there can be the temptation to try and make the product all things to all people. It is, after all, a lot easier to say yes than it is to say no. It is important, however, to keep the scope of the product as focussed as possible, especially in the earlier stages.
Consider focussing on one journey at a time and keep complex integrations to a minimum if you can, this will allow you to spend more time on delivering functionality early on, which can then be learnt from. This is especially true when working in an agile environment where development will be approached in short sprints rather than one long development delivery.
A great tool to use for this is the MoSCoW prioritisation technique, where requirements are prioritised in a “Must, Should, Could and Won’t have now”, along with the justifications for prioritising them in that way. This will prompt challenging but valuable conversations amongst your various interested stakeholders.
Say when
One of the big follies of product requirements documents is to try and define an accurate timeline for delivery up front. Studies have repeatedly shown that attempting to forecast complex and bespoke software delivery up front is a futile task as there are far too many variables and any estimate ends up becoming incorrect.
Generally speaking, if a product or project requires any element of custom or complex development, it is very difficult, if not impossible, to make an accurate estimate. Unfortunately, people still try and often spectacularly fail, thereby losing the confidence of those that require the product.
Just because estimating is difficult, it does not mean that rough timescales and orders of cost cannot be provided though. For smaller, less complex projects or proof of concepts of under 6 months, it should be possible to put together a rough cost and time proposal to the nearest month and with a rough order of financials.
For larger projects, it may be more prudent to aim for discovery or delivery milestones rather than attempting to forecast the entire project. Perhaps start with a design sprint, then a wireframed simulation, then a proof of concept and user testing before moving on to an initial launch of the first phase.
Document decisions
As the elicitation of the PRD progresses, more and more people will input into the document adding their specifications, requirements and making amendments to previously written things. It’s possible that changes made by one person could completely reverse the sentiment written by another.
It’s also possible that a requirement could be specified in the document on the spur of the moment that then becomes perceived as a key, non-negotiable piece of functionality that no one is willing to challenge.
It’s for this reason that it’s very important to log the decisions that were made and the changes made to the document as you proceed. This will allow for an element of requirements traceability, which enables such requests to be validated and for more details to be gathered from the correct party as the project progresses.
For other decisions, transparency on who made them and when is important so that if important changes in direction are made in the project, people can support, challenge or merely understand more about why the decisions were made.
Conclusion
Product requirement documents are key artifacts that inform the initial phases of new software build initiatives. You can share it with business and technical teams who help with the product. They cannot be written in isolation of the business, users, or other key regulatory stakeholders within the organization.
Use your PRDs as an opportunity to closely engage with a wide spectrum of individuals and gather project information in a collaborative and transparent way, ensuring that you start your project off the right way.
The best PRDs will prevent the need for costly and disruptive changes to impact the project once it is in flight. It is always more efficient to catch these things earlier on so that they can be accounted for as part of the design process.
