Out of Scope

A document that records only the work to be done leaves no trace of the work that was ruled out. Someone says "let's leave that out this round" in a meeting, everyone nods, and the sentence disappears the moment the meeting ends. All that survives is the list of commitments, so three weeks later, when the same request comes back, opening the document won't tell you whether the item was ever discussed.

Pagedeck ran into this while adding a coupon field to its checkout screen. The first meeting settled that codes would not be applied automatically this round, but the document only said a field would be built. Two weeks later Sofia asked when automatic application would ship because a customer kept asking, Theo said he thought it had been cut, and nobody could say for certain, so another meeting went on the calendar. Getting back to the same conclusion took forty minutes.

One sentence closes that gap. "Automatic code application is not part of this round," written in the document, turns the three-weeks-later conversation into a five-minute one. Out of scope is the place that sentence lives. A column for things you aren't doing looks strange at first, but in practice it gets opened more often than the list of things you are.

You write each item you are not doing on its own line, and attach the reason for cutting it and the point at which it gets looked at again. Without those two, the line reads as a rejection notice, and whoever asked for it routes around the document.

Three things belong on a line.

1. What isn't happening — name the feature and how far the exclusion goes. "No coupon issuing" doesn't separate "there's no admin screen for it" from "issuing is impossible." Write that no admin issuing screen gets built and that operations will enter codes directly, and both readings close.
2. Why it's cut — because the schedule is short, because demand isn't confirmed, or because of a technical limit. The reason decides what would bring the item back. A schedule cut returns the moment the schedule opens up, an unconfirmed-demand cut returns only with evidence, and a technical limit waits on whoever owns the limit.
3. When it gets revisited — "next quarter" works, and so does a condition like "when ten paying teams ask for it." Leave this blank and the item hardens into a permanent no.

The ruling happens the moment a new request arrives. You check whether it sits inside scope, sits in the out-of-scope list, or appears in neither. If it's in the out-of-scope list, changing the document becomes a decision, and that single step reopens the schedule conversation. If it's in neither, you decide then and write the result into one column or the other. Recording it either way is what keeps the same question from arriving a third time.

That one step is what holds off scope creep — scope growing quietly without anyone agreeing to it. Creep arrives in pieces, each attached to the phrase "this one's small," which is why nobody can point to when the work grew. No single day turned a two-week estimate into a six-week one.

The most common home is one column of a PRD. It sits right after functional requirements, the statements of what the product must do, and pins from the other side how much of a given feature belongs to this round. Non-functional requirements — the performance, security, and accessibility conditions — need the same column. Hold up to a hundred requests per second and ignore anything above that for now, written plainly.

Three other places use it.

1. Estimating a schedule — when one person says two weeks and another says six, they are usually picturing different scopes. Read three out-of-scope lines together and the two numbers move toward each other.
2. Talking to customers — sales and customer success open this column first. Promising a feature that doesn't exist leaves someone to unwind the promise after the contract, and that job lands on whoever made it. Sofia keeps the column open in a second tab during calls so her answer matches the document word for word.
3. Setting up the next round — lines here don't vanish. They move to the product backlog, the ordered list of candidates a team may build later.

Items carrying too many exceptions for one line go to a product policy instead, the document that fixes how the product behaves in each situation down to the edge cases. A single coupon picks up twenty-odd rules about stacking and partial cancellation; the combinations left alone this round get one out-of-scope line, and the table stays in the policy.

"That's out of scope for this round. Doing it means editing the document and redoing the schedule."

Not a refusal — an offer to reopen the schedule conversation.

"Put one line in the out-of-scope list. I can only tell the customer it isn't coming if it's written down."

Anything absent from the document is hard to state as absent to a customer.

"Is this in scope or out? It isn't written in either place."

The call hasn't been made, so make it now and record it in one column or the other.

Mia filled this column in for Pagedeck's coupon work. The draft carried two lines: the admin issuing screen and automatic code application. Three days in, Sofia commented that enterprise contracts already carried a separate discount, and Mia added a third line covering coupons used alongside those contracts.

A month later the three lines each did a different job. The first sent an issuing request from operations to the backlog, the second became Sofia's answer to a customer, and the third let Theo skip a set of exception handling.

The most common mistake is reading the column as a permanent rejection list. It says the work isn't happening, so that reading comes naturally. In practice the decision covers this round only, and items move into scope next quarter often enough. Once it hardens into a permanent no, people start avoiding having their requests written there, and decisions go back to individual conversations outside the document. Six months on, the document reads clean while the real calls live in direct messages nobody else can find.

The other common belief is that a well-written scope makes this column unnecessary, since the list of things you aren't doing is infinite anyway. But readers fill the unwritten space with their own assumptions. Given only a line about building a coupon field, sales reads the admin screen as included and engineering reads it as excluded. The infinite list doesn't need writing down. Three lines covering what actually came up in this round's discussion usually cover it.