Product foundation

From the product foundation to a verifiable solution

The product foundation is the authorized content that establishes what must be built, why it must exist, what results it must produce, what conditions it must respect and how compliance can be determined. It is not a new kind of document nor a mandatory template. It may be found in a Job Story, a Jobs to Be Done statement, an epic, a capability, a requirement, a business rule, a journey, an acceptance criterion or a coherent combination of these elements.

When the foundation is identifiable

A product foundation is identifiable when development can establish, without inventing product decisions, the following elements. They may be spread across one or several parts of the definition received, and they need not use these names or this order.

Element	Control question	Minimum condition
Source and authority	Where does it come from and who may modify it?	Traceable origin and recognized authority
Reason	What situation, need, problem or opportunity does it address?	Justification that is understandable without the solution
Result	What change or progress must it produce?	A result recognizable to people or to the product
Conditions and limits	What rules, constraints and exclusions must be respected?	Limits sufficient to prevent silent decisions
Evidence	How will we know it has been met?	Criteria, observations or tests proportionate to the risk

The absence of a specific section or field in the PRD is not in itself a defect. The method must understand the structure the product uses. If a definition capable of materially changing the solution is missing, the agent must surface the gap and refer the matter to the corresponding authority; it must not fill it in through a silent inference.

Full scope and product authority

When an approved product definition contains multiple stories, capabilities, rules or specifications, all of them form part of the scope unless the definition itself or an authorized decision establishes otherwise. The development plan must understand the whole, resolve its relationships and dependencies and ensure its coverage. It may break the work down, order it, group it or run it in parallel; that breakdown does not modify the scope.

The plan organizes how the scope is implemented. It does not silently decide which part of the scope deserves to exist.

• Every omission, modification or deferral must be explicit, traceable and approved by the product authority.

• If constraints of time, resources or technology prevent covering the scope, the plan must make the incompatibility visible and request a decision.

• An incremental, phased or release-based strategy may be used where the project adopts one; it is not an obligation of the core.

• Completeness is determined by reconciling the implementation and the evidence against the complete product definition and its approved exceptions.

This manifesto uses Job Stories as a reference form for showing how a product foundation can be carried through to design, implementation and verification. Job Stories make the circumstance, the motivation and the expected outcome explicit, which makes them a particularly useful representation for reasoning about human progress.

Their use in the explanations, rules, examples and tests does not require every product definition to be expressed through Job Stories, nor does it authorize automatically transforming a PRD into that structure. Where the definition uses another form, the method must preserve its meaning, its relationships and its authority. A derived Job Story may be proposed as a working view where it adds clarity, but it does not replace the source nor acquire authority by having been generated.

From Jobs to Be Done to Job Stories

Jobs to Be Done and Job Stories serve different functions. Jobs to Be Done maintains the product's direction: the broad progress that leads a person to adopt a solution in their life or work. The Job Story narrows that progress down to a concrete situation that can guide a design decision, an implementation and a test.

When this form is used, each Job Story must retain an explicit relationship to the corresponding higher-level job, purpose or outcome. That relationship prevents an isolated story from losing the product's direction.

Relationship between the levels

Level	Defines	Avoids
Jobs to Be Done	The broad progress the person is seeking to achieve	Organizing the product around features
Job Story	The circumstance, motivation and outcome that trigger a concrete need	Designing from generic roles or literal requests
Product response	The system behavior chosen to address the story	Confusing the problem with the first solution imagined
Acceptance evidence	The observation that demonstrates progress in that circumstance	Accepting a delivery because it works technically

Canonical form of a Job Story

When an observable circumstance occurs, I need to make progress without prescribing the solution, so that I can reach a recognizable outcome.

When. Describes the fact, change or tension that triggers the need. It must be observable or recognizable without depending on a fictional persona.

I need. Expresses the motivation, understanding or decision required. It does not name a screen, a button, an agent or a feature.

So that I can. Defines the improved situation the person is seeking to reach, and which will later have to be verified.

Minimum evidence accompanying the story

The sentence guides the conversation, but it does not replace research. A story ready to guide development must record only the evidence needed to support its decisions.

Element	Question	Minimum content
Current behavior	What does the person do today?	Observed steps, workaround or abandonment
Obstacle or anxiety	What holds progress back or makes it risky?	Relevant doubt, cost, fear, effort or dependence
Causal evidence	What supports the link between circumstance and motivation?	Observation, interview, usage data or a declared assumption
Evidence of success	What would demonstrate that progress occurred?	Observable behavior or outcome within the circumstance

When role still matters

Job Stories avoid using role as an automatic explanation. They do not eliminate real differences between people. Role, experience, age, permissions or a physical constraint must be incorporated when they causally change the circumstance, the risk or the valid solution. If they do not change the decision, they must not govern the story.

Quality tests before designing

• The circumstance describes a concrete trigger and not a category of user.

• The motivation expresses progress or understanding and not a requested feature.

• The outcome can be recognized without confusing it with completing the product's flow.

• The story is backed by evidence, or it clearly identifies the outstanding assumption.

• The formulation allows several responses to be compared, including the option of not building.

• The scope is sufficient to change a decision, but does not attempt to contain the user's entire work.

Chain of traceability

Development must be traversable in both directions: from each implemented decision back to the product foundation that justifies it, and from the complete product definition forward to the evidence that demonstrates its coverage. Where the foundation is expressed through Job Stories, traceability must preserve the circumstance, the motivation and the outcome of each applicable story.

Origin	Decision	Verification
Product definition	What must be built and under what conditions	Every mandatory element has coverage or an approved exception
Jobs to Be Done	What general progress deserves attention where this form applies	The outcome remains relevant to the person
Job Story	What concrete circumstance must be addressed where the source uses this form	The story is validated and does not prescribe an unauthorized solution
Design and implementation	What behavior responds to the foundation	Every element has a traceable reason
Acceptance	What evidence authorizes declaring the development complete	Results, rules and criteria are met under the defined conditions