Product Management is a core position at almost all the tech companies now yet a major chunk of product managers remain confused at where they are wrong and how they should be operating their product-engineering-design-etc-etc business.
Solution: Product Requirement Document (PRD)
I know, you’d say you already write it but there is very high probability that you ain’t doing in the correct way. Or may be you’re doing it correctly but you will definitely learn something from my version, so keep reading ;)
For novices, let me explain what this heck is all about.
PRD is a thorough document prepared by Product Managers containing each and every details of what the product requirement is — thus helping the engineering/design team to have clarity around what needs to be done and all the possible details linked to the task (including design, prototypes, instrumentation etc)
First of all, create a table and mention the prerequisites mentioned below to set the table
Then we divide the PRD into 2 Parts:
- Experiment Plan
Yes. Include the result part in PRD (obviously keep it blank till the time you have the results). This is important as the this will improve the transparency of the performance of the experiment and the team contributing (engineering, design) to the development, everyone will know the metric they are impacting and what the impact did their effort had on the product.
We’ll cover Results at the end. Let’s start with the Experiment Plan sections
The first thing to do under Experiment Plan is to define the problem.
Basically there has to be a problem statement for which this whole product changes in the form of experiment is being done. So define the problem statement first. Ask as many questions as you like to get to the depth of the problem so that we are affirmative that we are working on a problem that actually exists and not on a problem which is based on emotion/assumption or is not data backed.
- What the main problem is? (You should use Five Whys Method here)
- Who are we solving it for?
- Why solve it? The impact? (impact helps in prioritisation)
- Does it contribute to org level OKR?
- What type of experiment is this? — Client side / Backend
- What user problem is being solved? (Check for the validity of the user problem from reviews and UXR)
- How will we measure the success of the experiment? (Success metrics. Don’t forget check metrics here)
Next you mention the pre-analysis data — basically the data supporting the your decision of doing this experiment.
Next you mention the hypothesis:
Format: We hypothesise that …. will increase / decrease …
If you have defined the problem properly then this hypothesis is definitely data and user research backed.
Mention all the assumption made and question them if they are okay to be assumed.
In case, assumption is in form of a number, percentage etc, it’s better to assume a range and build a model, rather than assuming a ballpark number or percent. The model will give a range of output based on the range of assumptions.
Next you mention the Targeting of the Experiment
This step is critical as this is a make or break kind of detail. If you don’t research on whom are we actually targeting, then the complete experiment is scrap.
A few examples:
- Daily new app launches
- All users
- Users who do first time signup
Define the variants:
So if we want to do an experiment with 10% of the target audience, variant-1 can have the new changes, and we will need another variant called variant-2 with same size as that of variant-1 for comparison purpose but will be same as that of control with no new changes.
Next you mention the Flow of the variants of the Experiment
Mention step by step flow of each variant (including the control one) along with screenshots from design or prototype, if possible.
- Success Metrics
- Check Metrics
Mention the scope of the product requirement or divide it into multiple versions if needed.
Now suggest any any event to be added or any changes to the existing event needed and the experiment name. Make sure this is detailed as well with proper schema of the events.
Next we add the result table
That’s a basic but more than enough kind of PRD. This will evolve into a perfect PRD as per your own product.