How to find and prioritise your Riskiest Assumptions
If you’re working on an Alpha, you should be focused on testing your most risky assumptions. These are things that your design assumes to be true, but might not be, and that if you’re wrong, then the project will fail.
Alpha doesn’t mean you have to prototype your entire service. You’re trying to make the cost of building a service a less risky investment. Depending on what you’ve designed, that might take just a few days, or it could take much longer.
The key is to ask: “What are the riskiest things that the design of this service assumes to be true?”
3 types of assumptions
For most services, the majority of your risky assumptions will be to do with how users interact (because people are always the most unpredictable part of any system).
e.g. We assume users will find the link to the next page.
You need to test those with user research.
Assumptions could also be about what’s technically possible to build
e.g We can build an API which interacts with the legacy database.
Test these by building a proof of concept.
Lastly, you might have assumptions about policy/organisational constraints.
e.g We can change the rule that this service requires a wet signature.
Test these by ensuring the right stakeholders are aware of your design and have signed it off where necessary.
These 3 types of assumptions should cover most risk in most projects. Think of them as ‘lenses’ that you can look at your project through. Try stepping through your journey map, service blueprint or paper prototype with your team, looking for anything you aren’t 100% sure will work. Make sure you’ve got experts in each of the 3 lenses with you.
Prioritising your assumptions
Once you’ve got a bunch of assumptions down, you need to prioritise them into the most risky. Score each assumption with two scores:
- Impact if we’re wrong (Higher scores for worse impact)
- Confidence that the assumption is correct
Impact minus Confidence = Risk
e.g if Impact = 5 & Confidence = 3, then Risk = 2.
Track all this in a spreadsheet and review it every sprint to inform your planning. You should see the Confidence levels go up regularly (as you iterate in response to your user research and other work). Meanwhile, your Risk will automagically go down!
-> Here’s a spreadsheet template you can use in Notion and in Google Sheets.
Decide how much you’re going to test
You might find that you have lots of assumptions, which makes sprint planning long and the end of Alpha impossibly far away. This is where you need to make a call about 2 things: what your maximum risk score is going to be, and how long you can spend in Alpha. Remember that you’ll continue building confidence (and reducing risk) in Beta, but your priority will shift to delivering the minimum viable product, so choose carefully!
If you stick with it, it can create a really compelling case as to why you’ve chosen your focus areas and ultimately end up with a better service for users.
