MVP Design, How to Know What to Build First

How to scope an MVP. From the feature brain dump through honest prioritization to core user flows and wireframes.

Every founder I’ve worked with has a massive vision. A list of fifty features. The MVP design process is how we turn that vision into something shippable. A list of fifty features. An app that does everything. And every successful product I’ve seen started by building a fraction of that list.

MVP, minimum viable product, isn’t about building something bad. It’s about building the smallest thing that’s genuinely useful, shipping it, and learning from real users before investing in the rest. As a designer, my job is to help figure out what that smallest useful thing actually is.

What an MVP Actually Is

The term gets used to mean ”cheap version”, and that is not what it means. Eric Ries, who put the phrase into circulation, defined it in 2009 as ”that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.

Read that again, because the important word is learning. An MVP is not a smaller product. It is an instrument for finding out whether you are right.

That distinction decides everything downstream. If the goal is a cheap version, you cut quality everywhere evenly and ship something that works badly at everything. If the goal is learning, you cut scope brutally and keep quality high on the one thing you are testing. The second one is harder to agree to and it is the only one that works.

What an MVP is not:

• Not a prototype. A prototype answers a question inside the team. An MVP is used by real people who do not know it is an experiment.
• Not a beta. A beta is a finished product being tested for defects. An MVP is an unfinished product being tested for demand.
• Not permission to ship something broken. Minimum applies to scope, not to craft.

Start With the Brain Dump

Before we cut anything, we capture everything. Every feature, every idea, every dream. Things the client has wanted since day one, features they’ve seen in competitor apps, ideas that came up in user conversations, nice-to-haves they know are ambitious but want on the record anyway.

This brain dump matters because it gives us the complete picture. The MVP design process depends on seeing everything before you start cutting. You can’t make good decisions about what to cut if you don’t know the full scope of what exists. It also makes clients feel heard, every idea gets documented before we start prioritizing.

The MVP Design Process: The Honest Conversation

Here’s where it gets real. Out of this entire list, what are the three to five core features that must exist for the product to work? Not ”would be nice to have.” Not ”our competitor has it.” What is fundamentally necessary for a user to get value from this product?

This conversation requires honesty from both sides. Clients are passionate about their vision, that’s a good thing. But passion can make it hard to see that some features are phase-two territory, not launch requirements. My role is to help frame it clearly: cutting a feature from the MVP doesn’t mean it won’t exist. It means we’re being strategic about what to build first.

The products that launch well are the ones that do a few things excellently, not many things adequately.

How I Decide What Stays In

Cutting by opinion turns into a negotiation, and the loudest person wins. So I score instead. It is not sophisticated and that is the point, because it has to survive a room with a founder in it.

Every feature on the brain dump gets two numbers from one to five.

Does the product work without it? Five means the product is meaningless without it. One means nobody notices it is missing.

What does it cost to build? Five means weeks and a new dependency. One means an afternoon.

Then the list sorts itself. High necessity and low cost is the MVP. High necessity and high cost is the hard conversation, and usually the real product. Low necessity and low cost is the trap, because it looks free and it is what makes an MVP quietly triple in size. Low necessity and high cost goes on a list called later, which is a real list that we keep, because things people feel heard about stop coming back.

The value of scoring is not accuracy. It is that disagreement becomes visible. When two people give the same feature a five and a one, the argument stops being about the feature and starts being about what the product is for, which is the argument worth having.

The core flow gets drawn on paper first. It is cheaper to be wrong there.

Defining the Core User Flow

Once we know the MVP features, I map the core user flow. How does someone move through the product to accomplish the primary task? Every screen is a box, every navigation path is an arrow. This simple diagram reveals a lot.

Are there unnecessary steps? Screens that don’t add value? Dead ends where a user might get stuck? Confusing forks where the path forward isn’t clear? These problems are much cheaper to fix in a flow diagram than in a finished design.

The flow also validates the MVP scope. If a feature we included in the MVP doesn’t appear in the core user flow, we should question whether it’s truly core. If the flow feels incomplete without a feature we deferred, maybe it needs to come back in.

Wireframes Before Pixels

With the flow mapped, I wireframe each screen. Low-fidelity, grayscale, simple shapes. This is the UX phase of the UI/UX separation I use on every project. No visual design, no branding, just structure. Where does each element live? What’s the information hierarchy? What’s the most important action on this screen?

Wireframes force clarity. When you can’t hide behind beautiful colors or polished typography, every structural decision is exposed. Does this layout actually make sense? Is the call to action obvious? Can a user understand what to do within seconds?

This is also where the UX research lens applies. I look at how other products in the same space handle similar screens. Not to copy, but to understand the conventions users already expect. If every competitor puts the search bar at the top, putting it at the bottom might be innovative, or it might just be confusing.

How Finished Should an MVP Wireframe Be

Less finished than feels comfortable. The purpose of a wireframe at this stage is to be cheap to throw away.

My rule is that a wireframe is done when someone who has not seen it can describe what happens on the screen and what to do next. Not when it looks nice. Boxes, real words, correct hierarchy, no colour, no final copy, no icons that took an hour.

Two things I always put in even at low fidelity, because leaving them out hides the hard problems:

The empty state. Every product is empty on day one, and that is precisely the screen a new user meets. A wireframe that only shows the screen full of content is a wireframe of the good day.

The error. What the screen looks like when the thing does not work. If it has no design, it will get one at three in the morning from whoever is building it.

Real text matters more than it sounds. Lorem ipsum makes every layout look balanced, which is a lie. Writing the actual words in the wireframe is where you find out that the button needs three words and does not fit, and that is a cheap thing to find out now.

The System Underneath

This is where I disagree with most advice on MVPs. The scope should be ruthless. The structure should not.

Some decisions are cheap now and expensive later, and they are the ones people skip because they are invisible in a demo.

The data model. How you name and relate things at the start survives long after the interface is redrawn. Renaming a concept once real data exists is migration work, and it always costs more than it should.

Authentication and accounts. Bolting on real accounts after launch means touching everything you built. Even a thin version should be planned properly.

Design tokens. Colour, spacing and type as named values rather than hard-coded numbers. This costs one afternoon at the start and saves a rebuild later. It is also what makes a dark mode a small job instead of a project.

The one flow you are testing. Whatever the product exists to prove has to work properly. If people cannot complete it, you learn nothing about demand, only about your bugs.

Everything else can be scrappy. Admin can be a spreadsheet. Settings can be one screen. Onboarding can be a sentence.

What to Measure Once It Is Live

An MVP that ships without a defined question is just a small product. Before launch I want one sentence answered: what would make us confident we are right, and what would make us stop.

Three things worth watching, in this order:

Completion. Of the people who start the core flow, how many finish it. This is the only number that tells you whether the thing works.

Return. How many come back without being reminded. It separates curiosity from need, and it is the one founders least want to look at.

The thing they do instead. Where people go when they do not do what you expected. That is usually where the real product is hiding.

Vanity numbers, signups and pageviews, mostly measure how well you announced it.

Four Ways I See MVPs Go Wrong

The MVP that is a smaller version of everything. Every feature at half quality instead of one feature done properly. Users conclude the product is bad rather than incomplete, and that conclusion is hard to reverse.

The MVP that never ships. One more feature, and one more. If the scope grew after the cut, the cut did not happen.

The MVP nobody measures. It launches, everyone moves on, and six months later the same argument is still opinion against opinion.

The MVP built on a structure that cannot grow. It succeeds, and then the success has to be rebuilt from scratch, which is the most expensive way to be right.

Why Less Actually Leads to More

The counterintuitive truth about MVP design: constraints produce better products. When you can only build five screens, every screen has to earn its place. Every interaction has to matter. There’s no room for filler.

As Y Combinator’s startup advice shows, learning from real users beats assumptions every time. And once the MVP is live, something powerful happens: real users show you what to build next. Not your assumptions, not your competitor’s feature list, actual behavior from actual people using your actual product. The features you add in phase two are informed by evidence, not guesses.

That’s why cutting features from the MVP isn’t a compromise. It’s the most strategic design decision you can make. If you are looking for help with this process, here is how I approach app design from start to finish.

Scoping an MVP is the part of a project I like most, because it is where design stops being decoration and starts being a decision about what a product is for. It is one of the things I work on, alongside the interface and the build itself, which you can read about on what I do.