Section 06 · check
The shared language, and the traps to avoid.
Definitions, the distinctions teams blur, the twelve mistakes that quietly waste a cycle, and the checklist a manager runs before a readout reaches a sponsor.
Glossary
The shared language.
IXD
Innovation Experience Design. The discipline and practice behind evidence-led operational innovation.
Bet
A problem, opportunity, solution direction, or imported model raised for exploration, captured in a Bet Brief before a team is engaged.
Critical assumption
High risk if wrong, and currently only Assumed. The assumptions with the greatest potential to change the direction of the work. Test these first.
Solve, Build, Trial
The three phases of the arc. Find the solution worth building, build to learn, then prove it at scale.
The five categories
Desirability, operational feasibility, technical feasibility, viability, adoption readiness. Five ways an initiative can break.
6-week cycle
A time-boxed cycle to validate or invalidate a set of critical assumptions, ending in a Continue, Pivot, or Stop recommendation.
Open Studio
The end-of-cycle readout: a narrative recommendation backed by the evidence gathered during the cycle.
Demonstrated
Observed behaviour in realistic operating conditions, in one real site. The first level that counts as behavioural evidence.
For the full evidence scale, Assumed through Confirmed at scale plus Invalidated, see Confidence & Prioritisation.
The lines teams most often blur
Three distinctions worth defending.
Said versus observed
What people tell you in a room is Indicated at best. Demonstrated requires observed behaviour in realistic operating conditions.
Problem versus solution
Problem-led work needs diagnosis. Solution-led work needs a risk scan. Do not collapse current-state diagnosis and solution testing into the same thing.
Risk versus assumption
"Teams may not use it" is a risk. "Frontline teams will use it daily to prioritise" is an assumption: specific, testable, and rateable by evidence.
Field notes
Common mistakes to avoid.
Treating every initiative the same
Problem-led needs diagnosis; solution-led needs a risk scan. Using the wrong practice wastes the cycle.
Jumping to a solution too early
"Teams need a dashboard" pre-empts the diagnosis. Frame the problem neutrally first.
Blindly testing a pre-defined solution
Before piloting, ask which current-state assumptions could make the test misleading if wrong.
Treating the presenting issue as the real problem
"The report is bad" often masks unclear ownership, poor workflow timing, or distrust of the data.
Treating interviews as behavioural evidence
Interviews are Indicated at best. To reach Demonstrated, observe behaviour in realistic conditions.
Mapping the ideal process, not the real one
Map workarounds, skipped steps, duplicate entry, rechecking, and informal handoffs, not what should happen.
Assuming the problem is the same across all sites
Check variation by format, volume, location, staffing model, capability, trading pattern, and season.
Testing too many critical assumptions at once
Focus the next test on the one most likely to change what the team does next.
Prioritising by ease instead of risk
Not "easiest to test, so test first." High risk if wrong and only Assumed makes it critical.
Only focusing on technical assumptions
A solution can be technically perfect and still fail on desirability, operations, value, or adoption.
Treating assumptions as facts
Until tested, assumptions are beliefs. Use the confidence rating to show evidence strength honestly.
Treating Invalidated as failure
Invalidated means a belief was tested and a downstream mistake was avoided. Report it with pride.
For managers
Coaching review checklist.
Run this over a cycle brief or readout before it goes to a sponsor.