Most of the time in public sector product management, you aren't presented with a problem space but rather with a predetermined idea of how to fix a problem, often completely skipping past any validation of the problem itself. Ministers, senior leaders and HiPPOs (highest paid person's opinion) stalk this Serengeti of the pre-approved solution and PMs need a way to navigate it, lest they end up just building something rather than the right thing.
Going back to basics and running a discovery to look at the problem space isn't always politically palatable or possible, so how do you interrogate the solution everyone has in mind and validate that what you're thinking about building is going to be desirable, feasible and viable? Why, by using risky assumptions of course! (I feel like you should have seen that coming.)
Risky assumptions testing is an approach to finding, prioritising and validating the most important assumptions you need to look at as a delivery team before you go too far with the development of a product or service. It's a great method to provide a prioritised structure of 'things to do' in a discovery or alpha and a wonderful way to quickly test a brand new big idea, no matter what phase of development you're in.
First, make a big list of things you assume or hypothesise will be true related to building a successful service that is useful, usable and used. Then you score them to find the ones that are most impactful if you're wrong about them (aka most risky), and this gives you have a nice list of what to concentrate on.
All these steps are best run as a group exercise with your multidisciplinary team. At the very least you'll want representatives from product, delivery, design / user research / service design and tech. Depending on how amenable your stakeholders will be to the process, invite them to the workshop or do some light research with them in advance to better understand their view of the potential benefits and their underlying assumptions. If you're working with policy experts or clinicians in your service, definitely try and get them in the room to help you generate as many assumptions to test as possible.
Below I've provided a method for running a risky assumptions session along with some examples from a workshop I ran for a proposed service to let GPs use AI dictation to write consultation notes automatically, allowing them to concentrate fully on talking to their patient.
Write down a list of the hypothesised benefits of your service (e.g. 'We believe that ambient voice technology will improve NHS staff satisfaction, because burnout levels from additional admin tasks will reduce, morale will increase, and staff retention will improve.').
Use the 'We believe ...' format to keep the benefit statements consistent while also reinforcing that they're untested beliefs. Be sure to include benefits that you're sceptical about.
Allow roughly 20 minutes for this. Expect to have around 10-15 benefits listed. Consider not only direct benefits for users of the service but also benefits for the department / organisation and wider knock-on benefits.
Make a list of all your assumptions; the things that need to be true that describe a successful service. Make sure to frame these assumptions positively (e.g. 'clinicians will be able to complete the training necessary to be confident in using the service' rather than 'clinicians won't have time to complete the training'). This is so the scoring system works for every assumption. Frame them positively even if you think you actually assume the negative version!
You want a mix of assumptions relating to user desirability, technical feasibility and organisational viability (time / money / policy / politics). Think about what would need to be true for your service to be useful (does what it's supposed to), usable (users know how to use it successfully, including users with accessibility needs), used (will people actually use the service, even if it is useful and usable).
Assumptions can be hard to generate so if you're having trouble, just step through an imagined happy-path only service. I find this usually gets the juices flowing!
For each assumption I like to collect these fields:
Allow an hour to an hour and a half for this step. Make sure you've captured as many assumptions as possible.
Quickly match each assumption to a benefit and note down how many assumptions are assigned to each benefit. This will give you a useful indication of whether any of your benefits are particularly important to validate given they have so many assumptions clustered around them.
This should take about 15 minutes, depending on how many assumptions you've accumulated.
For each assumption you need to score:
This might take longer than you think to find scores that everyone agrees on. How long this takes is highly dependent on your team and how many assumptions you need to score.
Apply the algorithm! To generate the risky assumption score for each item, multiply the impact score by 10 minus your confidence score.
So that's: [impact] X [10 - confidence]
This will give you a score for each assumption of between 0 and 100.
Show off your mental maths skills, or use a calculator, to get this done in a few minutes.
I'm sure you're way ahead of me but you now have a prioritised list of assumptions, with the highest scoring ones being the items that you not only don't know much about but also will have a massive impact on the success of your service.
But don't panic (© Douglas Adams), now you can do something about it!
Have a look at your scored list and decide on a threshold for assumptions to take forward for validation. I usually find I have around a dozen items scoring over 70 and those are the ones I'll typically bring in for further work.
I would also discuss as a team whether there are any low scoring items that you want to bring into your final pool. In my example the assumption 'Clinicians not taking notes improves the patient experience' had scored a lowly 12 because the impact of us being wrong was low (if we're wrong the experience is as good as it is right now, which is fine for most people) and our confidence was high, having done some research in this area already. However, I knew that, at the time, the Treasury only wanted to fund NHS initiatives that improved the patient experience so we brought this one in for validation so we could build some more evidence to help secure funding.
These five steps above will take around 3.5 to 4 hours total.
Now you have your list of what assumptions to validate the next step is to play this back to stakeholders for a double check on your proposed direction and then run a separate session (because everyone's definitely had enough of looking at this list for one day) where you start to generate research, design, tech and product activities to validate each assumption. But that, dear reader, is a story for another time.
Published 2026-03-24