We are increasingly shifting from projects centered on the demands of customers or users to projects focused on product hypotheses. There are several reasons for this.
On the one hand, we are expected to implement new functions within increasingly shorter deadlines. That’s because the competition is getting fiercer, and the world, thanks to modern technology, keeps speeding up and getting more complex.
On the other hand, having more diverse groups of users means facing more diverse needs. We are moving at full speed towards an entirely customizable world. And this creates an even greater demand for instantaneous product adjustments.
From demand to hypothesis
The evolution of software development processes has prompted a change of approach, with the old, documentation-heavy models failing to fit into the new reality. In their stead came methods of continuous development, based on the understanding that systems must constantly grow and change. And hypotheses have become handy tools that help conceptualize the objectives for such changes.
If “demands” require implementation, then “hypotheses,” above all, need to be tested. But before that, the hypotheses must be coherently articulated. Which is not always as easy as we would have wanted.
The importance of articulation
On the one hand, we are all free to articulate our hypotheses in any way we like. There are no rules or laws against any specific approach. Common sense suggests it would be better to word our hypotheses clearly, so that others, like our coworkers, can understand them. But here I recall the theory of inventive problem solving (TIPS), which puts a lot of emphasis on the aspect of goal-setting, because the impact of the final solution depends very heavily on having a coherently articulated goal.
We believe that the more coherent the hypothesis, the more fruitful testing it will be. Testing in this sense covers not just the verification of the actual hypothesis, but also any possible insights that may be gathered in the process. To structure and simplify the process of articulating your hypothesis, we have singled out the following questions, which you can answer sequentially.
The steps for filling out the Product Hypothesis Canvas
- We believe that…
Here, we describe what we plan to develop.
2. For (whom)…
In this block, we define our target audience and, if required, evaluate its role in our project.
This step is very important, as it will later help us rank our hypotheses by their relevance to our project. Sometimes, project team members become utterly seduced by an interesting idea, and end up forgetting that it is only applicable to a few isolated cases.
In fact, if the author is unable to coherently explain whom their hypothesis is going to benefit, it’s very likely that they are just indulging in random guesswork. That is like when a pool player breaks with a powerful strike, hoping to pocket a ball at random. In the same way, product managers and designers generate hypotheses with no connection to the users, hoping that at least someone is going to be interested. Be really careful with such hypotheses; it may be worth the time to think about them in greater detail.
3. To achieve…
It is also important to determine what kind of result we are expecting from our experiment. Moreover, the result should preferably be measurable in specific terms. Don’t write, “We must do better!” It’s better to express your expectations like, “We must improve [product] by 5%.”
Depending on the hypothesis, we may have different expectations for short-term and long-term results. Many people prefer to focus on short-term results and avoid working with hypotheses that have more far-reaching goals. But when we create our hypothesis, we must be aware of how long it will take to test it: a day, a week, a month, or maybe even longer. With that in mind, we will later be able to plan a backlog of our experiment.
4. How do we measure this?
The ability to measure the results is the key parameter for testing product hypotheses. While we already mentioned what we are going to measure in the previous step, here we describe the kinds of tools we are going to use for this. What signals will indicate that the opportunity we have created is impactful? Which key performance indicators (qualitative or quantitative) are we going to measure to prove our experiment was successful?
5. Impact, positive or negative
We have introduced this block in case we want to approach our hypothesis as something beyond a single objective. Filling it in is not mandatory.
In some cases, the introduction of a certain function has a negative impact on other parameters within the system. For example, we add an extensive, informative presentation
to our home page, hoping to increase user engagement. However, the presentation impacts the page’s loading speed, which, contrary to our intent, increases the bounce rate, potentially reducing engagement. In this specific case, the higher bounce rate is probably not caused by the functionality itself but by its bulkiness and poor implementation.
This is what our template for articulating hypotheses looks like:
The Product Hypothesis Canvas helps you create more effective hypotheses. Keep in mind that the canvas does not do the work for you; it simply helps you focus on the task at hand and reach a more effective solution.
How to get the most out of hypothesis creation:
1. Remember: the better articulated your hypothesis, the better the results it will give.
2. Never lose sight of the target audience for which you are testing your hypothesis.
3. Describe your expectations in specific terms.
4. Do not forget about long-term goals.
5. Consider the possible negative impact of integrating your hypothesis into the product.
Dmitry Podluzhny, head of design at AGIMA
