MVP Feature Prioritization: The One-Hypothesis Rule

Every feature in an MVP has a lawyer.

“Customers will expect it.” “Sales needs it.” “It is almost free to add.” “We cannot launch without dark mode because one of our advisors prefers it.”

Nobody argues for a feature because they enjoy delays. They argue because the final product already exists in their imagination—and the MVP looks painfully incomplete by comparison.

That is exactly the point.

An MVP should not prove you can build the whole vision. It should test the one belief that makes the vision worth building. Choose that hypothesis first, then include only what a real user needs to complete the test safely.

Your backlog is not a strategy

A long backlog feels responsible. It captures ideas, calms stakeholders, and gives every meeting somewhere to put its anxiety.

But a backlog does not tell you what the first release is for.

The UK Government’s guidance on deciding priorities recommends grounding choices in user research, performance information, and stakeholder input—and revisiting them as the service changes. The important idea is that priority is contextual. “Valuable someday” and “essential now” are different categories.

Your MVP needs a sharper organizing principle than a vote.

Write one hypothesis worth testing

Use this format:

We believe [specific user] will [take a specific action] because [promised value]. We will know enough to make the next decision when [observable evidence] occurs.

A hypothetical example:

We believe independent service contractors will upload job details and pay for a professionally structured proposal because it reduces the time and uncertainty of preparing one. We will know enough to continue when real users can complete the flow, understand the output, and choose whether to use it.

Notice what is not being tested: team chat, advanced analytics, twelve template families, referral rewards, and an AI mascot with opinions.

Those may become good features. They are not required to test the belief.

Build the four-part Learning Loop

The MVP must let the target user complete four things.

1. Arrive with the right expectation

The user needs to understand what the product does, who it is for, and why the next step is worth taking.

This may require a focused landing page, clear offer, sign-in, or invitation. It does not require a complete marketing universe.

2. Perform the core action

This is the job at the center of the hypothesis: submit the request, configure the item, generate the result, collaborate on the decision, or complete the transaction.

Protect this path aggressively. If an idea does not make the core action possible, understandable, safe, or meaningfully better for the test, it is probably not first-release scope.

3. Receive the promised value

The loop is not complete when the user clicks the final button. They must receive and understand the outcome.

That may mean a usable document, a completed booking, a clear recommendation, a shared workspace, or a confirmed handoff. The promise cannot live only in the demo script.

4. Create evidence for the next decision

You need enough visibility to learn what happened. Did users complete the action? Where did they stop? Did the result make sense? What required support? Would they use it again?

This does not require surveillance theater or a dashboard with 47 charts. It requires evidence tied to the hypothesis.

Put every feature through the removal test

For each candidate feature, ask:

1. If we remove it, can the target user still complete the Learning Loop?
2. Would removing it make the evidence misleading?
3. Would removing it make the product unsafe, inaccessible, unreliable, or impossible to support?
4. Are we adding it because users need it now—or because the unfinished product makes us uncomfortable?

If the loop still works and the product remains viable, move the feature out.

Not delete. Not condemn. Move.

A visible “not now” list is one of the best tools in product work. It reassures stakeholders that the idea was heard while protecting the release from becoming a museum of everyone’s favorite feature.

Viable includes the unglamorous work

Teams sometimes interpret “minimum” as permission to postpone anything that is not visible in a screenshot.

That is how a tiny product launches with no password reset, unusable error messages, missing access controls, and a support plan consisting of the founder’s personal phone.

Viability includes the level of security, accessibility, reliability, privacy, and operational support appropriate to the use case. It also includes the boring states: empty, loading, failed, expired, duplicated, and interrupted.

The official guidance on writing user stories centers each story on the user, the need, the goal, and acceptance criteria. That is a useful antidote to feature vanity. If you cannot explain who needs the capability, why, and what “done” means, it has not earned its place.

Watch for the four scope-inflation disguises

“It will be harder to add later”

Sometimes true. Ask for the architectural evidence. A foundation that protects future options may belong now; the entire future feature usually does not.

“It is only a small addition”

The visible control may be small. The states, permissions, testing, support, and edge cases may not be. Count the complete behavior.

“Competitors have it”

Your MVP is testing your hypothesis, not reenacting a competitor’s mature roadmap. Understand why their users need it before inheriting it.

“We need it to look credible”

Credibility matters. But credibility comes from a coherent promise, trustworthy execution, and professional presentation—not from the number of navigation items.

Launch should change the backlog

The whole advantage of an MVP is that real use gets a vote.

The UK service standard on agile ways of working emphasizes putting a service in front of users, observing what happens, and iterating from the evidence. If the roadmap remains untouched after launch, the team has treated feedback as applause rather than information.

Some “must-have” features will vanish. Small frustrations will reveal themselves as major adoption barriers. Users may value a part of the product the team considered secondary. That is not the plan failing. That is the plan finally meeting reality.

Build enough product to earn the next decision

Start with one hypothesis. Draw the four-part Learning Loop. Admit every feature through the removal test. Protect viability. Move the rest to a clearly labeled next-release backlog.

Your MVP is ready when it can produce honest evidence—not when everyone has run out of ideas.

If your scope keeps growing because the product has not found its center, an MVP development process can turn the vision into a focused first release with a clear learning goal, deliberate boundaries, and room to grow after the evidence arrives.