To decide what to build first in an MVP, start from the single assumption you most need to test, and build only the smallest version of the product that can test it honestly. Everything else, every feature that would be nice to have but is not required to find out whether the core idea works, waits. That sounds obvious written down, but in practice most teams get it wrong in one of two ways: they build too little to learn anything real, or they build so much that "minimum" stops meaning anything.
Getting this decision right matters because an MVP is not a smaller version of your final product. It is a tool for learning, and every feature added to it has to earn its place by making that learning better, not by making the product feel more finished.
What "Minimum" Actually Means in an MVP
The word minimum in minimum viable product trips people up because it sounds like a budget constraint, as if you are simply building the cheapest version you can get away with. That is the wrong frame. Minimum means the smallest set of functionality that can genuinely test your riskiest assumption, no more and no less.
Viable is doing just as much work in that phrase. A viable version has to actually work for the person using it. It does not need to be polished, automated, or built to scale, but it needs to deliver the real outcome the person came for, even if a human is doing part of the work behind the scenes. A fake button that leads nowhere is not viable. A clunky process that genuinely solves the problem, even manually, usually is.
So before you decide what to build first in an MVP, you need a clear answer to one question: what is the one thing you are not yet sure is true, and what is the smallest build that would prove or disprove it?
Start From the One Problem You Are Testing
If you have already gone through validating the idea, you should have a specific problem statement: who has the problem, what they are trying to do, and what gets in the way today. That statement is your starting point for scoping the build, not a new brainstorming exercise.
Write down the single outcome a user needs to get from using your product for the first time to count as a genuine win. Not the full vision of the product. Just the first real outcome. If you cannot describe it in one sentence, you are not ready to decide what to build, because you have not yet decided what success looks like.
This is also the point to sketch the path someone takes from first realising they have the problem to getting that outcome, even in rough form. A simple map of this path, similar to a customer journey map, tends to expose which steps are essential and which ones you have quietly assumed matter because they would be nice, not because they are necessary.
How to Decide What to Build First in an MVP
Once you have the single outcome defined, list every feature or screen you can imagine the product needing, without editing yourself. Then sort that list into three groups.
Required to deliver the core outcome. Without this, the product simply does not work for its stated purpose. If a to-do app cannot let someone add a task, that is required. Everything in this group is a candidate for version one.
Makes the outcome easier or nicer, but is not required for it to happen. Notifications, customisation, a polished design, integrations with other tools. These improve the experience once people are already getting value, but their absence does not stop the core job being done.
Solves a problem you do not actually have evidence for yet. This group is sneaky because it often disguises itself as thoughtful planning: supporting a use case you imagine a future user might have, building for scale you do not have, or adding flexibility nobody has asked for. Most scope creep in an early product comes from this group, not the first two.
A Simple Way to Score Features
For anything that lands in the first or second group and you are still unsure about, ask two questions. First, does removing this feature stop someone from reaching the core outcome. If yes, it belongs in version one. If no, move to the second question: is there evidence, from the conversations or tests you ran during validation, that people specifically asked for or struggled without this. If the answer to both questions is no, leave it out for now.
This keeps the decision grounded in what you actually know rather than what feels professional or complete. A missing feature nobody has mentioned wanting is a reasonable gap. One that every person you spoke to flagged as a dealbreaker is not optional, however small it looks on a feature list.
What to Leave Out of Version One
Several categories of work are almost always safe to leave out of a first build, whatever the product.
Account and permission systems beyond the basics. Unless access control is the actual problem you are solving, a single login type and no roles is usually enough to start.
Automation of anything you can do manually for a handful of users. Doing a step by hand, sending an email yourself, manually moving data between two tools, is often faster to set up and easier to change than automating a process you do not yet fully understand. Paul Graham's essay on doing things that do not scale is a useful reminder that manual effort early on is how you learn what the real process should be, before you lock it into code.
Settings and configuration options. Every toggle is a decision you are asking the user to make, and a path you now have to maintain. Pick a sensible default and let feedback tell you whether people actually need to change it.
Anything built for a scale you do not have. Performance work, caching, elaborate error handling for edge cases that have never happened, all matter eventually, but far less than finding out whether anyone wants the product at all.
Signs You Are Building Too Much
A few warning signs tend to show up consistently when an MVP has grown past what it should be.
The build has been going for months with no real users yet. The team is discussing features for a use case nobody in your validation conversations described. You find yourself saying "we'll need this eventually" to justify building something now. Any one of these is worth stopping and re-checking your list against the single outcome you defined earlier.
The Lean Startup approach to this is to treat the first build as the start of a loop, not a finished product: build the smallest viable version, measure what real users actually do with it, and let that evidence decide what gets built next. Teams that treat the MVP as a one-off delivery rather than the first lap of that loop are the ones most likely to overbuild it, because without a learn-and-adjust step afterwards, every feature feels equally important to get right the first time.
When to Add the Next Feature
Once version one is live with real users, resist the pull to immediately build the second tier of features you set aside. Watch what people actually do, and let the gaps you observe decide what to build next, rather than the list made before anyone had used the product.
If users consistently hit a specific point and stop, that is a strong signal. If a "nice to have" feature keeps coming up unprompted in feedback, move it up. If nobody mentions something you assumed mattered, leave it out longer than feels comfortable. Basecamp's Shape Up makes a similar case for working in small, fixed-scope batches rather than open-ended feature lists, because an open list never stops growing on its own.
Common Mistakes When Deciding What Belongs in an MVP
Confusing minimum with cheap or low quality. A minimum viable product still has to work properly for the job it does. Cutting corners on the one thing it needs to do well is not scoping, it is building something broken.
Building for an imagined future user instead of the real first one. Flexibility for a market you have not reached yet usually means complexity for the market you are trying to reach now.
Treating every stakeholder request as required. Not every opinion about the product carries equal weight against evidence from the people you are actually building it for.
Skipping the single outcome exercise. Without a clearly written core outcome, every feature discussion becomes a debate with no shared standard to settle it against.
If this is the stage you are at with a product idea, GrowNowNow's work building small products follows the same approach: start from the one outcome that matters, build the smallest thing that delivers it, and let real usage decide what comes next.
Frequently Asked Questions
How small should an MVP actually be?
As small as it can be while still delivering the one outcome you defined as the point of version one. There is no fixed number of features that counts as correctly sized. The right test is whether removing anything else would stop the core outcome from happening.
Should an MVP include a polished design?
Not necessarily. A rough but clear design that does not confuse people is usually enough. Polish matters more once you know people want the product and use it regularly, since design effort spent earlier often gets thrown away once the product changes based on what you learn.
What if different early users ask for completely different features?
Treat this as a signal about your audience rather than your feature list. If requests genuinely diverge, it often means you are serving more than one type of user, and narrowing who you are building for is more useful than adding every request to the product.
Is it ever right to build more than the strict minimum at the start?
Occasionally, if a feature is cheap to add and removes a real barrier to honest feedback, such as basic error messages that stop people getting stuck silently. The test stays the same: does this help you learn faster, or just make the product feel more complete.
How do I know when the MVP stage is over?
There is no fixed point, but a reasonable marker is a steady group of real users getting the core outcome repeatedly, with your next decisions driven by what they actually do rather than by assumptions made before launch.