Keeping product projects on track: why time should shape scope

Most projects do not run late because teams are slow. They run late because scope keeps expanding while deadlines are treated as flexible. Reversing that approach — fixing the time and allowing the scope to adapt — consistently leads to more predictable delivery and better products.

Why timelines slip

Most plans start with a feature list and an estimate. But new products involve many unknowns, so early estimates are closer to informed guesses than firm plans. As the work progresses, the list grows through small additions and changes, and the delivery date moves accordingly.

The underlying issue is not poor estimation. It is treating scope as fixed and time as flexible, when the reverse is far more effective.

Start with appetite, not estimates

Instead of asking how long a feature will take, ask how much time it is worth investing in. Basecamp's Shape Up methodology describes this as setting an appetite, and it is one of the most useful planning principles we use.

Once the time is agreed, the discussion moves from negotiating deadlines to designing the best solution that fits within them.

Shape the work before anyone builds it

Fixed timelines work only when the work is well defined in advance. Before a sprint begins, we agree on four things:

• The problem we’re solving, in plain language.
• A rough solution — enough detail to build, enough freedom to adapt.
• The rabbit holes — the risky unknowns we need to solve or avoid early.
• The no-gos — what we’re deliberately not doing this time.

Much of the project risk is resolved at this stage, when changing direction is still inexpensive.

Prioritise must-haves early

Most feature lists contain a small number of essentials and a larger set of desirable additions. Separate them early and explicitly. When time becomes tight, the additions are deferred, quality is maintained and the delivery date holds.

Deferring features is a matter of focus, not compromise. They remain available for future releases once there is evidence they are needed.

“A fixed deadline is one of the most effective tools for keeping scope under control.”

Managing the trade-offs

Fixing the time can initially feel restrictive. Teams worry that an important feature will not fit, or that the wrong item will be cut. In practice, this pressure is valuable: it prompts early conversations about what genuinely matters.

It also improves day-to-day delivery. With a clear end date, teams make decisions faster, raise issues earlier and avoid refining work that has not been requested. The deadline becomes a shared constraint that informs every decision.

What this looks like in practice

This is why each stage of our process begins with an agreed timeline, and why “what can we leave out?” is a standard question in our planning sessions. Clients benefit from predictable delivery, teams have room to make sound decisions, and products reach the market while the opportunity is still current.

At the end of each sprint, we review what we have learned before planning the next. Some deferred features return to the plan; others prove unnecessary once real users are involved.

Further reading: Set Boundaries — Ryan Singer, Shape Up