How to Scope Non-Goals in Technical Specs

Every spec review I've been in where scope crept mid-implementation had the same root cause: the non-goals section was missing, or it was written so vaguely it meant nothing. Non-goals turn unstated assumptions into documented decisions. And documented decisions can only be changed deliberately, not silently.

Published on 2026-02-18 · ✓ Updated 2026-03-25 · 6 min read · Author: Daniel Marsh · Review policy: Editorial Policy

What non-goals actually are

In a technical spec, non-goals are an explicit list of things this feature is not going to do. Not "things we might do later" or "things out of scope for now" — but things the team has made a deliberate decision to exclude, and has written that decision down.

The difference between an unstated assumption and a written non-goal is accountability. An unstated assumption can be challenged at any point by anyone who holds a different assumption. A written non-goal is a decision that can only be reopened through a documented scope change. That shift is what makes non-goals one of the most valuable parts of any spec.

Why non-goals prevent scope creep

Scope creep doesn't usually happen because someone makes a bad decision. It happens because the boundary was never clearly defined, so different people draw different mental lines and add requirements that feel natural to them. By the time the team notices, implementation is underway and course correction is expensive.

A non-goals section is a scope boundary written in the spec, agreed to during review, before implementation begins. When a new requirement surfaces during development, the question shifts from "should we add this?" to "should we change the approved scope?" That reframe has different weight. It triggers a deliberate conversation rather than a quiet addition.

Where non-goals belong in the spec

Non-goals should appear near the top of the spec, immediately after or alongside the goals section. This placement is deliberate. A reviewer who reads the goals and then immediately reads the non-goals has the full picture of what the feature is and is not trying to accomplish before they reach any implementation details. Burying non-goals at the end of the document means many reviewers will never reach them.

# Feature: User Notification Preferences

## Goal
Allow users to control which types of email notifications they receive.

## Non-Goals
- Push notifications (mobile or browser) — not in this release
- Notification frequency controls (e.g., digest vs. immediate) — deferred to v2
- Admin ability to override user preferences — requires separate access model
- SMS or phone call notifications — outside this product's current scope

## Acceptance Criteria
...

The non-goals section here is positioned so that any reviewer understands, before reading a single acceptance criterion, what this feature will not handle.

What makes a good non-goal

A useful non-goal has three characteristics. It is specific enough that a reviewer cannot misinterpret it. It explains the reason for exclusion (at least briefly). And it distinguishes between "not in this release" and "not in this product" — these have very different implications for how the feature is architected.

Weak non-goals (too vague):
- "Advanced features are out of scope"
- "Performance optimizations not included"
- "Admin functionality excluded"

Strong non-goals:
- "Bulk operations (selecting >1 item at a time) are excluded — single-item
  operations only in this release. Bulk support is tracked in [ticket ref]."
- "We are not adding caching in this change. Latency is acceptable at current
  traffic volume. Caching can be added independently later."
- "Admin impersonation of users is excluded. It requires a separate audit log
  implementation that is tracked but not yet scheduled."

Non-goals vs. future work

Some non-goals are genuinely "never" — the feature does not belong in this system. Others are "not now" — the team has chosen to defer the work. Both are valid, but they are different, and specs should distinguish between them because the distinction affects how the current implementation is designed.

If a non-goal is "never for this product," the implementation does not need to leave room for it. If a non-goal is "deferred to next quarter," the current implementation should avoid architectural decisions that would make that future work harder. Writing "deferred — see [linked ticket]" signals to the engineering team that extensibility in that direction has value.

Common mistakes when writing non-goals

The most common mistake is writing a non-goals section that lists only the things nobody would have assumed were in scope anyway. That is not a useful non-goals section. The valuable non-goals are the adjacent features and capabilities that a reasonable reviewer might assume are included. Those are the things that need to be explicitly excluded.

The second common mistake is writing non-goals that are really just scope limitations stated negatively. "We are not supporting Internet Explorer" is not a non-goal — it is a browser support decision that probably belongs in the technical constraints section. A non-goal is a feature or capability that has been deliberately deferred or excluded, not a technical constraint.

Non-goals in a spec-first workflow

Write the non-goals section first, not last. The process of writing it answers a productive question: what are all the things a reader might assume this feature does that it actually doesn't? That question surfaces assumptions early — while they're still cheap to address in the document rather than expensive to address in code.

Teams that make this a habit have fewer mid-sprint scope arguments and more focused implementation reviews. It's one of the lowest-cost, highest-value practices in spec writing.

A template for the non-goals section

## Non-Goals

The following are explicitly out of scope for this change:

1. [Feature or capability] — [brief reason: deferred/architectural/out of product scope]
2. [Feature or capability] — [brief reason]
3. [Feature or capability] — [brief reason]

Any changes to this list require a scope change approval from [named decision-maker]
before implementation proceeds.

The final line matters: it names who owns scope decisions. Without a named decision-maker, the non-goals section is advisory rather than binding. With one, it creates an explicit gate — scope doesn't just expand, it gets reopened.

Non-goals as constraints for AI code generation

When a spec is used as a prompt for an AI coding tool, the non-goals section does something specific: it prevents the AI from adding features that look natural but were not requested. AI tools fill gaps based on what is common in similar codebases — which often means adding capabilities that are adjacent to the spec's goal but outside its agreed scope.

A non-goals section like "we are not adding bulk operations in this release" prevents the AI from generating a bulk delete endpoint alongside the single-delete endpoint. "We are not building admin override functionality" prevents the AI from adding an admin bypass route that seemed like a reasonable extension. Without the non-goals section in the prompt, the AI has no signal that these additions are out of scope — and the output will look correct until someone asks why the implementation contains functionality that wasn't approved.

The mechanical advice: include the non-goals section verbatim in the prompt, as a block before the acceptance criteria. The AI treats it as a hard constraint rather than a soft suggestion. Anything explicitly named as a non-goal will not appear in the generated implementation unless the prompt instructs otherwise.