Hey Fam!
In today's video, we will cover what a product requirements document or PRD is,
and share 5 things to keep in mind when writing this document.
If you are applying to associate product manager roles or product internships,
PRDs is something that you will definitely be asked about during interviews
To share a personal experience,
a few years ago when I interviewed for Google’s Associate Product Manager program or APM,
during my interviews I was asked what is a PRD and how to build a product spec.
I had no clue back then what a PRD was because I was not exposed to
that in any of my classes in college. And this is one of the main reasons that
motivated us to put this video together so that whenever you are asked what is a PRD you are
able to answer that question successfully If you are currently a PM or transitioning
into this role, this video will help you build a good foundation on what to keep in mind when
writing PRDs because you will be spending a lot of time working on these documents
If you are an engineer, a designer, a marketer, or a founder
working on building a new feature or product, this document will help you
think of the end-to-end experience of the product you are building.
If you are new to our channel, welcome!
My name is Dante, and I am a Product Manager.
If you are interested in working in tech and are
looking for career guidance this is the channel for you.
Our goal is to provide you with practical advice and knowledge
to help you enter and thrive in the tech industry
Let’s jump right in
What is a PRD?
The Product Requirements Document or PRD for short is a document that
is primarily written by a product manager that answers three fundamental questions:
#1: Why should we build a product? #2: What should the product do?
#3: How do we measure the success of that product?
Without a PRD, teams will have a lot of different assumptions
about the product and the features that need to be developed.
For example, the design team may be thinking of a feature in a certain way,
while the engineering team may have a completely different perspective on it.
documenting requirements solves that problem
A PRD aligns stakeholders around the key capabilities that will be delivered in a new
product, helping everyone from engineering, to design, customer support, and sales,
to effectively collaborate to build an end-to-end experience that will make customers happy
The PRD also helps to balance the engineering
team’s functional concerns with the design team’s focus on usability.
To summarize, a PRD is a document that is written by the Product manager
to create a shared understanding of the purpose of a product across the team.
Here are a few things to keep in mind when writing a PRD:
#1. Focus on the problem, not the solution: The goal of the PRD is to
explain “What” the product should do, not “How” it should be built.
The PRD should be a guideline for engineering,
design, and UX research teams to follow when designing solutions, not a recipe to follow
#2. Be concise: The PRD should be as concise as possible and no more than a few pages long.
Avoid lengthy documents at all costs. No one is going to read a PRD entirely
if it’s too long, and will actually cost more work for you because they may ping you about
questions that you may have already covered in the PRD. So make sure to keep it short and sweet
#3. Keep the PRD up to date: Good product managers keep their PRDs updated on a daily
or weekly basis, and they understand that the PRD is an ongoing process
The PRD is a living document that evolves as our team iterates, and it is our responsibility as
PMs to document any decisions and assumptions being made along the way for future reference.
One way you can do this is by adding a Recent
Updates section at the top of the PRD with two columns:
The first one for the date of the update
and a second one to provide a brief description of the update and keep everyone informed
#4. Get feedback from your stakeholders: The purpose of the PRD is to get
everyone aligned on the same page to avoid misunderstandings about what we are building.
Think of the PRD as a tool for collaboration, make sure to share the document and get your
stakeholders involved, especially the engineering and design teams
Encourage them to post their questions in the document, provide feedback,
and share key lessons that they’ve learned from other product launches.
#5. You know you have written a good PRD when you apply the rule of 5
which states that if you were to ask 5 random team members about the product’s purpose,
timeline, status, and features they should all be able to give you
roughly a similar answer.
By keeping these 5 things in mind, you will drive clarity across your team, and ensure that
everyone has a clear understanding of what the product should do and why you are building it.
Why do PMs write PRDs?
By putting our ideas into a document and reviewing
it with our stakeholders it will help us accomplish 3 things:
#1: Building out a PRD helps Product Managers fully think through what
the end-to-end experience of a product should be
Writing things down forces PMs to think about dependencies, like internal systems,
resources, or teams that may be needed or impacted when building out your product.
#2: Writing a PRD helps Product Managers identify the must-haves
versus the nice-to-have features of a product and helps us prioritize the essential components
that need to be built out by engineering to have a Minimum Viable Product or MVP ready.
#3: Shared understanding - Listing out our ideas in a
document allows PMs to validate their assumptions,
and brings the noise down when someone says "I don’t know what that PM is building."
It is very important for a PRD to be clearly written because a number
of other documents will be created by other stakeholders in the organization.
For example, engineers will create a technical specification also called a spec,
which describes how each user story in the PRD will be implemented,
and they may also create an architectural design document.
The product design team will create wireframes and mockups as needed,
and the quality assurance team or QA will write out a test plan to ensure that every use case
in the PRD is working as expected and document any bugs or defects that they may come across
To recap
Product Managers spend a lot of their time answering the question of WHAT
should the product do and aligning teams to execute against the product vision.
The Product Requirements Document or PRD
is one of the most useful tools in a PM’s toolbox to accomplish that.
The key takeaways from this video are:
#1: The PRD is a document that is written primarily by a product manager
to answer WHY a product should be built, and WHAT it should do
#2: The PRD should not answer “How” the product should be built.
It is up to the engineering and design teams to come up with how to implement the product.
#3: Keep the PRD concise, up to date,
and involve your stakeholders to provide their feedback and questions directly in the document
If you found this video helpful, please give it a thumbs up,
subscribe, and share it with someone whom you think can benefit from it.
If you have any questions or know of any PRD tips please share them in the comments below.
In our next video, we will be covering how to write a PRD
and share an example with you, so stay tuned!
Thank you so much for watching, and we'll see you in our next video!
Bye!