Every project we run starts with a feature list that is too long. That is not a criticism of clients; it is what happens when you think hard about a problem.
This is the method we use to cut one down.
Step 1: write the one sentence
Complete this without using "and":
The app lets [who] [do what] so that [why].
If you cannot do it without "and", you have more than one product. Pick the one that, if it did not exist, would make the others pointless.
Step 2: list the actions, not the features
Features are nouns and they multiply. Actions are verbs and they are countable.
Instead of "user profiles, notifications, search, favourites", write what a person actually does: find a thing, book a thing, pay for a thing, get confirmation. Four actions. Now you can see the shape.
Step 3: run every action through four questions
Ask of each action
- Does the core sentence break without it?If not, it is version two.
- Can we do it manually for the first hundred users?Onboarding, approvals, matching, and reporting can nearly all be done by a human at small scale.
- Are we building it because a user needs it, or because it feels incomplete without it?Settings screens are the classic case.
- Would we notice if it were missing on launch day?Genuinely ask. Most of the time the answer is no.
Anything that fails all four goes on the version-two list, which is not a bin. It is where you keep the ideas you will judge later using real evidence.
Step 4: keep the four things you must not cut
- The core actionEnd to end, working properly.
- Whatever makes it trustworthyAuth done properly, payment handled properly, data protected properly. Never cut these to save time.
- A way to observe what is happeningAn admin view. You cannot learn from a product you cannot see.
- A route to real usersIn the stores, or wherever they actually are.
Step 5: sanity-check the result
Read the scope back and ask: if we shipped exactly this and nothing else, would a real person use it more than once?
If yes, you are done. If no, you have cut too far, and the thing you removed last is probably the thing that has to go back.
What usually goes wrong
The stakeholder feature. Somebody senior wants something. Put it on the version-two list rather than arguing. Lists defuse this; debates do not.
The "while we're in there" feature. It always costs more than it looks, because it is never actually adjacent.
The compliance surprise. Something that seemed like a small feature turns out to require consent handling, retention rules, or an audit trail. Ask about data early.
Cutting the wrong things. Teams cut quality and testing before they cut features, because features are visible and quality is not. This is always the wrong order.
Common questions
How many features should an MVP have?
Count actions, not features. One core action a user can complete end to end, plus whatever is strictly needed to make that action repeatable. Most first feature lists contain three or four products pretending to be one.
What if my product needs two sides to work?
Then it needs two sides, and it is a bigger build. But test that assumption hard: many marketplaces launch by doing one side manually until there is enough demand to justify building it.
How do I say no to a stakeholder's feature?
Do not say no, say not yet, and write it on a visible version-two list. Almost nobody argues with a list that exists. People argue with features that seem to have been forgotten.