Direction — In Practice

Direction gives the team a shared understanding of where to go and why. The guide covers what Direction is. This page covers how to choose.

Relationship Map

Direction cascades. Each step narrows scope:

Vision → Missions → Goals → Domain Check → Issues

Vision:     long-term problem the team exists to solve
Missions:   what the team works towards now
Goals:      next 1-2 concrete outcomes
Domain:     unfamiliar domain or disagreement? Insert exploration here
Issues:     observations from exploration become candidate Issues

The Vision changes slowly. Missions change when the environment shifts. Goals change every cycle. Domain Exploration is inserted only when needed. It does not block the cascade.

Default Path + Branching

Default — stable domain:

Vision → Missions → Goals → Record direction → Begin Issue capture

Domain unfamiliar or team disagrees:

Vision → Missions → Domain Exploration → Goals → Record direction → Issues

Exploration comes between Missions and Goals. Missions define the scope to explore. Goals emerge from exploration findings.

Clear direction from leadership:

Skip Vision/Missions → Define Goals from leadership input → Record → Issues

Pre-PMF or early startup:

Minimal Vision → One Mission → One Goal → Ship → Repeat

No disagreement but unclear boundaries:

Vision → Missions → Goals → Context Mapping only → Issues

Full Event Storming is heavy when the team already agrees. Context Mapping is lighter when boundaries are the only unknown.

Role Map

Technique Table

Procedure Table

Artifact Table

Skip Conditions

Prepare to succeed. Do enough discovery to move forward, then stop. Direction is context for delivery. It does not block work.