Scoping with Non-Goals

The rule

Non-goals carry the most weight. Where a template has a section for what a blueprint will not do, that section is its strongest.

Why non-goals do the work

A list of what something does is unbounded: there is always another behavior to add, and nothing in the list says where to stop. Two people can read the same acceptance criteria and disagree about whether a feature is in scope.

A list of what something won’t do is a decision. It has an author, a date, and a diff. It answers the question that costs money six months later: “wait, doesn’t it handle X?”

## Out of Scope

- Cross-account resume. A shared TV is one device, not one person.

That line stops a plausible feature request being filed as a bug, records the reasoning so the next person can tell whether it still holds, and ends an argument before it happens.

Write it second

Right after the opening section, not last. Once you have written the behaviors you are thinking in terms of what the thing does, and the boundary has gone invisible. Write it while the shape of the problem is still in view.

The question that unsticks people

“What would a reasonable person assume this includes, that it doesn’t?” Every answer is a non-goal. So is every feature you considered and dropped.

What belongs in it

• Adjacent features you deliberately dropped, with the reason.
• Cases you decided not to handle: a class of user, a device, a locale.
• Things a reasonable reader would assume are included. These are the valuable ones.
• Boundaries with other blueprints, as a link: “Ranking is Search Results’s problem.”

What doesn’t

• “Not in v1.” That is a schedule, and it is work tracking. If it is out, say so and why. If it is later, it belongs in a top-level doc.
• “Nice to have.” Either it is promised or it isn’t.
• Things nobody would assume. A hundred non-goals reads as nervousness and hides the three that matter.

Still not a gate

An empty non-goals section is surfaced and offered, not refused. A validator that refuses files gets bypassed, and a bypassed validator flags nothing.

Whose job it is

Adding a behavior is a decision anyone can advocate for. Removing one from scope takes authority. A root with no clear owner accumulates behaviors and loses non-goals, because nobody feels entitled to write the second kind. It shows up in the diff before it shows up in the product. Who owns the product →