In this post, we’ll be answer the question: how to write a PRD. we’ll do this with two examples in order to ensure we’re able to help you drive point home. Let’s get started! ENSURE you scroll till the end, we’ve added a PRD Template for you to take with you.
In order to know how to write a PRD, it’s important to first understand what a PRD is. PRD stands for Product Requirement Document, just in case you didn’t know. Note that BAD PRDs result in:
What is a PRD?
A Product requirements document (PRD), simply put, is a document that lists out all the features of a product in as much details as possible. A PRD is like a Bible for tech, sales, product and marketing teams across organization. Almost all Products are different, but fundamentally, they all need to answer 3 things in the PRD, they are:
Let’s look into each of these in greater detail. If you’d like to see how to write a prd in greater depth, you can refer this video. we used this as an inspiration for this post:
“WHAT” of the PRD:
The “WHAT” Primarily answers 3 questions, what are we building, what are people doing to solve this today, and finally, what will tell us if the applied solution does the trick?
“what” is the problem?
This is the use case / problem definition, probably the most important of the lot. If you understand this incorrectly, your product will go through too many iterations. Let’s take two hypothetical examples to discuss through out.
1. It takes 20 hours to travel from location A to B 2. It takes 10 seconds to open web page A
“what” is being done to solve this problem today?
This is the current solution that people are using today.
- People take a train to this location given bad connectivity
- we’re seeing a lot of drop offs (THIS is because current solution isn’t really working)
Then, what is the current user flow (when improving existing feature)
- user goes to station A and goes to station B
- user visits pricing page and then goes to page A and drops off because of high TAT
“What” will tell us if the solution work?
These are Business, performance and adoption metrics, that show the health and adoption of the new product / feature. Examples of two such metrics for our problems are as follows:
- It now takes 10 hours to reach B / 90% of the people who used earlier route have shifted to our route
- % of paid users have increased
“WHY” of the PRD:
This is where the research happens, you need to ask all the relevant questions / “WHY’s” to figure why hasn’t someone else already solve this, and why is this important for us to solve. Let’s take our examples:
why is this problem important to solve?
The idea here is to guesstimate the impact we’ll be able to make.
- Current price of ticket from A to B is 100 INR, there are 500 people travelling daily, this means a 50000 INR daily opportunity, hence 15L INR MRR. Lack of competition and pressing pain means definite adoption
- We’re losing out on paid customers. we can increase our paid customer base by 25%, assuming there are 100 customers and ARPU (Average Revenue per user) is 100 daily, our daily revenue will jump by 10000 INR
Why hasn’t someone else solve it yet?
We wouldn’t want to build something that everyone else already failed at. so the idea is to figure if the complexity of the problem is too high / the problem is new. In case of latter, if it is sustainable, we should solve it.
- building this is too complex, given the path goes via forest and immediate road infra is not possible
- NA – because this is our problem.
“How” of the PRD:
This is where the execution happens, goal here is to help our tech teams as much as possible. Not teach them how to code, but give them as much direction as you can with respect to design, content, go to market approach, etc. Let’s take our examples:
UI / UX mocks (design) or API design
- build a high level diagram / map of the journey
- might not be relevant since UI does not change
proposed user flow (improving existing feature)
- airport A → Airport B
build X feature / product to solve to solve this
- Build Airport A and B, build a bunch of domestic flights, take government approvals
- Connect payment gateway to vendor B instead of vendor A
see how to create product roadmap on airtable
Template of PRD:
You’ve made it! You now know how to write a PRD, but how do you write an actual PRD? If you need the template, please fill this form here, and we’ll be sure to send it across to you. here’s how it looks:
So we hope you finally now know how to write a prd. The Author of this piece is the Casereads team. if you were able to draw some help off-of this post. Please subscribe to our newsletter! 🙂