Cutting Scope by the Question, Not the Difficulty
When the work does not fit, cut the parts that would not change the answer to the question the feature is asking — not the parts that are hardest to build.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
When the work does not fit, how do we decide which parts to cut?
Mid-sprint, the engineering lead says: "Saved carts is two weeks behind. The launch date is fixed because marketing already scheduled the email. Find something to cut by tomorrow."
Sort the remaining tickets by effort and cut the biggest, riskiest ones — cross-device sync, the reminder email, merging a guest cart into an account cart — and ship the parts that are nearly done.
Saved carts is betting that people who leave without buying come back to finish if their cart is waiting. Many of them come back on a different device — phone at lunch, laptop at night. Cutting cross-device sync because it is hard leaves a feature that cannot answer the question it was built for.
- Saved carts is betting that people who leave without buying come back to finish if their cart is waiting. Many of them come back on a different device — phone at lunch, laptop at night. Cutting cross-device sync because it is hard leaves a feature that cannot answer the question it was built for.
- The parts that are nearly done are nearly done because they are easy, and easy parts are often polish: the empty-state illustration, the "saved 3 days ago" label. The launch looks complete and tests nothing.
- A cut list made by engineering alone, by difficulty, reads to the PM as "engineering removed the hard parts". The next estimate is trusted less, and the next cut is negotiated rather than reasoned.
- The cut parts vanish. Nobody wrote down what was cut or what would bring it back, so three months later the reminder email is either forgotten or rebuilt by someone who does not know why it was deferred.
What is really going on
- Every part of a feature does one of four jobs: it changes the answer (without it, the launch could not show whether the bet was right), it is the floor (without it, nobody can use the feature safely at all), it makes it nicer, or it makes it last. Cut from the last two first. Difficulty is not one of the jobs.
- The test for each part is one question: "If we ship without this, would the result of the launch mean something different?" Cross-device sync: yes — without it, a flat result means nothing. Empty-state illustration: no.
- The floor is not negotiable and is usually small: keyboard and screen-reader users can use it, it does not lose or corrupt a cart, it can be turned off, and it records the events needed to read the result. Cutting any of these does not make the launch smaller; it makes it unreadable or unsafe.
- "Makes it last" is the part engineers find hardest to cut — the general cart-storage abstraction, the admin tooling, the retention job. It is also the part the first launch least needs, because nobody knows yet whether the feature will last (Sequencing Work So Value Lands Early).
- A cut is a deferral with a trigger, not a deletion. Each cut item gets one line: what it was, why it was cut, and what result would bring it back.
Four jobs a part can do
Lay the remaining saved-carts work out and give each part a job. The sort is quick once the question is written at the top: people who leave come back to finish if their cart is waiting for them, on whatever device they come back on.
Notice that the sort does not follow difficulty. Sync is the hardest item and stays. The retention job is modest and goes. The events are trivial and are floor.
| Part | Job | Launch without it? |
|---|---|---|
| Save cart for logged-in customers | Changes the answer | No — this is the feature |
| Cross-device sync | Changes the answer | No — most returns are on another device |
| Events: cart_saved, cart_restored, order_from_saved_cart | Floor | No — the result would be unreadable |
| Keyboard and screen-reader support | Floor | No |
| Flag with a working off switch | Floor | No |
| Guest-to-account cart merge | Makes it nicer | Yes — guests keep a local cart for now |
| Reminder email after 48 hours | Makes it nicer | Yes — trigger: saved carts convert at all |
| "Saved 3 days ago" label, empty-state art | Makes it nicer | Yes |
| Retention job and admin tooling | Makes it last | Yes — until volume makes it floor |
The one test
The four jobs come down to one question asked of each part: if we ship without this, would the result of the launch mean something different? If yes, it stays. If the answer is "the result means the same, there would just be less of it", it can wait.
That test also tells you how to narrow when cutting parts is not enough. Narrowing who sees it — logged-in customers only, web before app — keeps the answer intact for a smaller group. Cutting a part that changes the answer keeps the group and loses the answer.
Cut: cross-device sync (8 pts), reminder email (5), guest merge (5). Keep: save for logged-in (3), label (1), empty state (1), retention job (2).
Keep: save for logged-in, cross-device sync, events, accessibility, off switch. Cut with triggers: reminder email, guest merge, label, empty state, retention job. Narrow: logged-in customers only.
The effort sort ships a feature that looks finished and cannot show whether people come back. The question sort ships something plainer that answers the only thing the launch was for.
Telling people what was cut
A cut that the PM discovers in the demo costs more trust than the cut saved time. Tell people before, in the order that makes the reasoning obvious: the question, what stays for it, what goes and what would bring it back (Writing for Stakeholders).
Saved carts is two weeks behind, the marketing email date is fixed, and the engineering lead has asked for a cut by tomorrow.
"Heads up: we are cutting sync, the reminder email and guest merge to hit the date. Should be fine for v1."
"To make the email date: we keep save, cross-device sync and the tracking events, because without sync we cannot tell whether people come back. We drop the reminder email, guest merge, the 'saved N days ago' label and the empty-state art. Reminder email comes back if saved carts convert in the first month. Launch is logged-in customers only. If sync still slips, I will tell you by Wednesday and we choose between moving the email and launching something we cannot read."
When the parts that matter do not fit
Sometimes, after cutting everything that is nicer or lasts, the parts that change the answer still do not fit. At that point there is no clever cut left, only a choice between costs — and it is usually not the engineer's choice to make alone.
Sync still does not fit before the email. What now?
when The email can move a week and the launch result matters more than the calendar.
cost Marketing reschedules; the date slips visibly and someone has to explain it.
when A smaller group — web only, one country — still gives enough volume to read a result in a reasonable time.
cost A slower or noisier read; the email links to a feature many recipients cannot see.
when The date is truly fixed and a partial answer is better than none.
cost The launch cannot show whether saved carts work; it must be presented as a first step, not a result.
when The email is about a sale, not about saved carts.
cost Marketing loses a hook; the feature launches on its own schedule with less fanfare.
The cut list is a document
Cuts made in a meeting evaporate. Cuts written with triggers come back at the right time, for the right reason, and nobody has to remember them. Keep the list short and put it next to the feature, not in a chat thread.
1## Saved carts — cut for launch (decided with PM + design)2Question: do people who leave come back to finish if their cart is waiting, on any device?3 4| Cut | Why | Comes back when |5|-----------------------------|------------------------------|----------------------------------------------|6| Reminder email (48h) | Changes how many, not whether | Saved-cart orders appear in first month |7| Guest-to-account merge | Guests keep local cart | Support sees "lost my cart after login" |8| "Saved N days ago" label | Polish | Next design pass on cart |9| Retention job, admin tools | Makes it last | Saved carts exceed what one table handles |10 11Review date: four weeks after launch.The review date is the part that turns the list into a plan. Without it, every trigger is somebody else's job.
How to do it
Most important first.
- Restate the question the feature is betting on in one sentence at the top of the cut list, so every cut is argued against it (The First Version That Teaches You Something).
- Sort the remaining work into the four jobs with the PM and designer in the room, not afterwards — the designer knows which parts are the usability floor, the PM knows which ones stakeholders were promised (Working With a Product Manager, Working With Design).
- Cut "nicer" and "lasts" first. If that is not enough, narrow the audience or the surface — one platform, logged-in customers only — before cutting anything that changes the answer.
- If the parts that change the answer do not fit, say so plainly: the date and the question are incompatible, and one of them has to move (Saying No Well).
- Write the cut list down with triggers, and put it where the next planning session will see it (Decision Records).
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Start with what stays and why: "We are keeping cross-device sync, because saved carts only matters if people come back on another device. Without it, the launch cannot tell us anything."
- Then what goes, framed against the question: "The reminder email and the 'saved 3 days ago' label are out for launch. Neither changes whether people come back — they change how many, and we can add them once we know the base works."
- Name the trigger for each cut: "If returning customers are converting from saved carts in the first month, the reminder email is next. If almost none are, we do not need it."
- If it still does not fit, hand over the choice instead of absorbing it: "With sync we land a week after the email. Without sync we land on time with a feature that cannot show whether it works. I would move the email; it is your call."
- "Marketing already wrote copy about reminder emails." Then either the reminder is part of the floor for this launch, or the copy changes. Either is fine; finding out on launch day is not. I will talk to them today.
- "Sync is the risky part — cut it and ship something solid." Something solid that cannot tell us whether saved carts work. I would rather ship sync to logged-in customers only than ship no sync to everyone.
- "Just cut accessibility for launch and add it later." That is not a cut; it is shipping a feature some customers cannot use. It stays on the floor.
What can go wrong
- Everything gets labelled "changes the answer". The sort only works if someone is willing to call their own idea polish — and often that someone has to be you, about your own abstraction.
- Narrowing the audience so far that the launch is underpowered: saved carts for logged-in iOS customers only may be too few people to read anything in a month (Reading an Experiment Honestly).
- Cutting instrumentation because it is invisible to customers. It is the cheapest part to cut and the most expensive to regret: the launch happens and nobody can say what it did (Instrumentation First).
- The cut list with triggers is written and never read. A trigger nobody checks is a deletion with extra paperwork.
- "Cut the hardest parts to reduce risk." It reduces delivery risk and increases the risk that the launch means nothing — the more expensive of the two.
- "Never cut the core." The core is defined by the question, not by the architecture diagram. The general storage abstraction feels core to engineers and is usually "makes it last".
- "Cutting scope means we failed the estimate." Estimates are guesses made with the least information anyone will ever have; cutting well is how a plan absorbs that, not an admission of anything.
Knowing whether it worked
- The launch result is readable: afterwards you can say whether the bet was right, which is what the kept parts were for.
- The PM uses the four jobs in the next cut conversation without being prompted.
- Deferred items come back because a trigger fired, not because someone remembered them in a planning meeting.
- Estimates after a cut are trusted as much as before it — nobody asks "what else did you quietly drop?".
- On a small team the cut is a conversation over lunch. At 10x team size, a cut in one team removes something another team was depending on, and the cut list becomes a document other teams read.
- At 10x customers the floor rises: accessibility, data correctness and the kill switch matter more because more people hit the edge cases on day one.
- At 10x revenue some "makes it last" parts join the floor sooner — a saved-cart store that loses carts at volume is an incident, not a nice-to-have (Incidents Are Product Events).
- You keep the hardest part, so the launch still carries the most technical risk. Cutting by difficulty is safer for the date; cutting by question is safer for the quarter.
- The launch looks less polished. People will notice the missing label and the plain empty state, and some will say so.
- It takes a meeting with the PM and designer, which is slower than an engineer editing the ticket list alone the night before.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALSorting parts by whether they change the answer applies to any feature that is a bet. It applies less to purely operational work — a certificate renewal has no question to answer, only a deadline.
- PRODUCT-SPECIFICIn B2C the floor is usability, accessibility and data correctness. In B2B, anything named in a contract or a sales demo is floor whether or not it changes the answer, and in regulated products audit logging joins the floor too.
- TEAM-SPECIFICWith a PM and a designer the sort is a joint decision and the engineer leads on cost. Without them, the engineer does the sort alone and should write it down for whoever holds the date, rather than cutting silently.