Scope: Writing the "Not Doing" List

Scope is two lists. Most PRDs write one of them.

The in-scope list tells a reader what you are building. It says nothing about the boundary, which is the part people actually disagree about — and because it looks complete, nobody notices the missing half until the work is underway and the disagreement is expensive.

This is about the other list: what to exclude, how to find the exclusions worth writing, and how to phrase them so they hold.

What an in-scope list alone communicates

Take a real-shaped line:

In scope: team invitations by email, role assignment, member removal.

Now ask what a reader concludes about bulk CSV import. Or SSO provisioning. Or an approval step before an invitation sends. Or a domain rule that auto-joins anyone with a company email address.

The answer is that they conclude whatever they already expected, because the document gave them nothing to update against. Five readers leave with five slightly different products in mind, all of them compatible with what you wrote, and every one of those differences is a conversation deferred to a worse moment.

Why the fight arrives after approval

The mechanism is worth naming precisely, because it is not carelessness.

Approval is granted against an imagined scope. Nobody approves the literal text; they approve their reading of it. Every reader imagines slightly more than you wrote — a stakeholder pictures the version that solves their problem completely, an engineer pictures the version that is architecturally coherent, and both are being reasonable.

The gap surfaces during the build, which is precisely when your leverage is lowest. The request does not arrive as "can we add this?" It arrives as "wait, this doesn't do X?" — framed as a gap rather than an addition, which makes refusing it sound like backing out of something you promised.

Writing the exclusion moves that conversation earlier, to a point where it costs a sentence instead of a sprint. That is the whole return, and it is large.

Four kinds of exclusion

Not all exclusions are the same, and readers respond very differently depending on which kind you are naming. Say which one it is.

Adjacent. The obvious neighbour someone will assume is included. Bulk CSV import is not in this work. This is the highest-value category and the one most often left out, because it is exactly the thing that felt too obvious to mention.

Deferred. Genuinely coming, just not now. SSO provisioning is planned for Q4. Give the timeframe or the trigger, otherwise "later" is heard as "never" and someone will escalate.

Rejected. Considered and decided against. We are not adding an approval step before invites send — it doubles the flow length for a risk two customers have raised. Include the reason. A rejected exclusion without a reason reads as an oversight and gets re-litigated in the review.

Out of bounds. Someone else's system, team, or decision. Changes to the billing seat model are owned by Payments and out of scope here. This one prevents the specific failure where two teams each assume the other is handling something.

Finding the exclusions worth writing

You cannot list everything you are not doing. You need the two to five things a reader would plausibly assume are in. Three ways to surface them:

Ask what a reader will assume. Hand the in-scope list to someone who has not been in your planning conversations and ask what they expect it includes. Whatever they name that you had not planned is your exclusion list, discovered for free.

Ask the engineer what they would build. Specifically: "if I left the room now and you built this, what would you include that I have not mentioned?" Engineers fill gaps with what is architecturally sensible, which is frequently more than you scoped.

Look at the unaddressed nouns in your problem statement. If your problem statement mentions onboarding, permissions, and reporting, and your requirements only cover onboarding, the other two nouns are load-bearing. Either scope them in or name them out — leaving them mentioned but unaddressed is what produces the "I thought this covered reporting" conversation.

Writing one that holds

Four properties separate an exclusion that ends a conversation from one that invites it.

Specific. "Advanced permissions are out of scope" fails, because advanced is negotiable. "Custom roles beyond Owner, Admin and Member are out of scope" holds, because it names the line.

Categorised. Say whether it is adjacent, deferred, rejected, or someone else's. A reader who knows which kind knows whether to argue now or wait.

Reasoned or dated. Rejected exclusions get a reason. Deferred exclusions get a timeframe or a trigger. Adjacent ones often need neither — naming them is enough.

Unhedged. "We probably won't get to bulk import in this phase" is not an exclusion, it is an opening position, and it will be treated as one. If you mean no, write no.

The One-Pager template puts this section directly under the proposal for the same reason: the exclusion is most useful at the moment of the decision, not buried on page nine of a spec nobody re-reads.

The re-scope clause

Scope will sometimes have to change, and pretending otherwise makes the list brittle rather than strong. Give yourself a defined way to change it.

When something must come in, write three lines: what is being added, what is being dropped or delayed to make room, and who agreed. Not a new document — three lines appended to the existing one.

The trade is the point. Scope that grows without anything being named as the cost is how a six-week project becomes a fourteen-week one that nobody can quite explain, because each individual addition was small and none of them was ever weighed against anything.

An exclusion list is not a wall. It is a record of what you decided, so that changing it stays a decision rather than a drift.

FAQ

What does out of scope mean? The explicit list of adjacent things this work will not include — written before approval, while arguing is still cheap.

Why does creep happen after approval? Approval is granted against an imagined scope, and everyone imagines a slightly bigger one. The gap surfaces when your leverage is gone.

How many exclusions? Two to five. One thing someone genuinely wanted beats ten nobody proposed.

What if scope must change? Name what is added, what is dropped to make room, and who agreed. The trade is the point.