Section 03 · how
From a starting point to testable assumptions.
Two playbooks, split on where you start: diagnose a problem, or risk-scan a proposed solution. Use the lightest current-state discovery that avoids testing the wrong thing.
The decision rule
If a current-state assumption being wrong would make the solution test misleading, invalid, unsafe, or wasteful, test it first, or build it into the test design on purpose.
Path A · no defined solution
Starting with a problem or opportunity.
Five steps to understand the current state before solutioning: diagnose carefully, define the problem honestly, then decide what to solve.
Frame the problem or opportunity
A solution-neutral statement, so the team investigates before deciding what to build.
We have observed [issue / opportunity] affecting [people / process / customer / site / team / system], which may be causing [impact].
Create a current-state hypothesis
We believe [current-state condition] is causing [impact] because [reason].
Map the current state
Make it visible first. Pick the artefacts that match the question: current-state journey, process map, service blueprint, stakeholder map, systems map, pain-point map, evidence map. For field operations, include site routines, support-office processes, manual workarounds, exceptions, escalation paths, and seasonal variation.
Generate current-state assumptions
Write what you assume is true about the current state as statements, not questions. A useful one is specific to a stakeholder, process, system, or behaviour; testable; tied to the hypothesis; and important enough that being wrong changes the problem definition.
Write in a testable format
We assume [stakeholder / process / system / behaviour] currently [does / experiences / causes something], which contributes to [impact].
Five diagnostic lenses
Not solution-validation dimensions. Angles for seeing the problem before solutioning.
Need and pain significance
Who is affected, and does the problem matter enough to solve?
Operational reality
How the work happens today, the real process rather than the documented one.
Systems and data reality
Which systems, data, tools, reports, and workarounds shape the issue.
Problem materiality
What value, cost, risk, or opportunity is at stake.
Behavioural and change context
What behaviours, routines, and incentives hold the current state in place.
Path B · solution already proposed
Starting with a pre-defined solution.
Do not restart full discovery. Run a current-state risk scan: check whether the solution test rests on risky, untested beliefs about the current state.
Describe the pre-defined solution
We are testing [solution] to help [users / teams / customers] achieve [outcome] by [how it works].
Articulate the solution hypothesis
If we [introduce solution], then [users / teams] will [change behaviour], resulting in [measurable benefit].
Run a current-state risk scan
Do not assume the solution targets the right problem. For each current-state belief the test depends on, note why it matters and what happens to the test if it is wrong.
Identify two types of assumptions
Current-state assumptions: what must be true about today's problem, process, systems, or behaviours. Solution assumptions: what must be true about the solution working.
Decide what to test before, during, or after
Test a current-state assumption before the solution test if being wrong would make it invalid, misleading, unsafe, or wasteful. Build it into the pilot if the risk is manageable and you can observe it. Defer to scale if it is low-risk and only matters later.
Before
The cause is unclear, the solution may target a symptom, or results would be unreadable without a baseline.
During
The risk is manageable, observation can be built in, and failure would still produce clear learning.
After
Low-risk, does not affect pilot validity, and only matters for scaling.
Developing assumptions from a proposed solution
Five dimensions. Nine steps.
The goal is not to prove the solution right. It is to identify what must be true for it to work, then build confidence through evidence. Every solution rests on assumptions across five dimensions.
Desirability
Do users, customers, or team members want or need this?
Operational feasibility
Can the business operate it effectively?
Technical feasibility
Can we build, integrate, run, and support it?
Viability
Does it make commercial, strategic, or value sense?
Adoption readiness
Will people adopt, use, and sustain it over time?
Three movements: frame the solution and map assumptions (steps 1 to 3), write assumptions and rate evidence honestly (4 to 6), then prioritise, test, and decide what the evidence means (7 to 9).
Write assumptions in a testable format
We assume that [user / system / team / process] will [behaviour / outcome] because [reason].
Specific, testable, linked to one of the five dimensions, tied to the hypothesis, and important enough that being wrong changes the solution or decision. Convert the critical ones into experiments built to move confidence up exactly one level.
After learning
Synthesize the evidence. Decide by path.
Do not stop at updating the confidence rating. Work out what the evidence means for the current state, solution, hypothesis, and next decision. Five ways to act:
Proceed
Evidence supports the assumption strongly enough for the next decision.
Pivot
The problem or need stands; the current solution must change.
Stop
Evidence contradicts the assumption, solution, or value case.
Learn more
Evidence is inconclusive, too limited, or not yet behavioural.
And Scale, once Confirmed at scale produces decision-grade evidence.