Teams working on complex digital services often waste months pursuing ideas that look promising but rest on untested assumptions. A method built around ranking the riskiest assumptions first offers a way to catch these failures early, before they become expensive. The approach has grown out of government digital service design, but its logic applies anywhere teams must decide what to build with incomplete information.
Why familiar prioritisation frameworks fall short
Methods such as MoSCoW, impact versus effort matrices, or RICE scoring work well once a team already has confidence in its solution and simply needs to sequence improvements. They assume a backlog already exists and that the main job is ordering it sensibly. That assumption breaks down in early-stage, high-uncertainty work, where the real danger isn't picking the wrong feature to build next - it's discovering, too late, that the whole direction was wrong. Hypothesis-based prioritisation, ranked by impact and effort, helps frame experiments but tends to stay narrowly focused on features. It misses other common causes of failure: weak trust between stakeholders, slow feedback loops, or delivery that can't keep pace with learning. When prioritisation methods ignore these factors, exploratory work drifts, loses focus on value, and quietly turns into a failed investment.
What changes when assumptions are ranked by risk
Scoring assumptions by risk gives teams a consistent way to compare very different kinds of uncertainty - technical, organisational, behavioural - on the same scale. In an unclear problem space, it's usually a handful of big assumptions that will make or break the work. Testing those first reduces uncertainty early and lowers the cost of failure, because the team learns what doesn't work before committing significant development time, rather than after launch. The value increases further when the evidence behind each assumption is made visible and open to challenge, in line with the principle that openness improves outcomes. Done as a group exercise, scoring assumptions together tends to:
- build a more shared understanding of the problem among team members
- expose gaps or imbalances in what different people know
- surface honest concerns, which strengthens psychological safety
- produce a team more invested in the direction it has chosen
Knowing when this approach isn't worth the effort
Riskiest-assumption testing adds less value in smaller, better-understood problem spaces - for instance, refining an existing service already in public beta or live operation. By that stage, the service's value should already be established and the team should share a common view of the remaining problems and opportunities. Applying a heavyweight risk-ranking exercise there is usually unnecessary; simpler, faster methods do the job better.
Where the method has proved its worth
The clearest value shows up in a few recurring situations. When a stakeholder arrives already attached to a specific solution, naming and testing the assumptions behind it - framed respectfully as "what we know so far" - can open a more honest conversation and widen the scope of discovery before resources are committed. When risks aren't obvious, structured sessions that map user needs and desired outcomes, then interrogate the assumptions behind proposed solutions, turn vague ideas into testable questions. And when an alpha phase feels too large to tackle at once, scoring assumptions as a team for impact and confidence - then checking those scores with stakeholders - helps decide where the work should actually begin, ruling out weak approaches before significant effort goes into them.
The method is still evolving in practice, and teams adapt it to their own context. What stays constant is the underlying discipline: find out what could sink the project, and test that first, rather than the parts that feel easiest to build.