How to write a PRD
PRD is the greatest physical work done by a PM. It’s the only document really written that’s used by everyone and has the entire plan to execute.
Even though it’s a small (comparatively) looking document but it has information condensed from many processes like discovery, user research, and meetings with stakeholders.
For beginners, it’s good to make a template and follow it. After a few times, PM starts to think in the same format.
Description
This is a 1 liner for your project to give a quick idea of the PRD and the solution. This should be written after the solution is finalized.
Example: A short permanent 15 second video upload with audio as a post termed in a new format as a reel.
Problem
Describe the problem here in detail, better to condense as bullet points. It’s extremely important to amplify the problem with data. How difficult is the problem for the user? What is this stopping the user from doing and to which extent?
It should be written so that whoever is reading is convinced of the value and risks that will come if they are not solved.
Why
Why is the above problem worth solving and why it should be solved now?
Support the problem with statistics and qualitative data. How many users are facing the issue? What is the competitor doing and what market will they capture if they launched it before us? How does this problem fit into the strategy and growth plan?
According to me, this is the MOST important part as if this is not clear with evidence the other part is useless. Put a link to all the research that has been done, this research with insights and user behavior will aid in solutions.
Success
How do we know if the problem is solved?
Mention the goals you want to achieve by solving the problem. These goals are solution agnostic and should be achieved to make the experience the best for our users. With every goal (tangible/intangible), mention it’s priority too as with complex features or MVP it might be needed to focus on a few top goals.
Over here only, after the solution is fleshed out, should metrics come from north star to tracking to other metrics impacted.
Again, this should be as concise as possible so that people do read it and not skip it.
Audience
Who are we building for? Who are the users?
I would say keep this super-short with no frills. Explain the segment of users and their behavior and traits. Bullet out the use cases in which they face the problem.
How
What is the experiment plan?
The feature that is being proposed, how is it being validated with the first set of users? Who is the first set of users? How long will the experiment run? When will the experiment end and what will determine the success or failure of the experiment?
Even in B2B, I would always roll out in phases for a big feature and keep tweaking as per the tracking metrics and direct feedback from customers.
When
When does the project ship and what are the milestones?
At a high level, what’s included in V1 vs. later versions? How big of a project is this? What’s the rollout/testing plan? Consider the major pieces of functionality, Mobile, Platform, Internationalization, Entry Points, User Onboarding, and Premium.
Key Trade-Offs and Decisions
Whatever decisions were taken in framing the solution, this is a track record of it. Generally, my PRDs are filled with tables of pros and cons and impact. Sometimes there are links to sheets with brainstorming sessions and it’s condensed information.
SOLUTION
This will be broken down into 3 parts:
Vision
This is essential to me in this space. Because I always feel the more we go into user stories, the more we lose sight of what’s big and what as a PM after bonding with customers was thought of.
User stories
This is what will be developed. Write them in the format and cover all possible touchpoints and edge cases.
This will keep refining overtime before the real development begins as many leaders give their input.
Make sure the stories follow the flow that the user will perform and experience.
Key Logic
If there is any logic or calculation that needs to be defined. put it here with all examples of cases that might occur. To actually cover all cases, discuss this with the engineering team and take their input freely (this was true for me at least).
Open Discussion
After PRD is locked, use this section to write the date of discussion, the people’s names with whom the discussion was made, and what was the outcome. This is extremely important to log so whenever there is a dispute or lack of clarity, this can be referred to.
