Section 01 · the model
What the work is, and what counts as progress.
Progress is movement in two things only: the solution, and the confidence we have in it. Activity that moves neither feels like progress and is not. Everything in this guide serves those two.
What the work is
Two kinds of guide.
The other guides
How to do the work. The step-by-step practice for problem-led discovery and solution-led risk scans: playbooks, methods, templates.
This model
What the work is. The thinking the playbooks rest on: the quality of the solution, and the confidence we have in it. Nothing else is the goal.
In a Solve cycle
We start in one of two places.
Inside Solve, the practice depends on where the initiative begins. Reading this wrong is the most common mistake teams make.
A pain point, gap, or opportunity
No solution yet. Do not jump to one. Work out the real problem worth solving, then develop and test concepts. Skip this and you build a strong solution to a problem nobody has.
A tool, feature, or process change
It arrives with a hypothesis attached. Extract what must be true for it to deliver, then test the riskiest of those beliefs first. We do not run the solution to see what happens; we surface the beliefs it rests on.
Building to learn
Often, building is the test.
Developing confidence does not mean avoiding building. It means building the right thing, at the right fidelity, for where you are. There are two kinds.
Throw-away prototypes
Cheap, fast, disposable
Used early in Solve while searching for the right solution. They prove one thing, then get binned: for example, whether an AI can hit an outcome consistently before you commit to anything.
Working prototypes
Production-faithful, in a sandbox
Once committed to a real solution, build incrementally, as close to production patterns as possible, off production. Each increment proves an assumption and contributes a real component. We never build it twice.
The build cycle has a deliberate shape
Build the foundation
Stand up the production-faithful sandbox everything else gets built on.
Build by criticality
Build the feature for the most critical assumption, move it to Demonstrated, then take the next. Order follows priority, not a roadmap.
Stitch it together
Pieces accumulate instead of getting thrown away, leaving a coherent prototype ready to test at scale.
Setting the target
Confidence is not pursued to infinity.
Not every assumption needs Confirmed at scale. That would be slow, expensive, and pointless. Agree the target with the sponsor up front, on two levels:
1 · The level the decision requires
A small, low-risk change may need only Demonstrated. A large, costly, network-wide commitment needs Confirmed at scale.
2 · The level you target next cycle
Which assumptions move, and to what level, in the time you have. A concrete commitment for the cycle ahead.
This keeps the work honest both ways: no under-testing a big bet, no over-testing a small one.
The decision rhythm
The recommendation happens at the end of a cycle.
We work in time-boxed cycles to validate or invalidate a set of critical assumptions. At each boundary, the team makes one of three calls.
Continue
Testing confirms the direction, but critical assumptions remain. Keep investing. Resolves into another cycle, or a trial once testing supports in-field validation at scale.
Pivot
Learnings show the solution needs rethinking. The problem may still stand; this solution, in its current form, does not.
Stop
Something is not desirable, feasible, or viable, and it cannot be solved or it kills viability. Off-ramp, with the learning banked.
At the end of a trial
Scale, do not scale, or send back to innovation. A trial is not designed solo: it needs the future owner, commercial finance, and operations governance, against the operations governance model.
The one thing to remember
Develop solutions worth backing, and an honest recommendation on whether to keep investing.
The five categories, the prioritisation, the prototypes, the confidence levels, the phases: each one exists to serve that single outcome.