Why most MVPs end up too big
An MVP is supposed to be the smallest product that lets you learn whether your idea works. In practice, most first versions grow until they look like the full product: every stakeholder adds a must-have, and every edge case gets a feature.
The cost isn't just money. A bigger build takes longer to reach users, so you learn later, and you've spent your budget before you know which parts matter.
1. Write down the riskiest assumption
Every product idea rests on a few assumptions. Some are safe (people use email), and one or two could sink the whole thing. Usually that's whether a specific group of people has this problem badly enough to change how they work, or pay to fix it.
Write that assumption down in one sentence. The MVP exists to test it. Anything that doesn't help test it is a candidate for later.
2. Pick one user and one journey
Choose the single type of user whose problem you're solving first, and the one journey that delivers the core value, from arriving in the product to getting the outcome they came for.
If your product has several user types (say, buyers and sellers), ask which side you need to win first, and whether the other side can be handled manually at the start.
3. List features, then sort them ruthlessly
List everything you think the product needs, then sort each item into one of three groups:
- Core: without it, the main journey doesn't work.
- Supporting: makes the journey nicer, but users could get the outcome without it.
- Later: useful once you have users and data, not before.
4. Replace features with manual work
Many features that feel essential can be done by a person at first. Onboarding can be a call, reports can be a spreadsheet you send, and matching can be done by you behind the scenes.
Manual work doesn't scale, and that's the point: you only automate it once you know people want it, and you'll understand the process far better when you do.
5. Don't cut quality where it's expensive to fix
Scoping down is about features, not foundations. Some decisions are cheap to change later, and some aren't:
- Keep: a sensible data model, authentication, basic security and a stack you can grow on.
- Skip for now: admin dashboards, fine-grained settings, rare edge cases and most integrations.
- Fake if needed: anything that can run manually or be added in a week once it's proven.
6. Define what success looks like before launch
Decide in advance what result would tell you the assumption holds: a number of active users, a conversion rate, or people paying. Then make sure the MVP measures it.
Without that, it's easy to read any outcome as encouraging and keep building in the dark.
A quick scoping checklist
Before you start building, you should be able to answer each of these in a sentence or two:
- What's the riskiest assumption this MVP tests?
- Who is the first user, and what's the one journey they complete?
- Which features are core, and which can wait or be done manually?
- Which foundations are we not cutting corners on?
- What result after launch tells us to keep going?