Connect a strategic goal to a testable change

Read the diagram as text

Connect a customer outcome to an observable gap, a bounded experiment and a review. Return the evidence to the strategy discussion instead of treating a plan as proof of progress.

A strategy statement is useful when somebody can explain how today's work contributes to it. If a team cannot describe that connection, adding more status slides rarely solves the problem. Make the chain visible: the outcome you seek, the current gap, the change you will test and the evidence needed for the next decision.

Start with a customer outcome

Consider an illustrative digital service where customers repeatedly contact support after submitting a request. “Launch a new portal” names a project. “Help customers understand whether their request has been accepted” names a need. The portal might help, but so might a clearer confirmation message or a simpler process. Keep the desired outcome separate from the first proposed solution.

Describe whose experience matters and what boundary the team can influence. If a confirmation depends on an outside approval, name that dependency before promising a target. A broad strategic goal should not become a delivery commitment through a chain of optimistic assumptions.

Build a one-page connection map

1. Outcome: a meaningful change in the customer or operating experience.
2. Current condition: observed examples of the gap, with dates and sources.
3. Working explanation: why the gap may exist, including uncertainty.
4. Experiment: the smallest useful change you can arrange.
5. Owner: who will coordinate the test and the dependencies.
6. Review: when, with what evidence, and which decisions remain open.

Discuss the plan in both directions

Leadership can explain why an outcome matters and the constraints around it. People doing the work can explain feasibility, competing demand and what they have observed. The exchange should change the plan when new information appears. A meeting that only distributes pre-agreed numbers does not expose these trade-offs.

Hoshin Kanri, as explained by the Lean Enterprise Institute, connects strategy and execution across organizational boundaries and uses structured learning. This guide proposes a compact connection map for a digital team; it does not claim that one document implements a whole management system.

Illustrative experiment

Suppose a team reviews recent requests and finds repeated questions about whether submission succeeded. It proposes clearer confirmation text for one request type. The experiment owner records the existing message, the proposed message, affected users and the period of observation. The team watches the questions that follow and checks whether the clearer message introduces an incorrect expectation about approval. It will decide whether to expand, revise or revert the message after that review.

No improvement percentage belongs in this example: it has not been run. For a real trial, retain the observations behind the conclusion. If demand changed or a support campaign ran concurrently, record that context instead of attributing every change to the new message.

What to bring to the review

Outcome and reason it matters:
Observed gap and source:
Experiment and proposed mechanism:
Owner / dependencies / review date:
Evidence supporting or challenging the mechanism:
Decision: retain / modify / stop / gather more evidence

Link the map to an A3 when the gap needs deeper investigation. Read the historical Hoshin Kanri article and the surviving presentation in the resource library. Keep strategy connected to actual work rather than treating the archive's old events or examples as current offers.

Write the decision you will make if the experiment disappoints

A review date is useful only when the team knows what evidence to bring and what would change the plan. Extend the strategy map with a stopping rule. This invented service example is editorial teaching material, not a result or a new account of Richard Durnall’s work.

1. Choose one outcome and the observation behind the gap. Define the denominator and time window before setting a target. Keep waiting time separate from processing time and avoid inventing a baseline from memory.
2. Write a proposed mechanism: what small change should affect which part of the work, and why? Name a counter-observation that would challenge that explanation. A target is not a test design.
3. Agree the review evidence and a guardrail. Include unintended effects and changes in demand. Use the same definitions across periods; a favourable count with a different denominator is not a comparable result.
4. Choose among continue, change, stop or collect more evidence at review. Preserve the original prediction so a disappointing result cannot be edited into an apparent success. Share the decision with affected people.

Field	Example or check
Fictional change	Add an explicit “next action” line to a small service’s acknowledgement message, hoping to reduce repeated clarification contacts.
Evidence to collect	Number of eligible messages; number of clarification contacts; waiting time definition; whether recipients misunderstood the action. No observations have yet been collected.
Counter-explanation	A different case mix or a support campaign could change contact counts. Log those changes rather than attributing the whole difference to wording.
Stop / modify rule	If the new wording directs a recipient to an incorrect action, pause it and correct the message even if the raw contact count falls. If observations are too few, report insufficient evidence.
Review card	Outcome __; baseline source/window __; change/mechanism __; disconfirming observation __; guardrail __; review owner/date __; evidence __; decision __.

Hoshin provides an alignment context; this card makes a small proposed change reviewable. It does not claim a statistically established improvement or replace investigation of the actual work.

Download the worksheet ↓

Sources: Lean Enterprise Institute — Hoshin Kanri