How to Decide What Features to Build First (Your MVP Is Too Big)

Ask a first-time founder what their app does and you rarely get one sentence. You get five features, three user types, and a roadmap. Every one of those features feels essential, because each one is attached to a real scenario the founder has imagined in loving detail.

Here is the uncomfortable statistic-shaped truth behind most failed first apps: they do not die because the code was bad or the market did not exist. They die because the first version was too big. Too big to ship quickly, too big to learn from, too big to fix when the learning finally arrived. Deciding what features to build first is the highest-leverage product decision you will make, and it is mostly a discipline of subtraction.

Your MVP has one job

A first version is not a small edition of the finished product. It is an instrument for answering a question: will these specific people use this specific solution for this specific problem, repeatedly?

That reframe does most of the prioritization work for you. A feature belongs in the first version only if the question cannot be answered without it. Everything else, however good, however differentiating someday, is noise that delays the answer.

So before any framework, write the question your app must answer. For a habit app for coaching clients it might be: will clients log their habits at least four days a week when their coach can see it? Notice what that question does not require. It does not require streaks, badges, a social feed, an AI insights tab, or a settings page with themes. It requires logging, and a coach view.

Find the core loop

Every app that retains users has a core loop, the repeated cycle that delivers the value: log a habit, see progress, feel accountable, return tomorrow. Track an expense, see the budget move. Write a flashcard, get quizzed, remember.

Your first version is the core loop and almost nothing else. A useful test for every candidate feature: if I remove this, does the loop still run? If yes, it is not first-version material, no matter how attached you are to it. Onboarding tours, profile customization, notifications settings, data export, admin dashboards, all of these fail the test. They are supporting furniture around a loop that does not need them to prove itself.

The loop test also catches a subtler trap, the second loop. Many founders bundle two products into one app: the tracker and the community, the planner and the marketplace. Each loop halves the focus and doubles the surface area. Ship one loop. The second one becomes your first big experiment after launch, informed by real users instead of guesses.

Run one honest prioritization pass

With the loop defined, put every remaining feature idea through a single explicit pass. The classic frameworks all work because they force the same two judgments: how much this matters and how much it costs.

The simplest version is a value against effort grid. Score each feature for impact on your core question, and for build effort. What survives is the small set of high-impact, low-to-medium effort items. Be brutal about the definition of impact: impact on the question, not impact on how impressive the app looks.

If you prefer categories, MoSCoW works: must have, should have, could have, will not have. The only rule that matters is that "must have" is reserved for loop-critical features. The first time you do this honestly, your must-have list will shrink to four or five items and it will feel wrong. That feeling is the oversized roadmap leaving your body.

One more lens worth borrowing from the Kano model: users treat some features as basic expectations, some as performance, and some as delighters. First versions need the basics of the loop done well, plus at most one delighter, one small touch that makes someone smile and mention the app to a friend. More than one is decoration.

Let validation data pick, not your imagination

Everything above still leaves room for self-deception, because you are scoring impact by intuition. The fix is to have real signal before you scope.

This is the deeper reason to validate before you build. A landing page describing the product, a waitlist of the actual audience, conversations with the people who signed up, these produce a ranked list of what the audience actually cares about, in their own words. When thirty waitlist signups all mention accountability and nobody mentions statistics, your feature priorities have been decided for you. The graph tab you were sure was essential just moved to the will-not-have column, and it cost you nothing to find out.

Cheap prototypes extend the same principle into design. A clickable wireframe shown to five target users will kill or confirm a feature in an afternoon, at roughly one percent of the cost of building it. The order is always: validate the promise, sketch the loop, test the sketch, then build.

The cut list, kept in public

Cutting features is emotionally expensive, which is why founders quietly sneak them back in. The antidote is a visible cut list: a document of every feature you deliberately did not build, each with one line on what evidence would earn it a place in a future version.

This does three things. It turns cutting from loss into deferral, which makes the discipline sustainable. It gives you a ready-made experiment backlog for the day the app is live and the decision gate says grow. And it keeps the first version honest, because any feature trying to enter the build has to pass the same bar as the ones already on the list.

A good first version plus a good cut list is a complete product strategy. The app answers the core question. The list holds the future, sorted by evidence required.

What shipping small buys you

Every week cut from the first build is a week earlier you learn the truth. If the loop works, you iterate from strength with real users pulling features out of you. If the loop does not work, you have lost weeks instead of months and you still have your audience, your landing page, and your energy for the next attempt.

Small first versions also stay fixable. When feedback arrives, a five-feature app can turn in days. A twenty-feature app turns like a container ship, and most founders' motivation sinks before it does.

So write the one question. Draw the one loop. Run one honest prioritization pass with real audience signal. Keep the cut list where you can see it. Then ship the smallest thing that runs the loop end to end, and let actual users write your roadmap from there.