How to write a better hypothesis as a Product Manager?
This is personal learning of mine which I learned during my internship at Powerplay. Running experiments and getting results is something we admire a lot at Powerplay and to run these experiments we need to have a good hypothesis to test with.
I had a great opportunity to see & work on different experiments as a part of the product team at Powerplay. I’m in the implementation POD of the team and our team's main focus is to make sure users make an investment in the product so that they are ready to get retained in the product.
A hypothesis is nothing but just a statement made with limited evidence and to validate the same we need to test it to make sure we build the right product. If you can’t test it, then your hypothesis will have to remain in your dreams.
First, let’s see why do we even need a hypothesis? The reason is you don’t know what would work and what wouldn’t. You can’t just brainstorm and come out of the room and say we’re going to make this feature live, if you do that, then chances are high you will fail. But what if you can come up with multiple solutions using existing data and user stories (which comes from conducting user interviews) and then test them live with the real users? Yes, a few of them will fail but at least you now know what is the thing that your users liked the most.
These are the main components of a good hypothesis or say these are the things you need to define to write a better one -
- Problem
- Outcome & Metrics
- Epic Story
- User Goals
- Current Solution (If exist)
- Problem with the current solution
- Alternatives (If exist)
- Hypothesis
These are by no means in a definite order, sometimes you may not need these things depending on the project & problem statement.
So, starting with the “Problem” first, this could be the broad problem stating what you’re trying to solve. This doesn’t need to be very specific to a particular user but a generic one. The next thing is “Outcome & Metrics”, here you would mention what you want to achieve after the validation of your hypothesis. This is like how things would look if your hypothesis got validated. You need to clearly state metrics because that would help in letting you know whether this thing worked or not.
For example, a problem statement could be like - ”How might we increase the assignment upload rate from students?” and the Outcome might be - “If we build XYZ solution and validated our assumption then chances of assignment uploads would get increased by X% & helps us increasing our X metric”
Note: Here I’m talking about college teachers as my primary users & would be giving examples further considering that only.
Now the next thing that comes is the Epic story, it’s the large user story that contains multiple user stories. It’s the general user story but under it, there could be various user stories, that might help us better understand the problem and could create various flows solving the bigger problem together.
After this there are the User goals, it’s the part of the User stories. In the whole user journey, there could be multiple user goals, write them down & on the basis of them we need to write the hypothesis.
For example, an Epic story could be like - “Get back assignments from students in a faster way” and the various User goals could be - “As a user, I want to update assignment marks in sheet as early as possible”, “As a user, I want all the assignment’s marks in a single place”.
Next, you could write the existing solutions if they already exist & the problems with them, if not then just don’t and write no existing solution exists. Secondly, you might want to mention the alternatives, these could be something that are the different possibilities to solve the same problem.
Finally, the time comes to write the hypothesis, in the hypothesis, one should definitely mention what is the value that the user is getting if we build that particular solution.
An example could be - “As a teacher, I want to get assignments early from students so that I can update marks faster, if your application helps me do this, then my chances of being more productive increases”
Here, in this the value user is getting is “Increased productivity” & “Faster process”. It’s not necessary to write a hypothesis in the same format, even this could be written like - “We believe that if a user(teacher), get an assignment faster then the chances of being productive increases & s/he can update marks faster.
Yes, it’s that simple as you saw above. Now it’s time for you to write one for yourself. And obviously, you need to test these with your users either during the design/prototype phase or directly live with the users, if you have multiple experiments to run, to test which one works best for you.
