Introducing the Riskiest Assumption Canvas
Building products and features that customers want and businesses benefit from
Having started my Digital Product Design career in startups, I’ve become a big fan of the Lean Startup movement and I love the underlying principle of testing, learning, and pivoting by experimenting with the most basic product prototypes imaginable — the biggest buzzword in the tech industry — the Minimal Viable Product (MVP).
But many have become afraid of this word because of its preconceived notions. And you can’t blame them really. I am pretty sure that we are all familiar with this scenario: Someone picked up The Lean Startup book, had their mind blown, and said: “We should really do that!”. Suddenly there is no time for research, solutions and ideas are purely based on opinions and we’ve found a quick and cheap way to build a product or a set of features without fully understanding what the purpose is. In most cases, we’ve cut so many corners that the final result we delivered to our customers provides almost zero value. Cool!
But I think the problem stems from the misinterpretation of what an MVP is rather than the concept itself. It’s because we focus too much on assumptions of an overall system instead of thinking what actually do we really need to know about before moving forward.
I started thinking about this because recently I had the opportunity to work on a product that has literally started from scratch. The good thing is that it’s an experiment product within a bigger organization so there is still the pressure of the success factor but it’s being developed in a more contained and safe environment. Also, the team had already an MVP and it had a good market-fit and sales channel but when I started digging around and asking why this is the way it is, people would tell that “I had this idea and I think it’s true”.
That made me immediately realize that a lot of it was based on assumptions that required validation and most of all, identifying what the riskiest assumptions are so that the product doesn’t fail on the long run.
I first came across the concept of the riskiest assumptions testing by Rik Higham where he discusses that the key to this is rapid, small tests. What’s the smallest experiment you can do to test your biggest assumption? And as Tom Chi, co-founder of Google X, puts it:
“Maximising the rate of learning by minimizing the time to try things.”
Once you’ve validated the riskiest assumption you can move on to the next largest one. Gradually building confidence in the viability of your idea.
But before we delve deeper into the story, let me shed some light on what risk in business language means. Because at the end of the day as Digital Product Designers our job is to balance the goals of the business with the needs of our users. So, risk is nothing more nor less than the quantitatively defined impact of an event, times the (also quantitatively defined) probability of that event occurring. To put simply:
Risk = impact * probability
So back to my story. Once I started asking questions about why things are the way they are and why we have those epics on JIRA I soon realized that a lot was based on ideas and assumptions. I then invited the VP of Product, the Product Manager and the Researcher of the team to a assumptions session and together we mapped out our riskiest assumptions using this formula above. We started off by thinking all the vital assumptions we had about the business such:
- Are we selling to the right customers?
- Is the problem we are trying to solve really a problem and is our MVP good enough to fill the unmet needs?
- Is feature X something that our customers need or just the baby of the CEO which we shouldn’t spend too much time on it?
The goal here is to pick out at least 5 of your riskiest assumptions and objectively test them using generative research — mostly because if it’s early stage you probably don’t have the quantitative data that you need.
That session proved to be invaluable as we identified that what the business thought of who the customers were was very far from who they actually are and who uses the product. This way we were able to push back on a lot of ideas by either the CTO or CEO by having concrete data where otherwise it would be just a HIPPO’s (Highest Paid Person’s Opinions )ideas.
After I did this workshop I thought it would be a good idea to share the framework that we used to identify our riskiest assumptions. That’s when the Riskiest Assumptions Canvas was born.
The Riskiest Assumption Canvas framework
Step 1 — map out your assumptions
Gather your main stakeholders in one room and map all your assumptions that are vital to your product. I do this in two ways. One way, I ask them questions about what problem they think the product solves, which are the customers, what insights they have from speaking to sales or customer support. Think of this like ask the experts session when running Design Sprints. Then group those assumptions into groups.
The second way is together as a team we will brainstorm and write our assumptions based on any of the themes below. You might as well come up with more themes or even remove ones that are not working for you.
- Customers — Who are your customers? What do they do for a living? Where can you find groups of them? How many of them are there?
- Problem — Have you identified a pain point for your target customers? Are they currently doing something to try and solve it?
- Solution — Will your solution solve your customers’ problem? Can they get their core job done?
- MVP — What is the Minimum Viable Product for which your customers will pay?
- Competition — Who else is providing this solution? What is your competitive advantage?
- Sales channels — How will you sell your product/service? Online? Inside sales? Outside sales? Distribution?
Step 2 — Probability and impact
Now you should have a list of assumptions either organized into the predefined themes or clustered in groups that make sense to you. Then, go through each one starting from one group and write down two numbers. The first number is on a scale of 1–5, rating the probability that your assumption might be wrong. This is quite interesting because it’s like an inverse confidence rating. So the less confident you are about it, the higher the number. The second number is on a scale of 1–10, and it’s about how much impact your assumption can have on the product.
Once you are done with the two numbers, calculate for every assumption the total risk. You then should have a prioritized list of Riskiest Assumptions for each theme. Now it’s time for you and your team to validate!
Step 3 — Research to validate whether they are true or not
Depending on the theme of the assumption you can either do user interviews and identify whether or not the problem(s) you are trying to solve are the right ones, or that the customers you are selling to are actually the ones who would use it or not.
In some cases, especially for the solution part, the KANO model can be an excellent way to test your solutions and test your feature and follow up with a KANO questionnaire.
Grab the PDF version here or save the image below
If you found the canvas and the framework useful please share your thoughts with me, I’d love to know how you use it.
If you liked this article show me your appreciation by clapping on Medium and sharing this post on Twitter and LinkedIn by adding my social media handle. :)
