The skill: Keeping projects on track when new requirements surface and edge cases multiply. The difference between teams that ship on time and teams that are perpetually "almost done."
Draw the line before you write code
If you can't name the three things that must ship, you haven't scoped the project. Define must-have vs. nice-to-have before the first PR, not mid-sprint. This isn't a formality — it's the only defense against the slow accumulation of "small additions" that turn a 2-week project into a 6-week one.
Set a scope freeze date and enforce it. Scope expands in proportion to comfort — the more confident the team feels, the more they'll absorb. A freeze date creates a forcing function.
When new requirements surface mid-build
They will. The question is how you respond. One test cuts through every debate: would we start this project to get this feature? If the new requirement were the only thing we shipped, would we have kicked off the project? If no, it's scope creep.
New information earns scope changes. Opinions don't. A user test revealing a broken flow earns a change. A stakeholder saying "wouldn't it be cool if..." does not.
When you're behind, the instinct is to ask for more time. The better move is to ask what can be cut. Shipping 80% on time beats shipping 100% late.
Scope hammering
When time is fixed, scope is the variable you sculpt. Think of it as taking a chisel to a block of marble: you're not looking for what the feature can be, but what it needs to be. The tighter your constraints, the more ruthless you have to be about what stays and what goes. That ruthlessness is what gets products out the door.
Ship the boring version first. Edge cases, error states, and advanced settings can follow. The first version should nail the core use case and nothing else.
Do's and Don'ts
Written with ❤️ by a human (still)