Strategy
Your first release is not a smaller version of the final product.
When budget or timeline tightens, the instinct is to remove features until the total fits. It is the most reliable way to ship a product that is half-complete everywhere, useful to nobody, and that teaches you nothing.
Why trimming evenly fails
Picture a partner portal: case lookup, document upload, request tracking, messaging, dashboards, access management. The quote comes in over budget, so a little is cut everywhere. Messaging becomes a form, dashboards lose their filters, access management shrinks to two roles.
The result touches everything and finishes nothing. A partner can upload a document but cannot tell whether it arrived. They can open a case but cannot get an answer. Every path stops short of the point where it becomes useful, which leaves the organization without evidence: weak adoption will not say whether the need was misjudged or the product was simply unfinished.
The alternative is not to ship less. It is to ship a narrower slice completely. One path, carried all the way through, produces real usage and information you can act on.
Start from the question, not from the list
A useful first scope answers a question whose answer will change what comes next. It fits in one sentence, and it is rarely technical.
- Will partners upload their own documents, or keep emailing them?
- Will internal teams work requests in a new tool instead of their inbox?
- Is the existing data clean enough to show a customer as is?
Each of these dictates a different scope, and none reduces to "a simplified version of everything". The third, for instance, can be settled with a read-only screen, no elaborate sign-in and no polish — and it sometimes prevents a product being built on unusable data.
A first release is not judged by what it contains, but by what it lets you decide next.
Frame with appetite instead of an estimate
Estimating starts from scope and derives a duration. The approach Basecamp describes in Shape Up runs the other way: fix the appetite first — how much time the problem is worth — then design a solution that fits inside it. An estimate answers "how long will this take?"; an appetite answers "how long is this worth?".
The reversal has an immediate practical effect: the constraint becomes a design instrument rather than bad news. When six weeks are fixed up front, the conversation is about what fits inside them completely, not about how to stretch the calendar.
The discipline echoes a principle Martin Fowler has long written about as YAGNI: do not build a capability until it is genuinely needed, because the cost of a presumptive feature is not only building it — it is everything it complicates for as long as it exists.
Write down what you cut
The most neglected part of any scoping exercise is the list of what is not being built. Without it, every steering meeting reopens the same debate, and every new stakeholder reintroduces a requirement that was already settled.
| Status | What it means | What to write down |
|---|---|---|
| Deferred | The need is real, the timing is not | The condition that would bring it back |
| Out of scope | The need exists but belongs to another system | The system or team that owns it |
| Dropped | The need does not justify the cost | The reasoning, so it is not redone |
Experienced product teams, of the kind the Silicon Valley Product Group describes in its work on product discovery, spend a serious share of their effort on this elimination: a discovery phase is worth as much for the ideas it rules out as for the features it keeps.
A good first scope therefore looks nothing like a miniature of the target product. It looks like one complete, deliberately narrow slice, shipped alongside an owned list of what comes later — and a clear answer to the question that justified starting.
Sources and references
Related expertise
Explore the expertiseFacing a similar challenge in your organization?
Discuss your project
