How to Cut Your MVP Feature List in Half
By CodexierPublished 6 min read
The feature list you bring to a developer is the single biggest lever on what your MVP costs and how long it takes. Most lists are twice as long as they need to be, not because founders are careless but because every stakeholder adds a reasonable idea and nobody has a rule for saying no. This guide is that rule, in an exercise you can run in an afternoon.
Name the one core job
The core job is not your vision or your positioning; it is the narrow, specific thing the first users will pay for. A booking tool for physiotherapists is not hired to run the clinic, it is hired so that a patient can book a free slot without a phone call. If you cannot state the job in one sentence with a concrete user and outcome, stop here and do customer conversations before you touch the list; a job you cannot name cannot be prioritised.
Map features to that job
Put every feature on the list in a table and answer one question per row: if this did not exist, could the user still complete the core job? Be strict. Convenience, polish and things that make the product look finished all fail this test and that is the point.
| Feature | Job fails without it? | Manual workaround possible? | Column |
|---|---|---|---|
| Patient picks a slot and books | Yes | No | Must |
| SMS confirmation | No, but no-shows rise sharply | Yes, send manually for the first weeks | Later, early |
| Calendar sync with existing system | Yes for clinics that already use one | Yes, copy bookings by hand during pilot | Later, early |
| Patient accounts and login | No, a link and BankID or email works | Not needed | Later |
| Admin dashboard with statistics | No | A spreadsheet export | Later |
| Multi-clinic management | No | Sell to single clinics first | Never, for now |
| Loyalty points | No | Not needed | Never |
The second and third columns do the work. A feature that the job fails without and that cannot be done by hand is the only kind that earns a place in version one.
Must, later and never
Three columns, and the middle one is where the negotiation happens. Use these definitions in the room so the words mean the same thing to everyone:
Must
The core job fails without it and no human can cover for it. Usually five to eight features. If you have twenty, your core job sentence is too broad.
Later
Valuable, but the job completes without it. Ordered by how soon its absence hurts. The first two or three of these are usually version two, planned before version one ships.
Never
Serves a different user, a different job, or a scale you do not have. Write it down and let it go. This column is what keeps the product from becoming a platform before it is a tool.
The decision rule when two people disagree: which column would the first ten paying customers put it in? Not investors, not the team, the customers. If nobody knows, that is a question for a customer call, not a debate.
Manual workarounds for version one
Half of what founders call features are automations of something a person could do for the first fifty customers. Doing those things by hand in version one is not cheating; it is the cheapest research you will ever run, because you learn exactly what the automation needs to do before you build it.
- Onboarding: set up each customer's account yourself on a call instead of building a self-service wizard.
- Notifications: send the first confirmations and reminders from a template by hand, then automate the one people respond to.
- Integrations: export a CSV and import it into the customer's system weekly until the volume justifies an API integration.
- Billing: invoice from Fortnox manually before you wire up subscription billing.
- Reporting: a shared spreadsheet beats a dashboard until you know which numbers customers actually look at.
Each workaround has a breaking point, usually a customer count or a weekly hour count. Write that trigger next to it so the later list has dates attached to reality rather than to hope.
Keeping a visible later list
Cuts fail when they feel like losses. The later list is how you make them feel like sequencing. Keep it in one shared document with a one-line reason and a trigger per item, review it every time you talk to a customer, and move items up only when a real user asks for them. Stakeholders who can see their idea on the list with a condition next to it stop relitigating it.
When you do not need this exercise from anyone: if your list is already under ten items and you can state the core job, go build. If the list is long and the job is fuzzy, an afternoon with this method is more useful than any quote. And if you want a second pair of eyes before committing a development budget, that is what our MVP planning blueprint is: a scoped, prioritised plan with a fixed price, listed on the pricing page. It is also the point at which the no-code or custom code question gets a real answer, because it depends on what survived the cut. Book a short call if you want to walk through your list together.
Frequently asked questions
How many features should an MVP have?
As many as the core job needs and no more, which in practice tends to be five to eight. If your must column is longer, the core job is defined too broadly or several jobs are being bundled. Split them and build the one the first customers will pay for.
What if a customer says they need a feature we cut?
Ask what they would do without it and whether they would still buy. One request moves an item up the later list; it does not move it into version one. If several early customers make the same request, that is real evidence and the item earns its place in the next release.
Is it risky to do things manually behind the scenes?
Only if you hide it from yourself. Track the hours, set a trigger for when each workaround gets automated, and be honest with customers about response times. The risk of building the wrong automation is far larger than the cost of doing it by hand for a while.
Want to run the cut with someone who has done it before?
Bring your feature list to a fifteen-minute call. We will tell you what looks like must, what looks like later and whether a planning blueprint or a straight build is the right next step.
Book a free 15-minute call