Scope Cut
Turns a sprawling request into the smallest version that would actually prove the idea.
When to reach for it
When a request arrives as a paragraph of features and you cannot say which one it fails without — right before an agent starts building all of them at once.
What changes
- The agent restates your request as a numbered list of separable pieces, so you can see how many things you actually asked for.
- One piece is named as the core — the part that, if it worked, would tell you the idea is worth continuing.
- Everything else is written down as deferred rather than quietly dropped, so cutting scope stops feeling like losing work.
- You get something runnable in one sitting instead of a half-finished version of five features.
- The agent tells you what the cut version cannot do before you discover it by using it.
Pairs with
- Budget the SessionDecides in one sentence what this session is for, and writes down what it will not touch.
- Assumption CheckMakes the agent state what it is assuming — and verify it — before it writes a line.
- Constraint SurfaceGets the real limits — deadline, platform, budget, who inherits it — out of you before anything is designed around a guess.
Scope Cut
Before building anything for this request, reduce it to the smallest version that would still tell us whether the idea works.
1. Split the request into pieces
Restate what was asked as a numbered list where each item could ship on its own. Keep splitting until no item contains the word "and". Include the parts that were implied but never said — saving, sign-in, empty states, small screens — because that is where hidden scope lives.
2. Find the piece that carries the risk
Exactly one item is the reason this might not work at all. It is usually the part nobody here has done before: the unfamiliar API, the layout that may not be possible, the performance question. Name it.
3. Draw the cut
Write two lists.
Build now — the risky piece, plus only what it needs to run at all. Hard-code the rest: one fixed user, a file instead of a database, one screen instead of a flow.
Not now — everything else, one line each. This second list is the point of the exercise. It proves the work is deferred, not forgotten.
4. Say what the cut version cannot do
Three or four sentences in plain language. "It will not remember anything between reloads. It handles one file at a time. It will look wrong below 600 pixels." The user should learn this from you, not from using it.
5. Get agreement, then build only the "build now" list
If the user moves something from "not now" into "build now", move something else back the other way.
Rules
- Do not cut the risky piece because it is the hard one. Cutting it leaves a demo that proves nothing.
- Do not add polish nobody asked for — theming, animation, settings screens — while claiming to reduce scope.
- Do not read "smallest" as "roughest". The cut version has fewer features, not sloppier ones.
- Do not build items off the "not now" list because they turned out to be quick. Ask first. Quick items are how the list grows back.