A scope document earns its keep in the section listing what you will not build

TL;DR: The scope document exists so that a decision made calmly in week one survives a request made urgently in week five. Its most valuable section is the list of things you are deliberately not building.

Where you are. Last lesson of discovery. You have the real problem and the four people who decide. Now write it down, because a shared understanding that lives only in conversation is not shared.

Six sections, one page

Long documents do not get read, and a scope nobody read is not a scope. One page, six sections.

The problem, in their words, with the cost you established during discovery. Using their language matters: when they read a sentence they recognise, they engage with the rest of the document instead of skimming it.

Who it is for. A named operator or a specific small group. "The operations team" is not a user, and software written for a department gets adopted by nobody in it.

The success criterion. One number, with its current value written beside it. Not three numbers, because three criteria means no criterion. If nobody can state today's value, that is a finding, and usually means the first slice needs to include measuring it.

In scope. The thin slice, described end to end. If you cannot describe it as a complete path from input to something a person does differently, it is not a slice, it is a component.

Gall's law is the argument for insisting on this: a complex system that works is invariably found to have evolved from a simple system that worked, and a complex system designed from scratch never works and cannot be patched into working. A thin slice is not a reduced version of the real thing you will build later. It is the simple system that the real thing has to grow from, which is why cutting depth is safe and cutting the end-to-end path is not.

Explicitly not in scope. Below.

Known risks. Three to five, honest, including the ones that are your problem. A risks list containing only the customer's risks is a negotiating document rather than a plan, and experienced buyers read it that way.

Why non-goals do the work

In week five somebody will ask for something reasonable. Not unreasonable: reasonable. It will be small, adjacent, and genuinely useful, and it will be followed by two more like it. Scope never dies in one bite.

Without a written non-goals list, every one of those is a conversation you have on the spot with no standing to say no, because nothing was ever written down saying it was out. With the list, the conversation changes shape entirely. It becomes: that is on the not-now list, here is what it would displace, do you want to make that trade?

That question is not a refusal. It is a decision handed back to the person who is allowed to make it. It also protects the customer more than it protects you: the thing being displaced is usually the thing they said mattered most in week one, and they have forgotten saying it.

Write non-goals as the things a reasonable person would assume are included. "Historical backfill", "the second region", "mobile", "the admin interface". Naming the obvious ones is the entire point.

Ramp's forward deployed team runs on the mantra "always be scoping", a deliberate riff on sales' oldest slogan. This document is what that mantra looks like when somebody finally writes it down.

Circulate it, do not file it

Send it to all four stakeholders and ask for one thing: tell me what is wrong. Not approval, which people give without reading. A request for corrections gets read, because it invites the reader to be the expert, which they are.

The operator will correct the workflow. The gatekeeper will name a constraint you did not know about, which is the cheapest that constraint will ever be to learn. The sponsor will usually only read the success criterion, which is fine, because that is the line they will hold you to.

Do this before moving on

Write the six sections for the process you documented in the first lesson of this module. Keep it to one page. Then write five non-goals, each one a thing a reasonable reader would assume was included. If that list is hard to fill, your scope is still too vague to defend in week five.

Go deeper

• Scoping ambiguous problems covers how to choose the slice that goes into the in-scope section.
• Explaining trade-offs is the skill the non-goals list turns into a conversation rather than a refusal.
• Proof of concept to production is where this document gets tested against reality.
• AI cost and unit economics is often the missing constraint behind a success criterion nobody can state.
• Shipped in days what should take months is the interview version of defending a scope under pressure.

Key takeaways

• Six sections, one page. A scope nobody read is not a scope.
• One success criterion with today's value beside it; three criteria means no criterion.
• Non-goals should name the things a reasonable person would assume are included, because those are the week-five requests.
• Ask stakeholders for corrections rather than approval; approval is given without reading.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1Why is the non-goals section the most valuable part of a scope document?

   Answer it, then reveal

2. 2A customer cannot tell you the current value of the metric you plan to improve. What does that mean for the first slice?

   Pick a different metric that is already measuredEstimate the baseline yourself and proceedThe first slice probably needs to include measuring it, because without a baseline you cannot show improvement

3. 3You send the scope document and ask for approval. Everyone approves within a day. Why is this a bad sign?

   Fast approval means the scope was too small to matterApproval is given without reading; asking for corrections is what gets the document actually readIt means the stakeholders do not have authority