Field Guide / Getting Started

Section 02 · orient

Four starting points, each with a different practice.

A problem, an opportunity, a pre-defined solution, or an imported model. Each needs a different first move. Misreading the starting point, usually by assuming a solution is the brief, is the most common mistake teams make.

Starting point classification

Four ways an initiative begins.

01

Problem to solve

A known pain point, operational issue, performance gap, or friction.

What is happening, why, and is it worth solving?

Next practice → Current-state diagnosis
02

Opportunity hypothesis

An improvement area or opportunity space, with a loose sense of direction but no settled solution.

What opportunity might exist, and what evidence would make it worth exploring?

Next practice → Current-state diagnosis and opportunity shaping
03

Pre-defined solution

A tool, process, platform feature, vendor solution, or pilot someone already wants to test.

What must be true about the current state for this solution test to mean anything?

Next practice → Current-state risk scan and solution assumptions
04

Imported model or transferable practice

A model or practice that works elsewhere and might transfer to your organisation.

What conditions made it work there, and do those conditions exist here?

Next practice → Risk scan or diagnosis, depending on maturity
Fig. 06
Problem to solve Opportunity hypothesis Pre-defined solution Imported model classify, then route Problem-led Current-state diagnosis Solution-led Current-state risk scan
Four doors, two practices. Problems and opportunities route to diagnosis. Pre-defined solutions and imported models route to a risk scan. Both still begin with the current state, the difference is how much you build first.

Current-state versus solution-side logic

Do not diagnose a problem with solution lenses.

Problem-led work uses current-state diagnostic categories. Solution-led work uses the five evidence facets. Collapsing the two is a classic error.

Problem-led · current-state categories

  • Performance and baseline
  • Problem pattern and variation
  • Cause and mechanism
  • Operational flow and work reality
  • Stakeholders, jobs, and decision rights
  • Systems, data, and tooling reality
  • Operating context and constraints
  • Materiality and value at stake
  • Behavioural and change conditions

Solution-led · five evidence facets

  • Need / Desirability
  • Operating design / Operational feasibility
  • Technical build and integration / Technical feasibility
  • Value case / Viability
  • Adoption and sustained use / Adoption readiness

Reaching for these too early diagnoses a problem you have not yet understood.

Fig. 07
Problem-led toolkit Diagnose the problem 9 current-state categories cause · flow · systems · behaviour Solution-led toolkit Validate the solution 5 evidence facets desirability · feasibility · viability once the problem is clear the classic error
Two toolkits, in order. Diagnose with current-state categories, then validate with solution facets. Reaching for the facets while the problem is still unclear is the most common way teams test the wrong thing.

The quality gate

The Bet Brief comes before a team is engaged.

The Bet Brief does not answer everything. It makes clear why the bet exists, what kind of bet it is, what is known, what is assumed, what is missing, who to learn from, and what decision the next work should support.

Decision rule. A solution or model already on the table is not a neutral problem brief. Name the solution and run a current-state risk scan.

See the Bet Brief structure →
Next Section 03
The Practice →