The scope nobody cut — they just never named it
Cutting scope means crossing something off a list. The features that blow up a timeline were never on the list to begin with, so nobody ever got the chance to decide against them.
Hammad Iqbal
Software Engineer
The planning meeting went well by the usual measure: the feature list got trimmed, two nice-to-haves got pushed to a later phase, and the remaining scope looked achievable in the time available. Three weeks in, the timeline was gone anyway — not because of the features that got cut, but because of the ones that were never written down to begin with. What happens when the form submission fails halfway through. What the empty state looks like before any data exists. Whether a user without the right permission sees an error or just a blank page. None of that was in the plan, which meant none of it was ever a decision — it was just discovered, one Slack thread at a time, always later than it should have been.
- Scope that was never written down can't be cut — it only gets discovered mid-build, and discovery is always later than a decision would have been.
- The features people argue about are the visible ones; the ones nobody names — empty states, error handling, permissions, retries — are simply assumed, in whichever direction the engineer building them happens to guess.
- Naming the unglamorous scope in the plan turns a silent overrun into an actual choice someone gets to make on purpose.
You can't cut what was never on the list
Cutting scope is a negotiation over named items — this feature moves to phase two, that one gets simplified. It only works on things that made it onto the list in the first place. Anything that never got named isn't cut and isn't kept; it's just absent from the plan and present in the actual product anyway, because software that handles the happy path only isn't shippable, whether or not anyone scheduled time for the rest of it.
What gets left off the list, every time
The same categories of work go unnamed on almost every plan, not because they're unimportant, but because they're unglamorous enough that nobody thinks to ask about them until they're the thing blocking a demo:
- Empty, loading, and error states for every view that has a happy-path mock but no failure-path one
- What a permission boundary actually does — reject with an error, redirect, or silently show nothing
- What happens on a duplicate submission, a retry, or a request that times out halfway through
- Whether existing data needs to keep working under the new feature, or whether that's someone else's problem
Name it, then decide
The fix isn't more thoroughness in general — it's specifically putting the unglamorous items on the same list as the features, so that cutting them is a decision instead of an accident. 'We're shipping without a real empty state for v1' is a fine call to make on purpose. Finding out three weeks in that nobody made it is the actual problem, because by then it's not a decision anymore, it's just late work with no time left for it.
A feature you cut on purpose was never going to blow up your timeline — it's the scope nobody named that shows up uninvited, always at the worst possible time to add it.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.