The applications for the assumption canvas are straightforward. If we want to generate business hypotheses to test through customer interviews, surveys, expert interviews, experimentation, or desk research, this tool helps us boil our uncertainties down to concrete, independent units. After generating solutions, client teams most likely have implicitly built in multiple assumptions about the world, their skills, or the usefulness of their solutions. This exercise helps us uncover and address those assumptions.
Here's what we aim to achieve with this exercise:
- Uncover various important underlying assumptions
- Identify the most critical “deal-breaker” assumptions that would render a possible solution/decision alternative impossible or undesirable
- Prioritize, as in - agree on which assumptions should be tested first
- Formulate clear hypotheses
- Design tests
This post will not cover details of the last 2 objectives in the list.
Once teams have settled around a given set of solutions or decision alternatives that address the problem/opportunity at hand, they are briefed about the objectives and logics behind the assumption canvas (set out in the previous section of this post).
The target, as discussed, is to uncover critical assumptions that may render the designed solution/decision alternative obsolete. The assumptions will then be formulated into hypotheses for which data gathering exercises and tests will be designed. The canvas is broken down into 4 sections that represent assumptions of different type:
Technical – those are technology, legal, organizational or other technical constraints that may act as a blocker. For example, we often automatically assume that our solution is legal, or that the technology required to deploy it effectively exists
Behavioural – those are assumptions about the way our target users/clients behave. More specifically, they are about their habits and preferences. For example, selling ice cream in the winter assumes that eating ice cream then and there is what people will do, regardless of the quality of ice cream and its price
Value Proposition – those are assumptions about the value or offering. Each and every solution or product offers a certain “benefits” or “gains”. However, it is often an assumption that those benefits are actually of value to the target user/client. E.g. let’s say that I am offering you a toilet subscription service. You may like the product (preference) and you may be prone to subscription services (behaviour), but you may not see any added value in my specific offering and hence – would not purchase it. This is very important to grasp because if we treat it as a behavioural assumption and ask users if they think this service makes sense, they may say “Yes!”. However, if we ask them if they would pay extra for it, we may get a different answer. Hence – it is of no added benefit.
Scalability – those are assumptions that relate to things that have issues below or above a certain scale. For example a service that relies on a network effect depends on a certain critical mass of subscriptions for its model to work. Or, some solutions do not scale their costs in a good way. For example, if I wanted to make you feel better, I may offer you a backrub. IF I wanted to make 10 people feel better, my solution does not work at scale.
When everyone is clear on the definitions, the group members are briefed on the simple house rules for the exercise. In general, those are simple and similar to the ones in Hopes and Fears exercise:
Input during phase 1 should come from everyone individually
Ideation and evaluation are separated
One assumption per post-it. If you have to use “and” it’s probably not only one idea
Be specific – it should be clear without doubt what the assumption is referring to. E.g. “storing personal data” is not sufficient – one needs to exemplify storing which personal data is of particular risk (e.g. contact details, passwords, etc.)
Testable/Verifiable – this naturally flows from the previous item. One should be able to clearly tell when an assumption holds true or not
Write in caps so everything can be readable
Avoid high-context language and abbreviations – an external person such as the facilitator themselves should be able to understand what the post-it is referring to
One idea/solution/decision alternative per canvas
With that, everyone is invited to contribute inputs to the canvas for a period of 5 minutes per column/section. In general, that is enough to get a good 10-15 entries per category. If the group is small enough, everyone can explain their entry as they are committing it to the wall. That would shorten the next phases of the exercise.
A short note about the framing of assumptions. In the best case scenarios, the assumptions should be framed in such way that if they do not hold true, the proposed solution wouldn’t hold up. E.g. a good framing would be – “Our users will, on average, update their status with text or photos at least at least once a day”, or “Multi-gender ridesharing is acceptable for our target market”, or “We can collect and store credit card data safely”.
Below is an example of how the canvas would look.
Once this part is completed, the facilitator can go through the columns one by one with the group. Similar items will be grouped and unclear entries will be reformulated. Usually that would take another 2-3 minutes per column and would lead to a total of 5-10 entries per category. Not all categories have to be completed (E.g. not all ideas or decisions have an issue at scale).
When everyone is satisfied with the end state of the canvas, the facilitator should document it and the exercise moves on to evaluation. Each individual is given 10 sticker votes and is encouraged to distribute them across the post-its that they find to be the highest risk assumptions. 5 minutes are given for that part of the exercise. Once that part is done, the top 10-15 assumptions are extracted. Hypotheses and tests will be designed for them in order to determine how likely those assumptions are to hold true. This part will be addressed in a further post.