How to prioritise features for an MVP when everything feels essential

Everything feels essential because everyone has a stake

The moment a product enters planning, feature requests arrive from every direction. Marketing wants an onboarding flow. The product owner wants push notifications. The board wants a dashboard. And technically, all of those are useful things. But an MVP is not v1.0. An MVP is a focused question directed at reality.

At Livewall, we build digital products and platforms for brands including AvroTros, Sportvisunie, and KLM. We see the same pattern repeatedly: teams that start with a sharp hypothesis and end up with a product that does too much to prove anything clearly. The result is delays, budget overrun, and a launch that does not answer the question that started the whole thing.

The fix is not more discipline. It is a better framework for understanding what you are actually trying to validate.

Start with the hypothesis, not the feature list

Most teams begin with a list of features and then try to cut it down. This does not work, because by the time the conversation starts, every feature already has an advocate.

Instead, start with one sentence: What are you trying to prove?

Not "we want to build a loyalty app", but: "We believe active sports members will share their movement data to earn rewards, if those rewards are relevant enough to motivate the exchange."

With that hypothesis as your compass, the question you ask about every feature changes: does this help us validate or invalidate the hypothesis? If yes, keep it. If not, park it.

This sounds simple. In practice it is political. Every department has assumptions they want validated. The trick is to have those conversations before the build starts, not in the middle of a sprint.

Why MoSCoW fails in practice

MoSCoW (Must have, Should have, Could have, Won't have) is the most commonly used prioritisation method and also the most commonly misused one. In practice, Must-haves end up containing 80% of the feature list, because nobody wants to admit their feature is only a Should.

A more effective approach: work from the outside in. Ask three questions for every feature:

1. Can a user complete the core action without this feature? If yes, it is not a Must-have for the MVP.

2. Does leaving this out make it impossible to test the hypothesis? Not: "it would be better with this feature." But: "without this, we cannot answer the question."

3. Can this be added later without significant technical debt? If yes, waiting is not a compromise. It is simply a better sequence.

At Livewall, our UX/UI design process starts from user behavior, not from feature lists. That means by the time we are mapping journeys, we already have a clear picture of which interactions are load-bearing and which are enhancements.

The role of users in prioritisation decisions

A mistake we see regularly: teams prioritising features without any user research. They build on internal stakeholder assumptions and are then surprised when the product gets used differently than expected after launch.

For our MVP development engagements, we always begin with a short research sprint, a few days of user interviews or prototype tests to pressure-test the roughest assumptions. Not to fully define the product, but to avoid spending six weeks building something users cannot figure out within the first five minutes.

This applies to onboarding too. One of the most underestimated MVP mistakes is a poor first-user experience. If people cannot understand what to do, you see that in your activation numbers, not in your feature completeness score.

Catching scope creep before it takes hold

Scope creep rarely starts as a big decision. It starts as a small request: "Can we add a filter option here?" Or: "It would be useful if users could edit their profile."

Each of those requests sounds reasonable on its own. Together, they add weeks of work and produce a product that nobody feels entirely responsible for.

The most effective countermeasure: any request that comes in after the initial scope is set goes automatically onto a separate backlog. Not into the current sprint, not into the MVP. Into a separate list that you evaluate after launch based on real usage data.

This sounds rigid. But most teams find that half of those requests never resurface once the product is live and real feedback starts coming in.

On the AvroTros Eurovision Voting App project, tight event deadlines forced sharp decision-making. That external pressure kept the team aligned around the core experience. The result was an app that reached number one in the App Store, built on a clear and focused product core.

Technical debt as a signal, not a failure

A healthy MVP can contain deliberate technical shortcuts, as long as you choose them consciously and document them. Hardcoded logic that will later need to be generalised. A manual process that will eventually be automated. That is not sloppy engineering, it is a deliberate tradeoff.

What you do not want: technical shortcuts that get in the way of the validation itself. If performance is so poor that users drop off before reaching the core feature, you do not have an MVP. You have a prototype that cannot generate useful signal.

The line is straightforward: technical quality needs to be high enough to measure honest user behavior. Everything above that threshold is optional for the MVP phase.

Our web application development team works with explicit quality tiers per component, so everyone knows what is being built for validation now and what is being staged for scale later.

The framework in practice

Prioritisation is not about cutting for the sake of cutting. It is about staying focused on what you need to learn.

Step 1: Write the hypothesis as a single testable sentence.

Step 2: Evaluate every feature on its contribution to validating that hypothesis, not on its desirability.

Step 3: Create a hard boundary between MVP scope and the post-launch backlog.

Step 4: Actively protect that boundary, even as pressure builds.

Step 5: Launch, measure, and use real data to decide what gets built next.

At Livewall, we have seen this framework help teams ship faster, learn more, and rebuild less. That is not an ideal scenario, that is just what good product development looks like.