All Posts
As a digital product studio working with a number of clients, creating PRD’s has become second nature for our team of highly skilled product managers.
But what is a PRD? Why do we need this document? And how do we create them? The purpose of this article is to answer these questions and give you all the tools and tips you need to create your own, whilst sharing our insights from creating dozens of PRDs each year.
A product requirement document, also known as a PRD, is a document that helps developers understand what it is they are trying to build. The goal of this document is to use all of the information you have to create actionable user stories that will then decide the requirements for your product build.
A good PRD will outline the products:
How much information you have to begin with will determine how much detail you can include in your PRD. So, it stands to reason that the more you start with, the more thorough your document can be, and therefore the more useful it will be to your team.
At Crowdlinker, our clients generally come to us with a mix of written requirements, architectural plans or technical diagrams, drawings, wireframes and occasionally even high fidelity designs. The level of information we receive is dependent on the client, and for many of our clients this research is all completed by our team, enabling them to leverage a range of expertise without exhausting internal resources.
Using this information, a product manager from our team can then go away and write an introduction to the product, what the overall goal of the product is, and begin defining a list of features that would most benefit users, based on the research we have at this stage of the project.
These documents provide clear guidance for everyone involved in the project. That could include Developers, Designers, Stakeholders and of course PMs. It is a source of truth that establishes alignment between each of these team members, giving clarity and a sense of direction. Because of this, the PRD should be clear, well-researched, and tied closely to the overall goal of the project.
You may have heard people say - “if it’s not in the PRD, it shouldn’t be included in the launch.” This is true, but the PRD can still remain agile and adaptable throughout the different phases of your project.
A PRD can be adapted:
By giving each team member access to the document, you can update the PRD with any new findings. It’s important to remember that any new changes should be dated, and all team members should be informed so that the document can remain a clear source of truth for everyone involved in the project.
Writing a list of requirements can be tough. You don’t want to get lost writing a long list of things you think would be cool, or you assume people want. It’s crucial to have your end-user in mind, and consider how they will interact with your product.
When writing initial requirements, it’s beneficial to understand the who, what/how, and when:
The following is an example of a PRD our team recently created for a client. Using this example, we can break down the previous questions.
I have highlighted the specific requirement we will be focusing on in this example. The ‘who’ here is the app user. For this product, the end-user is someone who has seen a problem and would like to report it. This user needs to be able to access their camera, take a picture, and upload it to the app.
The ‘what/how’ is the function in which the app will allow users to access their camera. For this function to be possible, it will require permission from the user.
Lastly, the ‘when’. When does the product react this way? Essentially, in what situation does the user get to this point? To answer this question we have to think about the user journey, and how they will be engaging with the app.
By answering these questions, we can look at this single functionality of the app, and actively map out the design and development of a requirement, whilst also considering its usability.
As a product manager working within an agency or a digital product studio, the process of creating a PRD for a client may differ slightly to that of someone working internally on a project, but generally the principles are the same. Here’s how you can create your own PRD in just 6 simple steps.
Begin your document by giving a brief introduction to your company and what the overall goal of your project is. You should include an introduction to the product, how you think it might function, and what you hope it will achieve for your users.
Break your research down into as much detail as possible. The more details you know, the more you can learn about what you’re trying to build. This will fill in any gaps in your knowledge, and allow you to make better informed decisions about what requirements your product will need.
Be thoughtful with your time at this stage. You want to get as much information as possible before writing your PRD, whilst balancing time effectively to ensure you’re able to stick to time and budget constraints.
You can then begin outlining your requirements, using the what, why, how method mentioned above. Add in as much detail as possible, so that your team can understand the requirements, and make changes or ask questions where necessary.
Always consider the future scope of your project. At Crowdlinker we will usually add this to the bottom of the PRD. You may be writing a PRD for your MVP like the example I have included in this article, and the future scope will allow you to map out features that could improve your product during a later release. This can be useful when considering future investment for your product, but also gives team members a better understanding of the product's overall goals.
After the 1st version is complete, walk your team through it. You should endeavor to include any gaps in your knowledge as questions for stakeholders and team members to answer during the walkthrough, ensuring nothing is missed out. Get everyone to answer the questions during the first walkthrough, then take that information away and create an improved version of the document.
Once all stakeholders and team members feel aligned with the PRD and have validated all of the requirements, you can begin to create a statement of work.
Allow the PRD to remain a living document. Throughout the design and development phases you may uncover more crucial information that could give additional scope to your project. At Crowdlinker, we aim to work in an agile way so that changes can be made, whilst remaining mindful of time and budget.
Once you have created your PRD, it can be tempting to move on to the next stages of your build without taking it along with you. However, a PRD should be a living document that you can constantly refer back to, not a lost file taking up space on your desktop. To get the most out of this document, and help you to stay on track and within budget, here are some top tips from our team:
Ensuring that all team members are aligned on the initial PRD is paramount to a successful build. Making sure requirements are clear and defined by adding details to functionalities will allow everyone to follow the document closely.
During any project, it is crucial that all team members are united in their end goal for the product. By asking for feedback from stakeholders, or other teams, you can ensure the requirements have been assessed thoroughly, and all angles have been considered.
It can be very common to introduce features during the design phase without actually trying to. Be especially careful if you have a fixed timeline or budget, otherwise, you could end up making trade-offs further down the line, and losing some essential features.
If all team members are familiar with the document, you can stay close to it during design and development. This will help you to avoid accidentally adding in extra features during these other sprints.
After the build is complete, how will you know if it was worth the time and money? What is your overall goal? Try to define your metric of success in advance, so you can properly evaluate if each feature performed well, enabling you to better understand the future scope of your project.
Digital product studios like Crowdlinker create dozens of PRDs each year making it easy for them to spot gaps or things that don’t make sense. Using a partner allows you to get expert insights from professionals you may not have access to in-house - such as senior developers, UX designers, data scientists, etc.
If you’re unfamiliar with creating a PRD, it might seem like a daunting task at first. You want to make sure your requirements are based on the needs of your end-user, enabling your product to propel you towards your project's goals. Like we mentioned earlier, your PRD should act as a source of truth for all of your team members and stakeholders, but remain agile enough that mindful changes could be made to improve the product as more research brings new insights.
With enough research under your belt, and a clear understanding of your objectives, creating your PRD should be a breeze. But if wireframes and requirements have got your head in a spin, leveraging the expertise of a digital product studio like Crowdlinker can completely absolve the burden of creating your PRD by filling in the gaps where any internal knowledge falls short.
