What to build first: cutting scope without gutting the product

Deciding minimum viable product features is where most founders are told to cut scope. Almost nobody is told how, so the usual outcome is a list where everything has been trimmed by twenty percent — which produces a product where nothing quite works, at eighty percent of the cost.

Cutting properly means removing whole things, not shaving all of them.

Start from the moment of value

There is a single point in your product where a user gets what they came for. The report appears. The booking is confirmed. The document is signed.

Everything on the direct path to that moment is in scope. Everything else is a candidate.

This sounds obvious and is surprisingly clarifying, because most feature lists are assembled by imagining a mature product and working backwards. Working forwards from a first-time user's actual journey produces a much shorter list, and a different one.

Why founders resist cutting, even when they agree with it

Almost every founder nods along to this advice and then produces a feature list that ignores it. Worth naming why, because the resistance is rational rather than stubborn.

Fear of looking unfinished to investors. A narrow product can read as under-ambition rather than discipline, especially to anyone comparing it against a competitor's polished, feature-complete demo. The corrective is usually reframing the pitch: a narrow product with real usage data is a stronger signal than a broad one with none, and most experienced investors know it.

Sunk cost in the vision. By the time a founder is briefing a development team, the full product has usually existed in their head for months, sometimes years. Cutting ninety percent of it feels like abandoning the idea rather than sequencing it, even when nothing is actually being abandoned — it is just not being built yet.

Not trusting that "later" really means later. This one is well-founded, because it is often true: features deferred without a plan tend to stay deferred, or get built in a rush once a customer demands them, at a worse quality than if they had been designed for from the start. The fix is not to abandon deferral — it is to make the non-goals list a real plan rather than a vague promise, with the second milestone named even if it is not yet scheduled.

None of these are reasons to keep the full list. They are reasons the discipline is harder to hold than the argument for it suggests, and worth planning for rather than being surprised by.

Then ask: could a person just do this?

For each remaining item, ask whether a human could do it by hand at the volume you realistically expect in the first three months.

Things that are almost always fine to do manually at first:

• Onboarding — a call is better than a wizard, and you learn more
• Billing — an invoice works fine below a few dozen customers
• Moderation and approvals — a person with a shared inbox
• Reporting — a query and a spreadsheet, sent on Fridays
• Support and refunds — obviously
• Matching, routing, triage — a person makes better decisions than your first algorithm would

Cut by user type before feature

The highest-leverage cut is usually not a feature. It is a persona.

Most product plans serve three groups: the primary user, someone who administers them, and someone who reports on both. That is three products in a trenchcoat, and the second two can nearly always wait.

Serving one persona completely gives you users who love the product. Serving three partially gives you three groups who find it almost useful, which is not a position anyone builds from.

A worked example, start to finish

Method without an example stays abstract, so here is the process run against a real product shape — a tool for property managers to track maintenance requests across a portfolio.

The feature list a mature version would have. Tenant-facing request submission with photo upload. A triage queue with priority scoring. Contractor assignment and scheduling. SMS status updates to tenants. A cost-tracking dashboard for the portfolio owner. Multi-property support with role-based access for regional managers. Reporting exports for compliance audits. That is roughly what the eventual product looks like, and roughly what a founder describes when asked what they are building.

Step 1 — write the journey as sentences. "A property manager gets a maintenance request, decides who should fix it, and tells the tenant when to expect them." That is the whole loop for the person who is actually paying.

Step 2 — mark the moment of value. The tenant gets a time. Everything before that sentence in the founder's feature list is preparation; everything after it is retention and scale.

Step 3 — delete what is not on the path. Photo upload is useful but not required to assign a job. Priority scoring is a nice-to-have when there are three requests a week. Cost tracking, compliance exports and multi-property roles all describe problems a portfolio with twenty units does not yet have. Gone, not forgotten — just not in this release.

Step 4 — ask what a person can do. Triage: a property manager reading an inbox is triage. SMS updates: a text message sent manually costs nothing and teaches you what tenants actually want to know. Contractor scheduling: a phone call and a shared calendar.

Step 5 — cut to one user type. The tenant-facing submission form stays, because it is the intake mechanism. The regional manager role, the portfolio owner dashboard and the compliance exports all wait for a second milestone, once there is a paying customer whose regional manager actually exists.

What is left. A form a tenant fills in. A list a property manager reads. A way to mark a request assigned and resolved. That is the entire first release — deployable in weeks rather than months, and it answers the only question that matters at this stage: will a property manager use this instead of the clipboard and group chat they use today.

The founder in this example initially described eleven features. Four survived to the first release, and three of the discarded seven never got built at all, because the manual version taught the team that property managers cared about something the feature list had not anticipated — being able to see request history by unit, not by tenant. That is the return on cutting: not just a faster launch, but a correction to a wrong assumption that would have been expensive to discover after building the wrong dashboard.

Common over-building mistakes

Beyond the general instinct to include too much, a handful of specific patterns recur across almost every scope conversation we have.

Building for the persona who is easiest to imagine, not the one who pays. Founders often build the admin dashboard first because it is more interesting to design than the plain form a real user fills in. The paying user's path should come first regardless of which is more fun to build.

Solving for scale before there is any load. Multi-region support, caching layers, background job queues for a process that runs four times a day — these are real engineering, and they are premature when the actual volume does not yet justify the complexity. Build for the traffic you have, and let the traffic you get tell you what to build next.

Treating configurability as a feature. "Let users customise the workflow" sounds like flexibility and is usually a way of avoiding the harder decision of what the workflow should actually be. A opinionated first version teaches you more than a configurable one, because you find out where your opinion was wrong.

Assuming the second user type needs the first user's tools. A landlord and a tenant do not need the same interface just because they are both "users" of the property system. Each persona gets exactly the surface their job requires, and no persona gets a feature nobody in that role asked for.

A method that works

1. Write the user's journey as sentences. "A landlord logs in, sees which properties have open issues, and assigns one to a contractor." Concrete, not abstract.
2. Mark the moment of value. One sentence in that list.
3. Delete every sentence not needed to reach it. Be aggressive; you are not deleting them from the product, only from this release.
4. For each survivor, ask if a person could do it. If yes, that is the implementation.
5. Cut to one user type. Whoever gets the value first.
6. Write down what you removed and why. This is the non-goals list, and it is the artefact that stops all of it quietly reappearing.

Step six matters more than it looks. Scope does not return through big decisions — it returns through a hundred small reasonable additions, each of which nobody would have refused on its own.

How prioritising product features differs from cutting scope

These sound like the same activity and are not quite. Prioritising product features usually means ranking a fixed list — deciding what comes in week one versus week four of a roadmap that eventually builds everything. Cutting scope means deciding what does not get built at all, possibly ever.

The distinction matters because the two questions get different answers. A feature can rank low on a priority list and still belong in the first release — authentication is rarely exciting to prioritise and is almost never optional. Conversely, a feature can rank high in importance and still be cut entirely from a first release, because "important eventually" and "required to test the core idea" are not the same claim.

When prioritisation and scope-cutting get conflated, the usual result is a roadmap where everything is technically included, just pushed later — which is not actually cutting anything. Six months on, the "MVP" has become the mature product's full feature list delivered slowly, and the team never got the fast, cheap signal a genuinely narrow release would have provided.

The method above avoids this by asking a different question than prioritisation does. Not "what matters most" — almost everything on a founder's list matters — but "what is required to find out if anyone wants this at all." Most items fail that second test even when they pass the first one easily.

What good looks like

A first release that does one thing completely, for one kind of user, with an ugly admin process behind it and a founder personally onboarding every customer.

That is not a compromise. It is the version that gets you a real answer fastest, and it is what most successful products actually looked like at the point nobody was watching.

How this connects to cost and timeline

Cutting scope is not only a product decision — it is the single biggest lever on both budget and delivery time, more than any negotiation over rate or team size. Our guide on how much an MVP costs walks through why: two user roles cost roughly three times what one does, not twice, because every additional role touches every screen and every permission check. The feature list you arrive at using the method above is also, directly, the thing that determines your quote.

The same logic applies to timeline. A narrower first release is not just cheaper — it is dramatically less likely to run late, because most software timeline overruns come from scope that expanded quietly during the build rather than from engineers writing code slower than expected. A feature list with a written non-goals section, arrived at through the process above, is the single best defence against that failure mode.

If you are working with an external team on this, the specification format that captures the output of this process — outcome, constraints, non-goals, acceptance criteria — is covered in detail in how we scope a build.

Revisit the cuts, deliberately

The features deferred through this process are not gone — they are postponed, and postponed features deserve a deliberate second look once real usage data exists, rather than either being forgotten entirely or reflexively added back in because they were always the plan. The method described throughout this piece works as well for the second release as it did for the first: start from the moment of value again, informed by what real users actually did, rather than simply building whatever was cut the first time around.

In one sentence

Cut by removing whole things a customer does not yet need, not by shaving a little off everything they eventually will.

A practical next step

Take your current feature list and run every item through the two questions from the method above: is it on the direct path to the moment of value, and could a person do it by hand for the first three months. Anything that fails both is a strong candidate to cut entirely from this release. This exercise takes under an hour for most early-stage products and routinely halves a feature list without anyone feeling like something important was lost.

The discipline pays off beyond the first release

Teams that learn to cut scope well on their first release tend to keep the skill for every release after it, because the underlying question — what is the smallest version of this that teaches us something real — does not stop being useful once a product has customers. The habit built scoping an MVP is the same habit that keeps a mature product from accumulating the kind of unfocused feature sprawl that makes technical debt and slow delivery inevitable years later.

One more thing worth saying

The discipline described here is not about building less ambitiously — it is about sequencing ambition so the first thing you learn is whether anyone wants what you are building at all.