Assumption vs Requirement
A requirement is something somebody asked for. An assumption is something the design takes as true that nobody asked for. They look identical in a spec — "orders are in one currency" could be either — and confusing them means either building for a future that was never promised or treating a promise as if it could change.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
A sentence in the spec says the store handles one currency. Is that a requirement someone will hold you to, or an assumption you made to ship — and how do you tell, and why does it matter?
The document says "V1 supports a single currency" and "customers must have an account to order". I wrote both. Now the founder wants guest checkout and I am not sure whether I am changing a requirement, dropping an assumption, or breaking something someone else relied on. They are the same kind of sentence on the page.
Treat everything in the spec as a requirement. It was written down, it was agreed, and building to it is what building to spec means. Anything that changes is a "requirement change" and gets an estimate.
Requirements and assumptions get the same weight, so the design defends the assumptions as hard as the promises. "One currency" is held with the same rigidity as "a payment never happens twice", and when the founder wants a second currency the answer is "that is a requirement change" for something nobody ever required.
- Requirements and assumptions get the same weight, so the design defends the assumptions as hard as the promises. "One currency" is held with the same rigidity as "a payment never happens twice", and when the founder wants a second currency the answer is "that is a requirement change" for something nobody ever required.
- The reverse also happens: something a customer was promised — accounts required, because the legal team needs an identity per order — is treated as a simplification that can be dropped for guest checkout, and the promise is broken by an engineer who thought it was theirs to relax.
- Estimates come out wrong in both directions, because the cost of changing an assumption depends on its dependents and the cost of changing a requirement depends on who promised it, and a spec that does not say which is which cannot tell you either.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- For every constraint the design rests on, ask two questions: who asked for this, and what happens if it stops being true? A requirement has an owner — a person or a rule that would object if it were dropped — and dropping it breaks a promise. An assumption has no owner; it was taken as true because it made something simpler, and dropping it breaks the things that depended on it, not a promise (Requirement Discovery).
- Ask the third question for the ones with no owner: could it be true by accident? "One currency" may be an assumption today and a requirement tomorrow because the finance team's reporting depends on it; "customers have accounts" may look like a simplification and be a legal requirement. The status is discovered by asking, not inferred from the sentence.
- Record the answer next to the constraint. Requirement: owner, reason, what breaks if dropped. Assumption: why it was made, dependents, what would make it false (Making Assumptions Explicit). The same sentence lives in one of two lists, and the list decides how the design treats it: a requirement is enforced and tested; an assumption is isolated so that it is cheap to drop.
- When a change arrives, the first thing to determine is which list it touches. Dropping an assumption is a design change with a known cost; changing a requirement is a conversation with its owner first. Confusing them costs either a needless negotiation or a broken promise (Goal vs Implementation).
The same worry, asked three ways
The vague form is what the engineer thinks when the founder mentions guest checkout. The best form names the constraint, asks who would object, and asks what depends on it — which is enough to decide whether the change is a design task or a negotiation, and enough to know who to talk to first.
why The best form can be answered by a named person and produces both the constraint's status and the change plan; the vague form can only be answered "probably", and the middle form finds the status but not what the change would touch or what would satisfy the owner.
Telling them apart
The matrix is the sort applied to the store's constraints. The middle columns are the questions; the last column is what the design does differently depending on the answers. Two of the rows changed status during the conversation that the move requires — which is the point of having it.
| Constraint | Who asked? | What breaks if dropped? | Status | Design posture |
|---|---|---|---|---|
| A payment never happens twice | the customer, the provider, the law | money and trust | requirement (and invariant) | enforced at a chokepoint, tested with the retry |
| Customers must have an account | the founder, for legal identity per order | a legal obligation | requirement | enforced; guest checkout is a negotiation about what satisfies identity |
| Single currency | nobody — the engineer, to keep price a number | finance reporting, as it turns out | assumption with an owner-in-waiting | isolated: money type at one chokepoint; flips locally |
| One warehouse | nobody — there is one | nothing; someone would celebrate | assumption | isolated; dependents listed; expected to flip |
| Products have one price | nobody | nothing today; a B2B tier would | assumption | not isolated yet; noted, revisited if a tier is proposed |
What to do with each kind
The decision below is what the lists are for. A constraint's status decides how the design holds it, and holding an assumption like a requirement or a requirement like an assumption are the two failures this lesson exists to prevent.
A constraint the design rests on has been sorted. What does the design do with it?
when Someone would object if it were dropped and dropping it breaks a promise, a contract or a law.
cost Changing it later is a conversation with the owner before it is a design task; the design is deliberately rigid here.
when Nobody asked, it simplified V1, and a plausible requirement within the life of the system contradicts it.
cost A small abstraction paid now — a money type, an origin lookup — for a change that may not come.
when Nobody asked and no plausible change contradicts it soon; isolating it would be abstraction for its own sake.
cost If it does flip, the change is found by reading code — but the record at least says where to start.
when It looks like a simplification but a legal, finance or contractual owner might exist.
cost A conversation, and possibly the loss of a freedom the design was enjoying.
How to do it
Most important first.
- List every constraint the design depends on, in one column. Do not sort yet.
- For each, name the person or rule that would object if it were dropped. If nobody, it is an assumption until someone claims it.
- For each assumption, ask whoever asked for the system whether it is secretly a requirement. This is a short conversation and it changes the design's posture toward the constraint.
- For each requirement, write what breaks — a promise, a law, a contract — if it were dropped. That is the cost of the future conversation.
- Design differently per list: enforce and test requirements; isolate assumptions behind a chokepoint so that dropping them is local (Framework Independence).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- "V1 supports a single currency." Who asked? Nobody — it was written by the engineer to keep price a number. Would anyone object if it were dropped? The finance team, it turns out, because their reports assume one currency for the first year. Status: assumption with an owner-in-waiting; recorded as "assumption now, requirement for finance until reporting is multi-currency", and price is isolated as a money type at one chokepoint so that the day it flips is a local change.
- "Customers must have an account to order." Who asked? The founder, and the reason was legal: an identifiable customer per order for consumer-protection rules in the launch market. Status: requirement, with an owner and a reason. Guest checkout is therefore a conversation with the founder about what "identifiable" needs — an email captured at checkout may satisfy it, an anonymous session may not — before anyone changes the cart key.
- "Orders ship from one warehouse." Who asked? Nobody; the store has one. Would anyone object if it changed? No — the founder would celebrate. Status: pure assumption; dependents listed; treated as the most likely constraint to flip and isolated accordingly. The three sentences looked identical on the page and are now in three different postures.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every constraint the design rests on is in one of two lists, and each entry in the requirement list has a named owner and a reason.
- At least one sentence changed lists after a conversation — an assumption that turned out to be a promise, or a "requirement" nobody had actually made.
- The design treats the two lists differently: requirements are tested; assumptions are behind a chokepoint.
- When the founder proposes a change, you can say within a minute whether it drops an assumption or renegotiates a requirement, and what each costs.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?Who asked for this constraint, and what would they say if I dropped it?
- ?If nobody asked, could it still be a requirement somewhere I have not looked — legal, finance, a contract?
- ?Is this constraint tested and enforced because it is a promise, or isolated because it is a simplification — and is that the right posture?
- ?When this change arrives, am I dropping an assumption or renegotiating a requirement, and who needs to be in the room?
What can go wrong
- Every constraint is escalated to its possible owner and the founder spends a day confirming things nobody would ever dispute. The conversation is for constraints that a plausible change could contradict, not for "the store uses a web browser".
- The sort is done once and the lists are never updated. Assumptions become requirements as customers come to rely on them (The Requirements Nobody States) — a currency assumption is a requirement once the finance report is built on it — and the list has to follow.
- Assumptions are isolated so aggressively that the design abstracts everything: a currency type, a locale type, a warehouse type, each with one implementation. Isolation is for the assumptions likely to flip within the life of the system, not for all of them.
- Asking "who owns this?" for every constraint takes stakeholder time, and some of the answers are "I don't know", which is a third state the two lists do not have.
- Isolating an assumption behind a chokepoint costs a small abstraction now for a change that may never come.
- Discovering that a simplification is secretly a requirement removes a freedom the design was enjoying; the honest list is more constrained than the naive one.
- "Requirements are fixed and assumptions are flexible." Both change. Requirements change through their owners, assumptions through evidence; the distinction is who has to agree, not whether change is possible (Requirements Are a Snapshot).
- "If it's in the spec, it's a requirement." The spec is written by engineers as often as by stakeholders, and engineers write simplifications into it to ship. The document's authority does not transfer to every sentence in it.
- "An assumption with an owner is just a requirement." It is a requirement whose owner has not yet claimed it. The useful state is "assumption, and here is who would care", because that person is the one to ask before designing around it.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALAny constraint a design rests on has either an owner or none; the sort applies to a library's API guarantees, a pipeline's schema, and a store's currency alike.
- TEAM-SPECIFICA solo learner building their own store owns every requirement and the sort collapses to "which of these did I decide on purpose?"; on a team with a product owner and a legal reviewer the sort is a conversation, and the value is mostly in discovering who the owners are.
- ILLUSTRATIVEThe finance team's reporting, the launch-market consumer rule and the founder's reason for accounts are invented to show the same sentence landing in different lists; real ownership is found by asking, not by analogy to this example.
Where the depth lives
This domain asks the question and hands the answer off by name.