Writing a Comprehensive PRD
Shravan Tickoo - Ex- Flipkart ,Blackbuck , BYJUs
Type of entities
Business as an “entity” : Think of business as a living entity which to sustain has
to follow the equation
Business = Revenue - Cost -> Positive profit
If profit is not there , funds are needed to be raised to ensure this equation is met
for business to be sustainable
Type of entities
Product as an “entity” : Think of Product as a living entity which to sustain has to follow
the equation
Necessary engagement on product side which creates service value for end user ,
which leads to growth of a metric which propels the business
If engagement does not propel the business equation - product has no meaning
Business <---> Product
Business and Product have to work , hand in hand to support growth of a value driven
service :)
Type of documents :)
There are majorly 4 types of documents :
1. PRD - Product requirement document
2. BRD- Business requirement document
3. FRD- Functional requirement document
4. DRD - Design requirement document
The Entities broken down
BRD - Its a document written by the business as a requirement to the product team to implement < a
feature or a product or a business line > in order to growth business metrics in some way
Here Business is the - value receiver
Product is the - value generator eventually as the < feature of the product will be part of the product
strategy which will lead to more business value >
Typical parts of the BRD:
1. Business Objective : To implement a chatbot feature on the website to convert more leads in
the signup process from 5% to 7%
The Entities broken down
Typical parts of the BRD:
1. Business Objective : To implement a chatbot feature on the website to convert more
leads in the signup process from 5% to 7%
2. Current pain points : Currently we receive 1000+ visitors on our website currently out
of which only 5% are captured
The normal standard average of a website to lead conversion is 10% according to
hubspot for ed-tech businesses
Thus we need to have a better lead capture process
3. Solution suggested : We are suggesting a “chatbot” feature which will have
automated questions for lead capture - which will get presented if a person spends
more than 10 seconds on our lead capture homepage
The Entities broken down
Typical parts of the BRD:
1. Detailed flow : A user should land on the homepage ,
- As the user spends more than 10 seconds on the page
- A popup to trigger , which will ask for first the name , then the email id and then
ask a question like
- Are you looking for courses
- What type of courses -< Python , data science etc>
- Thanks our executive will contact you shortly
2. Metrics which will improve because of this : Traffic to lead conversion from 5% to
7% , improve lead quality and hence lead to sales conversion from 10 to 11%
3. Non- Goals : This should not lead to drop in any of the lead forms on the page
4. Operational checklist : We should have proper analytics evens to track the popup
behavior
The Entities broken down
Typical parts of the BRD:
This is a typical BRD - Business presents a requirement which product
understands and hence works on the same based on the product strategy
The Entities broken down
Now comes the important part the PRD :
“ A PRD is a love-letter to the engineering team if written comprehensively “
A PRD is called a Product Requirement Document :
1. Product is here the value receiver
2. Dev/QA/Design team is the value generator
3. Users are the value distributor
The Entities broken down
1. If a PRD is written comprehensively , it should do the job of what the PM does in
pre-sprint meeting
2. Here is the break down of a PRD
- Objective : A single statement to make the team understand what to build
- Building a whiteboard feature for zoom such that the tutor & students can actively
engage in problem solving and thus better learning
The Entities broken down
2. The why of the problem : A synopsis of why this problem should be solved and why
it adds so much value to the end user & the business
- Our product “Zoom for education” promises - 3 core pillars to the end user
- Classes from the best instructors
- Active doubt solving
- Study from anywhere
As the 1 and 3 point get addresses , active doubt solving means engagement between
the student and the tutor
The Entities broken down
2. The engagement between tutor and student happens via chat but its shown by
studies by Stanford and harvard educators that problem solving in assignments
coupled by an educator are 50% more effective than asynchronous problem solving
That is why doubt sessions have active attendance where students are willing to not
learn but apply the doubts
Ref 1 :
https://www.omidyarnetwork.in/wp-content/uploads/2020/06/20200527-EdTech-Rep
ort-Omidyar-V6.pdf
Ref 2:
The Entities broken down
2. This also strengthen ours pillars as a strong doubt solving platform thus increasing
student engagement , in-class , post the class and hence student retention
- This also becomes a very strong pillar of engagement and value for our free trial
classes leading to higher free to paid conversion
- Thus a whiteboard feature ( student+ tutor) becomes key to drive student
engagement and hence improves paid user experience and higher free trial
conversion
The Entities broken down
2. High level solution : To build a whiteboard feature where a tutor can launch a white
board and select a student in the class to join him/her on the whiteboard and solve a
problem
Student joins the Student & Tutor
Tutor launches a Tutor selects a
tutor on the solve the problem
whiteboard student or students
whiteboard together
The Entities broken down
2. Functional specifications : These are feature set level specifications which have to be
I.e Tutor launching whiteboard :
- Tutor logins in tutor panel
- Selects the white board option from the CMS option Tray
- The CMS initialises Whiteboard
- Till the time the CMS is initialised it takes 2-3 seconds . At the same time an initialisation popup is shown to
the students on the screen
- The whiteboard once initialised should be showcased to the tutor and the student
- The tutor can select 1 , 2 or max 3 students on bring on the whiteboard
- The students once selected would have options of using a font style pen on the whiteboard and so has the
tutor
- The tutor can close the whiteboard at any point
- Post which the content on the screen will be re-surfaced to the students and the tutor
-
The Entities broken down
4. Mention the designs along side function specs
- Do mention the design done besides the function spec
- If you have mockups - make an invision follow helps
5. Tracking data :
- Define key events in the feature journey
- I.e whiteboard initialization - event 1
- White board does not initialise - event 2
- Whiteboard student selected - event 3
- Whiteboard pen used - event 4
- Whiteboard - event 5
6. Also mention where the events will be tracked such as a product analytics tool such as clevertap or mixpanel
-
The Entities broken down
5. Metrics to track
In order to measure the success of the solution we will define key metrics
Baseline metrics : Watchtime % should increase , student engagement rate ( sumof
(number of insertions done by student )/ total number of students should go up )
Ingestion metrics : Hand raise percentage should go down , delightful reactions
should go up
-
The Entities broken down
5. Questions if any
Here the dev team will ask questions and you will answer
I.e What will happen if student on whiteboard is not responsive for 10
seconds ?
-
The Entities broken down
Top PRD’s - lenny’s newsletter
1. https://www.lennysnewsletter.com/p/my-favorite-templates-issue-
37?s=r
2. PM at SQUARE :
https://docs.google.com/document/d/1mEMDcHmtQ6twzNlpvF-9
maNlAcezpWDtCnyIqWkODZs/edit
