Statement
P01 The user's progress is the unit of design
Do not design what the user can do. Design the progress they need to achieve.
Tension
Explanation
A team may deliver many features and solve very little. When work is organized around features or generic profiles, no one has to explain what changes for the person after using the product.
Go deeper: Tension
When work is organized around features or generic profiles, a team can deliver a great deal and resolve very little. A Job Story forces the causality to be spelled out: the circumstance that triggers the need, the tension that drives action, and the better situation that would make progress recognizable. When the product uses another form, that same causality must be preserved to the extent that it applies.
Meaning
Explanation
A capability matters only when it produces a recognizable change for someone: moving from a current situation to a desired outcome. Before designing a response, describe when the need arises, what motivates it, and what outcome would make the progress recognizable.
Go deeper: Meaning
A feature only makes sense if it helps a person move from a current situation to a desired outcome. The product foundation establishes the authorized reason for the development. Jobs to Be Done can define progress at a broad level, and the Job Story makes it operational by describing when the need arises, what motivates the person and what outcome they are seeking, without anticipating the solution.
Consequence
Explanation
Every decision must be traceable to the product foundation that justifies it. A feature request is reframed as circumstance, motivation, and outcome before solutions are discussed, and that framing allows for more than one response, including not building anything.
Go deeper: Consequence
Identify the product foundation and the authorized source that establishes the scope before designing a response.
Where the foundation is expressed through Job Stories, place them within the higher-level progress or purpose to which they belong.
Formulate each Job Story as circumstance, motivation and outcome, without naming a screen, a component or a feature.
Ground decisions in observed behavior, the current obstacle or anxiety, and evidence that supports acceptance of the outcome.
Example
A request arrives as “add an export button.” Reframed, it says: when someone has to present their data to another person, they need to take it out of the tool without redoing the work. This framing allows for a button, a sharing link, or an automated report, and makes it possible to choose the response that adds the least load.
Counterexample
Describing a site as a collection of pages or effects. The list of what it contains does not reveal what understanding or capability someone gains by going through it.
Sign of non-compliance. “As a student I want to receive hints to solve derivatives” looks like a useful story, but it begins with a role and prescribes a feature. It does not explain when the blockage arises, what the person needs to understand, or how to recognize that they have regained momentum.
Decision test
A decision is ready when these questions have answers supported by evidence, not intuition.
Can the authorized source that justifies this decision be identified, together with its relationship to the full scope?
Where a Job Story exists, is the circumstance specific and observable, or does it merely describe a role?
Are the motivation and the outcome backed by evidence, or were they assumed by the team?
Does the formulation admit several possible solutions? If it already prescribes an interface without that being a product decision, it must be revisited.
Source
Manifesto core v2.1, section PRINCIPLE 1 · P01. Download the core