The most important point comes first. This record does not argue that accumulating requirements is wrong and that a core-domain approach is right. They are different types of organization, with different purposes, and both become a problem when missing. In practice, one is available only as material for verifying the other. Read it without that premise and it can look like a dismissal of a particular role or a particular person’s method. That is not the intent.
Why this record exists
In SaaS product work, the same situations keep appearing.
- A list of requests by customer or industry is assembled, yet the discussion never converges
- Each added request changes the spec, until no one can explain who the feature is for
- The question “is anything missing?” continues without end
This is not a matter of individual ability. It happens structurally when the type of organization does not match the situation. This record names the two types and explains why, in SaaS, the order of work changes.
Two types of organization
| Aspect | Accumulating requirements | Starting from the core domain |
|---|---|---|
| Question | What is being asked for? | What is essential to this work? |
| Output | A set of requests and features (a list) | Concepts and rules (a model) |
| Check for correctness | Are the stated items included? | Can unknown cases be placed? |
| Greatest risk | Omissions | Abstraction drifting from real work |
| Strongest when | The customer is fixed and their requests must be fully met | The set of targets keeps growing and the product will be operated for a long time |
The accumulation type has a clear strength: it can meet the requests of the customer in front of you without omission. In domains where a gap is immediate failure, listing everything first is the only serious order. The completeness of people trained in that work is not something I can easily copy; my own habit is to start from structure.
In SaaS, a feature that ships continues to be maintained. That is why an axis for deciding “include / exclude” is needed first, and that axis is the structure of the business.
How a list differs from a model
This is the crux. If “decide the core domain first” has become “make a must-have feature list first,” it is still accumulation with a different order, and the result does not change. The fork is whether you are making a list or making a model.
| List | Model | |
|---|---|---|
| Contents | A sequence of requests and features | Concepts and the relations and rules among them |
| New requests | Debated from zero each time | Placed against the model |
| Meaning of “we will not include this” | Low priority (we will include it someday) | Not a concern of this layer (absorbed elsewhere) |
| How it fails | It cannot be wrong; you can only say whether something is missing | It breaks on a counterexample, and can then be repaired |
| Accumulation | Judgment does not accumulate | One judgment determines the next |
A list can answer only the items already written down. A model can also answer items that have not yet appeared.
Tests for whether you have a model
- The unknown-request test — Bring a request you have not yet heard. Can you say where it sits on the trunk? If not, you have a list.
- The falsification test — Can you ask someone to name a case in which this structure does not hold? If you cannot, it is a wish, not a claim.
The second is especially important. A list can only discuss completeness, so the conversation loops on “is there anything else?” A model breaks when a counterexample appears. Then you repair it. That is progress.
In a discussion, asking for counterexamples rather than completeness clarifies everyone’s role. People who hold the reality of a field or an industry create the most value by producing those counterexamples.
Decision cost
The practical effect shows up here.
- Accumulation — Decision cost grows in proportion to the number of requests. Each new request reconvenes the stakeholders
- Model — Decision cost is concentrated in the first pass; later decisions take roughly constant time
The total cost is paid either way. What differs is when it is paid, and whether it can be reused. For a product operated over a long period, that reusability is where the gap appears.
In practice there is a third check, in addition to the two tests above.
- The decision-cost test — If the number of items doubles, does the time required to decide also double? If it does, you still have a list.
Established frames
Several named ideas already say roughly the same thing. They are listed here so the wheel is not reinvented.
| Frame | Source | What it says |
|---|---|---|
| Core domain / subdomain | Eric Evans, Domain-Driven Design | Identify the area that is the source of competitive advantage and concentrate modeling effort there. Treat the periphery as generic |
| Ubiquitous language | Same | Align on a single definition of terms. If language stays different by customer or industry, the design splits with it |
| Product vs Project / Feature Factory | Marty Cagan, INSPIRED | An organization that implements requests in sequence approaches contract work. A product exists through the judgment of what not to build |
| Jobs to be Done | Clayton Christensen | See the job to be done, not attributes such as industry or size. Industry is only a proxy for the job |
| Configuration over Customization | A general SaaS architecture principle | Absorb customer differences through settings and parameters, not code branches. Branches become permanent maintenance debt |
| 80 / 20 rule | SaaS in general | Hold the common 80% in the product; cover the remaining 20% with configuration, operations, or partners |
Each describes, from a different angle, the value of deciding the trunk first.
Failures worth knowing because the ideas are established
Abstracting too early and missing the domain. Evans himself writes that a model is distilled from concrete domain knowledge. A core domain cannot be made at a desk. Abstract without looking at real work and you get a model so generic that it lands with no one. Do not use this as an excuse to skip gathering specifics.
Abstracting so far that differentiation is lost. In vertical SaaS, depth in an industry is the competitive advantage. Generalize “industry differences are always branches” and you drift toward horizontal SaaS and cut away the strength. How far to share a layer is a design judgment every time; it does not follow automatically from a principle.
Not writing down what you will not decide. If “we will not include this” is never put into language, others cannot tell whether it was excluded on purpose or simply missed. For people who work from the accumulation type, that is the greatest source of unease. Filling in a PRD’s “what we will not focus on” is a device for that purpose.
How the two types divide the work
The two types function as a division of labor, not as opponents.
| Role | What to do | Why that type fits |
|---|---|---|
| Defining the trunk and choosing | Define the structure of the work and decide which layer absorbs what | If more than one person holds the axis, it drifts |
| Gathering specifics | Collect real work by customer and industry without omission, then structure it | People trained in completeness are far faster |
| Falsification | Force the claim “in this case the trunk does not hold” | This is where the accumulation perspective is most valuable |
What matters is that gathering specifics and falsifying are as indispensable as defining the trunk. A model with no counterexample is an unverified model, which is only a belief.
Checklist
Three checks for whether the organization has stopped at a list.
- Is it written in nouns and rules (not a string of feature names)?
- Can an unheard request be placed, and judged as fitting or not fitting?
- Is it in a form where you can ask someone to give a counterexample?
Two things to settle before a discussion starts.
- Did you declare at the outset what will be decided today and what will not?
- Did you tell participants whether you are asking for completeness or for counterexamples?
In short
- Accumulating requirements and starting from the core domain are tools with different purposes. Neither is superior
- What SaaS needs first is not a list of features, but a structure of the business that can serve as a criterion for judgment
- “Fix the trunk first” is not about narrowing requirements; it is about making judgment reusable
- A model is valuable because it can break on a counterexample. That is why the ability to gather specifics and the ability to falsify are indispensable
- How far to share the trunk is not decided automatically by a principle. Treat it as a design judgment each time