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.
Choose an outcome→02
Expose the gap→03
Run a test
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
- Outcome: a meaningful change in the customer or operating experience.
- Current condition: observed examples of the gap, with dates and sources.
- Working explanation: why the gap may exist, including uncertainty.
- Experiment: the smallest useful change you can arrange.
- Owner: who will coordinate the test and the dependencies.
- 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.
Primary reference
Lean Enterprise Institute: Hoshin Kanri ↗. Consulted 4 October 2026. Procedures and training examples above are editorial proposals; examples are illustrative and are not claimed business results.