Which Features Belong in an MVP? Four Rules for Cutting Scope

"Let's build an MVP first and test the water." Most companies have said this. Then the requirements session starts, the MVP gets read as "the full product with fewer features", and the first version quietly absorbs multi-role permissions, a points system, a data wall and a full message centre. Five months later everyone is back at the question nobody wanted to face: the budget is short, the timeline is long, and the direction is still unvalidated.

The correct reading is different. An MVP is not a smaller product. It is one core business loop that runs end to end, with everything else cut away. MVP feature prioritization comes down to four rules that decide what goes and what stays.

1. Define the core loop before the feature list

The core loop is the minimum set of steps a real user must pass through to complete one full business action. In EV charging operations it is scan, start charging, meter, pay, stop. In membership retail it is register, order, pay, redeem.

Once that loop is written down, the feature list has a basis for decisions: anything on the loop is mandatory, anything off it is cut by default. By this standard a real MVP usually has 8-15 core screens, not 30-60.

2. Four categories to cut

Multi-role permission systems. Version one needs two levels: administrator and ordinary user. Role matrices, data-level permissions and workflow engines can wait until the business is running and roles have genuinely diverged. Cutting this typically saves three to five weeks.

Full reporting and data walls. What version one needs is a minimal dashboard that shows the core numbers: orders today, revenue today, success rate. Multi-dimensional analysis, period comparisons and customisable report engines belong to version two.

Incentive mechanics. Points, tiers, coupons, distribution, referral. These all presuppose users and transaction history. Launching them during cold start means nobody uses them while the team spends weeks tuning rules.

Nice-to-have experience work. Multiple languages, dark mode, a full message centre, in-app customer service chat, share poster generation. None of these block the loop, and none stops a user completing a transaction.

In our experience these four categories absorb more than 40 percent of a first version's requirement volume. Cutting them does not lower quality; it concentrates the budget on the loop that decides whether the product works.

3. Four categories MVP feature prioritization must keep

However hard you compress, these four must survive. Cutting them removes the MVP's reason to exist:

• Identity and login. Without accounts there is no trackable user behaviour and no way to read retention.
• The core business flow. This is why the MVP exists. An incomplete main flow means the product does not stand up.
• Payment or settlement, where the business involves transactions. If the transaction loop does not run, what you validate is a fake requirement.
• Error messaging and failure handling. What the user sees when payment fails, the network drops or stock runs out. These details decide whether anyone comes back, and they are the most commonly skipped part of a first version.

One more item is often overlooked and must stay: basic analytics and logging. Without them, after launch you can see that people used the product but not where they got stuck. Instrumentation is cheap to add up front and expensive to retrofit, so put it in the first build.

4. What a first version should look like

A healthy MVP has roughly 15-25 feature points, 8-15 core screens, one or two clients (a user-facing app plus an admin console), and two or three third-party integrations.

At that scale, development typically runs 6-10 weeks and quotes land between RMB 50,000 and 150,000. Within that range the cost split is roughly: product and prototype 8-10 percent, visual design 12-15 percent, development 50-55 percent, testing and integration about 10 percent, project management and deployment 8-10 percent.

If a first-version quote exceeds RMB 200,000 or the schedule stretches past four months, do not cut the budget first. Re-read the feature list — most likely something from outside the loop has crept back in.

5. How to tell whether the MVP feature prioritization was right

After launch, three metrics are enough to judge the scoping:

• Core loop completion rate. Of the people who arrive, how many finish the full flow. Below 30 percent, some step in the flow has more friction than estimated.
• First-week retention or first repeat purchase. Whether users come back on their own after one use. This is the direct signal that the need is real.
• Manual work replaced. How much of what used to happen over WeChat, spreadsheets and phone calls now runs in the system. For internal management tools this matters more than the first two.

When two of the three hit target, talk about expanding for version two. When none do, the problem is not the feature count but that the core loop does not solve a real pain point — and adding features will only push the direction further off course.

One practical note to finish: settle the MVP feature list before you go for quotes. With a list you get comparable numbers. With "I want to build a platform" you get three numbers that cannot be compared at all.