Studio
What 200 launches taught us about scope
What 200 launches taught us about keeping scope small, choosing what to cut, and planning the first month after launch.
Written by
Ethan Park
Head of Delivery
Key points
- Scope grows when nobody writes down what will not be built.
- Three primary outcomes with one named owner each are easier to ship than a long list of good ideas.
- Agree the cut order before pressure arrives: integrations, edge states, admin tooling, then polish.
After enough launches, the post-mortem stops being interesting. The same pattern appears: the date slipped because the scope grew, and the scope grew because nobody had written down what would not be built.
We now run every project against a simple rule. If the scope has more than three primary outcomes, it is a programme wearing a project’s clothes.
Three outcomes, one owner
Three is a working limit, small enough to fit on a wall. Each outcome gets a named owner on the client side and a measurable definition of done. Everything else is explicitly deferred, including the ideas that are obviously good.
This is uncomfortable in the first week. It is much less uncomfortable in week twelve, when the team is still shipping and the deferred list has turned into a roadmap.
Cut in this order
When a date is at risk, we cut in a fixed order: integrations, then edge-case states, then admin tooling, then polish. We never cut performance, accessibility, or the migration path. Those are the things that become expensive after launch.
Having the order agreed before the pressure arrives turns a negotiation into a procedure. The client knows what they are giving up and why.
Go-live is the start
A launch that requires the whole team to stay for a month of cleanup is a demo with a production URL. We plan the first four weeks after go-live as part of the scope, with an on-call rota and a list of the things we expect to learn.
Scope discipline is about deciding, in advance, which yes deserves the team’s attention. The calm projects are the ones where the problems were expected.
FAQ
Common questions.
How do you prevent scope creep on a software project?
Write down the three primary outcomes, name an owner for each, and explicitly defer everything else. The deferred list becomes a roadmap. Changes then require a trade.
What should be cut first when a deadline slips?
Cut in a fixed order agreed in advance: integrations, then edge-case states, then admin tooling, then polish. Never cut performance, accessibility, or the migration path, because those costs compound after launch.
Why plan four weeks after launch?
A launch that requires a month of cleanup is unfinished. Planning the first four weeks as part of scope gives the team an on-call rota, a place to record what they learn, and a realistic definition of done.
Keep reading
All postsEngineering
Why we still choose Angular for enterprise platforms
Why we still choose Angular for long-lived enterprise platforms, and what we look for before committing to a framework for years.
Commerce
The real cost of a slow checkout
How small checkout delays turn into lost revenue, and the four numbers we track before changing the design.