The tier where intent becomes buildable. This is where the business context meets the software.
Product — the durable offering
A product is what the business builds and offers, and it is born attached to the product-offering context through which people meet it.
Worth separating the two in your head: the product is the durable thing you make; the operating context is the lens a stakeholder sees it through. The same product looks different to a trial user and to an administrator, and those are contexts, not products.
Journey — the arc through a product
A journey is the arc a stakeholder walks through a product to reach a goal, expressed as branching steps with outcome-conditioned transitions.
It is born attached to exactly one product and exactly one stakeholder, and it later reaches for a goal.
That the journey belongs to a stakeholder rather than a persona is the same distinction as everywhere else, and it does real work here: the arc through onboarding is not the arc through renewal, even for the same person, because the situation is different.
Journey steps are the moments that make up the arc. A step has no life apart from its journey — you add it to one, reorder it, set who performs it, or remove it. There is no free-floating step, because a moment outside an arc is not a moment in anything.
This is not the same construct as a business process in the engineering model. A journey here is about a person's experience reaching a goal. A business process over there is about the system's flow of operations. They describe the same reality from the two sides of the product, and keeping them separate is what lets the experience be designed before the software exists.
User story — the atom that must name its reason
A user story is one capability the business means to build, told from a stakeholder's perspective, in service of an expectation that stakeholder holds.
The sentence:
As a <persona>, when <situation>, I want <capability>, so that <outcome>.
└── narrator ──┘ └── context ──┘ └── declared ─┘ └─ expectation ─┘You author only the middle third. The persona and the situation come from the story's narrator — the stakeholder. The outcome comes from the expectation it serves. You write the capability; the rest is read from links.
That is the structural reason this model is worth the effort:
A story cannot exist without serving at least one expectation — the platform refuses to remove the last one.
So "why are we building this?" has an answer for every story in the system, by construction rather than by discipline. Not because someone enforced a template, but because the alternative is not expressible.
Link rather than restate
A story that spells out "as a branch manager" in its prose keeps saying it for months after the persona was renamed. A story that reaches it by link cannot be wrong.
The same goes for the outcome. Restating it in the story's text creates a second copy that drifts from the expectation it was copied from, and the drift is silent.
The commitment ladder
A story climbs six states, and each one refuses something specific:
| Move | Refuses unless |
|---|---|
| draft → refining | there is a capability statement |
| refining → ready | there is a kind, at least one acceptance criterion, and a size |
| ready → committed | at least one served expectation is active |
| committed → delivered | — the commitment was discharged |
| delivered → validated | a metric measures a served expectation, plus your reasoning |
| delivered → invalidated | the same evidence, opposite conclusion |
Two consequences are worth holding on to.
Commit is a business gate, not a status
It refuses unless a live expectation is being served. So a story that will not commit is telling you something real about the request: the expectation it claims to serve is archived, or draft, or was never agreed to.
That is a much better conversation than the one where the work ships and somebody asks afterwards who wanted it.
Delivered-but-never-validated is the shape of unvalidated build
The ladder does not end at delivered. A story sits there until evidence arrives, and validating it requires a metric that measures a served expectation — plus your reasoning about what the evidence showed.
Most backlogs contain far more delivered-never-validated work than anyone believes, and it is invisible in a tool where done is the last column. Here it is a queryable state, which means somebody can ask the awkward question routinely rather than heroically.
And invalidated is a real, respectable outcome: you built it, you measured, it did not work. Recording that is how the belief underneath gets re-graded instead of quietly surviving.
The orientation walk
From any piece of work, the shortest path to its reason:
- the story — what was committed;
- its narrator — whose perspective it is told from, which gives you the persona and the situation without inferring either;
- the expectation it serves — the promise;
- the goal that expectation proxies — what they were actually reaching for;
- the metric on that expectation — whether this can ever be judged.
Five hops, all links, no interpretation. Doing that walk before starting is the alignment step, and it is cheap.
Working practices
- Write the capability, link the rest. If you are typing a persona name into story prose, you are creating a copy that will drift.
- Check the evidence question before committing, not after delivering.
- Let a story fail to commit. That refusal is the model earning its keep; routing around it by pointing the story at a convenient expectation is how the trail becomes fiction.
- Do not invent context to make a task fit. If the reason is missing, that is a finding to surface, not a gap to paper over.
Read next: Working the model.