Surface Assumptions

Assumptions are an essential part of any human-centred change initiative. They are the things we accept as true, or sure to happen, without proof. Change design prototypes usually carry embedded assumptions about their desirability, feasibility and viability. As a leader, one of the most useful things you can do is help your design team surface these assumptions and work with them consciously and constructively.

Start by creating a safe and supportive environment. Surfacing assumptions can feel like criticism of an idea, so frame it as strengthening the concept, not attacking it. Encourage everyone to be curious, open-minded and respectful of each other’s perspectives. Then ask your team one anchoring question: what must be true for our solution to be desirable, feasible and viable?

Ask the questions

Work through each dimension using questions like these.

Desirability — do they want it?

1. 1. Who are the key stakeholders for this solution?
   2. What problem are key stakeholders trying to solve?
   3. How do key stakeholders deal with this problem today?
   4. What stops key stakeholders solving this problem well today?
   5. What outcome do key stakeholders most want?
   6. What would make key stakeholders change what they do now?

Feasibility — can we do this?

1. 1. What’s the hardest part of the solution to deliver?
   2. What legal or regulatory hurdles could stop the solution?
   3. What internal approvals or policies stand in the way?
   4. What would earn leadership support for the solution?
   5. Where will funding for the solution come from?
   6. Why are we the right team to deliver the solution?

Viability — should we do this?

1. 1. How will key stakeholders find and keep using the solution?
   2. How does the solution fit our purpose and priorities?
   3. What else could key stakeholders choose instead?
   4. What would bring key stakeholders back to the solution?
   5. Why would key stakeholders recommend the solution to others?
   6. How will we know the solution is working?

Capture one answer per question

Let each question spark discussion, but ask the team to land on one indicative answer per question. Write it down as a testable statement beginning “We believe that…” — for example, “We believe frontline staff will use this more than twice a week.”

This discipline matters. One answer per question produces a manageable set of assumptions, each precise enough that you would know if it turned out to be false. “Stakeholders will like it” is not a testable assumption. If a question surfaces two strong candidates, ask which one, if wrong, would do more damage — capture that one first.

Sort them on a matrix

Now categorise the assumptions on a simple matrix: how important is each one to the initiative’s success, and how confident are you that it’s true? Confidence should rest on evidence, not team belief — if something is “obvious” but untested, treat it as low confidence.

The four quadrants each suggest a next step:

1. High importance, high confidence. These assumptions matter and are well supported. Build them into the initiative’s foundation.
2. High importance, low confidence. These matter most and you know least. Test them first, through experiments or research, before investing further.
3. Low importance, high confidence. Safe to assume. Note them and move on.
4. Low importance, low confidence. Set them aside for now and revisit later if needed.

Test what matters most

Take the high-importance, low-confidence assumptions into experiments. Design the cheapest, fastest test that will teach you something, and involve users, stakeholders and subject matter experts to gather diverse perspectives on whether each assumption holds.

Working this way focuses effort where the risk actually sits. It helps the team avoid costly mistakes and builds shared confidence that the solution meets people’s needs, can genuinely be delivered, and is worth doing.